Semantic Interoperability Part II - Architectural scalability is the primary driver for adopting standards

In previous post - Semantic Interoperability Part I , I explained that the primary driver for adopting standards is to ensure architecture integration scalability.

This part is primarily focused on addressing the following questions mentioned in Part I

1. The development effort required to replicate the capability to another system or more in the entire healthcare ecosystem
2. The ability for the existing integrated interface to adapt for future use cases
3. How do I choose the right standards for my solution

To address the first two questions, lets get back to the basic software engineering questions, what do we need to do when integrating two different system, the owner of the involved systems will need to go through the following learning process

1. Understand the high level data entities used in the integration
2. The business definition of each data element in the data entity, the structure and relationship between these data elements, and whether these data elements are free text or coded entry, and if it is coded entry, what code set it uses eg LIONC lab test code?
3. Finally the new system owner needs to understand the physical integration data format such as XML schema, or pipeline flat file format such as HL7v2.
4. What's the service definition provided? What service contract I shall define?

 Besides the above learning curved involved, the architect will probably have to think about the following architectural concerns

1. What's the quality of my design in terms of integration data format and service contract definition? How extensible they are? Can they be easily extended or adapted to future needs?
2. Does the current system support the defined integration data format and integration service out-of-box, or minimum changes required?
3. Even if the current system may not fully support the standard, what standard are majority of the vendor products out there going to support? How can I future-proof my design so that the cost of alignment to the standards in the future is lower?

The above architectural concerns are extremely important points, why?  Let me quote the following lines from Charlie Mead - one of the key people in HL7v3 development, CTO of NCI, and ex-Oracle who was instrumental in the development of Oracle HTB - HL7v3 RIM based healthcare application. I considered him my virtual 'mentor' on my journey to HL7v3 though I have not never met him personally.



Now lets consider what is the consequence if you are using some proprietary integration data format or even if you intends to use some less known or not internationally recognized and mature standards.

• For systems not natively support internationally recognized industry standards, it may simplify integration between two connecting systems, but may still increases the barrier to entry for other connecting systems due to the learning of proprietary format as illustrated earlier

• For systems natively supports internationally recognized industry standards, it essentially reduces interoperability of the participating system and increases the barrier to entry, thus increases overall integration cost   

Of course the above are general rules,  if the scope of the integration is just few data elements and pretty much fixed even in the foreseeable future, proprietary one might prove to be cheaper solution since the learning curve for getting familiar with just few data elements is much quicker than getting familiar with a particular standard. But again I suggest you conduct some level of investigation and feasibility study before you make the decision. Also there will be eventually some tipping point in the development of standards, at certain point unfamiliarity of a particular standard might become exception instead of norm. So you also need to constantly revisit the decision you made in the past.

Now lets address the last question of "How do I choose the right standards for my solution". I will probably use the following criteria to evaluate the candidate standards 

1. Vendor Product Support – International acceptance and commercial vendor support. The more vendors support the chosen standards, the standards will gradually gain higher quality as required by vendor’s stringent quality assurance over the years, this translates to lower cost of integration since the out-of-box features can be re-used, extended or adapted.
2. Community Support – Another critical factor is the community where the standard is being developed. Generally more users are involved in the community, generally more mature and higher quality the standards will be. The open source software development is good testament. Secondly the larger user community, more knowledge sharing and leverage can be achieved, thereby reduce implementation cost. This factor is often neglected by high level decision maker, but turns out to be extremely important for the developers.
3. Market Development and Trend - As earlier mentioned, we need to watch out the market development and trend, identify the potential tipping point, preemptively make decision to ensure your architecture is future proof.

For point#3 above, it is worthwhile to elaborate here,due to the mandate of US Meaningful Use, every EMR solution, whether COTS or in-house developed, will implement and adopt the mandated standards such as HL7 CDA, and coupled with the imminent HL7 IP change,  these development will create huge impact on the healthcare interoperability landscape, and probably lead to  tipping point in the use of HL7v3 CDA standard.  Below figures show the use of CDA in MU.
 


 

I should also mention that HL7 CDA is also widely used in Hong Kong, Taiwan, and being adopted in China as well. Australia's PCEHR, whose core component is Oracle HTB, also adopts HL7 CDA as shown in the below figure as stated in  PCEHR Concept of Operations paper dated Sept 2011.




In the next and final part,  I will go through some detail analysis on some of the standards you might encounter, and point out the pros and cons, so that you can make informed decision on what standards to use.

I'd like to wrap up this part with the following quotes

"If your goal is to pursue silver bullet, we know where you are heading!" 

"If they keep on explain one thing with something else, you know where you shall look for your explanation!"