Clinical Quality Metadata Conceptual Model

US_2013DEC

Clinical Quality Common Metadata
Conceptual Model

Co-Chair: / Patricia Craig
Joint Comission

Co-Chair: / Floyd Eisenberg
iParsimony LLC

Co-Chair: / Crystal Kallem RHIA, CPHQ
Lantana Consulting Group

Co-Chair: / Chris Millet
National Quality Forum

Co-Chair: / Walter Suarez MD MPH
Kaiser Permanente

Editor: / Keith W. Boone
GE Healthcare

Contributor: / Aziz Boxwala

Contributor: / Bryn Rhodes

Contributor: / John Moehrke
GE Healthcare

Final
December 11, 2014

Table of Contents

1Introduction

1.1Purpose

1.2Audience

1.3Scope

1.4Approach

1.5How to use this Document

1.6Permissions

2Conceptual Data Types

2.1Basic Types

2.2Complex Types

3Common Metadata Attributes

3.1Purpose of Metadata attributes

4Metadata Classification

Appendix A —Common Metadata Mapping to Source Material

Page 1

Final1.0November 14, 2018

© 2014 Health Level Seven, Inc. All rights reserved.

Clinical Quality Metadata Conceptual Model

Clinical Quality Metadata Conceptual Model

1Introduction

Metadata is data about data. It is used to classify an information artifact (a document, message or other sort of communication) to enable that artifact to be retrieved, used, or quantified.

Within the Clinical Quality Improvement domain, there are several information models developed for HL7 standards which include metadata. These include specifications developed by various projects and workgroups, including:

  • Health eDecisions
  • Decision Support Services
  • Health Quality Measures Format
  • Virtual Medical Record
  • Quality Reporting Data Architecture
  • Templates
  • Clinical Document Architecture
  • Order Sets

There is a great deal of common metadata that has been reused across HL7 specifications, however, there is no single conceptual model for metadata presently within the HL7 family of standards.

1.1Purpose

The purpose of this specification is to identify a common model that shallbe used to derive and implement metadata information in D-MIMs and Logical Models in a consistent manner for any HL7 specifications impacting initiatives relevant to clinical quality improvement.It is expected that new editions of HL7 specifications addressing the Clinical Quality Improvement domain will use metadata that is derived from or extends the metadata elements found in this this specification.

1.2Audience

The primary audience for this document are HL7 standards developers. Secondary users include quality reporting agencies, regulatory Agencies, standards development organizations, payers, and healthcare IT vendors (e.g., EHR, PHR, Clinical Decision Support Systems) who want to understand metadata that appears in HL7 standards.

1.3Scope

This specification defines a common collection of metadata elements at a conceptual level that may be used to describe artifacts supporting clinical quality improvement. It further provides a high level classification of metadata categories and assigns those metadata elements to one or more metadata categories.

The purpose of this specification is to capture at a conceptual level the existing metadata concepts used by the specifications described in section 1.5Approach which are applicable to clinical quality improvement initiatives. No de novo concepts are being created by this specification.

1.3.1Future Work

The purpose of this project is to identify common metadata used across clinical quality improvement projects. It identifies requirements common to a number of different specifications. That may result in refactoring of future specifications in order to comply with this specification, but it is unknown at this time what those refactorings might be.

1.4Approach

The approach used in the development of this specification has been to review the following standards and specifications, and identify metadata elements in each so as to define the superset of all metadata attributes found in specifications used for Clinical Quality Improvement.

  • The Arden Syntax for Medical Logic Systems Version 2.9
  • HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, Release 1.1 - US Realm
  • CDA Release 2.0
  • HL7 Implementation Guide for CDA® R2: Quality Reporting Document Architecture - Category I (QRDA) DSTU Release 2 (US Realm)
  • CDA Release 3.0 (Draft)
  • HL7 Structured Documents Architecture (draft for ballot)
  • HITSP C80 Clinical Document and Message Terminology Section 2.1 Context Overview
  • HL7 Version 3 Standard: Clinical Decision Support; Virtual Medical Record (vMR) Logical Model, Release 2
  • HL7 Implementation Guide: Decision Support Service, Release 1
  • HL7 Version 3 Standard: Clinical Decision Support Knowledge Artifact Specification, Release 1.2
  • HL7 Version 3 Implementation Guide: Context-Aware Knowledge Retrieval Application (Infobutton), Release 4
  • HL7 Version 3 Standard: Order Set Publication, Release 1
  • HL7 Version 3 Standard: Representation of the Health Quality Measure Format (eMeasure) DSTU, Release 2
  • HL7 Version 3 Implementation Guide: Quality Data Model (QDM)-based Health Quality Measure Format (HQMF), Release 1 – US Realm
  • FHIR Infrastructure Resources
  • HL7 Version 3 Standard: Specification and Use of Reusable Constraint Templates, Release 2
  • HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1
  • IHE Document Sharing Metadata

