Meeting
Full Affinity Group Meeting
Purpose
Full AG Meeting
Date &
Time
Location
Friday, August 9th, 2013, 1:00PM 2:00 PM
Webex
BAH Team Members
Lynda Rowe (BAH) Rowe
Greg Dengler
Eunice Choi
Attendees
Beacon Community Members
Bruce Wiegand - Southeast Michigan
Nancy Maloney – WNY
Chuck Tryon – Tulsa - Co-Chair
Sri – Keystone
Vendors
Ed Donaldson – Success EHS
Alan Uhl - Vitera
Adele Allison – SuccessEHS
Tone Southerland – Greenway
ONC
Erica Galvez
1 Agenda







Full AG Roll call – Lynda Rowe (BAH) Rowe
SE Michigan MU 2 Transport Pilot Discussion – Bruce Wiegand (SE Michigan)Wiegand
Keystone MU 2 Transport Pilot Discussion – Sri (Keystone) Bharadwaj
Follow Up Questions from Tulsa and RIQI MU 2 Pilot Discussions – Chuck Tryon (Tulsa) Tryon
ONC White Paper Discussion “Key Considerations For Health Information Organizations
Supporting Meaningful Use Stage 2 Patient Electronic Access Measures” – Lynda Rowe (BAH)
Rowe
eHealth Exchange Questions Update –Adele Allison (Success EHS) Allison/Lynda Rowe (BAH)
Rowe
Wrap up/Next Steps – Adele Allison (Success EHS) Allison/Chuck Tryon (Tulsa) Tryon
2 Notes


Adele Allison (Success EHS) – I think where we want to start is with Sri (Keystone) and Bruce
Wiegand (SE Michigan) speaking about their pilots
Bruce Wiegand (SE Michigan) – This slide represents the work that we did with the user stories.
Our pilot represents the query user story. With our model we are looking at the eHealth
exchange. With our transfer pilots, we completed our c83 pilots, we are getting CDA types of
data automatically pushed with triggers into our NPI XDS repository, we are also circling back
with the vendor to work on a PICS and an XDS query model. This diagram represents our
community as a whole, it shows our community portal and various capabilities, as well as where
-1-
patients and providers can enter information. We decided we needed to centralize our data
because of our underserved segmented population.
o Bruce Wiegand (SE Michigan)– There are not enough major primary care providers in
Detroit, our best option is a central data repository which leverages technology to bring
the data to the patient in real time. Patients go from PCP to PCP, ED to ED, PCP to ED,
etc, our approach is looking at all transitions and all data throughout the community.
We onboard practices and expect them to push information to us. AS an example, when
a patient shows up in another care setting, the ED can query the longitudinal record and
see who their last PCP was, then inform the provider of the ED visit and schedule an
appointment. So when the patient checks in, it automatically updates their longitudinal
CDA within the system
o Bruce Wiegand (SE Michigan)– We have a lot of stakeholders behind us in this model
o Bruce Wiegand (SE Michigan) – Right now we are working with SuccessEHS and
Allscripts as well as several other vendors. Currently EMRs are using either XDS.b or
Direct to get the record to us. The most important thing we are doing is leveraging the
automatic triggers and workflows to get us the information when the CCD is generated,
we can then integrate it with our community registry.
o Lynda Rowe (BAH) – Bruce Wiegand (SE Michigan) can we walk through your technical
implementation spreadsheet, you are doing pilot 9, which presumes you will be an
eHealth exchange participant.
 Bruce Wiegand (SE Michigan) – The pilot description focuses on ED discharges
for ToC, leveraging our navigators and exchange to move these patients into a
medical home. If the patient is in the ER, the ED provider will pull a longitudinal
CDA of the patient, understand who their last known PCP was, then follow up
on discharge as well as work with the PCP on follow up care. The PCP can be
directed to either query or pull the summary, or wait until the patient shows up
at the PCP, because then the system will automatically generate the patient’s
CDA
 On the tech side we are using XDS.b. We are trying to use the same
