March 29, 2019
Health Level Seven International® invites you to take part in the ballot openings for balloting HL7 candidate standards and documents for the upcoming May 2019 ballot cycle.
The candidate standards and other documents described in this announcement are balloting prior to HL7's May 2019 Working Group Meeting (WGM). Comments received from consensus group members will be addressed at that WGM running May 4-10, 2019 in Montreal (Quebec), Canada.
Ballot Period Open/Close Dates
Voting for consensus group members in most ballots in this document will open and close on the following dates. Exceptions for a specific ballot are listed with that ballot description.
Ballot Open Date: Friday, March 29, 2019
Ballot Close Date: Monday, April 29, 2019
Consensus Group Enrollment Period
Consensus Group Enrollment Period is now closed
Important Note: Consensus group signup closes when ballot voting begins.
Changes from the initial announcement are identified in the Update to Ballot Announcement for May 2019 Ballot Cycle document released when this ballot cycle opens.
All those engaged in balloting should be informed that any subsequent ballot of material previously balloted at the normative level will supersede all previous ballots. Any votes or comments from previous ballots will not count towards the new normative ballot; for any comments to be considered again, voters will need to cast a new ballot with comments.
The grid below provides the name of the sponsoring and co-sponsoring Work Group(s) announcing the ballot opening for the ballot listed. Those interested in ballots for a certain attribute can sort the grid: by Work Group, or by product family for example,
|Work Group||Project ID||Ballot Name||Family||Ballot Iteration||Ballot Description||Last Balloted||Unique Ballot ID|
|Anesthesia||1153||HL7 Domain Analysis Model: Intra-Procedure Anesthesia, Release 1||HL7||1st Informative Ballot||The Anesthesia (intra-procedure) Domain Analysis Model will focus on the intra-procedure anesthetic process and its documentation in the anesthetic record. The goal of this project is to support the exchange and understanding of anesthesiology data by establishing:
• A structural outline of the anesthetic record
• Detailed models of significant components of intra-procedural anesthesia
• Standard terms and definitions for common anesthesiology data elements
|Biomedical Research and Regulation||1424||HL7 FHIR® Implementation Guide: Common Data Model Harmonization for Research (CDMH), Release 1 - US Realm||FHIR||1st STU Ballot||From a standards perspective, the project will specifically perform the following
• Create and update FHIR profiles which can be used to represent the data that is being accessed by the researchers.
• Update the DAF-Research IG which has already created some of these profiles.
• Update the Data Extraction and transformation processes within DAF-Research to use the various profiles.
|Since the last ballot of this material in 2019MAY , the following changes have been made: New ballot||FHIR_IG_CDMH_R1_D1_2019MAY|
|Biomedical Research and Regulation||1426||HL7 FHIR® Implementation Guide: Women’s Health Technology Coordinated Registry Network (CRN), Release 1 - US Realm||FHIR||1st STU Ballot||From a standards perspective, the project will outline the mechanisms that can be used to capture and exchange common or core data elements related to women’s health collected as part of the clinical care delivery eco-system. Specifically, the project will examine how to use FHIR Resources and IG’s to facilitate collection and exchange of data elements related to women’s health.||Since the last ballot of this material in 2019MAY , the following changes have been made: No substantive changes.||FHIR_IG_WHT_CRN_R1_D1_2019MAY|
|Biomedical Research and Regulation||1503||HL7 Domain Analysis Model: Biomedical Research Integrated Domain Group, Release 5.3||HL7||1st Informative Ballot||To ballot a new version of the BRIDG model that supports the additional semantics in support of NCI, DICOM and the National Biomedical Imaging Archive, the update of SDTM 3.1.3 to SDTM 3.2 and additional diagrams and reorganization changes to make BRIDG more accessible and easily navigated.||Since the last ballot of this material in 2019MAY , the following changes have been made: The newest version of the BRIDG model, release 5.3, adds support for NCI’s National Biomedical Imaging archive (NBIA ), CDISC’s Study Data Tabulation Model Implementation Guide (SDTMIG) v3.2, and a few new diagrams and assorted updates.
For NBIA, BRIDG is adding only one new model element. BRIDG already has a wide range of the concepts needed in support of imaging and these were leveraged for the vast majority of NBIA concepts. A new diagram also shows those concepts used in that harmonization effort.
For the CDISC SDTMIG v3.2 harmonization, little more than twenty model changes impact only about ten classes and many are due to the addition of new domains and variables added by CDISC to this version of SDTM. Again, the vast majority of semantics needed to support SDTM already exist in BRIDG. Several new diagrams are added to be able to view those concepts more easily.
This version of BRIDG makes a few structural changes, such as eliminating sub-domain packages and adding more diagrams, to make concepts in the model easier to search for and find. Also included are a few updates and corrections to previously added model elements.
|Clinical Decision Support||1493||HL7 FHIR® Implementation Guide: Documentation Templates and Payer Rules (DTR), Release 1- US Realm||FHIR||1st STU Ballot||This implementation guide will provide use cases, patterns, profiles, and extensions needed to support documentation requirements and rules for specific treatments and services to allow health systems and providers to ensure services are covered and/or medically appropriate.||Since the last ballot of this material in 2019SEP , the following changes have been made: This is the initial draft for comment of the implementation guide, which contains a complete description of the use cases and accompanying profiles and extensions.||FHIR_IG_DTR_R1_O1_2019MAY|
|Clinical Decision Support||1108||HL7 Cross-Paradigm Specification: Clinical Quality Language, Release 1||HL7||4th STU Ballot||The Clinical Quality Language Specification defines a representation for the expression of clinical knowledge that can be used within both the Clinical Decision Support (CDS) and Clinical Quality Measurement (CQM) domains. The specification defines both a high-level, clinically focused syntax for human-readable logic, as well as an equivalent canonical, machine-readable representation focused on sharing, translation, and evaluation of the logic.||Since the last ballot of this material in 2019MAY , the following changes have been made: In addition to numerous clarifications and errata throughout, this update includes:
1) Improved semantics for collapse and expand (including precision-based decimal predecessor and successor, as well as a count function for intervals)
2) FHIRPath alignment (including removing timezone offset from the Time type, and changing DateTime to use a Decimal for the seconds component, rather than considering milliseconds a separate precision)
3) Support for non-patient contexts (and change "Population" context to "Unspecified")
4) Support for namespacing CQL libraries
5) Support for unit conversions
|Clinical Interoperability Council||1363||HL7 FHIR® Implementation Guide: Breast Cancer Data, Release 1- US Realm||FHIR||3rd Comment-Only Ballot||CIMI Logical Models and FHIR Profiles for Breast-Cancer focused Radiology in collaboration with RSNA and ACR.||Since the last ballot of this material in 2019SEP , the following changes have been made: This will be the first ballot of this material 'for comment' with subsequent ballots to target Informative and STU by January 2020.||FHIR_IG_BRCANCER_R1_O3_2019MAY_WITHDRAWN|
|Clinical Interoperability Council||1494||HL7 FHIR® Implementation Guide: Health Record Exchange (HRex) Framework, Release 1- US Realm||FHIR||1st STU Ballot||The scope of the HRex Framework project is to define combinations of exchange methods, specific payloads, search criteria, conformance, provenance, and other relevant requirements to support specific exchanges of clinical information between: 1) providers, 2) a provider and a payer, 3) a payer and providers, and/or a provider and any third party involved in value based care.||Since the last ballot of this material in 2019SEP , the following changes have been made: N/A||HL7_FHIR_IG_HRex_2019MAY_WITHDRAWN|
|Clinical Quality Information||1499||HL7 FHIR® Implementation Guide: Quality Measures, Release 1- US Realm||FHIR||1st STU Ballot||FHIR Clinical Reasoning provides infrastructure requirements for representing a health quality measure as an electronic format. A quality measure is a quantitative tool to assess the performance 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.||Since the last ballot of this material in 2019MAY , the following changes have been made: This implementation guide (IG) provides specific guidance to eCQM developers and implementers to assure consistency for applying CQL expressions using any data model, enhancing ability to share eCQM artifacts for direct implementation and calculation. The IG will provide examples using the US Realm FHIR QICore data model but it will not restrict usage of any data model.||FHIR_IG_QM_R1_D1_2019MAY|
|Clinical Quality Information||1429||HL7 FHIR® Implementation Guide: Data Exchange for Quality Measures, Release 1 - US Realm||FHIR||2nd STU Ballot||This Implementation Guide defines common data exchange patterns usable for a broad range of value-based health care use cases, including quality measurement and reporting, and public health care reporting.||Since the last ballot of this material in 2019MAY , the following changes have been made: This ballot version includes numerous changes in support of reconciliation efforts with comment submitters, as well as the inclusion of use cases to support more general quality measurement and public health reporting use cases. Substantive changes include:
1) Ensuring the guidance addresses challenges associated with pull and subscription exchange mechanisms.
2) Ensuring the exchange mechanisms can support the use of messaging protocols.
3) Ensuring support for additional use cases including Colorectal Cancer Screening and Hospital Reporting for Venous Thromboembolism and Stroke reporting.
4) Ensuring support for communication of quality measurement results.
|Clinical Quality Information||1142||HL7 Version 3 Implementation Guide: Clinical Quality Language (CQL)-based Health Quality Measure Format (HQMF), Release 1 - US Realm||V3||4th STU Ballot||The CQL-Based HQMF Implementation Guide provides guidance and conformance requirements for defining and sharing electronic Clinical Quality Measure (eCQM) specifications. The guide defines an approach to specifying eCQMs using Clinical Quality Language (CQL) and Quality Data Model (QDM).||Since the last ballot of this material in 2019MAY , the following changes have been made: This update addresses STU comments submitted during the trial-use period, as well as several known issues reported through usage and implementation. In addition, the update incorporates changes to support CQL STU 4 and QDM 5.5.||V3_IG_CQL_HQMF_R1_D4_2019MAY|
|Community-Based Care and Privacy (CBCP)||1431||HL7 FHIR® Implementation Guide: Electronic Long-Term Services & Supports (eLTSS), Release 1 - US Realm||FHIR||1st STU Ballot||This IG provides the opportunity to implement eLTSS FHIR based solutions which will have a transformative impact on the collection, exchange and sharing of Home and Community Based Services (HCBS) data, clinical data and provider service plans.||Since the last ballot of this material in 2019MAY , the following changes have been made: This FHIR IG will implement the previously balloted and published mappings to the HL7 Cross-Paradigm Guidance: Electronic Long-Term Services & Supports (eLTSS), Release 1 - US Realm (eLTSS data set).||FHIR_IG_eLTSS_R1_D1_2019MAY|
|FHIR Infrastructure||1497||HL7 FHIR® Implementation Guide: Bulk Data, Release 1||FHIR||1st STU Ballot||This Implementation Guide will provide guidance for enabling secure bulk data transfer for FHIR resources. The guide will define the application programming interfaces (APIs) through which an authenticated and authorized clients may request a bulk data export from a server, receive status information regarding progress in the generation of the requested files, and receive these files securely using a back end service authorization.||Since the last ballot of this material in 2019MAY , the following changes have been made: First ballot||FHIR_IG_BULKDATA_R1_D1_2019MAY|
|FHIR Infrastructure||1433||HL7 FHIR® Implementation Guide: Patient Reported Outcomes (PRO), Release 1 - US Realm||FHIR||1st STU Ballot||The Patient Reported Outcomes (PRO) FHIR Implementation Guide (IG) will focus on capturing and exchanging patient reported outcome data electronically using the FHIR standard. The data that is captured will be made available to both providers and authorized researchers. While the PRO FHIR IG can be applied to multiple use cases, the current requirements have been drawn from PCORnet use cases and implementations.||Since the last ballot of this material in 2019MAY , the following changes have been made: The version of the IG is backwards compatible with the previous version of the IG. The IG is built on the latest release of FHIR namely R4. The changes from the previous version to the current version including clarifying various parts of the IG based on ballot comments received, adding examples and updating implementation guidance for developers.||FHIR_IG_PRO_R1_O1_2018SED1_2019MAY|
|FHIR Infrastructure||1390||HL7 FHIR® Implementation Guide: Structured Data Capture (SDC), Release 2||FHIR||1st STU Ballot||SDC provides guidance on how to use Questionnaire and QuestionnaireResponse for more sophisticated questionnaires, such as are used in the research, payment, public health and other areas. It includes controls over rendering, data entry, calculations, population from existing data, converting questionnaire responses to other FHIR resources and describes how to produce adaptive questionnaires.||Since the last ballot of this material in 2019MAY , the following changes have been made: The updated SDC specification changes expectations for population and introduces extraction and adaptive questionnaire capabilities. It lightens expectations for conformance and provides additional rendering and calculation capabilities.||FHIR_IG_SDC_R2_O1_2018SED1_2019MAY|
|Financial Management||1490||HL7 FHIR® Implementation Guide: Authorization, Release 1- US Realm||FHIR||1st STU Ballot||This implementation guide will provide a standard for adoption by both providers and payers for the exchange of information necessary for authorization of services by a payer.||Since the last ballot of this material in 2019SEP , the following changes have been made: N/A||FHIR_IG_AUTH_R1_D1_2019MAY_WITHDRAWN|
|Financial Management||1428||HL7 FHIR® Implementation Guide: Coverage Requirements Discovery, Release 1 - US Realm||FHIR||2nd STU Ballot||In the US clinicians are often unaware of the expectations of payor organizations around care delivery, requirements for pre-authorizations and other processes. This results in denied payment, changes to therapy after initiation and/or additional overhead costs are incurred. Defining a standardized mechanism by which care delivery organizations and providers can query payors to find relevant guidance prior to care delivery will increase efficient delivery of care and corresponding payment.||Since the last ballot of this material in 2019MAY , the following changes have been made: Changes were made throughout the guide to respond to comments made during the prior ballot period "Ballot for Comment".||FHIR_IG_COVREQDISC_R1_D2_2019MAY|
|Financial Management||1489||HL7 FHIR® Implementation Guide: ePayer Data Exchange (ePDx), Release 1 - US Realm||FHIR||1st STU Ballot||This IG defines exchange methods (push, pull, triggers, subscription), use of other interoperability "standards" (e.g. CDS Hooks and SMART on FHIR) and specific use of FHIR resources to effectively exchange payer information regarding the current or previous care, including the provenance of the data, of one or more specific patients/members with a provider responsible for evaluating/specifying/ordering/delivering care for the patient.||Since the last ballot of this material in 2019SEP , the following changes have been made: N/A||FHIR_IG_ePDx_R1_O1_2019MAY_WITHDRAWN|
|Health Care Devices||1277||HL7 FHIR® Implementation Guide: Personal Health Device (PHD), Release 1||FHIR||3rd STU Ballot||This implementation guide provides the mapping of data from IEEE 11073 Personal Health Devices to FHIR by developing and using FHIR profiles.||Since the last ballot of this material in 2019MAY , the following changes have been made: The main change includes implemented resolutions resulting from comments gathered in the previous ballog||FHIR_IG_PHD_R1_D3_2019MAY|
|Imaging Integration||1392||HL7 FHIR® Implementation Guide: FHIRCast, Release 1||FHIR||1st STU Ballot||FHIRcast synchronizes healthcare applications in real time to show the same clinical content to a common user. For example, a radiologist often works in three disparate applications at the same time (a radiology information system, a PACS and a dictation system), she wants each of these three systems to display the same study or patient at the same time. FHIRcast isn't limited to radiology use-cases.||Since the last ballot of this material in 2019MAY , the following changes have been made: N/A||FHIR_IG_FHIRCast_R1_D1_2019MAY|
|Implementable Technology Specifications||1237||HL7 Cross-Paradigm Specification: FHIRPath, Release 1||HL7||3rd Normative Ballot||FHIRPath is a graph traversal language which may be used to meet query language needs across HL7 families. In FHIR this language meets the needs for specifying a path (FHIRPath). FHIRPath is incorporated in Clinical Quality Language (CQL), an HL7 STU for representing clinical quality logic, to add graph traversal functionality.||Since the last ballot of this material in 2019MAY , the following changes have been made: Numerous clarifications have been made to the text and example as well as the substantive changes listed below:
Changed the following sections from Normative to STU: convertTo operators; 7.1 Aggregate; and,
#20310: Removed timezone offset from Time values (still present on DateTime values)
#20008: Corrected convertsToTime to not require the 'T' prefix
#20321: Marked Aggregate and Reflection sections as STU
#20311: Clarified requirements around timezone offset default behavior
#20309: Defined seconds as a decimal, rather than having a separate millisecond precision
#20201: Added .is() and .as() functions to the specification for backwards compatibility
#20200: Allowed strings to be used for environment variables for backwards compatibility
#20167: Added `any` function as a complement of `all`
#20013, #20004: Added literal notation for partial datetimes
#19635: Added quantity conversion function overloads
#19534: Added contains as a keyword to the grammar
#18501: Added a round() function
#17842: Added a sqrt() function
#17507: Added math functions: log(), exp(), ln(), power(), floor(), ceiling(), truncate() and abs()
#17455: Added an optional argument to trace() to allow logged content to be shaped
#20312: Clarified today() and now() semantics and added timeOfDay()
|Learning Health Systems||1317||HL7 Domain Analysis Model: Patient Centered Care Team, Release 1||HL7||1st Comment-Only Ballot||In a learning health system each activity in care and health promotion is informed by the collective knowledge of the system and the results of each activity update the knowledge of the system. Essential to such a system is the formal model which defines the roles and relationships of each entity which fulfills a role on the virtual team around each patient which this document describes||Since the last ballot of this material in 2018SEP , the following changes have been made: Updated based on comments in 1st comment only ballot logical model of relationships between care team members and definitions (including model) of non-credentialed/non-professional caregivers on the care team. There has, in particular, been expansion of the attributes and concepts related to roles that may be filled either by healthcare professionals or by family members and community members involved in the care of a patient.||HL7_DAM_PCCT_R1_O1_2019MAY_WITHDRAWN|
|Orders and Observations||1496||HL7 FHIR® Implementation Guide: DME Orders, Release 1- US Realm||FHIR||1st Comment-Only Ballot||Initial FHIR based implementation guide for DME orders between a provider and a DME supplier.||FHIR_IG_DME_R1_O1_2019MAY_WITHDRAWN|
|Orders and Observations||1238||HL7 Domain Analysis Model: Unique Device Identifier (UDI) Implementation Guidance, Release 1||HL7||3rd Informative Ballot||The focus of this ballot is to address the implantable
devices unique identification needs and support for implantable device list (e.g. Meaningful Use 2015 certification requirements).
|Since the last ballot of this material in 2019MAY , the following changes have been made: This version addresses the comments received in the first
|Orders and Observations||1512||HL7 Cross Paradigm Implementation Guide: UDI Pattern, Release 2||HL7||1st Normative Ballot||Update of content with R4 FHIR Device and Device Definition resources and any V2 content ready for use. The updates will be publishable as a Cross-Paradigm Implementation Guide.||Since the last ballot of this material in 2019MAY , the following changes have been made: The FHIR Device resource has been updated resulting in adjustments that need to be reflected in the informative FHIR section.
The V2 PRT segment in the V2.9 ballot is yielding name changes of the UDI fields. The associated proposed changes in the UDI Pattern will only be included if V2.9 passes ballot in a timely fashion.
|Patient Care||1495||HL7 FHIR® Implementation Guide: Clinical Data Exchange (CDex), Release 1- US Realm||FHIR||1st STU Ballot||The scope of the CDex project is to defined combinations of exchange methods (push, pull, subscribe, CDS Hooks, …), specific payloads (Documents, Bundles, and Individual Resources), search criteria, conformance, provenance, and other relevant requirements to support specific exchanges of clinical information between provider and other providers and/or payers.||Since the last ballot of this material in 2019SEP , the following changes have been made: N/A||FHIR_IG_CDex_R1_O1_2019MAY_WITHDRAWN|
|Pharmacy||1139||HL7 CDA® R2 Implementation Guide: Pharmacy Templates, Release 1 STU Release 2||CDA-Related||2nd STU Ballot||The Pharmacy Templates Implementation Guide defines common pharmacy artifacts (order, dispense, administration and statement) in CDA R2 form. The scope of this ballot is limited to the new content for Medication Dispense and Medication Administration Templates. Feedback not related to these templates will be found "not related" and should be made via the STU change request process.||Since the last ballot of this material in 2019MAY , the following changes have been made: Since the last ballot of this material in 2018MAY, the following changes to add Medication Dispense and Medication Administration Templates have been made. In addition, ballot reconciliation on Medication Order and Medication Statement have been applied.||CDAR2_IG_PHARM_TEMPLATES_R1_D2_2019MAY|
|Public Health||1002||HL7 CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), Release 1 STU Release 2 – US Realm||CDA||3rd STU Ballot||This project developed an HL7 CDA IG for representing data collected by the CDC NCHS within the Division of Health Care Statistics (DHCS). The data are collected through surveys of ambulatory, inpatient, and outpatient care services in the United States: the National Ambulatory Medical Care Survey (NAMCS), the National Hospital Care Survey (NHCS) and the National Hospital Ambulatory Medical Care Survey (NHAMCS). This includes mapping data elements required by the surveys to existing templates.||Since the last ballot of this material in 2019SEP , the following changes have been made: Update the IG based on implementer feedback contained in the STU comments.||CDAR2_IG_NHCS_R1_D3_2019MAY|
|Public Health||1216||HL7 CDA® R2 Implementation Guide: Public Health Case Report - the Electronic Initial Case Report (eICR) Release 1, STU Release 2.0 - US Realm||CDA||2nd STU Ballot||This implementation guide specifies an electronic initial case report (eICR) to support public health reporting of reportable conditions from healthcare organizations to public health agencies are required by law.||Since the last ballot of this material in 2019MAY , the following changes have been made: STU comments will be addressed, Pregnancy Status, Occupational Data for Health, Vital Signs, Lab Results Status and Specimen Source||CDAR2_IG_PHCASERPT_R2_D2_2019MAY|
|Public Health||1423||HL7 FHIR® Implementation Guide: Bidirectional Services eReferrals (BSeR), Release 1 - US Realm||FHIR||2nd STU Ballot||The Bidirectional Services eReferrals (BSeR) FHIR IG provides guidance on STU3 FHIR Resources and US Core IG profiles for use in exchanging a referral request and specific program data from a clinical provider to a typically extra-clinical program service provider, such as a diabetes prevention program, a smoking quitline, or a hypertension management training program. And provides for the return of feedback information from the service program to the referring provider.||Since the last ballot of this material in 2019MAY , the following changes have been made: This BSeR was included in the September 2018 ballot cycle. This iteration addresses the negative comments received. The major changes are the addition of terminology, artifacts to implement an exchange workflow, and repair of broken links in the specification.||FHIR_IG_BSeR_R1_D2_2019MAY|
|Public Health||1475||HL7 FHIR® Implementation Guide: Vital Records Mortality and Morbidity Reporting, Release 1 - US Realm||FHIR||1st STU Ballot||The VRDR FHIR IG provides guidance regarding the use of FHIR resources for the bidirectional exchange of mortality data between State-run PHA Vital Records offices and NCHS.||Since the last ballot of this material in 2019MAY , the following changes have been made: All of the material in this specification is new and does not contain changes to any previously balloted material.||FHIR_IG_VRDR_R1_D1_2019MAY|
|Public Health||1477||HL7 Version 2.6 Implementation Guide: Vital Records Death Reporting, Release 1 - US Realm||V26||1st STU Ballot||Vital Records death reporting has been developed as STU. A new STU version is
needed to support additional requirements based on the addition of new
stakeholders who will be involved with data exchange. The new stakeholders
include funeral directors, and medical examiners, as well as the Electronic Death
|Since the last ballot of this material in 2019MAY , the following changes have been made: The changes will include the addition of new stakeholders participating in the data
exchange and the associated messaging interactions. The new stakeholders include
funeral directors, and medical examiners. In addition the role of the Electronic
Death Registration System will be explicitly recognized. It is expected that very
little new data will be required, but additional conformance profiles are expected
to recognize the role of new stakeholders.
|Publishing||773||HL7 Version 2.9 Messaging Standard||V29||5th Normative Ballot||This is another ballot for V2.9 Normative edition with reconciled comments from the previous ballot cycle of Jan. 2019.||Since the last ballot of this material in 2019MAY , the following changes have been made: This is another ballot for V2.9 Normative edition with reconciled comments from the previous ballot cycle of Jan. 2019.||V29_R1_N5_2019MAY|
|Security||914||HL7 Version 3 Standard: Privacy and Security Architecture Framework, Release 1||V3||2nd Normative Ballot||The Privacy and Security Architecture Framework (PSAF) is comprised of: Volumes 1 and 2, Trust Framework for Federated Authorization conceptual and behavioral models;
Volume 3 Provenance, which addresses topics needed for trustworthy information exchange; and Volume 4 Audit, which provides a conceptual model for the audit service interfaces. These volumes form the basis of HL7 implementable privacy and security specifications. Only Volume 4 is in scope for comments.
|Since the last ballot of this material in 2019SEP , the following changes have been made: PSAF Volume 3 Provenance changes: Clarification on architecture's concept of a Federated Provenance Domain and capabilities for tracking the trustworthiness of participant's submission of discoverable provenance to that domain. PSAF Volume 4 Audit is a refactoring of the PASS Audit Conceptual Model, which passed normative ballot in 2017. The previous Audit specification missed the publication deadline of one year after approval as normative, and therefore required reballoting.||V3_PSAF_R1_N2_2019MAY|
|Services Oriented Architecture||1420||HL7 Cross Paradigm Model Transformation Service, Release 1||HL7||1st STU Ballot||This project will create a functional specification for transformation services with exemplary mappings using storyboards developed by the SOA Working Group, the interested parties of the Project, and co-sponsor WGs of this project. The project will create story boards that use aspects of 1) the current versions of HL7 Standards of V2, C-CDA, and FHIR, and 2) new information models such as CIMI and realm specific examples such as the FHIM.||Since the last ballot of this material in 2019MAY , the following changes have been made: N/A||HL7_MODEL_XFORM_R1_O1_2019MAY|
|Structured Documents||1480||HL7 Guidance: CDA Implementation Guide Quality Criteria Maintenance, Release 1||CDA||1st Comment-Only Ballot||This document will contain the proposed starting set of CDA Implementation Guide Quality Criteria. The initial set of criteria are based on the long standing CDA IG quality criteria developed by the Structured Documents work group. This draft for comment ballot is intended to gather comments on this starter set of criteria. Once finalized, the CDA Management Group will be responsible for evaluating the degree to which all HL7 CDA IG's meet these criteria.||Since the last ballot of this material in 2019MAY , the following changes have been made: N/A||CDA_IG_QUAL_CRIT_R1_O1_2019MAY|
|Structured Documents||1232||HL7 CDA® R2 Implementation Guide: Pharmacist Care Plan Document, Release 1 - US Realm||CDA||1st STU Ballot||The goal of this project is to develop an electronic care plan with enhanced medication management content based on the templates in the HL7 Implementation Guide for C-CDA Release 2.1: Consolidated CDA for Clinical Notes.||Since the last ballot of this material in 2019MAY , the following changes have been made: Apply changes from comment-only ballot reconciliation and add bindings to PharmacyHIT value sets currently in VSAC.||CDAR2_IG_CCDA_MTM_CAREPLAN_R1_D1_2019MAY|
|Structured Documents||1192||HL7 CDA® R2 Implementation Guide: Healthcare Associated Infection Reports, Release 3 - US Realm||CDA||4th STU Ballot||With cooperation from CDC and Healthcare Associated Infections (HAI) software vendors, document will be STU Release 4 of the HL7 Implementation Guide for CDA® Release 2: Healthcare Associated Infection Reports Release 3. The IG will continue to support electronic submission of HAI data to the National Healthcare Safety Network. This document is the fourth STU release and will include new outpatient forms, LOS/MEN denominator and updates to selected existing forms and vocabulary.||Since the last ballot of this material in 2019MAY , the following changes have been made: Addition of forms: Outpatient Same Day Outcome Measures Event, Outpatient Same Day Outcome Measures Summary, Outpatient Procedure Denominiator, Outpatient SSI (Surgical Site Infection) Event, LOS (Late Onset Sepsis)/MEN (Meningitis) Denominator and updates to selected existing forms and vocabulary.||CDAR2_IG_HAIRPT_R3_D4_2019MAY|
|Structured Documents||977||HL7 CDA® R2 Implementation Guide: Questionnaire Response Document, Release 1||CDA||2nd Normative Ballot||This ballot is for an implementation guide defining
Questionnaire Response Document for purpose of
representing patient responses to questionnaires as a
structured document reusing and/or enhancing existing
CDA templates where possible creating new CDA
templates where necessary.
|Since the last ballot of this material in 2019MAY , the following changes have been made: This is the second Normative ballot for this document.
The changes made to the document reflect the resolutions
that were agreed to by the working group. Both substantive
and non-substantive changes were made. As this is the
second Normative ballot for this IG, the ballot comments are
limited to only the substantive changes. The substantive
changes were due to the following N1 comments:
1, 2, 3, 4, 5, 6, 7, 9, 10, 11, 13, 16, 18, 31, 56, 60.
Comments during this second (N2) ballot are resticted to
those (subsantive) changes only. The corresponding final
reconciliation spreadsheet can be found here:
|Structured Documents||976||HL7 CDA® R2 Implementation Guide: Structured Form Definition Document, Release 1||CDA||2nd Normative Ballot||This ballot is for an implementation guide defining a
Structured Form Definition Document for purpose
of representing patient questionnaires as a structured
document reusing and/or enhancing existing CDA templates
where possible creating new CDA templates where necessary.
|Since the last ballot of this material in 2017JAN , the following changes have been made: This is the second Normative ballot for this document.
The changes made to the document reflect the resolutions
that were agreed to by the working group. Both substantive
and non-substantive changes were made. As this is the
second Normative ballot for this IG, the ballot comments are
limited to only the substantive changes. The substantive
changes were due to the following N1 comments: 1, 7, 11,
21, 25, 28, 29, 32, 33, 34, 35, 36, 37, 38, 39, 45, 46, 47.
Comments during this second (N2) ballot are restricted to
those (substantive) changes only. The corresponding final
reconciliation spreadsheet can be found here:
|Structured Documents||1232||HL7 FHIR® Implementation Guide: Pharmacist Care Plan Document, Release 1 - US Realm||FHIR||1st STU Ballot||The goal of this project is to develop an electronic care plan with enhanced medication management content based on the FHIR profiles in the HL7 Implementation Guide for C-CDA on FHIR and the US Core specification.
||Since the last ballot of this material in 2019MAY , the following changes have been made: Apply changes from comment-only ballot reconciliation and add bindings to PharmacyHIT value sets currently in VSAC.||FHIR_IG_CCDA_MTM_CAREPLAN_R1_D1_2019MAY|
|Structured Documents||1192||HL7 FHIR® Implementation Guide: Healthcare Associated Infection Reports, Release 1 - US Realm||FHIR||2nd STU Ballot||With cooperation from CDC and Healthcare Associated Infections (HAI) software vendors, document will be STU Release 2 of the HL7 Implementation Guide for FHIR®: Healthcare Associated Infection Reports Release 1. The implementation guide will add to the CDA support of electronic submission of HAI data to the National Healthcare Safety Network. This document is the second STU release and will include the new outpatient forms and LOS/MEN denominator form.||Since the last ballot of this material in 2019MAY , the following changes have been made: Addition of forms: Outpatient Same Day Outcome Measures Event, Outpatient Same Day Outcome Measures Summary, Outpatient Procedure Denominiator, Outpatient SSI (Surgical Site Infection) Event, LOS (Late Onset Sepsis)/MEN (Meningitis) Denominator.||FHIR_IG_HAI_R1_D2_2019MAY|
|Structured Documents||1498||HL7 Informative Document: C-CDA Scorecard Rubric, Release 1- US Realm||CDA||1st Informative Ballot||The C-CDA Rubric are a set of rules defining the methodology behind the scoring rubric to be used by tool developers to include in a C-CDA quality testing tool. The goal is to promote best practices in C-CDA implementations by assessing key aspects of the structured data found in individual documents. Identifying areas of improvement can increase interoperability of C-CDA documents. The rubrics are meant to be tool agnostic.||Since the last ballot of this material in 2019MAY , the following changes have been made: N/A||HL7_C-CDA_RUBRIC_R1_I1_2019MAY|
For more information on ballot procedure, such as general guidelines, and voting, see Ballot Procedures and Guidelines