Difference between revisions of "Performance Quality Report"

From IHE Wiki
Jump to navigation Jump to search
 
Line 15: Line 15:
  
 
==June 16, 2009 Profile Review==
 
==June 16, 2009 Profile Review==
Details available at: [[Performance Quality Report QRPH Review Call 17 June 2009]]
+
Details available at: [[Performance Quality Report QRPH Review Call 17 June 2009]]<br>
 +
Next Profile Update Call Wednesday 24 June 2009, 1-2 PM CDT<br>
 +
 
 
==Discussion on various sections and comments, tasks==
 
==Discussion on various sections and comments, tasks==
 
Conference Call<br>
 
Conference Call<br>

Latest revision as of 08:42, 18 June 2009

Current work


Schema to Represent Measure Specifications
Health Quality Measures Format (HQMF) Reference Guide
Health Quality Measure Format (HQMF) Issues Log
Ambulatory Measures:

  1. Controlling high BP (logic: could bring in VSs from EHR) [page 49 at link below]
  2. Colon cancer screening (logic: complex measure due to multiple modalities and currently requires hybrid review) [page 99 at link below]
  3. Overuse measures for adults and children - (logic: requires meds and diagnoses and gets to overuse)
    1. Avoid antibiotics for child with URI [page 7 at link below]
    2. Avoid antibiotoic use for adult with bronchitis [page 4 at link below]

NCQA Ambulatory Measure Specifications

June 16, 2009 Profile Review

Details available at: Performance Quality Report QRPH Review Call 17 June 2009
Next Profile Update Call Wednesday 24 June 2009, 1-2 PM CDT

Discussion on various sections and comments, tasks

Conference Call
Topic: QRPH Tech: Discussion, Performance Quality Report Profile
Date: Friday, December 5, 2008
Time: 2:00 PM, Central Standard Time

Project Scope

Three inpatient measure sets (Specification links above):

December 22, 2008 Proposal Update

  1. Create a standard xml definition (in IS06 and constructs)
    1. Instantiate as exemplars each of the 3 measure sets (in measure-specific document)
    2. Each instantiation will include vocabulary and where in the structure EHR these things can be found
  2. Present query to hybrid (clinical information system, administrative system, human, data warehouse, …) – so EHR can create a query (e.g., SQL) to an EHR – long-term target, not to be done this year
    1. (Interim step) Define what the content needs to be - derived from the hybrid information system, could use RFD and/or Quality standard data set (c38)
    2. The standard XML definition in item 1 above would use the same terminology and EHR context as the content described above
  3. Create QRDA (currently DSTU) document (general form to be referenced in IS06)
    1. Instantiate as exemplars each of the 3 measure sets (in measure-specific document)
    2. Patient-level data relevant to the measure in the document (all denominator, numerator, exclusion/inclusion criteria data elements) – now DSTU – level 1
    3. Aggregate – level 2 – proposal defined, but still to be validated
    4. Value of measure (e.g., 80% compliance) – level 3 – highest level of aggregation
  4. Run Schematron against QRDA to validate the QRDA contents (assume Patient-level and/or aggregate)

Next Steps

  • IHE QRPH Planning / Technical Committee Call Dec 22, 2008 to determine final status for profiles and white papers.

Agenda QRPH Joint Planning/Technical TCon 22 Dec 2009
Date and Time: Dec 22 12:00 - 2:00 PM CST
WebEx Link

Project Facts and Proposals per December 5, 2008 Discussion

  1. The current measures are endorsed by the National Quality Forum (NQF). The Joint Commission updates their measures every six months and the next update is due for publication in March (or at least submission for publication). Therefore, work on the ‘current’ measures will be outdated somewhat by publication. We should use the most updated version.
  2. Many of the data elements in the measures will require judgment calls with respect to whether EHR-available data are useful and sufficient to express the intent of the element and the context intended by the measure developer. For the output of the effort to have a specified measure that has the same meaning as the manual version, measure developers must participate. Patty Craig represents The Joint Commission and is seeking an additional resource from the measure development area. The Oklahoma Foundation for Medical Care (OFMC) is a partner in the measure development and a request for their participation is in progress.
  3. Some of the data elements in the measures will not have clear EHR or electronic codified data concepts. To accommodate such items, we propose that the measure specification be included as content within a Retrieve Form for Data Capture (RFD – an ITI Profile) as output of a Form Manager. The EHRs, as Form Receivers, will auto fill what is possible and enable human filling of information not in codified standard form. The completed form can be returned then as a constrained structured document (i.e., QRDA with Schematron testing). This last (return) step requires further analysis with respect to scope.
  4. The project will encode a measure within an existing structure. Inclusion of the implementation in an EHR which and subsequent production of a patient-level aggregate patient report using HL7 Quality Reporting Document Architecture (QRDA) is part of the roadmap but potentially out of scope for this Performance Quality Report Profile in 2009. Since QRDA is a draft standard for trial use (DSTU) in HL7, a profile may not be necessary for testing and such testing can occur in the US domain through the Healthcare Information Technology Standards Panel <HITSP>. HITSP expects to use a patient-level QRDA report (Category I). To be determined is the extent to which an aggregate report (Categories II and III) will be used. Note that QRDA includes schematron rules so that in such testing the completeness, terminology and structure of the QRDA can be validated before submission to an external performance monitoring organization.
  5. Successful final output is a fully specified measure set (3 of them) in electronic format that can be used by an EHR, an HIE, or some coordinator of clinical and administrative data. A statistical analysis step would help to validate that the calculated aggregate results are the same or better than the data currently submitted using manual processes.


Previous work (versions)

Related materials



Return to Quality, Research and Public Health Domain Main Page
Return to Quality, Research and Public Health Planning Committee
Return to Quality, Research and Public Health Technical Committee