Health Information Exchange in Long-Term and Post-Acute Care Settings: Final Report. Findings: Implementing Ehie Between Ltpac Providers and Exchange Partners


This section seeks to answer the following research questions:

  • What types of health information do the LTPAC providers and their trading partners need to support continuity and coordination of care; and how were these information needs identified? What types of information do the LTPAC providers and their trading partners create and transmit? How has the type and timing of information exchange changed since implementing eHIE?

  • What eHIE methods (i.e., what technology solutions) are used to transmit information to/from the LTPAC provider and their HIE trading partners? Does the method of exchange enable the interoperable exchange and re-use of needed clinical information? What are the costs of the technology solutions?

  • What do the LTPAC providers and their trading partners describe as being the advantages and disadvantages of engaging in eHIE with LTPAC providers?

Types of Information Required to Support Continuity of Care

Some of the types of information LTPAC providers and their trading partners require to support the continuity of care and general care coordination are encompassed under the 2014 Edition of EHR Certification Criteria and Stage 2 MU Objectives. However, the investments have not generally been made by LTPAC providers or HIE organizations to support the infrastructure required to support cost-effective and bidirectional exchange and re-use of information with and by LTPAC providers. Instead, at this point in time, hybrid or partial solutions with limited functionality are being implemented which are perceived as "good enough" substitutes for interoperable exchange.

The National Learning Consortium as developed by the Health Information Technology Research Center identified some of the specific types of information required to support care coordination between LTPAC providers and their trading partners.55 The interviews and site visits conducted under this project have found results consistent with this report. Specific elements of importance that were identified include: current medication list, allergy list, current problem list, and a discharge summary. These are well-established components of consolidated-clinical data architecture (C-CDA) requirements.

The issue becomes exchanging and re-using these data within evolving hybrid or limited exchange systems. LTPAC providers are not using MU-certified technologies and are opting for lower cost, feasible solutions in the short term such as view-only portals and the printing and scanning of exchanged CCDs into patient records (see Provider Organization Characteristics level of Conceptual Framework). These lower cost solutions often do not support the interoperable exchange and re-use of information. The interviews also suggest that a further barrier to adoption of EHRs and/or eHIE is providing solutions that provide perceived and actual benefits that justify their use over well-established faxed-based workflows within LTPAC organizations. The types of information required to support the continuity of care on behalf of LTPAC patients by LTPAC providers and their partners are known and available, but typically they are not exchanged in a functional manner that supports electronic re-use.

Electronic Health Record Penetration in Long-Term and Post-Acute Care Facilities

Interviews indicated that adoption of data exchange by LTPAC providers is inconsistent, even within an HIE service region. For example, in the interviews, some LTPAC and HIE respondents indicated that Medicare/Medicaid EHR Incentive Program Stage 2 MU requirements resulted in hospitals reaching out to NHs in order to meet non-affiliate exchange requirements. Others stated that their trading partners indicated that they were too busy meeting EHR Incentive Program MU requirements to deal with exchanging data with LTPAC facilities. Overall, the result has been an isolation of LTPAC providers away from larger evolving interoperable and integrated system of exchange. One result of this isolation is a narrowing of EHR vendors targeting the LTPAC market. Respondents indicated that many larger vendors of certified EHRs indicated a disinterest in the LTPAC market segment because the vendors were resources constrained by meeting MU certification requirements for existing customers and/or viewed LTPAC providers as inferior customers due to the lack of incentive dollars.

There appears a pronounced difference in the definition and functionality of EHRs between LPTACs and their partners. This has created confusion in understanding the capacity and characteristics of exchange. Studies and industry surveys have indicated that LTPAC providers have EHR adoption rates that are close to those of Medicare/Medicaid EHR Incentive Program-eligible providers. For example a March 2015, study by LeadingAge of LTPAC providers in the state of New York found 73% of NHs and 68% of health home agencies have partially or fully implemented an EHR.56 The authors identified a likely bias in respondents with a low response rate by non-adopters. More importantly, as occurred in earlier survey-based studies, respondents may be including electronic information systems used for recording patient demographics and reporting administrative and some quality data for regulatory compliance in their self-reporting of EHR adoption within the survey.

The difference in the definition of what capabilities and characteristics constitute an EHR has led to an ability to effectively compare adoption and use rates between LTPAC providers and their trading partners. The EHRs adopted by LTPAC providers have limited technological functionality when compared to the capabilities of the EHRs of their partners. While a few LTPAC facilities owned or closely associated with large IDSNs may have an MU-certified EHR, the vast majority of LTPAC providers do not have certified EHRs. Within the LTPAC market segment, the market share for EHR vendors has some regional characteristics and a degree of fragmentation, but national leaders are emerging. For NHs and SNFs, PCC is the largest provider on a national basis. For example in 2011, PCC had a 43% market share in Minnesota.57 The 2015 LeadingAge study found that PCC had an 18% market share in New York.58 As the leading EHR in-use in the LTPAC segment, PCC only added DSM in mid-2015. Within the PCC EHR, functionality is read-only and scan (the EHR does not consume or parse the data into the EHR). Other national NH and SNF vendors have indicated that they are moving towards including DSM capability in their EHR. This means that DSM is positioned to evolve as the principal bidirectional transport mechanism between NHs and SNFs and their trading partners using MU-certified EHRs.

