Enterprise Information Management

The most popular standard for exchanging of data between two disparate healthcare systems is known as HL7 (HelathLevel 7), which is currently in its v3.0 adoption (XML based vs previous versions that were pipe-delimited flat files and trust me, a pain to read). There are few other standards that take one or other mutation of HL7 and build upon it, such as IHE or CCD (Continuity of Care Document). In addition to the data exchange, the data content itself may be codified drastically different in different systems. For example there are disease and procedure coding schemes such as ICD (International Classification of Disease), CPT (Current Procedure Terminology) etc.

So now one is talking about having a patient's medical data in different systems (internal or external to a given provider) who each could possibly codify the data in a different scheme and who each could decide to use or not use a common platform to exchange the data. Got the context... No wonder a patient who has had a CT scan a day before goes thru another one next day because the refered physician does not have access to the report from the previous day's scan. Talk about wastage of resources (and obviously increased healthcare costs) not to mention the access radiation going thru the patient's body which could have easily been avoided.

So the response in the industry has been the clamor for an interoperability platform (a Health Exchange, usually called HIE for Health Information Exchange) that is primarily a glorified ILM system with a few additional bells and whistles. Core to such a platform is a clinical repository (though federated approach is also equally popular) that contains the most significant aspects of each patient's clinical data, extracted in batch from the source transaction systems. Obviously one can not hope to put every person's complete medical history in one single repository (after all we are talking about 300 million+ people in US and many of them quite sick. We dont even start talking about the Billion+ size of India or China). So what does one do? One option is to create a hierarchical repository structure, a la domain services provided by the erstwhile Network Solutions.

In a hierarchical structure (the kind the US' NHIN, National Health Information Network, is attempting), you create distinct repositories for let's say each community, which in turn get connected at a regional level, which in turn lead to state level network, which finally get into national network. Complex, Aye! (My attempt at Canadian vernacular). This is a task  easier said than done. One has to categorize data from the perspective of what can be and what should be stored at what level, how to link a patient across multiple systems each of which could (and usually do) have a distinct patient id. Add to it the regulatory mandates regarding patient's health information (PHI) and you have a royal mess on your hands. The situation leads to some very clear mandatory requirements if one wants to attempt healthcare data corelation and management:

1. MPI - Master Patient Index -> A probabilistic algorithm that can accept demographic information of the patient as input, match it against similar information in other networked systems, and generate a common patient id that spans across all systems. The MPI algorithms are usually associated with services to define probabilistic thresholds (all records above the upper threshold are definite match, all records below lower threshold are definitely not a match, and all records in between the thresholds require additional intervention to decide whether the are a match or not
2. RLS - Record Locator Service -> An identification logic that given the MPI as input, identifies all the source systems that contain any medical data for the patient and passes the information to the EAI component (or a low-foot-print proxy server, sitting on the source-system side), to retrieve the required data
3. Consent Management -> An encapsulated component that allows the patient to maintain permission for who can see his/her medical data, what data is available to be viewed and under what condition.
4. EAI / Proxy Server Component -> Collection of components that given the patient id in the source system by the RLS component, retrieve the required data from the source system, convert it from its source terminology (coding scheme) to the common terminology used in the clinical data repository, convert the data into HL7 (or whatever common standard is being used) message, and then store-and-forward the message according to guaranteed delivery principals.
5. Presentation portal -> Distinct portals for patient, physician, and administrators that provide services such as longitudinal record (complete medical history of patient) presentation to physician under care-giving situation, Clinical Decision Support (CDSS) considerations, secured communication between physician and patient, Refill reminders, remote consultation etc.

I end with a generic architecture for a federated HIE. Any questions or comments are welcome. See ya till we talk again.

http://infosysblogs.com/eim/HIE_Federated3.html