Friday, March 30, 2012

Standards based implementation

Yesterday (Mar 29, 2012) I attended Singapore IT Standards Committee (ITSC) plenary meeting at Hotel Fort Canning, at present there were about 10 TC (Technical Committee) such as ADC (Auto Data Collection), Biometrics, Green Data Center and HITC (Health Informatics TC) which I am part of. After the plenary, a pleasant night of beer, food and very enjoyable conversations with standards enthusiasts and practitioners.

During the conversions with the standards enthusiasts, I am extremely shocked at the miserable state of how standards are being applied in Singapore healthcare industry compared with other industries. I asked myself what is the main reason?

Does 'Being standards-based' equal to 'overlooking practical constraints and boil-the-ocean solutions"? What and How that misconception is created in the first place in healthcare industry? How we can make it right?

1) Developing standards is a serious software engineering practice requiring discipline and process

Developing standards is just like developing a software solution, we need to have product vision and long term roadmap, and plan all the efforts (business needs, conceptual design, detail design, implementation, testing, rollout and ongoing maintenance) into each measurable deliverable, it is so obvious to a person with basic software engineering discipline, but the sad truth is that it is not so obvious in healthcare industry,this is the most problematic issue in healthcare. However just take note, the effort I described such as design and implementation are not necessarily just software development, the gist is the engineering process to ensure constant quality deliverable and incremental road map to long term vision realization.

Developing standards is a serious software engineering requiring discipline and proper planning, analyze what's possible and not possible given the current technology landscape and limitation, and make the necessary architecture trade-off, and in the mean time also keep in view o the technology landscape change and user community maturity in order to implement the unrealized strategy and features

We also need to distinguish between 'research' and 'development' types of standards, should have clears strategy to transition 'research' to 'development'.

2) The right talent

Because of the above misconception about standards, the right talent is not recruited and managing the standards development. As more and more 'unqualified' people are recruited and involved in the development of standards, the most obvious outcome we can see is the so-called standards become more and more complex to the point no one can understand what's the real purpose.

This is the typical downward spiral that could happen to every industry.

3) Standards shall be VERB instead of NOUN

Standards is a VERB instead of NOUN - 'standards-based implementation' needs to translate into the action of standardizing instead of producing standards only. Just like what we develop software product? Is it for demonstrating to customers only or delivering features to help customers do their job better?

4) Standards is an ecosystem

If we are developing standards, this point is extremely important. whenever we start to develop a standard, we are in fact trying to create a new ecosystem, so we have to take into consideration the following key stakeholders in the entire ecosystem, and make alignment in early planning phase when defining vision.

  • Standards Development Organization (SDO). HL7 has developed comprehensive healthcare data exchange standards such as HL7v2, HL7v3 CDA etc.
  • National Standards organization (NSO). NSO' s primary objective should be 'evaluate and ratify the suitable standards for use for the nation', and only recommend to develop if there is really no suitable existing standards in the market
  • User community. Evaluate what existing standards they are using and comfortable at this moment, take in their inputs and opinions, choose a standard where the user community is able to adopt it incrementally and equally importantly, it is commercially justifiable and sustainable in the long run.
  • Commercial software vendors. Ultimately what is being used rules the world. So we need to see what these vendors are using. If majority of the commercial vendors are using standards A, and you try to develop another completely different standard, then you already defeat the whole purpose of standards which is to reduce integration cost in the case of data exchange standards, unless you can educate and convince the entire user community, vendor community, and respective government agency.
If we do not take into consideration the above stake holders and with holistic perspectives, it will lead us to the NIH (Not Invented Here) syndrome, and a result create yet another standard. Here I'd like to use the picture from Grahame's following post

Source : What’s a Good Exchange Specification

Sunday, March 4, 2012


An email from one HL7 member wrt to HL7v3 methodology had been spawn into a long discussion and debate w.r.t to "Message" and "Document" again, the intended use and actual use of HL7 CDA, what has been the critical success factors of HL7v3 CDA, and its relationship with FHIR (Fast Healthcare Interoperability Resource) Grahame has started last year out of HL7 fresh look task force initiatives.

We had the same long debate Nov 2011 when a question raised with regard to the use of CDA in IHE Lab.

This time I felt we have at least reached some consensus on HL7 CDA's success factors, and clarified some of the confusions some of HL7 members (including myself) had in the past towards FHIR.

1) What's the success factor of HL7 CDA

The consensus is that the key difference between V3 CDA and V3 Messaging is not that one is about documents and the other is about messages, that's the business side of the equation. But it is the fact that CDA uses a single fixed schema from technical design/implementation perspective, this is really the primary basis for its attractiveness to implementers.

HL7 CDA is "One model and one Schema" with its well-documented templates for the details esp. with the introduction of Consolidated CDA, now it is even much easier to search for CDA templates.

In fact that's also the key messages I have been articulating within HL7 for the need to ensure wire format stability back in 2010

I am not commenting on whether we should keep wire format compatible between CDA R3 and R2, if there is valid technical reason to break the compatibility, then we have no choice even if HL7v3 has promised wire format compatibility.

