Detailed Clinical Models

Definition

A Detailed Clinical Model (DCM) is a formal specification of the semantics of discrete structured clinical information. It provides the elements and attributes, including the possible values and types of the attributes, needed to convey the clinical reality in a fashion that is understandable to both clinical domain experts and to formal logics, including the potential for use in computer algorithms. It provides unambiguous detail which is intended to be cross domain and cross discipline.

HL7 version of a DCM

The HL7 specific application of DCMs will be published as a Template which constrains the Clinical statement pattern following the TermInfo guidance on use of controlled terminologies. It is also likely that in addition to any template specification, it will include additional machine processable definition and constraints needed for a computer program to 'understand' a given DCM, with the intent of providing a plug-in type mechanism where ERHS and other healthcare IT platforms can add new content directly without requiring separate implementation.

Current focus at HL7 is on clinical findings

DCMs are of clear value in multiple areas of clinical data. Given the pressing needs the initial focus will be on capture and representation of clinical findings. This is a loose definition, but conceptually could be considered whatever a clinician would put into a health record which documents information about a patient. While this could include every laboratory report or medication administration, the unmet need is to document the intellectual work product of credentialed clinicians. Thus, while there are some aspects of some laboratory result reporting which may benefit from the more elaborate and formal semantics of DCMs, the actual representation of the data is largely encompassed by existing HL7 specifications. What is missing is the test specific set of diagnosis, or other interpretations, which would be based upon the test results. So while there isn't a pressing need for a DCM for serum sodium reporting, there is a definite gap when it comes to serum sodium interpretation (which would also include other clinical findings, such as renal function, serum and urine creatinine measurement--to calculate a FeNA--, as well as urine sodium, exam findings of volume status, mental status etc.).

Use of SNOMED-CT to the point of exclusion of other code systems

One requirement for DCM is the slot binding to terminology that defines the concept of each variable. Currently, the only controlled reference terminology which has the structure and the breadth of content suitable for representation of clinical findings in an electronic health record system. Other terminologies will be needed to supplement content in specific areas (e.g. use of ICD-O-3 or parts of NCI thesaurus to represent details of cancer diagnosis).

Selected use of other terminologies

• ICD9CM
• ICD10, ICD10CM
• ICD-O-3
• NCI thesaurus
• GO
• NDFRT
• RxNorm
• VANDF
• FMA
• Nursing specific terminology (NANDA, NIC, NOC, ICNP)

Use cases

• Clinical decision support systems
• Disease / syndrome surveillance
• Quality of care metrics
• Generation of human user interface components
  • Checklists
  • Review of systems (ROS) and physical examination (PE) 'templates'
  • Structured complaint/disease specific HPI
  • Disease specific datasets
• Clinical research
  • Case report forms (CRF) and electronic data capture (EDC) in prospective clinical trials
  • Patient reported outcomes (PRO) and symptom diaries
  • Retrospective comparisons, case series, and other 'naturalistic' study designs
  • Ad hoc case-control analysis
• Automatic claims adjudication
• Provider credentialing and procedure logs

Publication format

UML (non-HL7 specific

All DCMs SHOULD have a non-HL7 UML2 Class diagram which uses the ISO 21090 data types to represent the components of the DCM. Class/element and attribute names should match those used in clinical practice. Value sets can be represented as an enumeration with or without specification of the contents. This is very similar, if not identical to, a very detailed domain model.

Project to Compare

At the Sept-2009 WGM we decided to create a project plan to determine if it would be feasible to compare the models in current use (e.g. UK NHS, South Korea's Center for Interoperable EHR, OpenEHR Archetypes, Intermountain Healthcare), and if so determine an approach for comparison/cataloging, and determine potential for harmonization efforts.

In-Progress DCM (examples)

• Chief complaint, presenting problem, and/or reason for visit
• History of present illness
• Review of systems / symptoms
• Prior/past medical history of disease / disorder
  • History of specific infectious disease
  • History of coronary artery disease
  • History of reactive airway or other obstructive lung disease (asthma, COPD)
  • History of cancer
  • Obstetric and current pregnancy history
  • History of psychiatric disorder
  • History of stroke
  • History of diabetes
  • History of drug allergy or intolerance
  • Birth and gestation history (primarily of interest in pediatrics)
  • Clinical sex
• History of specific procedure
• Physical exam finding
• Current medication use
• Entries in a health concern tracker / problem list / diagnostic impression / differential diagnosis
• Evaluation or treatment plan