Detailed Clinical Models

return to: Patient Care

further to: Detailed Clinical Model instance construction

further to: Detailed Clinical Model guidelines for creation

further to: DAM vs DCM vs SAEAF

further to: Governance

Concern about commercial interests around DCM

In is unfortunate that while DCM is considered an open source initiative, based on harmonisation principles between CDISC, CEN, ISO, and IHTSDO, some spread the rumor that it would be a vendor lock in / commercial endeavor. This is certainly not the case. HL7 was one of the supporting organisations to get this going. But is it still interested in this harmonisation work?

At the moment the Top 10 examples are provided by Nictiz for purpose of sharing. The are free to use by anyone. They must not be changed however. The intention of this material is to arrange an informative ballot in HL7, just like we do for the DAM's, but only covering a very detailed granular small piece of information.

Authorship is a key item in the DCM meta-information, it must be traceable where the DCM materials come from.

Endorsement is another key item in the meta-information in the DCM. Thus it becomes clear who applies this DCM in what kind of project or EHR etc.

Currently Nictiz is the copyright holder, just to be sure that it cannot be caught as a wild horse. The intention is to sort out copyrights on several levels.

1. In the DCM there needs to be a notification about copyrights of source materials modeled in the DCM.

2. We are working on a creative commons copyright solution that states: DCM are free to use, also in commercial systems. However, a DCM cannot be changed without involvement and agreement of the authors, and / or endorsing organisation.

If however, someone makes money out of creating DCM, or teaching etc. that is exactly as currently is done with HL7 standards at large. A lot of us make a living selling HL7 capable systems, or consultancy for implementation of messages or D-MIM and R-MIM development and so on. I believe that is a valid and supported way to move the HL7 organisation forward and to keep it alive.

At this stage I would recommend to not believe anyone that tells you that DCM is commercial. It is pertinently not. If some of HL7 membership think otherwise, then please contact me on williamtfgoossen@cs.com

William Goossen

Status of this Wiki and of DCM in and outside HL7 space

The material on this part of the wiki on DCM cannot be considered as 'owned' by HL7. In contrary, it is to a large extend not (only) HL7 material. This wiki page is hosted by HL7 WG Patient Care to discuss these matters, as a result of different WGM meetings where participants of OpenEHR, CEN, ISO, HL7 and researchers in the area requested that at least one of the organizations facilitate further work. The more neutral www.detailedclinicalmodel.org website is currently not always accessible for such discussions and in particular it does not facilitate file storage. Further, the DCM website is highjacked almost every other week, rendering it unsafe for our work.

The top 10 draft examples of DCM presented in the area further on in this HL7 PC wiki are formally owned by Nictiz, the Netherlands, with Results 4 Care employees being the authors. Nictiz has a charter to make this material publicly available after being finalized. Public consultation is part of the finalization to take place. Feedback from within the HL7 community and from outside the HL7 community will be solicited.

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.

5. Added in the dispositions on the New Work Item Proposal (July 2009) is an additional item on how to guarantee patient safety in specifications.

Definition

The Detailed Clinical Model (DCM) does include the clinical knowledge on the concept, the data specification, a model and where possible, technical implementation specifications. A DCM is a conceptual 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 logics, including the potential for use in computer algorithms. It provides unambiguous detail which is intended to be cross domain and cross discipline.

In the ISO 13972 standard for Quality Requirements and Methodologies for Detailed Clinical Models (DCM) it is described as follows: Detailed Clinical Models are small items of clinical, preventive and care information that are well defined and for which knowledge, data definition, vocabulary binding, and information model for use in information and communication technology are standardized and reusable over domains, purposes, standards and implementations (adapted from Brisbane workshop, 2007). DCM work currently includes clinical content analysis, quality assurance, information modeling, and repositories.

Purpose

(TSC Question 2 and 13). The purpose of DCM is suggested as follows:

The overal goal for DCM is to form a collection that will support the long-term goal of an automated standards-based information technology (IT) environment for the exchange of information supporting the process for clinical data collection and exchange to support continuity of care, aggregation of data and lifetime storage and retrieval, more or less independent of the actual technical implementations. (Nictiz discussion, January 2010).

