Standards Conformance Terminology across IHE, HITSP and HL7

One of the discussions the HL7 Structured Documents Workgroup held in Sydney was with the HL7 Conformance committee.  The topic of discussion was use of conformance terminology, and was applicable to the HL7/IHE/ONC consolidation project.  The results of the discussion were recorded on the HL7 Wiki.  The first part of what was written is pretty much dead on.  The R2 = Should in IHE requires some clarification.

If you haven't already, you MUST become familiar with RFC 2119.  This is the standard for standards makers on the use of the terms MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL.

The HL7 Publishing Facilitators Guide uses a subset of these terms: SHALL, SHALL NOT, SHOULD, SHOULD NOT, and MAY, and adds NEED NOT as the alternative for MAY stated in the "optional negative sense".  The subset is based on discussions of terms that needed to be used according to HL7 interpretation of ANSI rules.

IHE and HITSP use the terms SHALL, SHALL NOT, SHOULD, SHOULD NOT, and MAY most often and in the way that they are defined in RFC 2119, but make no direct reference to these terms.
 
HL7 uses the terms mandatory and required in HL7 Version 3 modeling, and in conformance statements.  Mandatory means that a data element in a message or document SHALL be present and SHALL not be empty (or contain an exceptional value or nullFlavor [all of which are essentially the same statement]).   Required means the a data element in a message or document SHALL be present, but MAY be empty (or contain an exceptional value or nullFlavor).  In tabular form, these are often shortened to M and R.  Data items in an HL7 model are always at a level no more granular than the HL7 data type or class contained in the model.  So, HL7 conformance statements using Mandatory/Required don't talk directly about the XML produced, but only do so through implication and application of the XML ITS.  Structured Documents CDA implementation guides have transitioned to talking about the XML being produced, and have conformance statements on the XML element content and sometimes the XML attributes.  I find this preferable from an implementer perspective because it addresses what needs to appear "on the wire", and that is where interoperability is most dramatically apparent.  The shift from HL7 class and class attribute dotted notation (e.g., ClinicalDocument.code) to XPath expressions (/ClinicalDocument/code) was subtle but powerful shift that made the guides  readily understood by XML aware implementers.

IHE also uses the terms Required (R), Required if Known (R2), Conditional (C), and Optional (O) in its specifications.  Required if Known is a special sort of conditional that means "if you have the data, you SHALL send it."  The use of term R2 comes from the DICOM standard which has a "Type 2 Required Element".  From Section 7.4.3 of Part 5 of DICOM standard:
IODs and SOP Classes define Type 2 Data Elements that shall be included and are mandatory Data Elements. However, it is permissible that if a Value for a Type 2 element is unknown it can be encoded with zero Value Length and no Value.
The Type 2 Required element in DICOM is most like Required in HL7 Version 3 modeling.  BTW:  DICOM uses Mandatory in much the same way that HL7 V3 does.

When applied to templates created by IHE PCC, R is identical to the use of SHALL requirement [an item using template X SHALL be present], and R2 most closely interpreted as SHOULD [an item using template X SHOULD be present], but the approximation is not exact.  Realistically, it means that if you capture the data, you must send it, but there is no requirement that you must capture the data (see HL7 V2 discussion of RE below).  If the section is not present, IHE does not require you to send an empty length section, instead you simply omit the data.  From a testing/conformance perspective, what I'd like to see for all R2 constraints on document sections is that Document Creators must either demonstrate the ability to create the content, or state clearly that their product does not capture the data and therefore cannot send the information.  Note that IHE PCC has no requirements on document consumers with respect to what they do with the data, so there is no specific requirement that a document section be dealt with by the receiver in the IHE profiles.  As Kevin Coonan pointed out to me in a side channel discussion on todays Consolidation call, the IHE PCC R2 is a dynamic, rather than static conformance criteria.

HL7 Version 2 has a set of conformance abbreviations it uses on fields described in a conformance profile. In addition to Required (R), Conditional (C) and Optional (O), it has Required but may be Empty (RE), and Conditional but may be Empty (CE).  RE in HL7 V2 and R2 in an IHE profile have nearly the same meaning, but HL7's definition for RE is stronger.  It indicates that an application MUST have the ability to send something in a field using RE in a conformance profile, while IHE PCC's use of R2 is a little weaker.

In profiling HL7, IHE sometimes uses R+ as well to indicate things that IHE has made Required which HL7 said were optional, just to make our lives a little easier.

I hope that clears things up about the current state of affairs.

