What about HL7?

Mar 10, 2007 at 7:51 AM
I assume there's HL7 under the hood somewhere, but when I searched for the term "HL7" in each of the documents in the documentation package, I turned up nothing of substance.

The high-level descriptions sound good, but who builds a healthcare connection engine without making any meaningful reference to HL7 in the documentation? Unless I'm starting from scratch on the Microsoft platform and am ignorant of existing healthcare standards, I'm going to want to know how HCE deals with the various flavors of HL7 before I commit too much more time investigating it.
Mar 10, 2007 at 7:34 PM
More specifically, is there any relationship between the HL7 Software Factory and HCE? How about the BizTalk HL7 Accelerator? Is there a place to plug in DICOM? X12? Or is HCE basically just "you can express anything with web services"?
Developer
Mar 11, 2007 at 9:52 PM
Edited Mar 11, 2007 at 9:52 PM

orand wrote:
I assume there's HL7 under the hood somewhere, but when I searched for the term "HL7" in each of the documents in the documentation package, I turned up nothing of substance.

The high-level descriptions sound good, but who builds a healthcare connection engine without making any meaningful reference to HL7 in the documentation? Unless I'm starting from scratch on the Microsoft platform and am ignorant of existing healthcare standards, I'm going to want to know how HCE deals with the various flavors of HL7 before I commit too much more time investigating it.


Hi Orand. This is valid question. HCE defines a connection infrastructure to exchange well defined messages inside an Ecosystem. Those messages are defined for the players of that particular ecosystem. That’s where HL7 plays a big role, setting the standard for the message definition for any particular Health sub-domain. This “payload agnostic” approach provides the following benefits:

- The use of the most relevant HL7 flavour for a particular scenario.

- The adoption of the latest version of the standards without changes in the transport infrastructure (as long as the players are ready to accept the new messages, they can be used). It also allows for the co-existence of two versions of the standard for transition scenarios.

- The ability of having non-domain related messages (e.g. system’s metadata exchange/maintenance) to navigate using the same mechanism as the domain messages (simplifying the development).

I think it is important to stress that it is not “any web service can be transported”. There are mechanisms in place to make sure that a particular message matches the payload being transported and that the message type is agreed between the two parties exchanging the information.

Cheers, Wagner.

Mar 14, 2007 at 1:56 AM
Hi Wagner, there is nothing in your response that paints this solution as being any more healthcare-specific than say BizTalk. Is HCE just a shell project for a "general factory for industry-specific integration factories" or an ESB? From the language used to describe HCE, it seems HCE has seriously "gone meta" with lots of industry-agnostic infrastructure development (store & forward, events, federation/P2P, management, etc.) and a few optional healthcare-specific plugins ("registers"). That's probably not the message you want to communicate, but that's what's coming across. Or is the goal to build a metasystem that allows harmonization of all the various flavors of healthcare-specific communication?
Developer
Mar 15, 2007 at 2:04 AM
Thanks - a good comment.

I know Roberto Ruggeri would have been keen to respond to your questions, but I am aware he is tied up in meetings in Chicago for much of this week. If you don't follow his blog at (url:http://blogs.msdn.com/rruggeri/) you may find of interest his announcement there this week around the HL7 Accelerator.

On the broader question of what HCE is and where it fits, far be it for a mere mortal like me to comment on that as a non Microsoft person, but let me do so anyway!

Microsoft's overarching architecture for Healthcare is contained in the Connected Health Framework. Roberto's initial post on that is at (url:http://solshare.net/forums/thread/343.aspx) with links to the documents. Core to that is the concept of a Connected Health Services Hub - which looks just like an ESB (if you define Enterprise to be a whole health eco-system). HCE is thus a CHF conformant example of such a hub, connecting health point of service systems and health domain services (such at patient registers), and as such is just one example of applying CHF principles.

Your "gone meta" comment is interesting, because I wouldn't have thought of it in those terms, but it does have some validity. The approach to the HCE architecture was heavily influenced by SOA principles, not just because it was a cool thing to do, but in reality in complex healthcare environments loosely coupling is essential. As an example, we have looked at situations where a national or provincial patient register is in place (NHI in New Zealand, EMPIs in Canada), others where there are different patient registers in each hospital facility needing identity rationalisation on the fly, to situations where a register within HCE will become the default. To cope with these range of options (rather than hand crafting in each situation) it is desirable to be able to plug in the appropriate register - local, national, internal, whatever - without changing the fundamental architecture. After all a patient register is just a service - and so fits nicely into SOA concepts.

Therefore in architecting HCE we were very concious that services should be abstracted to an appropriate level that do not constrain their use to any particular domains. So you are right that it can potentially be applied beyond healthcare, although I can assure you the origins and focus to date have been heavily healthcare focused.

BTW, when you have digested the Connected Health Framework, you might look for the Connected Government Framework and note the similarities and differences. After all we are all into reusability - code and architectural concepts.

Have fun reading!

Brent