Today I facilitated an IHE Workshop for the third time. This is always an interesting program. The first half of this half-day program is spent describing how IHE is structured, what it does, why, the benefits, how the processes work, et cetera.
The second half is done in five stages.
Step 0: We review the IHE profile proposal template.
Step 1: This step includes brainstorming interoperability problems in healthcare. We simply come up with an unconstrained list of problems that IHE might be able to solve.
Step 2: The next step divides the room up into teams of 3-5 people and having them select a particular problem to solve. Each team has to develop a profile proposal (short form), which includes four things:
A) Problem and Value Statement
B) Use Case
i) Current State
ii) Desired future state
C) Available Standards
D) Systems involved
Step 3: Teams present their proposal in 5-10 minutes, and answer any questions on them from the class. I also gently critique the proposals, explaining what might be done to make them a little better.
Step 4: The class votes on the proposals. Because of the timing, the class dwindled a bit from 12 to 6 people (it was the last class on the last day of HL7). So, I didn't let teams vote for their own proposal.
One proposal today got overwhelming support, and it was from the Opthomologist who worked solo with a bit of help from me. So, I'll be flying that one past some friends in IHE Eyecare to see if I can find a supporter of it to present at the next opportunity.
The problem described was lack of consistency in data collection on cataract surgeries. This is apparently a very common surgery (in general as well as in that specialty). The proposal was to develop either an OpenEHR Archetype or a CDA Document template that could be used to gather and report on the data pre and post-surgery, with use of SNOMED CT or LOINC Vocabulary, and restriction to appropriate units to report on vision acuity. A 20/20 in the US translates into 6/6 here in Australia, but there are also log scales.
I'll get the complete proposal from my student in my e-mail. We also looked at remote (home) monitoring, but that one didn't "win the prize". It had some valuable points also, and was well done, it just didn't have the same focus as the Cataract Surgery one. So, I'll take the output from that group and forward it to some folks in PCD next week also, and make sure that the team at least gets feedback on what is available.
The last proprosal was for ePrescribing, and had participation from AU, NZ, and CZ. The challenge here is that there really are NO common standards available for the electronic prescribing acrosss these regions, so the proposal was not terribly feasible. Even so, I promised to point them to the work being done by epSOS as a possible starting point.
Everybody gained something.
Next week I'll be doing something similar, but with much more limited time. Students will identify problems, and use existing IHE profiles they've had described to them earlier in the day to design a solution to an interoperability problem. I won't have to provide as much background for them because they'll have been at the Connectathon conference and will have also already toured the floor.
-- Keith
Friday, January 14, 2011
Thursday, January 13, 2011
An overdue Ad Hoc Motorcycle Guy Harley Award ...
The Ad Hoc Harleys are headed into their second year. They were initiated on January 20th of 2010 (my Birthday). The whole point of the Ad Hoc Harley is to recongize the contributions of someone with regard to standards who would otherwise be an unsung hero.
This particular award goes to one of those heros I first met in 2003 at an educational meeting in Chicago. Since then I've watched him over the years invest tremendous amounts of time and effort into ensuring that more than a 1000 products work with each other, using more than 200 different specifications. Unlike many others who get recognized here, this is part of his job, but he does that job well, and as a result of his efforts millions of lives have been made better by more interoperable healthcare products. It is not unusual for a computer to review hundreds of thousands of complex transactions, but it is the rare individual who can claim some responsibility for the same. This person can, and has done so more more than a decade.
In his role as "Mother" he has raised up a number of children through the complex process of ensuring systems work together. He is a bit stern, and expects his children to grow up rather quickly, but he also manages to ensure that they do. For his efforts, I award the next Ad Hoc Harley to:
This particular award goes to one of those heros I first met in 2003 at an educational meeting in Chicago. Since then I've watched him over the years invest tremendous amounts of time and effort into ensuring that more than a 1000 products work with each other, using more than 200 different specifications. Unlike many others who get recognized here, this is part of his job, but he does that job well, and as a result of his efforts millions of lives have been made better by more interoperable healthcare products. It is not unusual for a computer to review hundreds of thousands of complex transactions, but it is the rare individual who can claim some responsibility for the same. This person can, and has done so more more than a decade.
In his role as "Mother" he has raised up a number of children through the complex process of ensuring systems work together. He is a bit stern, and expects his children to grow up rather quickly, but he also manages to ensure that they do. For his efforts, I award the next Ad Hoc Harley to:
This certifies that
Steve Moore of the Mallinckrodt Institute of Radiology
Has hereby been recognized for outstanding contributions to the forwarding of Healthcare Standardization
Congratulations Steve, and here's to another decade of testing fun. See you in a couple of days.
Wednesday, January 12, 2011
Convergence
Today's Q2 meeting in Templates with Structured Documents, Patient Care, Vocabulary and Tooling was a continuation of several discussions (of which my post on Triplets is one) that have occured over the week regarding templates, detailed clinical models and archetypes. The focus of the discussion was the refresh of the HL7 Templates Draft Standard for Trial use.
The Templates DSTU was both a great success and a great failure for HL7. It was successful in its ability to clarify what an HL7 Template is. There are now over 1000 templates that conform to the HL7 definition of what an HL7 template is, used in national and international programs all over the world, including the US, the EU, and Asia. In fact, I've participated in the development of a set of more than 100 templates through IHE and HL7 that have been reused in national programs in those regions. It's even the same set in those regions, which provides a remarkable amount of consistency in clinical information found in CDA documents.
The failure of the Templates DSTU is a failure not in the details of what a template is, but rather in the information that is used to keep track of it, locate it, vet it, et cetera. The XML representation of that metadata has gone largely unused. When we reviewed the Templates DSTU for the Template Registgry Requirements project, we found it lacking in several places.
We discussed working on some common definitions that would help us parse all of the terms that I mentioned in Triplets, and to define the concepts, identify super concepts, and describe the various differences. So you could imagine that we would have the concept of an Archetype, and that would be specialized to describe HL7 based archetypes and openEHR based archetypes. Similarly with Templates and/or Detailed Clinical Models.
The audience in the room was generally supportive of this idea, and there seems to be a general consensus that this would actually have value not to just HL7 but also to openEHR. Apparently this is a shift in the relationship that has changed recently, spawned by nobody knows what.
A point which I made to the room. We, sitting in the room, are the people who care about these distinctions. To the average healthcare provider, they are meaningless. It is to ALL our benefit to have a common way to describe these things that we ALL understand and to promote its use, because no matter what we call it, Doctors just want it all to work together.
In that veign, I learned of a remarkable piece of work done by Heath Frankel. He was able to create a solution which took information from an HL7 Version 2 message, store it into an OpenEHR based repository, map from the OpenEHR structuire to the IHE Referral Summary, and then submit it to an XDS registry. I've known about the technical feasibility of this for some time. I wrote a few months ago on converting from Version 2 to CDA. I've also generated CDA from several EHR database structures from several different vendor's systems in my career.
I think about combining this idea with the notions that Robert Warden has about Neutral Mapping. I can envision a world where their exists a neutral mapping between the OpenEHR Information Model and the HL7 Reference Information Model. I believe this to be readily managable for a core subset that has yet to be determined. If this were to exist, I can see ways in which existing OpenEHR tools could be used to benefit the development of HL7 Detailed Clinical Models and HL7 and IHE Templates, that clinicians could use.
I've recently seen some demonstrations of tools which already in use in this space, and after sitting down and putting all the pieces together, my brain just exploded.
I'm sure most of you by know are wondering if I'm headed into the Dark Side of openEHR. Fear not, I still remain a huge fan and strong supporter of HL7 and IHE. But what I see here are some possibilities and synergies in convergence that would greatly benefit all of healthcare IT. The real challenge will be whether there is a way to truly take the best of both worlds forward.
The Templates DSTU was both a great success and a great failure for HL7. It was successful in its ability to clarify what an HL7 Template is. There are now over 1000 templates that conform to the HL7 definition of what an HL7 template is, used in national and international programs all over the world, including the US, the EU, and Asia. In fact, I've participated in the development of a set of more than 100 templates through IHE and HL7 that have been reused in national programs in those regions. It's even the same set in those regions, which provides a remarkable amount of consistency in clinical information found in CDA documents.
The failure of the Templates DSTU is a failure not in the details of what a template is, but rather in the information that is used to keep track of it, locate it, vet it, et cetera. The XML representation of that metadata has gone largely unused. When we reviewed the Templates DSTU for the Template Registgry Requirements project, we found it lacking in several places.
We discussed working on some common definitions that would help us parse all of the terms that I mentioned in Triplets, and to define the concepts, identify super concepts, and describe the various differences. So you could imagine that we would have the concept of an Archetype, and that would be specialized to describe HL7 based archetypes and openEHR based archetypes. Similarly with Templates and/or Detailed Clinical Models.
The audience in the room was generally supportive of this idea, and there seems to be a general consensus that this would actually have value not to just HL7 but also to openEHR. Apparently this is a shift in the relationship that has changed recently, spawned by nobody knows what.
A point which I made to the room. We, sitting in the room, are the people who care about these distinctions. To the average healthcare provider, they are meaningless. It is to ALL our benefit to have a common way to describe these things that we ALL understand and to promote its use, because no matter what we call it, Doctors just want it all to work together.
In that veign, I learned of a remarkable piece of work done by Heath Frankel. He was able to create a solution which took information from an HL7 Version 2 message, store it into an OpenEHR based repository, map from the OpenEHR structuire to the IHE Referral Summary, and then submit it to an XDS registry. I've known about the technical feasibility of this for some time. I wrote a few months ago on converting from Version 2 to CDA. I've also generated CDA from several EHR database structures from several different vendor's systems in my career.
I think about combining this idea with the notions that Robert Warden has about Neutral Mapping. I can envision a world where their exists a neutral mapping between the OpenEHR Information Model and the HL7 Reference Information Model. I believe this to be readily managable for a core subset that has yet to be determined. If this were to exist, I can see ways in which existing OpenEHR tools could be used to benefit the development of HL7 Detailed Clinical Models and HL7 and IHE Templates, that clinicians could use.
I've recently seen some demonstrations of tools which already in use in this space, and after sitting down and putting all the pieces together, my brain just exploded.
I'm sure most of you by know are wondering if I'm headed into the Dark Side of openEHR. Fear not, I still remain a huge fan and strong supporter of HL7 and IHE. But what I see here are some possibilities and synergies in convergence that would greatly benefit all of healthcare IT. The real challenge will be whether there is a way to truly take the best of both worlds forward.
Expressions in HL7 Data Types R2 and Computable Clinical Guidelines
The HL7 Structured Documents Workgroup met with Clinical Decision Support today to discuss some of the issues with the HL7 Quality Measurement Format that would need to be addressed in the next release. Bob (Dolin) gave a quick update on the NQF status. Apparently the Meaningful Use measures have all been converted to HQMF, including all the value sets in all the Meaningful Use specified vocabularies (ICD-9-CM and SNOMED CT) and are in CMS hands. We heard that there may be some sort of comment / vetting process as a later phase.
The issue that Bob wanted to address is the way to represent an expression in a computational language in a measure. HL7 Data types release 2 includes the EXPR data type. This data type is an extension of a data type of type T which has one new component: expression. An example representation of this is shown below:
‹value xsi:type='EXPR_INT'›
‹expression mediatype='application/javascript'›
foo.value.value - bar.value.value
‹/expression›
‹/value›
Now, by itself, this isn't completely useful, but when you put it inside an Observation that you are defining, the expression can be used to define how the value is computed. There are a couple of other things that you need. One of these is a binding from the variables foo and bar above to specific classes.
The HL7 RIM has a way to create bindings for the derivationExpr component of the act class, but hasn't defined how to create bindings for EXPR_T. I'd stick with using the same mechanism for derivationExpr. What could be done is something like the following:
‹observation moodCode='DEF'›
‹value xsi:type='EXPR_INT'› ‹actRelationship typeCode='DRIV'›
‹expression mediatype='application/javascript'›
foo.value.value - bar.value.value
‹/expression›
‹/value›
‹localVariableName›foo‹localVariableName›
‹observation›
‹value value='1'›
‹/observation›
‹/actRelationship›
‹actRelationship typeCode='DRIV'›
‹localVariableName›foo‹localVariableName›
‹observation›
‹value value='2'›
‹/observation›
‹/actRelationship›
‹/observation›
What this essentially says is that the outermost definition of the observation has a value. That value is computed from information contained in two other named classes: foo and bar. These classes are then defined to be local variables representing the named observation classes.
So, why is this cool? Well, it's something only a geek could love. What it does is provide a mechanism whereby we can bind an HL7 class represented in XML to a programming language like javascript (Bob wanted to use GELLO, but I can hand you a book today on javascript if you really need it. And you can probably already figure out how to access the classes.
The next piece of this is that it allows certain computations to be defined based on the contents of other stuff.
What is missing from this is the binding rules that tell us how to evaluate the named portion of the expression. I cheated by using the binding rules for derivationExpr, which are very simple. Those rules state that the named variables are contained within in derived acts. I could have used other binding rules, e.g., that the named variables are contained within some other set of named variables.
What I like about this is that it gives me the missing pieces needed to define a Structured Document for a Clinical Guideline. Those two pieces are what I call level 3 and level 4 of clinical guidelines.
The structured clinical guideline in my head has four levels. Level 1 contains a header comprised of metadata used to allow the guideline to be found in a repository of guidelines and human readable content as an attachment, e.g., PDF or XHTML. Level 2 contains the information structured into sections where each section is addressible, coded, and has additional metadata describing it, along with human readable content in a format like XHTML. Level 3 are the definitions of things that need to be tracked to manage the guideline (e.g., heart rate, ejection fraction ratio, blood preassure, comorbidities, et cetera). Level 4 is a way to bind to ANY computational langauge, such as javascript (my preferred language for reasons of reduciong complexity).
So we never did get to discuss the idea of how to build this thing in clinical decision support like I had wanted to, because we could hardly get away from the discussion about how what Bob wanted was already in scope of VMR [sort of like swatting flies with a sledgehammer]. But now I know the pieces are there. It's time to start thinking more about how to put this together.
And see, I don't even need to worry about the Gello, Arden, GLIF, ... debate because any mediaType will do as the computable language. The standard need not state a preference.
So, it looks like there might be enough to define a quality process that has measurement built in. One of these days, I'm just gonna have to take a class on that six-sigma thingy-ma-bob.
G'Night all.
Keith
P.S. They tell me that there's a foot of snow back home. I hope you all are enjoying it.
The issue that Bob wanted to address is the way to represent an expression in a computational language in a measure. HL7 Data types release 2 includes the EXPR
‹value xsi:type='EXPR_INT'›
‹expression mediatype='application/javascript'›
foo.value.value - bar.value.value
‹/expression›
‹/value›
Now, by itself, this isn't completely useful, but when you put it inside an Observation that you are defining, the expression can be used to define how the value is computed. There are a couple of other things that you need. One of these is a binding from the variables foo and bar above to specific classes.
The HL7 RIM has a way to create bindings for the derivationExpr component of the act class, but hasn't defined how to create bindings for EXPR_T. I'd stick with using the same mechanism for derivationExpr. What could be done is something like the following:
‹observation moodCode='DEF'›
‹value xsi:type='EXPR_INT'› ‹actRelationship typeCode='DRIV'›
‹expression mediatype='application/javascript'›
foo.value.value - bar.value.value
‹/expression›
‹/value›
‹localVariableName›foo‹localVariableName›
‹observation›
‹value value='1'›
‹/observation›
‹/actRelationship›
‹actRelationship typeCode='DRIV'›
‹localVariableName›foo‹localVariableName›
‹observation›
‹value value='2'›
‹/observation›
‹/actRelationship›
‹/observation›
What this essentially says is that the outermost definition of the observation has a value. That value is computed from information contained in two other named classes: foo and bar. These classes are then defined to be local variables representing the named observation classes.
So, why is this cool? Well, it's something only a geek could love. What it does is provide a mechanism whereby we can bind an HL7 class represented in XML to a programming language like javascript (Bob wanted to use GELLO, but I can hand you a book today on javascript if you really need it. And you can probably already figure out how to access the classes.
The next piece of this is that it allows certain computations to be defined based on the contents of other stuff.
What is missing from this is the binding rules that tell us how to evaluate the named portion of the expression. I cheated by using the binding rules for derivationExpr, which are very simple. Those rules state that the named variables are contained within in derived acts. I could have used other binding rules, e.g., that the named variables are contained within some other set of named variables.
What I like about this is that it gives me the missing pieces needed to define a Structured Document for a Clinical Guideline. Those two pieces are what I call level 3 and level 4 of clinical guidelines.
The structured clinical guideline in my head has four levels. Level 1 contains a header comprised of metadata used to allow the guideline to be found in a repository of guidelines and human readable content as an attachment, e.g., PDF or XHTML. Level 2 contains the information structured into sections where each section is addressible, coded, and has additional metadata describing it, along with human readable content in a format like XHTML. Level 3 are the definitions of things that need to be tracked to manage the guideline (e.g., heart rate, ejection fraction ratio, blood preassure, comorbidities, et cetera). Level 4 is a way to bind to ANY computational langauge, such as javascript (my preferred language for reasons of reduciong complexity).
So we never did get to discuss the idea of how to build this thing in clinical decision support like I had wanted to, because we could hardly get away from the discussion about how what Bob wanted was already in scope of VMR [sort of like swatting flies with a sledgehammer]. But now I know the pieces are there. It's time to start thinking more about how to put this together.
And see, I don't even need to worry about the Gello, Arden, GLIF, ... debate because any mediaType will do as the computable language. The standard need not state a preference.
So, it looks like there might be enough to define a quality process that has measurement built in. One of these days, I'm just gonna have to take a class on that six-sigma thingy-ma-bob.
G'Night all.
Keith
P.S. They tell me that there's a foot of snow back home. I hope you all are enjoying it.
Tuesday, January 11, 2011
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
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
Monday, January 10, 2011
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 ...
@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 ...
Sunday, January 9, 2011
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:
- Ignore
- Monitor
- Contribute
- Lead
- Kill
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:
- 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.
- 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.
- Replacing it with something better. ASTM and HL7 produced CCD which effectively did in the Care Record Summary.
- 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.
- Introducing unimplementable features and/or scope. This is hidden as a contribution and fails the test of transparency.
- 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.
- 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.
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.
Subscribe to:
Posts (Atom)