Lyniate Team

How to Comply with the CMS ADT e-Notification Condition of Participation — and Answers to Other FAQs

December 30, 2020

API Primer The API resource for healthcare providers

Lyniate and PatientPing team up to answer questions about meeting this new Condition of Participation by the May 2021 deadline.  

 

The May 1, 2021 deadline for hospitals to comply with a new CMS Condition of Participation (CoP) — the electronic event notification requirement — is quickly approaching. The e-notification CoP requires all hospitals to make a reasonable effort to send e-notifications either directly or through an intermediary at the point of emergency department presentation/registration and discharge, as well as at the point of inpatient admission, discharge, and transfer.  

The goal of this CoP is to improve information sharing between hospitals and other providers across the care continuum. 

To help hospital CIOs, IT teams, and compliance officers understand the rule and evaluate solutions, Lyniate and our partner PatientPing hosted a webinar titled Prepare for the CMS Interoperability & Patient Access Rule (E-Notifications CoP).

Attendees asked some great questions during the webinar, which we’ve answered below. 

 

Q: What is the new requirement from CMS?

A: The new CMS e-notifications CoP requires all hospitals to send real-time e-notifications on patients’ inpatient and emergency department admits, transfers, and discharges (ADTs) to every patient’s PCP, post-acute providers (such as skilled nursing facilities and home health agencies), and primary care practice groups (e.g., ACOs, FQHCs).   

To become compliant, hospitals need the ability to send patient-directed e-notifications to PCPs and other patient-identified practitioners, and must respond to all valid primary care practice group and post-acute provider requests for e-notifications.  

Current EHR and health information exchange (HIE) solutions leave hospitals exposed to compliance gaps when it comes to fulfilling all required provider e-notifications. 

