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