HITPC - Information Exchange Workgroup

Stage 3 Draft RecommendationsSeptember 5, 2012

Agenda

• Subgroup 1 Report Out• Subgroup 2 Report Out• Next Steps

2

Goals for today•Review Stage 3 MU recommendations developed by the subgroups and provide input for finalization next week.

3

Stage 3 Recommendations• The IE WG was asked to provide input to the MU Workgroup in nine key for

Meaningful Use Stage 3. The areas were broken up among two subgroups:

• Subgroup 1 – Quality and Efficiency– Electronic prescribing of controlled substances– Lab orders– Prior authorization– Medication history

• Subgroup 2 – Care Coordination and Patient and Family Engagement– Query for patient record– Notification of utilization event– Data portability – Specifying transition content– Exchange of electrocardiography

4

Recommendation Options• The Subgroup used a number of options for addressing these areas

including:– Stage 3– Certification only– Explore in RFC– Push to Stage 4 – No recommendation

5

IE Workgroup TimelineDate TopicIE WG Call - Wednesday , September 5th, 3:00-4:00pm ET

Review Subgroups recommendations

IE WG Call – Tuesday, September 11, 3:00-4:30 pm ET

Finalize recommendations

September 18th MU WG meeting

6

Subgroup 1: Quality and Efficiency Stage 3 MU Recommendations

Dave Goetz

7

Membership

• Chair: Dave Goetz• Members: Cris Ross, Chris Tashjian, Steve

Stack

8

Subgroups ApproachDate TopicWednesday, August 22nd 3:00-4:00 pm Goals and Objectives for stage 3

• Prior authorization

Wednesday, August 29th 3:00-4:00pm ET

Goals and Objectives for stage 3 • Prior authorization• Lab orders

Tuesday, September 4th, 12:30-1:30pm ET

Goals and Objectives for stage 3 • Medication history• Controlled substance e-rx

9

E-Rx of Controlled Substances Recommendation Language

• MU objective: Controlled substance prescriptions should count in the measure for e-prescribing for providers where allowed by state law. An exemption should be included for providers practicing in areas where there are no pharmacies supporting electronic prescribing of controlled substances.

• Certification criterion: The EHR system must be able to support the e-prescribing of controlled substances.

• This recommendation needs significant further exploration and may be more suitable for inclusion as a set of questions in the RFC then as a objective.

10

Lab Order Recommendation Language

• Certification Only for EPs: The EHR must have the ability to issue an electronic order of laboratory test within a providers workflow. The capability should be compatible with the Lab Order Interface and Lab Results Interface guidelines produced by the S&I Framework Initiative.

• Question for RFC: Are the existing standards for laboratory orders adequate to support including this certification criteria?

11

Prior Authorization Recommendation Language

1. The first order is to look to what might be required of EHRs that would facilitate prior authorizations, and then to look to providers to use where available. The certification requirements should build upon and hopefully reuse functionality that already exists or is being developed.

2. The goal is to reduce unwanted variation in quality and cost and to remove complexity and friction in the interaction between providers and payers in working towards that goal. The strategy is to identify the use cases where this interaction improvement could most readily take place.

3. The current interactions occur by fax, phone, web portal and EDI. It is generally acknowledged by both providers and payers that fax exchanges are the least efficient method of interaction, and a focus on reduction of faxes could reduce the level of frustration on both sides. The highest number of interactions currently would be phone calls, which are often time consuming and labor intensive for both payers and providers. Uses of electronic exchange could reduce the number of calls, but phone calls will always be necessary for interaction over the more complex procedures with the most variation around efficacy and appropriateness. Next would be payer portals where providers may both inquire as to eligibility and coverage issues and also submit clinical and other information necessary for the most efficient determination, receipt of approvals, filing appeals of adverse decisions. Last in current utilization is the transaction sets around EDI. Some payers currently use these X12 transactions, mostly with hospital systems. There are serious efforts underway, led by the AMA, to consider how to use this existing set of interactions between payers and providers to improve these interactions.

12

Prior Authorization Recommendation Language

4. Sub group 1 discussed these issues, and suggests that use cases for EHR certification can go from interaction with existing authorization systems through the transmission of clinical information for more complex decisions. We recommend that:

a.       Where available, EHRs should be able to automatically check and make available to Meaningful Users as part of the clinical workflow those methods of interacting with payers that are already in widespread usage. For example, for electronic prescribing, EHRs should be able to import formularies and medication histories, where available. Where payers have secure portals for the purpose of receiving prior authorization requests, EHRs should be able to allow Meaningful Users to sign into those portals as part of the clinical workflow without having to leave their EHR. Some payers currently have clinical questions on these portals, and clinicians can answer those to receive an automated approval. This functionality should be encouraged for those approvals where the clinical pathways are clear.

b.      Where this functionality exists in both EHRs and payer systems, providers should use this functionality in order to qualify as Meaningful Users, and payors should accept.