transport between systems to reduce cost. We are doing some MDM
CCDs until the vendor can support XDS. We are also using XDI. Specific
data is filtered into the registry so that it can generate care
considerations. When the longitudinal CDA is generated it will pull
every available data source
 Bruce Wiegand (SE Michigan) – the Chronic care coordinators would be
able to use to the portal to see when patient’s last had care, medication
issues, etc to help with their care
 Bruce Wiegand (SE Michigan) – We are pondering SOAP+ XDR/XDS, our goal is
to improve patient care by being more inclusive. We are also trying to make
patient’s data move when the patients show up or leave a care facility
 Bruce Wiegand (SE Michigan)– The sending provider generates a CDA
based on the encounter
-2-

Lynda Rowe (BAH) – We are doing numerator/denominator now, so your
denominator would be any patient for which a CCD is sent into the exchange.
Do you have a way of calculating, maybe not now, but in the future, what the
denominator is for ToC?
 Bruce Wiegand (SE Michigan) – We are working with the HIE vendors on
this issue no. We are hoping to use XDS.b for 100% of all CDAs. When a
referral consult or order is generated in the XDS, we are looking to
populate the XDM segment in the referral specific CDAs, the ones that
need to be identified and transported to specialist. If the vendors
populate specific CDAs, then we would work with them to leverage the
notice of document availability capability. Only those transactions with
ToC would get an alert that new information is available
 Lynda Rowe (BAH) – So on the outbound, you flag whether the ToC is to
a specialist or hospital, then those CDAs will stripped and using NDA,
and you will send a notification stating it counts in the numerator?
 Adele Allison (Success EHS) –So will the flag require something from the
