If it ain't broke, don't fix it

A very long time ago, during the start of my software development carear, I had two quotes from my boss written on the chalkboard in my office at the University.

“	Two rules of software development Just get it to work If it ain't broke, don't fix it.

These became a sort of test for people walking into my office.  If they looked at these two statements and questioned the implications of them on the software generated in that office, they passed. More than 70% of the cost of software is not in the development of it, rather, it is in the maintenance and support of it.  Applying these two rules might get it done quick, but won't result in something that you (or I for that matter) want to maintain.

In the realm of laboratory ordering and reporting, we are in a situation that is the result of applying these two rules.  We have numerous laboratory order and reporting interfaces installed across the country that "work", and since they aren't "broken", there are concerns that we shouldn't be spending a great deal of time fixing them.  This results in debates in the HIT Standards and Policy committees over the need to specify standards now or later, or allow early adopters a "buy" for the first round.

The question is whether you want to drive a more expensive vehicle that is reliable, or if you just want a clunker that spends a good bit of time in the body shop. The just get it to work attitude results in driving around a lot of lemons that have high maintenance costs, but the other approach is expensive in the short term. And if you've already got a lemon that's running, you may not be ready to purchase that new car just yet.  It might require some planning and adjustment, but when that lemon dies, you should be ready to get something that will last.

My thoughts in this are fairly straightforward. 
1.  If it ain't broke, don't fix it. 
2.  When it does break, fix it right, or get a new one that won't break like that again.

The same principle was applied to Federal Health IT infrastructure under the Bush administration via Executive Order 13410, and should be applied to laboratory standards for meaningful use.  In essence it says that new, upgraded or newly developed HIT, use the recognized standards.  Basically, if it isn't being replaced, don't change it.  I know, telling this adminstration to pay attention to what the last one did probably won't fly, even if it was a good idea.  So, instead, look to what section 13111 of ARRA has to say about federal spending on HIT.  What's good for the gander in this case, should be good for the rest of the geese.

If a provider has a working electronic laboratory interface, let it count for the first two years, but ensure that they are planning to update it to support the required standards by 2013.  That will avoid unnecessary expenditures on fixing what "isn't broken", but it will also indicate that we are serious about the use of standards.  It won't leave early adopters out in the cold over what is needed for laboratory interfaces.

Laboratory results are very important in quality measures and clinical decision support.  Avoiding standardization of the laboratory results interface will delay other factors of meaningful use that aren't being debated.  So, it's important to push for standardization and make it clear that we will move forward.

One of the key features of CDA that makes it so implementable is "incremental interoperability".  Let's use that principle for laboratory interfaces as well.

Vocabulary

Healthcare IT products need to deal with terminology for ICD-9-CM, ICD-10-CM, ICD-10-PCS, SNOMED-CT, RXNORM, LOINC, NDC, CPT, HCPCS, UMLS, the Healthcare Provider Taxonomy and a number of proprietary vocabularies as well.  Most of these use different file formats to exchange the data about the vocabulary.

What I'd really like to see is everyone use standard format to exchange this information.  Preferably I'd like that format to be XML-based to make it easier to process.  But I'd also like that representation to be fairly compact, so I might be able to live with a text delimited format.  I can readily create an XML reader that will import common text delimited formats in an XML document for processing, so it's not a huge problem if the format isn't XML-based.

Finally, I'd like everyone to agree on some very common concepts (e.g., "is a") that need to be expressed so that these concepts have the same meaning across terminology.  Ensuring that we have a set of commonly accepted (standard) relationships will certain help us get to a point where we can reason across terminology boundaries.

The US Federal government is responsible in some way for maintenance, delivery or mandated use of some of these vocabularies (RXNORM, UMLS, ICD-9 and 10 variants used in the US, NDC, HCPCS and the Healthcare Provider Taxonomy), and yet almost all of them require different file formats for distribution.  It's what I've come to expect from my government, but I wish it would stop.  At least the work done by NLM (RXNORM and UMLS) have a common file format.  The Rich Release Format is used for both of these and uses | as a text delimiter to separate columns.  In fact, it might even be worthwhile to have a number of SDOs get together and agree to use that format (or perhaps a modification of it) to deliver vocabulary information.

