Thursday, April 3, 2014

Support Requesting Data over Direct - Join SWG by 4/4/14

The Data Access Framework (DAF) initiative was launched in June of 2013 by ONC to standardize the ability to pull data from inside of one’s own system (local DAF) or to request data from someone else’s system (targeted DAF). I have been involved from day one as the first committed member of the project and have made it my personal mission to espouse the benefits of Targeted DAF to solve several problems with HIE Pull services as implemented using  web services. The lift is minimal for Direct as we will use existing metadata definitions to populate the Direct request message. We need as many of you to commit to this sub-workgroup if you believe in any of the business reasons or benefits below.

If you would like to participate in this SWG, please e-mail Gayathri Jayawardena at with your contact information and reference the DAF over Direct SWG.

Business Reasons you should commit to the “DAF over Direct” Workgroup


You should commit to this workgroup, or have your EMR vendor commit, because implementing DAF over Direct allows you to work the way you work. It replicates the phone/fax/mail process by which you don’t necessarily have to collect any additional releases from the patient unless you really need the sensitive data protected by specific release. In this one-to-one push model, you can request and receive PHI as you do today on a patient you are treating as allowed under HIPAA.

ACOs and Health Plans

You should commit to this workgroup, or have your HIE vendor commit, because implementing DAF over Direct allows you to work the way you work. It replicates the phone/fax/mail process by which you already can collect patient data for the programs you offer based on the relationships in place between you and your provider network and/or between you and your subscribers. You don’t have to jump through another consent hoop that doesn’t exist today.

EMR Vendors

You should commit to this workgroup because it removes the more cumbersome and mixed HIE standards that are occurring today.


You should commit to this workgroup if you are in a state that believes in reducing costs of health care and government.

Problems Solved by Targeted DAF over Direct

Problem – Too Complex for the Client EHR

Basically, for an EHR to be part of an XDS affinity domain and pull information from an HIE or from another EHR peer to peer as part of the same domain, they have to do as many as 6 web service calls to look-up and maintain the patient identity cross-reference (PIX – up to 3 calls), provide consent, find the document, and retrieve the document.
In the ideal world EHRs and HIEs would connect using late binding that allows for acceptable differences in their implementations. This is done using a Service Directory (e.g. UDDI) such as that offered by HealtheWay. However, this isn’t really occurring. EHRs are for the most part tightly coupled to HIEs or other EHRs and HIEs are tightly coupled to each other even if they participate in a service directory.

Due to the complexity and tight coupling, the number of implementations is limited. In fact, many EHRs don’t have support for XDS web services today. But, most do have Direct protocol support.

Solution – Simplification to a Single Transaction

DAF as proposed has the potential to remove the complexity of multiple transactions and simplify this to a single request for either documents or data (multiple rows in a data document).

Problem – Limited Control in Host (HIE or responding EHR)

Even when EHRs integrate with HIEs, there is a major problem in the way IHE web services work. They put all the responsibility on the client EHR. The client adds, updates, or finds the patient. The client separately posts consent declarations. Then the client finds the document. Finally, the client pulls the document it wants.

Solution – More Control for the Host (HIE or responding EHR)

The Targeted DAF method would reduce this to a single transaction sending a declaration of what I want on what patient or patients and why you should give it to me. The HIE or responding EHR contains the orchestration and business rules to determine who to automatically respond to from a whitelist of known providers by Direct address and what requests do not meet those rules then can be looked at manually.

Problem – XDS Implementations are splintered

Today, due to limited implementations of XDS by EHR vendors but support for Direct and XDR, presumably to connect to a HISP for Direct, by EHR vendors; multiple HIEs have implemented Direct and XDR and methods to supply data to an XDS affinity domain. Those HIEs orchestrate the PIX transactions behind the scenes.