c.       As payers and providers work together to simplify and improve interactions around prior authorizations, they should be aware of how existing functionality in EHRs could be repurposed. For example, CCDA could provide the clinical information that payers would need in order to be able to more efficiently reach decisions with a minimum of repetitive or lengthy interactions. As noted above, there is work underway to see if other transaction sets can be repurposed or expanded to help automate routine transactions. 13

Prior Authorization Recommendation Language

Proposed Use Cases:

1. Medication formulary compliance v.1: prescriber electronically prescribes, EMR reconciles against relevant formulary, if formulary-compliant, prescription transmitted to pharmacy

2. Medication formulary compliance v.2: prescriber electronically prescribes, EMR reconciles against relevant formulary, if NOT formulary-compliant, prescription rejected, prescriber alerted to non-compliance, opportunity given via structured data prior-auth form to document medical necessity for non-formulary med, prior auth electronically and automatically granted in real-time if required prior auth requirements are fulfilled; this entire transaction could be done with structured data

3. Procedure/Surgery prior authorization v.A: for those procedures/surgeries with clear and objective prior authorization requirements and a structured data prior authorization form is available, clinician fill out the prior authorization form using structured data fields and prior authorization can be granted electronically and in real-time by the payor.

4. Procedure/Surgery prior authorization v.B: for those procedures/surgeries, for which prior authorization is non-standardized and is highly individualized, a standardized form is created that collects from the clinician text fields answering an agreed upon set of medical necessity questions, standardized form is sent electronically to insurer for review, insurer responds with Approval/Denial (with rationale if denied) using a standardized format text document back to clinician with either approval and/or denial with rationale.

A CCD (or comparable) could be appended to any of the above for added context if/when desired by either party.

14

Medication History

• MU WG recommendation

• The subgroup concurs with this recommendation

HITPC: MU Workgroup Stage 3 Recommendations 15

ID Stage 2 NPRM Stage 3 Recommendations Stage 4 Placeholder HITPC Comments

SGRP125

Placeholder for Stage 4

Placeholder for Stage 4 Medication reconciliation: create ability to accept data feed from PBM (Retrieve external medication fill history for medication adherence monitoring)

No changes suggested.

Subgroup 2: Care Coordination and Patient and Family Engagement

Stage 3 MU Recommendations

16

Membership

• Co-Chairs: Jeff Donnell and Larry Garber • Members: Peter DeVault, Jonah Frohlich,

Arien Malec

17

Subgroups ApproachDate TopicWednesday, August 22nd 1:00-2:00 pm Goals and Objectives for stage 3

• Query for patient record• Notification of utilization event• Data portability

Wednesday, August 29th 10:00-11:00am ET

Goals and Objectives for stage 3 • Specifying transition content

Tuesday, September 4th, 2:00-3:00pm ET

Goals and Objectives for stage 3 • Specifying transition content• Exchange of electrocardiography • Query provider directory

18

Collaborative Care Communication (New, Menu)Proposed Phase 3 IE WG MU Objective

EH OBJECTIVE: The EH/CAH will send electronic notification of a significant healthcare event in a timely manner to key members of the patient’s care team, such as the primary care provider, referring provider or care coordinator, with the patient’s consent if required.

EH MEASURE: The eligible hospital or CAH will send electronic notification within 2 hours of a patient’s arrival at an Emergency Department (ED), admission to a hospital, discharge from an ED or hospital, or death, to at least one key member of the patient’s care team, such as the primary care provider, referring provider or care coordinator, with the patient’s consent if required, more than 10 % of the time.

Corresponding certification criteria will also include the ability for all (EP and EH) certified EHRs to be able to receive these notifications.

Request for Comment for Meaningful Use with these additional questions:• Is the mere notification that the event has taken place sufficient, or is more detail needed at a minimum? For

instance should the ED Triage note be the minimum ED Arrival Notification? Should the patient discharge instructions with disposition be the minimum Facility Discharge Notification? Is the cause of death required at a minimum for the Death Notification?

• Are there sufficiently mature standards to define the content and vocabulary for these notifications? Will the Consolidated CDA satisfy these needs?

• Timeliness of notification must be balanced against the practical ability to produce these notifications, for example, in a busy ED. Is 2 hours a reasonable balance, or should it be shorter or longer?

• Should notification of more members of the patient’s care team be required? • Would a 50% threshold (instead of 10%) be too difficult to achieve?• What exemptions from the measure or exclusion from the denominator should be considered?

19

Query for Patient Information (EHR Certification Criteria) Proposed Phase 3 IE WG1. The EHR must be able to query another entity* for outside records and respond to such

queries. This query may consist of three transactions:• Patient query based on demographics and other available identifiers• Query for a document list based for an identified patient• Request a specific set of documents from the returned document list

*the outside entity may be another EHR system, a health information exchange, or an entity on the NwHIN, for example.

2. When receiving in inbound patient query, the EHR must be able to tell the querying system whether patient authorization is required to retrieve the patient’s records. (E.g. if authorization is already on file at the record-holding institution it may not be required).