These specifications were chosen because they define metadata about Clinical Quality Improvement artifacts.

In addition to these specifications, Metadata attributes described by Dublin Core were also reviewed. The Dublin Core is a small set of fifteen Metadata attributes which can be used to describe media resources including those available on the web or in print or other media formats. Because the Dublin Core is a well-recognized standard for metadata, it was incorporated into the set of specifications to be reviewed for this conceptual data model on metadata.

After identifying each of the metadata elements, definitions were assigned to each from the HL7 RIM or Vocabulary standards, along with a mapping to the source of the definition.

A collection of metadata categories was already established in IHE XDS. We have extended that collection and adapted it for general use. The metadata catalogued in this document was then assigned to one or more of these categories based on the original IHE category assignments and for those not assigned, by comparing them to similar metadata elements already assigned.

1.5Structure and use of this Document

In developing this specification, the authors are following the HL7 Service Aware Interoperability Framework (SAIF). In the SAIF model, this specification is intended to fill the role of a conceptual information model for metadata, becoming the basis for metadata used in more concrete specifications supporting Quality Improvement specifications in HL7.

This document is organized into the following sections:

1Introduction
This section.

2Conceptual Data Types

In the absence of a formally approved HL7 Conceptual Data Type specification, this section provides a small set of conceptual data types which are used by this specification to define the metadata attributes.

3Common Metadata

This section describes the common metadata attributes found in the reviewed specifications.

4Metadata Classification
Classifies the common metadata according to the purposes for which it is used.

1.6Permissions

Material in section 3.1Purpose of Metadata attributes is adapted from Section 4.1.3.1 The Purpose of Metadata Attributes (Informative) of Volume 3 Cross-Transaction Specifications and Content Specifications of the IHE IT Infrastructure Technical Framework and is used with permission.

1.7Acknowledgements

The authors wish to acknowledge members of the Clinical Quality Information Work Group who sponsored this specification, and of the Architectural Review Work Group, Arden Syntax Work Group, Clinical Decision Support Work Group, Structured Documents Work Group and the Templates Work Group who cosponsored it. In addition, we are grateful for the contributions of the following individuals.

Contributor / Organization
Aziz Boxwala / Melliorix
Bryn Rhodes / Veracity Solutions
Catherine Hoang / US Department of Veterans Affairs
Chris Millet / National Quality Forum
Clem McDonald / NLM/NIH
Crystal Kallem RHIA, CPHQ / Lantana Consulting Group
Floyd Eisenberg / iParsimony LLC
John Moehrke / GE Healthcare
John Moehrke / GE Healthcare
Kathleen Connor / Edmond Scientific Company
Keith Boone / GE Healthcare
Keith W. Boone / GE Healthcare
Kensaku Kawamoto, MD, PhD / University of Utah
Patricia Craig / The Joint Comission
Rick Geimer / Lantana Consulting Group
Thomson Kuhn / American College of Physicians
Walter Suarez MD, MPH / Kaiser Permanente

2Conceptual Data Types

Conceptual data types provide a high level definition of data types used within a conceptual specification such as this. The data types that follow provide a simplified conceptual view of data types referenced by this specification. In more concrete (e.g., implementable) specifications, thedata types below can be replaced with more concrete data types such as those found in the HL7 Abstract Data Types Release 2.0.

The Conceptual Model within this specification uses the conceptual data types described below.

2.1Basic Types

  • The basic data types used in this model are shown below. The name used within this specification is given in the first column.
  • An informative mapping to the HL7 Abstract Data Types is provided in the derivation column. The purpose of this column is to illustrate how these conceptual data types might be implemented in a more concrete specification.
  • The third column provides the conceptual definition for the type.

Table 1 Basic Conceptual Data Types

Name / Derivation / Description
Code / CD / A coded value
Identifier / II / A globally unique identifier
Name / PN / The name of a person
Number / Quantity / A real or integer number
Contact / ADDR or TELECOM / One or more addresses, phone numbers, or other means (e.g., e-mail) for contacting a person or organization
Set<Type / Set> / A set of values of the specified type
String / ST / A simple string
Timestamp / TS / A date or date time value

2.2Complex Types

The following complex types are used within this specification. The components of each type are provided in tables similar to those used for the basic types. The name column is the name of the component within the data type.

Tables within this section provide:

  • The name of the data type components,
  • The type used for each component,
  • The HL7 Abstract Data Type from which this was derived[1], and
  • A brief description of the component.
