Tuesday, December 27, 2011

Wisdom from the Chinese Fable of Spear and Shield

There were a lot of exciting activities occurring in healthcare interoperability space this year.

Within HL7, the most phenomenal activity must be the HL7 "fresh look task force" and Grahame's RFH (Resource for Health), later it was renamed by HL7 as FHIR (Fast Healthcare Interoperability Resource, pronounced as 'fire').

In the mean time, there were extensive debate w.r.t modeling the information using HL7 v3 RIM ActRelationship v.s SNOMED CT post-coordination, the intended use v.s actual use of HL7v3 CDA.

Outside HL7, there was the recent CIMI (Clinical Information Modelling Initiative) debate, some intended it to be "HL7 buster". Out of the various discussions and opinions expressed, I found the view of Keith Boone (see Keith's view on CIMI ) correctly reflects the complementary roles played by various and different standards or initiatives in healthcare interoperability arena.

I can't agree more with Keith, I would like to borrow the following Chinese Fable of 'Spear and Shield' to illustrate the point, the moral of the story is to advise people not to overstate the strength and applicability of one particular thing, be practical and realistic, and take balanced view.

English translation of 'Spear and Shield'

In the State of Chu (one of the 7 kingdoms in China during warring state period around 200 BC), there was a man who was selling both shields and spears. He would proudly exclaim: "My shield is so strong it can not be pierced." At the same time, he would continue to boast the strength of his spear: "My spear is so strong that it can pierce through anything."

One day someone asked him: "What happens if I try to pierce your shield with your spear?"

Confused and bewildered, he fell silent.

Monday, December 12, 2011

Building Foundation going beyond EHR

Last Month I attended 3rd Annual Electronic Health Records (EHR) Asia 2011, during pre-conference workshop, I shared my experience in building adaptive enterprise foundation that goes beyond the current EHR capabilities. Below I summarized the key challenges we faced and the approaches of tackling these issues so that EHR scales up progressively to meet ongoing business needs.


1. Plan and design enterprise architecture with business capability centric view to support end-to-end care giving.

The boundary between EMR and summary care record EHR becomes increasingly fuzzy. Traditionally we plan IT systems from care setting perspective, however due to the fact that healthcare delivery is undergoing transformation to support patient centric care giving from primary care, inpatient acute care and the step-down care, there is increasing need for more efficient information flow to support seamless integration of care giving and transfer.

Just like Service Oriented Architecture design, enterprise architecture planning needs to be driven with "SOA style" - Business capability as Service, care setting is the context of the service, care provider/giver and patient are the consumer of the service.

2. Articulate the business benefits and value proposition from the perspective of the entire healthcare ecosystem.

The benefits of EHR is not equally shared by different stakeholders within the healthcare ecosystem, also the time of realizing these business benefits by different stakeholders are not synchronized. For example, in order to provide quality clinical analytic, we need to improve data quality at the point of data entry, however this will incur additional cost of system upgrading and might still increase the workload of data entry giving the current technology limitations and constraints. The additional workload during data entry might lead to time saving at another step of entire care giving process, also improved data quality and thus patient safety as whole.

However those benefits might not be realized immediately, thus at early planning stage, we need to highlight business value with the view from the entire care delivery perspective instead of individual setting perspective, also lays a foundation to allow different stakeholders to realize business benefits as early as possibly to drive up the adoption and at the same time progressively move up the IT capability ladder to enjoy more business benefits.

3. Role of different healthcare interoperability standards/specification

One of the question asked during the workshop is "What standard shall I use? e.g HL7v2, HL7v3, ISO13606, IHE" .

The common mistake in the current healthcare interoperability space is the notion of "all or nothing". To decide what interoperability standards to use, firstly we need to be clear that the above mentioned standards or specifications play different roles in healthcare interoperability, they are not equal, neither exclusive, they are complementary to each other to play its intended role in the entire software development life cycle.

Secondly we should define an architecture framework esp SOA reference architecture to position each respective standard/specification's role in the reference architecture to guide the overall solution design and implementation.

More detail can be found at EHR conference 2011.

Thursday, December 1, 2011

Whose greenCDA anyway

Recently within and outside HL7, there is great debate and discussion with regard to the role and position of greenCDA - whether greenCDA should be used as normative wire format. The context of discussion is from the blog post greenCDA over the wire by Dr John D. Halamka which I initiated the discussion within HL7 group.

Back in Feb 2011, I was also involved in the discussion, HL7 structured document working group stated that greenCDA is a simplified process to produce CDA, greenCDA is not intended to be normative standards as wire format for data exchange. Though greenCDA also produces XML schema, however the greenCDA XML schema is to be treated as XML API by application internally, for example you can use JAXB (Java to XML Binding) to generate Java classes from greenCDA XML schema.

So What's my opinion and position w.r.t greenCDA? Two main points

1) I agree that greenCDA is only a process, a 'green' approach to produce CDA on the wire, it is NOT meant for normative standard for the wire format. Why can't? What's the implication? I will explain it in greater detail below.