Concrete objectives for DCM to be included in the ISO 13972 draft standard are:

1.    A DCM specifies clinical information to support semantic interoperability between standards and technologies by means of expressing for one or more small sets of clinical concepts / data elements, their purpose in care, the evidence base, data element specification, proper execution, interpretation of values, and literature references.

2.  DCM are a means to support  Health Informaticians to understand the complex health care business and understand the source knowledge to design, create and maintain health care information and communication technologies.

3.    DCM facilitate Re-usability of work carried out by clinicians to specify EHR and message content, independent of technology.

4.    DCM are a means to integrate different standards with each other, in particular medical knowledge, terminology, workflow, and datamodelling, in such a manner that security is maintained and technical implementation is facilitated.

5.    DCM apply identified quality criteria for clinical content specification, application of terminology, classification and unique coding, language translations, generic information modelling independent of a particular standard, and transformations via tooling from generic models to standards specific modelling and implementable formats.

6. A DCM  forms thus a bridge between different technical representation formats, in particular between HL7 v3 templates / clinical statements and OpenEHR / CEN ISO 13606 archetypes.

7.    A DCM is supposed to be informing technical designs and implementations of health care IT including GUI design, database design, HL7 message design, algorithm design, rule-based Decision Support System design, among others.

Functions of DCM

(TSC Q 8) Overall, the DCM tries to achieve the following functions:

=> specify clinical content for use in EHR

=> specify clinical content for use in HL7 messages, services and CDA

=> specify clinical content for user interface

=> specify clinical content for use in Medical Devices

=> specify clinical content for use as cost parameter in health care

=> specify clinical content for use as quality indicators and national registries

=> specify clinical content for use in medical guidelines and protocols

=> specify clinical content for use in medical and health care research

such that these specifications on the same concept are consistent for all these functions that it tries to achieve.

Methodology of DCM

(TSC Q 9) This is very draft and not discussed in ISO workgroup 1. The methodology is under construction but does include the following steps:

Clinicians identify the information requirements. In that requirements listing the list of data elements is analyzed and data elements are sorted out. What belongs together is determined to become one DCM. For instance data on blood pressure, the five observations and total score of the Apgar score and so on.

For each concept, it is defined, its purpose stated, evidence base summarized, instructions to get reliable and valid data are included and interpretation guidelines and references.

Next, the data are specified based on ISO 21090 and include: concept specification, parameter description, data type specification and code binding. Where applicable (CO, CD etc) a value set is specified.

In the third stage, UML modeling is applied, with a view on what eventually is necessary to transform this into a HL7 template or into an ISO/CEN 13606 archetype (ADl 1.2) or OpenEHR archetype (ADL 1.4). Transformations are currently started based on a UML to XMI export in Enterprise Architect (EA). This is ongoing work with the goal at end of 2010 to be able to input DCM content in EA, export it to XMI, import that into HL7 tooling for templates. This work is carried out partly in the University Hospital in Groningen.

Finally, for a complete set of DCM the work tries to ensure patient safety, maintenance, governance and distribution via repositories.

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.

TSC Q 24. Is a DCM an underspecified static model fragment, that says something about the clinical content of the static model, but nothing about attribution, identity criteria, version tracking, audit trail support and other such issues?

That is correct. DCM do need a RIM in 1360 and Open EHR to find a place in an EHR and a D-MIM / R-MIM to find a place in HL7 materials. Or alternatively, need a functional profile to fit in.

TSC Q 25. Is a DCM a static model that defines the Clinical Data Items, or is it a behavioural model that defines process, or is it both, or is it something else?

A DCM is preliminary a static model defining clinical data items, but also their medical evidence base and where applicable care process behavioral matters. It does not specify system behavior or process other than what is necessary for the content. E.g. it would specify that an Apgar score is derived from 5 single observation via calculating the 5 subscores to a total score. It would refer to clinical process to get reliable and valid data into EHR and into message.

HL7 DCM project 320 Scope statement

HL7 approved in 2008 project 320 on creation of DCM. Patient Care was requested in 2009 to update the scope statement. (TSC Q4). The updated scope statement was brought to vote during the Jan 2010 Steering Devision meeting and accepted. It will be brought to TSC for vote soon.

