Detailed Clinical Models

return to: Patient Care

further to: Detailed Clinical Model project

further to: Detailed Clinical Model instance construction

further to: Detailed Clinical Model guidelines for creation

further to: DAM vs DCM vs SAIF

further to: Governance

Current Ballot of DCM Reconciliation

Patient care has just finalized the DCM ballot of sept 2010. Please refer to Ballot section of HL7. The reconciliation package is uploaded. Those who voted negatively are kindly requested to see if the reconciliation satisfies their comments and if so, to retract their negative votes.

Introduction

From ISO 13972 Draft

The need for semantic interoperability is driving developments in current healthcare information technology. Semantic interoperability is about the clear understanding of stored, used and communicated data and information by the users of this information, in particular patients and health care professionals. It is defined as: "Semantic interoperability means ensuring that the precise meaning of exchanged information is understandable by any other system or application not initially developed for this purpose” (EC Recommendation, COM (2008) 3282 final).

Semantic interoperability addresses issues of how to best facilitate the coding, transmission and use of meaning across seamless health services, between providers, patients, citizens and authorities, research and training (Semantic Health, 2009).In particular the standardization of clinical concept representation is the core development for future EHR and other health IT, and the communication between systems. This developments move towards obtaining information that is suitable for decision making on different levels in health care: both clinical and aggregate levels. The semantic interoperability implies that received data can be combined seamlessly with local data and processed homogeneously, and that clinical data from local and external systems can be combined and processed identically and collectively without loss of meaning.

Demographic developments, increasing demands for quality care, improvements in diagnostics and treatment, Evidence Based Practice, technology push, sustainability, cost containment, quality measurement, research, education, among other driving forces, require health care professionals to document increasingly numbers of data. Data seen as uninterpreted units for documentation. Of course, professionals apply the medical knowledge to interpret data and derive information from it. Healthcare Information Technology thus implies that the technology helps health professionals to obtain information from data by applying knowledge and making appropriate decisions for patients and practice. In particular the electronic health record (EHR, ISO 18308) is the core technology that can be based on a logical structure for health records and data can be entered systematically, applying healthcare terminologies that ensure the semantics of what is stored.

Increasingly, the hypothesis is uttered that data from an EHR can be reused for other purposes, such as continuity of care and decision support on the individual level, and quality measurement, management of healthcare institutions, epidemiology, among other purposes for secondary data use, based on comparison of populations and healthcare systems. Such hypothesis can only be confirmed if certain conditions are met. One sine qua non condition is adherence to privacy regulations and data security measures. That is assumed here, but not explored further. Another assumption is that the data to be aggregated are comparable indeed. That is the driving assumption for this standard, because it does require preciseness in meaning and in use in applications. The third assumption is that each purpose on an aggregate level requires its own context to be taken into account for valid and reliable decision making. In particular, algorithms, calculations for proper data handling, but also potential influencing factors. For management data management from EHR for instance, one needs to have knowledge on the architecture of the building in which care takes place, the workforce and so on. If data are interpreted for quality measurement, one needs to be aware of case-mix and regulations to interpret scores properly. For epidemiology, the characteristics of the population are core for proper interpretation of study data.

All purposes, both on clinical and aggregate levels, have in common that the semantics, the context, the care process, and the use in decision making determine how data are collected, stored, managed in an EHR and communicated.

Healthcare is used to classifications and terminologies to help in purposes of data collection. To a large extend, classifications can be seen as mainly developed for the aggregate purposes, and terminologies for clinical data in the EHR. However, these functions are more and more overlapping. Similarly, we see assessment sheets for clinical practice and registry forms, like minimum data sets, for the data collection. We also see that information modeling is applied as tool to organize data in healthcare information technology in general, and the EHR in particular. Two core examples are the Health Level Seven Reference Information Model , and the IS 13606-1 reference information model for the Electronic Health Record.

The underlying assumption for this standard on Detailed Clinical Models is that to use, exchange and reuse data, and to obtain meaningful information from it for each purpose, data need to be handled consistently. This consistent use is required on both the mono and multidisciplinary health professional level. But of course, consistency is not only necessary at the human level, but also at systems level such as the EHR itself, data exchange for continuity of care, and data warehouses or registries where the aggregated data are stored.

Definition

Conceptual definition

A Detailed Clinical Model (DCM) is an information model of a discrete set of precise clinical knowledge which can be used in a variety of contexts.

Structural definition

