Health IT Standards: Where went wrong

Over the past few years I have been facing people with two extreme views - one view is that 'standard is magic', the other extreme view is that 'standards never work'.

I am not going to address the second one here, since I concluded that it is primarily caused by the people who is holding the first view, as long as we address the root cause of the first view, hopefully we are able to help the second group of people see the benefits of standards.

To avoid confusion and set the context correct, the HIT standards I am talking about here is interoperability standards such as HL7v2, HL7v3 RIM, CDA etc, excluding terminology.

For those people who has the view of  "standard solves everything" tends to have the following characteristics

1. Lacks the mindset and experience of architecture design

2. Theoretical view of the world out there, and pursue the dream of  'silver bullet'

3. Not Invented Here (NIH) Syndrome


Let me share with you few real conversations I had in the past. Once I was asked about how we know that the interoperability standard developed is ready for implementation. Guess what is my reply, my simple suggestion is the following question,

"Do you know HOW to implement this standard if you are the one to implement?"

I continued to say that if the answer is "No", then I am 100% sure that there must be something very wrong with it even before I look at it.


In another situation, I was asked how the standard can help to churn good data out of low quality data, that's really amusing! How can it be possible that interoperability standard itself turn bad data into good data? If some data is missing from the received message, yes, the receiving system may be able to figure out the missing data, but that is not going to be solved by standards itself even if it is achievable.

For people who holds the view of 'silver bullet', they tends to misplace the use or application of one particular technology or standard, take the case of ISO13606 or openEHR, which I find it very useful for clinical requirement definition as I commented on this blog - Complexity of Standards, however if we are going to turn that standard into a universal data exchange and OLTP/OLAP model, that's where standard scares away the people who want to adopt standards in the first place.  This kind of debate is just as useless as arguing 'whether to use SQL or MapReduce', the right answer shall be 'Use the technology where it thrives'.

The last one - NIH syndrome, it is so pervasive, different people do have different views and opinions, I guess everyone wants to create his/her own thing so that we can leave some legacy behind, I am not exception. This can only be solved by the organization which shall enforce the rule of putting personal views and opinions behind organization's and extended community's collective objective. If you do not use the standards the industry already developed, and continue to enhance and extend, then what is the point of developing standards in the first place? It defeats the whole purpose of using standards.


So how to equip yourself with the architectural mindset to solve the first two problems mentioned above?

Lets look at the definition of an architecture used in ANSI/IEEE Std 1471-2000:

    "The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."

The most difficult part of architecture design is reflected in the second part of the above definition, the principles governing its design and evolution to ensure that architecture's agility - extensibility, configurability, customizabillty, etc. It is extremely easy to design an architecture or information model without considering its evolution, however this kind of system is extremely fragile, I think this point will somehow relate to some of the projects you are involved, and you might be smiling. If so, please continue to read.

So how to ensure the architecture's agility?

1) Why? We shall ask the WHY question before you develop anything, whether it is interoperability standard or a piece of software, it is all about design. Only when you ask WHY, you will be able to uncover the real objectives. The tendency is that users give very vague requirement, and sometimes they are just clueless.

2) Anticipate! With the correct understanding of objectives, you will perform some level of predictive analysis. How far and deep you can predict is based on your experience, that's why architecture design is an art to some extent.

3) Tradeoff. Architecture design is all about trade-off, it is the design of different choices, you can use ATAM (Architecture Tradeoff Analysis Method) to help you on that.

4) Outcome. We shall think about outcome before we start to develop anything.


5) Engineering.  We need to have strong engineering discipline to do the work. I have mentioned this point in my previous post - Standards based Implementation

To conclude, interoperability standards development is architecture design activity, treat it seriously, realisticly and holistically

If you are in the middle of developing your own backyard standards, think about twice here! Are you on the right path?

How useful is 13606 RM record component id

I was asked why rc_id in ISO13606 is mandatory, below is the summary for sharing.

Note: below few paragraphs are excerpt from ISO13606-1 2008 version spec.

ISO 13606 is not intended to specify the internal architecture or database design of EHR systems or components. Nor is it intended to prescribe the kinds of clinical application that might require or contribute EHR data in particular settings, domains or specialities. For this reason, the information model proposed here is called the EHR Extract, and might be used to define a message, an XML document or schema, or an object interface.

ISO 13606 may offer a practical and useful contribution to the design of EHR systems but will primarily be realised as a common set of external interfaces or messages built on otherwise heterogeneous clinical systems.

Now lets look at this RM (reference model) as shown below RECORD_COMPONENT class which is the top level class for most of the 13606 RM classes - COMPOSITION, SECTION, ENTRY, ITEM and ELEMENT. ELEMENT class is the object that really holds the actual data. (this is important concept, we will refer it later)





"rc_id" attribute inRECORD_COMPONENT class is mandatory, now let's look at the definition of this attribute in ISO13606 spec,

rc_id: The globally-unique identifier by which this node in the EHR hierarchy is referenced in the EHR system to which the data were first committed. This identifier shall be retained by the EHR Recipient and re-used whenever this RECORD_COMPONENT is subsequently included in
another EHR_EXTRACT.

Below was my reply.

First, Is it meaningful or useful that every record in healthcare system has globally unique identifier in data exchange? As we mentioned above, RECORD_COMPONENT is top level class, so if rc_id is mandatory, then every sub class instance will need to supply value for rc_id.

Use a concrete example, lab test lipid panel has the following test item




Since in ISO13606 model, the actual data is holding in ELEMNT class, for the above test result, there are at least 4 ELEMENT object instance and 1 CLUSTER instance for the panel itself.

CLUSTER -- Lipid panel with direct LDL in Serum or Plasma
--> ELEMENT : Cholesterol [Mass/​volume] in Serum or Plasma
--> ELEMENT : Triglyceride [Mass/​volume] in Serum or Plasma
--> ELEMENT : Cholesterol in HDL [Mass/​volume] in Serum or Plasma
--> ELEMENT : Cholesterol in LDL [Mass/​volume] in Serum or Plasma by Direct assay

So for this particular report, the system needs to generate 5 GUID just to be compliant with the Reference Model. But how useful it is for data exchange? Does the receiving system need to know the GUID of each test item in the report? Will there be any value to the receiving system? Not at all.

Second, if the rc_id does not serve any purpose for data exchange, does it serve any purpose within the system? Yes, it is possibly required within the system itself, probably used as primary key to uniquely identify each record in database tables and the relationship. At relational data model level, there definitely needs to be primary key for each table, however this kind of information shall not surface at EHR extract reference model level. The abstract level information model shall not be mixed up the actual data model of the database otherwise each model will not be able to perform its intended function properly . Also it is contradictory to the intended objective of ISO13606 - "ISO 13606 is not intended to specify the internal architecture or database design of EHR systems or components".


So my conclusion is that it is wrong that ISO13606 RM specifies rc_id is mandatory.


However the user was not satisfied, he asked a very interesting question - why not let sending system specify what ever pseudo GUID in rc_id to be compliant with the reference model, and receiving system just ignore the value in rc_id, and then generate its own internally unique guid in rc_id attribute.

That's very very interesting - again back to the fundamental in any model design, if it does not serve any purpose, why you should model it in the first place?