Frankly, I prefer SHALL, SHOULD and MAY, because all of these shortcuts make it a lot harder to understand.  Later profiles in IHE PCC created after the great R2 debate of a couple of years ago (initiated by HITSP and spawned through IHE and HL7).  It is apparent after discussions with HL7 conformance that the discussion is not yet over, and that IHE will need to review its use of R2 in existing final text PCC profiles (XDS-MS, EDR, and XPHR) to ensure that we clearly capture the intent of the committee as it stood at the time the profile was created, and appropriately clarify its terminology. The Consolidation project will capture the intent as we move forward on those final text IHE profiles which become part of the work.

I'd also enjoy seeing a reference to RFC 2119 be used in IHE, and HL7 (although that is a losing battle, as the current terms are hard fought based on HL7 perceptions of ANSI rules).

In almost all of this discussion of conformance constraints, I have been talking about sender / creator responsibilities, and not about the receiver responsibilities to do something with the data that is sent to it.  This is mostly because many of us can imagine some very innovative ways for a receiver to do something with just one tiny bit of the message that we don't want to prevent by requiring the receiver to do anything more than accept a valid message.

     Keith

Triplets

@motocycle_guy: @omowizard An archetype, a DCM and a template walk into an #HL7WGM event, stroll up to the bar ... and the bartender says...


@omowizard: @motorcycle_guy ...identical triplets I presume! #HL7WGM

Well, not quite identical, but certainly they share the same parents, intellectually at least.
 
From the HL7 Perspective:
A Detailed Clinical Model is an information model of a discrete set of precise clinical knowledge which can be used in a variety of contexts. (see the HL7 Conceptual Definition).

 
A Template is a collection of contraints that can be applied to a model [based on a pronouncement by LLoyd McKenzie at the last MnM/SDWG Meeting of the day, so it must be true ;-) ].  It's also defined in nearly the same words in the HL7 Templates DSTU:  A template is an expression of a set of constraints on the RIM or a RIM derived model that is used to apply additional constraints to a portion of an instance of data which is expressed in terms of some other Static Model.
 
Given that the HL7 process works via refinement on the RIM, a Detailed Clinical Model is a refinement of the RIM information model providing a discrete set of precise clinical knowledge...
 
Which makes it an expression of a set constraints on a RIM derived model, which makes it a template.
 
Now, quoting from the openEHR perspective (see page 8 of Archetype Definitions and Principles [pdf])
 
An archetype is a computable expression of a domain content model in the form of structured constraint statements, based on a reference (information) model.
 
And, a template is: a directly locally usable definition which composes archetypes into a larger structures often corresponding to a screen form, document, report or message. A templates may add further local constraints on the archetypes it mentions, including removing or mandating optional sections, and may define default values. 
 
But, an openEHR archetype is further specified: openEHR archetypes are based on the openEHR reference model.
 
So, an HL7 DCM is an archetype, but not an openEHR archetype because is derived from the HL7 Reference model rather than the openEHR reference model (and I think a blog post comparing the two is worth doing).
 
And an openEHR notion of a template is a collection of constrainsts on screen forms, documents, reports or messages, which means that it is a subset of HL7 templates.  What an openEHR template doesn't include are the set of constraints which make up the detailed clinical model (which HL7 could also express as a template).  These are what we would call document or section templates in HL7 or IHE, and the "DCMs" are what HL7 IHE would describe as a deeper refinement of "Entry Templates" on CDA.
 
The amount of precision in these fine distinctions is about as useful as trying to cut butter with a lazer.  It may be very precise, but all it really does is get in the way of breakfast.  But, as @omowizard points out, it didn't get in the way of dinner.
 
So, how do we take the collective intelligence of these two organizations forward.  I would propose a trial project covered by an MOU between the two organizations.  Let's have openEHR provide resources to help HL7 put together DCMs for some stuff, and then, using the outputs of that, have HL7 ballot the materials as a DSTU which would be shared content across both organizations.
 
That's liable to get me some strange looks in certain circles, especially back in some camps where openEHR isn't even mentioned and the great evil is that other XML perpetuated by yet another organization.
 
But what can I say?  We've already learned so much from CCD, let's give it another go.  After all, if the project fails, we've lost little, and if it succeeds ...

Tactics for Standards Setting: Lead, follow, or get out of the way.

“	Lead, follow, or get out of the way. -- Thomas Paine

I have to make up my travel budget annually every December/January.  In order to do so, I have to look at the overall strategic picture for standardization, and then pick the tactics that I think I will use.  Having chosen the tactics, I can plan my movement orders to match.

