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.