HL7 Project Scope Statement
The objective of the project scope statement is to communicate the type of activities a group is undertaking to achieve specific objectives or to produce specific work products. Project Scopes should provide sufficient information to allow inexperienced individuals to anticipate what a group is working on and decide if they wish to become involved. Project Scope statements should also assist TC chairs to manage the workload of the TC and help to set priorities and recognize inter-dependencies with the work of other TCs.
ARB reviews project statements to assure that the entries are consistent with the directions, discover project overlaps or dependency gaps and ensure the names and descriptions are clear and unambiguous across all projects.
Group Name(s)
Structured Documents Technical Committee and Pediatric Data Standards Special Interest Group
Enter the name of the TC or SIG that is sponsoring the project. Some projects are jointly sponsored and the name of all sponsoring groups should be noted.
Project Initiation Date
2007-09-20
Enter the date the project started. Sometimes a project gets started before its scope statement has been approved by the group. The initiation date is the date people start actually working.
Project Name
Quality Reporting Document Architecture
Enter the name by which a project will be known. The name should be concise, describe the objective and be unambiguous from the names of all other projects the group takes on.
Project Description
Health care institutions routinely collect and report performance measure data to improve the quality of care provided to patients. Measure data conforms to the requirements of defined "quality measures" which are written and maintained by institutions concerned about health care quality. This project will define and bring to ballot a set of specifications for communicating quality measure definitionsto,and reporting quality data from, electronic health records. The initial focus of the project will involve patient-level data submissions and, for specific use cases, it willinclude population-based submissions across a defined measure population.
The specification will foster the development of fully automated EHR-based data submission and reporting. As needed, it will be compatible with semi-automated reporting which continues to rely on information derived from manual chart review and abstraction.
This project will be compatible with the developing project known as "Clinical Document Architecture Release 2 for Reporting". In addition, this project will leverage and harmonize similar activities within and outside HL7 to avoid duplication of existing efforts.
Enter a description of the project. The description should have sufficient detail that an individual with no previous exposure to the group (or even HL7) would understand what the project is expected to accomplish.
Project Objective(s)
The goal of the project will be to develop HL7 Version 3 structured document specifications for quality measurement. Specifically, the project will:
1. Propose a draft standard for trial use (DSTU) for HL7 V3 Standard Specifications for Reporting Quality Measures to be known as the "Quality Reporting Document Architecture". The DSTU will be consistent with other implementations under development by SDTC. The DSTU will define data reporting requirements across the quality reporting domain and will provide specific guidance on an initial set of high-priority quality measures. This set of measure definitions will be augmented over time.
2. Explore the feasibility of aspecification that takes defined measures and communicates compliance requirements to a data collection application (EHR). The specification willre-use the same model-driven validation rules as the QRDA.
3. Develop requirements for a set of messages for distributing instances of the QRDA in conjunction with appropriate HL7 TCs/SIGs including Patient Care and Patient Safety.
4. Coordinate with groups outside of HL7, specifially the Alliance for Pediatric Quality, the Collaborative for Performance Measure Integration with EHR Systemswhich is defining requirements for export of quality measure data, and the National Quality Forum (NQF) Health Information Technology Expert Panel (HITEP).
4. Support the use cases developed by the American Health Information Community (AHIC), the Health Information Technology Standards Panel (HITSP) and Integrating the Healthcare Enterprise (IHE). .
Enter a list of specific objectives the project is trying to meet. If the project is to develop one or more work products, the work products’ descriptions should be clear, concise and unambiguous. Normative work products should be labeled as such. In the rare case where an objective is not a work product, it must be described in a way that an observer can always determine a yes or no answer to the question 'has this objective been met?'
Target Delivery Date(s)
The target date for project submission for HL7 national ballot (DSTU) is May 2008
Enter the date the project is expected to be completed. At initiation, a project may only have a general target, eg. Fall Meeting 2001. As projects progress, target dates can be updated and refined. Projects that have more than one work product to deliver should list each work product’s expected delivery date separately
Project Dependencies
None
Enter a list of all projects or project objectives that this project is dependent on for completion. A dependency may be the work of another project undertaken by this group or by another group. Anticipating dependencies can allow groups to coordinate their effort to ensure the overall objectives of HL7 can be met. An example might be: the PRA ballot needs the data types produced by Control Query to be finalized prior to full membership ballot
Project ID
A project ID will be assigned by the ARB when the Project Scope Statement is reviewed. Leave this section unchanged when initially filling out the form.
Project Scope Statement Status
Status:APPROVED Date of most recent draft or change in status:2009-01-14
Enter the status of the Project Scope Statement itself, and the date the status was established. Possible statuses are DRAFT (prepared for discussion); APPROVED (approved by the committee(s) sponsoring the project); REVIEWED (reviewed by the Architecture Review Board); and, AMENDED (amended by a committee chair, usually to update dates or objectives).