One of the things that I learned about 5-6 years ago from a colleague in the Healthcare standards space is what the tactics are.  They fall into 5 categories, each with different degrees of effort required:

1. Ignore
2. Monitor
3. Contribute
4. Lead
5. Kill

These tactics are applicable to any industry, not just healthcare.  Let's look at them in more detail.

Ignore
Tactics in this category include: 
If I pretend it doesn't exist, maybe it will go away. 
This is the Ostritch method, or the stick my finger in my ears tactic (nyah, nyah, nyah, I can't HEAR YOU....).  It only works if I can successfully ignore the standard and convince others that I don't need to pay attention to it (but see kill below).
I can simply ignore that at it is not relevant to me. 
This is easier.  If I never build a product that will use that standard, and it will never impact me, I can also ignore it.  I might want to pay attention from time to time to see if they've done anything I can learn from, but realistically, this is simply not my problem, or anyone else's that I deal with.
This is John's problem, not mine.
Or Harry's, or Charles', or whomever.  This is a delegation tactic.  DICOM is not an area in which I have expertise, so I let others deal with it.  As a friend of mine says, 'I put a "not-my-problem field" around it and it simply goes away.'  But, first I have to trigger the field, and thats where the delegation part comes in.

Anything in this category gets no travel time allocated, and little if any effort.  It does require a VERY small amount of monitoring, to see if tactics need to change.

Monitor
The principal tactic in this category is listening.  That may be monitoring e-mail or RSS feeds, or paying attention to what others are saying.  That's why I want an RSS feed for new projects from all the SDOs, so I can better monitor what is going on.  For now, I stay on several e-mail lists to keep up with what's going on.  I can also expect to get a heads up call from my network if something comes up that I might be interested in.   In the same vein, I also make sure to contact those I know when I see something coming up that might interest them.  Developing your network is one of the very best ways to increase your bandwidth in managing standards.

Monitoring implies that you have a process for review and escalation if your tactics need to change, so I try to keep enough in the kitty for one unplanned trip.  Monitoring can take from 2-5% of your time

Contribute
Contribution can include comments on listserves, participation in discussions and t-cons, engagement in meetings, or providing feedback during voting / balloting, or providing text.  The level of engagement depends on A) your level of trust in the process to move forward without you, and B) the amount of influence you want to have in the end result.
Contribution can take 5-15% of your time depending on the level of engagement.  I often have to allocate travel to activities that I'm going to contribute to.

Lead
Lead can also be at various levels.  You can lead a project as editor, cochair a workgroup, or become a member of the organization's board.  One of the nice things about editing a standard is that about 80% of what you write goes uncontested.  The remaining 20% is stuff that you wind up having to fight for, and probably half that is not worth the effort if you can have a good consensus group.  Leadership can be a valuable position to be in, but is also very effort intensive, requiring about 10-25% of your time.  It almost always involves travel for me, usually a week or more.  My leadership position in HL7 requires me to travel about 4 times a year now, and in IHE, 6 times.

Kill
Not all standards efforts are good ones.  Some deserve to die.  Failure to recognize that or acknowledge it is not an option.  Since most standards are good, the general perception is that all standards are good (the fallacy of hasty generalization).  As a result, killing a standards effort is often the hardest to accomplish, and should be undertaken rarely.  You can spend time, effort and most importantly, credibility on this sort of effort, and they don't always die easily.  Sometimes you'll think you put the last nail in the coffin, and it simply crops up another way.  Been there, done that, and there are people who still won't talk to me as a result.

I'll note that it is far easier to divert a punch or kick than it is to stop it.  I much rather use diversion tactics than head on ones when I can.  Another point is that it is far easier to generate change from within rather than without.  I tried making CCR better before I tried to oppose it, and it was only when the former was unsuccessful that I did the latter.

You cannot go this route alone.  You usually need partners outside your organization to help you.  Effort is always high, but travel varies.  Sometimes you need as much travel as leading, and other times, as strong as monitor.

There are a few different ways to kill a standard:

1. Ignoring it (this works if only everyone in the industry does it).  Microsoft tried this with XSTL but eventually had to put support in Internet Explorer.
2. Pre-empting it with something better.  HL7 tried this with the Care Record Summary and put a big dent in the ASTM Continuity of Care Record.
3. Replacing it with something better.  ASTM and HL7 produced CCD which effectively did in the Care Record Summary.
4. Confusing the space with multiple versions.  So now there is a Care Record Summary Release 2, which works somewhat differently than the IHE XDS-MS and the HITSP C48 specification.
5. Introducing unimplementable features and/or scope.  This is hidden as a contribution and fails the test of transparency.
6. Delaying a standard.  Negative ballots can take quite some time to reconcile.  ANSI and ISO rules require that all negatives be addressed, so you can stretch out the process, or retain your negative vote requiring an administrative process to resolve the issue.  I'll continue to work with a committee on a negative ballot as long as they want.  But I will rarely try to stretch the process out on my own, as the test of transparency fails there.  I recall one HL7 ballot that went a year.  The committee didn't contact me for 6 months, and then we spent another 3 months before they eventually "voted my comment non-substantive."  As is my right, I retained by negative and they had to go through another ballot process to pass.
7. Reducing the level of impact.  An informative document in HL7 usually has less "credence" in the industry than a normative standard.  Similarly, a white paper in IHE is not a profile that gets tested at connectathon.  Sometimes you can scale back the effort to be less intrusive.  This needs to be done sooner rather than later.

One of the principles that I use when engaging in the "Kill" effort is to be open and transparent.  Efforts at standardization need to be creditable.  If you engage in nasty tactics and aren't open about what you are doing, it can come back to haunt you.  One of the "old sayings" where I work is "Never do anything you wouldn't want to see reported on the front page of the New York Times".  That's what I call the test of transparency.  The report might not even be the NYT, it could just be the committee list serve.

The best time to kill a standard is in the early stages, during processes to evaluate the project.  Some organizations are better than others at not starting projects that aren't valuable, and others will adopt anything that is staffed.  Even then, it is difficult because standards organizations don't want to alienate those who are willing to contribute.

So, there you have it.  Lead, follow, or get out of the way.

Call for Participation to the ONC S&I Framework and three S&I Initiatives

I'm stuck in LA for a day waiting for my plane to be fixed along with several other HL7 members on our way to the Working Group Meeting meeting in Sydney, Australia. While I'm waiting, I found this in my mailbox from Arien Malec, who led up the Direct Project...

 

I plan on participating as a committed member. I hope my colleagues in the US do as well.

 

    Keith

---

Greetings to the Direct Project Participants,

 

Because the Direct Project has not been nearly enough work, this is an invitation to participate in the Standards and Interoperability (S and I) Framework. The S and I Framework is launching today, with Calls for Participation for three initiatives (defined below) starting today and closing on January 28th. The S and I Framework is sponsored by the Office of the National Coordinator for Health Information Technology (ONC), through the Office for Interoperability and Standards (OIS).

 

For details about the upcoming S and I Framework Initiative Kick-Off Call, please visit the S and I Framework Wiki at http://wiki.siframework.org/

 

What is the S and I Framework?

 

The Standards and Interoperability (S and I) Framework is an investment by the country in a set of harmonized interoperability specifications to support national health outcomes and healthcare priorities, including Meaningful Use, the Nationwide Health Information Network, and the ongoing mission to create better care, better population health and cost reduction through delivery improvements.

 

What is needed to achieve this future are specific health interoperability initiatives that guide the design and development of a fully integrated and connected health information system to enhance the efficiency, quality and effectiveness of the delivery of healthcare. The focus of the S and I Framework is on delivering guidance to the health information technology community that can achieve lasting results in healthcare delivery improvements, through the development of content and technical specifications, the development of reusable tools and services, and the effort to unite stakeholders on common healthcare challenges.

 

What are S and I Framework Initiatives?
An S and I Initiative focuses on a single challenge with a set of value-creating goals and outcomes that will enhance efficiency, quality and effectiveness of the delivery of healthcare, through the development of content, technical specifications and reusable tools and services. The S and I Framework is currently launching three Initiatives:

 

• Transitions of Care
• Lab Interface Improvement
• Consolidation Project