However what I am trying to say here is the wire format stability/compatibility is extremely import for standards adopters, without stable/compatible wire format, we won't even achieve the basic syntactic interoperability let alone semantic interoperability in the long run.

So if we have to break the compatibility for CDA R3, we'd better think carefully and for the long term, maybe we also should rethink the goal and design approach of CDA, why not we just take out the rending part from XSD and put into XSLT for rending and use the new RIM ITS to provide single unified wire format, we should try to solve the problem once and for all if we have to break the compatibility.

2) What's the relationship between FHIR and HL7 CDA

I brought up the concern that whether we will run into the debate "CDA" and "FHIR" if we do not harmonize the development of CDA R3 and FHIR since I have been hearing that FHIR will eventually render the discussion of "Message" and "Document" irrelevant.

The below messages from Lloyd perfectly stated the differences between HL7 CDA and FHIR, and the benefits FHIR will be bringing to us.

There are a few differences:
- A single RMIM in today's methodology will often break down into multiple resources under FHIR
- There are an unlimited number of potential RMIMs under the current methodology, while there will be on the order of 100 resources defined total

A more apt comparison might be to look at each of the acts and roles on the right-hand side of CDA and consider each of them to be a resource. Rather than having one schema for the entire clinical statement, we now have a separate schema for each of the major pieces of the clinical statement. (In practice there will be more resources than there are acts and roles in the clinical statement because things like lab order & lab result will be distinct resources.)

Another difference with FHIR is that it will generally be possible for implementers to figure out how to assemble resources to represent a particular construct independently in a consistent way without needing templates. That doesn't mean there won't be a need for templates and profiles in FHIR, merely that they aren't as critical to get started as they are with CDA or other v3 models that rely on Clinical Statement and similar abstract structures.

The number of resources comes from an enumeration we did based on all of the domains and CMETs, RMIMs and domains. There will likely be a few more over time, but I'd be extraordinarily surprised if we ever get to 200, even 20 years from now.

The FHIR resources will *definitely* have stability. Grahame and I are debating right now how stable - specifically whether it's possible for extensions to ever move into the resource proper if they become popular. But everything that's in a resource will remain at that same x-path forever.

When resources reference other resources, they do so by internal id. The resources don't actually nest. So the overall schema is just a list of resources - and it will support any and all resources because anyone might use an extension that includes a reference to some resource that wasn't defined as part of the main package. There will be no multiplication of schemas based on the different combinations because all combinations need to be supported everywhere - and that's just an arbitrary list of resources. (Your conformance profile tells you what ones *must* be present for a given scenario.)

I know there's been discussion about using FHIR for CDA R3, and I'm definitely in favor of that direction. I think there are benefits for both CDA and HL7. However, that's a topic for structured docs to decide. The 2.1 decision gives us the breathing room to do a proper evaluation. In any event, I don't think we can brand FHIR as being just CDA. The branding message needs to be inclusive of those who aren't interested in documents (e.g. medical device vendors). Though it's possible that CDA R3 might become CDA FHIR or FHIR CDA or something. (A change in label to signal the change in backward compatibility might be appropriate.)

FHIR carries forward the essentials of CDA:
- Stable XML structure
- One schema for everything
- Ability to send both textual representations and discrete data for the same content
- Partitioning of discrete data into simple constructs (entry = resource, more or less)

It also carries forward some essentials of v2:
- Data structures built from a countable number of standardized structures (you can think of a resource as a segment)
- Message paradigm still supported and works much as it does in v2
- Guaranteed wire format backward compatibility
- Standardized way to communicate extensions

But it fixes some of the issues with CDA:
- Wire format is intuitive to implementers out of the box (implementers don't have to know the RIM or ISO datatypes exist, no structural codes to ignore or get wrong)
- Don't *have* to have templates in order to use FHIR productively
- No need to create custom "intuitive" wire formats per template or per use-case (as is the case with Green CDA)
- Extensibility doesn't require messing around with namespaces or breaking schema validation
- Extensions tell you whether you can safely ignore them or not
- Templates used for CDA can also be used for message, service and REST paradigms (and vice versa) because wire format is identical

And issues with v2:
- Specification doesn't get cluttered up with esoteric use-cases (e.g. the PD1 segment :>)
- Extensions are clearly defined and registered, so no more black-box Z-segments
- You can do XML with tag names that aren't butt-ugly :>
- You can work with a structure that's actually object-oriented

Thursday, March 1, 2012

China started to issue citizen health card

China started to issue health card to citizens, starting with these few provinces - He Nan, Inner Mongalia and Guang Dong.

The citizen health card contains the following information

1) Patient Information
  • Patient Identification
  • Patient Demographic
  • Next of Kin
2) Card Identification Information
  • Basic Card Data
  • Issuing Organization
3) Basic Health Data
  • Vital Sign
  • Immunization
  • Medication Allergy
4) Administrative Data
  • Patient Visit
  • Billing
More can be found at the following site