Introduction to the problem

Are we there yet?
In spite of decades of experience with electronic health records and clinical decision support, the lack of semantic interoperability has prevented the predicted sea-change in healthcare. Health data is not comparable, it cannot be aggregated and it cannot be used to automate or augment clinical decision making. The solution requires a robust information model and rigorous attention to detail in use of clinical terminology which is well suited for clinical documentation, decision support, public health reporting, quality improvement and clinical trials.

A Detailed Clinical Model (DCM), within the scope of HL7, is a set of specifications for clinical content represented in HL7 v3 formalism. It provides the canonical static semantics for clinical information exchange independent of the particular information exchange paradigm.

The specific implementation presented is implemented as HL7 version 3 specifications which extend by constraint HL7 Clinical statement model using HL7 Templates and following the HL7 TermInfo (Use of SNOMED-CT) specifications. Furthermore, the model adopts a subset of the SNOMED-CT concept model attributes for Findings with Explicit Circumstances as mandatory, relying on the mechanism within the CD data types for post-coordination. This allows for a compact message which is reliably interpreted even by systems which are not designed around this model.

It may be possible to create DCMs with the same semantic content using terminologies other than SNOMED-CT. However, it is the consensus of the HL7 terminology community that SNOMED-CT offers the greatest opportunity to success. There is also a growing recognition (q.v. the TermInfo guide) that creation of implementable specifications which are not specific to a given terminology does not result in semantic interoperability. Thus, while the efforts at HL7 will initially focus on SNOMED-CT based DCM efforts, it should be kept in mind that subsequent efforts will be needed to evaluate other terminology approaches at some later time.
One other use of SNOMED-CT is as a reference terminology. DCMs defined using SNOMED-CT concept models could be re-implemented using other terminologies. The role of SNOMED-CT here isn't as an exchange terminology, but rather to define the semantics of the model, regardless of what controlled vocabulary is used at the interface/message level.

Detailed clinical models address issues of clinical content of health record systems and do not mandate a specific implementation, as transformations between this model and other alternative representations is possible. Furthermore, they are explicitly designed for use in multiple applications including messaging, structured documents, web services, or as the specification of a virtual medical record API for decision support or other components.

Clinical records serve multiple primary uses and roles. They primarily serve as a set of notes so a provider may refresh their recollection of a patient at a subsequent encounter, or as a means of communicating with other providers who may subsequently see the patient. Clinical records further provide a legal document to provide evidence of compliance with regulatory requirements as well as the account which documents the quality and conformance of care which is used to substantiate claims for reimbursement and defend against claims of malpractice. The record may also be primarily concerned with documenting observations gathered as part of a research endeavor, much as a laboratory notebook documents more basic experiments. Clinical decision support systems represent a more modern primary use of captured clinical findings. While the distinction is not terribly informing, secondary uses typically fall outside the direct care or purpose of the encounter, and more often (like the collection of information for research or use in a decision support application) have an analytic or computational focus. Some additional examples include collection of case histories required for board certification in some clinical specialties, reporting of cases of interest for public health authorities, quality assurance reviews, and research involving clinical encounter information (as contrasted with use of information collected primarily for research use). While the primary use requirements are well established, often by statute, and are often met with pre-Gutenberg technology, secondary use is highly dependent upon computational methods.

To meet the requirements of clinical research, clinical decision support, and the analytic requirements, clinical findings must be represented with considerations beyond the simple record keeping mandates and beyond the capability of narrative text. For information to be useful to anyone but another comparably educated professional, an author must express their findings as discrete observations in an information model that reflects the context in a structured manner using an appropriate controlled terminology (or proper structure for numeric data types). The representation of a shared pattern of expression, with the necessary structure to represent simple cases simply while allowing for semantic richness and complexity is the core requirement of the detailed clinical models (DCM) process. The use of shared detailed clinical models is essential to functional semantic interoperability. In addition, clinical system design is complicated by the need to create, often de novo, data structures and application logic. This is often left to the discretion of a non-clinician (and all too often, informatics naive) programmers resulting in the proliferation of lackluster electronic health records which fall short of the decades old promises of automation and improved patient outcomes due to decisions support technologies. One of the objectives of the detailed clinical models effort is the creation of a library of reference information components created by the leading clinical informatics experts in a peer-reviewed and maintainable manner for use by anyone wishing to create an application or system using clinical information.

Detailed clinical models have specific requirements. First, they reflect the clinical and biomedical reality with accuracy and precision. It is not sufficient to create data models which cannot capture the relevant details in complex cases, nor is it acceptable to have data models which impose rigid and complicated requirements for cases where the observation is simple (such as the case with most normal findings documented). Furthermore, there is nearly always some degree of imprecision in describing a finding, and often a degree of uncertainty as to the very existence or truth of the finding. For example, a physician may appreciate the soft, rounded edges of what appears to be an enlarged spleen on physical exam. They may be able to quantify it as mild, moderate, etc. or describe the lower edge in centimeters below the costal margin. In many patients, appreciation of abdominal masses is limited by their body habitus, and general physical examination estimation of size of visceral contents is notoriously inaccurate. The physician may not even be certain that they are palpating the spleen, and may wish to qualify it as “probably present” or “possibly present”. In contrast, diagnostic imaging (such as an abdominal CT or ultrasound) can provide accurate measurements with known precision/error.

Summary of DCMs

There is a critical dependence on representing clinical content in a fashion which is both human readable (usually easy), useful for secondary analysis (hard), and which is machine-interpretable (very hard). Casual approaches nearly always fail, as they effectively tie their logic in knots, and use-specific, highly focused approaches lead to volumes of hard (if not impossible) to use piles of important information. There is a recognized need to have a systematic, precise, yet expressive and flexible approach to representation of structured clinical content specification at the level of clinical, research, and legal detail required.

Detailed Clinical Models (DCM) are a precisely defined set of data element specifications which capture the meaning and context of clinical information is a format which is amenable to analysis and use in clinical decision support systems. They provide a common information model for clinical data (including procedures, history and physical exam findings, diagnosis, problems, medication use) which is independent of the use of the information, the source of the information, and which can be shared between applications/services to facilitate semantic interoperability.
Benefits of DCMs include reducing the long-term cost of system development and maintenance by centralizing the management of complexity, and providing data element specifications which can be safely reused for multiple purposes. They also can help simplify migration of data from legacy systems, can be used to define persistence mechanisms which “future proofs” the clinical data, and makes it available for use outside the application which created it.

Specific examples where DCMs are the key enabling technology include interfacing “best of breed” systems, robust clinical decision support, rich data warehouses with precisely defined data, cross organizational quality measures, early recognition of infectious disease outbreaks, and computable electronic health record information exchange.

Design of DCMs is as complex as the clinical information they represent. They need to be able to capture data at the most specific and detailed level which is clinically relevant and which meets the basic requirements of clinical documentation. They also need to be able to represent simple findings simply, while allowing for arbitrary complexity. One of the most important advantages, and requirements, for DCMs is the need to have explicit representation of relationships between data elements, such as those linking a test result to a diagnosis to a therapy.

Detailed Clinical Models include both compositional rules to combine simple models into more complex models, and using multiple hierarchical design patterns (i.e. a broader pattern is constrained into a more specific child pattern) to create models which can be easily parsed and which have deterministic meaning. Similarly, terminology is bound and further constrained as part of the model definitions. All DCMs are a constraint on a common reference model (in the HL7 context, this would be the Clinical Statement Pattern), and will follow a common approach to definition to provide consistent data structures.

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.