In this model you have EHR vendors implementing with HIEs in many different ways for XML documents. The first is pure XDS as we do in New York. The second is over Direct as they do in Rhode Island. And the third, is a Hybrid using XDR (XDS.b provide and register) with the requisite PIX transactions being performed by the HIE and the content being posted to the HIE repository instead of referred to another as they do in some IDN based HIEs. These are just the more common standards based ways. Beyond this your have people sending Base64 encoded documents in legacy HL7 2.x messages and who knows what else.

The problem beyond the lack of using a single method due to lack of support in EHRs is that these are all about sending data in and in many cases using Direct to do it. There is no solution to use Direct to get data from the HIE or another EHR. Thus, users of one-way methods to post documents to HIEs over Direct, need a way to get data over Direct back into their EHR.

Solution – Harmonize a solution to request data via Direct

This completes the Direct integrations between EHRs and HIEs that already exist by giving them a means to get data from the HIE community back into the EHR rather than having to use an HIE portal and not be able to digest the structured data.

Problem – Privacy restrictions when Pulling data

In the real world, you request data from another provider, you don’t take/pull it. The IHE web services and audit is based on taking data with permission of a user. While this may reflect the reality that provider has an existing user account at the local hospital to access records; that is not the real world. That is a world doctors were forced into by the limitations of 1990s technology. In the 1990s, organizations gave people passwords to their systems via simple portals and VPNs because they had no real interoperability to solve for the problem of routine record access by those within close trust. To see the natural relationship, we need to remove that forced world and look at how they get data with no systems in place. In that world, the provider wanting the information asks for it and the other decides and responds. This process of, I’ll just open the whole system and let you find what you want, probably wasn’t what should have been replicated. This is the client-side focus of the IHE.

Solution – Change from client taking data to host sending data.