Detailed Clinical Models (DCM) are descriptions of items of clinical information that 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 modelers. This includes the potential for use in health care information and communication technology, for example in EHR, telehealth applications, messages, medical devices, computer algorithms, and deductive reasoning, decision support, among others. It provides unambiguous detail which is intended to be cross domain and cross discipline and standardized and reusable over domains, purposes, standards and implementations. DCM work currently includes clinical content analysis, quality assurance, information modeling, and repositories. DCM include the structural model. Dynamic models are handled elsewhere, but some aspects of dynamics might be in the DCM.

Contextual definition

To be completed with the context of DCM in HL7 SAIF.

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 purpose of Detailed Clinical Models are to provide precise semantic consistent data and terminology specification that are comparable and sharable between multiple care providers, health enterprises and standards-based Healthcare Information Technology (HIT).

The DCM can be used for multiple objectives. Examples of such objectives are:

• clinical data collection and communication
• clinical care
• continuity of care
• electronic exchange of information
• lifetime storage and retrieval linked to the context in which this took place
• quality measurement
• research
• management and policy making
• aggregation of data for other purposes
• among others.

A DCM is intended to be agnostic or neutral with respect to reference model and platform. For a DCM to be used in applications, it needs to be transformed into platform specific artefacts, for example HL7 templates or ISO 13606 or openEHR archetypes.

Concrete Objectives

Concrete objectives for DCM are:

• A DCM specifies clinical information for one or more sets of clinical concepts and their corresponding data elements and terminology. This with the goal of supporting the semantic interoperability between standards and technologies by means of expressing
  • their purpose in clinical care,
  • the evidence base,
  • data element specification,
  • proper execution,
  • interpretation of values,
  • literature references, supporting the concept and its evidence.

• DCM are a means to support Health Informaticians to understand the complex health care business.

• DCM further support Health Informaticians to understand clinical content necessary to design, create and maintain health care information and communication technologies.

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

• DCM are a means to integrate different standards with each other, in particular medical knowledge, terminology, workflow, and data modeling.

• DCM facilitate the secondary use of clinical data for research and epidemiological studies.

• DCM apply identified quality criteria for:
  • clinical content specification,
  • application of terminology, classification and unique coding,
  • language translations,
  • generic information modeling independent of a particular technical standard.

• DCM facilitates transformations via tooling from generic models to standards specific modeling and implementable formats.

• A DCM forms thus a common starting point between different technical representation formats, in particular between HL7 v3 templates / clinical statements and OpenEHR / IS 13606 archetypes.

• A DCM is not implementable by itself but requires another implementation technology to create a EHR, a message or medical device.

• A DCM informs 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.

Usage of DCM

Overall, the DCM supports 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 Interfaces

• 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 Measures and National Registries

• Specify clinical content and knowledge for use in Healthcare Guidelines and Protocols

• Specify clinical content for use in Medical, Health Care and Epidemiological Research

• Specify clinical content for use in Decision Support Systems

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.

Process

To be integrated with the above text. 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.

Model Driven Architecture MDA

DCM are part of a whole series of modeling efforts, starting from an enterprise view, via domain specifications to the smallest items of information, expressed in the DCM. If UML is applied, consistency at the different levels can be achieved, and traceability. A paper on this has been published in 2010:

Michael van der Zel & William Goossen (2010). Bridging the gap between software developers and healthcare professionals. Model Driven Application Development. Hospital Information Technology Europe, vol 3, no 2, pp 20-22.

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

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 has been submitted to the list and document section.
• HL7 DCMs may be published as Domain Analysis Models or SAIF Conceptual Models. Since DCMs are business-centric they may simply address the Business Viewpoint of a SAIF-conformant Conceptual Model. They can hold an informative Logical Model e.g. in UML format.

UML (non-HL7 specific)

• All DCMs SHOULD use standard-based UML2 for graphical representation (e.g. Class diagram which uses the ISO 21090 data types to represent the contents 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 debate 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. However, since is DCM is intended to represent the business viewpoint, it would beneficial to any communication with buseinss stakeholders to employ business terms.

CDA Template

A DCM may be used to constrain the clinical statements in a CDA-based document.

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

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.

Some aspects of this comparison are published as:

William Goossen, Anneke Goossen-Baremans, Michael van der Zel, (2010). Detailed Clinical Models: A Review. Healthc Inform Res. 2010 December;16(4):201-214. doi: 10.4258/hir.2010.16.4.201.

• Paper Available at this link

and

Goossen, W.T.F., Goossen-Baremans, A.T.M., (2010). Bridging the HL7 Template – 13606 Archetype gap with Detailed Clinical Models. In: C. Safran et al. (Eds.) MEDINFO 2010. Stud Health Technol Inform. 2010;160(Pt 2):932-6.

"CIMI Informatics-Modeling Terms, Tools and Their iEHR Use" paper edited by Stephen Hufnagel

• Current *.DOCX is at: http://informatics.mayo.edu/CIMI/index.php/Main_Page
• Current *.EAP is at: https://www.dropbox.com/s/69ca6zhjuxhrcdj/CIMI%20in%20iEHR-CIIF.eap

The Figure above shows CIMI (Clinical Information Model Initiative) containing

1. CIMs (Conceptually Independent Models aka Conceptual Models (CMs)) are the OpenEHR archetype models (AMs) and Mind Map Models (M3s) or NEHTA AMs and M3s CIC (Core Information Component),

2. PIMs (Platform Independent Models aka Logical Models) result when AMs and DCM are composed into “clinically useful” iEHR CLIMs (Common Logical Information Model) aka NEHTA-SCS (Structured Content Specifications), aka Hl7-CSPs Clinical Statement-Patterns) (e.g., discharge summary).

