Semantic Interoperability on Steriods

Posted by ED

<note>RE: Our friend John Hardin -

Dear Members and C.O.M.B.A.T. Advisory Board,

We received sad news this morning and I felt it was important that you hear it from me. John Hardin, a good friend and confidant, passed away on Friday night. We have few details right now but I talked to his wife, Meggan, this morning and she wanted to relay how much John enjoyed working with our members at MBProject and how much he believed in our cause.

As you may know, John presented at our 3rd National Medical Banking Institute and was instantly recognized with an unusually gifted talent in the area of open source technology. In fact, John was a open source warrior, holding key positions in a number of open source organizations to advance the cause (OASIS, OMG). His final position was at Sun Microsystems, an open source advocate, where he managed B2B initiatives. Most recently, John wrote an analysis of how an innovation in UDEF, created at Lockheed, could facilitate semantic interoperability of medical records. You can find this analysis in our last issue of The Medical Banking Report, July/August 2007, Vol. 4 No. 3.

John chaired our Planning & Design Subcommittee for the C.O.M.B.A.T. Initiative. He architected the design for a medical banking platform that could be used by banks for provisioning healthcare records, fully incorporated in MBProject's response to ONCHIT's RFP in 2005. His work defined "C .O.M.B.A.T. Version 1", and we formally recognized his efforts by awarding him with MBProject's Person of The Year Award in 2006. John introduced MBProject to General Motors, Walt Disney, and the Automotive Industry Action Group, paving the way for the formation of our Joint Taskgroup for Value In Health. His contributions in the new arena of medical banking will be memorialized in our website.

I will personally miss our stimulating and encouraging talks about how to link open source to medical banking, align the stakeholders and how small unknowns can create a "disruptive" force in healthcare that can have ripple effects all over the world for the better. I would be most appreciative if you joined with me in extending our sincerest condolences to the Hardin family during this time of loss. He is survived by his wife, Meggan, and his two sons who live in Kansas City.

Sincerely,
John Casillas
Chair, Medical Banking Institute
Executive Director, Medical Banking Project

John Hardin's colleague from SUN, David Lee Todd, adds this post.</note>

This article was written by MBProject Member, John Hardin, Product Manager, B2B Platforms, Sun Microsystems, Inc. John was MBProject’s “Person of the Year Award” in 2006 due to his work in the Planning & Design Subcommittee of MBProject’s C.O.M.B.A.T. Initiative. This article appeared originally in The Medical Banking Report, July/August 2007 Vol. 4, No. 3

As the stage is being set for widespread adoption of clinical record document sharing capabilities, sometimes referred to as Regional Healthcare Information Organizations (RHIOs) or Healthcare Information Exchanges (HIEs), there is a growing number of standards that are competing to provide the payload document formats. These standards include the Continuity of Care Record from ASTM, the HL7 CDA and the XDS-Medical Summary from IHE, among others. Additionally, the interview published by Health-IT World. The article provides excellent insight to many of the issues and opportunities associated with EHR.

As adoption grows, the number of disparate formats creates a lack of interoperability across platforms and applications. If your E.H.R. application produces a CCR as output to share information about a patient, but the care provider that you are sharing with uses an E.H.R. that accepts / produces a HL7 CDA format, then the two can’t communicate electronically. This then creates the requirement for a mapping, transformation and integration project to link the two documents, translating from one to the other and back again. Multiply this times the size of the medical industry, even in a single region, and the result is such a lack of interoperability that the applications become ineffective at sharing data, and the entire objective of the build out becomes difficult to meet.

Some collaboration between these groups is happening, however, there may still be a condition where we don’t have a single standard.... Obviously, this is a problem across all of IT, encompassing most software applications and nearly every industry. It has single-handedly spawned the entire Integration software industry, and complex frameworks are being built to facilitate the processes of transformation and delivery of documents that are different in format, and use different terms to name the data elements. A further difficulty arises as each of those standards bodies improve on or change from one version of the document format to the next. These changes can break the mapping and transformation code, which then require more development to stay current. This is an exponentially increasing problem, which won’t be solved until either every software application that needs to exchange data uses the same formats, or a bridging solution can be implemented to cross the gap between formats.