DAF Allows Hosts (those responding from a legal perspective (the practice/hospital, not the HIE or EHR vendor) to define how and when they share data and with whom. The transaction is a request from the entity wanting information followed by an evaluation of the request by the entity that will respond, followed by a response (no or here is the data). The responding entity is responsible for evaluating the privacy policy and matching the patient for the request. This is just as they would for a request made by phone or fax today from a trusted partner. The main difference is that that evaluation can be automated for trusted partners and put into a manual queue for those needed more vetting.  The automation will improve as well as Data Segmentation for Privacy (DS4P) is adopted and the response can leave out any protected data not covered by patient release. This is the responder-side focus of DAF.

Problem – Security Concerns with Synchronous query using web services

XDS registry/repository web services based HIEs are protected by a fabric of trust that ties to a public key infrastructure and the protection of a private key identifying a trusted endpoint (Other HIE, SaaS EHR implementation, hospital, etc). If a private key identifying such a trading partner is stolen, the person who stole it can essentially pretend to be the organization that uses it. In a synchronous query environment, this is hard to detect. After all, the query is coming from what you identified as a proper trusted endpoint. The results of the query are returned on the same transaction as the request. 

Solution – Direct Transport Protocol            

In an asynchronous implementation of XDS, such as by using Direct as the transport, this is improved because the information would be sent back to the known address of the endpoint, not just encrypted to the key of the endpoint. So, someone would have to steal the endpoint address (domain name most likely). This would be more readily noticed by the endpoint as they would not be able to communicate with anyone over this transport any longer.

Another benefit of Direct as transport is that it is far more prevalent than IHE web services as it is the required transport for Meaningful Use (MU) stage 2 that began on April 1, 2014.

Summary of Benefits

I believe Targeted DAF can produce a superior form of HIE by which not only are records accessible from all whom have data based on a signed consent form that overcomes specific release requirements, but also serves other business relationships between organizations, such a population health management between ACOs and their network of providers. It represents the real world of exchange and provides greater security protection. When combined with Data Segmentation for Privacy (DS4P), it can provide a privacy-limited exchange when specific release and business relationships are lacking but the provider requesting the data is treating the patient and supplying information in such case is allowed by HIPAA. This real-world-view of “push me a request”; “I’ll evaluate it and push you a response”; has fewer limitations than true PULL from my records systems that impose greater restrictions for that reason – they are a take not a request. It can even work across state boundaries as it does in the phone/paper/fax world today with the responder evaluating the request under applicable law.

Upcoming Timeline

On the March 19th DAF “All Hands” call, Direct was discussed as a choice for transport for targeted DAF. ONC committed to sending out an interest letter to all committed members of DAF to launch an implementations workgroup for Direct based DAF on the March 26th “All Hands” call. My organization, HIXNY, is already planning to take part in this implementation workgroup.

On March 31st ONC announced that the DAF/IHE White Paper Now Available for Public Comment and it is available for download at Comments can be submitted through the online form located here

The IHE white paper is not necessarily all encompassing of DAF at this point as IHE doesn’t have a single transaction that will support requesting a document on a patient by describing the document and describing the patient rather than doing multiple transactions to identify the patient and the document and then finally requesting it. This is work that is still required to simplify the service and any comments supporting simplification could drive more resources towards that goal.

Call to Action

I encourage any EHR, HIE, or other party that is interested to join us in the implementation workgroup for Direct protocol for Targeted Data Access. Together we will overcome the artificial boundaries of HIE. If you would like to participate in this SWG, please e-mail Gayathri Jayawardena at with your contact information.

Monday, July 1, 2013

Direct Protocol Grows Up

Not Just for Clinician to Clinician Messaging Anymore

I have long maintained that the Direct Protocol, while it is basically email, was not just for physicians to send messages to physicians. Instead, Direct is exactly what it describes itself as a Secure Health Transport. As such, it can and should be used in a variety of use cases whether they are for user to user integrations, system to system integrations, or some other combination.

The Standards & Interoperability Framework projects have long recognized that Direct is a Secure Health Transport for many uses and that many of those are automated system to system communications. Beyond the eReferral model of the initial Direct implementations, the S&I Framework has added projects like Lab Orders Interface and Lab Results Interface that are service organization to provider communications. Also, they added projects like Query Health and now Data Access Framework that are more system integrations to serve population health queries and automate chart pulls from either EMRs or HIEs.

The first of these initiatives were slow to mature but now that Lab Orders are on the radar, Lab Results will pick up. Of course, it will work best when the order comes in with the direct address that need the results and then the results can flow more easily. Query Health will be slow just because it isn’t an existing service that everyone does. So we aren’t making something better, we are making something new. That needs more policy than technology so adoption is going to be slow but steady.
Unlike Query Health, I believe Data Access Framework will really jumpstart Direct into use as a mainstream transport protocol for broader HIE than just one to one communication. This is because it is always policy not technology that holds up adoption. In the case of policy for pulling data, many regions already have a policy implemented by their local RHIO and the tie to that policy is the participation agreement with the RHIO. So good news, policy already exists for pulling data. Now we can just implement technology for those EMRs and practices that didn’t do web services but have Direct.


The HIE embedded HISP

The fact that RHIOs will use Direct Protocol both to receive data from practices/EMRs and to accept and respond to queries of the HIE for patient centric history is why I have long been driving the notion that HIEs are an abstraction point between providers for data integration and HIEs need to implement Direct as one of the many protocols they support. Direct is not some other thing that gets implemented on a different stack from the HIE itself and call it the HISP. Direct is just a protocol. It needs to be supported directly inside the HIE protocols. This is not to be the middleman for EMR to EMR communications like eReferral or someday even for Lab or Image Studies. This is for the core services of the patient centric RHIO/HIE. It is for retrieving patient history into the EMR and it is for delivering alerts and notification of patient centric activity to primary care, care managers/coordinators, and patients in support of the emerging ACO models.

Taking the High Road

The States and RHIOs that have developed or contracted for a HISP that sits outside of their HIE I think have made a huge mistake. Don’t focus on being the HISP. That is a service that sits close to the provider/EMR. Focus on the patient centric data and being your own HISP, just like many EMR vendors and hospitals will be their own HISP, to support your own transactions like patient data access and alerts & notifications. This is what we have done and I believe is the high road so that we aren't competing with EMR vendors or our own participants but complementing them.

Don't Stop, Don't Change Direction, Just Reuse

One last note; don't stop doing IHE web services. The Data Access Framework will still take time to mature the technology. So even with policy out of the way via RHIOs, we still need to move forward. Also, one of the two flavors of Direct (SOAP XDR) is actually the IHE web service XDS.b Provide and Register that is used in the common IHE web service integration to connect with RHIO based HIEs. So any effort completed today is still valuable tomorrow. Again, since the "HIE the noun" is the SOA-based loose coupling (abstraction point) between organizations using multiple standards, one organization may use web services, one may use SMTP, one may still send legacy HL7 message and look up patients using a portal web link. But, they all can communicate seamlessly and not worry about what the other does because the HIE takes care of the translation, transformation, and any changes in transport.

Saturday, June 29, 2013

Data Access Framework - Seamless Automated Chart Pulls

Automated Query for patient detail history via Direct.

A new day has dawned in HIE. I have been quiet on the blog front for a few months. When asked why, I generally respond, "not much to talk about these days." That is over. Now, after 3 long years, we have the main reason I got involved in Direct and the S&I Framework; an ability to simplify the connection to pull clinical data.

The new initiative is part of the Office of the National Coordinator's (ONC's) Standards and Interoperability Framework (S&I). The Data Access Framework is charged with creating a capability for systems to retrieve patient data within an organization or between organizations.