end user, or will this be automatically created based on a trigger?
o Bruce Wiegand (SE Michigan)- We need to work with the EMR
vendor on this issue. The EMR vendor will need to maintain a
list of Direct addresses because there will be other HISPS/HIEs
they will also be using. Covisint would generate a NAV alert, we
will maintain provider patient relationships at the HIE level. As
soon as that alert pops into the exchange, then the provider
may need to go to the exchange to query that summary. When
a patient shows up to a site of care, the portal will have the
most recent information because information has been added
to the registry real time, some referrals may be out of date by
the time the patient actually shows up for care because of the
time in between referral generation and care being received
o Chuck Tryon (Tulsa) – Back to the question Lynda Rowe (BAH)
asked, the calculation of the denominator will be on the EMR
side?
o Bruce Wiegand (SE Michigan) – Yes, exactly. If the EMR has
1000 CDAs for all transfers regardless of type, and 100 referral
orders, they can tell the referrals because they inserted 100 of
them into the XDN segment of the CDA. It is now a matter of us
making the relied upon delivery, whether it is pushing a CCDA or
having the information queried by provider B
o Chuck Tryon (Tulsa) – I want to back up a little, 100 CDAs
contain referral orders, so that should be 100 that will be in the
denominator captured by the EMR within the attestation
window. If I had 100 referrals that I sent out of my product, this
is what will be calculated as the denominator because using a
-3-
o
o
o
o
o
o
o
o
o
o
o
o
plausible delivery method; they will be considered delivered
unless a failure message is sent. Lynda Rowe (BAH) is that
right?
Lynda Rowe (BAH) – Yes
Chuck Tryon (Tulsa) – So, the numerator/denominator still lies
with the EMR
Bruce Wiegand (SE Michigan)– Yes, we are trying to simplify this
instead of using audit logs to track referrals
Chuck Tryon (Tulsa) – If all we are wanting to know is that
referrals were sent and not rejected, than the EMR is the place
where all these calculations will be taking place.
Bruce Wiegand (SE Michigan) – Yes,
Chuck Tryon (Tulsa) – Where does eHealth exchange come into
this picture?
Chuck Tryon (Tulsa) – I am still trying to find where the eHealth
exchange value is? I like the way SE Michigan is going with this.
I am more interested in the mechanics of how we notify
providers. If you have a patient care model it would help us to
know who we need to notify of the ToC
Bruce Wiegand (SE Michigan) – One last point, even though we
are focusing on numerator/denominator calculations, this
capability can be used for any type of transition of care. A
notice of availability would go to the provider, verses sending
the data, we give them a notification that they need to go to the
HIE to get the new information where it can be injected into
their EMR or viewed
Erica Galvez (ONC) – A couple of thoughts on the eHealth
exchange piece. If we rewind to what is acceptable for counting
ToC, there are two options a provider has to use to transport
the ToC in order for it to count in the numerator. MU 2 ties
content and transport. One, it needs to be sent out of a CEHRT
using either Direct/Direct +XDR or Soap+ XDR, the other option
is sending it however you want through the eHealth exchange.
The XDS.b or any other transport between the EHR and the
registry is acceptable as long as the sender is an eHealth
exchange participant. if the sender is not, than the provider
needs to use a CEHRT.
Bruce Wiegand (SE Michigan)– We will become and eHealth
participant, then we can use any edge protocol, it gives us more
flexibility
Chuck Tryon (Tulsa) – Thanks Erica Galvez (ONC)
Erica Galvez (ONC) – Have any of you tested how the flag would
work, to say this is a referral instead of something else?
-4-
o
o
o
o
o
o
o
o
o
Bruce Wiegand (SE Michigan) – Yes, I believe WNY is doing the
same thing. It depends on the HIE vendors capabilities. Even
using XDS.b you need to develop a use case for the vendors to
develop around. Once that is developed and tested, if it all
works then it will be repeatable for anyone else using these
same products
Lynda Rowe (BAH) – Bruce Wiegand (SE Michigan)are you
talking to Ed Donaldson (SuccessEHS) or Allscripts about actually
implementing this within the outbound messaging as well as
how they would capture it in their outbound product?
Bruce Wiegand (SE Michigan)– Just initial conversations, we are
still struggling with the numerator/denominator question. XDS
is a more complete set of metadata. The XDR for the MU 2
requirements is just around patient id. If we can leverage what
is already there, the vendor needs to be able to recognize it and
tag it. I have confirmation that they will be able to produce the
scope to do that, we just need to look at a pilot and workflow
options. Ed Donaldson (SuccessEHS) and I had a conversation
and it sounded feasible from his perspective, we need to know
if the HIE vendors can support it. Then we can look at how to
automate those orders and pop in the XDS statement of the
SOAP+XDR push
Adele Allison (Success EHS) – I like the vision, when will you
have an answer on the logistics?
Bruce Wiegand (SE Michigan)– I have the scope of work. We are
going to do Direct and be a destination for other HISPS. We will
have our own CDR mailbox. We don’t want to relay unless we
have to, this will help with our provider relay as well as the
ability to support nav
Lynda Rowe (BAH) – Instead of Covisint being able to do it, are
you able to do it via file export? I know it was the analytics team
that would send the log back to EHR vendor because they know
the numerator and the EHR vendor knows the denominator,
then it would have to be matched up.
Chuck Tryon (Tulsa) – The way that this becomes a legitimate
counting device is if you are an eHealth exchange participant;
otherwise you need a CEHRT transport. I like this idea of a
notice of availability flag.
Adele Allison (Success EHS) – I agree, this is a great concept, I
want to make sure the logistics are available
Bruce Wiegand (SE Michigan) – That is the quandary we have,
we spent months trying to figure out numerator/denominator
calculations. We are using CEHRT, CCDA HIE compliant XDs, and
-5-
o
o
o
o
o
o
o
o
o
o
o
o
o
o
longitudinal CDAs for everything regardless of the transition
type. We are trying to reverse engineer this process to identify
the 10% of electronic ToC we need for MU 2 attestation.
Chuck Tryon (Tulsa) – For our tech people, is this notice of
availability flag something that has been talked about before, or
is this a new concept?
Ed Donaldson (SuccessEHS) – I am not especially familiar with
the notice of availability, other than something coming back to
a provider saying the record is available to be queried.
Allan Uhl (Vitera) – Keith Boone did a piece on that, I can try to
find that particular piece. He had a conversation at HIMMS
about it, then referred somebody back to his blog, he would be
a good source on that topic.
Lynda Rowe (BAH) – Anyone else have questions for Bruce
Wiegand (SE Michigan), I think this is a great approach and I
think we need to push conversations with Vendor partners to
figure out how we can do numerator/denominator calculations.
That way we can get providers ready to attest
Bruce Wiegand (SE Michigan) – The notice of availability would
be on the HIE side. All we need from an EMR is to populate the
XDM segment of the XDR, then it is up to the XDS registry in the
HIE to identify the information, generate the alert, then get it to
the provider
Chuck Tryon (Tulsa) – What is the site where the Keith Boone
blog is kept
Alan Uhl (Vitera) – Motorcycleguy.blogspot
Lynda Rowe (BAH) –Erica Galvez (ONC) any other questions?
Erica Galvez (ONC) – No I do not think so
Alan Uhl (Vitera) – Keith Boone wrote a protocol for notification
for HIEs a while back
Bruce Wiegand (SE Michigan) – Ed Donaldson (SuccessEHS)
came up with the nav. We included that in the user story, that
is what got me going with how we could leverage XDS
Lynda Rowe (BAH) –So you think this would satisfy MU 2 ToC if
Michigan became an eHealth exchange member?
Erica Galvez (ONC) – I think it probably would, the key is that
notification of receipt. One thing I was thinking, not from the
accounting perspective, but from what providers will want, is
that there may be some thinking to do around read receipts or
delivery of those notifications. Maybe an audit log for each
provider but could be made available in case of inspection
Bruce Wiegand (SE Michigan) – That is where the subscribing
comes in, we have secure inboxes available, they would get
-6-



















