DCM Charter

Charter Section Two: DCM Charter Approach

Device DCM Project Charter

Charter Purpose

This charter states the direction of the HL7 project to develop a Domain Analysis Model (DAM) for medical devices. This DAM will include, in addition to the normal content for the domain, component representations in the form of a new specification, the Detailed Clinical Model (DCM).

The Project Scope Statement lays the foundation for the project; this document exists to clarify team members’ understandings of the specific activities. It is a living document and should be updated to reflect changing project direction.

This charter lists the specific activities and deliverables that the project will produce, and it describes the stakeholder organizations and their interests and responsibilities.

JL: I'm using italics to indicate text that's not intended as Charter but as discussion about what should go in the charter.

JL: Here, I emphasize a key need: some participants see the DAM as the artifact to produce, with some detailed packages serving as DCMs; others expect some sort of formalism from Patient Care project 320 (a.k.a. R4C?) to be the DCM artifact. These seem to me to be different assumptions. I outline some pros and cons, in which my bias will be clear, so please contribute:

DAM:

+ somewhat established

+ designed for clinical representation

+ well-known formalism

- may require enhancement

- vocabulary and constraint solutions not optimal

TBD:

+ designed for clinical representation

+ presumably will address DAM shortcomings

- not proven that it will address DAM shortcomings

- not yet established

Background

Clinicians need to be able to stipulate requirements for clinical data in a form that they can understand, both in order to participate in the requirements definition process and in order to ensure the quality of the resulting documentation. For a variety of reasons, existing formalisms for data modeling have proven inadequate to this task.

The idea of a Detailed Clinical Model is to meet that need. It is clinical in scope, so it represents the knowledge of the clinician rather than the software developer or data modeler. It is detailed; i.e., it specifies exactly the information needed by the clinician, leaving no room for ambiguity. And, as any requirements definition method must, it captures requirements in a consistent and rigorous formalism in order to support the development of technical specifications.

There are currently (April, 2010) two HL7 projects addressing the DCM concept. One, Patient Care DCM (project 320), focuses on defining the methodology of developing these artifacts, including not only the requirements capture, but also mechanisms for sharing and for automated conversion of DCMs into technical specifications. The second, Patient Care Medical Devices DAM (project ___), will develop a Domain Analysis Model for medical devices, with the expectation that this DAM will comprise a number of DCMs.

This charter is for the second project, Medical Devices DAM.

For conceptual boundaries between the DAM and DCM models, please see the Approach section.

MZ: My picture on the HL7 wiki!

JL: OK, logically, a DAM can aggregate DCMs, and if a DCM is a DAM package, I also understand that physically (it's another UML package) and conceptually (it's part of the DAM, not an external thing that the DAM references). If it's not (see above discussion on divergent assumptions on approach), I don't.

Stakeholders and Objectives

Business Owner

Who is driving and funding this activity?

AG: ?

JL: Any effort has to meet the requirements of the stakeholders, but "stakeholder" is a vague term that may include varying degrees of engagement. There are, however a small number (usually 1, sometimes 2-4) of stakeholders who are actually paying for the results and who should be kept first in mind when prioritizing work and ranking solution options. Do we know who they are?

Stakeholders

We need to differentiate between stakeholders, who are concerned enough to participate and on whose approval we stake success, and “interested parties,” whose needs we may need to recognize, but whose objectives cannot derail the project. This list aims to clarify which of the organizations in the PSS fall into which category.

The following stakeholders have been identified for this project.

• CEN TC 251

TC 251 is a CEN workgroup whose goal is to achieve compatibility and interoperability between independent systems and to enable modularity in Electronic Health Record systems.

This project will look to CEN TC 251 for [resources, requirements, endorsement?].

• ISO TC 215

TC 215 works on the standardization of Health Information and Communications Technology (ICT), to allow for compatibility and interoperability between independent systems.

This project will look to ISO TC 215 for [resources, requirements, endorsement?].

• IEEE 11073

ISO/IEEE 11073, Medical / Health Device Communication Standards, is a family of ISO, IEEE, and CEN joint standards addressing the interoperability of medical devices.

This project will look to IEEE 11073 for [resources, requirements, endorsement?].

• IHE PCD

IHE PCD is sponsored by the American College of Clinical Engineering (ACCE) and the Health Information Management Systems Society (HIMSS). It was formed in 2005 to address the integration of medical devices into the healthcare enterprise, from the point-of-care to the EHR, potentially resulting in significant improvements in patient safety and quality of care.

This project will look to IHE PCD for [resources, requirements, endorsement?].

• Veteran’s Health Administration

The Veteran’s Health Administration (VHA) shares the needs of clinicians for semantic interoperability and comprehensible requirements documentation. In order to meet this need, the VHA is supporting this HL7 project to develop DCMs. [resources, requirements, endorsement?]

• Health Level Seven (HL7)