The big question any reader of this should be asking is, "why does this centralized SOA based HIE supporter want this federated do it yourself peer to peer protocol for query of patient data?" That is a fair question. This should be what HIE guys should fear the most. But the answer is simple; we have already connected most everyone who is going to connect using IHE web services. What I need is an alternative using Direct to implement the practices using EMR vendors that do nothing but Direct. So, I see this as an alternative front-end to what we already do. Technically, we will just create an orchestration that publishes this standard but calls the IHE web service interfaces in the background.

It is interesting for RHIOs/HIEs that ONC identifies 3 ways of using the new standard: 1) intra-organizational query, 2) inter-organizational query, and 3) multi-organizational query; but they leave multi-organizational query as out of scope. This is great for HIEs that take a leadership position on this. HIEs (RHIOs, etc.) fit into the inter-organizational framework but they respond with multiple organizations data in one response. So traditional centralized HIEs have a service they can provide beyond just MPI/RLS to find who has records. This is a great opportunity for successful HIEs to expand to serve more practices with a simpler protocol for retrieving patient history.

I see this new service as fitting in with our other HIE based use cases for Direct. These include sending alerts and notifications to primary care, care managers/coordinators, and patients themselves based on patient events anywhere in the region as well as using Direct to feed the HIE updated patient data. The second of course fits in very well with the new Data Access Framework when working with an HIE. A standard Direct message for Transitions of Care can be sent to the HIE after an encounter to update the HIE. The Data Access Framework can be used to request patient data and receive an automated response nearly instantly from the HIE. This is a great move forward to untangle us from VPNs and Web Services and use Direct to its full potential. This will move laggard EMR systems that did not implement IHE web services into the world of interoperability with HIEs or without HIEs depending on what is available in your region. This is a great move forward for HIE the noun and HIE the verb.

Monday, February 4, 2013

Mass Customization based on HIE Standardization

Building the Dell Computers of Health Information Exchanges (HIE)

In earlier posts, "Game Changing Healthcare Information Exchange" and "Weaving the Fabric of Care", I included examples of mass customization as an enabler of accountable care programs. What I left out was the fact that Standardization is the enabler of Mass Customization. Instead, I relied on an earlier post on "The Well Architected HIE and Direct Push", which points out the benefits of standardization using a Services Oriented Architecture and a Common Information Model for HIE. While I thought this was enough, I now think I need to explain more about the relationship between mass customization and standardization.

