360X Closed Loop Referral
Project Meeting
Thursday, December 6, 2012
11AM-12PM
Meeting Minutes

Paul reviews logistics for future full membership meeting.
o Due to events and holidays, we’ll hold the next full membership meeting on January 10,
2013 at 11AM.

Paul briefly reviews the mission of the 360X Closed Loop Referral project:
o It is not to demonstrate that it is technically possible, but rather to ensure that it is
clinically relevant and useful.
o It is also to ensure that it is rapidly and widely deployable.
o In addition, 360X is not a standards-making body but rather a workgroup for implanting
existing standards in combination to advance “real-world” interoperability.

As a result of recent conversations, we have found that everyone is at a slightly different place
and nobody is fully ready to support MU standards at this time.

During recent workgroups, we have worked to determine the best path forward:
o Our pilots will start with what folks can do now.
 Communities are at different stages of forming pilot teams and what pieces they
will include.
 Come January, we will have more specific pilot communities to discuss and the
ability to provide details.
 To address participant question on pilots: overall guidance and objective is
provide this regardless of number of HISPs involved.
 Ideally, there should be a capacity to have interoperability between HISPs and
EHR vendors.
o Our 360X v1.0 Implementation Guide will point to our desired future and is ongoing work.
 Both activities will inform and be informed by the other.

Next, Paul presents on Supporting Meaningful Use Stage 2 Transition of Care Requirements.
o There is a direct relationship between what is known as certified EHR technology and
Meaningful Use; rules are released in parallel.
o Meaningful Use rule points to how this technology is to be utilized.
o MU2 focuses on actual use cases of electronic information exchange.
 Paul focuses on Measure#2 which requires that a provider electronically transmit
a summary of care for more than 10% of transitions of care and referrals.
o For the purposes of 360X, let’s focus on the CEHRT Criterion 170.314(b)(2) – Transition
of Care send criteria.
o In order for a certification criterion to be met, all specific capabilities expressed as part of
it need to be demonstrated.
o For example, in 45 CFR 170.314(b)(2) there are two:
1. Create CCDA with requisite data specified for MU.
2. Enable a user to electronically transmit CCDA in accordance with:
a. Direct (required).
b. Direct +XDR/XDM (optional, not alternative).
c. SOAP + XDR/XDM (optional, not alternative).
o Thus, whatever EHR technology is presented for certification must demonstrate
compliance with both 1 and 2 under (b) (2) to meet the certification criterion (above).
o
o
o
o
o
o
o
o
o
o
o
This also means that there’s no certification for “transport only” as part of MUS2 / CEHRT
2014 Edition.
Next, Paul presents 3 valid certification scenarios for EHR technology for sending with
Direct:
1.
EHR generates C-CDA, and also performs as STA and sends Direct
message. All is handled by the EHR with no relied upon software.
 As an HIE, you can chose to become certified EHR technology as
well.
2.
EHR sends data to HISP, and then HISP generates C-CDA. HISP also
performs as STA and sends Direct message.
3.
EHR generates C-CDA and sends C-CDA to HISP. HISP performs as STA
and sends Direct message.
 EHR and HISP are not certified separately, they are certified
together.
Paul next returns back to Measure #2 for MU Transition of Care.
This is defined as: the eligible provider, eligible hospital 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 10 percent of such transitions and referrals either:
 Electronically transmitted using CEHRT to a recipient
 Where the recipient receives the summary of care record via exchange facilitated
by an organization that is an NwHIN Exchange participant or in a manner that is
consistent with the governance mechanism ONC establishes for the nationwide
health information network.
Next, Paul reviews approach #2 -- Send with CEHRT Optional Transport: SOAP + XD via
Intermediary.
 Because Provider A is sending to Provider B using their CEHRT’s SOAP +
XDR/XDM transport option, the fact there’s a “HISP in the middle” is irrelevant
with respect to Provider A meeting MU requirements.
 This allows any EHR vendor supporting the SOAP + XDR/XDM option to
interoperate with any HISP that also offers SOAP + XDR/XDM support.
 Under this approach, HISPs do not have to be certified
 If EHRs implement SOAP/XD support and then partner with a HISP (i.e., use the
HISP as relied upon software for certification), they can also fulfill their Direct
requirement under Scenario #3 with minimal (or no) additional
development/technical work on their part.
 If you chose this path, you can use it to partner up with a HISP that has this
capacity and use common edge as a way to fulfill requirement specified for
Direct.
Mallika Edwards poses a question on this slide and the green box: provider A could
actually be certified if they did this, or do they need step #4 to achieve certification
through Direct?
Paul explains that if provider A, or their EHR technology, would still need to do step #4 in
order to be certified through Direct. Could also follow any of the other testing scenarios
that were previously outlined.
Could, for example, have a native STA that also supports SOAP and would not have to
do step #4. Would imagine that some vendors that support SOAP + XDR/XDM would
chose to use this as an edge and then pick and HISP to certify with under scenario #3 for
meeting Direct requirement.
Answer is yes, in order to meet the definition for ToC you must demonstrate a Direct
capacity, but could use SOAP + XDR/XDM in combination with a HISP to achieve it.
What is the green box? This shows the boundaries of what the certified EHR technology
the provider is using. This could either have a complete EHR that includes ToC or using a
module that is adjusted for ToC – could be either.
Next, there is a question on Approach 2: SOP would be XDR only with the minimal data
set required for Direct, why is it SOAP + XDR/XDM?
o
o
This is the way that it is specified in the rule; you do not necessarily have to do both of
these.
Next Paul reviews approach #3 (last slide).
 If using certified EHR technology, don’t have to send the messaging using Direct.
Could also send through an exchange participant and this would meet MU2
requirements.
 To note, the edge for this is SOP XD edge. To meet requirements, the trading
partners would have to be on exchange as well.

Paul explains that this presentation will be distributed and posted to the wiki, and opens the floor
for questions.

Omar poses a question about “incorporate” on the receive end and what this term specifically
refers to:
o Paul explains that it would be actually storing data within certified EHR technology. There
are both requirements associated with this, as well as test procedures for meeting this
certification criterion.
o Would have to demonstrate that this is being stored within the technology.
o Omar explains that there is no way one would want to incorporate all the data received in
its own EHR, i.e. receive all kinds of extra information. Therefore, you provide the
functionality to “copy and paste” the data, but based upon clinical selection of what they
want to incorporate.
o Again, it comes back to the certified EHR technology and the certification process. There
are capacities that have to be demonstrated, and for MU there are requirements for how
this needs to be utilized.
o The requirements around MU are primarily send-based. There is discretion on behalf of
providers with how they are utilizing EHR technology to meet MU.
o To answer the question, there is not a requirement that a clinician includes this.
Laura McCrary poses a question on approach #3. In Kansas HIE, the C-CDA is sent to a data
repository and held there until someone queries for the patient via discovery. How does this meet
the requirement unless there is an alert sent to provider B that there is a CCD in the repository
that is related to a referral?
o Paul explains that it would be best to do additional research to clarify, specifically if there
is an HIE in the “middle.” The ruling from CMS does allow for pull-based transactions to
count.
o Paul will take this as a takeaway, and will provide Laura with an answer as to how this
works if the information is actually being stored and where the “pull” originates from.
o Paul is doing a session on this at the Annual Meeting and can provide Michelle McGuire
(project manager) with a response during the week, as well as offline with Laura.


Paul reiterates for those folks that do not participate in the individual workgroup meetings that this
will be the last full membership meeting until January 10, 2013.