A problem has been identified on the HL7 email lists concerning the degree to which the receiver of a message or document can reason out what its meaning is automatically, merely by inspecting what is received.
As Lloyd McKenzie puts it, under the current regime, "Converting a standard lab, pharmacy or other instance into a generic RIM instance will be easy. The tricky bit will be the reverse process - converting instances expressed as generic RIM in the content of a CDA and parsing them into the domain-specific structures. For many static model designs, there isn’t necessarily a deterministic path (due to looseness of constraints in the models)."
The very point of the RIM, however, is to provide determinate interpretations of messages. If such determinate interpretation is no longer available, then (as the Dutch say) HL7 is brooken.
We provide the context of Lloyd's remark in what follows. Minor corrections have been made for readability.
From: “McKnight, Lawrence (H USA)”
Date: 20 augustus 2009 23:26:51 GMT+02:00
To:
Subject: FW: What is the technical difference between a pattern, dmim, rmim, cmet, and template.
With the goal of making similar content look similar across domains or between organization[s] defining models or constraints, and regardless [of] which kind of exchange method is used, I’m asking for clarity on what logical differences exist between the modeling constraints on the RIM and how a CMET or RMIM is different from a Template. I for one am increasingly unclear on the hows and whys of this. Lloyd said he would provide the follow up answers.
To make things more concrete, here is a (mostly real) example which might provide better clarity to work from.
Org H (an organization independent of HL7) would like to take advantage [of] the great work that HL7 has done and write implementation guides that reference HL7 specifications and requirements it has been given by the US government.
The requirements given to Org H are:
1) At the point of discharge from the hospital, patients should receive a stuctured document that contains their meds, allergies, problems, and labs, and instructions that they could import into their PHR.
2) Primary care doctors receive a similar but different[ly] structured document that contains the meds, allergies, problems, but also a listing of vital signs, and a brief narrative of what happened in the hospital. This document should be available for future reference in a document archive.
3) The hospital should send labs and vital signs via unsolicited messages as real time feeds to the PCP’s office.
Org H would like to ensure that the structural representation look[s] the same in all the documents and messages (e.g. a med structure as similar as possible regardless of being passed in a message or document or service). They would like to ensure that the same terminologies get bound in all use cases (eg RxNorm SCD for meds, SNOMED for problems, LOINC for labs, etc.). Finally, to mix things up, they would like to use a constrained detailed clinical model of vital signs from an organization outside of HL7 (say IHE). To mix it up even further, let’s say that meds need to have conditional elements such as “hold if systolic BP is <100”, or “give 3 units for a glucose between 150 and 200”, where the same structured vital sign or lab observations are used in the model for the medication intent or the independent message.
Finally, there is a requirement that a certification agency be able to check and enforce that the implementation guides are being followed.
Now, let’s assume ideal conditions [where] we have CDAr3 with a new improved “right side” that references a generic RIM model and can represent everything.
How should the Org H implementation guides be written to reference the appropriate constraints from the various organizations while ensuring that the appropriate constraints from the HL7 domains gets used (e.g. the pharmacy RMIM is followed for meds in the patient summary document)? How does the pharmacy domain ensure that it references the correct models in its conditional element? How does the structured documents domain ensure that a document implementation guide uses the pharmacy model?
How does IHE place its constraints where Org H can apply it to the appropriate models?
In all of this, what gets done in a pattern, a RMIM, a CMET, or a template? And why (e.g [because] this constraint could not be [used] in XX because XX doesn’t have ...)?
Please help. I’m confused.
Larry.
-------------
From: Lloyd McKenzie
Date: 25 augustus 2009 07:55:14 GMT+02:00
To: “McKnight, Lawrence (H USA)”
Cc: clinicalstatement@lists.hl7.org, MNM List
Subject: Re: FW: What is the technical difference between a pattern, dmim, rmim, cmet, and template.
Reply-To: Lloyd McKenzie
Hi Larry,
Sorry for the delay in my promised answer. I’m copying MnM as the answer may be of interest there as well.
First off, DMIMs, RMIMs CMETs and Templates are all examples of static models. HL7 does not currently have (and has never had) an artifact called “pattern”. We use patterns in many of our artifacts and there is an MnM project that captures and documents common patterns that have been found to be useful in designs. However, these are generic structures such as “how do you capture the assigner of an identifier”. I therefore won’t talk about patterns further.
In the methodology, there are four different types of static models. They are:
RIM - Domain Information Model - there’s only one in the HL7 world, you’ve probably seen it once or twice ;>
DIM - Domain Information Model: These are high level models reflecting a group’s understanding of a particular healthcare domain. They frequently have multiple entry points and are not intended to be serialized. They may have a mapping to a committee’s Domain Analysis model. It is possible to create DIMs that are constraints of another DIM, though that doesn’t happen very often.
CIM - Constrained Information Model (possibly to be renamed SIM - Serializable Information Model): These are serializable models. In previous modeling terms, they were called RMIMs, HMDs and Message Types. In the new methodology, they’re all called CIMs and we aren’t limited to exactly 3 levels of constraint. I.e. a CIM can constrain another CIM which constrains another CIM which constrains . . . which constrains a DIM. You can have greater or fewer levels as necessary. CIMs tend to be balloted and they determine what the wire format of an instance will be. They are used by the ITS to generate schemas.
LIM - Localized Information Model: These include templates and the static portion of conformance profiles. They have the same rules as a CIM, but represent a set of constraints applied “on top of” a CIM, or for templates, for parts of a whole whack of CIMs. They don’t have any impact on the wire format which is determined by the parent CIM. LIMs aren’t usually balloted, though they can be. Some specifications, like CDA, depend on LIMs for interoperability because the base CIM (that determines the schema) is so generic it’s hard to conform with directly. Templates can be invoked at any node within a CIM. Profiles begin at the root node of an interaction and cover the entire model. Profiles define “what’s allowed/expected” in a particular implementation environment or what’s actually done by a specific system. While there may be 100s of balloted CIMs, there will be 10s or 100s of thousands of templates covering all sorts of detailed structures for various disciplines and needs.
CMETs (Common Model Element Types) are a way of referencing one CIM from another CIM. Essentially a CMET is an interface that can be referred to by multiple static models. It is bound to a specific static model in a particular release of a specification in a given realm (in the cmetinfo.txt file). E.g. For release X in Canada, the CMET “AssignedPerson-Informational” is bound to CMET COCT_MT123456CA. The point of CMETs is to allow common static model fragments to be re-used and applied consistently. So things like patients, locations, providers, etc. that are referenced by numerous models can be defined a few different ways to meet common use-cases and then get re-used all over the place.
Similar to CMETs are a structure called “stubs”. Like CMETs they are interfaces in a model that say “reference something like X here”. However, unlike CMETs, stubs aren’t bound for an entire release. Instead, they’re bound for the creation of an interaction. Models that contain stubs are called “wrappers”. That’s because they’re not complete in and of themselves. Interactions that reference them also need to ‘bind’ the stub (or stubs) in the wrapper to point to another model. The model pointed to might itself contain one or more stubs that also need to be bound. At the moment, we tend to have two layers of wrappers - transmission and controlAct. However, the methodology allows for more layers where it’s userful. For example a batch might contain a message which contains a controlAct which contains a claim which contains a billable act.
As to your more specific questions:
- The “profile” created for your document could (and should) reference separate sub-LIMs (templates) that represent constraints on the various domain models (pharmacy, patient care, lab, etc.)
- The conditional element within pharmacy would probably be defined solely within pharmacy. It’s a generic criterion and isn’t a model drawn from a particular healthcare discipline. The capturing of blood pressure would be patient care and the measuring of glucose would be lab. The conditional statement is still pharmacy.
- Structured documents can’t ensure that a document implementation guide developed and approved outside of HL7’s process uses the appropriate domain models. However, I’d like us to get to a place where there’s an expectation that implementation guides developed and balloted within HL7 *would* be expected to be aligned with the appropriate domain models and failure to align (without a documented and convincing reason :>) would be grounds for negative ballot.
- As for how IHE fits in, I have no clue. They’re just one organization that can create (and promote) implementation guides. I would hope they would follow good practices and leverage domain content rather than applying constraints on their own. Whether they always will, I don’t know.
Lloyd
-----------
From: “McKnight, Lawrence (H USA)”
Date: 25 augustus 2009 16:14:49 GMT+02:00
To: “Lloyd McKenzie”
Cc: , “MNM List”
Subject: RE: FW: What is the technical difference between a pattern, dmim, rmim, cmet, and template.
Thanks, Lloyd.
I learned a little, but still have questions.
I was unaware of the RMIM->CIM change, but welcome that. The remainder fits my understanding.
Unfortunately, the issue remains. In document profile, I know of mechanisms to use LIMs. For example, CCD uses “conformance statements”, which are currently executed in the form of a schematron check. Presumably, a similar mechanism could be applied to apply a LIM constraint to messages or services as well.
But I’m not clear on a mechanism to apply a CIM to a document, and that’s generally where the modeling differences arise. The need is to create a document profile, that might include for example a medications section, and in that medications section specify that an individual medication use[s] the same modeling [as] in the pharmacy CIM (perhaps with additional constraints from the LIM). My gap [is] in understanding how that would work using CIMs. It would seem that the CDA r3 spec would need to include not just the ‘RIM on the right side’ but also every CIM!
So, is it possible to apply the constraints of a CIM to a generic model outside of the HL7 tooling (e.g. use a CMET in a profile)? If not, is it possible to convert the constraints of a CIM to a LIM-like structure (e.g. as a template) and ensure alignment? It seems [as though], functionally, they are equivalent structures (they both apply a set of constraints on the RIM plus a starting base of constraint[s] defined by somebody else). The main difference seems to be that they are applied by different organizations at different points.
I think we all agree that we would like alignment. But, your statement
“... can’t ensure that a document implementation guide developed and approved outside of HL7’s process uses the appropriate domain ...”
doesn’t capture the issue. It’s not that these implementation guides could or need to be bound. Other organizations will do what is reasonable. But, it’s generally easier to re-use the same where they can. The issue is that we prevent them from doing this. Part of the problem is that, as you mention, the ‘right hand side’ of CDA is limiting. The other part is more pragmatic. Unless I’m misunderstanding how CIM’s can be applied, we are making it next to impossible for the domain models to be appropriately referenced by outside organizations. The statement above is saying, we can’t control this, therefore we don’t care. Is it any wonder other organizations don’t do the right thing and reference models appropriately? It’s true that we can’t control this, but we do care. Therefore, we should make it easy to do the right thing. Currently it doesn’t feel like we’re doing that.
Larry.
----------
From: Lloyd McKenzie
Date: 25 augustus 2009 17:13:42 GMT+02:00
To: “McKnight, Lawrence (H USA)”
Cc: clinicalstatement@lists.hl7.org, MNM List
Subject: Re: FW: What is the technical difference between a pattern, dmim, rmim, cmet, and template.
Hi Larry,
The RMIM/HMD/MT -> CIM change is part of the methodology but not the tooling or publication process yet.
In answer to your question, you can treat any CIM as a LIM. The only difference is the “intention to affect element names”. Personally I would welcome a situation where the actual wire format of a prescription in CDA was the same as it was in a message type. This could be done by making Entry a “stub” and the CDA structure into a wrapper. However, given the strong desire to see a single schema for all CDAs, that might not fly. (You could still have a single schema for generic CDA, but it would end up having xs:any for the entry content and I don’t [think] that would be acceptable to some.)
So our models certainly can be referenced. In most cases, they wouldn’t be referenced directly anyhow. Instead, someone would create a LIM that is a proper constraint on a CIM because odds are they’ll want to be a bit tighter than the UV message specifications for a given area (for example, specifying vocabularies, limiting some repetitions or recursions, etc.)
Lloyd
--------------------------------------
From: “Buitendijk, Hans (H USA)”
Date: 25 augustus 2009 18:17:06 GMT+02:00
To: “Dan Russler” , “Lloyd McKenzie”
Cc: “McKnight, Lawrence (H USA)” , , “MNM List”
Subject: RE: FW: What is the technical difference between a pattern, dmim, rmim, cmet, and template.
Reply-To: “Buitendijk, Hans (H USA)”
Can you expand the clarification such that we could see how the approach suggested for CDA R3 can be consistent with / be applied to Composite Order such that the same data communicated as part of a document is expressed the same when communicated as part of a Composite Order?
Hans J. Buitendijk
HS Standards & Regulations Manager
Siemens Healthcare
------
From: Lloyd McKenzie
Date: 25 augustus 2009 18:28:39 GMT+02:00
To: “Buitendijk, Hans (H USA)”
Cc: Dan Russler , “McKnight, Lawrence (H USA)” , clinicalstatement@lists.hl7.org, MNM List
Subject: Re: FW: What is the technical difference between a pattern, dmim, rmim, cmet, and template.
Hi Hans,
The idea would be that when sending data appropriate to a particular domain (lab, pharmacy, claims, whatever) the “template” applied to the entry portion of the CDA document would be a static model that is a proper constraint on the published CIMs (RMIMs, Message Types, etc.) of the appropriate domain. The wire format could still be a generic RIM syntax if that’s what’s decided by Structured Documents. Converting a standard lab, pharmacy or other instance into a generic RIM instance will be easy. The tricky bit will be the reverse process - converting instances expressed as generic RIM in the content of a CDA and parsing them into the domain-specific structures. For many static model designs, there isn’t necessarily a deterministic path (due to looseness of constraints in the models). Therefore we may need to take advantage of embedded template cues to assist in the parsing process.
Lloyd