notifications the record was available, verses sending
unsolicited CCDs all over the place
o Alan Uhl (Vitera) – Actually Keith Boone wrote this specification
and gave a seminar back in 2005
Lynda Rowe (BAH) – Lets switch over to the Keystone presentation
Sri (Keystone) – We are going to talk about our lab integration effort
Sri (Keystone) – We are trying to help our physician groups get lab data into an EHR using quest
diagnostics EMR. We are asking them to consume the information. we are using Direct for
transport, and looking at getting Certified as an HIE using Direct
Lynda Rowe (BAH) – Are you planning on getting certified in ToC?
Sri (Keystone) – Yes a modular certification, we are transitioning to Orion, we want to make sure
keystone can get certified as the HIE
Lynda Rowe (BAH) – So you are going to be a ToC certified entity?
Sri (Keystone) –Yes that would be required for us to satisfy MU 2. We will get the lab results
then we will use an HL7 message with Direct, send it to care 360, they will identify the payload,
either as human readable pdf or a standard HL7 message, they will then inject the information
into the EMR and notify the physician that a lab result is available. Once that is made available,
we can also put it in the patient portal
Sri (Keystone) – A direct email goes to the physician and one to the EMR
Sri (Keystone) – The HL7 message is sent to Keystone, they create the message for the provider,
which is sent as a Direct message with the HL7 message attached for consumption. The
recipient EMR of the physician receives an email and can read the user friendly pdf or consume
the message into the EMR. There is a 72 hour layover before the data is shared in the patient
portal. This is at a high level what we are intending to do, I can answer any other questions.
Lynda Rowe (BAH) – I know our pilots are content agnostic, I am assuming because you are
certifying KeyHIE then KeyHIE will support C-CDA as the export vehicle?
Sri (Keystone) – With this process we can send any type of message, not just xd lab. We want to
use Direct as the method of transport for any type of message
Erica Galvez (ONC) – If you were certified for ToC, you could receive the information from the
EMR in any form because you would be creating the C-CDA then passing it forward using the
CEHRT transport methods. I have not heard of another HIE taking this route
Sri (Keystone) – We are with Suresctipts right now for Direct, if we do this then all we have to
do is generate the C-CDA, then we are well on the path to meet ToC
Lynda Rowe (BAH) – You are going to be doing the numerator and denominator calculation on
behalf of your providers?
Sri (Keystone) – Yes, because we can count what we sent, who sent it, and where it was sent
Lynda Rowe (BAH) – Is Orion going to do that or are you going to build an app on top of Orion?
Sri (Keystone) - We are still looking at options now
Sri (Keystone) – We could do both, we just need to make sure we have the audit capability. We
want to build the technology first, then figure out the numerator/denominator calculation piece
Lynda Rowe (BAH) – Have you been using the technology, or are you still in the process of
developing it?
-7-





















