Transcription

1 Practical Guidance to Implement Meaningful Use Stage 2 Secure Health Transport for Certification and Meaningful Use 1. Introduction Electronic Health Record Association Standards and Interoperability Workgroup Meaningful use (MU) Stage 2 introduces three transport standards for use in healthcare information transport. The purpose of this paper is to: Summarize the transport standards and their purposes; Provide practical guidance to apply one or more of these standards in a MU Stage 2 implementation from a software developer perspective seeking to meet certification; Highlight the flexibility allowed by MU Stage 2 in the ways providers may qualify in deploying health information exchange (HIE) with a certified. 2. Summary of Certification Requirements Section of the final rules for Stage 2 certification identifies three transport standards adopted for healthcare messaging. They are: 1. ONC Applicability Statement for Secure Health Transport (incorporated by reference in ) This specification discusses the Direct protocol for provider-to- provider messaging. The core component in the technology stack is standard, secure (SMTP/SMIME). This specification does not support the exchange of metadata associated with the exchanged documents. It is important to note that it recommends (i.e., does not mandate) its use and provides a minimal metadata specification. 2. ONC XDR and XDM for Direct Messaging Specification (incorporated by reference in ) This specification discusses the application of XDR and XDM to the direct messaging environment and the interaction between the primary Direct Project environment, which uses SMTP and RFC 5322 to transport and encode healthcare content, and the XDR (Web Services push) and XDM ( with metadata) specifications. XDM and XDR support the exchange of metadata in addition to the exchanged document. Both standards use the same metadata definition. 3. Standard. ONC Transport and Security Specification (incorporated by reference in ) 1 Celebrating Ten Years of Advocacy, Education, and Outreach January 28, 2014

2 This document defines the primary set of Web services-based (SOAP) security and transport protocols needed to establish a messaging, security, and privacy foundation for health information exchange. This standard is not at a level where healthcare metadata is being exchanged as it is used as a transport under XDR. The above three standards are related and may be combined in three ways, as defined in 45CFR (b) (1) (i) A, B, C and (b) (2) (ii) A, B, C. These three combinations are labeled: (a), (a + b), and (b + c). The following diagrams describe the main steps to produce, transmit, and receive a document for each of these combinations. 2.1 Send Supporting Direct-only SMTP (a) Document Locate Destination and Associated Certificate Sign and Encrypt S-MIME attachment Type of receiving system may be : service HIE or HISP or other Send (SMTP) SMTP o The conveyance of metadata is not required, but may be supported optionally with the use of the (a+b) combination below. 2 Celebrating Ten Years of Advocacy, Education, and Outreach January 28, 2014

3 Supporting Direct with XDM (a+b) CCDA Document(s) XDM wrapper (ZIP with metadata and 1-n docs) Locate Destination and Associated Certificate Sign and Encrypt S-MIME attachment Type of receiver may be: : service HIEor orhisp HISP or orother other Send (SMTP) SMTP o The XDM Wrapper combines metadata along with one or more documents. Supporting SOAP with XDR (b+c) Document(s) XDR Encoding (Metadata and 1-n Documents) SOAP (http + web services+saml) Type of receiver may be: HIE or HISP or other Node Certificate + TLS encryption SOAP Web Services on TLS o XDR relies on SOAP (Web services) and not as transport. However, it offers the same ability to wrap the document(s) with associated metadata and place it in the SOAP message. 3 Celebrating Ten Years of Advocacy, Education, and Outreach January 28, 2014

4 2.2 Receive Supporting Direct-only SMTP (a) Document Type of sending system may be: service HIE or HISP or other Validate signature and sender identity Decrypt S-MIME attachment Receive (SMTP or POP or IMAP) Supporting Direct with XDM (a+b) Document Type of sending system may be: service HIE or HISP or other XDM wrapper (ZIP with metadata and 1-n docs) Validate signature and sender identity Decrypt S-MIME attachment Receive (SMTP or POP or IMAP) 4 Celebrating Ten Years of Advocacy, Education, and Outreach January 28, 2014

