Software As Service: June 2010

In the US healthcare, there is a lot of buzz around "Interoperability". Mostly driven by standardization bodies and vendors, this discussion is lost in translation. Just count number of standards, HL7, LOINC, SNOMED, DICOM, CDA, AJCC, FORDS, etc. Don't worry if you don't know a few of these standards – Google will lead you in the right direction.

For system integrators, challenge is in synchronizing the relevant information and to facilitate the prompt decision making. Mostly the source data is stored in a relational format in the underlying RDBMS systems like SQL Server, Oracle, DB2, MySQL etc. In some cases, data is stored in legacy systems on mainframe computers in EBCDIC format. For example VistA, the Veteran Administration's aging Electronic Health Records (EHR) system written in MUMPS.

A good analogy would be to compare healthcare interoperability landscape with the United Nations General Assembly. In the UN, we have more than 150 countries and their representative speaking in hundreds of different languages and numerous dialects. Everyone is concerned with "Global Peace". And as was explained by one UN employee, the challenge is to establish the common ground, and ensuring that the message is not lost in translation. We in healthcare are facing the same challenge – for us, it's an interoperability challenge. For system healthcare integrators, interoperability is an ongoing struggle. Consider the following figure

Figure above represents the simplistic view of diverse message formats used in every day healthcare information exchange. Many expert working groups are investing a lot of time and energy in formulating these standards, and keeping them up to date. Most of these messages carry almost identical information like patient demographics, albeit in its own format. For example, X12 Eligibility request and HL7 patient demographics information. In the source data store, patient information will mostly be stored in the same location. Challenge is in figuring out the real cost of supporting these diverse message sets for system integrators like EMR/EHR vendors, and for the end users like providers and hospitals?

Time and again, these standards are presented as panacea for all healthcare data integration issues. Each group claims universal support and wide adoption on their website, and vendors supporting them use it wherever possible. Challenging or questioning their relevance is a sin. From BI system to PACS vendors, everyone is driving this bandwagon. IMHO, standards can resolve an interoperability issue is a myth. Standards are part of this puzzle but not the puzzle itself.

Another issue in interoperability domain is related to the special cases / exceptions. For example, In the US labs market, LOINC is a well established standard. But there are some reference labs where LOINC is not a good enough solution. So we end up with the broken system in which we implement LOINC plus custom codes. It's like writing 90% of the blog post in English with remaining 10% in some other foreign language. Supporting such special requests breaks the interop logic flow. At the implementation level, such requests are either implemented via lookup tables or through custom logic built inside the interop / rules engine.

Finally, the uniqueness of healthcare presents its own challenge. Consider the specialty like cancer care and in that specialty, a very specialized vertical like Brest Cancer treatment. Brest Cancer treatment and survival statistics reporting demands some special attention. Hence, we end up with FORDS - Facility Oncology Registry Data Standard. FORDS provides definitions and detailed instructions for coding patient diagnosis, treatment, and outcomes. Now, standards like FORDS play an important role in the cancer treatment domain. But for the system integrators, this is one more message format to deal with. In the end, we have to deal with multitude of interoperability challenges as explained below

Conclusion

Interoperability requirements will evolve with time. No one standard / group should try to design "Grand Daddy" of all these systems. Any such attempt will create a gynormous blueprint, practically impossible to implement.

References