2) I also agree that there is a need to simplify CDA wire format to some extent, but the simplification of CDA wire format is completely different from greenCDA. greenCDA may provide some direction and suggestion on how to simplify CDA, but greenCDA is NOT the answer. I will probably provide another post in the future to talk about this topic.

Before I explain my reasons, let me first quickly run through some key concepts of greenCDA. Below figure is the overall greenCDA design process, it uses CDA as basis to create user-friendly XML schema whose element name and cardinality follows the business requirements, and at the same time produces XSLT which is used at run time to transform greenCDA XML document to CDA XML document. Note, currently the tooling is not fully ready yet, most of them are done manually.



Source: greenCDA - an Implementation Methodology for CDA, Release 1


Below figure illustrates the run time process illustrating how these design artifacts are used at run time.



Source: greenCDA - an Implementation Methodology for CDA, Release 1

Now lets use a concrete example, how to translate HITSP spec to greenCDA XML schema. On the top left corner, it shows the spec of HITSP C83 (CDA Content Module) which specifies the data elements and the mapping to CDA. At bottom right corner, the implementer defines a greenCDA XML schema with element name from HITSP specification.



Source: greenCDA - an Implementation Methodology for CDA, Release 1



Having explained the key concepts of greenCDA, now we can see the potential downstream issues and implications for using greenCDA over the wire.

1) greenCDA is not stable XML schema even for the same use case, and there are many greenCDA XML Schema for the same use case within different projects, e.g for exchanging lab result in different projects or different countries since the XML scheme element is named after the data element name in the requirement specification. For example you may name the element name as "adverseEventDate", I may decide to name the element as "adverseOnsetDate" and with additional timing related data elements for allergy, as a result each project will end up having different XML schema for exchanging allergy information.

2) When two independent greenCDA systems need to exchange information, we will end up with two approaches, either a) modify the existing greenCDA schema for these two systems, which will of course affect the existing systems which are exchanging data with them, or b) either of them implements the transformation bidirectionally. The cost of first approach is high (for some explanation, please refer to my another post - intended use vs actual use of CDA), the cost of second approach is also high, may be not as high as the first approach initially, but the long term the implication of second approach is eventually there are tons of point-to-point integration, so the overall cost of both approaches is very high. If that's the case, what's the benefits at all in adopting greenCDA as wire format, the goal of adopting standardized wire format is to reduce the overall cost, and make the system more adaptive.

Why stable XML schema is important for reducing the overall software system cost? From software architecture's perspective, this will ensure system more extensible and resilient - That's the essence of adaptive architecture (Another blog topic for me in the future so that you will have better understanding)

3) Thirdly, if everyone adopts greenCDA as wire format, eventually everyone will define his/her own XML schema, and he/she can claim whatever greenCDA he/she produced conforms to CDA XML schema. Any XML document can be transformed to full CDA schema technically, with this capability, people will create his/her own whatever XML schema for their data exchange requirement, and the transformation to CDA or whatever XML schema can be done later when there is a need since it always be able to transform back to CDA schema. This in fact re-enforce the danger of trying to use greenCDA as wire format as detailed in the above point.


Does that mean you can't use greenCDA XML schema as wire format, yes it can be used as wire format technically. But just be aware of the above implementations I highlighted, and be aware that whatever your greenCDA or anyone's greenCDA will not become normative standards at all if one of your project goal is to pursue standards conformance.