Health Home versus Long-Term Care

HHAs have a different group of EHR vendors than NH and SNF providers. Based upon the site visits and interviews, HHAs appear more likely to be using an HHA HIT or EHR module from a certified EHR vendor than a NH or SNF using a certified EHR. This is likely due to either the HHA being owned by a hospital system or having a close hospital system affiliation. Non-certified EHRs for HHAs have similar constraints on interoperability as non-certified EHRs in the NH and SNF market segment relative to electronic data re-use, but interviews indicated an easier integration of the data. This is partially due to the nature of the services provided and the characteristics of the workflow. For example, visiting nurses will input data and notes onsite during the patient encounter. Based upon the site visits in Minnesota and Pennsylvania, there appeared near universal adoption of mobile technologies such as tablets or portable computers during patient encounters and the use of cellular systems to transmit that information to centralized systems. This supports the bidirectional exchange with both certified and non-certified EHR systems and potentially eHIE from remote locations.

Methods of Exchange

Based on our discussions with stakeholders from selected regional and state eHIEs, there currently are four potential methods and two potentially innovative solutions to data exchange for LTPAC providers and their trading partners. These are summarized in Table 1. Appendix B provides a further description of the technologies and their implications for LTPAC providers.

TABLE 1. Exchange Alternatives for LTPAC Providers
Technology LTPAC Provider Benefit LTPAC Provider Issues
Provider Portal
  • No cost to LTPAC
  • Privacy and security managed by provider
  • Bedside access
  • Widely in use and integrated into workflow
  • Viewed as "good enough" and an improvement over faxes
  • Uni-directional
  • No electronic data re-use
  • Includes limited information (e.g., most recent acute care episode)
  • Print and scan record
  • Data only from single provider system
  • Does not meet MU of certified EHRs requirements
eHIE Portal
  • With provider participation more data than single provider portal
  • Integration with public health, Medicaid, other public entities
  • Bedside access
  • Uni-directional
  • Typically requires HIE subscription/fees
  • Many providers are not publishing data to public HIEs
  • May not have as much clinical information as provider portal
  • Privacy and security managed by both HIE and LTPAC
  • No electronic data re-use
  • Print and scan record
  • Does not meet MU of certified EHR requirements
  • Beginning to be supported by LTPAC EHRs
  • Non-EHR access alternatives
  • Low cost
  • Established standards
  • Supports CCD exchange
  • Bidirectional exchange and information re-use
  • Supports innovative solutions including API or FHIR Transform, SEE
  • DSM is required to be included in 2014 CEHRT
  • May not be as efficient as established fax workflows
  • Point-to-point communication (data not available to the broader health care community)
  • Generally, LTPAC EHRs do not support consumption (electronic re-use) of documents represented using the C-CDA r2 standard (including CCD)
  • ONC standards for transport conversion
  • Implementation by certified EHR vendors is inconsistent (e.g., some can only receive (but not create) C-CDA documents)
  • HISP to HISP interface issues
  • PDF-based solutions (e.g., document scanning)
  • HIPAA constraints on mailboxes
  • Privacy and security management
  • Workflow integration
  • Absence of provider director/address challenges
  • Absence of read receipt
  • View-only alternatives (i.e., HIE and provider portals) cheaper and easier
Query-Based Exchange
  • Public and private HIEs
  • Comprehensive record (if data shared across providers)
  • Bidirectional exchange and information re-use
  • Contributed health information is available (when authorized) to the entire community of providers
  • Expensive
  • Not supported by LTPAC EHRs
  • Interface costs for continued upgrades/functionality
  • Interface technology complexity
  • Semantic interoperability challenges
  • Providers not publishing data on HIEs
  • HIE sustainability
  • Low Cost
  • Uses MDS/OASIS
  • Standards-based
  • Creates consumable CCD
  • Supports bidirectional exchange
  • Limited market penetration
  • Specific use case, limited data
  • Being used as print and scan solution
  • Data only from single provider system
  • No clear migration path to query exchange
  • Must be updated as document standard and assessment content evolves
  • Both an EHR and DSM mailbox solution
  • Low cost
  • Standards-based
  • Creates consumable CCD
  • Supports bidirectional exchange
  • Has had technical set-backs
  • Only tested in one trial location
  • Limited EHR integration
  • No clear migration path to query exchange
  • Commercialization prospects and broader availability is unclear
  • Draft HL-7 standard available for trial-use, complementary to existing standards
  • Resource definitions support interoperability and ease of deployment (compared to C-CDA)
  • Ability to work with finite data set
  • Not limited to clinical "use" cases (e.g., include administrative data)
  • Low cost
  • Uses well-established web standards
  • Supports widely used (RESTful) architectures
  • Adaptable to local needs
  • Can be used in multiple contexts (mobile, peer-to-peer, EHR, cloud, etc.)
  • In trials, technically unproven
  • Modular solutions do not support exchange of full range documents (incomplete record)
  • Use cases need to be expanded and proven
  • Risk of solution fragmentation (one-offs)