Some of the vocabularies I mention are published in books with a lot of ancillary material that should also be part of the downloads.  For example, the ICD-9-CM vocabulary contains a rather large index which is incredibly valuable, along with a number of inclusions and exclusions.  But to really make good use of the vocabulary you need the data associated with these additional parts incorporated into the downloads.

Finally, I'd like to see some of the hierarchical relationships in some of these terminologies be formally expressed within them.  LOINC for example, contains numerous concepts describing clinical documents, but the LOINC data itself doesn't actually include some of the important relationships between the different types.  For example, the Admission History and Physical Note (47039-3) doesn't show up as being related in the document hierarchy with the Cardiology Hospital Admission Note (34094-7).  The same is also true for relationships between the various laboratory results. 

As we in the US continue to talk about simplification and debate some of the really hard IT topics, this seems like a really simple problem to solve that could be addressed with just a little bit of the right attention.

Healthcare IT Standards and General IT Standards

A recurring theme of this blog is using the right tool for the right job, and is one of my father's favorite aphorisms.

I am struck by the number of times that I hear others discuss healthcare standards problems as if they are different from problems that others in the IT field have addressed.  The current case has to deal with modeling of consents to share or release private information for use by others.  This is NOT a healthcare specific problem, it appears in multiple business contexts (e.g., credit reporting and credit checks).  It should be a matter of profiling appropriate industry standards (and I admittedly don't know which those would be, nor do I have a personal preference) to use appropriate healthcare terminology (regarding occupation and licensure, healthcare specific purpose, et cetera).

For some reason though, there seems to be this need to apply HL7 modeling to this problem (and perhaps every other problem encountered in the healthcare context).  The HL7 RIM is extraordinarily powerful and you can model almost anything you want with it.  I know, I've modeled 100 bottles of beer on the wall with it to teach RIM modeling for Claims Attachments.  Does that mean it should always be applied?  In this particular case, I'm not certain that it should.

This particular issue is a general problem that should have a general solution available from the IT space.  It just needs to be customized to address  healthcare specific issues.  If it was correctly modeled to begin with, that should be a straight-forward prospect.  If not, then it seems the right answer might be to go back to those bodies and get them to fix it rather than perpetuate the proliferation of perplexing products purported to puzzle out the problem.

I think that there are two issues here:
1. Using a solution provided by someone else isn't necessarily sexy or cool. 
2. Inventing new solutions provides product or consulting opportunities.
Neither of these is a requirement.  I want solutions, I want them to be commercially available and easily integrated into my current suite of tools.  Ideally, I'd like it to be something I can buy a book on or take a class on, and a skill-set that I can hire for from the existing pool of experienced IT  people. 

To be fair, using solutions built by others is hard, and building it yourself always seems to be easier, better and/or faster.  You have to read all the existing work and understand it, and apply creativity sometimes.  But the people building standards for healthcare are bright people.  I expect them to be able to take on that task.  On the easier/better/faster to build it yourself, well, most of the time, that's just an illusion.  Yes, what you do may be easier/better/faster, but does it really provide enough incremental value to justify all that work?  You could be spending your time on harder and more interesting problems that are much more valuable to solve.

I'm all for standardization, and I like HL7 and all the rest ..., but frankly I'd rather go to a mechanic when my car is broken than a doctor.  They charge better prices and the problem seems to stay solved longer.

UTC in HL7 Version 3

The timestamp data type is used in a variety of standards to mark the time at which an event occured.  Most standards (including HL7 Version 3 and W3C XML Schema) rely on ISO 8601 as the base standard which is then constrained in different ways.

Marc de Graauw asked a question about how one would represent Universal Coordinated Time using the HL7 Version 3 standards (see How to express UTC time in TS).  I did a bit of research on this and was somewhat amused with my findings:

The HL7 V3 Datatypes schema allows [0-9]{1,4} for the pattern following the + or - so that doesn't help much.

Section 4.2.5.1 of ISO 8601 states:
When it is required to indicate the difference between local time and UTC, the representation of the difference can be expressed in hours and minutes, or hours only. It shall be expressed as positive (i.e. with the leading plus sign [+]) if the local time is ahead of or equal to UTC of day and as negative (i.e. with the leading minus sign [–]) if it is behind UTC of day. The minutes component of the difference may only be omitted if the time difference is exactly an integral number of hours.

The key phrase ahead of or equal to UTC indicates that +00 or +0000 are the only ways to represent UTC other than Z. I know that zero is neither positive or negative but those terms are in reference to the leading + or - sign. The statement "equal to UTC" is what makes the point, which means that -0000 isn't valid (according to 8601).

Standards using 8601 disagree: 
The W3C use of 8601 in XML schema recognizes +00:00 -00:00 and Z as legal representations of UTC, with Z being the canonical representation. See http://www.w3.org/TR/xmlschema-2/#dateTime

Abstract Datatypes Release 1 and 2 say pretty much the same thing for the literal form of a time stamp:
In the modern Gregorian calendar (and all calendars where time of day is based on UTC), the calendar expression may contain a time zone suffix. The time zone suffix begins with a plus (+) or minus (-) followed by digits for the hour and minute cycles. UTC is designated as offset "+00" or "-00"; the ISO 8601 and ISO 8824 suffix "Z" for UTC is not permitted.

The ITS: XML Datatypes, Release 1 specification has nothing to say other than by reference to Abstract Data types.

Pragmatically, any user of HL7 V3 schemas should recognize any of +0, -0, +00, -00, +000, -000, +0000 and -0000 as a UTC time zone, but should only record UTC as +00 or +0000 (my own preference). These are all legal representations of time zones using the HL7 TS data type according to the (non-normative) schemas provided by the XML ITS.
So, there you have it.
 
Keith
 
P.S.  This is book fodder...

Don't Panic

DON'T PANIC

Unlike the Hitchhikers' Guide to the Galaxy, the HITECH ACT of ARRA does not contain the words "Don't PANIC" printed in big bold text on the front cover, but it should. 

The HITECH provisions describing meaningful use are principally concerned with motivating healthcare providers to use electronic medical records wht the anticipated goal of reducing the costs of care. They do so through INCENTIVES.  See the definition below from wiktionary for the term:

incentive (plural incentives) Something that motivates, rouses, or encourages. I have no incentive to do housework right now. A bonus or reward, often monetary. Management offered the sales team a $500 incentive for each car sold.

As we all anticipate the pending regulation my current frustration is with various people who are panicing about there being "too much, too fast" for providers to adopt, or that the standards are not ready.  If the standards aren't ready, then how is it that 47% of the hospitals responding to the AHA Most Wired survey are already able to support CCD, or that 84% of the most wired can (see Connecting all Your Docs)? 

HITECH is nothing like HIPAA in what it requires of providers.  HIPAA regulation basically stated that you had to use certain standards if you wanted to use electronic claims transactions, and that you had 2-3 years to do it, and there was no money from the Federal government to help it along.  HITECH basically says that if you want to recieve incentive payments, then you have to do certain things over five years, and you'll be ahead of the game, and after five years, there will start being penalties for non-conformance.

Yes, this results in a great deal of craziness as everyone tries to ensure that they get as big a piece of the pie as they possibly can.  But...

If you aren't ready, slow down.  The world won't end tomorrow (or in the next two weeks), nobody is poised to bulldoze your practice.  You have some time to make reasoned and good decisions.  The incentives are structured so that the biggest payouts will be in the first years of technology adoption.  Waiting a little bit won't cut a huge chunk off the potential incentives you can recieve, just read Page 354 of ARRA.  In fact, you'll see that waiting a year (being a meaningful user in 2012) is just as good as starting in 2011.

That doesn't mean I don't want you to start now, because I do, but do so in a thoughtful way, and if you need more time, by all means take it.

What I want for Christmas

From HL7:  A new ITS that makes it easier to implement Version 3 specifications and a US Realm.
From W3C:  A binary XML that reduces the footprint of XML on the wire and an updated Schema specification that enables HL7 to build that new ITS.
From HITSP:  A week or two off and some infrastructure to build better specifications.
From IHE:  Actually, I think I've gotten that one already, a full slate of active leaders in PCC.
From ONC:  Some forethought and an RFP to continue the standards harmonization process that includes some of the other streamlining of standardization that I've asked for.
From ISO and the US TAG:  Some time to play in that sandbox.
From NIST: Open sourcing of validation tools.
From a book publisher: A contract.
From Congress:  Health Reform

What I'm giving for Christmas:
To HL7: Some easy ballot comments to address.
To W3C: Feedback on that new Schema specification they have.
To HITSP: 25 hours a day.
To IHE:  Antepartum Workflow Draft -- Really, I promise this time.
To NIST: Comments on testing tools.
To Congress:  A new senator.  It'll be a little late, but...

It's just a short list really, and I've been such a good boy...

More on Language

This time the issue is inclusive language.  Several times over the past two days I've been involved in various discussions around standards around that particular topic.

Several readers complain that a given specification hasn't listed a given profession, care activity, or other detail pertinent to a specific job function in a list that's clearly marked as being an incomplete set of examples.

Other comments indicate that certain types of documents should be included in such a list of examples.

A specific example in one document is faulted because it uses a concrete term in a detailed example, indicating that the example need not use THAT concrete term, and could use others.

In another case, we are asked to rewrite requirements coming from a third party to incorporate those necessary for a specific type of product.

I have three ways to deal with these issues:
1.  Ensure example lists are clearly marked as examples, using terms such as for example, e.g., or "as in the following incomplete list".
2.  Point out to the commenter that a specific example is being given that doesn't indicate preference for any given concrete term.
3.  Add the suggested term to the list, or find another change that can be made to make the commenter happy.

In all cases, these discussions and the resolutions:
1.  Do not impact the normative text of the document (what needs to be implemented in the specification).
2.  Make the reader with a specific focus feel as if their concerns are addressed.
3.  Consume time.

It's a frustrating balance.  The end result is a document that will please a wider audience, at the cost of time.  I continue to remind myself that making readers happy is an important component of getting specifications read and understood.  It is amazing what inclusive language can do for a reader, even though in the end, it may not change anything required by a specification (the specifications usually already support the given requirement).

I'm defining the terms clinician, healthcare provider and provider organization in my book right up front because I want everyone to understand what I'm saying and why there is a need to distinguish between these three entities.  I'm even having to deal with comments from reviewers on that language.

“	Oh Lord, give me patience, and give it to me NOW!  -- Unknown

On Language and Standards

“

‘When I use a word,’ Humpty Dumpty said, in a rather scornful tone, ‘it means just what I choose it to mean, neither more nor less.’ ‘The question is,’ said Alice, ‘whether you can make words mean so many different things.’ ‘The question is,’ said Humpty Dumpty, ‘which is to be master – that’s all.’

As someone who participates in the activities of multiple standards bodies and reads standards published by even more, I am often having to jump between different viewpoints of the world.  If you've studied the dynamics of organizations, you understand that they go through several phases (all of which are necessary), including storming, forming, norming, performing and reforming.  The norming stage includes agreeing on a common language to describe things.  The last few days have highlighted the importance of language: 

• I need to be able to express something in the language of people in a particular role that I'm not familiar with so that they can understand what I'm saying.
• I explain that training that I provide is customized to the audience, so that if the class is filled with one set of students, it focuses on their higher level concerns about clinical content, and with another set, on theirs, which is focused on the pointy brackets of the XML.
• I'm engaged in a discussion with a participant about the differences between the language they are using and the norms of the group they are communicating with.
• I'm looking to simplify the language used in a specification so that what is being said can be written in a sentence that can be understood by three different audiences with very different languages.
• I'm battling over the use of terms that are being defined by a group that are at variance with common definitions of those terms used elsewhere.

One of the most time consuming aspects of standards development is in indentifying definitions of things (note that I said identifying and not creating). Definitions are important. They provide the "white lines" that many are looking for to understand the boundaries of a thing. Many times it is the least productive, because nobody can agree on a single definition. This inspires what I consider to be unnecessary invention of new terms to which people can agree on a definition for because they are describing something new rather than trying to fit it into what is already known. This results in needless explanation of new terms that are really reuses of old things in new contexts, and a lot of translation and cross walking between concepts.

Because my mind is on the topic, I spent a few minutes writing up some of what I consider to be best practices around language used in standards:

As a participant in an SDO or Profiling Organization:

1. Keep it simple.  The more complex a definition is, the less likely that the term it defines will be readily understood. 
2. If you need to give something a name, make it a name that can be interpreted from the words in it without a definition (but still define it), or better yet, use a term that has a definition that suits, and cite your reference. 
3. Use readily available and well recognized sources for definitions of terms.  I happen to prefer dictionaries like Websters or the American Heritage Dictionary as my source of definitions, or when necessary, dictionaries of computer terms, and lastly definitions created by well recognized organizations with broad participation rather than those that are specific to a single field of practice.
4. Keep sentences simple and understandable by as broad a group as possible.  Remember that your audience likely contains the top-most C-levels of an organization right down to the recent college graduate responsible for implementing some portion of a system. 
5. Avoid use specially coined terms that will be recognized and properly understood only by someone who has been participating in your organization for years (the phrases "class clone" and "transaction package" come to mind).  This is especially true in material that someone outside your organization needs to understand.
6. Do create a glossary of technical terms that provides definitions and cites references to help new members.
7. Avoid creation of new acronyms.  These are the least comprehensible to someone outside your organization.
8. When you find cases where a different understanding terms results in different meaning, make sure you clarify it in what is published.  If it took your group an hour to resolve issues that result from different understandings of the term, don't assume that your readers will automatically have the same understanding of those terms when you publish.
9. Provide real-world examples.  They are often the simplest way to express what is happening in ways that everyone can relate to.

As a new participant in and SDO activity:

1. Ask for the glossary of terms.
2. Ask for definitive references and resources.
3. Try to understand the terms being used by the group using the group norms instead of your own, but also...
4. Ask for clarification when you don't  understand a term or acronym.
5. If you find yourself disagreeing with a statement, see if the source of the disagreement is in your understanding of the terms used in the statement.  So many times I've seen the reconcilliation of a disagreement resolved by ensuring that everyone has the same understanding of the terms being used.
6. Ask for a real world example.

I'd love to see the various SDOs and profiling organizations to individually agree on a set of definitive published reference works that they will use and cite for definitions.  If we could get them all to agree collectively on these references, I'd be even happier.

A Canadian Perspective on Standards Harmonization

Today I have a special guest post from Mike Nusbaum.  Mike's a great guy and knows quite a bit about participating in multiple standards organizations.  He has been in leadership positions to my knowledge in ISO TC-215, HL7 and IHE, and also facilitates and writes for ANSI/HITSP here in the US.  Mike helped establish the Canadian framework for standards harmonization, and I asked him to write a guest post on the topic.  Here's Mike:

Guest contribution by: Michael Nusbaum, BASc, MHSA, FHIMSS

(a Canadian healthcare IT consultant who also works with HITSP in the US)

A Canadian Perspective on Standards Harmonization
As the US health reform freight train continues to roar down the tracks, the IT standards imperative becomes increasingly critical.  The government's well-funded priority to stimulate reform through the establishment of an interoperable nationwide health information network (NHIN) has put incredible pressure on standards harmonization activities over the past 6 months. Clearly, interoperability is achieved through the implementation and use of standards, and funding directed towards state and regional health information exchange (HIE) initiatives is contingent upon the adoption of those standards within all stakeholder communities.

Keith has written extensively in the blog about the fractured system of standards development and maintenance in the US, and despite incredible progress over the past 3 years towards harmonization, there is still so much to be done. Standards, of course, must be developed and used in a global context, as no one country [not to mention a large multi-national vendor community] can afford to tackle this alone.  That's why standards organizations like ISO/TC215, IHE, HL7, IHTSDO and others are all focussed internationally, while required to co-exist and link to initiatives being undertaken domestically (ANSI/HITSP, CCHIT, US/TAG, etc.).  In the US, there is no "umbrella" to formally coordinate domestic and international efforts.

As a Canadian who is also working extensively in the US healthcare IT community, I have had a unique opportunity to become involved in the governance and management of standards development/maintenance in both countries.  While I normally stay quiet on Canadian successes (and failures) with my US colleagues (respecting the need of each country to undertake their own voyage of discovery), there has been a recent flurry of enquiries asking the question "how does Canada do that?".  One of these enquiries recently came from Keith, who asked me to respond to his recent Call to Action posted to his blog last summer, describing the need for the US to not only harmonize standards development, maintenance, certification, vocabularies and implementation support... but to also harmonize governance through the establishment of some kind of "national organization".

[OK, here it comes...]  In fact, Canada has done exactly this, with the establishment of the Standards
Collaborative that operates under the custodianship of Canada Health Infoway (the not-for-profit corporation that has been empowered by Canada's federal and provincial governments to coordinate and fund e-health initiatives). I was fortunate to have worked with Infoway a few years ago on a consulting contract, and was one of the team that developed and implemented the Standards Collaborative.  At the time, it was a radical concept to bring together all standards organizations operating in Canada, and link these to the standards development/maintenance activities that were being undertaken by Infoway to facilitate the interoperability of the national EHR "infostructure".  Now, some 4 years later, the Standards Collaborative has proven to be a model that has really worked well towards harmonizing standards (and by extension, interoperability) activities in Canada.

I won't repeat all the information that can easily be found online (e.g. see this fact sheet), except to say that just about all of the former, fragmented, standards organizations and initiatives have been brought under the Standards Collaborative "umbrella", which now includes HL7-Canada, ISO/TC215 Canadian Advisory Committee, IHTSDO liaison, DICOM liaison... and soon to be IHE-Canada).  Each of these "constituencies" operate in concert with one another, and while governance is harmonized, each constituency has a "head of delegation" supported by a SIG-like interest group.  The big benefit is the communication and harmonization between all of these initiatives, as well as a cohesive Canadian presence both internationally as well as domestically.  The "clients" (jurisdictions, health authorities and vendors) find this consolidation to have removed one of the most significant barriers towards the adoption of standards and the implementation of interoperability.

Would this work in the US?  Definitely.  However there must be amassed a significant and trusted leadership (like Infoway has done in Canada), together with a fair amount of political will (which ONC is in a good position to provide, I expect).

As I continue to monitor the evolution of the healthcare IT reform agendas in both countries, I will most certainly respond to any questions (like Keith's request) that foster more synergy between the US and Canada.  Those of you who were able to attend the recent Canada-US "HIE Summit" in Philadelphia were able to observe first-hand the tremendous bi-lateral potential of such synergy.  I remain optimistic.  If anyone is interested in an offline conversation about this, you can contact me at michael@mhnusbaum.com.


Thanks for the opportunity to weigh in on this, Keith!!

-- You are welcome Mike, and thanks for taking time to do it!

SAEAF Revisited

You may recall this box from Demystifying SAEAF ...maybe



Well, I joined a telephone call and web exchange with a number of really bright people who are, like me, still confused about the HL7 Services Aware Enterprise Application Framework or SAEAF as it is known in HL7 circles.

We spent a good bit of time working on the "elevator pitch" about SAEAF.  What we came up with was the following:

“	SAEAF provides a framework for specifying how HL7 products integrate and function from different viewpoints and levels of abstraction. When HL7 products agree upon common viewpoint and abstraction details, they can be used together.

SAEAF needs to be looked at not from the perspective of one HL7 Standard or work product, but from the viewpoint of the HL7 work products as a whole.  Think about each of the edges of the box as parts of a LEGO^® block. A correctly designed HL7 Enterprise Architecture will use common measurements for the connectors that allow each of the blocks to snap neatly together. This illustrates the concept of conformance to the architecture. It requires that we have some ability to test conformance and measure how well different HL7 products stack up against each other.