Skip to main content

"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?

Comments

  1. BME and BCE notably intersect with multi-material printing in firms like Metallum3D and AIM3D, who produce pellet extrusion printers able to printing polymer, ceramic, and metal pellets in the same construct. However, IDTechEx additionally tracked publicly announced funding in 3D printing-related firms in 2021, which amounted to over $950 million. Nearly a billion dollars of funding poured into the 3D printing trade last year, most of which went into 3D printing hardware firms. Based on that, the Hand Warmers additive manufacturing trade is not consolidating - it's increasing, and it's increasing thanks to continued innovation in 3D printing hardware.

    ReplyDelete

Post a Comment

Popular posts from this blog

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

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

Using SOA to create Interoperablity between Providers

In the State of New York we have found the key to interoperability for Healthcare Information Exchange (HIE) is in building on a services oriented architecture (SOA). The preferred SHIN-NY 1.0 architecture was based on SOA in order to get the benefits of its characteristics, which are having business focused services based on open standards that provide reusability, flexibility, agility, and loose coupling (abstraction). Abstraction is also one of the foundational concepts of computer science. In HIE, we want abstraction between providers and consumers of information; such that the provider does not have to know how the consumer wants the information and the consumer does not have to know how the provider sends the information. One of our business goals is to make HIE a value-adding process for users in that it transforms between standards without losing the meaning of the content being shared. For example, what if a primary care provider (PCP) wants to send a referral patient summ