Why HL7 needs a DCM standard to collaborate as part of CIMI

First, I want to be sure that there is a good understanding why HL7 needs a DCM DSTU when most of us working in the HL7 DCM space are also working on the CIMI () efforts.

I think the most important thing to remember is why some of us took up the banner after the "Bocca DCM Summit". There are clearly different aspects of the problem, and different motivations for trying to advance the agenda, so it isn't surprising that different aspects of this complex area require some experimentation and development.

Second, my focus has not been on UML modeling conventions for clinical content. The HL7 DCM DSTU draft/strawman I am working on is all about the methodology, intermediate level models, terminology-RIM interactions, and modularity.

In addition to the bottom-up clinical detail, we need a top-down specification so we can build complex things from simple parts, and so that we can write software which can process information, not just parse data into some local system. Thus, we need design patterns defined as HL7 Templates (whatever those turn out to be. Eg. the time series, which becomes a parent/contributor to the "pharmacological challenge and response model" (which the GTT is a specialization of).

The notion I have been selling (which is useful to consider for CIMI, explains why I think HL7 needs a DCM standard to provide a deterministic target to map CIMI models into).

#1 HL7 DCMs are critically needed as a quality improvement initiative in HL7 specifications (and fit nicely into one of the empty boxes of the SAIF matrix). There is too much variability in how various groups model the same content, and far too many complex issues of RIM semantics which are often not appreciated, ignored, not supported (e.g. CDA r2), or just done wrong.

#2 HL7 DCMs are needed because the existing 'reusable' representations are not terribly reusable and don't support generic programming methods. They are either specific to a standard desperately in need up updating (CDA r2, and I am not just picking on them, I am trying to find a few free minutes to help with a r2.1/2.5/3) or which lack the detail needed to implement in a fashion which supports interoperability.

#3 HL7 DCMs need to support non-messaging uses, particularly decision support and long term data persistence. I can throw together an XSD which conveys the data of a glucose tolerance test (and will post a UML of a 'sketch' for something more useful on the blog) in about a half hour. Of course, a year from now, you need to know exactly what I was thinking at the time to write any sort of algorithm to use the information. Using information is the goal, not just exchange or capture.

#4 HL7 DCMs need to provide explicit semantics which are based on both RIM semantics and terminology semantics as a cohesive whole. This turns out to be harder than a lot of people think, and requires expertise in terminology, modeling, RIM semantics, clinical statement pattern, and particularly (in most cases) SNOMED-CT concept model/TermInfo guidelines. So having a centralized and pre-built library of properly modeled content can serve to accelerate the development of a domain's clinical content specifications.