After a recent meeting on Medicaid Health Homes with several stakeholders, including the state department of health (DOH), I came to understand that some may see customization and standardization as opposing thoughts since they are somewhat antonyms. Actually though, standardization is what makes mass customization possible. In this meeting, I found myself explaining that "your (health home) secret sauce for managing care doesn't have to be the same as that of the next health home". I was attempting to explain in lay terms that "they could have custom business rules and orchestrations to notify them of what they want to know about when they want to know it" and that they could have a "custom dashboard" in the portal. This was confusing to the audience as they were talking to another HIE about a common user interface that everyone would use. So I went on to explain that we standardize at the data model, not at the user interface. At the orchestrations of business services and data transformations, we support customization to support a business process. This supports the fact that, while they don't see themselves as having "secret sauce", the information and events that they were asking for differed by organization because they had different business processes that they wanted to enable via HIE. Thus, they had a custom business problem that needed a custom solution.

I realized that I needed a better way to explain this than "secret sauce". So after the meeting, I thought about how they explain it in business school. Typically, B-schools use the Dell Computer Case Studies. Dell made its mark on the world offering custom products at packaged product prices with quick turnaround via mail order. Dell was able to do this because of the standardization inside of the personal computer. Since computers have a modular design built around a bus architecture, people can choose any combination of capabilities and all that needs to be done is the technician plugs them into the bus. The customer picks their case, motherboard, processor, memory, video card, sound card, keyboard, mouse, etc. The technician plugs it all together because it is all standardized to fit any PC. There were many case to motherboard combinations to choose from. There were many processors that you could use with that motherboard. The video and sound cards plugged into the common bus. The memory plugged into the memory bus. It was all easy to customize because standards enabled customization.

The HIE, like the desktop PC, is based on standardization within a bus architecture. On that bus, the enterprise service bus (ESB), you can have orchestrations and transformations that offer a customization to meet the business need. This is mainly going to be felt as notifications and dashboard mashups that are unique to a care management program. Each program, with different business goals for different patient conditions, may need to monitor and manage differently. This is what I call "mass customization through standardization for care management".

I also think that the HIE makes sense to be the enabler of this mass customization because of its unique position with the health information. The HIE is both the data repository and the patient consent enforcer. For example, some complex business processes need to rely on a choreographed processes by which one entity (e.g. a hospital) decides to contact another entity (e.g. a practice) based on what it knows about a patient in order to determine if there is more to be done or to know. The practice collaborates and uses what it knows to assist the hospital and provide more information or consume more information. This is a complicated iterative peer to peer interaction with different steps in the choreography having different knowledge about the patient. This is very expensive to do in the current healthcare world because it involves a lot of human labor for the interaction. In the HIE, we can actually automate this by having two or more separate orchestrations (one for each entity) that act upon their rights to the patient data. These can even invoke human interactions (e.g. via a task queue) as a long-running process. This composition of separate business processes is known as choreography in SOA/ESB terms. In this way the HIE can automate very complex business interactions, made more complex by patient data rights protections, and become a Low Cost Producer of Business Process Management and Execution between trading partners. I think this is one of the promised value proposition of HIE. It reduces time and labor for collaborative care. This is also similar to the Dell Case as they were a low cost producer of custom PCs because they could assemble to order at the same cost as a mass manufacturer rather than at the one-off cost of a local supplier.

Monday, January 28, 2013

Why Direct makes sense for Data Delivery to an EHR Hub

Who precisely are you sending that message to?

There is a little recognized problem in using legacy HL7 over VPNs to deliver data (lab results, image studies, reports, etc). The orderer is in the message regardless of whether you are trying to send to them or not. The CC list is in the message regardless as well. The attending, the primary, etc. all there but maybe not who you are routing to. Who are you routing it to?

How is this a problem?

In today's modern world of Software as a Service (SaaS), many of the EHRs get data delivery through a common gateway for many practices. If you route a message to a single practice with a locally installed EHR, then when the data source (e.g. hospital or an HIE as its proxy) sends a message to the practice, the practice endpoint and the EHR endpoint are one in the same. There is no confusion about who the message is for. When the EHR serves multiple practices is where we get the confusion. The endpoint of the practice is a spoke off of the EHR vendor hub.

