This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Detailed Clinical Models"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
 +
[[Patient Care}}
 
[[Category:Patient Care]]
 
[[Category:Patient Care]]
 
[[Category:Templates]]
 
[[Category:Templates]]

Revision as of 18:30, 18 October 2009

[[Patient Care}}

Definition

A Detailed Clinical Model (DCM) is a formal specification of the semantics of discrete structured clinical information. It provides the data 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. The DCM does include the clinical knowledge on the concept, the data specification, a model and where possible, technical implementation specifications.

Implementation of DCM

DCM is considered to be a specification that is first independent of a specific technology. In other words, more or less agnostic to a particular standard or technology. However, DCMs are only useful when implementable. Thus the DCM does require additional work to have them fit into for instance and OpenEHR archetype model, a database schema, a user interface or a HL7 message or document or service.

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

New Work Item Proposal 13972 quality criteria and methodology for Detailed Clinical Models was accepted by ISO member states in July 2009. This standard does not focus on creation of DCM, but on guidance on how a DCM should look like, and criteria that need to be met. The ISO DCM International Standard is in its first stage of development during the ISO work group meeting in Durham, NC, Oct 2009.

Currently core components of the ISO DCM standard include:

1. assuring clinician engagement and endorsement.

2. the quality of the content that forms a proper DCM.

In particular the following criteria have been established in earlier discussions:

  • a proper DCM has meta information, including authorship and endorsing authority.
  • a proper DCM has a terminology binding which is slot based.

This means that a DCM can work with any terminology upon choice of user, e.g. with LOINC, or Snomed CT or ICD9 or ICD 10.

  • a proper DCM does include particular rubrics such as what is the concept, what is the goal for use in clinical practice, what is the supporting evidence, the full specification of data elements and relationships, the guidelines for appropriate use, interpretation guidelines, and where necessary guidance for the care planning around its use.

3. guidance on modeling of DCM, where UML will be used as example, but might not become normative.

4. quality measures for repositories of DCM in order to be able to store, index, find, retrieve, update and maintain DCM.

One item which will be discussed is how guarantees will be given for patient safety.

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.). Similarly, the use of assessment scales is in this space of clinical work. Assessment scales facilitate clinicians in their decision making. More explanation on that can be found in the Patient Care Care Provision topic of assessment scales.

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 or data element. 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 seems Snomed CT. Although Snomed CT is far from perfect, nor complete. 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). Alternatively, some concepts are best represented in another terminology, for instance the example of the Braden scale that is in the DCM examples section. The Braden scale, including each allowable value in the value set has been fully encoded in LOINC.

Selected use of other terminologies

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

Use cases

The major use case for DCM is to create a consistent data element specification for concepts that need to be entered in an Electronic Health Record (EHR) and in a Message. This makes the first use case the clinical documentation of findings. In addition the following purposes can be defined, which are use cases in their own right.

  • 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

Process

Publication format

The Netherlands has been creating examples of what is now called DCM since 2003. These examples have largely informed the current project and are available at www.zorginformatiemodel.nl. The format will be published soon, following discussions in Durham at ISO.

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.

Comment by William Goossen on this: This use of UML is agreed in the Patient Care committee and has many experts in favor of this. However, in particular the OpenEHR representatives challenge the use of UML. At this stage UML does allow to specify all characteristics of the examples we worked with. That cannot be done with an HL7 template as they currently exist. It can also not be done in the OpenEHR or CEN/ISO 13606 archetypes. So in order to be complete for the clinical material, we believe UML is appropriate. In particular because the CEN/ISO 13660 standard and the OpenEHR reference information models are in UML and a transform without loss of meaning can be assumed at this stage.

HL7 Template

Value sets

Metadata

DCM do require metadata. Which metadata are appropriate needs to be established. Currently we work with the list of metadata specification from HL7 templates and from the OpenEHR clinical knowledge manager.

Conformance

Project to Compare existing formats of DCM

At the May 2007 WGM in Cologne we decided to carry out a project to determine if it would be feasible to compare the models in current use (e.g. UK NHS, Dutch Care Information Models, New Zealand data specification, Tolven examples, OpenEHR Archetypes, Intermountain Healthcare), and if so determine an approach for comparison/cataloging, and determine potential for harmonization efforts. During the Sept 2009 WGM this was reconfirmed following a presentation from South Korea's Center for Interoperable EHR.