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.