Which of those spokes is the message intended to go to?

The message identifies many providers who could potentially be routed the message (ordered by, CC, attending, primary, etc.). But those may not be who this message is intended for at this endpoint. This is because some of those may be getting this message a different endpoint (they have a different EHR). Some may be getting it at this endpoint but they are still getting fax and are not ready for the structured data message.

Why is this a problem?

First off, the EHR Hub may wonder who you are routing to and may come back to ask about the additional providers that they cannot identify. That isn't a real big issue. The bigger issue is that if an HIE or HISP is in use, some providers may be getting this message by an older point to point feed and could wind up with the message twice. Some providers simply are not whom the sending facility was trying to send to (e.g. the attending has their copy in the hospital system and they are not trying to send it to their ambulatory practice connection). Lastly, there may be a business relationship and BAA chain issue if the EHR Hub sends a message to a practice that does not have a service agreement with the HIE or HISP that sent the message to them.

How do you solve the problem with Direct as it becomes the standard?

The good thing about direct is that it is a routing protocol, an email message. The content of the message may be an HL7 message, as it is with the lab results initiative (LRI). This way the concept of routing is added outside of the clinical content of the message. So Direct will eventually solve the problem across the board as we move from VPNs to Direct over the next several years. That problem being, we only want the message to go to those we intended and not send it to others even if they are in the clinical data for some other reason.

How do you solve the problem with Legacy HL7 over VPN today?

The bad thing about HL7 over VPN is that it uses content based routing within an EHR Hub. The best solution we have found is to add a specific new segment and field for routing and not rely on trying to interpret routing from the clinical message content. This can be accomplished by adding a Z-segment with a provider XCN field to the outbound message to be used by the EHR Hub. This new field is then used exclusively by the EHR Hub for content based routing and the other fields in the clinical content are not used. This resolves any issue with hub and spoke (HIE and/or EHR Hub) based routing until Direct can be introduced as the wrapper to handle the same.

How does it work?

We implement this as either the concept of a "receiving system" for some EHR hubs or as a Z-Segment approach for other EHR hubs in the HIE that I am associated with and it is yet another benefit of the SOA based abstraction that we implement as the foundation of our HIE and it serves as a stepping stone to Direct via the HIE as we are routing based on addressing for user accounts that are specified in the subscriptions (for publish-subscribe SOA pattern) rather than purely on content, even if that subscription is triggered by IDs in the content.

Thursday, January 17, 2013

eRegister and Get Rid of the Clipboard

The Real Use Case for Personal Health Records (PHR)

I have been at this, HIE game, for a few years or so now. And when I go out and meet new people, I get the typical, "so, what do you do" question. Once I tell them and give a little explanation of what it means, about half of them have a follow-up question. There is only ever one follow-up question and it is always the same question "so, are you going to get rid of that clipboard of paperwork that I have to do over and over again every time I go to see a doctor".

The fact that I only get one question from general consumers and it is always the same question tells me one thing. This is what matters to them. This is how they see their information making it from them to their provider today. This is what they want to eliminate by using HIE or a PHR.

In essence, I see the HIE and PHR as one in the same. The HIE, in a fixed repository model, is a collection of "views" of the patient. We have a primary care view from one doctor. We have a couple specialist views from some other doctors. We have a couple hospitals views from some inpatient and emergency encounters. The PHR is either the same as the HIE consolidated view of these, or in an improved form, it is the consumers view of themselves as a patient. In essence, it is what the patient would put on the registration/intake forms when presented with them.

For a few years now, I have been putting forth what I call the eRegistration use case. eRegistration is the elimination of paperwork and pre-population of the providers system. It populates the Contact Information, Health History, Family History, Social History, Other Providers, Employment, Insurance, Payment, Disclosures, Consents and any other necessary information.