(For a deeper dive on the CoP, and how Lyniate and PatientPing are working together to help hospitals comply with it, please read our blog post The Countdown to CMS E-Notifications CoP Compliance: What You Need to Know and How Lyniate & PatientPing Ease the IT Compliance Burden.

 

Q: Who is a requestor?

A: A requestor can be virtually any one of the entities eligible to receive notifications from your hospital as per the CMS CoP requirements. For example, a primary care entity (ACO, FQHC, etc.), a PCP, or a post-acute provider (skilled nursing facility, home health, etc.).  

Any provider within these categories that has a treatment relationship with your patients is eligible to request for notifications about their patients’ events at your hospital.  

 

Q: What isPatientPing Route, and how does it work with Lyniate solutions?

A: PatientPingRoute helps hospitals achieve full compliance with the e-notifications CoP while minimizing IT and administrative burdens. PatientPing handles the complex roster processing and patient matching required to fulfill post-acute and primary care group e-notification requests, regardless of geographic location or type of requesting provider. PatientPing also enables patient-directed e-notifications compliance via our Direct Messaging capability. 

Lyniate customers already have all the necessary ADT messages flowing through their Corepoint or Rhapsody interface engines, and PatientPing is an expert managing patient roster functionality and delivering real-time e-notifications to its national network of over 5,000 post-acute providers. 

Lyniate and PatientPing are co-creating a connector that seamlessly interoperates between Lyniate engines and PatientPing’s Route solution.  

 

Q: Can CCD transmission meet the requirement? It supplies more information than an ADT message.

A:  While the rule applies to all hospitals with an EHR or registration system that has the capability specified in the rule (HL7 2.5.1), the actual notification that is sent does not need to meet a specific format (ADT, CCD, FHIR, secure text, other).   

Across data exchange platforms, the most common mechanism for transmitting event data out of a hospital system today is the HL7 2.3.1 ADT message, while the mechanisms for delivering the data to the end recipient span a wide variety of formats and technologies, including but not limited to ADT messages, portals (mobile/web), secure email (direct), and secure text. Any of these mechanisms for sending or delivering event messages will be compliant with the rule. 

 

Q: Does submission to an HIE with ADT data conform to this requirement?

A: It depends. CMS clarified recently that the e-notification CoP is not limited by the location of one particular provider. Does the HIE have the ability to send notifications to out-of-state providers? Does the HIE also have the capability to handle required notifications to different types of providers, such as those coming from post-acutes, ACOs, FQHCs, and individual PCPs, and other practitioners?   

 

Q: What about PCPs who do not have the capability to receive notifications, or for those that are also not PatientPing customers?

A: Notifications can be enabled in a variety of ways, and most primary care providers have at least some way to receive notifications today. PatientPing can enable notifications via SMS or email alerts, direct integrations, and a variety of other methods, as well as through a streamlined web-based portal that any provider can use through their web/mobile browser.  Note that PatientPing Route does not require the recipient to be an existing or future participant in the PatientPing network. 

 

Q: Is PatientPing part of a national HIE network?  

A: PatientPing is a national network in its own right, and the Route solution is technology- and network-agnostic. We enable the hospital to be compliant regardless of the provider’s network affiliation. That said, PatientPing does work with a number of HIEs and other interoperability conveners nationwide.   

 

Q: Can FHIR resources confer to this requirement?

A: The content and delivery format is not specified, so in theory FHIR is certainly possible. However, FHIR resources are not widely available/accepted by the broader provider/EHR community for this purpose (push notifications), so you likely won’t see FHIR being used for this purpose frequently except in very localized situations. 

 

Q: We have opt-out in North Carolina. If we have a query set that the patient wishes to opt out of sharing with the HIE, does that mean we also need to filter that out here? Or can that be sent as part of the HIE and filtered inPatientPing?

A: There are several ways to tackle opt-out. The best is always in the source system (EHR or integration engine). But other options are also possible. For example, sending PatientPing a list of the patient opt-outs, flagging opted-out patients in the ADT feed, or directing patients to an opt-out page. 

 

Q: We’re in Alaska. I see you’re not currently serving hospitals here.

A:  Our solution is geography-agnostic (well, within the United States), so we can certainly serve hospitals and their surrounding care community there. Note thatPatientPing Route does NOT require the recipient to be an existing or future participant in the PatientPing network. 

 

Q: What are the requirements around auditing the transmission (whether it is ADT or CCD) of the data?

A: The auditing requirements have not been fully specified and will not be until near the compliance date. We are in touch with all/most CMS auditors to ensure that our auditing capabilities meet or exceed the requirements as CMS guides those auditors, to ensure hospitals are always compliant. 

 

Q: Can that connector be used with all versions of Corepoint and/or Rhapsody, or is there a minimum version for implementing?

A: The connector will be available for all versions of Corepoint and Rhapsody.  

 

Q: Are both the sending facility and the receiving facility required to have PatientPing?

A: The requesting provider does not need to have PatientPing. The Route solution allows the requesting provider to log in and use the Requester Portal. This is included in the hospital solution, and as such the requesters pay nothing for this; it also comes with some other integration options beyond the portal.   

However, if the requesting provider wants to do more with the larger PatientPing network — for example, receive notification data beyond the specific hospital that has purchased Route — then they certainly can subscribe to one of our paid products that gives them network-wide access. 

 

Q: What are the costs?

A: The Lyniate to PaitentPing connectors are available at no cost. Please reach out to us to learn more. 

 

Q: With each facility having its own patient identifying numbers, how are patients matched?

A: PatientPing uses an industry/ONC-recognized patient matching algorithm to match patients. We have an industry-leading, >99.99% true positivity rate (i.e., false positive patient matches less than 0.01% of the time). We use standard demographics, as well as optional additional data, to do our matching magic.  

 

Q: How do we know which providers are subscribed to your portal? As you know, sending patient information to a provider that isn’t subscribed is a violation of HIPAA under the definition of bulk sending of data blindly to any organization. Not all our PCPs will subscribe to this solution, so how do we know which patients’ PCP are subscribed?  

A: This is top of mind for us. In addition to literally calling and vetting the requester, we require them to complete appropriate legal documentation. This is not an “open API” that any random organization can connect to. They must be a provider organization, and they have to be obligated to abide by HIPAA.   

 

Q: Does the May 1, 2021 deadline mean the technology must be set up for e-notification? Or that trading partners are identified and data sharing rights, security, and a technical solution is setup?  

A: This is subject to interpretation, but our perspective is that you have the technology up in order to be able to send e-notifications, and that it is functioning and live (security/privacy obviously being implied). However, whether you have proactively communicated this capability to the community seems beyond the scope of compliance. 

 

Q: How does the PCP actually get notified? Direct Email? ADT to their EMR Vendor?

A: There are a few. options. The requester may want to get it through direct messages, PatientPing’s web-based app, or one of our other integration options, such as SMS alerts, email alerts, or HL7 integrations. We want to be as flexible as possible to make sure that the requester’s experience is a good one — with the hope that flow of care coordination information has maximum impact.  

 

Do you have a question that we didn’t answer here? Let us know!




Related Blogs

How State HIEs Are Advancing Interoperability

Abigael Grippe

How State HIEs Are Advancing Interoperability

Read more

Abigael Grippe

TEFCA: Everything Healthcare Organizations Need to Know

Read more
Lyniate_Rapid_illustration_api_gateway_manager (1)

Lyniate Team

Lyniate introduces Rapid, a healthcare API gateway

Rapid is a healthcare API gateway and manager designed to help health teams create and safeguard APIs, including Fast Healthcare Interoperability Resources (FHIR)-based APIs like those required by the CMS Interoperability and Patient Access Rule.

Read more