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.

 

Summary

 
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.
 
 

Sunday, December 23, 2012

The Audacity of Tenacity


A Lesson in Strategic Management of HIE

Recently I was awarded "The Game Changer" award by the HIXNY collaborative RHIO, where I am the current COO. It was a very nice presentation including a letter of recognition from Senator Charles Schumer.

In reflection though, I didn't "change the game". What I did was I continued to play the game long after the other regions around the state abandoned the statewide strategy for other pursuits. As a result, HIXNY is the only real implementation of the SHIN-NY standards.

Strategic Management

Many years ago, in a class on strategic management, we studied the varied aspects of strategy. Most of it was fairly basic common sense, but a couple of the more unusual aspects of strategic management that stuck with me were serendipity and sticktoitiveness. Thus, I try to never miss an opportunity that falls in my lap, and I try to be tenacious and never give up too soon.

Managing Stakeholders and Expectations

If I had given up on the SOA/ESB model of exchange, HIXNY would not be where it is today as perhaps the most robust multi-stakeholder exchange in the country. During the process, it was like opening a restaurant with Gordon Ramsey, I had to keep the patrons (healthcare providers) in the restaurant, the cooks (my staff) in the kitchen, and the waiters (HIT vendors) getting the orders right and in line with what we could deliver and when.

The patrons wanted to eat and instead of waiting for their dinner, they wanted to eat some appetizers. Unfortunately, this would take away the stove from the main entree so we had to limit the appetizers to just a few. Those appetizers took the form of minor demonstration projects that were built on fragile infrastructure and would later have to be migrated to the more robust SOA infrastructure we were building. While this slowed overall achievement, it was necessary. Unlike when you cook dinner for someone, they can't see a half-baked HIE and get an estimate of when they will eat. It doesn't do anything the stakeholders will recognize until it is done. Those of us in IT knew when we were 90% of the way there, but the stakeholders couldn't tell 10% from 90%. To them is was all 0% or 100%. So they needed the distraction of minor demonstrations to prove that we knew what we were doing.

The cooks were mainly just afraid that the patrons would storm the kitchen. As long as I just made it clear that we were staying on our path come hell or high water, and they didn't see any fear in my eyes, we were fine.

The waiters were another issue all together. Basically, I had to play them against each other. Who would get an extra reward for being first to take an order and deliver it? Vendor X is going live next week, with all the work you put in don't you, Vendor Y, want to go first? The truth was nobody was going live. They all wanted to test more. The problem was, test data was never going to present all of the variation as production. Somebody was going to have to serve the first meal and hear that the meat is undercooked. Eventually, I got one to move through this competitive positioning and another to follow. The rest would then follow out of competition as well.

Taking Risks and Drawing on Experience


Even one of my key vendors didn't want to support our move to go live with repository exchange for the same reasons. Their exact response was "no don't do it, it’s not ready". I simply told them that they better put on more support staff and expect that we were going to open support tickets. The meals were going out to the patrons, ready or not. We were going to learn and fix at the speed of live production. If I didn't do it, who would? My problem was, I didn't spend two years of my life just to show a test implementation to NYS to get final payment from a grant. I did this to do it for real. So we were going live. We were between CEOs at that moment so I didn't need to ask anybody. It was my responsibility to make the call and my accountability to live with the consequences.

I had the prior experience taking ERP systems live across the globe. I knew that nobody was ever happy enough to take those live either, but we always made it through and had a more successful company at the end. So, I figured we would have some complaints but those would happen no matter when we did it and how much more testing we did. It was go time.

Sticktoitiveness is NOT Following the Herd

I could have followed the herd. The herd was just getting signoff on grants and never putting repository based HIE into production. The herd was so concerned with their customer having a perfect experience that there was no such thing as a "good enough" first effort that could be improved upon. To add to that, some parts of the herd were already moving onto the next thing, like Direct.
We didn't follow the herd and after one year in production with the standards everyone agreed to, we have delivered on the promise. The customers see the value developing. There is still more to do to make this easier and more valuable but we are on the right track. By taking the risk, we eliminated the chance that HIXNY would give up and follow the herd of non-compliance with the state model.

Deliver with Integrity because the game never ends

In the HIXNY case, we have a payoff for now. This is a changing market however. Thus, those who did not stick, may still wind up on top. I suggest anyone building an HIE stick to what they say they are going to do and achieve something besides pulling down grant funds. Even if others pocket more money and perhaps win over you in superficial ways, at least you can have self-respect and there are always other opportunities for those who deliver on what they say they will deliver. The game may change. You may win a round or loose a round. But the game never ends.

Friday, October 5, 2012

Preventing the HIE Cloud from Raining Data

The HIE of yesterday was based on legacy connections across private networks (VPN mostly). Access may have been over the Internet with just a user ID and a password. While this seems little security, it is generally pretty good so long as your password policy is strong and your users understand the basics of passwords (no sticky notes on the monitor).

That type of HIE had a centralized security model. Now, I welcome you to the modern HIE, connected by either web services and secure email. This decentralized or federated security model is not something healthcare is used to dealing with. There are two major issues that need to be addressed:
  1. What is the security policy of the system that actually authenticated the user
  2. Is the system that authenticated the user, actually the system I think it is.