5 Supporting SOAP with XDR (b+c) Document(s) Type of sender may be: HIE or HISP or other XDR Encoding (Metadata and 1-n Documents SOAP (http + web services+saml) SOAP Web Services on TLS Node Certificate + TLS encryption 3. Certification Requirements 3.1 Send 1. Required Certification: (a) Direct SMTP Only vendors have a variety of implementation strategies, as long as an S-MIME encrypted is received by the test tool. This can be realized for example by: 1. Bundling by the vendor of the capability to locate a destination direct address and association of the signing/encryption certificate (often incorrectly called HISP-like functionality) with the module supporting the criterion requiring transport. This capability may reside within the (see Case A in figure below), or be externally operated by the vendor (see Case B in figure below). 2. Partnering by the vendor with a third party operating as relied upon software for the capability to locate a destination direct address and association of the signing/encryption certificate. When this specific combination of the two is certified for (a), then the alone or in conjunction with a different third party HISP is not considered a certified solution (see Case B in figure below). 5 Celebrating Ten Years of Advocacy, Education, and Outreach January 28, 2014

6 Implementation Strategies for Direct (a) and (a+b) Case A: generates locates destination gets certificate and encrypts Certified Direct (SMTP+S-Mime) Direct (SMTP+S-Mime) Case B: generates HIE/HISP locates destination HIE/HISP gets certificate and encrypts Certified with relied upon software HIE or HISP Direct (SMTP+S-Mime) Note: There is no requirement for a sender to use delivery notification. Only receivers are required and tested to respond to delivery notifications requests. CMS stated that the sender must know that the transition of care document was received, but no technical requirements are specified. 2. Optional Certification: (a+b) Direct with XDM This certification is optional in addition to (a), not instead of (a), as (a) is minimally required. This certification is identical to (a) and only involves the addition of the ability to wrap the document(s) with associated metadata and place it in the S-MIME attachment. The same variants in implementation (Cases A and B in figure) may be used as described under (a). The benefits of this approach over the (a) result from the inclusion of metadata (for either non-cda and CDA documents, as well as multiple documents) for the receiver are: 1. better management/routing of the document; and 2. improved privacy and security management without having to open the document. Note: In order to enhance interoperability between (a) sources and (a+b) receivers, we suggest that any implementation of (a) may be designed to receive (a+b) by 6 Celebrating Ten Years of Advocacy, Education, and Outreach January 28, 2014

7 ignoring the XDM wrapper and the metadata, if not used. This provides compatibility between (a) and (a+b) considering that the certification of (a+b) without also being certified for (a) is not permissible. 3. Optional Certification: (b+c) XDR (with SOAP) This certification is optional in addition to (a), not instead of (a), as (a) is minimally required. In this scenario, XDR relies on SOAP (Web services) and not as transport. However, it offers the same ability to wrap the document(s) with associated metadata and place it in the SOAP message. Note that this is not an S-MIME attachment, but the SOAP attachment method supported by all SOAP stacks. The benefits of this approach over the (a) are: Gives independence from HIE/HISP/receivers (if they are capable of XDR receive) in that an need not be certified with the relied upon HIE/HISP chosen by the provider; Provides metadata for receivers (especially with non-cda documents and multiple documents) to improve their ability to manage/route the document(s); Provides compatibility with an IHE XDS Provide and Register transaction (share documents in an HIE). 3.2 Receive 1. Required Certification: (a) Direct SMTP Only vendors have a variety of implementation strategies, as long as an S-MIME encrypted is received. This can be realized for example by: Bundling by the vendor of the capability to receive an SMTP (as server or STA) and to decipher the S-MIME attachment (often incorrectly called a HISPlike functionality), enabling a POP or IMAP service to pull from a specific service mailbox and to check the signature and decipher the S-MIME attachment. These receive capabilities may be offered within the or operated independently by the vendor. Have the vendor partner with a third party operating as relied upon software the capability to receive an SMTP and decipher the S-MIME attachment. The specific combination of the two is certified for (a). The alone or in conjunction with a different third party HISP is not a certified solution. Note that when acquiring the alone, using it in conjunction with a different service than the one it has been certified with is not considered a certified solution. 7 Celebrating Ten Years of Advocacy, Education, and Outreach January 28, 2014

8 2. Optional Certification: (a+b) Direct with XDM This certification is optional in addition to (a), not instead of (a), as (a) is minimally required. This certification for receive is identical to (a) and only involves the addition of the ability to unwrap the document (one or more) and associated metadata and extract it in the S-MIME attachment. The same variants in implementation may be used as for (a). The benefits of this approach over the (a) result from the inclusion of metadata (for either non-cda and CDA documents, as well as multiple documents) are: The receiver can better manage/route the document without having to open it; Improved privacy and security management without having to open the document. Note: In order to enhance interoperability between (a) sources and (a+b) receivers, we suggest that any implementation of (a) may be designed to receive (a+b) by ignoring the XDM wrapper and the metadata, if not used. This provides compatibility between (a) and (a+b) considering that the certification of (a+b) without also being certified for (a) is not permissible. 3. Optional Certification: (b+c) XDR (with SOAP) This certification is optional in addition to (a), not instead of (a), as (a) is minimally required. XDR relies on Web services and not on as transport. However, it offers the same ability to extract from the SOAP message. This is not an S-MIME attachment but the attachment method of SOAP. The wrapped content that includes documents (one or more) and associated metadata to facilitate the routing of the documents without any need to parse their content. The benefits of this approach over (a) are: Gives independence from HIE/HISP/receivers (if they are capable of XDR receive) in that an need not be certified with the relied upon HIE/HISP chosen by the provider; Provides metadata for receivers (especially with non-cda documents and multiple documents); Provides compatibility with an IHE XDS Provide and Register transaction (share documents in an HIE). 4. Provider Requirements for Deploying an to Qualify for MU Stage 2 The Incentive Program for MU Stage 2 Final Rule describes in 495.6(j)(14) for eligible providers (EPs) and 495.6(l)(11) for eligible hospitals (including critical access hospitals EHs and CAHs) the measurements: 8 Celebrating Ten Years of Advocacy, Education, and Outreach January 28, 2014

9 (A) Subject to paragraph (c) [of/in] this section, the [EP/EH or CAH] that transitions or refers their patient to another setting of care or provider of care provides a summary of care record for more than 50 percent of transitions of care and referrals, (B) Subject to paragraph (c) in this section, the [EP/EH or CAH] that transitions their patient to another setting of care or provider of care provides a summary of care record for more than 10 percent of such transitions and referrals either: (1) Electronically transmitted using Certified Technology to a recipient; or (2) Where the recipient receives the summary of care record via exchange facilitated by an organization that is a NwHIN Exchange participant or in a manner that is consistent with the governance mechanism ONC establishes for the nationwide health information network; (C) Subject to paragraph (c) of this section an [EP/EH or CAH] must satisfy one of the following: (1) Conducts one or more successful electronic exchanges of a summary of care record meeting the measure specified in paragraph [(l)(11)(ii)(b)/(j)(14)(ii)(b)] of this section with a recipient using technology to receive the summary of care record that was designed by a different developer than the sender's technology certified at 45 CFR (b)(2); or (2) Conducts one or more successful tests with the CMS designated test during the reporting period. This allows for transport mechanisms described in this document, based on ONC's 2014 Edition Final Rule, to meet the target measurements, as well as those consistent with the NwHIN / ehealth Exchange (e.g., XCA/XDS queries, as referenced from their WIKI pages (http://exchange-specifications.wikispaces.com/home) and the Message Platform page in particular (http://exchange-specifications.wikispaces.com/messaging+platform+home)). Therefore, the provider must interface its with other providers with which it is performing transfers of care. Two cases are worth considering: 1. If the provider uses a service offered by the vendor (as relied upon software), no further analysis is needed. This relied upon software/service, along with the, must have been certified to (a), and optionally to (a+b) or (b+c). No other choices are acceptable. 2. If the provider wishes to use another HIE/HISP service than the one chosen by the vendor when it certified to (a) Direct, either: a. The provider needs to certify with the selected HIE/HISP on their own, or with assistance from the vendor; or b. The provider needs to connect its using (b+c) to the HIE/HISP (no need for self-certification), but this implies that the was certified to (b+c) and that the HIE/HISP supports (b+c) which is likely. No other choices are acceptable. 9 Celebrating Ten Years of Advocacy, Education, and Outreach January 28, 2014

10 Note that under scenario 2.b. above, the provider still must possess CT that is certified to (a) DIRECT, even though it is not used to achieve the threshold measurements for transitions of care. The software developer cannot completely carve out (a) Direct from its module offered as (a) Direct, and (b+c) XDR (with SOAP) are part of the same certification criterion. To accommodate that the provider in those situations does not have to fully implement and pay for HISP services they are not using, ONC clarified the concept of right of possession. This is further defined and clarified in ONC s FAQ #21. ONC in its communication has been recommending that s implement the optional (b+c) to provide more flexibility to providers. See ONC s December 19, 2012 presentation to NeHC at: irect%20requirements%20for%20meaningful%20use%20stage%202.pdf. For receipt, the requirements for the providers in the CMS regulations are quite flexible. Only the ability to consume s (as well as CCD and CCR for backward compatibility) is required. A provider is explicitly qualified to receive with other solutions than (a), (a+b) or (b+c) in its, such as using the ehealth (previously called NwHIN) Exchange which relies on a query for documents on SOAP (IHE XCA Query Retrieve which is the same as XDS Query Retrieve, plus SAML). Note that the sending provider is not measured on the recipient consuming the transmission, only that the transmission successfully arrived at its intended destination. Also note that the receiving provider does not have a transitions of care measure. 5. Value-Added workflows leveraging XDM/XDR metadata 1. Recommendations to HISP/HIEs Implementers a. When a HISP/HIE receives metadata from an connected via (a+b) Direct with XDM or via (b+c) SOAP with XDR, it should forward unchanged this metadata to other HITPS/HIE using (a+b) Direct with XDM. b. When a HISP/HIE receives metadata from another HISP/HIE using (a+b) Direct with XDM, it shall forward unchanged this metadata to either another HISP/HIE using (a+b) Direct with XDM or to an if connected via either (a+b) Direct with XDM or via (b+c) SOAP with XDR. c. Only when neither the next HISP nor the receiving, should a HISP/HIE revert to using (a) Direct only and discard the received metadata. 2. Recommendations to s Implementing the (a+b) XDM or (b+c) XDR MU2 Options a. When an has been certified with one or both of the transport options: (a+b) Direct with XDM or via (b+c) SOAP with XDR, it should populate the metadata with the data values identified below. This will enable any supporting the MU2 optional transports to receive a transition of care patient summary in the context to enhance its user experience and workflows. 10 Celebrating Ten Years of Advocacy, Education, and Outreach January 28, 2014

14 6.3 Vendor Provided Communication Infrastructure in an MU Stage 2 Context Document (s) Vendor Specific Vendor Specific Vendor Specific XDM wrapper (ZIP with metadata and 1-n docs) Locate Destination and Associated Certificate Sign and Encrypt S-MIME attachment Send (SMTP) vendor provided communication infrastructure SMTP SMTP with XDM Type of receiver may be: service HIE or HISP or other and supporting communication infrastructure certified together for (a) and (a+b) Provider qualifies for using either (a+b) or (a) 7. Addressing Considerations for Direct Transport One of challenges with the deployment of the Direct transport paradigm is the ability to address the message to the correct party. Building up my contact list of reliable and valid addresses will be a learning experience for everybody involved. As we have seen with , the use of personal/local directories will be common place, but we do expect that HIEs and other national/regional entities will (begin to) provide directory services for look-up of their provider s relevant contact address(es). Based on practical use cases, we must recognize that messages will not only be sent from one person to another person, but from a person to an organization, organization to person, or organization to organization. The following use cases may illustrate this further. A primary care physician (PCP) wants to refer a patient, on a non-urgent basis, to a specific specialist. The PCP will select that specialist from the Directory and send the referral message directly to that specialist. 14 Celebrating Ten Years of Advocacy, Education, and Outreach January 28, 2014

15 The same PCP wants to refer another patient on a semi-urgent basis (i.e., to be seen within the next few days) to an X type specialist. The PCP is unsure which specialist will have availability during the desired timeframe and therefore selects the desired X type specialty organization for the patient to be seen by the first available specialist within the practice and sends the Direct message to that specialty organization. When a patient is admitted to a hospital for a planned elective procedure, a similar clinical summary could be sent to the hospital (e.g., the admission office) to be put into the hospital's, and be made available to the patient's treating clinicians. Upon discharge to home, the message would be sent via Direct to the patient's PCP. However, if the patient was discharged to a skilled nursing facility or to a rehabilitation facility, the message could be sent via Direct to that organization. Staffing and workflows of the provider organization/practice/hospital will determine who sends and who will receive and appropriately distribute Direct messages within the recipient. For further information and considerations, including HDPPlus, see the Statewide Send and Receive Patient Record Exchange and its Technical Specification Appendix, HDPPlus RDB Implementation Guide, issued by the /HIE Interoperability Workgroup. These can be obtained using their documentation web page. 15 Celebrating Ten Years of Advocacy, Education, and Outreach January 28, 2014

17 Folder patientid R R2 R2 Folder uniqueid R R R R= Required to be sent O=Optional to be sent R2= Required to be sent if known 17 Celebrating Ten Years of Advocacy, Education, and Outreach January 28, 2014

TABLE OF CONTENTS INTRODUCTION USE CASES FOR CONVERSION BETWEEN DIRECT AND XDR Conversion from Direct SMTP+S/MIME Messages to XDR Conversion from XDR to SMTP+S/MIME Data Transmission between two EHRS that

Navigating the Trends in Health Care Today MEDITECH Solutions for Meaningful Use and Interoperability Certification Update EHRs Meeting ONC 2014 Standards "There is no such thing as being 'Stage 1 Certified'

s Preparing for Meaningful Use in 2014 MEDITECH (Updated December 2013) Professionals please see the document: MEDITECH Prepares You for Stage 2 of Meaningful Use: Professionals. Congratulations to our

Architectures and Transport Mechanisms for Health Information Interchange of Clinical EHR Data for Syndromic Surveillance A Report from the International Society for Disease Surveillance Prepared by Noam

Expanded Support for Medicaid Health Information Exchanges Thomas Novak Medicaid Interoperability Lead Office of Policy Office of the National Coordinator for Health IT Medicaid Data & Systems Group Centers

Santa Cruz HIE Proposal for Demonstrating at California Connects 2014 Use this template to communicate critical information for each demonstration proposed for the 2014 California Connects Interoperability

Introduction MaxMD is pleased to provide the Pennsylvania ehealth Partnership Authority (Authority) the Business and Technical Requirements report under the Lab Grant pilot project. We have demonstrated

Interoperability will bind together a wide network of real-time life critical data that not only transform but become healthcare. Health Information Interoperability Challenges Healthcare and healthcare

Data Provenance Functional Requirements Document: Developed in Response to the Data Provenance Task Force Recommendations Version 1.0 May 2015 Version History Version Revision Author Description of Change

Interoperability will bind together a wide network of real-time life critical data that not only transform but become healthcare. Health Information Interoperability Challenges and Integrating Healthcare

Direct Secure Messaging: Improving the Secure and Interoperable Exchange of Health Information Within the healthcare industry, the exchange of protected health information (PHI) is governed by regulations

Services Available at No Cost Health Information Exchange Services & Pricing Package Services Available at No Cost Services Available at No Cost HealthlinkNY Web Portal The HealthlinkNY Web Portal is available

Frequently Asked Questions About PreManage The Oregon Health Leadership Council has formed a unique coalition of major stakeholders, including hospitals, health plans, Emergency Department (ED) physicians

ConCert by HIMSS Certification: An Overview This paper provides an introduction to the ConCert by HIMSS certification program. An overview of the 2015 Certification Pilot program is also provided along

Health Information Exchange (HIE) in Minnesota Where have we been and where are we going Jennifer Fritz, MPH Anne Schloegel, MPH Minnesota Department of Health 1 Session Goals Learn about Minnesota s approach

Pennsylvania s Department of Public Welfare s Office of Medical Assistance Programs (OMAP) developed the ehealth Pod Pilot Program to stimulate the use of health information technology by behavioral health

Federal and State Update John D. Halamka MD NPRM Review The use of SNOMED-CT instead of ICD-10 for diagnosis. If the intent is to gather clinical data, SNOMED-CT is best. If billing classification is needed

Basic Patient Privacy Consents (BPPC) provides a mechanism to record the patient privacy consent(s), a method to mark documents published to XDS with the patient privacy consent that was used to authorize

Demonstrating Meaningful Use of EHRs: The top 10 compliance challenges for Stage 1 and what s new with 2 Today s discussion A three-stage approach to achieving Meaningful Use Top 10 compliance challenges

PHS-Connect Users Group Forum November 7, 2013 Agenda Introductions and Opening Remarks PHS-Connect Update Direction of PHS-Connect What can PHS-Connect Do for Me and My EMR Secure Messaging for MU2 and

Meaningful Use Updates Stage 2 and 3 Julia Moore, Business Analyst SMC Partners, LLC July 8, 2015 Stage 2 Requirements 2015 EPs beyond 1st year of MU must report on a full year of data EPs in 1 st year

Building Regional and National Health Information Systems Mike LaRocca Agenda What are the key use cases driving New York? What is the SHIN-NY NY and its architecture? What standards and protocols were

Who are we? Purdue Healthcare Advisors (PHA)*, a business unit of Purdue University, specializes in affordable assistance to organizations that share our passion for healthcare transformation. We bring