Main Case:

  1. Patient Enters Provider’s Waiting Room
  2. Patient uses smartphone to scan a barcode on the wall with the provider's Direct address
  3. Smartphone collects any relevant data from the patient (who is the request for – if multiple PHRs are registered on the same device, why are you here today, what payment do you want to use – if multiple are recorded)
  4. Smartphone sends request to PHR/HIE cloud to share data
  5. PHR/HIE cloud sends standardized message with XML Registration package containing:
    1. Patient Direct Address
    2. Health, Social, and Family History
    3. Care Team info (including Direct addresses) and desire to share visit information with care team.
    4. Insurance Info
    5. Payment Info
    6. Legal disclosures and consents
  6. Provider PMS/EHR prepopulates the PMS/EHR system with the data.
  7. Patient is seen by provider without having to fill-out the clipboard full of documents
  8. Patient is discharged without having to stop and do any paperwork
  9. Patient receives discharge instructions back via their contact address (PHR or HIE portal account)
  10. Patients care team receives appropriate encounter data
The main issue is that eRegistration cannot be achieved in vacuum by the HIE or PHR system vendor or RHIO. We need to make a few, not many, decisions on what XML documents to put into the registration package. Every provider and their system vendors needs to work together to implement such a change. That said, my real use case contains some alternate paths so that providers can all participate regardless of their technical limitations. This is done by having the HIE fill in for the EHR where the provider may not have an EHR or the EHR may not support this use case yet. This way, we continue to not let the perfect get in the way of the good and adoption of new technology move faster.

The ability to scan a barcode on the wall of my provider's office and my paperwork is done is tangible to patients. It is self-enabling. The physical action delivers feelings of trust and ownership in the act of sharing private information. Since the data is in the HIE cloud and not on the smartphone the information is safe. I believe this to be an enabler of HIE that empowers and binds the consumer to the cost and sustainability of HIE. The consumer will now feel their self-interest in HIE in a tangible way if we create this system of empowerment.

Wednesday, December 26, 2012

Game Changing Healthcare Information Exchange

Evolving HIE Beyond just replacing the fax machine

HIE can be more of a game changer for healthcare than just being a replacement for the fax machine. The route to being a game changer is to be an enabler of care management. That care management can come from a health plan (managed care organization), an Accountable Care Organization (ACO) like a Patient Centered Medical Home or Medicaid Health Home, or from the patient/consumer as care manager for themselves or as the caretaker of another.
To do this, I think the HIE needs to serve the following customers and their use cases. These are the healthcare providers for care coordination, the care manager in the role of managing care, the care management at a program management or quality improvement level, and the care management at a financial management level.

HIE must Support Provider-Patient Coordination Use Cases


Send patient data between providers

This is the primary purpose of the HIE PUSH functionality. This is great for planned transitions in care. It is the basic delivery of information from one provider to another. It can be as basic as sending results from a test or study back to the physician who ordered it. It can be a more advanced communication for a care transition between providers such as a hospital transfer or discharge.
This is the basic replacement of the fax machine that most HIEs start with. This is the HIE the verb it is accomplished by either peer to peer or centralized HIE services.

More advanced versions of this support active monitoring of the patient. For example, I defined and had my team implement a "Subscribe with Consent" functionality that is the cornerstone of our offerings for care managers. It is essentially, publish/subscribe that complies with the NYS consent policy. This allows the care manager to subscribe to the patient events and get a PUSH notification or document to trigger care coordination. For example, we can send discharge summaries to care managers for the patients from whom they have collected affirmative consent. That monitoring is a value of HIE the noun over pure peer to peer (P2P) solutions.

Review Patient Clinical History