*Discussed in "Innovative Solutions" section.

The alternative exchange solutions available to LTPAC providers have been shaped by the characteristics of competition between health care systems, technology functionality, costs, and workflow. In many regions Epic Systems Corp. is the dominant EHR vendor and providers look to the EpicCare Everywhere solution as the exchange transport solution as opposed to a public HIE. In addition, owing to competitive factors, many providers do not publish their data to public HIEs but rely instead upon their internal or private HIEs for exchange.

Aside from private vendor and HIE network considerations, there is evidence that portals are the preferred method of exchange. In Central Pennsylvania, even with a relatively mature HIE organization and high participation rates (94%) of hospitals in the region, 82% of the 122,000 patient records accessed during April 2015, was through the portal. Also, DSM does not appear to be a popular solution. While KeyHIE does not support DSM, Geisinger offers the service and indicated that for the month of March 2015; only 54 direct messages were sent to LTPAC providers. The apparent explanation is that the portal solution that Geisinger offers, EpicCare Link, contains the same information and is easier to use than DSM.

Based upon the site visits, the experience in Minnesota parallels that of Pennsylvania. The principal means of data access is through provider portals. There is very limited exchange through public eHIEs, and the current focus is to develop community exchange solutions primarily using DSM At this time, there are no technological alternatives available within the state except private HIEs and portal solutions, and planners anticipate being proactive in addressing the constraints of DSM. The the leading LTPAC EHR vendors, have either recently included or are in the process of introducing DSM within their EHR products.

For bidirectional exchange, national LTPAC chains are supporting DSM. They cite the number of markets they are in and the cost of developing individual interfaces with each HIE as being prohibitive. They are relying upon national LTPAC vendors and their Healthcare Information Services Providers (HISPs) to support DSM with the acute care EHR vendors and their respective HISPs.

In sum, there is little evidence of bidirectional information exchange and re-use among LTPAC providers. While the industry sites a high penetration of EHRs, their functionality is often limited to administrative data capture and reporting for regulatory compliance purposes and they are not certified as part of the MU of certified EHRs. View-only portals (principally from providers) are the dominant means of exchange and scanned PDF files are the principal means of data input. In the near term, our stakeholder interview and site visit results suggest that DSM is the technology that LTPAC providers plan to use for bidirectional exchange. In order to support future use of DSM for exchange, workflow issues (described below) created by the need to log out of one's email server and into Direct to receive messages will need to be addressed.

Innovative Solutions

There are alternative solutions and pathways that support LTPAC HIE. For example the KeyHIE Transform tool is based upon using the CMS MDS and OASIS data sets and converting them into a standards-based consumable CCD format which can be exchanged via DSM. Developed under federal grants, Transform has been commercialized and implemented by 27 companies encompassing 41 care locations as of September 30, 2015. There will be more than 100 care locations using Transform based upon planned funding from ONC Advanced Interoperability awards.59

A similar tool, Local Adopter for Network Distribution (LAND)/SEE is under development by researchers in Massachusetts. LAND/SEE refers to the system architecture designed to support the IMPACT (Improving Massachusetts Post-Acute Care Transfer) initiative which is part of an ONC funded grant to improve care transitions. There are two solutions, LAND, which is designed for providers with an EHR, and Surrogate EHR Environment (SEE), which is designed for providers who do not have and EHR and are using DSM. The data sets supported are standards-based. LAND works by creating a text document that can be consumed by an EHR. The SEE solution is based upon software linked to a Direct mailbox which creates a CCD from received documents that can be viewed and copied. The copied document can have content added but not edited. This more complete record can then be converted back into a CCD and transmitted via DSM. The LAND/SEE project has been targeted to be implemented at a pilot site in Worchester.

The development of both private and public application protocol interface solutions, application program interface (API) solutions and standardized data formats such as Fast Healthcare Interoperability Resources (FHIR) have the potential to bring simplified and lower cost solutions to data exchange. FHIR is currently a Health Level Seven (HL-7) draft standard available for trial-use. FHIR is a health care information exchange standard that makes use of an HL7-defined set of "resources" to support information sharing by a variety of means, including documents, messages, applications and RESTful interfaces.60 Initiatives such as SMART on FHIR and DSM on FHIR have the promise of supporting the exchange of well-defined modular pieces of information as opposed to the complexity and technical challenges associated with the exchange of a full C-CDA document. This could resolve, at effective price points, some of the technical barriers to interoperability while providing the necessary information to support transitions in care.

View full report


"LTPACsetting.pdf" (pdf, 1.22Mb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®