HQMF DSTU R2_Working Document_2012_all_sections · Web view2012/07/18 · July 2012 Author dlloyd Created Date 07/18/2012 11:27:00 Title HQMF DSTU R2_Working Document_2012_all_sections

Health Quality Measures Format: eMeasuresHL7 V3 QM, R2

HL7 Version 3 Standard: Representation of the Health Quality Measures Format (eMeasure),

Release 2Draft Standard for Trial Use

V3_HQMF_DSTUR2_U1_2012SEP

July 2012

Diana Wright, 07/17/12,

“Release 2”Or “Release Two”?This sets the pattern for the whole document.

Author/Co-Chair Robert H. Dolin, MD, [email protected] Consulting Group

Co-Chair/Co-Editor

Calvin [email protected] Clinic/Foundation

Co-Chair Brett [email protected] Consulting Group

Co-Chair Austin [email protected] Consultant to CDC

Co-Chair Grahame [email protected] Computing Pty Ltd

Co-Editor Liora [email protected] Consulting Group

Co-Editor Keith [email protected] Healthcare Integrated IT Solutions

Co-Editor Gunther Schadow, [email protected] Institute, Inc

Co-Chair/Co-Editor

Robert A. Jenders, MD, MS, FACP, [email protected], Department of Medicine University of California, Los Angeles

Co-Editor Douglas S. Bell, MD, [email protected] Scientist, RAND Health Associate Professor of Medicine, David Geffen School of Medicine at UCLA

Co-Editor Floyd P. Eisenberg, MD, [email protected] Quality Forum

Co-Editor Christopher [email protected] Quality Forum

Co-Editor Gaye Dolin, MSN, [email protected] Consulting Group

Co-Editor Crystal Kallem, RHIA, [email protected] Consulting Group

Co-Editor Rick [email protected] Consulting Group

Co-Editor Jingdong (JD) Li, [email protected] Consulting Group

Co-Editor Chengjian Che, [email protected] Consulting Group

Co-Editor Dale [email protected] Consulting Group

Co-Editor Yan Heras, [email protected] Consulting Group

Co-Editor Stan [email protected]

Co-Editor Marc [email protected] Corporation

Co-Editor Nageshwara Bashyam (Dragon)[email protected] Corporation

Co-Editor Brian [email protected] Consulting Group

Tehcnical-Editor Diana [email protected] Consulting Group

Publishing Facilitator

Andy [email protected] Consulting Group

Last Published: 03/02/2010 11:08 AMContent Last Edited: 3/01/2010 10:56:20 PM

HL7(tm) Version 3 Standard, (c) 2010 2012 Health Level Seven(tm), Inc. All Rights Reserved.

HL7 and Health Level Seven are registered trademarks of Health Level Seven, Inc. Reg. U.S. Pat & TM Off


Andy ‑ Are these generated automatically when you post on the web?

Table of ContentsPREFACE................................................................................................................................15

Acknowledgements............................................................................................................15Changes from Previous Release ........................................................................................16

1 HQMF OVERVIEW............................................................................................................171.1 What is the HQMF, and what is an eMeasure?..........................................................171.2 Guidance for Measure Developers............................................................................171.3 HQMF and the quality life cycle................................................................................181.4 HQMF and Templated CDA........................................................................................191.5 Backwards Compatibility..........................................................................................191.6 General HQMF Concepts...........................................................................................19

1.6.1 Measure Period..................................................................................................191.6.2 Data Criteria......................................................................................................19

1.6.2.1 Filters and Data Criteria...............................................................................201.6.2.2 Time Relationships and Data Criteria...........................................................201.6.2.3 Value Sets and Data Criteria........................................................................20

1.6.3 Population Criteria.............................................................................................211.6.3.1 Population Criteria and Data Criteria............................................................22

1.6.4 Stratifier Criteria................................................................................................221.6.5 Human Readability and Rendering HQMF Documents.......................................241.6.6 Encoding eMeasure quality statements.............................................................25

1.6.6.1 General Approach........................................................................................251.6.6.2 Patient criteria vs. aggregate scores............................................................261.6.6.3 Measure definition vs. Reporting requirements............................................26

1.6.7 Data collection and missing data.......................................................................261.6.8 Relationship of the HQMF to HL7 Messaging Standards.....................................27

2 INTRODUCTION TO HQMF TECHNICAL ARTIFACTS..........................................................282.1 HL7 Reference Information Model.............................................................................282.2 V3 Data Types..........................................................................................................282.3 Concept Domains and Value Sets.............................................................................282.4 HL7 HQMF Model......................................................................................................292.5 HL7 HQMF Constraints..............................................................................................302.6 HL7 HQMF Hierarchical Description..........................................................................302.7 HL7 HQMF XML Implementation...............................................................................30


This TOC is for draft organization purposes only.Final TOC style and number of levels shown is up to Andy.

3 HQMF MODEL.................................................................................................................313.1 QualityMeasureDocument........................................................................................31

3.1.1 QualityMeasureDocument Attributes.................................................................323.1.1.1 QualityMeasureDocument.typeId.................................................................323.1.1.2 QualityMeasureDocument.classCode...........................................................323.1.1.3 QualityMeasureDocument.moodCode..........................................................323.1.1.4 QualityMeasureDocument.id........................................................................323.1.1.5 QualityMeasureDocument.code...................................................................323.1.1.6 QualityMeasureDocument.title.....................................................................333.1.1.7 QualityMeasureDocument.text.....................................................................333.1.1.8 QualityMeasureDocument.statusCode.........................................................333.1.1.9 QualityMeasureDocument.effectiveTime.....................................................333.1.1.10 QualityMeasureDocument.availabilityTime..................................................333.1.1.11 QualityMeasureDocument.languageCode....................................................343.1.1.12 QualityMeasureDocument.setId...................................................................343.1.1.13 QualityMeasureDocument.versionNumber...................................................34

3.1.2 QualityMeasureDocument Participations...........................................................343.1.2.1 QualityMeasureDocument.author................................................................343.1.2.2 author.typeCode..........................................................................................343.1.2.3 author.contextControlCode..........................................................................343.1.2.4 author.functionCode....................................................................................353.1.2.5 author.time..................................................................................................353.1.2.6 author.signatureCode..................................................................................353.1.2.7 author.responsibleParty...............................................................................353.1.2.8 responsibleParty.classCode..........................................................................353.1.2.9 responsibleParty.id......................................................................................353.1.2.10 responsibleParty.code..................................................................................353.1.2.11 responsibleParty.addr..................................................................................353.1.2.12 responsibleParty.telecom.............................................................................353.1.2.13 QualityMeasureDocument.custodian............................................................353.1.2.14 custodian.typeCode.....................................................................................363.1.2.15 custodian.contextControlCode.....................................................................363.1.2.16 custodian.responsibleParty..........................................................................363.1.2.17 QualityMeasureDocument.participation.......................................................363.1.2.18 participation.typeCode.................................................................................363.1.2.19 participation.contextControlCode.................................................................36

3.1.2.20 participation.functionCode...........................................................................363.1.2.21 participation.time.........................................................................................363.1.2.22 participation.signatureCode.........................................................................373.1.2.23 participation.responsibleParty......................................................................373.1.2.24 QualityMeasureDocument.verifier................................................................373.1.2.25 verifier.typeCode.........................................................................................373.1.2.26 verifier.contextControlCode.........................................................................373.1.2.27 verifier.functionCode....................................................................................373.1.2.28 verifier.time.................................................................................................373.1.2.29 verifier.signatureCode..................................................................................373.1.2.30 verifier.responsibleParty..............................................................................37

3.1.3 QualityMeasureDocument Relationships...........................................................373.1.3.1 QualityMeasureDocument.relatedDocument...............................................373.1.3.2 relatedDocument.typeCode.........................................................................383.1.3.3 relatedDocument.parentQualityMeasureDocument.....................................383.1.3.4 QualityMeasureDocument.componentOf......................................................383.1.3.5 componentOf.typeCode...............................................................................383.1.3.6 componentOf.qualityMeasureSet.................................................................383.1.3.7 QualityMeasureDocument.controlVariable...................................................383.1.3.8 controlVariable.typeCode.............................................................................383.1.3.9 controlVariable.localVariableName..............................................................383.1.3.10 controlVariable.measurePeriod....................................................................393.1.3.11 QualityMeasureDocument.subjectOf............................................................393.1.3.12 subjectOf.typeCode......................................................................................393.1.3.13 subjectOf.measureAttribute.........................................................................393.1.3.14 QualityMeasureDocument.definition............................................................393.1.3.15 definition.typeCode......................................................................................393.1.3.16 definition.valueSet.......................................................................................393.1.3.17 QualityMeasureDocument.component.........................................................393.1.3.18 component.typeCode...................................................................................393.1.3.19 component.contextConductionInd...............................................................393.1.3.20 component.section.......................................................................................393.1.3.21 component.measureDescriptionSection.......................................................403.1.1.1 component.dataCriteriaSection....................................................................403.1.3.22 component.populationCriteriaSection..........................................................403.1.3.23 component.measureObservationsSection....................................................40

3.2 ParentQualityMeasureDocument..............................................................................403.2.1 ParentQualityMeasureDocument Attributes.......................................................40

3.2.1.1 ParentQualityMeasureDocument.classCode.................................................403.2.1.2 ParentQualityMeasureDocument.moodCode................................................403.2.1.3 ParentQualityMeasureDocument.id..............................................................403.2.1.4 ParentQualityMeasureDocument.code.........................................................403.2.1.5 ParentQualityMeasureDocument.text..........................................................413.2.1.6 ParentQualityMeasureDocument.setId.........................................................413.2.1.7 ParentQualityMeasureDocument.versionNumber.........................................41

3.3 QualityMeasureSet....................................................................................................413.3.1 QualityMeasureSet Attributes............................................................................41

3.3.1.1 QualityMeasureSet.classCode......................................................................413.3.1.2 QualityMeasureSet.moodCode.....................................................................413.3.1.3 QualityMeasureSet.id...................................................................................413.3.1.4 QualityMeasureSet.title................................................................................41

3.4 MeasurePeriod..........................................................................................................413.4.1 MeasurePeriod Attributes..................................................................................42

3.4.1.1 MeasurePeriod.classCode.............................................................................423.4.1.2 MeasurePeriod.moodCode...........................................................................423.4.1.3 MeasurePeriod.code.....................................................................................423.4.1.4 MeasurePeriod.value....................................................................................42

3.5 MeasureAttribute......................................................................................................423.5.1 MeasureAttribute Attributes..............................................................................42

3.5.1.1 MeasureAttribute.classCode.........................................................................423.5.1.2 MeasureAttribute.moodCode.......................................................................423.5.1.3 MeasureAttribute.id.....................................................................................433.5.1.4 MeasureAttribute.code.................................................................................433.5.1.5 MeasureAttribute.value................................................................................43

3.6 ValueSet...................................................................................................................483.1.2 Value Set Identification, Versioning, and Stewardship.......................................483.6.1 ValueSet Attributes............................................................................................48

3.6.1.1 ValueSet.classCode......................................................................................483.6.1.2 ValueSet.moodCode.....................................................................................493.6.1.3 ValueSet.id...................................................................................................493.6.1.4 ValueSet.title...............................................................................................493.6.1.5 ValueSet.text...............................................................................................49

3.6.1.6 ValueSet.value.............................................................................................493.6.2 ValueSet Relationships......................................................................................49

3.6.2.1 ValueSet.component....................................................................................493.6.2.2 component.typeCode...................................................................................493.6.2.3 component.valueSet....................................................................................49

3.7 Section......................................................................................................................493.7.1 Section Attributes..............................................................................................49

3.7.1.1 Section.classCode........................................................................................493.7.1.2 Section.moodCode.......................................................................................493.7.1.3 Section.id.....................................................................................................503.7.1.4 Section.code................................................................................................503.7.1.5 Section.title..................................................................................................503.7.1.6 Section.text..................................................................................................503.7.1.7 Section.languageCode.................................................................................50

3.7.2 Section Participations........................................................................................503.7.2.1 Section.author..............................................................................................50

3.7.3 Section Relationships.........................................................................................503.7.3.1 Section.component1....................................................................................503.7.3.2 component1.typeCode.................................................................................503.7.3.3 component1.contextConductionInd.............................................................503.7.3.4 component1.section.....................................................................................51

3.7.4 Section Narrative Block.....................................................................................513.7.4.1 paragraph....................................................................................................513.7.4.2 list................................................................................................................513.7.4.3 table.............................................................................................................513.7.4.4 footnote, footNoteRef...................................................................................513.7.4.5 content.........................................................................................................523.7.4.6 styleCode.....................................................................................................523.7.4.7 sub and sup.................................................................................................533.7.4.8 br.................................................................................................................533.7.4.9 caption.........................................................................................................533.7.4.10 linkHTML......................................................................................................533.7.4.11 renderMultiMedia.........................................................................................54

3.8 MeasureDescriptionSection......................................................................................543.8.1 MeasureDescriptionSection Attributes...............................................................54

3.8.1.1 MeasureDescriptionSection.code.................................................................54

3.9 DataCriteriaSection...................................................................................................543.9.1 DataCriteriaSection Attributes...........................................................................55

3.9.1.1 DataCriteriaSection.code.............................................................................553.9.2 DataCriteriaSection Relationships......................................................................55

3.9.2.1 DataCriteriaSection.definition......................................................................553.9.2.2 definition.typeCode......................................................................................553.9.2.3 definition.actDefinition.................................................................................553.9.2.4 DataCriteriaSection.entry.............................................................................553.9.2.5 entry.typeCode............................................................................................553.9.2.6 entry.localVariableName..............................................................................553.9.2.7 entry.subsetCode.........................................................................................563.9.2.8 entry.actCriteria1.........................................................................................563.9.2.9 entry.actReference......................................................................................56

3.10 PopulationCriteriaSection..............................................................................563.10.1 PopulationCriteriaSection Attributes..................................................................62

3.10.1.1 PopulationCriteriaSection.code....................................................................623.10.2 PopulationCriteriaSection Relationships............................................................63

3.10.2.1 PopulationCriteriaSection.component..........................................................633.10.2.2 component.typeCode...................................................................................633.10.2.3 component.localVariableName....................................................................633.10.2.4 component.patientPopulationCriteria...........................................................633.10.2.5 component.numeratorCriteria......................................................................633.10.2.6 component.denominatorCriteria..................................................................633.10.2.7 component.denominatorExceptionCriteria...................................................633.10.2.8 component.numeratorExclusionCriteria.......................................................643.10.2.9 component. denominatorExclusionCriteria .................................................643.10.2.10 component.measurePopulationCriteria........................................................643.10.2.11 component.stratifierCriteria.........................................................................64

3.11 MeasureObservationsSection........................................................................643.11.1 MeasureObservationsSection Attributes............................................................64

3.11.1.1 MeasureObservationsSection.code..............................................................643.11.2 MeasureObservationsSection Relationships.......................................................65

3.11.2.1 MeasureObservationsSection.definition.......................................................653.11.2.2 definition.typeCode......................................................................................653.11.2.3 definition.measureObservationDefinition.....................................................65

3.12 Model Definitions...........................................................................................65

3.12.1 Definition Attributes..........................................................................................653.12.1.1 ActDefinition.classCode................................................................................653.12.1.2 ActDefinition.moodCode..............................................................................653.12.1.3 ActDefinition.id............................................................................................66

3.13 Criteria..........................................................................................................663.1.3 Processing Order for Entries in the Data Criteria section...................................693.13.1 ActCriteria Attributes.........................................................................................70

3.13.1.1 ActCriteria.classCode...................................................................................703.13.1.2 ActCriteria.moodCode..................................................................................703.13.1.3 ActCriteria.actionNegationInd......................................................................703.13.1.4 ActCriteria.id................................................................................................703.13.1.5 ActCriteria.code...........................................................................................703.13.1.6 ActCriteria.derivationExpr............................................................................703.13.1.7 ActCriteria.title.............................................................................................703.13.1.8 ActCriteria.text.............................................................................................703.13.1.9 ActCriteria.statusCode.................................................................................703.13.1.10 ActCriteria.effectiveTime..............................................................................713.13.1.11 ActCriteria.activityTime................................................................................713.13.1.12 ActCriteria.availabilityTime..........................................................................713.13.1.13 ActCriteria.priorityCode................................................................................713.13.1.14 ActCriteria.confidentialityCode.....................................................................713.13.1.15 ActCriteria.repeatNumber............................................................................713.13.1.16 ActCriteria.uncertaintyCode.........................................................................713.13.1.17 ActCriteria.reasonCode................................................................................713.13.1.18 ActCriteria.languageCode............................................................................713.13.1.19 ActCriteria.isCriterionInd..............................................................................71

3.13.2 ActCriteria Participations...................................................................................713.13.2.1 ActCriteria.participation...............................................................................713.13.2.2 participation.patient.....................................................................................713.13.2.3 participation.role..........................................................................................72

3.13.3 ActCriteria Relationships....................................................................................723.13.3.1 ActCriteria.definition....................................................................................723.13.3.2 definition.typeCode......................................................................................723.13.3.3 definition.actReference................................................................................723.13.3.4 ActCriteria.excerpt.......................................................................................723.13.3.5 excerpt.typeCode.........................................................................................72

3.13.3.6 excerpt.inversionInd....................................................................................723.13.3.7 excerpt.sequenceNumber............................................................................733.13.3.8 excerpt.subsetCode.....................................................................................733.13.3.9 excerpt.actCriteria1.....................................................................................743.13.3.10 excerpt.actReference...................................................................................743.13.3.11 ActCriteria.temporallyRelatedInformation....................................................743.13.3.12 temporallyRelatedInformation.typeCode.....................................................753.13.3.13 temporallyRelatedInformation.sequenceNumber.........................................763.13.3.14 temporallyRelatedInformation.pauseQuantity..............................................763.13.3.15 temporallyRelatedInformation.localVariableName.......................................783.13.3.16 temporallyRelatedInformation.subsetCode..................................................783.13.3.17 temporallyRelatedInformation.actCriteria1..................................................783.13.3.18 temporallyRelatedInformation.actReference................................................783.13.3.19 ActCriteria.sourceOf.....................................................................................78

3.14 EncounterCriteria..........................................................................................783.14.1 EncounterCriteria Attributes..............................................................................78

3.14.1.1 EncounterCriteria.admissionReferralSourceCode.........................................783.14.1.2 EncounterCriteria.lengthOfStayQuantity......................................................783.14.1.3 EncounterCriteria.dischargeDispositionCode...............................................78

3.15 ObservationCriteria.......................................................................................803.15.1 ObservationCriteria Attributes...........................................................................80

3.15.1.1 ObservationCriteria.value............................................................................803.15.1.2 ObservationCriteria.valueNegationInd.........................................................803.15.1.3 ObservationCriteria.interpretationCode.......................................................803.15.1.4 ObservationCriteria.methodCode.................................................................803.15.1.5 ObservationCriteria.targetSiteCode.............................................................80

3.16 ProcedureCriteria..........................................................................................803.16.1 ProcedureCriteria Attributes..............................................................................80

3.16.1.1 ProcedureCriteria.methodCode....................................................................803.16.1.2 ProcedureCriteria.approachSiteCode...........................................................813.16.1.3 ProcedureCriteria.targetSiteCode................................................................81

3.17 SubstanceAdministrationCriteria...................................................................813.17.1 SubstanceAdministrationCriteria Attributes.......................................................81

3.17.1.1 SubstanceAdministrationCriteria.methodCode.............................................813.17.1.2 SubstanceAdministrationCriteria.approachSiteCode....................................813.17.1.3 SubstanceAdministrationCriteria.targetSiteCode.........................................81

3.17.1.4 SubstanceAdministrationCriteria.routeCode................................................813.17.1.5 SubstanceAdministrationCriteria.doseQuantity............................................813.17.1.6 SubstanceAdministrationCriteria.rateQuantity.............................................813.17.1.7 SubstanceAdministrationCriteria.doseCheckQuantity..................................813.17.1.8 SubstanceAdministrationCriteria.maxDoseQuantity....................................823.17.1.9 SubstanceAdministrationCriteria.administrationUnitCode............................82

3.18 SupplyCriteria................................................................................................823.18.1 SupplyCriteria Attributes...................................................................................82

3.18.1.1 SupplyCriteria.quantity................................................................................823.18.1.2 SupplyCriteria.expectedUseTime.................................................................82

3.19 References....................................................................................................823.19.1 ActReference Attributes.....................................................................................82

3.19.1.1 ActReference.classCode...............................................................................823.19.1.2 ActReference.moodCode..............................................................................823.19.1.3 ActReference.id............................................................................................82

3.20 PatientPopulationCriteria...............................................................................823.20.1 PatientPopulationCriteria Attributes...................................................................83

3.20.1.1 PatientPopulationCriteria.classCode.............................................................833.20.1.2 PatientPopulationCriteria.moodCode............................................................833.20.1.3 PatientPopulationCriteria.id..........................................................................833.20.1.4 PatientPopulationCriteria.code.....................................................................833.20.1.5 PatientPopulationCriteria.isCriterionInd.......................................................83

3.20.2 PatientPopulationCriteria Relationships.............................................................833.20.2.1 PatientPopulationCriteria.precondition.........................................................833.20.2.2 precondition.conjunctionCode......................................................................843.20.2.3 precondition.Grouper...................................................................................843.20.2.4 precondition.actReference...........................................................................84

3.21 NumeratorCriteria.........................................................................................843.21.1 NumeratorCriteria Attributes.............................................................................84

3.21.1.1 NumeratorCriteria.code...............................................................................843.22 DenominatorCriteria......................................................................................84

3.22.1 DenominatorCriteria Attributes..........................................................................843.22.1.1 DenominatorCriteria.code............................................................................85

3.23 DenominatorExceptionCriteria......................................................................853.23.1 DenominatorExceptionCriteria Attributes..........................................................85

3.23.1.1 DenominatorExceptionCriteria.code.............................................................85

3.23.2 DenominatorExceptionCriteria Relationships.....................................................853.23.2.1 DenominatorExceptionCriteria.precondition................................................853.23.2.2 precondition.conjunctionCode......................................................................853.23.2.3 NumeratorExclusionCriteria.........................................................................853.23.2.4 DenominatorExclusionCriteria......................................................................86

3.24 StratifierCriteria.............................................................................................863.24.1 StratifierCriteria Attributes................................................................................86