How does it work?
The S and I Framework works with a set of motivated organizations and individuals who share the mission and goals of care delivery transformation through improved interoperability. The overall success of the S and I Framework is dependent upon volunteer experts from the healthcare industry and we welcome and encourage new volunteers to contribute to this evolving process. Participant collaboration and deliverable management will be organized through the use of the S and I Framework Wiki (http://wiki.siframework.org/).

 

How Do I Participate?
Any interested party is invited to get involved in S and I Framework Initiatives, participate in discussions and provide comments and feedback by joining the Wiki. However, only Committed Members have voting rights in the S and I consensus process. A Statement of Commitment is required to be a formal Committed Member of the S and I Framework. Participating organizations and individuals must (1) regularly attend weekly Initiative Group meetings, and (2) meaningfully participate in developing needed deliverables, including development of source code, documentation development, and supporting implementation of the S and I Framework pilot efforts.

 

To participate as a Committed Member, please register for access to the S and I Framework Wiki (http://wiki.siframework.org/) and submit a Statement of Commitment directly on the wiki.

 

To participate as a Non-Committed Member, please register for Wiki access and feel free to contribute comments or participate in discussions.

 

We look forward to working with you in advancing the S and I Framework and the ongoing mission to create better care, better population health and cost reduction through delivery improvements. Thank you again for your support and continued interest in healthcare interoperability.

 

Arien

I'm off to see the Wizard in Aus.

Actually, that about one of twenty different things I'll be up to over the next two weeks.  I won't list them all, but some include:

1. I'll be attending the HL7 Working Group meeting in Sydney Australia.
2. I'll be attending my first HL7 Board Meeting
3. I'll have my last HL7 Structured Documents meeting as Cochair (I'll just be a committee member after Monday).
4. I'll teaching classes on CCD, IHE XDS and CDA, and a workshop on how to develop an IHE profile
5. I'll be attending my 7th IHE Connectathon.
6. I'll be attending my first Connectathon Conference, where I will be presenting on development of IHE profiles.
7. I'll be preparing materials for two sessions I'll be teaching for a John's Hopkins Informatic's program.
8. I'll be reviewing meaningful use phase 2 proposals and related regulation as it arrives.
9. I'll be preparing two presentations I'll be giving later this year at HIMSS11, one on social media, and another on development of IHE profiles (can you see a theme here)?
10. I'll be promoting The CDA Book, now available for pre-order from my very own bookstore.

You can look forward to a week of blog posts from the HL7 Syndey WGM next week on what's new from HL7.  In the following week, expect a week's worth of posting on the IHE North American Connectathon.

I hope to see many of you in my (and your) travels in the coming weeks.

Oh, yeah, and the Wizard?  That's @omowizard.  I'm hoping we can cook up some interesting magic with respect to healthcare standards.

   Keith

P.S.  For those of you who've asked:  The manuscript is only available to educational institutions looking to review the book for use as a text in Informatics or Health IT classes.  Sorry, no early copies...  I'd love to get them to you sooner, but I just can't.

2011 Healthcare Standards Calendar

I'm getting ready to head off to two events back to back, first to the HL7 Working Group Meeting in Sydney, then following that, the IHE Connectathon here back in Chicago. Sometimes I have trouble figuring out whether I'm going or coming, so I have to put together a calendar every year of significant events.

Below you see a Standards Event calendar that I have shared in Google Calendars. This calendar isn't intended to deal with minutia, but rather the big meetings, usually two-five day events related to Healthcare Standardization around the world. Feel free to send it invitations to your healthcare event.

I will monitor what is submitted, and try to keep it managable.

The e-mail address for this calendar is: 9h5apktq1vvr82k0ogvunvdsvo@group.calendar.google.com

If you want to be able to post events to it, drop me a line and I'll share it with you.

Definitions Matter

In more than two decades of software development, I've become quite accustomed to having to deal with product builds where the final changes to a product were strictly replacing its name. This is usually because marketing either had a very late brainstorm, or someone higher up decided that we needed something catchier for a name. I'd long been accustomed to using code phrases to identify a release because we never knew what the name was going to be ... sometimes even on purpose.  I've also been very wary of believing I understood something just because someone used a name or three word phrase I recognized. I usually ask for definitions.

So, the latest ONC blog post providing definitions for EMR and an EHR shouldn't really bother me.  But it does, in part because this office already wasted $100K defining these terms.  It was Bush's ONC and not Obama's that wasted the money, but the current office could have at least had the courtesy to reference the previous report rather than ignore it and redefine the terms.  But the original report should have been buried anyway ... maybe I would have been happier if ONC had acknowledged the errors in that report and then redefined the terms.

The next part of the post that annoys me is the qualitative judgement applied to the names, that an "EMR" product has certain limits on features (e.g., equivalence to digital paper) and information exchange which an "EHR" solves.

I spent 10 years working on linguistic software.  One of the things that I learned during that period of time is how definitions change over time.  Today's Electronic Medical Record is a completely different thing that what we had 5 years or a decade ago.  Perhaps it is time to change the name, and call it an Electronic Health Record.  I guess I'll wind up leaving that issue up to marketing and politicians.  What I do know is that changing the name of a thing doesn't change what it IS, just the perceptions of it.  I'll just have to remember to use the latest HealthIT Buzz words, but if I happen to use EMR, please remember that I mean EHR.  I haven't ever worked on anything as limited as what ONC describes.