Skip to main content

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 summary to a specialist? In this case, the PCP only wants to select the data to be sent, find the specialist in his address book, and press send. He does not want to know, and even his computer system does not want to know, how the specialist receives the data. In this case, perhaps the PCP system is sending via Direct (a secure email containing health information). Perhaps, the specialist receives referrals as Notifications of Available Documents (an email containing a link to the secure HIE repository from where it can be downloaded). Fortunately, a good HIE can seamlessly transform between these and other standards without either of the users knowing it had to happen.
As described in the above example, the HIE works like the telephone network. When you place a phone call, you don't care what kind of phone the other person has and they don't care what kind you have. You can call from a cell phone and talk to someone on Skype or on a 50 year old rotary phone. Doing this provides syntactical interoperability so that one can know what you are saying.
Another example of such abstraction or loose coupling could be results delivery. In this case, an HIE can take a legacy message feed for lab results, translate a local code set into a common vocabulary, transform the message into a Direct message, and deliver it over open standards. This is a value add to the results provider who doesn’t have to change their system and a value add to the receiving medical records system in that they don’t have to support multiple legacy transactions with different mappings into their system.
In the results delivery example, the ideal HIE needs to work like the phone network as well as provide real-time language translation so that one person can speak in Spanish and the person on the other end can hear English. This is the value that a terminology service for vocabulary standardization or translation at the HIE adds to the process. This is what is referred to as semantic interoperability so that one not only knows what you are saying but they also understand what you mean.
This is how SOA for healthcare makes the clinicians and other staff interoperable, not just computer systems interoperable. This is the business focused characteristic of SOA. It starts with the business view of making the medical provider interoperable. Then, we provide processes and infrastructure to support that business.

Comments

  1. Joel RybaJuly 24, 2012 at 3:24 PM

    SOA and HIE intersect by implementing an Enterprise Service Bus (ESB) as the foundation of the HIE; or as the operating platform for SOA. An enterprise service bus is more than just a messaging bus or integration engine. It provides an integrated foundation for orchestrating business processes from reusable services through transformation and message routing. At the same time, it integrates security, auditing, monitoring, and logging into all of those orchestrations. The ESB gives an HIE the flexibility and agility that are characteristic of SOA. The ESB gives the HIE’s customers loose coupling with their trading partners. That not only enables the transformation between standards as noted in the above examples but also allows one entity to change its interface without having to coordinate with hundreds of other entities. The upgrading entity just needs to coordinate with the HIE (one connection, not many).

    ReplyDelete

Post a Comment

Popular posts from this blog

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 ...
7 comments
Read more

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 provi...
3 comments
Read more

"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 upg...
Post a Comment
Read more