Sri (Keystone) – We are in the middle of a project to get this completed, we have done some
development work, but it is not yet connected to all the doctors. Once that is all done, we can
provide an update, that will be useful for this group to see
Lynda Rowe (BAH) – We would be interested in how you would technically implement this as
well as how you figure out how the numerator/denominator calculations
Erica Galvez (ONC) – On the lab piece, which vendor are you working with?
Sri (Keystone) – We use Geisinger medical labs, I am not 100% sure of the LIS, on the other side
we use Quest EMR
Lynda Rowe (BAH) – Are there any other Questions? This fits the spirit of our pilots, this is one
type of transitions and Keystone will be expanding it in the future.
Lynda Rowe (BAH) – From the EHR vendors perspective this would be an easy environment to
work in, you just need to be able to send them the relevant data elements for ToC
Sri (Keystone) – We will share some of our results once we figure this out
Erica Galvez (ONC) – The EHR vendor would still need to let KeyHIE know there has been a ToC
bundled so that KeyHIE knows they have to turn it into a C-CDA and use a certified transport. It
seems like it would be hard for you to count that measure without a notification
Sri (Keystone) – What we actually do is look at the NPI number of the provider, then identify the
patient and send it over to care360. Care360 has the NPI information and updates the EMR of
the provider
Lynda Rowe (BAH) – You have to do that for a lab as well as delivering a ToC. You really need to
know what they sent was a care summary and not a lab. How do you identify the difference?
Sri (Keystone) – We are starting with labs for now, if we were going to use this for other ToCs we
would convert encounter information to a C-CDA and send it over. We would then have the
encounters coming in for a specific patient
Erica Galvez (ONC) – I am not sure I understand, it seems what comes out of the EHR would
need to signal to you that this is a ToC bundle?
Sri (Keystone) – Today we get CCDs from EHRs and we pass them on to our nursing homes.
Erica Galvez (ONC) – What is the user story?
Sri (Keystone) – If we receive the CCD, we can count what we receive from each hospital
Erica Galvez (ONC) – Do you receive those CCDs for any other purposes? It is interesting to think
of the RIQI and Detroit case. I would imagine you get a lot of HL7 messages that are not
transitions, but have valuable patient information. I think what you would be counting for ToC
would be a subset of those, you would need to know what is coming in is related to a referral
not an update to a longitudinal CCD
Sri (Keystone) – We have nursing homes connected to us, if we know that this is ToC, once we
know the destination we can pass it on
Lynda Rowe (BAH) – Do some destinations receive multiple documents?
Sri (Keystone) – Yes
Lynda Rowe (BAH) – If I am a specialist, I may receive lab results as well as ToC, so you would
need both the denominator and numerator to know that this one today was a ToC verses a lab
result
Lynda Rowe (BAH) – I think you want to think about the granularity of your use cases and what
document types are associated with them
-8-
3 Action Items

Follow up with Keystone in a few weeks on their pilot progress – Greg Dengler

Continue to develop parameters for numerator/denominator calculations – Co-Chairs

Follow up on Keith Boone record tracking whitepapers/presentations – Alan Uhl/Co-Chairs
4 Dial in Information
TO JOIN THE WEBINAR, please log on to https://beaconcommunity.webex.com about 5 minutes before
the call.
Under the list of events, look for “Follow-up Meeting: ONC Vendor AG - MU Stage 2 TOC transports”
Click on the “Join” link to the right of the session
You will then be asked to enter your email address and your name (Also enter in the Beacon
Community or Vendor you are from)
Your screen will adapt for a few minutes while the session is getting set up on your computer
A grey pop-up box will appear - You’ll want to select “I will call in” from the drop down box
Please dial-in using the teleconference number 1-877-668-4493, follow by the participant access code
664 415 482
-9-