Page History

...

The ONC 2014 Edition, 45 CFR 170.314(b)(2), requires CEHRT to demonstrate the ability to create a C-CDA with the Common MU data set and enable a user to electronically transmit in accordance with Direct. The details of the requisite data can be found in the Companion Guide produced by the S&I framework. The 2014R2 Edition and the 2015 Edition supporting MU Stage 3 maintain the premise of Stage 2 in that they do require electronic transmission of the C-CDA. These editions also extend the 2014 Edition to update the Common MU Data Set to a Common Clinical Data Set (CCDS), introduce Edge Protocols that can be used instead of or in addition to Direct, and update the HL7 standard for the C-CDA to v2.1.

360X seeks to support these MU requirements and to introduce the ability for EHRT to manage the referral request process itself with the introduction of the electronic communication of the HL7 v2.x order payload. 360X also seeks to support both MU stages and ONC Certification Editions and, therefore will remain agnostic regarding C-CDA HL7 IG versions and compliance with the ONC-specified data sets. Therefore, a system will be compliant with 360X by complying with the requirements of this Implementation Guide, however that may introduce the need to augment or constrain C-CDA content that is otherwise compliant with above-mentioned aforementioned CMS/ONC requirements.

2.2 In Scope

...

• Application functionality within the EHRT for managing and displaying the processes related to referrals. Note that a referral request may proceed through multiple steps to achieve an initiation readiness state such as confirmation of eligibility, patient coordination for desired locations/providers, etc. These preparation steps are very important but not within the scope of this guidance which starts with an initiation ready request.
• Functionality designed explicitly to support clinicians not using EHRT (though valuable, the focus of this project is on EHR-to-EHR interoperability)
• Processes and transactions related to the administrative and financial aspects of referrals such as eligibility and claims handling.
• Occurrence handling. This guide assumes one request and , one Accept and Complete or Decline. Any recurrent pattern of patient encounters the referral initiator may need is not managed by the scope of this document and is within the referral initators' discretion.
• Defining or modifying existing clinical medicine practices
• Provider - Patient communication use cases
• Continuity of care use cases outside of the single referral request handling between two providers. For example, "courtesy copy" or "referral forward" use cases to communicate among a broader set of providers.
• Privacy and Security policies and processes such as consent handling.
• Person (provider, patient) identity matching capabilities
• Relevant but tangential processes covered elsewhere such as HPD+ (or other) enabler of provider directories used for efficient addressing and routing.
• Referrals/consults within a single EHRT such as consult orders from and attending to a specialist or between two providers using the same EHRT instance.
• How the C-CDA content is rendered to a user. Based on the various certification requirements, it is expected that the EHRT receiving a C-CDA document is able to present it in its entirety to the appropriate users. Additional rendering help (e.g. XSLT stylesheets) may or may not be provided by the sender, therefore the receiver may not rely on the presence of such. If the sender provides rendering help, the receiver is not required to use it, and if they chose to use it, proper precautions must be made to alleviate any security risks presented by applying executable code of foreign origin. The C-CDA specification provides a stylesheet, and there are projects under way to provide other freely available stylesheets to help with rendering the content.
• Use Cases concerning intermediary communications ("chatter"), "forking" the conversation through other means, such as forwarding or carbon copying or any other internal processes that are desired to add additional observers. This includes interim status updates that do not have any accompanying patient clinical formation (unless specifically defined in this Implementation Guide).