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.