The problem has a simple explanation: different names for the same data concepts, and is closely related to the formation of ontologies or taxonomies. The solution is termed Semantic Interoperability. The Universal Data Element Framework (UDEF) proposes to solve this problem by adding an attribute, in the form of an alphanumeric tag, to every data element in each format. This would provide a common identifier for each data element concept in each document, which can then be programatically analyzed and matched, then transformed, by software. This will be a major change from the mostly human-based analysis, coding, testing and implementation effort that characterizes current integration projects. Also of note is the fact that the UDEFID’s are alphanumeric, allowing them to also provide bridges across language translations (from English to Korean, for example).

As an example, let’s take a few data elements from the healthcare ontology and make a comparison, then explain how the UDEF tag will help bridge the gap:

UDEF ID’s are assembled based on trees of Object words and Property words, such as: Person (object word...) and Name (property word...). These top level words then have infinitely expandable trees under each, where we can use the deeper level detail to specify a more accurate description of the exact data element concept. Each word in the trees is assigned a letter or number, and these are then strung into tags where an underscore separates the Object side from the Property side.

Some examples from the recent additions to the UDEF trees, meant to support the Electronic Health Record interoperability:

So where we might have one format that calls the Patient Identifier <patientid>, and another format calls it <identitynumber>, there would be a match found when each added the UDEFID attribute to the data element:

<patientid UDEF ID = au.5_13.35.8>, and <identitynumber UDEF ID = au.5_13.35.8>

This then allows software companies to develop applications that automatically find the matches and transform from one format to the other with much greater efficiency. One estimation of time savings, coming from a very large integration project that used a similar method to the UDEF, found that nearly 60% of all data elements could be matched. This saved a tremendous amount of time and effort on the human programmer side of the project.

The UDEF was originated in the Aerospace Industry, by Ron Schuldt at Lockheed Martin. It matured in the Aerospace Industry Association’s Electronic Enterprise Working Group, who exposed the idea to standards bodies as a potential solution to the growing problem of semantic interoperability. It was eventually picked up to be promoted, improved and stewarded by the Open Group. Information on the project at Open Group can be found at http://www.opengroup.org/udef/. Chris Harding ([email protected]) is the project manager for the UDEF.

Current efforts for the UDEF include an Electronic Health Record Vendor Challenge, and a broader Vendor Interoperability Challenge. There are also a number of subject matter experts working to expand the trees of the UDEF so that it is usable by a wide variety of industries, projects to build globally available registries for the UDEF trees, and efforts to create online tools to manage the trees and any updates to them. Eventually, the UDEF will live permanently in the internet cloud, acting much as the DNS system now behaves. From the E.H.R. Vendor Interoperability Challenge email sent out recently:

The challenge to vendors is to deliver semantic interoperability, and to demonstrate this by using Electronic Health Record Data Exchange as an example problem area. Many companies and government organizations are in the process of making plans to support Electronic Health Records as part of the President’s Health Information Technology Plan announced during his State of the Union Address in January 2004 http://www.whitehouse.gov/infocus/technology/economic_policy200404/chap3.html

The problem is that many existing data exchange standards exist for the medical field such as those listed at http://www.ushik.org/registry/x/ and medical systems used today, within hospitals and doctor’s offices, do not support the same set of standards. These disparate systems are now expected to feed an electronic health record for each individual. The detailed scenario and other requirements are available from The Open Group UDEF Project Web site after self-subscribing for free to the UDEF Interested Parties – see http://www.opengroup.org/udefinfo/ for the link.

The Open Group believes that the UDEF can help solve this dilemma but vendors need to step forward with UDEF-based solutions that enable semantic interoperability between disparate systems.

Overall, the entire concept and project is maturing rapidly, and is gathering an enthusiastic following of developers, managers and others. I would suggest that the Medical Banking Project could provide an additional proof of the usefulness of the concept, by encouraging adoption of the UDEF by healthcare IT vendors, and potentially demonstrating it’s advantages within the COMBAT or a related MBP project.

You can download the UDEF definitions, in XML or in RDF format, for use in your enterprise. To do this, you must join the UDEF Interested Parties Group. Membership in this group is free. As well as enabling you to download the UDEF definitions, it will give you access to more information about the UDEF, and allow you to contact other users of the UDEF, and UDEF experts.

For more information, please refer to the UDEF home page at the Open Group, and consider joining the effort.