3.24.1.1 StratifierCriteria.code...................................................................................863.24.2 StratifierCriteria Relationships...........................................................................86

3.24.2.1 StratifierCriteria.precondition.......................................................................863.24.2.2 precondition.conjunctionCode......................................................................87

3.25 measurePopulationCriteria............................................................................873.25.1 measurePopulationCriteria Attributes................................................................87

3.25.1.1 measurePopulationCriteria.code..................................................................873.26 Logical Groupers...........................................................................................87

3.26.1 Grouper Attributes.............................................................................................883.26.1.1 Grouper.classCode.......................................................................................883.26.1.2 Grouper.moodCode......................................................................................883.26.1.3 Grouper.id....................................................................................................88

3.26.2 Grouper Relationships.......................................................................................893.26.2.1 Grouper.precondition...................................................................................893.26.2.2 precondition.typeCode.................................................................................893.26.2.3 precondition.conjunctionCode......................................................................893.26.2.4 Precondition.negationInd.............................................................................893.26.2.5 precondition.Grouper...................................................................................893.26.2.6 precondition.actReference...........................................................................89

3.27 measureObservationDefinition......................................................................893.27.1 measureObservationDefinition Attributes..........................................................92

3.27.1.1 measureObservationDefinition.classCode....................................................923.27.1.2 measureObservationDefinition.moodCode...................................................923.27.1.3 measureObservationDefinition.id.................................................................923.27.1.4 measureObservationDefinition.code............................................................923.27.1.5 measureObservationDefinition.derivationExpr.............................................933.27.1.6 measureObservationDefinition.methodCode................................................93

4 DEFINITIONS...................................................................................................................954.1 General Definitions...................................................................................................954.2 Measure Parameter Definitions.................................................................................954.3 Reporting Parameter Definitions...............................................................................964.4 Quality Measure Scoring...........................................................................................974.5 Quality Measure Types.............................................................................................97

5 EXAMPLES......................................................................................................................985.1 eMeasure Example Files...........................................................................................985.2 Sample HQMF Rendering Style Sheet.......................................................................985.1 Using Occurrences of QDM in HQMF.........................................................................98

6 HQMF SCHEMA.............................................................................................................101

Table of FiguresTable of Tables


Lantana’s HL7 IG style includes a Table of Tables.Should we do that for this IG?


Lantana’s HL7 IG style includes a Table of Figures.Should we do that for this IG?

PREFACE

AcknowledgementsThis project was originally supported by volunteer efforts and through the National Quality Forum’s (NQF, www.qualityforum.org) contract with the U.S. Department of Health and Human Services to promote the effective use of Electronic Health Record (EHR) systems. In addition, tThethe Collaborative for Performance Measure Integration with EHR Systems ("Collaborative"), co-sponsored by the American Medical Association (AMA), and the National Committee for Quality Assurance (NCQA), and the Electronic Heath Record Association (EHRA), developed the an HQMF reference guide, a prototype to address performance measure functionality and integration with EHR systems. The HQMF prototype defined a standardized way of expressing performance measures while preserving the clinical intent of the measure itself. In spring 2009, NQF sponsored efforts to align take the prototype HQMF and align it with HL7 constructs. This draft HL7 standard was originally produced through volunteer efforts and the Health Quality Measure Format (HQMF) project sponsored by the NQF. Release 2 updates were sponsored by the Office of Clinical Standards and Quality of the Centers for Medicare and Medicaid Services (CMS) in partnership with Health Level Seven (HL7) and the Office of the National Coordinator (ONC). The project was carried out within the framework of ONC’s Standards and Interoperability (S&I) Framework Query Health Technical Workgroup.The design of this specification was produced over the course of 22 multiple interdisciplinary stakeholder sessions using an open and transparent process to ensure broad stakeholder input. The following individuals were instrumental in guiding the project so that alignment occurred between interested organizations:

Chad Bennett, Iowa Foundation for Medical CareTelligen Kevin Coonan, Dana-Farber Cancer Institute Patty Craig, The Joint Commission Aaron Cutshall, Indiana Health Information Exchange Lori Fourquet, eHealth Sign Paul Fu, Illumisys William Goossen, Results 4 Care Kendra Hanley, American Medical Association Delane Heldt, American Medical Association Joy Kuhl, Child Health Corporation of America Thom Kuhn, American College of Physicians Cecil Lynch, OntoReason, LLC Susan Matney, University of Utah Health Care Lloyd McKenzie, LM&A Consulting / HL7 Canada Greg Pawlson, National Committee for Quality Assurance Jacob Reider, Allscripts Phil Renner, National Committee for Quality Assurance Dan Russler, Oracle Corporation Harry Solomon, GE Healthcare David Stumpf, United Health Julie Thompson, Nationwide IT Services, Inc. Jim Unander, American Medical Association

crystal.kallem, 07/17/12,

Many of these individuals are no longer with some of these organizations. Do we remove this section, remove affiliations, or update affiliations?

http://www.qualityforum.org/

The co-editors also express their appreciation for the support and sponsorship of the HL7 Structured Documents Working Group. We acknowledge the work on HL7 Version 3 and the Reference Information Model (RIM), and the contributions from HL7 domain committees, especially the Clinical Decision Support, Patient Care, and Modeling and Methodology Working Groups. Finally, we acknowledge the foundational work on the HQMF, initially a prototype of by the Collaborative for Performance Measure Integration with EHR Systems (a collaborative of the American Medical Association, the National Committee for Quality Assurance, and the Electronic Health Records Association); and the RAND's work on a Performance Measure Reporting Language (PMRL) for representing performance measures in a computer-interpretable and sharable format. This material contains content from SNOMED CT® (http://www.ihtsdo.org/snomed-ct/). SNOMED CT is a registered trademark of the International Health Terminology Standard Development Organisation (IHTSDO).This material contains content from LOINC® (http://loinc.org). The LOINC table, LOINC codes, and LOINC panels and forms file are copyright © 1995-2010, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee. All are available at no cost under the license at http://loinc.org/terms-of-use.

Changes from Previous Release


Moving to the appendix

http://loinc.org/terms-of-use

http://loinc.org/

http://www.ihtsdo.org/snomed-ct/

[1] HQMF OVERVIEW"If you cannot measure it, you cannot improve it." — Lord Kelvin (1824-1907)

1.1 What is the HQMF, and what is an eMeasure?The Health Quality Measures Format (HQMF) is a standard for representing a health quality measure as an electronic document. A quality measure is a quantitative tool that provides an indication of an individual or organization’s performance in relation to a specified process or outcome via the measurement of an action, process, or outcome of clinical care. Quality measures are often derived from clinical guidelines and are designed to determine whether the appropriate care has been provided given a set of clinical criteria and an evidence base. Quality measures are also often referred to as performance measures or quality indicators. Through standardization of a measure's structure, metadata, definitions, and logic, the HQMF provides for quality measure consistency and unambiguous interpretation. A health quality measure encoded in the HQMF format is referred to as an "eMeasure". Standardization of document structure (e.g. sections), metadata (e.g. author, verifier), and definitions (e.g. "numerator", "initial patient population") enables a wide range of measures, currently existing in a variety of formats, to achieve at least a minimal level of consistency and readability, even if not fully machine processable. From there, a formal representation of the clinical, financial, and/or administrative concepts and logic within an eMeasure support unambiguous interpretation and consistent reporting. Examples of statements that can be formally represented by the HQMF include:

To be included in a measure's Denominator. , a patient will have had at least two face face-to to-face visits; AND will have a confirmed diagnosis of coronary artery disease (based on diagnostic or procedure criteria).; To be included in a measure's Initial Patient Population, a patient will have had a principal inpatient discharge diagnosis of stroke; AND a hospital length of stay less than or equal to 120 days.

1.2 Guidance for Measure DevelopersCreating eMeasures in HQMF format requires measure developers to adopt a programmer’s mind set. Measure developers must consider how a measure will be executed by a processing engine. This process is similar to constructing an SQL query. HQMF is effectively a declarative programming language, and like any such language it is possible to create code that is syntactically correct but contains unanticipated bugs or side effects, or simply does not make logical sense. As HQMF processing engines become more available, we envision that measure developers will need to adopt many of the practices common to software development, such as integrating testing with the development process.

[1.3] HQMF and the quality Quality life Life cycleCycleHQMF is one component of a larger quality measure framework, as shown in the following figure.

Figure 12: Quality Measure measure Frameworkframework

Measure developers, often drawing upon available evidence, devise measureable parameters to gauge the quality of care in a particular area. These measureable parameters are assembled into quality measures, which are then expressible expressed as eMeasures in HQMF format. eMeasures may be understood by providersused to guide optimal care, and as well as to guide collection of data for Electronic Health Record (EHR) and other datasystems. The data, which is are then assembled into quality reports (e.g., HL7 CDA R2 Quality Reporting Document Architecture) and submitted to quality reporting or other organizations. Unambiguous expression of concepts and logic within an eMeasure is a necessary step towards the larger objective of automatically enabling a direct query against an EHR or other operational data store. While HQMF is not an EHR query language, through the provision of unambiguous and formal definitions, it is an EHR query enabler. Additionally, an unambiguous representation of the clinical concepts in an eMeasure allows EHR vendors and healthcare providers to be proactive in capturing such information at the point of care. If, for instance, a quality measure reports on the provision of educational material to stroke patients, the corresponding eMeasure will make it clear exactly what type of educational care provisionmaterial would be considered appropriate care. If the eMeasure calls for the collection of a certain data element not normally captured by the EHR, the EHR might now prompt the user in some way to provide collect this information, thereby enhancing not only the quality of data reporting, but also the quality of care. HQMF, like the HL7 Clinical Document Architecture (CDA) standard, is derived from an overarching Structured Document Architecture. HQMF is not a CDA standard, but rather, has a peer-to-peer relationship with CDA.

1.3[1.4] HQMF and Templated CDAHQMF criteria can have an association to a CDA template. For example, the National Quality Forum maintains a set of Quality Data Element (QDE) patterns that can be used in HQMF criteria. The HL7 Quality Reporting Document Architecture CDA Implementation Guide Release 2 maintains a mapping of QDE pattern identifiers to QRDA templates that supply the

Yan Heras, 07/17/12,

Added “Release 2”. Since the QRDA R2 is dramatically different from R1, and the mapping is in R2.


Ref and location needed

data for the corresponding pattern. An HQMF instance will not directly reference a CDA template, but can contain the criteria id, and the relationship between the two can be asserted outside the HQMF document itself. See the QRDA Implementation Guide Release 2 for a complete description of this approach.

1.4[1.5] Backwards CompatibilityThe use of HL7 R2 data types R2 and user friendly “business names” prevent HQMF R2 from being directly backwards compatible with HQMF R1. We envision that backwards and forwards compatibility will be handled via transforms. Prototype transforms have already been developed and tested with significant success, but complex HQMF R1 measures may still require some manual work for a successful migration to HQMF R2.

1.5[1.6] General HQMF ConceptsThis section serves as a high-level introduction to the concepts used within an eMeasure document, all of which are described in greater detail again and in greater detail later onin later sections. The intent here is to familiarize the reader with the high-level concepts to facilitate an understanding of the sections that follow.

1.5.1[1.6.1] Measure PeriodEvery quality measure has a Measure Period. The Measure Period for a quality measure designates the reference time frame based on which data is are identified, filtered and analyzed. Data that is are collected before or after the Measure Period can also be identified with a time relationship which will be explained in the next section.

1.5.2[1.6.2] Data CriteriaThe Data Criteria of a quality measure identify the various constraints and filters that can be applied on the data to identify populations. For example:

“Identify the number of people between the ages of 20 – 30 years” narrows the universe of population down to just those who are between 20 and 30 years.

“Identify people who had a hbA1C test as part of last visit” “Identify people with Diabetes type II condition”

Data Criteria can be defined on the following clinical data elements. Patient Demographics Encounters Medications Lab Results Vital Signs Problems Procedures Allergies Immunizations


Suggest to use “Measurement Period” throughout instead to be consistent with the blueprint and the human readable.


Need a reference and location for this.


“template id” ? or other id?

1.5.2.1[1.6.2.1] Filters and Data CriteriaFilters can be applied on Data Criteria to further refine the data criteria to identify populations. For example:

Identify people who have a hHbA1C value > 9% in the most “RECENT” lab test Identify the “FIRST” encounter where the patient was diagnosed with Diabetes

Type II.In the above examples “RECENT” and “FIRST” are examples of filters that can be applied to initial data criteria to refine and extract the population of interest.

1.5.2.2[1.6.2.2] Time Relationships and Data CriteriaData Criteria can be related to other Data Criteria or Measure Period via time relationships. For example: The following examples show how an encounter can have a temporal relationship with other Data Criteria or a Measure Period.

Identify the lab test which occurs occurred one year before the most recent encounter

The example relates the encounter with the lab test temporally Identify encounters encounters where a particular medication was requested

during the Measure PeriodThe example relates encounters where medications was requested to the Measure Period temporally

[1.6.2.3] Value Sets and Data CriteriaQuality Measures often need to select patients based on enumerated features of demographics, encounters, medications or other criterion criteria that span a range of coded values. These ranges of coded values are represented as Value Sets and are used to filter out populations. A Value Set has a unique identifier that is assigned by the owner of the Value Set. These identifiers are referenced within the Data Criteria and included within the eMeasure. The exact representation will be described later in the this document.An example of a Value Set is:

A Value Set for Diabetes Type II from National Quality Forum (NQF) is identified by 2.16.840.1.113883.3.464.1.37 and contains codes from SNOMED-CT, ICD-9-CM and ICD-10-CM vocabularies defining the various types of conditions that get designated as Diabetes.

This Value Set includes codes for conditions such as Diabetes Mellitus, Diabetes with ketoacidosis, type II or unspecified type, not stated as uncontrolled etc.

1.5.2.3[1.6.2.4] Processing Order and Data CriteriaThe Data Criteria section specifies a set of filters on the events it identifies. The order that those filters are processed in determines the end result for any specific criteria. The following order should be used when processing these filters:

1. Initial set of events - code value set and category of events


New location and title suggested by Stan

2. Attributes (e.g., status, value)3. Temporal relationships4. Subsets - always processed last since some operators (COUNT, MIN, MAX,

etc.) reduce the event list to a simple Boolean value preventing further processing.

Within each of the above classifications, filters are applied in document order. For example, if there are two excerpt elements, they are processed in the order they appear within the criteria.Consider the following example.

<entry> <localVariableName>HbA1C</localVariableName> <observationCriteria> <id> <item root="2.16.840.1.113883.190" extension="HbA1C"/> </id> <code valueSet="2.16.840.1.113883.3.464.1.72"/> <statusCode code="completed"/> <value xsi:type="IVL_PQ"> <low value="9" unit="%"/> </value> <definition> <observationReference moodCode="DEF"> <id root="2.16.840.1.113883.190" extension="LabResults"/> </observationReference> </definition> <excerpt> <subsetCode code="RECENT"/> <observationCriteria> <id root="2.16.840.1.113883.190" extension="HbA1CMeasured"/> </observationCriteria> </excerpt> <temporallyRelatedInformation typeCode="DURING"> <observationReference moodCode="EVN"> <id root="2.16.840.1.113883.190" extension="MeasurePeriod"/> </observationReference> </temporallyRelatedInformation> </observationCriteria></entry>

What does this mean? This asserts criteria that the most recent HbA1C result is 9% or greater during the measurement period. This assertion is determined based on following the processing steps previously mentioned,

1. Initial set of events2. Find all result events whose code matches one in the

2.16.840.1.113883.3.464.1.72 value set3. Attributes4. Remove any events for which the value is < 9%5. Remove any for which the status is not "completed"6. Temporal relationships7. Remove any events that are outside the measurement period8. Subsets9. Remove all but the most recent event

1.5.3[1.6.3] Population CriteriaThe Population Criteria identifies a population using one or more data Data criteria Criteria elements. Populations can be of multiple types and are used differently in the context of a query. The population types are “Initial Patient Population”, “Denominators”, “Numerators”, “Exceptions”, and “Exclusions”. These different population types provide the ability to group populations within a particular context. The following diagram shows the relationships between the populations pictorially and the table below provides their definitions.

Figure 34: Population Criteria Illustration

Table 1: Population Criteria Definitions

Population DefinitionInitial Patient Population (IPP)

The initial patient population refers to all All patients to be evaluated by a specific performance eMeasure who share a common set of specified characteristics within a specific measurement set to which a given measure belongs.

Denominator (DENOM) It can be the The same as the initial patient population or a subset of the initial patient population to further constrain the population for the purpose of the eMeasure.

Denominator Exclusions (EXCLDENEX)

Patients who should be removed from the eMeasure population and denominator before determining if numerator criteria are met. Denominator exclusions are used in proportion and ratio measures to help narrow the denominator.

Numerator (NUMER) In proportion measures the numerator criteria are the The processes or outcomes expected for each patient, procedure, or other unit of measurement defined in the denominator. Of a proportion measure.

Denominator Exceptions (EXCEP)

Denominator exceptions are those Those conditions that should remove a patient, procedure, or unit of measurement from the denominator only if the numerator criteria are not met. Denominator exceptions allow for adjustment of the calculated score for those providers with higher risk populations.

Here are is an some examples for of using the various populations types to select data on diabetes patients for a proportion measure:

Initial Patient Population (IPP): All patients between the age of 16 and 74.


Should be “DENEX” to be consistent with the harmonization proposal.

rickg, 07/17/12,

JD or Cheng, can one of you provide a description of Numerator Exclusions? You will also need to work with Dragon to update the illustration above.


Replace with updated diagram from Chris; synch with section 3 diagram as well


This is for Proportion Measure. The text of this section needs to be clear on that. If the intent of this section is to include all defined populations including numerator exclusion, measure population, the text and table needs to be updated and be clear with what type of measure it applies.

Denominator (DENOM): All patients between the age of 16 and 74 having the problem of Diabetes Type II

Numerator (NUMER): All patients between the age of 16 and 74 having the problem of Diabetes Type II and their most recent lab result has hHbA1C value > 9%.

Denominator Exceptions Exclusion (EXCEPDENEX): The denominator exception criteria for the example above can be “All patients between the age of 16 and 74 having the problem of Diabetes Type II but are also designated as having “Steroid Induced Diabetes” or “Gestational” Diabetes”.

1.5.3.1[1.6.3.1] Population Criteria and Data CriteriaThe Population Criteria is are constructed using Data Criteria to appropriately identify the right population. In order to use multiple Data Criteria to filter out populations, the Data Criteria are combined logically using “AND/OR/XOR” operators. These operators appear in the form of:

“AllTrue” and “AllFalse”, representing AND operator “AtLeastOneTrue” and “AtLeastOneFalse” representing OR operator “OnlyOneTrue” and “OnlyOneFalse” representing XOR operator

For example: , tTo identify an Initial Patient Population consisting of Male patients between the ages of 16-74, we would construct two Data Criteria elements and combine them as follows:

Data Criteria Element 1: “Identify patients between the ages of 16-74” Data Criteria Element 2: “Identify patients who are Male” Combine the above two criteria using the “AllTrue” operator (which is a logical

AND) to extract the Initial Patient Population desired.

1.5.4[1.6.4] Stratifier CriteriaStratifier Criteria is are constructed using Data Criteria and is used to specify how the results need to be grouped. For example:

Identify all patients between the ages of 16 – 74 and stratify the counts by Gender and zip code.

In the above example, the stratification criteria refers to Gender and zip code data criteria elements to group the counts of patients between 16 and 74. The above concepts are bundled together in a structure shown in the diagram below.


Maybe use “Race” instead of zip code. Theoretically zip code can be used for stratification, but not sure if it will actually be used.


Suggest to name it “Stratification Criteria”


This is not an example of “Denominator Exception” based on the blueprint definition. Should be “Denominator Exclusion”.

Figure 5Figure : Typical HQMF Document Structure

Figure 6: Typical HQMF Document Structure

An eMeasure document is wrapped by the <QualityMeasureDocument> element, and contains a header (see HQMF Header (§ 3.2 )) and a body (see QualityMeasureDocument HQMF Body (§ 3.3 )). The header identifies and classifies the document and provides important metadata about the measure.

Measure Processing MetaData

Stratifier Criteria Section

Population Criteria Section

Data Criteria Section

Measure Description Section

Measure Period

Custodian

Author

HQMF Document Attributes

HQMF Body

HQMF Header

HQMF Structure


Andy:How do you want these in-document links flagged?

The body contains componentssections, each wrapped by the <component> element. Each component can contain a single narrative block (see the Section Narrative Block (§ 3.3.4 ) section), and any number of HQMF entries. A conformant eMeasure may contain various pre-defined components, such as the Population Criteria section (see Document constraints (§ 3.1.1 )). Each pre-defined components may suggest or require various entries (see Section Constraints (§ 3.3.5 )), and HQMF entries within these components are constrained to better ensure consistency across eMeasures (see Entry Constraints (§ 3.3.7 )). Additional components and entries, above and beyond those required for HQMF conformance, can be included as needed. The An HQMF narrative block is wrapped by the <text> element within the a <component> element, and must contain the human readable content to be rendered. Within a document sectioncomponent, the narrative block represents content to be rendered, whereas HQMF entries represent structured content provided for further computer processing. A minimally conformant eMeasure will contain elements from the document header, but need not include structured components. The full measure, in any electronic format, is placed into or referenced by QualityMeasureDocument/text. From there, one can represent the full narrative of a quality measure within the narrative blocks of HQMF defined components. Full encoding further enhances the narrative of the quality measure with the addition of entries.

1.5.5[1.6.5] Human Readability and Rendering HQMF DocumentsHQMF requires that a receiver of an eMeasure be able to algorithmically display the document on a standard Web browser such that a human reader would extract the same quality data as would a computer that is basing the extraction on formally encoded eMeasure entries. Material within a component to be rendered is to be placed into the component.text field. The content model of this field is the same as that used for other Structured Document specifications (e.g. Clinical Document Architecture, Structured Product Labeling). The following conformanceconformance constraints relate to the narrativenarrative block of an HQMF document.A recipient of an eMeasure shall be able to parse and interpret the document sufficiently to be able to render it, using the following rendering rules: HQMF header fields which if present must be rendered include the following attributes, participants, and relationships:

QualityMeasureDocument.title. QualityMeasureDocument.text. QualityMeasureDocument.statusCode. QualityMeasureDocument.effectiveTime. QualityMeasureDocument.versionNumber. QualityMeasureDocument.author QualityMeasureDocument.custodian QualityMeasureDocument.verifier

o QualityMeasureDocument.verifier.time QualityMeasureDocument.componentOf. QualityMeasureSet. title. QualityMeasureDocument.subjectOf. MeasureAttribute code value pairs.

HQMF section fields which if present must be rendered include:


In a Word-delivered IG, this would be formatted as “shall”. CK: Need to ask AndyShould we do that in this one?If so, do we need a section that defines the conformance constraints?(This excerpt is from Consolidation)Conformance Verbs (Keywords)The keywords shall, should, may, need not, should not, and shall not in this document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide (http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm): shall: an absolute requirementshall not: an absolute prohibition against inclusionshould/should not: best practice or recommendation. There may be valid reasons to ignore an item, but the full implications must be understood and carefully weighed before choosing a different coursemay/need not: truly optional; can be included or omitted as the author decides with no implications The keyword "shall" allows the use of nullFlavor unless the requirement is on an attribute or the use of nullFlavor is explicitly precluded.The Consolidated Conformance Verb Matrix table represents a matrix of the conformance verbs used across the standards reviewed for the consolidation guide. The subject of a conformance verb (keyword) in a top-level constraint is the template itself; for example, the subject of CONF:5249 is the ClinicalDocument element. In nested constraints, the subject is the element in the containing constraint. Top-level constraints are those that begin with a number and are not indented.


Andy: Can we put all code in a distinct font, like this? If so, how should I flag it for you?


“HQMF defined components” ?CK: Correct – leave as is


Need to fix all in-document links from here down.


This paragraph is damaged.The old text read:“The HQMF Body contains eMeasure sections. An eMeasure section is wrapped by the <section> element. Each section can contain a single narrative block…”

Section.title. Section.text (must be rendered per the rules defined in 3.3.4 Section

Narrative Block). A creator of an eMeasure shall properly populate section.text and Section Narrative Blocks such that a recipient, adhering to the recipient requirements above, will render the document such that a human reader would extract the same quality data as would a computer that is basing the extraction on formally encoded eMeasure entries.

[1.6.6] Encoding eMeasure quality Quality statementsStatements

1.5.5.1[1.6.6.1] General ApproachQuality measures exist in a variety of formats today, and. Tthe HQMF specification, while providing a formalism for query measure statements, also provides for an incremental approach, where one can:

Create a minimally conformant eMeasure that simply wraps an existing quality measure in any electronic format within in the HQMF header.

Represent the full narrative of a quality measure within the narrative blocks of HQMF defined sections.

Enhance the full narrative within the HQMF XML with a formalized representation of quality statements. This formalism is based on the following approach, which serves to modularize the process and make it easier to understand, reuse, and implement via an eMeasure authoring tool: [10.] Data criteria are defined: A criterion ("age is greater than 18",

"antibiotic was prescribed", "diminished renal capacity", "length of stay less than 120 days") is an assertion that can be found to be true or false, often by looking at raw EHR data. Data criteria in HQMF are used primarily to determine whether or not a given patient is included in a measure's numerator, denominator, etc. For instance, a measure might say that "to be included in the Denominator, a patient must have age greater than 18 and antibiotic therapy prescribed". HQMF formalizes a datum criterion by expressing it as a RIM pattern coupled with vocabulary. Where a patient has an object in their his EHR that is subsumed by a datum criterion, that criterion can be deemed true for that patient.

[11.] Population criteria are defined: Criteria for numerator, denominator, and other measurement populations are defined based on the underlying data criteria. For instance, the criteria for a patient to be part of a measure's denominator might be that they meethe meets the criteria for "diminished renal capacity" and do does not meet the criteria that "antibiotic was prescribed". A population criterion, like a data criterion, is an assertion that can be found to be true or false, thereby providing a means for HQMF to formalize a measure's population parameters.

10.[12.] Measure observations are defined: While some quality measures only define data criteria and population criteria, other quality measures also define variables or calculations that are used to score a particular aspect of performance. For instance, a measure intends to assess the use of restraints. Population criteria for the measure include "patient is in a psychiatric inpatient setting" and "patient has been restrained". For this population, the measure defines a measure observation of "restraint time" as the total amount of time the patient has been restrained. Measure