2.2.1TimeInterval

A time interval represents the period of time over which an event occurs.

Table 2 Time Interval Conceptual Data Type Components

Name / Type / Derivation / Description
Start / Timestamp / IVL_TS.start / The start of the interval
End / Timestamp / IVL_TS.end / The end of the interval
2.2.2Person

Derivation:Person

This class describes a person responsible for some activity. It has the following components.

Table 3 Person Conceptual Data Type Components

Name / Type / Derivation / Description
Identifier / Identifier / Person.id / A unique identifier for that party.
Name / Name / Person.name / The name of that party.
Role / Code / Role.code / The role played by that party.
Contact / Contact / Role.addr,
Role.telecom / Contact information for that party
Organization / Organization / Role.player / The organization the person is affiliated in when playing the role specified above.
2.2.3Organization

Derivation:Organization

An organization responsible for some activity. It has the following components.

Table 4 Organization Conceptual Data Type Components

Name / Type / Derivation / Description
Identifier / Identifier / Organization.id / A unique identifier for that party.
Name / String / Organization.name / The name of that party.
Contact / Contact / Organization.addr,
Organization.telecom / Contact information for that party
2.2.4System

Derivation:Device[2]

A system responsible for some activity. Note that System is presently used within this specification to identify an authoring device. It has the following components.

Table 5 Device Conceptual Data Type Components

Name / Type / Derivation / Description
Identifier / Identifier / Device.id / A unique identifier for the system. This may contain an FDA GUIDID or other device identifier.
Type / Code / Device.code / A code describing the type of system.
Name / String / Device.softwareName / The name for the system.
2.2.5Party

Either a Personor an Organization as described above.

2.2.6Entity

A Person, Organizationor System as described above that can be uniquely identified.

2.2.7Approval

The approval complex type is used to relate the approval identifier to the issuer of the approval.

Table 6 Approval Conceptual Data Type Components

Name / Type / Derivation / Description
Identifier / Identifier / N/A / The unique identifier of the approval.
Approver / Party / N/A / The party giving the approval
2.2.8Link

A link provides a reference from one artifact to another.

Table 7 Link Conceptual Data Type Components

Name / Type / Derivation / Description
Identifier / Identifier / Act.id / The identifier of the linked artifact
Address / Contact / Act.text.
reference / The location of the linked artifact
Link Type / Code / ActRelationship.
typeCode / The type of link

The table below describes some of the concepts that may be embodied in Link Type described above.

Table 8 Conceptual Types of Links

Concept / Derivation / Description
Structural Model / ActRelationship (typeCode=DEF) / Link to a model from which this artifact originates
Transformation / ActRelationship (typeCode=XFRM) / Used when the target artifact is a transformation of the source artifact
Replacement / ActRelationship (typeCode=REPL) / Used when the target artifact is replaced by this artifact.
Successor / ActRelationship (typeCode=SUCC) / Used when the target artifact succeeds this artifact.

Other relationships may be described using the Link type. For example, the Decision Support Services Implementation Guide describes links between artifacts using the following codes: USES_EVALUATION_RESULT_FROM, PROVIDES_EVALUATION_RESULT_FOR_USE_BY, PASSES_THROUGH_EVALUATION_RESULT_FROM, PROVIDES_EVALUATION_RESULT_FOR_PASS_THROUGH_BY. These code values could be used in the Link data type to provide these associations in metadata.

2.2.9Prior State

The prior state provides information about the previous status of a Metadata attribute.

Table 9 Prior State Conceptual Data Type Components

Name / Type / Derivation / Description
Status / Code / Act.statusCode / A prior state of the artifact, e.g., new, under development (active), published (complete), superseded (obsolete)
Time / Timestamp / N/A / The time of entry into that state.
User / Party / The party responsible for the transition into the state.

Page 1

Final1.0November 14, 2018

© 2014 Health Level Seven, Inc. All rights reserved.

Clinical Quality Metadata Conceptual Model

3Common Metadata Attributes

The table below describes common metadata appearing within HL7 specifications.

  • Each Metadata attribute in the table is given a simple name by which it can be recognized.
  • It is associated with a data type from the Conceptual Data Types section above.
  • The derivation column identifies the HL7 RIMclass, class attribute, or data type from which the Metadata attribute derives, providing an implementation hint about appropriate placement of the attribute in a Version 3 specification.
  • The final column describes the Metadata attribute.

Standards developers should consider these metadata attributes when creating or updating more concrete specifications for standards artifacts.