This is the primary purpose of the HIE PULL functionality. The PULL has mistakenly been described by some as the naked and unconscious in the ED use case. However, that is not the case. This functionality covers any unplanned or uncoordinated transition in care. Showing up at the emergency department is one of these, but naked and unconscious has nothing to do with it. In fact, if that were the case, I don't think it would work if the treating team could not identify you. It is more likely that the patient is dressed and conscious and has granted consent to access their records. This is also valuable for other ambulatory visits to review recent activity with other providers that your family physician or specialist may have been unaware of otherwise. It saves time and money tracking down records with other providers.

This is the slightly more advanced HIE query/response that replaces phone calls and fax machines and does in seconds what would have taken hours and probably not even been attempted. This is what more advanced clinical HIEs do today. This is HIE the noun as most people see it.

Schedule Patient Visits

The clinical HIE is the ideal place to exchange (both PULL and PUSH) schedule data. It gives the provider a view of upcoming appointments and missed appointments. Being able to request appointments and get one scheduled via HIE enables collaboration between the patient, care coordinator (if not the patient), and the care team (all providers).

HIE must Support Care Manager Use Cases

Manage Care Transitions

  • Notify Care manager when patient meets criteria for transition assurance.
    • This is the use of functionality such as the "Subscribe with Consent" mentioned above.
  • Track patients enrolled in various management programs
    • This is basically an additional demographic of the patient. What programs are they enrolled in?
  • Schedule Appointments with Practices. 

Manage Patient Adherence to Quality Standards and Physician Orders

  • Support direct contact with patient for Follow-up scheduling. The HIE should be able to connect the consumers system (a PHR or similar) for communicating with their care team.
  • Notify Care Manager when patient falls out of adherence or is about to. This can be adherence for quality measures, attending appointments, or filling orders for medications, lab work, image studies, or other referrals.

HIE must Support ACO Program Development and Evaluation Use Cases

The product of the ACO is lower cost, higher quality care through evidence based management of the patient care lifecycle. Analytics/Reporting against the HIE activities is a mean to close the loop in that lifecycle for continuous quality improvement (CQI).

Analyze Current Operation

The HIE needs to support reporting on clinical and financial outcomes with ability to segment and aggregate based on patient care lifecycle (how the patient flowed from point a to point b with or without intervention along the way)

Develop New Programs

The HIE needs to support an ability to define a program and enroll patients into that program. This is covered above in program enrollments as well.

Implement Change

The HIE needs to support an ability to assign patients to care managers. The care managers are the implementation of the care management program.

This is all about getting the right data sent to the right person. For example, "subscribe with consent for whom?" The answer is for care manager X and ACO Y or for the PCP, etc.

Measure effectiveness

The HIE needs to support the reporting need as “Analyze Current Operation” but with ability to compare with and without ACO program and cost savings versus the cost of the ACO program itself (Value of the ACO program).

This closes the loop on the question: "Did the program work as we expected it to?"

HIE must Support ACO Revenue Cycle Use Cases


Track patients enrolled in various management programs

This is simply reporting against the HIE by patient demographics (program registrations are essentially just a slowly changing dimension of the patient demographics).

Report Quality for Pay for Performance (P4P) measures.

Ease reporting submission to CMS’s Physician Quality Reporting System as it moves to accepting QRDA XML submissions.
Theoretically, quality will be how ACOs and other may be paid in the near future. The HIE is a great vehicle not just to submit these documents but to find exceptions in them and to share them with other providers.
By finding exceptions in the quality reports, providers can benefit from increased compensation. The HIE can find where the patient is actually in compliance with a measure and send the information back to the ACO or PCP to recalculate their measures.
By sharing the quality reports as sections of the on-demand CDA document produced by the HIE for consumption by providers (The CCD or portal view that providers look at), they can get a quick view of patient non-compliance and have an opportunity to bring them into compliance. This opportunity can occur anywhere in the community, not just at the PCP office. The patient will then get the same message on compliance everywhere they go. They can be bought into compliance during an urgent care visit as well as at their PCP so long as compensation models support/reward it.



I think the evolution beyond displacing the fax machine above is what will make HIE a game changer for healthcare. We won't be supporting just a better mousetrap for moving information. We will support better management from better information.