There are several styles of formatting for conformance statements (both paragraph styles and special character styles for “shall”, etc.Should we use these styles in the XML publishing?CK: We may need to seek input from Andy S. (from the HL7 publishing perspective) and Liora A. (from a Lantana style perspective) – please check with them

observations are not criteria, but rather, are definitions of observations, used to score a measure

These steps are described in greater detail in the sections that follow. HQMF entries corresponding to these steps are segregated into different sections in an eMeasure

[1.6.6.2] Patient criteria Criteria vs. aggregate Aggregate scoresScoresTerms like "numerator" and "denominator" can be ambiguous, in that they can refer to [1] the criteria for determining if an individual patient is included in a particular population (e.g. "numerator criteria are inpatient AND diagnosis of pneumonia AND treated with antibiotic); [2] the total count of patients meeting the criteria (e.g. "27 patients meet the numerator criteria"); [3] the top or bottom of a fraction (e.g. "the numerator is total restraint time, the denominator is total psychiatric inpatient days"). HQMF differentiates these interpretations in a number of ways:

Data criteria and population criteria are expressed as individual patient criteria. In other words, criteria are constructed such that one can determine whether or not a particular patient meets the criteria.

HL7 has distinct codes to distinguish between the interpretations. For example, the code "included in denominator" is an assertion (represented in HQMF as an observation value) that a patient has met the denominator criteria; whereas the code "denominator count" is an observation (represented as an observation code) that carries a value.

Measure Observations are not directly tied to any particular population. For example, a measure defines a Measure Observation "average systolic blood pressure" as the sum of systolic blood pressures divided by the number of blood pressure readings. While the "sum of systolic blood pressures" is the numerator of an equation, it bears no relationship to the measure's numerator population. In fact, a quality organization may require that "average systolic blood pressure" be reported on any of the measure populations.

[1.6.6.3] Measure definition Definition vs. Reporting requirementsRequirementsDifferent Organizations with a variety of quality organizations reporting goals can collect data based on the same eMeasure, but stipulate different reporting requirements. For example, several quality organizations aremight be interested in the use of antibiotics in patients with bronchitis. An eMeasure is created, which defines the denominator criteria as "encounter with diagnosis of bronchitis", and the numerator criteria as "antibiotic prescription is written". One quality organization wishes to receive a quarterly summary where all qualifying encounters are reported, stratified by age; whereas another quality organization requests semi-annual reports, where, in order to minimize the human burden of chart review, only 20% of encounters with a diagnosis of bronchitis need to be sampled. A "measure definition" includes those components of a quality measure that are fixed and universally applicable, whereas "reporting requirements" are not part of a measure's definition, and can vary across quality organizations. While the dividing line is not absolute, common reporting requirements, that are not typically defined as part of an eMeasure, include reporting frequency, sampling, and chart source (e.g. paper vs. EHR).

[1.6.7] Data collection Collection and missing Missing dataDataWhere the approach to missing data is part of the measure definition itself, it can be included as part of the eMeasure.


Need to make sure this still aligns with QRDA – check with Yan – Crystal to follow up with Yan

nbashyam, 07/17/12,

Dragon: Don’t think even this is required since they have already been introduced.CK: Leave for now


I don’t think this paragraph is accurate or maybe just because it is confusing to read. Measure Observation only applies to Continuous Variable measures, and for Continuous Variable measures, only IPP and Measure Population are permitted. So it is confusing to even try to compare with numerator population. Also the last sentence is not accurate.

nbashyam, 07/17/12,

Dragon: I don’t think these sections are required here …but I will leave it up to others to decide.CK: Leave for now

1.5.6[1.6.8] Relationship of the HQMF to HL7 Messaging StandardsAn HQMF document is a defined and complete information object that can exist outside of a messaging context and/or can be a payload within an HL7 Version 2 or Version 3 message. Thus, the HQMF complements HL7 messaging specifications. The exact method by which an eMeasure is exchanged is outside the scope of this standard.

2 INTRODUCTION TO HQMF TECHNICAL ARTIFACTS

A complete understanding of HQMF requires an understanding of the underlying HL7 technical artifacts used to describe the specification. While an eMeasure must validate against the HQMF Schema, it must also adhere to the conformance rules stated in this specification. The following sections summarize the artifacts used by HQMF, and how they can be used by those seeking to implement or understand the specification.

2.1 HL7 Reference Information ModelThe definitive description of the HL7 Reference Information Model can be found here The HL7 RIM is the definitive reference source for class and attribute definitions. The HQMF specification does not exhaustively replicate RIM definitions, but instead refers the reader to the RIM for complete definitions. While HQMF may further constrain RIM definitions, at no time will HQMF definitions conflict with those in the RIM. HQMF, Release One Two is derived from HL7 RIM, Version 2.380.Where readers wish to see the complete definition of a RIM attribute or class, they should refer to the HL7 RIM.

[2.2] V3 Data TypesHL7 defines both an abstract data type specification, which is the definitive reference, and an XML-specific data type representation. Data types define the structural format of the data carried within a RIM attribute and influence the set of allowable values an attribute may assume. Some data types have very little intrinsic semantic content. However HL7 also defines more extensive data types such as the one for a person or organization's name. Every attribute in the RIM is associated with one and only one data type. HQMF, Release One Two uses the HL7 Version 3 Data Types, Release 2 abstract and Release 21.1 XML-specific specification.A reader will often find that the XML-specific description of a data type is sufficient for implementation, but at times will want to refer to the abstract data type specification for a more comprehensive discussion.

2.2[2.3] Concept Domains and Value SetsThe definitive description of HL7 V3 Vocabulary can be found here. An HL7 Concept Domain is a named category of like concepts (semantic type) that will be bound to one or more coded elements. Concept Domains exist because we want to constrain the intent of a coded element at a universal level, while deferring the association of the element to a specific coded terminology until later in the standards development or implementation process, often at a part of particular country's localization. Thus, Concept Domains are independent of any specific vocabulary or code system.


Andy:In a Word-delivered IG, I’d put these in footnotes. What shall we do for this IG?


Need a reference location for the HL7 RIM.Dale to send to Diana

A list of intended values for a concept Concept domain Domain is referred to as a value set. A value set consists of one or more coded concepts. These are the possible concept codes that can be carried in an eMeasure within a coded data type. Different value sets can be associated with the same concept Concept domain Domain in different countries. Concept domains Domains and value sets have a coding strength that can be "Coded, No Extensions" (CNE), in which case the only allowable values are those stated by the standard; or "Coded, With Extensions" (CWE), in which case values outside those stated can be used if necessary. Where aR readers should refer to the HL7 Vocabulary chapter needs to see the complete definition of an HL7-defined value, they should refer to the HL7 Vocabulary chapter.

2.3[2.4] HL7 HQMF ModelThe definitive description of the HL7 V3 model refinement process, model development and interpretation can be found at… The HL7 HQMF Model is a "Constrained Information Model" (CIM) (previously known as a "Refined Message Information Model (RMIM)), derived from a broader "Domain Information Model" (DIM) (previously known as a "Domain Message Information Model" (DMIM)). HL7 specifications derived from the HL7 RIM use a process known as "cloning" to refine domain specific models from the base HL7 RIM. When a refined model makes use of a specialization of an HL7 RIM class, the new class in the refined model is known as a clone of the HL7 RIM class. These specializations may further constrain the base class, for example, by specifying more restrictive attribute cardinality or by further constraints on the allowed vocabulary values. Multiple clones of a particular HL7 RIM class may appear in a refined model, each representing a different specialization. The HQMF model is a technical diagrammatic representation of the HQMF specification. It is presented using diagramming conventions and notations that were developed by HL7 to represent the specific semantic constructs contained in the critical, "back-bone" classes of the RIM. Although it could be represented in UML notation, as the RIM is, the HL7 notation provides more details about the specific constraints and class clones being represented. The HQMF model can be displayed graphically to aid in the understanding of the specification. Because the HQMF Hierarchical Description, and subsequently the HQMF Schema, are derived from the model, the model serves as a good basis for describing the standard. The narrative description below is aligned to correspond with the model. Although the eMeasure is defined and represented based upon the HL7 RIM, an EHR system does not necessarily require full RIM compliance. The EHR can successfully implement eMeasure by mapping relevant EHR data components to RIM classes.

2.4[2.5] HL7 HQMF ConstraintsAdditional constraints, above and beyond what is easily expressed in the HQMF model and/or the HQMF schema, are asserted in this document as conformance statements. Constraints are often used to define required or optional patterns or templates, rather than restricting HQMF model attributes or associations or allowable values. For instance, an eMeasure has a required Data dictionary section. Constraints are used to define the Data dictionary section and to require that it be present in an eMeasure, but those constraints do not preclude the inclusion of additional sections, above and beyond those required by conformance constraints.


Data Criteria section?


Ref or example?CK: Cite the RMIM reference in beginning of Section 3

2.5[2.6] HL7 HQMF Hierarchical DescriptionThe definitive description of developing and interpreting HL7 Hierarchical Descriptions can be found by following the link. A Hierarchical Description is a tabular representation of the sequence of elements (i.e., classes, attributes, and associations) represented in a model and that define the structure of the instance without reference to XML or any other implementation technology. For HQMF, Release One, the HQMF HD is uniquely identified by the string "POQM_HD000001UV". As described below, this value must be included in an eMeasure instance to serve as an unambiguous reference to the HQMF, Release One specification.

2.6[2.7] HL7 HQMF XML ImplementationThe HQMF Schema is derived through the use of the HL7 XML Implementation Technology Specification (ITS). The definitive description of HL7 XML ITS and the process used to go from Hierarchical Description to Schema can be found here. HQMF, Release One is based on the HL7 V3 XML Implementable Technology Specification for V3 Structures, Release One. Looking at the HQMF model, a reader familiar with the RIM and as well as the HL7 Development Framework and its rules for XML implementations can identify the corresponding XML elements and attributes. Due to algorithmic generation of some of the element names,When the correspondence may beis unclear, and the reader should refer to the HL7 V3 XML ITS for more details.


Update for this HQMF R2?


Update for this HQMF R2?


Update for this HQMF R2?CK: Do a global search and replace


Can this and the previous sub-sections switch places, so that this follows directly after “HL7 HQMF Model” and its reference to the Hierarchical Description…?CK: No preference on order

http://www.hl7.org/v3ballot/html/help/v3guide/v3guide.htm#v3gits

http://www.hl7.org/v3ballot/html/help/v3guide/v3guide.htm#v3ghmd

3 HQMF MODELThe HQMF Model is derived from the RIM.

Figure 78: The HQMF Model is derived from the HL7 RIM

Click thumbnail above to open larger graphic in a new window.The HQMF HMD table view and excel view can be accessed by viewing the model and clicking on it.

3.1 QualityMeasureDocumentQualityMeasureDocument The QualityMeasureDocument class is the entry point into the HQMF model, and corresponds to the <QualityMeasureDocument> XML element that is the root element of an eMeasure document. An eMeasure document is logically broken up into a header and a body. Quality measures, taken as a whole, contain a wide breadth of content. It may only require small portions of the RIM to encode the commonly seen components in quality measures (e.g. diagnoses, medications, lab results), whereas additional portions of the RIM are required to meet the use cases addressed by quality measures as a whole. For this reason, large portions of the RIM are available in the HQMF model, where it they can be used to encode quality measure components. The QualityMeasureDocument class inherits various attributes from the InfrastructureRoot class of RIM, including templateId and typeId. In the QualityMeasureDocument class these are represented as QualityMeasureDocument.templateId and QualityMeasureDocument.typeId. When QualityMeasureDocument.templateId is valued in an instance, it signals the imposition of a set of template-defined constraints. In addition, the templateId attribute is available in all other HQMF classes, thus enabling the imposition of a


This figure was linked to another location. Do we need to maintain that?CK: Dale to double check with Diana

Dale Nelson, 07/17/12,

This needs a new drawing. Will supply.CK: Dale sent to Diana

set of template-defined constraints at any level of granularity. The value of this attribute provides a unique identifier for the template(s) in question. A minimally conformant eMeasure will contain elements from the document header, but need not include structured sections. In this case, the measure can be described in QualityMeasureDocument.text. However, a structured eMeasure will contain at least one section (the PopulationCriteriaSection), and may contain more.

[3.1.1] QualityMeasureDocument Attributes Definitions

3.1.1.1 QualityMeasureDocument.typeIdQualityMeasureDocument.typeId is aA technology-neutral explicit reference to this HQMF, Release One Two specification, and. It must be valued as follows: QualityMeasureDocument.typeId.root = "2.16.840.1.113883.1.3" (which is the OID for HL7 Registered models); QualityMeasureDocument.typeId.extension = "POQM_HD000001" (which is the unique identifier for the HQMF, Release One Two Hierarchical Description).

Constraint 1: An eMeasure SHALL contain 1..1 QualityMeasureDocument / typeId / @root valued with "2.16.840.1.113883.1.3"

Constraint 2: An eMeasure SHALL contain 1..1 QualityMeasureDocument / typeId / @extension valued with "POQM_HD000001"

3.1.1.2 QualityMeasureDocument.classCode The major class of Acts to which a QualityMeasureDocument.classCode instance belongs. The class code is fixed at "DOC" (document).

3.1.1.3 QualityMeasureDocument.moodCode The intended use of the QualityMeasureDocument. The QualityMeasureDocument moodCode is fixed at "EVN" (event).

3.1.1.4 QualityMeasureDocument.id Represents the globally unique measure identifier for a particular version of a quality measure. Contrast This contrasts with QualityMeasureDocument.setId, which represents the unique measure identifier for a quality measure, regardless of version. For example, the "Anticoagulation therapy for atrial fibrillation/flutter" quality measure can have multiple versions. For each version, the QualityMeasureDocument.setId remains constant, whereas each version has a unique QualityMeasureDocument.id.

3.1.1.5 QualityMeasureDocument.code The code specifying the kind of document. The value is fixed in HQMF. The unique identification of a quality measure is via QualityMeasureDocument.id (which uniquely identifies a particular version of a measure) and QualityMeasureDocument.setId (which uniquely identifies a measure across versions).

Constraint 3: The value for QualityMeasureDocument/code SHALL be "57024-2" Health Quality Measure Document (CodeSystem: 2.16.840.1.113883.6.1, LOINC)


In HQMF Release 1, constraints were numbered sequentially for the whole document (#1-52). Should we hold with that pattern, or have constraints numbers start at 1 for each item being constrained?


Andy—These Constraint statements are in “ConformanceStatement” style with auto numbering.If this causes you a problem, let me know and I will number by hand.

Boone, Keith W (GE Healthcare), 07/17/12,

This section needs more detail.Keith – please describe the additional detail you want and provide narrative to Diana

Constraint 4: The value for QualityMeasureDocument/code SHALL be "eMeas-X" Health Quality Measure Document (CodeSystem: 2.16.840.1.113883.6.1, LOINC)

3.1.1.6 QualityMeasureDocument.title Represents the title of the particular quality measure, such as "Anticoagulation therapy for atrial fibrillation/flutter".

3.1.1.7 QualityMeasureDocument.text Represents a brief narrative description of the measure, such as "Ischemic stroke patients with atrial fibrillation/flutter who are prescribed anticoagulation therapy at hospital discharge". A minimally conformant eMeasure will contain elements from the document header, but will not include structured sections. The full measure, in any electronic format, is placed into or referenced by QualityMeasureDocument.text. A more detailed or embellished description, such as one containing images and/or flow diagrams, can be included in the body of the document, in the Measure Description section.

3.1.1.8 QualityMeasureDocument.statusCode Represents the state of the current version of the eMeasure. Can be used to signify that a particular version is draft (statusCode="active") vs. final (statusCode="completed").

3.1.1.9 QualityMeasureDocument.effectiveTime Represents the time interval over which this version of the measure is applicable. The QualityMeasureDocument.effectiveTime is not the same as the reporting period. The reporting period is the time interval over which data for the measure is are collected. The same measure may have different reporting periods depending on the organization requesting the data. The reporting period is not part of the measure definition and therefore is not represented in HQMF.

3.1.1.10QualityMeasureDocument.availabilityTime Represents the time that at which a particular completed version of an eMeasure was made publically available.

3.1.1.11QualityMeasureDocument.languageCode Represents the human language of character data (whether they be in contents or attribute values). The values of the attribute are language identifiers as defined by the IETF (Internet Engineering Task Force) RFC 3066 for the Identification of Languages, which obsoletes supersedes RFC 1766. The HL7 code system for these values is "2.16.840.1.113883.6.121".

3.1.1.12QualityMeasureDocument.setId Represents the unique measure identifier for a quality measure, regardless of version. For example, the "Anticoagulation therapy for atrial fibrillation/flutter" quality measure can have multiple versions. For each version, the QualityMeasureDocument.setId remains constant, whereas each version has a unique QualityMeasureDocument.id.


Should we describe the difference between effectiveTime and Measurement Period as well?


Duplicate?

http://www.ietf.org/rfc/rfc3066.txt

3.1.1.13QualityMeasureDocument.versionNumber A positive integer value used to version successive replacement documents.

[3.1.2] Participants in a QualityMeasureDocument Participations This section describes all participant classes involved with the quality measure creation and maintenance.

3.1.1.14[3.1.2.1] QualityMeasureDocument.author Represents the humans and/or organizations that authored the quality measure.A human author is uniquely identified via QualityMeasureDocument.author.responsibleParty.id. The responsible organization is identified via QualityMeasureDocument.author.responsibleParty.representedResponsibleOrganization.id. Authorship defined in the document header propagates throughout the entire document, where it can be overridden at the section and/or entry level. Typically, the author(s) and the custodian are part of the same organization. However, there may be use cases where the quality measure is authored by one organization on behalf of the custodian organization.

3.1.1.15[3.1.2.2] author.typeCode The QualityMeasureDocument.author.typeCode isRepresents the author type and remains fixed at "AUT" (author).

3.1.1.16[3.1.2.3] author.contextControlCode The QualityMeasureDocument.author.contextControlCode isRepresents the context of authorship and remains fixed at "OP" (overriding propagating), meaning that the stated author is the author for the entire document and all of its components, unless overridden by a different author somewhere within the document.

3.1.1.17[3.1.2.4] author.functionCode Describes aAdditional detail about the function that the author has in the QualityMeasureDocument. This code, if specified, must not conflict with the Participation.typeCode.

3.1.1.18[3.1.2.5] author.time The time during which the author is involved in the QualityMeasureDocument.

3.1.1.19[3.1.2.6] author.signatureCode A code indicatingIndication that the author has attested participation through a signature.

3.1.1.20[3.1.2.7] author.responsibleParty Defines The assignedPerson is the individual or organization accountable for their participation as author in the QualityMeasureDocument. This element takes the form of assignedPerson. The assignedPerson represents a relationship between a person


Please review.The relationship between “assignedPerson” and the item being defined needs to be clear here and inresponsibleParty.classCode responsibleParty.id custodian.responsibleParty participation.responsibleParty participation.responsibleParty ORWe can format as in responsibleParty.addr (below) in which we use “assigned person”.


It seems that this and the next 5 subsections could be nested under the item above (as all pertaining to the author.This will make a difference in how the TOC is formatted and how much information it shows.Should I nest these subsections?CK: Your choice

(responsiblePerson) and an organization (responsibleOrganization). The person, playing the role described within the assignedPerson class, is participating in the QualityMeasureDocument as described by the type of participation (e.g. as author, as verifier, etc.). A person's role is scoped by an organization. In other words, it is within an organization that a person can function as author or verifier.

3.1.1.21[3.1.2.8] responsibleParty.classCode assignedPerson.classCode is a subtype of "assigned" in a QualityMeasureDocument. "Assigned" is a role in which the playing entity is acting in the employ of or on behalf of a scoping organization.

3.1.1.22[3.1.2.9] responsibleParty.id A unique identifier for the assignedPerson in the Role in a QualityMeasureDocument.

3.1.1.23[3.1.2.10] responsibleParty.code The specific kind of Role. Role.code must conceptually be a proper specialization of Role.classCode.

3.1.1.24[3.1.2.11] responsibleParty.addr A postal address for the assigned person.

3.1.1.25[3.1.2.12] responsibleParty.telecom A telecommunication address for the assigned person.

3.1.1.26[3.1.2.13] QualityMeasureDocument.custodian Represents the organization that is in charge of maintaining the document. The custodian is the steward that is entrusted with the care of the document, and bears overall responsibility for the measure, serving as primary contact for issues or concerns about the measure. Every eMeasure document has exactly one custodian. Typically, the author(s) and the custodian are part of the same organization. However, there may be use cases where the quality measure is authored by one organization on behalf of the custodian organization.

3.1.1.27[3.1.2.14] custodian.typeCode The QualityMeasureDocument.author.typeCode isRepresents the custodian type and remains fixed at "CST" (custodian).

3.1.1.28[3.1.2.15] custodian.contextControlCode Represents the context of custodian’s role and remainsThe QualityMeasureDocument.custodian.contextControlCode is fixed at "OP" (overriding propagating), meaning that the stated custodian is the custodian for the entire document and all of its components.

3.1.1.29[3.1.2.16] custodian.responsibleParty assignedPerson: See the descriptions in the Author section.


See note above about “assignedPerson”


See note above about “assignedPerson”

3.1.1.30[3.1.2.17] QualityMeasureDocument.participation Represents other parties somehow participating in the quality measure. The type of participation is represented by the required participant.typeCode, along with the optional participant.functionCode where more details about the type of participation are needed.

3.1.1.31[3.1.2.18] participation.typeCode The kind of Participation participation or involvement the responsiblePerson playing the participant has with regard to the QualityMeasureDocument. The QualityMeasureDocument.participant.typeCode is a subtype of ParticipationType (any participation typeCode).

3.1.1.32[3.1.2.19] participation.contextControlCode The QualityMeasureDocument.participant.contextControlCode is fixed at "OP" (overriding propagating), meaning that the stated participant is the participant for the entire document and all of its components, unless overridden by a participant of the same type somewhere within the document.

3.1.1.33[3.1.2.20] participation.functionCode Additional detail about the function that the participant has in the QualityMeasureDocument. This code, if specified, must not conflict with the Participation.typeCode.

3.1.1.34[3.1.2.21] participation.time The time during which the participant is involved in the QualityMeasureDocument.

3.1.1.35[3.1.2.22] participation.signatureCode A code indicating that the participant has attested participation through a signature.

3.1.1.36[3.1.2.23] participation.responsibleParty assignedPerson: See the descriptions in the Author section.

3.1.1.37[3.1.2.24] QualityMeasureDocument.verifier Represents the humans and/or organization who have endorsed or approved the quality measure definition including data criteria, population criteria, and observation measures. There can be many approvals – e.g. by the authoring organization, by the National Quality Forum, etc. Time of verification is captured via QualityMeasureDocument. verifier. time.

3.1.1.38[3.1.2.25] verifier.typeCode The QualityMeasureDocument.author.typeCode is fixed at "VRF" (verifier).

3.1.1.39[3.1.2.26] verifier.contextControlCode The QualityMeasureDocument.verifier.contextControlCode is fixed at "OP" (overriding propagating), meaning that the stated verifier is the verifier for the entire document and all of its components.

3.1.1.40[3.1.2.27] verifier.functionCode Additional detail about the function that the verifier has in the QualityMeasureDocument. This code, if specified, must not conflict with the Participation.typeCode.

3.1.1.41[3.1.2.28] verifier.time The time during which the verifier is involved in the QualityMeasureDocument.

3.1.1.42[3.1.2.29] verifier.signatureCode A code indicating that the verifier has attested participation through a signature.

3.1.1.43[3.1.2.30] verifier.responsibleParty assignedPerson: See the descriptions in the Author section.

[3.1.3] Relationships in a QualityMeasureDocument Relationships

3.1.1.44[3.1.3.1] QualityMeasureDocument.relatedDocument Where a quality measure in a non eMeasure format is used as the source for the construction of the corresponding eMeasure, that source document can be represented with the ParentQualityMeasureDocument class.

3.1.1.45[3.1.3.2] relatedDocument.typeCode Represents the source of a document revision (relatedDocument.typeCode="RPLC") or transformation (relatedDocument.typeCode="XFRM").

3.1.1.46[3.1.3.3] relatedDocument.parentQualityMeasureDocument Provides access to information about the quality measure document that this eMeasure replaced or is a transformation of. See ParentQualityMeasureDocument (§ 3.2) below for details.

3.1.1.47[3.1.3.4] QualityMeasureDocument.componentOf Quality measures can be part of a set of measures with common attributes (e.g., patient population).

3.1.1.48[3.1.3.5] componentOf.typeCode The type code is fixed to “COMP” (component).

3.1.1.49[3.1.3.6] componentOf.qualityMeasureSet Provides access to information about the quality measure set that this eMeasure is a component of. See QualityMeasureSet (§ 3.3) below for details.

3.1.1.50[3.1.3.7] QualityMeasureDocument.controlVariable Provides access to metadata variables that control how the measure is computed.

Represents measure's measurement period. The controlVariable contains 1..1 measurePeriod with datatype IVL_TS. Both <low> and <high> elements of data type IVL_TS are required.

<controlVariable> <localVariableName>MeasurePeriod</localVariableName> <measurePeriod> <code code="MSRTP" codeSystem="2.16.840.1.113883.3.560 2.16.840.1.113883.5.4"> <displayName value="Measurement period"/> </code> <value highClosed="true" lowClosed="true"> <low value="20110101"/> <high value="20111231"/> </value> <id > <value xsi:type="IVL_TS"> <low value="20110101" inclusive="true"/> <high value="20111231" inclusive="true"/> </value> </measurePeriod></controlVariable>

3.1.1.51[3.1.3.8] controlVariable.typeCode The type code is fixed to “CTRLV” (control variable).

3.1.1.52[3.1.3.9] controlVariable.localVariableName May be used to provide a name for the control variable, allowing its values to be used in computations in the eMeasure.

3.1.1.53[3.1.3.10] controlVariable.measurePeriod Provides access to the measurePeriod that controls the period over which the measure is computed. See MeasurePeriod (§ 3.4) below for details.

3.1.1.54[3.1.3.11] QualityMeasureDocument.subjectOf Provides access to metadata describing the measure.

3.1.1.55[3.1.3.12] subjectOf.typeCode The type code is fixed to “SUBJ” (subject).

3.1.1.56[3.1.3.13] subjectOf.measureAttribute Provides access to a measure attribute describing the measure. See MeasureAttribute (§ 3.5) below for details.


JD wrote this for QualityMeasureDocument.controlVariablePlease review in light of KWB’s reorganization.CK: Improper markup – Dale to supply proper sample to DianaJD: the controlVariable XML snippet is updated.


This is the OID for “NQF”. We requested the code “MSRTP” to be added to the ObservationQualityMeasureAttribute value set, which is in code system ActCode

3.1.1.57[3.1.3.14] QualityMeasureDocument.definition Quality measures often use value sets to specify the codes for the matching criteria. In order to implement a measure, the system computing it needs to be able to access these value sets. This relationship the definitions of these value sets, or references to them to be provided within the measure.

3.1.1.58[3.1.3.15] definition.typeCode The type code is fixed to (INST) (instantiates)

3.1.1.59[3.1.3.16] definition.valueSet Provides access to the value set definition or expansion. See ValueSet (§ 3.6) below for more details.

3.1.1.60[3.1.3.17] QualityMeasureDocument.component A quality measure is made up of several sections. These are components of the document.

3.1.1.61[3.1.3.18] component.typeCode The typeCode is fixed to “COMP” (component).

3.1.1.62[3.1.3.19] component.contextConductionInd The context conduction indicator is fixed to “true”, indicating that context (e.g., authorship, act relationships, et cetera) propagate down through each section component.

3.1.1.63[3.1.3.20] component.section Provides access to the content of a section. See Section (§ 3.7) below for details.

3.1.1.64[3.1.3.21] component.measureDescriptionSection A measure description section is a specialization of section which describes the measure. See MeasureDescriptionSection (§ 3.8) below for details

Constraint 5: An eMeasure MAY contain 0..1 Measure Description section.

3.1.1.65[3.1.3.22] component.dataCriteriaSection The data criteria section is a specialization of a section which describes the data that is of interest to the measure. See DataCriteriaSection (§ 3.9) below for details

Constraint 6: An eMeasure SHOULD contain 0..1 Data Criteria section

3.1.1.66[3.1.3.23] component.populationCriteriaSection A population criteria section is a specialization of section which describes the populations for the measure. See PopulationCriteriaSection (§ 3.10) below for details

Constraint 7: An eMeasure SHALL contain 1..1 Population Criteria section

3.1.1.67[3.1.3.24] component.measureObservationsSection A population criteria section is a specialization of section which describes the computations used for a measure. See MeasureObservationsSection (§ 3.11) below for details.

Constraint 8: An eMeasure MAY contain 0..1 Measure ObservationsSection

3.2 ParentQualityMeasureDocument The ParentQualityMeasureDocument describes the document that was transformed or replaced by this QualityMeasureDocument.

3.2.1 ParentQualityMeasureDocument Attributes

3.2.1.1 ParentQualityMeasureDocument.classCode The class code is fixed at "DOC" (document).

3.2.1.2 ParentQualityMeasureDocument.moodCode The QualityMeasureDocument moodCode is fixed at "EVN" (event).

3.2.1.3 ParentQualityMeasureDocument.id A unique identifier for the ParentQualityMeasureDocument.

3.2.1.4 ParentQualityMeasureDocument.code The code specifying the kind of document. The value may be any documentType.

3.2.1.5 ParentQualityMeasureDocument.text Can be used to indicate the MIME type of the related document. It is not to be used to embed the related document.

3.2.1.6 ParentQualityMeasureDocument.setId Represents the unique measure identifier for a quality measure, regardless of version.

3.2.1.7 ParentQualityMeasureDocument.versionNumber A positive integer value used to version successive replacement documents.

3.3 QualityMeasureSet Represents the measure set, if any, of which this eMeasure is a part.A measure set is a unique grouping of performance measures carefully selected to provide, when viewed together, a robust picture of the care provided in a given domain(e.g., cardiovascular care, pregnancy). The Initial Patient Population is the same across all quality measures within a single quality measure set.

3.3.1 QualityMeasureSet Attributes

3.3.1.1 QualityMeasureSet.classCode The class code is fixed at "ACT" (Act).

3.3.1.2 QualityMeasureSet.moodCode The moodCode is fixed at "EVN" (event).

3.3.1.3 QualityMeasureSet.id A unique identifier for the QualityMeasureSet.

3.3.1.4 QualityMeasureSet.title Represents the title of the particular quality measure set.

3.4 MeasurePeriod Represents the measure period which should be used for the measure. Measures are often designed to be used for a particular time period, such as one month, or one year. This is specified as a control variable for the measure, because it controls how the measure is computed. A localVariableName may be supplied for this control variable so that it can be referenced in computations elsewhere in the measure.At present, MeasurePeriod is the only control variable associated with measures. In the future, additional control variables may be specified, similar to how measure attributes are specified in the section following.

3.4.1 MeasurePeriod Attributes

3.4.1.1 MeasurePeriod.classCode The class code is fixed at "OBS" (observation).

3.4.1.2 MeasurePeriod.moodCode The moodCode is fixed at "EVN" (event).

3.4.1.3 MeasurePeriod.code The code specifying that this is the measure period. The code shall be MSRTP from the HL7 ActCode vocabulary (codeSytem: 2.16.840.1.113883.5.4).

3.4.1.4 MeasurePeriod.value The value representing the measure period. This value is an IVL_TS, and represents at the very least, the width of the measure period, with a specified unit of time (e.g., one month or one year). It may specify a fixed measurement period, in which case, the measure is only specified for the time period given (e.g., from January 1st, 2011 to December 31st, 2011).

3.5 MeasureAttribute

3.5.1 MeasureAttribute Attributes Represents miscellaneous metadata to further characterize an eMeasure. The following measure attributes may be included. In addition, other metadata attributes may be included.

3.5.1.1 MeasureAttribute.classCode The class code is fixed at "OBS" (observation).

3.5.1.2 MeasureAttribute.moodCode The MeasureAttibute moodCode is fixed at "EVN" (event).

3.5.1.3 MeasureAttribute.id The global unique instance identifier of measureAttribute. It is an optional element.

3.5.1.4 MeasureAttribute.code The code specifying the kind of measureAttribute. In the following table, columns " Data Element Name" and "Code" include suggested measure attributes. None of them are required, and other measure attributes can be included.

Constraint 9: An eMeasure MAY include 0..* measure attributes from the following table.

Constraint 10: An eMeasure SHOULD include 0..1 Measure Scoring data element.

3.5.1.5 MeasureAttribute.value The result of the observation action of a measureAttribute. The following table includes suggested measure attribute data types (column "Value data type") and values (column "Allowable values").

rickg, 07/17/12,

Needs a definition. JD, please supply.

Table 2: Measure Attribute Table

Data Element Name

CodeValue Data Type

Allowable Values (ValueSet OID) Definition

clinical recommendation statement

CRS Summary of relevant clinical guidelines or other clinical recommendations supporting this eMeasure.

improvement notation

IDUR Information on whether an increase or decrease in score is the preferred result(e.g., a higher score indicates better quality OR a lower score indicates better quality OR quality is within a range).

measurement period

MSRTP The time period for which the eMeasure applies.

definition DEF Description of individual terms, provided as needed.

guidance GUIDE Used to allow measure developers to provide additional guidance for implementers to understand greater specificity than could be provided in the logic for data criteria.

stratification STRAT Describes the strata for which the measure is to be evaluated. There are three examples of reasons for stratification based on existing work. These include: (1) evaluate the measure based on different age groupings within the population described in the measure (e.g., evaluate the whole <age 14-25> and each sub-stratum <14-19> and <20-25>); (2) evaluate the eMeasure based on either a specific condition, a specific discharge location, or both; (3) evaluate the eMeasure based on different locations within a facility(e.g., evaluate the overall rate for all intensive care units and also some strata include additional findings <specific birth weights for neonatal

intensive care units>)

transmission format

TRANF Can be a URL or hyperlinks that link to the transmission formats that are specified for a particular reporting program.

supplemental data elements

SDE CMS defines four required Supplemental Data Elements (payer, ethnicity, race, and gender), which are variables used to aggregate data into various subgroups. Comparison of results across strata can be used to show where disparities exist or where there is a need to expose differences in results.Additional supplemental data elements required for risk adjustment or other purposes of data aggregation can be included in the Supplemental Data Element section.

measurement start date

MSD The start date of the measurement period.

measurement end date

MED The end date of the measurement period.

finalized date/time

FINALDT The timestamp when the eMeasure was last packaged in the Measure Authoring Tool.

items counted ITMCNT Describes the items counted by the measure (e.g., patients, encounters, procedures, etc.)

Care Setting MSRSET CD/CWERoleClassServiceDeliveryLocation ValueSet (2.16.840.1.113883.1.11.16927)

Location(s) in which care being measured is rendered.

Copyright COPY ED Any Copyright Information for the measure

Data Aggregation

MSRAGG ED Examples: "Aggregate rate generated from count data reported as a proportion (for example, rate-based measures which report summary data generated from the

Indicates, for the measure, how data will be analyzed and statistically reported for quality improvement and public reporting activities. Note: This does not identify the type of data (patient-level or aggregate) that will be

number of Cesarean sections as a proportion of deliveries)", "Aggregate rate generated from count data reported as a ratio (e.g., bloodstream infection per 1,000 line days)", "Aggregate measures of central tendency (e.g., continuous variables which report means and medians such as length of stay)".

transmitted to the measure adopter / warehouse.

Disclaimer DISC ED AnyA statement intended to specify or delimit the scope of rights and obligations associated with the measure.

Keyword KEY CD/CWE or ED

A significant word or words that aid in discoverability.

Improvement Notation MSRIMPROV ED Any

Information on whether an increase or decrease in score is the preferred result. This should reflect information on which way is better, an increase or decrease in score.

Measure Type MSRTYPE CD/CWEObservationMeasureType ValueSet (2.16.840.1.113883.1.11.20368)

Indicates whether the measure is used to examine a process or an outcome over time. Examples: Process, Outcome

Measure Scoring MSRSCORE CD/CWE

ObservationMeasureScoring ValueSet (2.16.840.1.113883.1.11.20367)

Examples: Proportion, Ratio, Continuous variable

Notice of Use USE ED Any Usage notes

Rationale RAT ED AnyDescription of why this measure is important, particularly from a clinical perspective.

Reference REF ED Any

Bibliographic citations. May include general references, related clinical practice guidelines, sources of evidence, etc.

Risk Adjustment MSRADJ ED Any

The method of adjusting for clinical severity and conditions present at the start of care that can influence patient outcomes, to make valid comparisons of outcome measures across providers. Indicates whether a measure is subject to the statistical process for reducing, removing, or clarifying the influences of confounding factors to allow more useful comparisons.

Topic Type MSRTOPIC CD/CWE Any Clinical condition or activity for

which the measure was developed to address.

NOTE that the Codes in Column 2 (Code) are taken from ActCode (codeSystem="2.16.840.1.113883.5.4")

3.6 ValueSet Represents the definitions of the value sets used within a measure. Systems implementing a measure may wish to have the definitions or expansions of value sets provided during the measure computation. This class is provided to allow representations of a value set definition or expansion to be provided. A value set definition explains how the set of codes in a value set is obtains, while the expansion provides the full set of codes. This specification does not define a representation for definitions or expansions.

3.6.1 Value Set Identification, Versioning, and StewardshipThe code element has a valueSet attribute holds the OID or UUID for the value set. The valueSetVersion attribute can hold a time stamp with the date of the value set. The HL7 vocabulary working group has rules for value set versioning that define when value set identifiers need to change, and measure developers should refer to those rules when creating or modifying value sets. We envision that value sets will be reused across many measures. In order for this to happen, value sets need a “steward”, i.e. an organization that takes responsibility for maintaining the value set. Recommendations for specific tools for value set management are beyond the scope of this implementation guide, but we do recommend that such tools have the ability to associate a value set identifier with a steward.

3.6.2 ValueSet Attributes

3.6.2.1 ValueSet.classCode The class code is fixed at "OBS" (observation).

3.6.2.2 ValueSet.moodCode The mood code is fixed at "DEF" (definition).

3.6.2.3 ValueSet.id The unique identifier for the value set whose definition or expansion is being provided.

3.6.2.4 ValueSet.title The name of the value set whose definition or expansion is being provided.

3.6.2.5 ValueSet.text The definition or expansion of the value set.

3.6.2.6 ValueSet.value The set of codes in the value set.

3.6.3 ValueSet Relationships

3.6.3.1 ValueSet.component Subcomponents of the value set can be represented in this element (e.g., for hierarchical value sets that are composed of other value sets).

3.6.3.2 component.typeCode The type code is fixed at “COMP” (component).

3.6.3.3 component.valueSet A description of value set that is a component of the parent value set.

3.7 Section An eMeasure document is divided into several sections. The attributes, participations and relationships described below apply to all sections found in an eMeasure document. Specialized section constraints and relationships are described after the generic section.

3.7.1 Section Attributes

3.7.1.1 Section.classCode The class code is fixed to “DOCSECT” (Document Section)

3.7.1.2 Section.moodCode The mood code is fixed to “EVN” (event)

3.7.1.3 Section.id A unique id for the section.

3.7.1.4 Section.code A code describing the content of this section.

3.7.1.5 Section.title The title of the section. When rendered for human readability, the title if present, must also be displayed.

3.7.1.6 Section.text Used to store narrative to be rendered. Also referred to as the Section Narrative Block. See Section Narrative Block § 3.7.4 below for details on the contents of section.text.

3.7.1.7 Section.languageCode Represents the human language of character data (whether they be in contents or attribute values). The values of the attribute are language identifiers as defined by the IETF (Internet Engineering Task Force) RFC 3066 for the Identification of Languages, which obsoletes RFC 1766. The HL7 code system for these values is "2.16.840.1.113883.6.121".

3.7.2 Section Participations

3.7.2.1 Section.author Represents the author of this section and overrides the author specified at the document (or parent section) level. See QualityMeasureDocument.author (§ 3.1.2.1) for details of the author participant.

3.7.3 Section Relationships

3.7.3.1 Section.component1 Contains subsections. All sections can contain subsections, but those subsections can only be represented using the generic Section class clone.

3.7.3.2 component1.typeCode The type code is fixed to “COMP” (component).

3.7.3.3 component1.contextConductionInd The context conduction indicator is set to “true”, indicating that context is conducted into the subsection.

3.7.3.4 component1.section Contains the subsection.

3.7.4 Section Narrative BlockThe Section.text field is used to store narrative to be rendered, and is therefore referred to as the Section Narrative Block. The content model of the Section Narrative Block schema is the same as that used for other Structured Document specifications (e.g. Clinical Document Architecture, Structured Product Labeling). The schema is registered as a MIME type (text/x-hl7-text+xml), which is the fixed media type for Section.text. Components of the schema are described in the sections that follow. While all narrative block components are available for use in an eMeasure, many were added to meet the needs of other Structured Document specifications, so may not be directly applicable.

3.7.4.1 paragraphA <paragraph> element is similar to the HTML <p> element, which allows blocks of narrative to be broken up into logically consistent structures. A narrative block <paragraph> element contains an optional caption, which if present must come first before any other character data.

http://www.ietf.org/rfc/rfc3066.txt

3.7.4.2 listA <list> element is similar to the HTML <ol> or <ul> elements. The <list> element has an optional caption, and contains one or more <item> elements. The required listType attribute specifies whether the list is ordered or unordered (with unordered being the default). Unordered lists are typically rendered with bullets, whereas ordered lists are typically rendered with numbers, although this is not a requirement. A <item> element contains an optional caption, which if present must come first before any other character data.

3.7.4.3 tableThe <table> is similar to the HTML table. The table markup is for presentation purposes only and, unlike a database table, does not possess meaningful field names. The narrative block schema modifies the strict XHTML table model by removing formatting tags and by setting the content model of cells to be similar to the contents of other elements in the narrative block.

3.7.4.4 footnote, footNoteRefThe <footnote> element is used to indicate a footnote. The element contains the footnote, in line with the flow of text to which it is applied. Receivers are required to interpret a footnote when rendering by visually distinguishing footnoted text. The exact rendition is at the discretion of the recipient, and might include a mark at the location of the footnote with a hyperlink to the footnoted text, a simple demarcation (such as "This is the text [this is the footnote] that is being footnoted"), etc. The <footnoteRef> element can reference an existing footnote in the same or different narrative block of the same document. It can be used when the same footnote is being used multiple times. The value of the footnoteRef.IDREF must be an footnote.ID value in the same document.

3.7.4.5 contentThe <content> element is used to wrap a string of text so that it can be explicitly referenced, or so that it can suggest rendering characteristics. The <content> element can nest recursively, which enables wrapping a string of plain text down to as small a chunk as desired. The <content> element contains an optional identifier that can serve as the target of a reference. All values of attributes of type XML ID must be unique within the document (per theW3C XML specification). The <content> element contains an optional "revised" attribute that can be valued with "insert" or "delete", which can be used to indicate narrative changes from the last version of a document. The attribute is limited to a single generation, in that it only reflects the changes from the preceding version of a document. If applied, it needs to be used in conjunction with standard document revision tracking. Changes to a document that has been released for use still require a formal versioning and revision, and the revised document can optionally carry the "revised" attribute to show the delta in the narrative. Receivers are required to interpret the "revised" attribute when rendering by visually distinguishing or suppressing deleted narrative.

3.7.4.6 styleCodeThe styleCode attribute is used within the narrative block to give the instance author the ability to suggest rendering characteristics of the nested character data. Receivers are not required to render documents using the style hints provided and can present stylized text in accordance with their local style conventions. The styleCode attribute is used within the narrative block to give the instance author the ability to suggest rendering characteristics of the nested character data. Receivers are not required to render documents using the style hints provided and can present stylized text in accordance with their local style conventions. Local extensions to the styleType vocabulary domain must follow the following convention: [x][A-Za-z][A-Za-z0-9]* (first character is "x", second character is an upper or lower case A-Z, remaining characters are any combination of upper and lower case letters or numbers). The styleCode attribute can contain multiple values, separated by white space. Where an element containing a styleCode attribute is nested within another element containing a styleCode attribute, the style effects are additive, as in the following example:

<section> <text> <content styleCode="Bold">This is rendered bold, <content styleCode="Italics">this is rendered bold and italicized,</content> this is rendered bold.</content> <content styleCode="Bold Italics">This is also rendered bold and italicized. </content> </text></section>

3.7.4.7 sub and supThe <sub> and <sup> elements are used to indicate subscripts and superscripts, respectively. Receivers are required to interpret these elements when rendering by visually distinguishing subscripted and superscripted characters.

3.7.4.8 brThe <br/> element is used to indicate a hard line break. It differs from the <paragraph> element in that the <br/> element has no content. Receivers are required to interpret this element when rendering so as to represent a line break.

3.7.4.9 captionThe <caption> element contains a label for a paragraph, list, list item, table, or table cell. It can also be used within the <renderMultiMedia> element to indicate a label for multimedia content. The <caption> element contains plain text and may contain links and footnotes.

3.7.4.10linkHTMLThe <linkHtml> element is a generic referencing mechanism, similar, but not identical, to the HTML <a> tag. It can be used to reference identifiers that are either internal or external to the document. Multimedia that is integral to, and part of the verified content of the document requires the use of the <renderMultimedia> element described below. Multimedia that is simply

referenced by the document and not an integral part of the document can use the <linkHtml> element. The source of a link uses the linkHtml.href attribute. The target of an internal reference is an identifier of type XML ID, which can exist on other elements in the same or a different narrative block, or Act.id identifiers. The linkHtml.name attribute is deprecated, because attributes of type XML ID provide an alternative and more consistent target for referencing. Following the conventions of HTML, an internal link is prefaced with the pound sign, as shown in the following example. Document links do not convey shareable meaning. Shareable semantics are only achieved by the inclusion of entries and their associated formalized relationships. There is no requirement that a receiver render an internal or external link, or the target of an external link.

3.7.4.11renderMultiMediaThe <renderMultiMedia> element references external multimedia that is integral to a document, and part of the verified content of the document, and serves to show where the referenced multimedia is to be rendered. The <renderMultiMedia> element has an optional <caption>, and contains a required referencedObject attribute (of type XML IDREFS), the values of which must equal the XML ID value(s) of an entry within the same document. Multimedia that is simply referenced by the document and not an integral part of the document must use <linkHtml>. The expected behavior is that the referenced multimedia should be rendered or referenced at the point of reference. Where a caption is present, it must also be rendered. If the <renderMultiMedia> element references a single observation class, that observation class should be rendered or referenced at the point of reference.

3.8 MeasureDescriptionSection The Measure Description section is used to provide a more detailed or embellished description, such as one containing images and/or flow diagrams, than that provided in QualityMeasureDocument.text.

3.8.1 MeasureDescriptionSection Attributes

3.8.1.1 MeasureDescriptionSection.code Constraint 11: The value for section/code shall be "34089-3" Measure

Description section (CodeSystem: 2.16.840.1.113883.6.1, LOINC

3.9 DataCriteriaSection The Data Criteria section contains the criteria describing the data of interest to a measure. This data can subsequently be referenced in the Population criteria section to determine whether or not a given patient is included in a measure's numerator, denominator, etc.There are two parts to the data criteria section.Definitions – which identify the elements of the data model against which the measure is designed.

Entries – which describe the data elements of interest to the eMeasure. If a data element appearing in the system where the measure is being computed is not described in an entry within a data criteria section, it is not relevant to the measure, and its contents will not alter the measure.

3.9.1 DataCriteriaSection Attributes

3.9.1.1 DataCriteriaSection.code Constraint 12: The value for section/code shall be "57025-9" Data Criteria

Section (CodeSystem: 2.16.840.1.113883.6.1, LOINC

3.9.2 DataCriteriaSection Relationships

3.9.2.1 DataCriteriaSection.definition Definitions found in the data criteria section may be used to link criteria to an implementation model (e.g., tables in a clinical data repository, objects in an object model).

3.9.2.2 definition.typeCode The type code is fixed at "INST" (definition).

3.9.2.3 definition.actDefinitionThe definition may contain an actDefinition, encounterDefinition, observationDefinition, procedureDefinition, substanceAdministrationDefinition, or supplyDefinition described starting at Definitions (§ 3.12) below.

3.9.2.4 DataCriteriaSection.entry An eMeasure specifies the data of interest to it as entries with specified criteria from the criteria choice box. All acts in this choice box are specified as criteria (the isCriteriaInd attribute is fixed to “true”), which means that they describe the possible acts of interest.Acts specifying criteria can be considered as prototypes or examples of acts which could appear within the system where the measure is being performed. The attributes of a criterion act might specify a single value, a range of values, or even a value set which the acts of interest to the measure would match. Acts which do not match the criteria described in entries in this section are of no interest to the measure, and need not be considered for further processing.

3.9.2.5 entry.typeCode The typeCode may be “COMP” (component) or “DRIV” (derived). It must be DRIV when the narrative describing the data criteria is derived from the entries.

3.9.2.6 entry.localVariableName Provides a name that can be used to refer to a data criterion in expressions elsewhere in the eMeasure. This value can also be used when translating the eMeasure into a computable form to enable traceability between a computable form and the eMeasure.

3.9.2.7 entry.subsetCode Describes the operations that can be performed to select a single act from a set of similar acts. See ActCriteria.excerpt (§ 3.13.3.4) below for more details on the use of subsetCode.

3.9.2.8 entry.actCriteria1An entry can contain any of the acts found in the Criteria choice box. The criteria acts are described in more detail at Criteria (§ 3.13) below.

3.9.2.9 entry.actReference An entry can also simply reference another criteria act. This can be used to avoid duplication of identical criteria used in multiple locations. The act referenced must be one defined in another entry in the data criteria section.

3.10PopulationCriteriaSection The Population Criteria section is used to formalize a measure's population (e.g. numerator, denominator) parameters.The population criteria section combines entries from the data criteria section using and/or logic to identify the items to be counted or computed by the measure. It should contain components describing the initial patient population, and may contain components describing the numerator, denominator, denominator exceptions, and numerator or denominator exclusions.The Population Criteria section contains criteria for the measure population parameters (e.g. numerator, denominator). Applicable measure parameters vary based on the measure scoring (e.g. proportion, ratio, continuous variable). Each of the population parameters has a normative definition stated within this HQMF standard. See Definitions (§ 4 ). In a proportion measure, there is a fixed mathematical relationship between the parameters, as shown in the following figure. In some cases, the Denominator and Initial Patient Population will be the same. In a proportion measure, there is a fixed mathematical relationship between the parameters, as shown in the following figure. In some cases, the Sample Size will equal the Initial Patient Population. In some cases, the Denominator, Sample Size, and Initial Patient Population will be the same.

Figure 910: Typical Measure Populations

Continuous variable measures do not have a Denominator, but instead define a Measure Population, as shown in the following figure. Rather than reporting a ratio or a Numerator and Denominator, a continuous variable measure defines variables that are computed across the Measure Population (e.g. average wait time in the emergency department).

Figure 1112: Continuous Variable Measure Populations

Entries in the Population Criteria section, like entries in the Data Criteria section, are defined as a set of criterion. The following example, a valid entry in the Population Criteria section, defines the criteria for inclusion in a measure's Initial Patient Population as those patients who have had their weight measured (the weight measure criterion was illustrated above):

<patientPopulationCriteria classCode="OBS" moodCode="EVN"> <id root="c75181d0-73eb-11de-8a39-0800200c9a66"/> <code code="IPP" codeSystem="2.16.840.1.113883.5.1063"

codeSystemName="HL7 Observation Value"> <displayName value="Included in Initial Patient Population"/> </code> <isCriterionInd value="true"/>


This is a different version of the Fig 2 (presented in Section 1.6.3 Population Criteia).Do you want a figure in both places. If so, should they be the same figure or not? What are the important differences?I we use figures in both places, it seems that this one should be showing Sample Size along with Initial Patient Population and Denominator.CK: Update with diagram from Chris

<precondition typeCode="PRCN">  <observationReference classCode="OBS" moodCode="EVN"> <id root="f92aa450-73c0-11de-8a39-0800200c9a66"/> </observationReference> </precondition></patientPopulationCriteria>

Some things to note about the example:The observation is defining inclusion criteria for a single patient – i.e. it is providing the criteria for determining whether or not a single patient meets the Initial Patient Population criteria. A separate observation could be used to represent the total count of those patients meeting the criteria. The sourceOf.typeCode "PRCN" (precondition) defines the criteria that must hold in order to satisfy inclusion. The target of the precondition can be a reference to a criterion defined elsewhere, whether in the same eMeasure document or contained in an external library of criteria, if necessary. Logic Expression Representation - AND: The next example defines the criteria for inclusion in a measure's Initial Patient Population as a combination of two criteria, joined by a logical "AND"

<patientPopulationCriteria classCode="OBS" moodCode="EVN"> <id root="c75181d0-73eb-11de-8a39-0800200c9a66"/> <code code="IPP" codeSystem="2.16.840.1.113883.5.1063" codeSystemName="HL7 Observation Value"> <displayName value="Included in Initial Patient Population"/> </code> <isCriterionInd value="true"/> <precondition typeCode="PRCN"> <allTrue> <id root="9ea5d63f-f794-4b5d-ae33-e1091cb31d38"/> <precondition typeCode="PRCN">  <observationReference classCode="OBS" moodCode="EVN "> <id root="f92aa450-73c0-11de-8a39-0800200c9a66"/> </observationReference> </precondition> <precondition typeCode="PRCN">  <observationReference classCode="OBS" moodCode="EVN "> <id root="42e2aef0-73c4-11de-8a39-0800200c9a66"/> </observationReference> </precondition> </allTrue> </precondition></patientPopulationCriteria>

It is very common to AND preconditions within the PatientPopulationCriteria, and so this fixed to be the behavior for all preconditions that emanate directly from it (Note that this is also true for numerators, denominators and measure observations). Thus you can rewrite the above as:

<patientPopulationCriteria classCode="OBS" moodCode="EVN">

<id root="c75181d0-73eb-11de-8a39-0800200c9a66"/> <code code="IPP" codeSystem="2.16.840.1.113883.5.1063" codeSystemName="HL7 Observation Value">

<displayName value="Included in Initial Patient Population"/> </code> <isCriterionInd value="true"/> <precondition typeCode="PRCN">  <observationReference classCode="OBS" moodCode="EVN "> <id root="f92aa450-73c0-11de-8a39-0800200c9a66"/> </observationReference> </precondition> <precondition typeCode="PRCN">  <observationReference classCode="OBS" moodCode="EVN "> <id root="42e2aef0-73c4-11de-8a39-0800200c9a66"/> </observationReference> </precondition></patientPopulationCriteria>

The next example defines the criteria for inclusion in a measure's Denominator as a combination of three criteria, joined by a logical "AND" and "AND NOT". While there are many ways to represent “AND NOT” in the HL7 RIM, the HQMF specification limits expression using the groupers described above. Thus, you cannot negate referenced criteria. If that has been allowed, it would violate the notion that a data element that does not match a data criteria specified by the measure is not relevant to the measure.

<denominatorCriteria classCode="OBS" moodCode="EVN"> <id root="238a0250-7401-11de-8a39-0800200c9a66"/> <code code="DENOM" codeSystem="2.16.840.1.113883.5.1063" codeSystemName="HL7 Observation Value"> <displayName value="Included in Denominator"/> </code> <isCriterionInd value="true"/> <precondition typeCode="PRCN">  <encounterReference classCode="ENC" moodCode="EVN"> <id root="6026f0c0-7f8b-11de-8a39-0800200c9a66"/> </encounterReference> </precondition> <precondition typeCode="PRCN">  <actReference classCode="ACT" moodCode="EVN "> <id root="aebb2a61-73da-11de-8a39-0800200c9a66"/> </actReference> </precondition> <precondition typeCode="PRCN"> <allFalse> <id root="9b484bbe-4599-40be-b7a0-9724376d65e7"/> <precondition typeCode="PRCN">  <actReference classCode="ACT" moodCode="EVN"> <id root="aebb2a62-73da-11de-8a39-0800200c9a66"/> </actReference> </precondition> </allFalse> </precondition></denominatorCriteria>

Some things to note about the example:

The logical expression "AND NOT" can be represented by including the criterion inside a precondition inside the allFalse grouper class.The interpretation of the example is "the criteria of the measure's denominator include an encounter, AND the problem of atrial fibrillation/atrial flutter, AND NOT the problem of Von Villebrand's Disease". Logic Expression Representation - further nested AND, OR, XOR: Logic trees can be nested as deeply as necessary. The next example illustrates the XML representation of nested AND, OR (AND, (OR)) criteria for inclusion in a measure's Dominator.

<denominatorCriteria classCode="OBS" moodCode="EVN" > <id root="238a0250-7401-11de-8a39-0800200c9a66"/> <code code="DENOM" codeSystem="2.16.840.1.113883.5.1063" codeSystemName="HL7 Observation Value"> <displayName value="Included in Denominator"/> </code> <isCriterionInd value="true"/> <precondition typeCode="PRCN">  <encounterReference classCode="ENC" moodCode="EVN"> <id root="6026f0c0-7f8b-11de-8a39-0800200c9a66"/> </encounterReference> </precondition> <precondition typeCode="PRCN">  <atLeastOneTrue> <id root="4416d432-949d-4c03-86cb-df9b65a44109"/> <precondition typeCode="PRCN">  <actReference classCode="ACT" moodCode="EVN"> <id root="aebb2a61-73da-11de-8a39-0800200c9a76"/> </actReference> </precondition> <precondition typeCode="PRCN">  <allTrue> <id root="b22bb902-556e-457f-b55e-0de555b0a8c1"/> <precondition typeCode="PRCN"> <conjunctionCode code="AND"/>  <actReference classCode="ACT" moodCode="EVN "> <id root="aebb2a61-73da-11de-8a39-0800200c9a80"/> </actReference> </precondition> <precondition typeCode="PRCN">  <procedureReference classCode="PROC" moodCode="EVN "> <id root="aebb2a61-73da-11de-8a39-0800200c9a81"/> </procedureReference> </precondition> </allTrue> </precondition> </atLeastOneTrue> </precondition></denominatorCriteria>

Some things to note about the example:The nested "AND", "OR", or "XOR" criteria groups all use one of the grouper classes described above. In each group, criterion is included inside a precondition. The interpretation of the example is "the criteria of the measure's denominator include an encounter, AND at least one of the (act one criterion, (act two criterion AND procedure one criterion)) ". Whereas the Numerator is always a subset of the Denominator in a proportion measure, this relationship is not necessarily the case for a ratio measure. The next example makes the relationship explicit by defining the Numerator criteria as a further constraint on the Denominator criteria:

<numeratorCriteria classCode="OBS" moodCode="EVN "> <id root="c3490951-393d-4e88-a68d-6fed6e218a4e"/> <code code="NUMER" codeSystem="2.16.840.1.113883.5.1063" codeSystemName="HL7 Observation Value"> <displayName value="Included in Numerator" /> </code> <isCriterionInd value="true"/> <precondition typeCode="PRCN">  <observationReference classCode="OBS" moodCode="EVN "> <id root="f7d92711-7f92-11de-8a39-0800200c9a66" /> </observationReference> </precondition> <precondition typeCode="PRCN">  <actReference classCode="ACT" moodCode="EVN.CRT"> <id root="aebb2a61-73da-11de-8a39-0800200c9a66" /> </actReference> </precondition></numeratorCriteria>

Some things to note about the example:The example represents "to be included in the numerator population, a patient must meet the Denominator criteria AND must have a problem list entry of atrial fibrillation". When developing entries in the Population Criteria section, it is paramount to first understand and be able to express clearly the underlying logic and criteria of the measure. An ambiguous measure, with fuzzy inclusion criteria, will not become magically computable simply through its representation as an eMeasure. For instance, if a measure's numerator inclusion criteria is "ambulatory visit" and "2 to 6 months at the visit" and "weight measurement at the visit", it is important to understand that satisfying the criteria requires that there be at least one visit such that it is ambulatory AND age 2-6 months at visit AND weight measurement at visit. It would be incorrect to identify a patient that had two ambulatory visits during the measurement period, the first when 5 months old with no weight measurement, the second when 7 months old with weight measurement. The next example correctly defines the Numerator criteria in the above scenario, by expressing the age and weight measurement criteria as components of the ambulatory encounter criterion: In the data criteria section:

<encounterCriteria classCode="ENC" moodCode="EVN "> <id> <item root="aee8d5ae-350d-47d0-8b0a-3a1dcd0bc457"/>

</id> <code code="AMB" codeSystem="2.16.840.1.113883.5.4"> <displayName value="Ambulatory encounter"/> </code> <sourceOf outboundRelationship typeCode="COMPSUBJ">  <observationReference classCode="OBS" moodCode="EVN.CRT"> <id root="f92aa450-73c0-11de-8a39-0800200c9a66"/> </observationReference> </sourceOfoutboundRelationship> <sourceOf outboundRelationship typeCode="COMPSUBJ">  <observationReference classCode="OBS" moodCode="EVN.CRT"> <id root="42e2aef0-73c4-11de-8a39-0800200c9a66"/> </observationReference> </sourceOfoutboundRelationship></encounterCriteria>

In the population criteria section:<numeratorCriteria classCode="OBS" moodCode="EVN"> <id root="c751a8e0-73eb-11de-8a39-0800200c9a66"/> <code code="NUM" codeSystem="2.16.840.1.113883.5.1063" codeSystemName="HL7 Observation Value"> <displayName value="Included in Numerator"/> </code> <isCriterionInd value = "true"/> <precondition typeCode="PRCN"> <encounterReference classCode="ENC" moodCode="EVN"> <id root="aee8d5ae-350d-47d0-8b0a-3a1dcd0bc457"/> </encounterReference> </precondition></numeratorCriteria>

3.10.1 PopulationCriteriaSection Attributes

3.10.1.1PopulationCriteriaSection.code Constraint 13: The value for section/code shall be "57026-7" Population

Criteria section (CodeSystem: 2.16.840.1.113883.6.1, LOINC)

3.10.2 PopulationCriteriaSection Relationships

3.10.2.1PopulationCriteriaSection.component The components of the population criteria section describe how the populations in the measure are computed.

3.10.2.2component.typeCode The type code is fixed to “COMP” (component).

3.10.2.3component.localVariableName May be used to name individual population criteria components.


Not schema validBelieve it is the two sourceOf items that are invalid; EVNCheng to try to update the schema examples that are not valid

3.10.2.4component.patientPopulationCriteria This entry describes how the initial population for the measure is computed.

Constraint 14: A populationCriteriaSection SHALL contain 1..1 Initial Patient Population entry.

3.10.2.5component.numeratorCriteria This entry describes how the numerator for a proportion, rate or ratio measure is computed.

Constraint 15: A populationCriteriaSection SHALL contain 1..1 Numerator entry if the measure population parameters are proportion or ratio based.

Constraint 16: A populationCriteriaSection SHALL NOT contain Numerator entry if the measure population parameters are continuous variable based.

3.10.2.6component.denominatorCriteria This entry describes how the denominator for a proportion, rate or ratio measure is computed.

Constraint 17: A populationCriteriaSection SHALL contain 1..1 Denominator entry if the measure population parameters are proportion or ratio based.

Constraint 18: A populationCriteriaSection SHALL NOT contain Denominator entry if the measure population parameters are continuous variable based.

3.10.2.7component.denominatorExceptionCriteria This entry describes how the denominator exceptions for a proportion measure is computed.

Constraint 19: A populationCriteriaSection MAY contain 0..1 Denominator Exception entry if the measure population parameters are proportion or ratio based.

Constraint 20: A populationCriteriaSection SHALL NOT contain Denominator Exception entry if the measure population parameters are continuous variable based.

3.10.2.8component.numeratorExclusionCriteria This entry describes how the numerator exclusions for a ratio measure are computed.

Constraint 21: A populationCriteriaSection MAY contain 0..1 Numerator Exclusion entry if the measure population parameters are ratio based.

Constraint 22: A populationCriteriaSection SHALL NOT contain Numerator Exclusion entry if the measure population parameters are proportion based.

3.10.2.9component. denominatorExclusionCriteria This entry describes how the denominator exclusions for a ratio measure are computed.

Constraint 23: A populationCriteriaSection MAY contain 0..1 Denominator Exclusion entry if the measure population parameters are ratio based.


Have bob Check me on these constraints

Constraint 24: A populationCriteriaSection SHALL NOT contain Denominator Exclusion entry if the measure population parameters are proportion based.

3.10.2.10 component.measurePopulationCriteria This entry describes how populations are selected for computed measures (e.g., continuous variable based).

Constraint 25: A populationCriteriaSection SHALL contain 1..1 Measure Population entry if the measure population parameters are continuous variable based (e.g. average wait time in the emergency department).

3.10.2.11 component.stratifierCriteria This entry describes how a population is stratified for measure computations.

3.11MeasureObservationsSection The Measure Observations section defines computations (e.g. time from check in to antibiotic administration) used to score particular aspects of performance.

3.11.1 MeasureObservationsSection Attributes

3.11.1.1MeasureObservationsSection.code Constraint 26: The value for section/code shall be "57027-5" Measure

Observation section (CodeSystem: 2.16.840.1.113883.6.1, LOINC)

3.11.2 MeasureObservationsSection Relationships

3.11.2.1MeasureObservationsSection.definition The MeasureObservationDefinition describes a computation that is performed on enumerated items in order to provide a particular score.

3.11.2.2definition.typeCode The type code is fixed to “INST” (definition)

3.11.2.3definition.measureObservationDefinitionContains the definition of the computation. See measureObservationDefinition (§ 3.27) below for more details.

3.12Model Definitions A collection of model Definition elements can be found in the Definition choice box attached to the data criteria section. These enable binding of implementation model definitions to an eMeasure.An eMeasure may be designed to operate against a particular data model (e.g., the HL7 Virtual Medical Record, or the HL7 CCD). In order to bind measure criteria to data model

elements, these data model elements must be identified in the measure. The definition relationship allows the identifiers for these model elements to be specified. This relationship provides a choice box containing data element types for acts, encounters, observations, procedures, substance administration, and supply acts, but they all support the same attributes as ActDefinition described below.The eMeasure does not need a full model specification (e.g., all of the relationships from one model components to another, or the attributes of the model). It only needs to be able to uniquely associate the basic model elements and type information with a data criterion to enable translation of the measure into a computable form. See Criteria (§ 3.13) below for more details on data criteria.

3.12.1 Definition Attributes

3.12.1.1ActDefinition.classCode The class code for each definition act is fixed to the correct value for each of the definition classes.

3.12.1.2ActDefinition.moodCode The mood code is fixed at "DEF" (definition).

3.12.1.3ActDefinition.id The unique identifier for the data element’s model. This identifier can be used to by a data criteria element reference the model definition. Implementations may also use this information to reference an externally defined model if needed.

3.13Criteria The RIM, like many other healthcare data models, is a service-centric model, meaning that much of health care is seen as comprised of a number of health care services or "acts". At the heart of the HL7 RIM is the Act class. Acts include such things as observations (blood pressure, lab result), procedures (appendectomy, caesarian section), encounters (office visit, hospitalization), etc. An act is "a record of something that is being done, has been done, can be done, or is intended or requested to be done". Thus, the RIM allows for not only the representation of acts that have occurred, but that may occur. It also allows acts to serve as criteria for rules or guidelines or quality measures, should they occur. This latter feature, the ability to express an act as a criterion, is heavily exploited in the formal representation of quality measure statements in the Data Criteria section. From a technical implementation perspective, the RIM's Act class contains an attribute "isCriterionInd", which when true is used to indicate that the Act serves as a description of an act that may have occurred. The following example, a valid entry in the Data Element section, represents the criterion for a completed weight observation:

<observationCriteria classCode="OBS" moodCode="EVN" > <id> <item root="f92aa450-73c0-11de-8a39-0800200c9a66"/> </id> <code code="27113001" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"> <displayName value="weight"/>


Keith – can you please review all examples for proper moodCode?


Keith – should we take this out? The example below shows this correctly.

</code> <statusCode code="completed"/> <isCriterionInd value="true"/></observationCriteria>

Some things to note about the example: An Act with <isCriterionInd value="true"/> is somewhat analogous to a "query by

example", in that it lays out patterns, which if matched by an object in an EHR, are considered to be satisfied. In reality, an EHR would not necessarily search for an exact match, but rather, for objects that are subsumed by the criteria. For instance, if the EHR is using a local code that maps to the criterion's weight measurement code, the EHR object would still meet the criterion.

The observation.id uniquely identifies this criterion assertion, allowing it to be referenced by other criteria. The ability to uniquely identify and reference a criterion enables an external library of criteria, and enables the construction of more molecular criteria, which is further exploited in the Population Criteria section (e.g. when defining numerator criteria). (An observation.id is a globally unique object identifier. Details can of the Instance Identifier (II) datatype can be found in the Datatypes R2 specification.)

Whereas observation.id uniquely identifies this criterion, all other properties of the criterion, such as observation.code and observation.value, express patterns that are to be met by a subsumed EHR object meeting the criterion.

In a data criterion, if a measure parameter's value must be one of a list of allowable codes, the eMeasure steward would be expected to provide access to the actual value set, e.g. via a web site (HL7 value set definition can be found here). The following example represents the criterion that encounter code be one of a list of allowable codes:

<encounterCriteria classCode="ENC" moodCode="EVN" > <id> <item root="db9b8400-73c4-11de-8a39-0800200c9a66"/> </id> <code valueSet="2.16.840.1.113883.19.5"/> <isCriterionInd value="true"/></encounterCriteria>

Some things to note about the example: In this example, an external body, the National Quality Forum (NQF), has

developed a value set of encounter codes. The NQF manages and versions this value set, and the value set is used in the construction of a number of other criteria. Code.valueSet contains the identifer for this value set. An actual encounter event with a code from this value set (or with a local code mapped to a member of the value set) would be subsumed by this criterion.

The example contains a reference to a value set. The eMeasure steward would be expected to provide access to the actual value set (e.g. via a web site).

Code.valueSetVersion can be used where it is necessary to associate an eMeasure with a particular version of allowable codes.

Quality measure criteria commonly apply to age, or to a defined subset of observations, such as the first, last, minimum, or maximum in a set. The following example represents the criterion that the patient's age is between 2 to 6 months, inclusive:

<observationCriteria classCode="OBS" moodCode="EVN" > <id> <item root="42e2aef0-73c4-11de-8a39-0800200c9a66"/> </id>


Link needed.


Update Link to Datatypes R2

<code code="424144002" codeSystem="2.16.840.1.113883.6.96" > <displayName value="Age"/> </code> <isCriterionInd value="true"/> <value xsi:type="IVL_PQ" lowClosed="true" highClosed="true"> <low value="2" unit="mo"/> <high value="6" unit="mo"/> </value> <participantion typeCode="SBJ"> <role patient classCode="PAT"/> </participantion></observationCriteria>

This next example represents the criterion that an encounter's first systolic blood pressure reading be less than 180 mm Hg.

<encounterCriteria classCode="ENC" moodCode="EVN" > <isCriterionInd value="true"/> <excerpt typeCode="XCRPT"> <subsetCode code="FIRST"/> <observationCriteria classCode="OBS" moodCode="EVN"> <code code="271649006" codeSystem="2.16.840.1.113883.6.96"> <displayName value="Systolic blood pressure"/> </code> <isCriterionInd value="true"/> <value xsi:type="IVL_PQ"> <high value="180" unit="mm[Hg]"/> </value> </observationCriteria> </excerpt></encounterCriteria>

The following example illustrates XML representation of temporal relationship of an inpatient encounter occurred three month before measurement period start date.

<entry> <localVariableName>InpatientEncounter</localVariableName> <encounterCriteria classCode="ENC" moodCode="EVN"> <id> <item root="e9a068dc-310a-48e4-95b0-eed852a8950b" identifierName="inpatientEncounter"/> </id> <code valueSet="2.16.840.1.113883.3.666.5.3001" codeSystem="2.16.840.1.113883.3.560.101.1"> <displayName value="Encounter, Performed: Encounter Inpatient"/> </code> <code valueSet="2.16.840.1.113883.3.666.5.307"/> <definition> <encounterReference moodCode="DEF"> <id root="0" extension="Encounters"/> </encounterReference> </definition>  <temporallyRelatedInformation typeCode="SBS"> <pauseQuantity value="3" unit="mo"/> <observationReference moodCode="EVN"> <id root="e656021e-89a9-4c7c-a45d-74adf2378af00" extension="MeasurePeriod"/>

</observationReference> </temporallyRelatedInformation> </encounterCriteria></entry>

Constraint 27: The root entry SHALL contain 1..* act.id. Child acts (via the sourceOf act relationship) SHOULD have 1..* act.id.

Constraint 28: An entry SHOULD represent status criterion (e.g. to differentiate an active vs. inactive medication) with act.recordSstatusCode.

Constraint 29: An entry SHOULD represent author criterion (e.g. to differentiate a physician- vs. patient-authored problem) with act.participant. When participant.criterionInd is valued "true", it will assert that this participation is part of a criterion or definition (as opposed to the author of the criterion or definition).

Constraint 30: An entry SHOULD reference an externally maintained code list by citing that code list in a code attribute (e.g. observation.code.code, observation.value.code), where the codeSystem is the owner of the code list.

3.13.1 ActCriteria Attributes The attributes below are described based on the ActCriteria class. However, these attributes are present on every criteria class (e.g., encounterCriteria, supplyCriteria) and have the same meaning in those classes.

3.13.1.1ActCriteria.classCode The class code is fixed to “ACT” (Act) for the ActCriteria. It is similarly fixed to appropriate values for other kinds of criteria (e.g., to “ENC” for EncounterCriteria).

3.13.1.2ActCriteria.moodCode The mood code can be any legal RIM mood code. It defaults to “EVN” (event) if not specified.

3.13.1.3ActCriteria.actionNegationInd A Boolean value that if true, indicates that the act itself was NOT performed. If not present, the default value of “false” is assumed. When an act criteria is specified with isNegationInd=”true”, it means that the act as described did not occur.

3.13.1.4ActCriteria.id The identifier for the criteria. This value is referenced in Measure Population criteria to indicate which acts are relevant to the measure.

3.13.1.5ActCriteria.code A code describing the kind of act being performed.

3.13.1.6ActCriteria.derivationExpr An expression describing how attributes of the act are derived from other values.


Example from JDCK: Conduct global search and replace for ‘id root = 0’; replace with HL7 example OID; can be copied from the XML sample; Rick can help with thisJD: the XML snippet is updated by fixing root="0" problem.

3.13.1.7ActCriteria.title A title for the act.

3.13.1.8ActCriteria.text A textual description of the act.

3.13.1.9ActCriteria.statusCode A code indicating the status of the act (completed, active, aborted, et cetera).

3.13.1.10 ActCriteria.effectiveTime The time interval indicating the clinically effective time for the act.

3.13.1.11 ActCriteria.activityTime A time interval indicating the actual time associated with the act.

3.13.1.12 ActCriteria.availabilityTime An interval indicating when the act was available to be performed.

3.13.1.13 ActCriteria.priorityCode A code indicating the priority with which the act was or should be performed.

3.13.1.14 ActCriteria.confidentialityCode A code indicating the confidentiality status of the act.

3.13.1.15 ActCriteria.repeatNumber A value indicating this acts position in a sequent of similar acts.

3.13.1.16 ActCriteria.uncertaintyCode A code indicating the certainty or uncertainty that the act was performed.

3.13.1.17 ActCriteria.reasonCode A code indicating the reason that the act was (or wasn’t) performed.

3.13.1.18 ActCriteria.languageCode A code describing the principal language associated with the documentation of the act.

3.13.1.19 ActCriteria.isCriterionInd The criterion indicator is fixed to “true” indicating that this act is a criteria for matching against other acts.

3.13.2 ActCriteria Participations Criteria acts includes a generic participation.

3.13.2.1ActCriteria.participation This participant supports the RIM modeling for participants, through the general role and entity classes. For definitions of the attributes for these classes, see the HL7 RIM.

3.13.2.2participation.patient The patient participant is present to support additional patient role attributes.

3.13.2.3participation.role The generic role supports RIM modeling for roles, through the general entity classes. For definitions of the attributes for these classes, see the HL7 RIM.

3.13.3 ActCriteria Relationships

3.13.3.1ActCriteria.definition Criteria can be linked to definitions to help implementations differentiate between similar acts. Each criterion can be linked to one and only one model definition.

3.13.3.2definition.typeCode The type code is fixed to “INST” (instantiates).

3.13.3.3definition.actReference The definition links to another act via the actReference (encounterReference, etc.). An ActCriteria must be defined by an ActReference. An SupplyCriteria must be defined by a SupplyReference. The reference itself must contain an identifier that appears inside the appropriate Definition act. See Model Definitions (§ 3.12) above for more details.

3.13.3.4ActCriteria.excerpt The excerpt relationship allows one of a set of similar acts to be considered in a criteria, e.g., the first, last, or most recent act of a series of similar acts.The excerpt relationship is used to extract (excerpt) one act from a set of a similar acts matching a criteria, or to summarize the set of acts.

3.13.3.5excerpt.typeCode The type code is fixed to “XCRPT” (excerpt).

3.13.3.6excerpt.inversionInd The inversion indicator is fixed to “true”, which at first might seem backwards from the usual way things would be done. The rationale for this is that the typical order of operations for computations is to

1. Compute the set.


Include link to HL7 role in the RIM.


Include link to RIM participant class.

2. Take an Excerpt from it.Without inverting the relationship, the XML would need to be written in the reverse of this “natural” order. When the operation is inverted, the XML reads naturally.Note: When excerpting, be aware of subtle differences in criteria. The following two specifications do not result in the same outcome:

1. Compute the set of HgA1C lab results where the most recent result is greater than 9%

2. Computer the most recent HgA1C of all lab results greater than 9%Consider two results, one at T0 at 10%, a second at T1 at 8.9%Since T1 > T0, the most recent result is at T1. Since this result is less than 9%, this patient does not qualify under the first criterion. However, he does qualify under the second criterion because he has two results, one of which is greater than 9%, and the most recent (and only one) is at T0. If you change the order of the results, the patient qualifies under both criteria.

3.13.3.7excerpt.sequenceNumber This attribute can be used to select a specific occurrence of an act by its sequence in time or an observation by its sorted value. By default, acts are assumed to be ordered from oldest to youngest. Setting sequenceNumber to 1 selects the oldest act. Setting the sequence number to 2 selects the second oldest act, et cetera. When used in combination with subsetCode, the sequenceNumber attribute allows one to select the second, third or Nth occurrence of the act, as ordered and selected according to the subsetCode. When sequenceNumber is not set, it assumed to be one.When used with target acts that are observationCriteria, acts can also be selected according to observationCriteria.value. To select the second highest value, set sequenceNumber to 2 and subsetCode to MAX. To select the second lowest value, set sequenceNumber to 2 and subsetCode to MIN.

3.13.3.8excerpt.subsetCode This is used to indicate how the target of the relationship will be a filtered subset of the total related set of targets. Used when there is a need to limit the number of components to the first, the last, the next, the total, the average or some other filtered or calculated subset. When subsetCode is combined with sequenceNumber, the two constraints are additive. Thus, you could select the 4th largest value by setting subsetCode to MAX, and sequenceNumber to 4.When used with the subsetCode values for Summaries, the “act” being selected summarizes all of the acts. Time intervals (e.g., effectiveTime, availabilityTime) in the summarized acts become the smallest time range that spans the time interval of all summarized acts. The repeatNumber attribute of the act becomes the total number of acts summarized. The value of an observation becomes the sum of all observed values (assuming that values are stored using the physical quantity).Values for subsetCode are restricted to values from the table below.

Code Print Name DefinitionValue Constraints (used when the target is ObservationCriteria only)MAX maximum Selects the observation with the largest valueMIN minimum Selects the observation with the smallest valueFuture Time ConstraintsFUTURE expected future Selects all acts expected to occur after the current timeLAST expected last Selects the act that is expected to occur the farthest in the

futureNEXT expected next Selects the act that is expected to occur the nearest in the

future.Past Time ConstraintsPAST Previous Selects all acts that have or were expected to occur in the

past.FIRST first known Selects the first known occurrence of the act.RECENT most recent Represents the most recent act that has or was expected to

occur.SummariesFUTSUM future summary Summarizes all acts expected to occur in the futurePREVSUM previous summary Represents a summary of all acts that have or were

expected to occur in the past.SUM summary Represents a summary of all accts.

3.13.3.9excerpt.actCriteria1 The ActCriteria (or encounterCriteria, et cetera) inside the excerpt relationship provides further criteria to apply to the excerpted act.

3.13.3.10 excerpt.actReference Additional criteria could also be specified by referencing an existing ActCriteria.

3.13.3.11 ActCriteria.temporallyRelatedInformation The temporallyRelatedInformation relationship allows two acts to be related by when they occur with respect to each other.A note on recording and comparing times: Times are quantities and are treated that when during comparisons. Just as 1.5 is not < than 1, neither is 1:00 am on December 31st, 2012 < December 31st, 2012. While the precision of the second timestamp would seem to cover the entire day of December 31st, 2012, it does not. When the two timestamps are converted to numbers and compared, the second will be less than the first.This is most commonly a problem when performing comparisons against a measurePeriod specified similar to the following:

<measurePeriod> <effectiveTime> <low value='20120101'/>

<high value='20121231'/> </effectiveTime></measurePeriod><measurePeriod> <effectiveTime lowClosed="true" highClosed="true"> <low value='20120101'/> <high value='20130101'/> </effectiveTime></measurePeriod>

This measurePeriod represents the entire year.

3.13.3.12 temporallyRelatedInformation.typeCode The relationships are determined by comparing the start and/or end times of the source and target act according to the value of typeCode. The type code is restricted to the ActClassTemporallyPertains value set from the ActRelationshipType vocabulary.NOTE: Items in bold in the table below are based on recent harmonization proposals that have been adopted, but not yet updated in the current edition of the RIM and Vocabulary.


Link needed to vocabulary

Concept Code Print Name DefinitionCONCURRENT concurrent with A relationship in which the source act's effective time

is the same as the target act's effective time.DURING occurs during A relationship in which the source act's effective time

is wholly within the target act's effective time.EAE ends after end of A relationship in which the source act's effective time

ends after the target act's effective time.

EAS ends after start of A relationship in which the source act's effective time ends after the start of the target act.

EBE ends before end The source Act ends after the end of the target Act

EBS ends before start of

A relationship in which the source act's effective time ends before the start of the target act.

ECW ends concurrent with

A relationship in which the source act's effective time ends with the end of the target act's effective time.

ECWS ends concurrent with start

The source Act ends when the target act starts

EDU ends during A relationship in which the source act ends after the start of the target act and on or before the target act ends.

OVERLAP overlaps with A relationship in which the source act's effective time overlaps the target act's effective time in any way.

SAE starts after end of A relationship in which the source act starts after the end of the target act.

SAS starts after start of

The source Act starts after the start of the target Act.

SBE starts before end The source Act starts after the end of the target Act.

SBS starts before start of

A relationship in which the source act starts before the end of the target act.

SCW starts concurrent with

A relationship in which the source act's effective time starts with the start of the target act's effective time

SCWE starts concurrent with end

The source Act starts when the target act ends.

SDU starts during A relationship in which the source act starts after the start of the target act and on or before the end of the target act.

3.13.3.13 temporallyRelatedInformation.sequenceNumber See excerpt.sequenceNumber above.

3.13.3.14 temporallyRelatedInformation.pauseQuantity When comparing two acts by time, there are occasions when you would like to determine if the times are within some number of hours or days of each other. For example, to

determine whether a medication administration occurred within 4 hours of a heart attack, you would use the following:

<observationCriteria classCode="OBS" moodCode="DEF"> <code code='ASSERTION' codeSystem='2.16.840.1.113883.5.4'/> <value xsi:type="CD" valueSet='Heart Attack Value Set'/> <temporallyRelatedInformation typeCode="SBS"> <pauseQuantity xsi:type="IVL_PQ"> <any value='4' unit='h'/> </pauseQuantity> <substanceAdministrationCriteria classCode="SBADM" moodCode="EVN"> <participation typeCode="CSM"> <role classCode="MANU"> <playingMaterial classCode="MMAT" determinerCode="KIND"> <code xsi:type="CD" valueSet='Clot Buster Value Set'/> </playingMaterial> </role> </participation> </substanceAdministrationCriteria> </temporallyRelatedInformation></observationCriteria><observationCriteria classCode="OBS" moodCode="EVN"> <code code='ASSERTION' codeSystem='2.16.840.1.113883.5.4'/> <value xsi:type="CD" valueSet='Heart Attack Value Set'/> <temporallyRelatedInformation typeCode=""> <pauseQuantity xsi:type="IVL_PQ"> <any value='4' unit='h'/> </pauseQuantity> <subsetCode code='SBS'/> <substanceAdministrationCriteria classCode="SBADM" moodCode="EVN"> <participant> <role> <manufacturedMaterial> <code xsi:type="CD" valueSet='Clot Buster Value Set'/> </manufacturedMaterial> </role> </participant> </substanceAdministrationCriteria> </temporallyRelatedInformation></observationCriteria>

What this means is: 1. Find observations where a patient has had a heart attack.

To compare times using pauseQuantity:1. Add the time in pauseQuantity to the start and end times of the source act

(the outer act in the document).2. Compare the adjusted times based on the value in subsetCode.

Note that values in pauseQuantity can be negative. The same relationship can be restarted in terms of when the substanceAdministration occurred.

<substanceAdministrationCriteria classCode="SBADM" moodCode="DEF"> <participation typeCode="CSM"> <role classCode="MANU"> <playingMaterial classCode="MMAT" determinerCode="KIND"> <code xsi:type="CD" valueSet='Clot Buster Value Set'/> </playingMaterial>


Example not valid per schemaCheng will work with Dale to updateDN: Fixed


Not valid per schemaCheng will work with Dale to updateDN: Fixed

</role> </participation> <temporallyRelatedInformation typeCode='SAS'> <pauseQuantity xsi:type="IVL_PQ"> <any value="-4" unit="h"/> </pauseQuantity> <subsetCode code='RECENT'/> <observationCriteria classCode="OBS" moodCode="EVN"> <code code='ASSERTION' codeSystem='2.16.840.1.113883.5.4'/> <value xsi:type="CD" valueSet='Heart Attack Value Set'/>

</observationCriteria>

</temporallyRelatedInformation></substanceAdministrationCriteria><substanceAdministrationCriteria classCode="SBADM" moodCode="DEF"> <temporallyRelatedInformation typeCode='SAS'> <pauseQuantity xsi:type="IVL_PQ"> <any value="-4" unit="h"/> </pauseQuantity> <subsetCode code='RECENT'/> <observationCriteria classCode="OBS" moodCode="EVN"> <code code='ASSERTION' codeSystem='2.16.840.1.113883.5.4'/> <value xsi:type="CD" valueSet='Heart Attack Value Set'/> </observationCriteria> </temporallyRelatedInformation> <participant> <role> <manufacturedMaterial> <code xsi:type="CD" valueSet='Clot Buster Value Set'/> </manufacturedMaterial> </role> </participant></substanceAdministrationCriteria>

3.13.3.15 temporallyRelatedInformation.localVariableName See entry.localVariableName above

3.13.3.16 temporallyRelatedInformation.subsetCode See excerpt.subsetCode above.

3.13.3.17 temporallyRelatedInformation.actCriteria1 The ActCriteria (or encounterCriteria, et cetera) inside the excerpt relationship provides further criteria to apply to the excerpted act.

3.13.3.18 temporallyRelatedInformation.actReference

3.13.3.19 ActCriteria.sourceOfThe sourceOf relationship allows use of the broad set of RIM-based relationships between acts not otherwise specified above.


Needs X-Ref to section


Needs X-Ref to section, and do same for all other uses of localVariableName

3.14EncounterCriteria

3.14.1 EncounterCriteria Attributes

3.14.1.1EncounterCriteria.admissionReferralSourceCode A code indicating how the patient was referred for this encounter.

3.14.1.2EncounterCriteria.lengthOfStayQuantity Represents the length of stay for the encounter.

3.14.1.3EncounterCriteria.dischargeDispositionCode A code indicating where the patient was discharged to.Encounter-related timestampsThese are the common time stamps associated with encounter.

Admission datetime Facility location arrival datetime Discharge datetime Facility location departure datetime

HL7 RIM Encounter.effectiveTime description:The time interval starting with the administrative onset of the encounter (e.g. admission, registration, patient arrival) and ending with the patient's departure (e.g. discharge). Note, for an encounter appointment this represents the planned time range.To avoid ambiguities of interpreting effectiveTime in encounter, it is suggested in HQMF V2 that the effectiveTime.low is defined as admission datetime and the effectiveTime.high is defined as discharge datetime. In the cases where an event is comparing to the start of an encounter, the comparison is achieved by comparing the event to the effectiveTime.low, which is admission datetime. Similarly, in the cases where an event is comparing to the end of an encounter, the comparison is achieved by comparing the event to the effectiveTime.high, which is discharge datetime. Facility location arrival/departure datetimes are pertaining to the effectiveTime of a location within the encounter. For instance, a patient is admitted in inpatient encounter, and during the hospitalization the patient is transferred to ICU for two days and then back to floor for the rest of the hospital stay. In this example, to define the facility arrival and departure datetimes, HQMF V2 suggests adding location as a participant by using a sourceOf relationship to encounter. The suggested model is shown below.

encounterCriteria classCode="ENC" moodCode="EVN"> isCriterionInd="true"> <code codeSystem="2.16.840.1.113883.6.96" valueSet="2.16.840.1.113883.3.666.5.625"> <displayName value="Encounter Inpatient SNOMED-CT Value Set"/> </code> <title value="Encounter, Performed: Encounter Inpatient (facility location arrival datetime: 'ICU Locations')"/> <statusCode code="completed"/> <isCriterionInd value="true"/> <participation typeCode="LOC"> <time> <low/> </time>

<role classCode="SDLOC"> <playingPlace classCode="PLC" determinerCode="INSTANCE"> <code codeSystem="2.16.840.1.113883.6.96" valueSet="2.16.840.1.113883.3.666.05.627"> <displayName value="ICU Locations"/> </code> </playingPlace> </role> </participant></encounterCriteria>

At most of times, the arrival datetime should correspond to the admission datetime, and the departure datetime should correspond to the discharge datetime. In some cases, measures may require the actual arrival datetime and the departure datetime of an encounter, which could be different from the admission datetime and discharge datetime, to construct criteria. HQMF V2 suggests modeling the whole encounter as a single location and using the effectiveTime.low and effectiveTime.high in location to correspond to the actual arrival datetime and departure datetime respectively. The sample xml is shown below.

<encounterCriteria classCode="ENC" moodCode="EVN"> isCriterionInd="true"> <code codeSystem="2.16.840.1.113883.6.96" valueSet="2.16.840.1.113883.3.666.5.625"> <displayName value="Encounter Inpatient SNOMED-CT Value Set"/> </code> <title value="Encounter, Performed: Encounter Inpatient (arrival datetime)"/> <statusCode code="completed"/> <isCriterionInd value="true"/> <participation typeCode="LOC"> <time> <low/> </time> <role classCode="SDLOC"> <playingPlace classCode="PLC" determinerCode="INSTANCE"> <code codeSystem="2.16.840.1.113883.6.96" valueSet="2.16.840.1.113883.3.666.05.625"> <displayName value="Encounter Inpatient"/> </code> </playingPlace> </role> </participant></encounterCriteria>

3.15ObservationCriteria

3.15.1 ObservationCriteria Attributes The following attributes are specific to ObservationCriteria. Other possible attributes are defined above in ActCriteria (§ 3.13.1)

3.15.1.1ObservationCriteria.value The value associated with the observation.

3.15.1.2ObservationCriteria.valueNegationInd A Boolean value, which, if true, indicates that the value specified above was explicitly NOT observed.

3.15.1.3ObservationCriteria.interpretationCode A code indicating how this observation should be interpreted.

3.15.1.4ObservationCriteria.methodCode A code indicating in more detail the method by which the observation was made.

3.15.1.5ObservationCriteria.targetSiteCode A code indicating the target site associated with the observation.

3.16ProcedureCriteria The following attributes are specific to ProcedureCriteria. Other possible attributes are defined above in ActCriteria (§ 3.13.1)

3.16.1 ProcedureCriteria Attributes

3.16.1.1ProcedureCriteria.methodCode A code indicating in more detail the method by which the procedure was performed.

3.16.1.2ProcedureCriteria.approachSiteCode A code indicating the approach site associated with the procedure.

3.16.1.3ProcedureCriteria.targetSiteCode A code indicating the target site associated with the procedure.

3.17SubstanceAdministrationCriteria The following attributes are specific to SubstanceAdministrationCriteria. Other possible attributes are defined above in ActCriteria (§ 3.13.1)

3.17.1 SubstanceAdministrationCriteria Attributes

3.17.1.1SubstanceAdministrationCriteria.methodCode A code specializing the method of administration. Note: SubstanceAdministrationCriteria.code should be used to define the method. This attribute is only used to note specializations.

3.17.1.2SubstanceAdministrationCriteria.approachSiteCode A code describing the approach site used for administration of a medication (e.g., a port) or other substance.

3.17.1.3SubstanceAdministrationCriteria.targetSiteCode A code describing the target site for administration of a medication or other substance.

3.17.1.4SubstanceAdministrationCriteria.routeCode A code describing the route of administration of a medication or other substance.

3.17.1.5SubstanceAdministrationCriteria.doseQuantity The quantity of the substance administered. Note: This is a physical quantity. When the substance is homogenous (all the same), it can be a measure of the amount of the substance given. However, when a medication is a mixture of one or more clinically active substances, it should be measured in dose units, with a unitless measure (e.g., 1 tablet).

3.17.1.6SubstanceAdministrationCriteria.rateQuantity The rate of administration for a substance. Often used when a substance is administered over time, such as an IV.

3.17.1.7SubstanceAdministrationCriteria.doseCheckQuantity A quantity that describes the total dose per unit of time.

3.17.1.8SubstanceAdministrationCriteria.maxDoseQuantity The maximum total dose of the medication that should be administered per unit of time.

3.17.1.9SubstanceAdministrationCriteria.administrationUnitCode A code describing the unit of administration for the medication.

3.18SupplyCriteria The following attributes are specific to SupplyCriteria. Other possible attributes are defined above in ActCriteria (§ 3.13.1)

3.18.1 SupplyCriteria Attributes

3.18.1.1SupplyCriteria.quantity The quantity supplied.

3.18.1.2SupplyCriteria.expectedUseTime The period time over which the supplied product is expected to be used.

3.19References References are used to point to other acts (Act, Encounter, et cetera) provided elsewhere within the HQMF Document. The act has only one important attribute, the identifier, which is used to locate the act that was provided.

3.19.1 ActReference Attributes

3.19.1.1ActReference.classCode Fixed to “ACT” (act) for the ActReference class, and to suitable values for other Reference classes.

3.19.1.2ActReference.moodCode Defaults to “EVN” event for all classes, but may take on any legal value.

3.19.1.3ActReference.id The unique identifier of an ActCriteria, or ActDefinition class (depending upon context).

3.20PatientPopulationCriteria This entry describes the initial patient population (IPP) for the measure. Each precondition in the PatientPopulationCriteria must be met for an item to be included in the measure.Some uses of HQMF may only require an IPP to be defined where all patients identified in the IPP would be sent to the receiver using QRDA Category I. Allowing for this would support registries (such as CDC's cancer registry defined in an IHE profile) and other similar types of data requests where 100% of the analysis will be performed by the receiver.HQMF defines the population criteria and data criteria, whereas QRDA determines the data reporting architecture. Although QRDA has not been implemented as of the year 2012, the architectural design between HQMF and QRDA recommends sending the initial patient population by default within the QRDA framework. The receiver of QRDA data will calculate the categorization of Denominator, Numerator, and Denominator Exclusions for each patient record (in the example of a proportion measure) according to the corresponding HQMF specification. It is also a foreseeable challenge if the entire patient population in a hospital during the measurement period is extracted for a measure. To avoid this problem, it becomes a good practice to specify the initial patient population at the finest level as much as possible, with the goal of not transmitting unnecessary data.

3.20.1 PatientPopulationCriteria Attributes

3.20.1.1PatientPopulationCriteria.classCode The class code is fixed to “OBS” (observation).

3.20.1.2PatientPopulationCriteria.moodCode The mood code is fixed to “EVN” (event).

3.20.1.3PatientPopulationCriteria.id A unique identifier for the patient population criteria. This identifier is required, and may be used to refer to the patient population from which a measure result was generated from in other documents (e.g., HL7 QRDA) that report on the measure.

3.20.1.4PatientPopulationCriteria.code The code must be “IPP” from the HL7 ObservationValue code system.

3.20.1.5PatientPopulationCriteria.isCriterionInd The is criterion indicator is fixed to “true”.

3.20.2 PatientPopulationCriteria Relationships

3.20.2.1PatientPopulationCriteria.precondition The precondition relationship identifies logical groupers or data criterion that must be met for inclusion in the patient population. precondition.typeCode The type code is fixed to “PRCN” (precondition).

3.20.2.2precondition.conjunctionCode The conjunction code is fixed to “AND” for the precondition. All preconditions directly attached to a PatientPopulationCriteria must be true for the item to be included in the initial population.

3.20.2.3precondition.Grouper A precondition can point to a logical grouper to indicate that it is met when the conditions found inside the grouper are met. This allows for complex Boolean expressions to be used to specify the criterion for inclusion.

3.20.2.4precondition.actReference A precondition can also reference a data criterion to indicate that it is met when the data criterion exists. The reference acts used in this context must point to an ActCriteria (or EncounterCriteria, et cetera) when used in this context.

3.21NumeratorCriteria An entry describing the numerator of the measure, used for ratio, rate or proportion measures. This entry describes the items that are counted in the upper portion of the fraction used to compute the rate, proportion or ratio for the measure. Each precondition in the NumeratorCriteria must be met for an item to be included in the measure.

3.21.1 NumeratorCriteria Attributes This section describes differences between the NumeratorCriteria act and the PatientPopulationCriteria act. Attributes not described below are defined as for PatientPopulationCriteria (§ 3.20).

3.21.1.1NumeratorCriteria.code The code must be “NUMER” from the HL7 ObservationValue code system.

3.22DenominatorCriteria An entry describing the denominator of the measure. This entry describes the items that are counted in the lower portion of the fraction used to compute the rate, proportion or ratio for the measure. Each precondition in the DenominatorCriteria must be met for an item to be included in the measure.

3.22.1 DenominatorCriteria Attributes This section describes differences between the DenominatorCriteria act and the PatientPopulationCriteria act. Attributes not described below are defined as for PatientPopulationCriteria (§ 3.20).

3.22.1.1DenominatorCriteria.code The code must be “DENOM” from the HL7 ObservationValue code system.

3.23DenominatorExceptionCriteria This entry describes the items that may be treated as special cases in lower portion of the fraction used to compute the proportion for the measure. At least one precondition in the DenominatorExceptionCriteria must be met for an item to be treated as a denominator exception for the measure.

3.23.1 DenominatorExceptionCriteria Attributes This section describes differences between the DenominatorCriteria act and the PatientPopulationCriteria act. Attributes not described below are defined as for PatientPopulationCriteria (§ 3.20).

3.23.1.1DenominatorExceptionCriteria.code

3.23.2 DenominatorExceptionCriteria Relationships This section notes the differences between DenomonatorExceptionCriteria relationships and those described for the PatientPopulationCriteria relationships.

3.23.2.1DenominatorExceptionCriteria.precondition The precondition relationship identifies logical groupers or data criterion that must be met for inclusion in the patient population.

3.23.2.2precondition.conjunctionCode The conjunction code is fixed to “OR” for the precondition. At least one preconditions directly attached to a DenominatorExceptionCriteria must be true for the item to be an exception.

3.23.2.3NumeratorExclusionCriteriaThis entry describes the items that may be excluded in the upper portion of the fraction used to compute the rate or ratio for a measure. At least one precondition in the NumeratorExclusionCriteria must be met for an item to be treated as a numerator exclusion for the measure.

Constraint 31: The Numerator Exclusion entry is represented as an Observation (classCode OBS) in event mood (moodCode EVN).

Constraint 32: The Numerator Exclusion entry SHALL contain 1..1 Observation.id.

Constraint 33: The Numerator Exclusion entry SHALL observation.code with "NUMEX", codeSystem "2.16.840.1.113883.5.1063" (HL7 Observation Value).

3.23.2.4DenominatorExclusionCriteriaThis entry describes the items that may be excluded in the lower portion of the fraction used to compute the rate or ratio for a measure. At least one precondition in the DenominatorExclusionCriteria must be met for an item to be treated as a denominator exclusion for the measure.

Constraint 34: The Denominator Exclusion entry is represented as an Observation (classCode OBS) in event mood (moodCode EVN).

Constraint 35: The Denominator Exclusion entry SHALL contain 1..1 Observation.id.

[Constraint 36: ] The Denominator Exclusion entry SHALL observation.code with "NUMEXDENEX", codeSystem "2.16.840.1.113883.5.1063" (HL7 Observation Value).

3.24StratifierCriteria An entry describing criteria used to stratify the results for a measure. This entry describes a set of mutually exclusive criteria which is to be used to stratify the results for a measure. Each precondition in a stratifierCriteria represents one of the strata by which results will be split out. Strata are usually simple, based on patient demographics, but can use more complicated logic as well. Multiple stratifierCriteria can be present to stratify measure results by more than one axes. When multiple StratifierCriteria exist, they need not be combined. For example, if two stratifierCriteria elements are present, one stratifying by age group (e.g., < 50 and >= 50) and the other by gender, the measure results need not be stratified by the cross-product of the criteria, so that you could review results for women >= 50 years of age, or men < 50 years of age. To ensure that results are stratified across these two groupings, a single stratifierCriteria would need to be created representing all four categories.

3.24.1 StratifierCriteria Attributes This section describes differences between the DenominatorCriteria act and the PatientPopulationCriteria act. Attributes not described below are defined as for PatientPopulationCriteria (§ 3.20).

3.24.1.1StratifierCriteria.code The code must be “DENOM” from the HL7 ObservationValue code system.

3.24.2 StratifierCriteria Relationships This section notes the differences between StratifierCriteria relationships and those described for the PatientPopulationCriteria relationships.

3.24.2.1StratifierCriteria.precondition The precondition relationship identifies population strata using a logical grouper or reference to a data criterion. Each precondition identifies a separate strata of the StratifierCritieria.


Stratifier criteria should be allowed to have "components" for which we would take the cross product. Also, there should be a simple way to express a value set as a stratifier (e.g., gender).CK: Ask Keith to make the change if he sees the need


Verify these codes throughout the documentNUMEX is for Numerator Exclusion; need the code for Denom ExclusionAre these consistent?EXCEPEXCLDale will verify

3.24.2.2precondition.conjunctionCode The conjunction code is fixed to “XOR” for the precondition. Preconditions in a StratifierCriteria are not permitted to overlap.

3.25measurePopulationCriteria An entry describing criteria used to identify items that need to be computed to score a measure. See also measureObservationDefinition (§ 3.27) below.

3.25.1 measurePopulationCriteria Attributes This entry describes the items that are enumerated to compute continuous variable or ration measures. Items meeting the measure population criteria are used in later computation to calculate the measure score.This section of the specification describes differences between the DenominatorCriteria act and the measurePopulationCriteria act. Attributes not described below are defined as for PatientPopulationCriteria (§ 3.20).

3.25.1.1measurePopulationCriteria.code The code must be “MSRPOPL” from the HL7 ObservationValue code system.

3.26Logical Groupers Population criteria is expressed as a tree of preconditions referring to data criteria, or grouped together in AND/OR/XOR expressions using grouper acts. These groupers allow only one kind of precondition to enforce the logic described by the name of the grouper. Groupers can combine other groupers or individual criteria to allow for more complex Boolean logic to be computed.

Grouper Class Name Boolean Expression Equivalent

Description

AllTrue AND This act is composed of subcriteria all of which must be true in order for the item being counted to appear in the measure.

AllFalse NOR This act is composed of subcriteria all of which must be false in order for the item being counted to appear in the measure.

AtLeastOneTrue OR This act is composed of subcriteria of which at least one must be true in order for the item being counted to appear in the measure.

AtLeastOneFalse NAND This act is composed of subcriteria of which at least one must be false in order for the item being counted to appear in the measure.

OnlyOneTrue (see Note 1) This act is composed of subcriteria of which exactly one must be true in order for the item being counted to appear in the measure.

OnlyOneFalse (see Note 1) This act is composed of subcriteria of which exactly one must be false in order for the item being counted to appear in the measure.

Note 1: OnlyOneTrue and OnlyOneFalse represent the positive and negative forms of the HL7 Exclusive OR operation (XOR), which is defined as “One and only one of the XOR conditions must be true (false).” The generalization of this over more than two operands does not follow typical conventions in Boolean logic.

3.26.1 Grouper Attributes

3.26.1.1Grouper.classCode The class code is fixed to “GROUPER” (Grouper)

3.26.1.2Grouper.moodCode The mood code is fixed to “EVN” (event)

3.26.1.3Grouper.id A unique identifier for this grouper expression.


Check against vocabCK: JD doesn’t believe there is a data element called Grouper; JD to look in RMIM and Schema and connect with Keith to resolve

3.26.2 Grouper Relationships

3.26.2.1Grouper.precondition Each grouper connects to the criteria that it groups with a precondition relationship. The precondition relationships vary in their definitions to ensure that the grouper computes the appropriate logic described by the name of the grouper.

3.26.2.2precondition.typeCode The type code is fixed to “PRCN” (precondition).;

3.26.2.3precondition.conjunctionCode The conjunction code is fixed to the appropriate value for each grouper to ensure that the grouper generates the appropriate logical connective.

3.26.2.4Precondition.negationIndThe negation indicator is fixed to the appropriate value for each grouper to ensure that the grouper generates the appropriate logical connective.

3.26.2.5precondition.Grouper A precondition can contain addition groupers to perform complicated Boolean logic.

3.26.2.6precondition.actReference A precondition can also reference any of the data criteria defined in the DataCriteriaSection using the appropriate reference class.

3.27measureObservationDefinition A measureObservationDefinition provides the information needed to calculate a measure score. While some quality measures only define data criteria and population criteria, other quality measures, such as continuous variable measures, also define variables or calculations that are used to score a particular aspect of performance. For instance, a measure intends to assess the use of restraints. Population criteria for the measure include "patient is in a psychiatric inpatient setting" and "patient has been restrained". For this population, the measure defines a measure observation of "restraint time" as the total amount of time the patient has been restrained. Measure observations are not criteria, but rather, are definitions of observations, used to score a measure. For each item matching a measurePopulationCriteria, the calculation specified in the derivationExpr is performed. The result of this calculation is aggregated according to the aggregation methods indicated in the methodCode attribute(s).Functionally, the score is computed as follows:

1. For each measure observation definition repeat steps 22. For each item matching a measure population repeat steps 3-53. Compute the value described in measureObservationDefinition.derivationExpr

in the context of the matching item.

4. Aggregate the results according to the code value specified in measureObservationDefinition.methodCode

5. Report the aggregated result. When StratifierCriteria are present in the measure, the aggregate is calculated for each strata, and for the measure population.The following example, a valid entry in the Measure Observations section, defines the criteria for computing the time interval from when a decision is made in the Emergency Department to admit a patient to the hospital to when the patient physically leaves the Emergency Department.

<observation classCode="OBS" moodCode="DEF"> <id root="b421c8a3-7949-11de-8a39-0800200c9a66"/> <code ... > <displayName value="Time from admit decision to departure from ED"/> </code> <derivationExpr> PhysicalDepartureFromED.effectiveTime - ListedForAdmission.effectiveTime </derivationExpr> <sourceOf outboundRelationship typeCode="DRIV"> <localVariableName>PhysicalDepartureFromED</localVariableName>  <observation classCode="OBS" moodCode="CRT"> <id root="b421c8a9-7949-11de-8a39-0800200c9a66"/> </observation> </outboundRelationshipsourceOf> <outboundRelationship sourceOf typeCode="DRIV"> <localVariableName>ListedForAdmission</localVariableName>  <observation classCode="OBS" moodCode="CRT"> <id root="b421c8a2-7949-11de-8a39-0800200c9a66"/> </observation> </outboundRelationshipsourceOf></observation>

Some things to note about the example:Whereas observations in previous sections were criteria (i.e. had moodCode="CRT"), observations in this section are definitions (i.e. have moodCode="DEF"). Measure observations are not criteria that can be found to be true or false, but rather, are definitions of observations, used to score a measure. The observation is defined for a single patient – i.e. it defines the time interval for a single patient. A separate observation could be used to represent the mean of those patients meeting the criteria. Observation.derivationExpr is a character string containing a narrative, semi-formal, or formal language expression that specifies how the observation.value is to be derived from the nested observations. Nested observations used in the derivation have a sourceOf.typeCode of "DRIV" (is derived from), and can have a sourceOf.localVariableName, which is used in the observation.derivationExpr expression. (Note: The syntax of the derivationExpr expression is yet to be fully specified, it will be updated based upon the HL7 data type release two evolution). While many potential expression languages exist, the HQMF standard makes no specific recommendations for which to use at this time.

HQMF eMeasure's data and population criteria specify what measure population group a patient belongs to (e.g. initial patient population, denominator, denominator exclusion, numerator, etc.). For each data or population criterion defined in a HQMF measure, a patient EHR data can have three possible results:

1. The patient data meets the criterion.2. The patient data does not meet the criterion.3. Unknown patient data (event is not captured in EHR, or event is captured,

but result is unknown) due to various reasons such as data corruption in patient's EHR, not machine queryable free text data, EHR data capture limitation (the EHR was not designed to capture the desired data), or desired data is represented in local code rather than the standard code defined by HQMF measure.

For result #1 or #2, it is straightforward to evaluate what population group the patient should belong to, based upon criterion satisfaction. For result #3, since HQMF measures normally do not provide guidance on how to deal with the unknown result, there are often questions - does or does not the patient record meet the criterion? How to determine a measure population group based on unknown result? Should a query continue to retrieve other patient data defined by the rest of the measure criteria?To eliminate confusion and inconsistency of interpreting unknown patient data, following generic rule should apply: unless explicitly specified in an individual measure, "unknown " to a measure criterion shall be treated as "not meet the criterion". The examples below illustrates the XML representation of "HbA1c was performed, result is unknown and unknown HbA1c exam as denominator exception criteria".HbA1c exam was captured in EHR, result is not available (unknown):

<entry> <localVariableName>UnknownHbA1cResult</localVariableName> <observationCriteria classCode="OBS" moodCode="EVN">

<id> <item root="2.16.840.1.113883.3.999.2.1.123"/> </id>

<code valueSet="2.16.840.1.113883.3.464.0001.72"> <displayName="HbA1c test Value Set "/> </code>



<value xsi:type="IVL_PQ" nullFlavor="NI" /> </observationCriteria></entry><entry> <localVariableName>UnknownHbA1c</localVariableName>  <observationCriteria classCode="OBS" moodCode="EVN" actionNegationInd="true">

<id> <item root="2.16.840.1.113883.3.999.2.1.124"/> </id>

<code valueSet="2.16.840.1.113883.3.464.0001.72"> < displayName="HbA1c test Value Set "/> </code>

</observationCriteria></entry>

Representing unknown HbA1c and unknown HbA1c result as denominator exception criteria:<entry> <denominatorExceptionCriteria>

<id root="c75181d0-73eb-11de-8a39-0800200c9a66" extension="DENEXCEP"/>...<precondition> <atLeastOneTrue>

<precondition> <observationReference>

<! specify unknownHbA1cResult as a denominator exception criterion -->

<id root="2.16.840.1.113883.3.999.2.1.123"/> </observationReference></precondition><precondition>

<observationReference><! specify unknownHbA1c as a denominator exception criterion

--> <id root="2.16.840.1.113883.3.999.2.1.124"/>

</observationReference></precondition>

</atLeastOneTrue></precondition>...

</denominatorExceptionCriteria></entry>

3.27.1 measureObservationDefinition Attributes

3.27.1.1measureObservationDefinition.classCode The class code is fixed at "OBS" (observation).

3.27.1.2measureObservationDefinition.moodCode The mood code is fixed at "DEF" (definition).

3.27.1.3measureObservationDefinition.idThe unique identifier for the definition. This identifier may later be used to reference the definition when reporting the results.

3.27.1.4measureObservationDefinition.code The code “AGGREGATE” from the HL7 ActCode vocabulary, indicating that this observation is performing an aggregate calculation.

3.27.1.5measureObservationDefinition.derivationExpr A string in a formal language defining the calculation to perform in terms of local variables in scope within this eMeasureDocument. The language syntax is not described by this specification. Implementations are free to define the language that they will use for the contents of this field.

3.27.1.6measureObservationDefinition.methodCode One or more codes from the ObservationMeasureAggregate value set depicted in the table below. Code Display Name Description

COUNT Count Count of non-null values in the referenced set of values

SUM Sum Sum of non-null values in the referenced set of values

AVERAGE Average Average of non-null values in the referenced set of values

STDEV.S Sample Standard Deviation

Standard Deviation of the values in the referenced set of values, computed over a sample of the population.

VARIANCE.S Sample Variance Variance of the values in the referenced set of values, computed over a sample of the population.

STDEV.P Population Standard Deviation

Standard Deviation of the values in the referenced set of values, computed over the population.

VARIANCE.P Population Variance

Variance of the values in the referenced set of values, computed over the population.

MIN Minima Smallest of all non-null values in the referenced set of values.

MAX Maxima Largest of all non-null values in the referenced set of values.

MEDIAN Median The median of all non-null values in the referenced set of values.

MODE Mode The most common value of all non-null values in the referenced set of values.

The following examples shows how to compute a continuous variable measure for the average ED wait time.In this example, the data of interest is defined in the Data Criteria Section. For this example, these are ED encounters, described as being an encounter whose code come from a value set (the ED Encounter Value Set) identifying emergency department encounters.

<entry> <encounterCriteria> <id> <item root="b421c8a3-7949-11de-8a39-0800200c9a67"/> </id> <code xsi:type="CD" valueSet=".. ED Encounter Value Set .." /> </encounterCriteria></entry>

Next, the measure defines a measurePopulationCriteria element, and names it with a local variable name. The localVariableName is crucial, as it provides the hook for computations to be performed.

<component> <localVariableName>EDEncounter</localVariableName> <measurePopulationCriteria> <precondition> <encounterReference> <id root="b421c8a3-7949-11de-8a39-0800200c9a67"/>

</encounterReference> </precondition> </measurePopulationCriteria></component>

And finally the Measure Observations Section defines a measureObservationDefinition which indicates how to compute the measure from the encounter start time, and the patient arrival time. This measure will report the number of encounters, the average and median wait times, the standard deviation of the wait time, and the minimum and maximum wait times for the encounters analyzed.

<measureObservationDefinition classCode="OBS" moodCode="DEF"> <id root="b421c8a3-7949-11de-8a39-0800200c9a66"/> <code code="AGGREGATE" codeSystem="2.16.840.1.113883.5.4" /> <derivationExpr> EDEncounter.effectiveTime.low - EDEncounter.location.time.low </derivationExpr> <methodCode code="COUNT" codeSystem="2.16.840.1.113883.5.84"/> <methodCode code="AVERAGE" codeSystem="2.16.840.1.113883.5.84"/> <methodCode code="MEDIAN" codeSystem="2.16.840.1.113883.5.84"/> <methodCode code="STDEV.P" codeSystem="2.16.840.1.113883.5.84"/> <methodCode code="MIN" codeSystem="2.16.840.1.113883.5.84"/> <methodCode code="MAX" codeSystem="2.16.840.1.113883.5.84"/></measureObservationDefinition>

4 DEFINITIONS

4.1 General DefinitionseMeasure: A health quality measure expressed in HQMF formatHealth Quality Measures Format (HQMF): A standards-based formalism for the representation of quality measures. A quality measure expressed in HQMF format is also referred to as an "eMeasure".Quality Measure: A quantitative tool that provides an indication of an individual or organization’s performance in relation to a specified process or outcome via the measurement of an action, process or outcome of clinical care. Quality measures are often derived from clinical guidelines and are designed to determine whether the appropriate care has been provided given a set of clinical criteria and an evidence base. Quality measures are also often referred to as performance measures or quality indicators.Quality Measure Set: A unique grouping of performance measures carefully selected to provide, when viewed together, a robust picture of the care provided in a given domain (e.g., cardiovascular care, pregnancy).

4.2 Measure Parameter DefinitionsDenominator: The lower part of a fraction used to calculate a rate, proportion, or ratio. The Denominator is a subset of the Initial Patient Population, grouped for inclusion in a specific performance measure based on specific criteria (e.g., patient's age, diagnosis, prior MI). Different measures within a measure set may have different Denominators (e.g. measure #1 Denominator = Initial Patient Population AND Smoker; measure #2 Denominator = Initial Patient Population AND Atrial Fibrillation).(Can have inclusion and exclusion criteria). (Continuous Variable measures do not have a Denominator, but instead define a Measure Population).Denominator Exception: Denominator exceptions are those conditions that should remove a patient, procedure, or unit of measurement from the denominator only if the numerator criteria are not met. Denominator exceptions allow for adjustment of the calculated score for those providers with higher risk populations. Denominator exceptions are used only in proportion eMeasures. They are not appropriate for ratio or continuous variable eMeasures. Denominator exceptions allow for the exercise of clinical judgment and should be specifically defined where capturing the information in a structured manner fits the clinical workflow. Generic denominator exception reasons used in proportion eMeasures fall into three general categories:

Medical reasons Patient reasons System reasons

Denominator Exclusion: Patients who should be removed from the eMeasure population and denominator before determining if numerator criteria are met. Denominator exclusions are used in proportion and ratio measures to help narrow the denominator. Initial Patient Population: This identifies the eligible group of patients that the performance measure is designed to address. Details could include such information as

specific age groups, diagnoses, diagnostic and procedure codes, enrollment periods, insurance and health plan groups, etc. For example, a patient aged 18 years and older with a diagnosis of CAD who has at least two visits during the measurement period. The Initial Patient Population may be the same across all quality measures within a single quality measure set, but this is not required. All patients counted (e.g., as Numerator, as Denominator) are drawn from the Initial Patient Population. (Can have inclusion and exclusion criteria).Measure Population: Continuous variable measures do not have a Denominator, but instead define a Measure Population. To be in the measure population, a patient is in the larger Initial Patient Population appropriate to the measure set and is not excluded from the individual measure. (Can have inclusion and exclusion criteria). (Proportion and Ratio measures do not have a Measure Population, but instead define a Denominator).Numerator: The upper portion of a fraction used to calculate a rate, proportion, or ratio. For a Proportion Measure, the Numerator is a subset of the Denominator, which defines the group of patients in the denominator for whom a process or outcome of care occurs (e.g., flu vaccine received).

Numerator Exclusion: Numerator Exclusions are used only in Ratio eMeasures to define instances that should not be included in the Numerator (e.g., infections with a specific bacterium for a measure considering the number of central line blood stream infections per 1000 catheter days).

4.3 Reporting Parameter DefinitionsStratification: Stratifications are used to classify populations into one or more characteristics, variables, or other categories. As subsets of the overall population, they are used in risk adjustment, analysis and interpretation. Examples of stratification would include age, discharge status for an inpatient stay, facility location within a hospital (e.g., ICU, Emergency Department), surgical procedures, and specific conditions.Supplemental Data Elements: Variables used to aggregate data into various subgroups. Comparison of results across strata can be used to show where disparities exist or where there is a need to expose differences in results. Examples of supplemental data elements would include payer, ethnicity, race and gender.

4.4 Quality Measure ScoringContinuous Variable: A measure score in which each individual value for the measure can fall anywhere along a continuous scale (e.g., mean time to thrombolytics which aggregates the time in minutes from a case presenting with chest pain to the time of administration of thrombolytics).Proportion: A score derived by dividing the number of cases that meet a criterion for quality (the numerator) by the number of eligible cases within a given time frame (the denominator) where the numerator cases are a subset of the denominator cases (e.g., percentage of eligible women with a mammogram performed in the last year).Ratio: A score that may have a value of zero or greater that is derived by dividing a count of one type of data by a count of another type of data (e.g., the number of patients with central lines who develop infection divided by the number of central line days).

4.5 Quality Measure TypesOutcome Measure: A measure that indicates the result of the performance (or non-performance) of a function or process.Process Measure: A measure which focuses on a process which leads to a certain outcome, meaning that a scientific basis exists for believing that the process, when executed well, will increase the probability of achieving a desired outcome.

4.6 General Timing ConstraintsElements conforming to the IVL_TS data type can contain several child elements such as <low>, <high>, <center>, and <width>. The HL7 Data Types R2 specification contains definitions and rules for the use of these elements, and users should refer to that specification for a full description of their use. However, some key rules will be paraphrased here. The <low> element represents the start time for an event, the <high> element represents the end time for an event, the <center> element represents the midpoint of the event, and the <width> element represents the duration of the event. It is important to note that the <width> element is not allowed when both <low> and <high> are specified.

5 EXAMPLES

5.1 eMeasure Example FilesThe following sample measures are provided for illustration purposes only. They are all draft, awaiting formal validation by the measure steward.

An example HQMF document for Joint Commission Stroke 3 Quality Measure is available by following the link.

An example HQMF document for Joint Commission Stroke 8 Quality Measure is available by following the link.

An example HQMF Document for National Initiative for Children's Healthcare Quality BMI Percentile Recording Quality Measure is available by following the link.

An example HQMF Document for Centers for Medicare and Medicaid Services Emergency Department is available by following the link.

An example HQMF Document for Joint Commission Inpatient Psychiatry is available by following the link.

5.2 Sample HQMF Rendering Style SheetThis is a sample HQMF XSLT style sheet that can be used to transform an eMeasure into HTML. It is provided as a convenient starting point for local style sheet development, and has several known limitations, including:

Local implementations may have different requirements for rendering HQMF header components;

Does not support RegionOfInterest rendering in the narrative block. Does not support rendering of inline multimedia (e.g. multimedia that is Base

64 encoded within the eMeasure document). Does not support rendering of deleted text within the Narrative Block.

A sample style sheet for rendering an eMeasure into a web browser is available by following the link.

5.3 Using Occurrences of QDM in HQMFA measure can have a criterion that require two instances of the same type of Quality Data Model (QDM) and compare the timing relativity between the two instances. For example, if the measure requires two continuous respiratory rates taken with no more than 2.5 hours elapse, Occurrence A and B can be used to distinguish the two separate instances of the procedure of taking respiratory rate. It is critical to create a unique instance identifier for each instance of QDM as well as an intuitive title. It is suggested in HQMF to create a unique id.extension in procedureCritieria which will correspond to the localVariableName. As a result, the localVariableName becomes unique even sharing the same kind of QDM and allows implementation of proper naming instances feasible.


Cheng wrote this section “Using Occurrences of QDM in HQMF” in response to Req#76.Spreadsheet suggests it belongs in Section 5 – Examples.CK: That was my best guess. If Rick likes it here, I’m fine with that.


Link need.mable of Contentsgenerated automatically when you post on the web?��


JD created 3 V2 measure sample files:HQMF_V2_ AMI10.xml: the sample measure file (AMI-10) [file: HQMF_V2_ AMI10.html‎]HQMF_V2_AMI10.html: the web browser rendered measure HTML file [file: blocked in email‎]HQMFV2.xsl: the HQMF V2 measure human readable HTML rendition XSL file. [file: blocked in email‎]All files are also available in SVN project

The example below shows representations of the Occurrence A and Occurrence B of the procedure of taking respiratory rate. The next example shows the criteria that the time lapse between the Occurrence A and Occurrence B is no more than 2.5 hours.

<entry typeCode="DRIV"> <localVariableName value="OccurrenceAOfTakingRespiratoryRate"/> <procedureCriteria classCode="PROC" moodCode="DEF"> <id> <item root="0" extension="OccurrenceAOfTakingRespiratoryRate"/> </id> <title value="Occurrence A Of Procedure Performed: Taking Respiratory Rate"/> <code valueSet="2.16.840.1.113883.3.117.1.7.1.120"/> <definition> <procedureReference classCode="PROC" moodCode="EVN"> <id root="0" extension="Procedures"/> </procedureReference> </definition> <excerpt> <sequenceNumber value="1"/> <subsetCode value="SEQUENTIAL"/> </excerpt> <temporallyRelatedInformation typeCode="DURING"> <pauseQuantity/> <encounterReference classCode="ENC" moodCode="EVN"> <id root="0" extension="InpatientEncounter"/> </encounterReference> </temporallyRelatedInformation> </procedureCriteria></entry><entry typeCode="DRIV"> <localVariableName value="OccurrenceBOfTakingRespiratoryRate"/> <procedureCriteria classCode="PROC" moodCode="DEF"> <id> <item root="0" extension="OccurrenceBOfTakingRespiratoryRate"/> </id> <title value="Occurrence B Of Procedure Performed: Taking Respiratory Rate"/> <code valueSet="2.16.840.1.113883.3.117.1.7.1.120"/> <definition> <procedureReference classCode="PROC" moodCode="EVN"> <id root="0" extension="Procedures"/> </procedureReference> </definition> <excerpt> <sequenceNumber value="2"/> <subsetCode value="SEQUENTIAL"/> </excerpt> <temporallyRelatedInformation typeCode="DURING"> <pauseQuantity/> <encounterReference classCode="ENC" moodCode="EVN"> <id root="0" extension="InpatientEncounter"/> </encounterReference> </temporallyRelatedInformation> </procedureCriteria></entry>

<entry typeCode="DRIV"> <localVariableName value="TimeLapseBetweenTwoSequentialOccurrencesOfTakingRespiratoryRateLTE2.5hrs"/> <procedureCriteria classCode="PROC" moodCode="DEF"> <id> <item root="0" extension="TimeLapseBetweenTwoSequentialOccurrencesOfTakingRespiratoryRateLTE2.5hrs"/> </id> <title value="Time lapse between two sequential occurrences of taking respirator rate less than or equal to 2.5 hours"/> <definition> <procedureReference classCode="PROC" moodCode="EVN"> <id root="0" extension="OccurrenceAOfTakingRespiratoryRate"/> </procedureReference> </definition> <temporallyRelatedInformation typeCode="DURING"> <pauseQuantity value="-2.5" unit="h"/> <procedureReference classCode="ENC" moodCode="EVN"> <id root="0" extension="OccurrenceBOfTakingRespiratoryRate"/> </procedureReference> </temporallyRelatedInformation> </procedureCriteria></entry>

6 HQMF SCHEMAAn eMeasure document conforms to and is a valid XML document against the eMeasure Schema. The eMeasure schema can be viewed by following the link.

The eMeasure Schema (EMeasure.xsd) can be found here The POQM_MT000001UV Schema (POQM_MT000001UV.xsd) can be found

here The HL7/ISO Data Types R2 schema (iso-21090_hl7-r2_datatypes.xsd) file can be

found here The Infrastructure Root schema (infrastructureRoot-r2.xsd) file can be found here. The Narrative Block schema (NarrativeBlock.xsd) file can be found here. The Voc schema (voc-r2.xsd) can be found here.

The eMeasure XSD, XSL and sample XML files can be downloaded from here as a single zip file. The eMeasure schema is algorithmically generated from the HQMF model as described above (see HL7 HQMF XML Implementation (§ 2.7 )), followed by various hand edits needed to accommodate structured documents:

Wrap POQM_MT000001UV.xsd in eMeasure.xsd (which declares the root eMeasure element, QualityMeasureDocument).

Reorder act relationships coming off of QualityMeasureDocument so that component/section comes last.

Remove the trailing “1” from some element names (for example, AllTrue1 becomes AllTrue).

Incorporate narrative block markup into section.text: o Include narrative block schema. o Change type of section.text to "StrucDoc.Text"

7 ACRONYMS AND ABBREVIATIONSNQF National Quality ForumHER Electronic Health RecordAMA American Medical Association NCQA National Committee for Quality AssuranceEHRA Electronic Heath Record AssociationHQMF Health Quality Measure FormatCMS Centers for Medicare and Medicaid ServicesHL7 Health Level Seven ONC Office of the National CoordinatorS&I Standards and InteroperabilityRIM Reference Information ModelPMRL Performance Measure Reporting LanguageIHTSDO International Health Terminology Standard Development OrganisationLOINC Logical Observation Identifiers Names and Codes