Name / Data Type / Derivation / Description
Instance Identifier / Identifier / Act.id / The unique identifier for the current version of the artifact.
Version Set Identifier / Identifier / ContextStructure
.setId / A unique identifier that remains constant across the set of all revisions that are derived from a common artifact.
Version Label / String / ContextStructure
.versionNumber / A label that uniquely identifies a specific version of the object within the set of revisions that are derived from a common artifact.
Title / String / Act.title / A word or phrase by which a specific artifact may be known among people.
Subjects / Set<Code or Set<String / Role.code
OR Role.text / A description of the subject or subjects of the artifact.
Subject Parties / Set<Entity / Participant
(typeCode = SBJ) / Identifies the subject or subjects of the artifact.
Subject Date Range / TimeInterval / N/A / The time period over which the activities described within the artifact occurred or was relevant. For example, the time period associated with a measure report.
Classification(s) / Set<Code / N/A / Classifications which may be useful for indexing the artifact in a retrieval system.
Task(s) / Set<Code> / Act.code / Tasks being performed by an entity that are relevant to this artifact.
Facility Type(s) / Set<Code / ServiceDelivery
LocationRoleType / A role of a place that further classifies the setting associated with the content of the artifact.
Clinical Specialties / Set<Code> / Role.code / Code(s) describing the area of medical specialty associated with the artifact.
Audience / Set<Code> / IntendedRecipient / A description of the anticipated audience for the artifact.
Purpose / String / N/A / An explanation of why the artifact exists.
Description / String / Entity.desc / A textual or multimedia depiction of the artifact
Usage / String / N/A / An explanation of how the artifact is to be used.
Audit / Set<Prior State> / HXIT<ANY> / Audit information showing state changes
Type of Artifact / Code / Act.code / The particular kind of artifact that the instance represents within its class of artifacts.
Artifact Format / Code / Act.text.mediaType / The MIME type describing the format of publication.
Artifact Structure / Code / N/A / A code further refining MIME type which indicates conformance to a particular structure.
(c.f., IHE Format Code, Arden Version)
Language(s) / Set<Code> / Act.languageCode / The language or languages in which this artifact is specified
Date of Creation / Timestamp / Act.activityTime
.low / The time of first activity on this artifact.
Date of Last Revision / Timestamp / Act.activityTime
.high / The time of last activity on this artifact.
Date of Last Review / Timestampe / N/A / The time of last review on this artifact.
Effective Date Range / TimeInterval / Act.effectiveTime / The operationally relevant time of the artifact, exclusive of administrative activity. For example, the time period for which a measure is valid.
Publication Date / Timestamp / N/A / The date of publication of the artifact. An artifact can be published prior to being effective.
Status / Code / Act.statusCode / The current state of the artifact, e.g., new, under development (active), published (complete), superseded (obsolete)
Prior Version / Link
<Replacement> / ActRelationship
(typeCode=REPL) / A specialization of link used when the target artifact is replaced by this artifact.
Successor / Link<Successor> / ActRelationship
(typeCode=SUCC) / A specialization of link used when the target artifact succeeds this artifact.
Security Tags / Set<Code> / Act
.confidentialityCode / Code(s) that identify how sensitive the artifact is and/or that indicate how the information may be made available or disclosed.
Integrity Verification / Number / ED.integrityCheck
ED.length / A method of verifying the integrity of data.
Author(s) / Class:Set<Person or Organization / Author / A party that originates the artifact and therefore has responsibility for the information given in it and ownership of it.
Authoring System(s) / Set<System> / Authoring Device / A device that originates the artifact.
Oversight Entities2 / Set<Party / Responsible Party, Authenticator / A person or organization responsible for oversight of an action. This entity can be authenticating, approving or providing other oversight.
Steward / Organization / Custodian / The organization that is in charge of maintaining the information of this artifact.
Publisher[3] / Party / Distributor / The distributor (publisher) of the artifact.
Rights / String / N / A / A statement of rights asserted on the artifact.
Repository Location / Address or Identifier / TELECOM / A telecommunications address or identifier which identifies the location of the repository where the artifact is stored.
Link(s) / Set<Link> / ActRelationship
(typeCode=REFR) / Links to or associations with other related artifacts. For example, artifacts created using Arden Syntax or HQMF may rely on definitions in other artifacts. The Link attribute allows these artifacts to be identified and the kind of relationship to be described.
Bibliographic Reference(s) / Set<String> / Document
.bibliographic-
DesignationText / A citation for a cataloged document that permits its identification, location and/or retrieval from common collections.
Value Sets / Set<Identifier> / CD.valueSet / The collection of value sets and concept domains that the artifact uses.
Enables searching for artifacts based on content of those value sets or uses of them or their respective concept domains. For example, show me all quality measures that use or are related to the results of a Hg A1C test.

Page 1