• Note that ADL AM and UML DCM “packages” have CIM and PIM parts.
• Ideally, published ADL AMs and UML DCMs can go through isosemantic transforms into each other’s representation. Most transforms are not 1:1, but need some extra information to do the transform.

3. PSMs (Platform Specific Models aka Implementable Models) result when CLIMS/SCSs/CSPs/AMs are composed into Clinical-Template, which add implementation details-and/or-constraints.

4. As an example, NEHTA creates CIC M3 and AMs, which, they transform into DCMs and group them into SCSs, which are transformed as Clinical-Template PSMs, such as CDA documents

5. On the surface the above steps seem straight forward; but in reality, ADL and UML model representations are based on radically different paradigms and models; and, they are created with entirely different processes; because, UML class inheritance-hierarchies are additive, while, ADL archetype constraint-hierarchies are subtractive.

6. Archetype advocates may argue that DCMs, without a reference model, can be inconsistent across organizations; while, DCM advocates may argue that archetypes have implementation details in their PIMs.

• This implies that, the OpenEHR and CIMI Reference Models (RMs) start with the universe of possible classes (and data elements (is this true for archetype data elements?)); then, they are constrained-down to meet specific clinical domain requirements; while,
• DCMs start with nothing or with subsets of classes from the FHIM or HL7 RIM; then, the class attributes are augmented by domain-specific inheritance.

7. CIMI productivity and reusability will be limited till its partners converge on standard informatics terms and model representations, processes, governance, configuration management, system-of-record repository, and “isosemantic” model transformations. The proposed OMG AML (Archetype Modeling Language) profile for UML, which includes ADL like features, to constrain models, is intended to help catalyze seamless sharing of models. The objective of the AML profile is to make UML sufficiently expressive to support the CIMI requirements.

• AML supports model-to-model transformations (ADL archetypes to UML and vice-a-versa)
• AML specifications support MDHT and commercial tool venders to include the AML UML-Profile

MODEL ACRONYMS

• AML Archetype Modeling Language UML-Profile
• BIM Business Information Model
• BPM Business Process Model
• CCS Care Coordination Service
• CDS Clinical Document Architecture
• CIMI Clinical Information Model Initiative
• CLIM Common Logical Information Model
• CIC Core Information Component (Mind Map)
• CPOE Computerized Physician Order Entry
• CSP HL7 Clinical Statement Pattern
• CTR Clinical-Template Repository
• CTS Common Terminology Service
• DAM Domain Analysis Model (DAM)
• DCM Detailed Clinical Model
• EHR-S FIM EHR System Function & Information Model
• ETL Extract, Transform, Load Service
• FHIM Federal Health Information Model
• FOC Final Operating Capability
• HDD Health Data Dictionary
• IBRM Integrated Business (activity) Reference Model
• I&FCM Inventory and Funds-Control Management
• iEHR Integrated Electronic Health Record
• IOC Initial Operating Capability
• Iz Immunization
• JPS JSR 286 Portlet Service
• JSR Java Specification Request
• MDHT Model Driven Health Tool
• NIEM National Information Exchange Model
• RDF Resource Description Framework
• RLUS Retrieve, Locate, Update Service
• RIM Reference Information Model
• RM Reference Model
• Rx Pharmacy
• SCS Structured-Content-Specification
• VDR Virtual Data Repository
• VPR Virtual Patient Repository

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 be represented and any quality criteria that need to be met by DCMs. 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.

Concern about commercial interests around DCM

In is unfortunate that while DCM is considered an open source initiative, based on harmonization 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 organizations to get this going. But is it still interested in this harmonization 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 organization.

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 organization 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 wgoossen@results4care.nl

William Goossen