Detailed Clinical Models
- 1 Definition
- 2 Process
- 3 Publication format
- 4 Conformance
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.
DCM work at ISO
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
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
- ICD10, ICD10CM
- NCI thesaurus
- Nursing specific terminology (NANDA, NIC, NOC)
- Clinical decision support systems
- Disease / syndrome surveillance
- Quality of care metrics
- Generation of human user interface components
- 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
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.