The overall goal of the DCM initiative is to develop methods, tools for requirements gathering with clinicians, requirements for modelling tools, quality control, identification of clinical items, binding of clinical content to terminology, model generically and transforms to different formalisms, authorisation and governance of DCM rules and maintain in a repository a set of DCM that are useable in different standards, formats and different technical implementations using the same generic model. The purpose is to enhance the semantic interoperability between different systems and developments.

Based on discussions in ISO Joint Working Group 9, the JWG leadership requested two projects to be started: one on creating a set of examples, useful in a standard, and two a set of criteria for good quality of DCM that are indeed clinically sound and implementable in different technical environments. Creating a Top 10 of DCM and discuss its use is HL7 project 320 on DCM, where this document is an update of. Establishing DCM criteria and methodologies is currently done under ISO NIWP 13972, which is approved July 2009.

The project scope within the HL7 community is is thus specifically to develop and maintain a set of Detailed Clinical Models (DCM). This has later been discussed as being the Top 10. This proposal is inclusive the proper representation of assessment scales, indexes and scoring systems that Patient Care has decided to take on as new project, and will use elements of other HL7 WGs or projects such as Terminfo, Structured Documents, Templates and Clinical Statement. One DCM includes the purpose of one or small set of clinical data elements, the evidence base, data element specification, proper procedure, interpretation of values, and literature references. A guideline for this has been created on behalf of Nictiz in the Netherlands.

A DCM specification must be usable within the HL7 Clinical Statement, and HL7 template specification, meet HL7 terminfo requirements, must be adjustable to the CEN/IOS 13606 and OpenEHR archetype environment, and the Clinical template specification, among others. Technical implementations that would be able to deploy DCM include GUI design, database design, HL7 message design, algorithm design, rule-based Decision Support System design, among others. In particular a DCM is to form a bridge between different technical representation formats, in particular HL7 v3 templates / clinical statements and OpenEHR archetypes. That is the harmonization aspect of DCM. In order to actually use a DCM, the transformation to HL7 must be made. This is done via mapping the DCM content to a Clinical Statement R-MIM, in any HL7 domain that uses Clinical Statement. The formalism to use a DCM in HL7 space would be that of an HL7 v3 template.

Current focus of DCM 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

Example

This example uses a non-normative HL7 "flavored" UML. UML is a notation which can express a wide range of detail and modeling rigor. While UML does have a very useful serialization (XMI), the principle use of UML remains communication between humans. Readers are asked for some indulgence in this regard. As the methodology evolves over time, it is likely that there will be a formalism which is shared between all parties to specify the clinical content in EHRs. In addition to the conventional use of UML in software engineering and the common use of specific tools in creation of domain analysis models, we should investigate some of the more advanced used, particularly the OMG's Ontology Definition Metamodel [www.omg.org/ontology/ ODM] which is supposed to be iso-semantic and transformable with OWL-DL.

Note: this example is released under conditions of the creative commons Share Alike with Attribution Non-Commercial license, with the exceptions that part may be covered under copyrights held by HL7 and/or IHTSDO which are included under fair-use. I will upload a better example when I can find the original (XMI) file --KevinCoonanMD 04:59, 27 October 2009 (UTC)

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

The purpose of the DCM development proces are to facilitate users to express their data requirements for EHR and data exchange and verify the standardisation processes, to facilitate endorsing authorities to endorse DCM as part of specifications for dedicated use of IT in health care,  express DCM, model DCM, transform DCM, apply appropriate slot bindings to terminologies, and apply meta information. Further, the inclusion of DCM in repositories and DCM governance and maintenance will be facilitated, in such a manner that patient safety is taken into account.

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.

There is some discussion about whether it is mandatory or required in HL7 terms. Tendency is to state that UML is plausible to model DCM in, but not mandatory. Other formalisms can be used as well. The right way to do it will be part of the future discussion.

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.

Project to Compare existing formats of DCM

Although this is an important part of DCM work to move it forward, it is on hold at this stage (January 2010).

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.