Suppose you have users connected via web services for cross domain data sharing (XDS) by which they can pull clinical data into their system or viewer. Or suppose you just have single signon (SSO) solution that allows a trusted connection to establish a session for a user. Or even if you have QueryHealth with a query and response over Direct in the future. Our first question should be, "What is the security policy of the system that actually authenticated the user?" If we have a policy for strong password, limit password reuse, two factor authentication, disable accounts after a number of attempts, maximum session time length, etc. shouldn't this client system to the HIE have to have the same policy or stronger? Yes it should, so these, if not expressed during connection in SAML, should be established by policy with all HIE participants.

Now suppose those web service connections rely on public key infrastructure (usually for SSL client authentication, encryption, and digital signatures). Or, suppose you do HIE via Direct (S/MIME protected email). The private key needs to be kept private. If the wrong person obtains private keys, then public key security is defeated. That person can impersonate the authorized owner of the private key. If the private key is a credential for a hosted EMR, the person can impersonate any of the users that that EMR vendor uses that key for during authentication. So our next questions should be, "What has been and will be the custody and protection of the private key?" and "What happens if you find out a key is compromised?" Then we need to evaluate those answers against our policies to see if we really want to connect to such a system.

From the other side of the equation, we should be asking ourselves, can I detect use of a stolen certificate even though the certificate owner does not know it has been stolen? Are we mapping IPs to certificates and participants? Do we have an XML Firewall (e.g. IBM Datapower or Level 7) in front of our XDS web services? Are we monitoring for unusual shifts in the use of these credentials using event monitoring for fraud detection? If not, maybe we should. Otherwise, maybe the VPN was better.

For password access, one of the most common techniques for 30 years has been to tell a user when they last signed on and from where. That way, if their account was compromised, they know it and can contact a system admin. This closes the loop. For certificates, maybe we should close the loop on federated security by reporting accesses back to the source system provider and they should match to authenticated user activity to find if the certificate was used by another system. This is of course a use case for query of the ATNA repository by the accessing system. However, the reality is that few if any client systems are prepared to close this loop by using query of ATNA.

The above sounds like a bunch of stuff the techies work out and nobody needs to worry about it. However, most of the above is policy not technology. We need to require policies for those we connect. Our password policy or stronger needs to be their password policy. Their certificate management policy needs to be acceptable under our policy. Those we connect to, to pull data from, should have similar policies to place requirements on us. In the end, even if your hospital or practice connects to the HIE via legacy connections and portals, you are still concerned. This is because it is the other guy, and how he is connected, that exposes your data. While I believe today's HIEs are secure, they rely too much on everyone to "do the right thing" without a policy or contractual agreement telling them what that is. So, I am advocating that we need to federate the security policies as we federate the authentication of the user. And we are federating the authentication of the user, because that is what lets them stay in the workflow of one system. So in the end, if we want access to patient data embedded in the workflow, we need to make sure we have good federated security policy.

Thursday, August 30, 2012

"Version the Verb" is more efficient with "HIE the Noun"

What happens when you version the standards for P2P exchange?

One of the key value propositions of "HIE the noun", for example an Enterprise Service Bus (ESB) based regional patient-centric exchange, is that it abstracts between data providers and data consumers. Thus, if a new standard comes along, some can implement it and some can hold off. The HIE provides the abstraction between the two. There is no tight-coupling between trading partners. In the "we will all do the same thing peer to peer" model, doesn't it break when something new comes along? Otherwise, every P2P end-point needs to support every standard that emerges as they emerge and until everyone has it implemented, the world is frozen.
That sounds an awful lot like where HIT is with ICD10 right now. Most systems seem to have tightly coupled to the ICD9 codes rather than having an abstraction in their system between internal coding and the outward facing standard codes, now they have trouble upgrading, and nobody can move until everybody moves or the trading partners need to build the abstraction that they missed so that they can do both without losing granularity in the coding. Why repeat the ICD10 mess, build on abstraction!
Part of the argument for a P2P strategy is that current HIE is too expensive if you can even do it. I say ESB based HIE is less expensive than the support of P2P because of reuse and we do it every single day.

Essentially, I only see 3 possible ways to support electronic HIE:
  1. You build on a single standard and never change it so that P2P is inexpensive but is not adaptive to change or extensible for new solutions.
  2. You allow change but still want P2P so everyone runs an ESB and everyone supports every version of every standard and they need to tightly-couple to their trading partners by knowing what standard they support and transforming to that standard.
  3. You have a community service bus, an "HIE the noun", and thus you benefit from reuse. Everyone has one integration with the ESB rather than with each other. And you benefit from abstraction. You don't need to know how your trading partners can send or receive data, the HIE takes care of the transformation.
If option one were a reasonable model, we would all be running Version 1 of just about everything. So logically, that is not going to happen. Option two is what option one leads to once you realize standards version and get replaced. Option three is the cost saving alternative to two where you centralize the abstraction as a service. That abstraction service is called HIE and it is generally provided by RHIOs in the parts of the country that have successfully matured this service. So what is the argument for P2P being less expensive again if it results in every system having to be an ESB and everyone having to know how what their trading partners can support?