3. The EHR must be able to query an outside entity for the authorization language to be presented to and signed by the patient or her proxy in order to retrieve the patient’s records. Upon the patient signing the form, the EHR must be able to either:• Send a copy of the signed form to the entity requesting it• Send an electronic notification attesting to the collection of the patient’s signature

Note: the authorization text may be located in a directory separate from the record-holding EHR system, and so a query for authorization language would need to be directable to the correct endpoint.

20

Query Provider Directory (EHR Certification Criteria) Proposed Phase 3 IE WG

1. The EHR must be able to query a Provider Directory external to the EHR to obtain entity-level addressing information (e.g. push or pull addresses).

21

Priorities supported by a provider directory query which facilitates Direct messaging and queries:

– Improved care coordination– Reduces readmission, redundant testing– Improves patient safety– Facilitates “hassle-free” health information exchange

Data Portability Between EHR Vendors - RFCRequest for Comment for EHR Certification:ONC’s HIT Policy Committee recognizes the importance of enabling healthcare providers to switch from using one EHR to another vendor’s EHR. It also recognizes that not all data can be migrated from one EHR to another. For instance, it is unreasonable to expect audit trails to be able to be imported from one EHR into another vendor’s EHR because EHR audit trails are so intimately tied to the EHR’s internal data structure and function. In the MU2 Certification Rule, ONC required at a minimum the capability to export C-CDA summaries on all patients which includes their most recent clinical information. It was recognized that this core clinical dataset was merely a first step towards the goal of seamless data portability. ONC also encouraged, although did not require, including historical laboratory test results, immunizations, and procedures.ONC’s HIT Policy Committee wishes to advance data portability further, and thus seeks comment to help identify reasonable actions that may further facilitate data portability.• What are the most important current and historical data elements that should be included in the

exported data? Should this included data that was saved in the EHR as an image or waveform?• What associated metadata should be exported to provide context to these historical data elements?• Should there be different standards for EP versus EH EHRs with regards to which data elements to

export and how far back historically to include?• ONC’s HIT Policy Committee recognizes that some data elements do not need to be transferred into

the new EHR but instead need to be archived and made available through some other non-EHR mechanism. What non-EHR mechanisms for storing, retrieving and displaying these archived data are available? Are there standards and services available to accomplish this?

• What are the risks and harms of requiring EHR vendors to provide data portability beyond C-CDA summaries?

• What are the risks and harms of not advancing the current state of data portability beyond C-CDA summaries?

22

Exchange of electrocardiograms - RFCRequest for Comment for EHR Certification:ONC’s HIT Policy Committee recognizes the importance of enabling healthcare providers to exchange electrocardiograms (EKGs). It also recognizes that there is limited experience with exchange of EKGs between healthcare providers.ONC’s HIT Policy Committee wishes to advance the exchange of EKGs between healthcare providers, and thus seeks comment to help identify reasonable actions that may promote this exchange.• How useful is the exchange of electrocardiograms (EKGs). What is the incremental value of exchanging

the actual image or waveform instead of just the textual EKG reading?• What technologies and standards are available for exchange of EKGs, and how mature are they? What

vendors support these standards and to what extent are they supported? Should EKGs be exchanged as waveforms or images and why?

• Are current EKG systems designed for sending and receiving EKGs? If yes, by what means and using which standards?

• Are current EHR systems designed for sending and receiving EKGs? If yes, by what means and using which standards?

• What examples of successful and unsuccessful exchange of EKGs are available?• What are the barriers to the exchange of EKGs? Are these barriers universal or unique to certain EKG

vendors?

23

Specifying Transition Content• Existing MU2 recommendation language for a

“Transition of care/referral summary”• CCD/C32 (for backward compatibility)• CCR (for backward compatibility)• Consolidated CDA (CCD, Discharge Summary, or

Consult Note)

• Problems:• C-CDA has no “Referral” document type• Nursing homes and home health agencies receive

these but these document types don’t meet their needs

24

Expanded Transfer of Care Dataset• Includes Collaborative Care Plan data elements• Transfer of Care Dataset: ~450 Data Elements• CCD: Only has ~175 Data Elements• Next steps:

November 2012 Preliminary Implementation Guide completedDecember 2012 Pilot full Transfer of Care Dataset in 16 facilitiesMarch 2013 Finish Implementation Guide in S&I FrameworkMay 2013 HL7 Balloting of Implementation Guide for inclusion in Consolidated CDA

25

Specifying transition contentSupport “Summary of Care Record” as defined in the MU WG’s MU3 Objective SGRP303, by providers optionally using 3 datasets (which include the Care Plan) being defined by S&I Longitudinal Coordination of Care WG and are expected to complete HL7 balloting for inclusion in the C-CDA by Summer 2013:1) Consultation Request (Referral to a consultant or the ED) 2) Shared Care Encounter Summary (Consultation Summary, Return from the ED to the referring facility, Office Visit)3) Transfer of Care (Permanent or long-term transfer to a different facility, different care team, or Home Health Agency)

26

Next Steps

• Based on IE WG input recommendations will be revised for review next week.

27