HL7 supports the development of healthcare interoperability standards. It will provide the venues and processes for DAM development, and will serve as the sponsor for ANSI and ISO standard submission. [resources, requirements, endorsement?]

AG: I would like to see another ordening of these. It is HL7 with Patient Care en Health care devices WG. In PC there is a DCM project. So it is not about a different organization, but WG in the same organization.

JL: I had separated these because they have different representatives who may have different objectives and resources. HL7 has a stake, as do both workgroups, as well as the other PC project (320).

• Health Level Seven (HL7) Patient Care Workgroup

Patient Care is concerned with the delivery of care. As articulated in its mission statement, “The goal of Patient Care Working Group is to define the requirements and solutions to support the needs for communicating information regarding the creation, management, execution and the quality of care provision.” [resources, requirements, endorsement?]

• Health Level Seven Patient Care Workgroup DCM Project (Project 320)

HL7 Project 320 addresses the formalisms necessary for representing DCMs as well as mechanisms for administering and maintaining them and for transforming them into technical specifications. [resources, requirements, endorsement?]

MZ: R4C! Joint with ISO. Include in the HDF!

JL: Should we change references to "Patient Care Workgroup 320" to "R4C?" What's it stand for?

As for the HDF, include what? I'd think that what the R4C comes up with might be included, but we're building a model, not a method, I think.

• Health Level Seven (HL7) Health Care Device Workgroup

Health Care Devices is concerned with enterprise device integration, harmonizing models within HL7 and with ISO/IEEE and other national and international interoperability standards organizations. [resources, requirements, endorsement?]

• ISO/CEN/HL7/ CDISC / IHTSDO Joint Initiative

The Joint Initiative on SDO Global Health Informatics Standardization has been formed to enable common, timely health informatics standards by addressing and resolving issues of gaps, overlaps and counterproductive standardization efforts. [resources, requirements, endorsement?]

• HL7 Medical Product and Device Listing Project

According to its Wiki page, HL7 project 325 “will develop a standardized specification of the data elements and exchange format for the transmission of information that uniquely and certainly identifiers a medical product or device, wherever authorized for marketing, for the purposes of product listing/registration.” [resources, requirements, endorsement?]

Interested Parties

• XYZ

Any other person or organization concerned with the reporting or use of device data is also a stakeholder, and may participate in the development and balloting process, per the HL7 development process. Membership in HL7 is not required for participation, but is encouraged.

Objectives

The project has three primary objectives:

1. To create a domain analysis model, following the HL7 HDF process, for the description of the use of medical devices, including
   1. Measurement devices
   2. Procedural devices
   3. Life support devices
2. To construct, as part of this domain analysis model, and as a proof-of-concept for DCMs, component DCMs to represent specialized devices within the device domain
3. To define a formalism for the construction of DCMs,
   1. In the business context; i.e. in a platform-independent way
   2. In a way that can be registered for re-use and re-used in different contexts for different use cases

The formalism may resemble, to a greater or lesser extent, any number of existing formalisms. A fourth objective is mentioned in the scope statement, and will not be addressed by this project:

1. To construct, in support of all DCMs,
   1. A registry for DCM identification and reuse
   2. Tools to support transformation of DCMs into computable artifacts
      1. Clinical statement patterns
      2. HL7 templates
      3. openEHR archtypes.

This last objective is being addressed by the Patient Care DCM project, HL7 project 320.

AG: Re: #3, This is part of the ongoing work on ISO 13972 for as much as international voters accept a formalism for that. And Patient Care will continue to work on a formalism for construction in Enterprise Architect.

JL: Absolutely in agreement, subject to resolution of the big question in section one.

Scope

Clinical Scope

The scope of the DAM is the use of medical devices. The list of use cases below defines the dynamic scope of the model; the static scope will consist of those data elements necessary to support the use cases.

Domain requirements are scoped by use cases in the following areas:

• Timing automation: e.g., a device that takes a vital sign every hour; or ASTM case involving the ventilator that was turned off to take an x-ray
• Rule-based action: e.g,, the ASTM case involving the patient controlled analgesic (PCA) and blood pressure
• All-manual (the easy one) – e.g., glucometer: manually started, patient is manually identified, and the only automation is to record the result

MZ: XMI is there! Look very good at it to provide example.

These use cases involve the following settings:

• Hospital inpatient
• ICU
• OR
• Home care

These use cases involve the following device types:

• Measurement devices
• Procedural devices
• Life-support devices

Technical Scope

The project supports the modeling of clinical information. Values representing device model, state, capability, or other technical attributes will be addressed where they are necessary to the elicitation or interpretation of clinical data.

AG: There potentially need to be two DAMs models, one for the clinical content as described here, and another for the device itself as a manufactured product.

JL: I'm not sure what the answer to the clinical-vs-hardware question is, but it's likely to complicate the DAM-to-DCM package model, whichever assumption you make.

Charter Section Two: DCM Charter Approach