HITPC Meaningful Use Stage 3 RFC Comments

May 23, 2013

Information Exchange Workgroup

Micky Tripathi

2

Agenda

• Review MU WG Pathways for Meaningful Use Stage 3

• Consolidation Discussion• IEWG101

3

Meaningful Use Workgroup Pathways for Meaningful Use Stage 3

Proposed IE Workgroup TimelineDate TopicThursday, May 23rd, 10:00-11:00 am ET MU WG update, IEWG 101

Thursday, June 6, 3:30-4:30 pm ET IEWG 101, 102

Friday, June 21st, 10:00-11:00 am ET IEWG 103, finalize all recommendations

Tuesday, July 9rd, 9:30 am – 3:00 pm ET HITPC Meeting - recommendations from workgroups

4

Consolidation

• Are there any IEWG items that should be consideration for consolidation?

Query for Patient Record (IEWG101)

Provider Directory (IEWG102) (certification only)

Data Portability (IEWG103) (certification only)

5

Stage 3 RecommendationMENU objective: For patients transitioned without a care summary, an individual in the practice should query an outside entity. The intent of this objective is to recognize providers who are proactively querying.Certification criteria: The EHR must be able to query another entity for outside records and respond to such queries. The outside entity may be another EHR system, a health information exchange, or an entity on the NwHIN Exchange, for example. This query may consist of three transactions:

a) Patient query based on demographics and other available identifiers, as well as the requestor and purpose of request.

b) Query for a document list based for an identified patient c) Request a specific set of documents from the returned document list

When receiving inbound patient query, the EHR must be able to: d) Tell the querying system whether patient authorization is required to retrieve the patient’s records and

where to obtain the authorization language*. (E.g. if authorization is already on file at the record-holding institution it may not be required).

e) At the direction of the record-holding institution, respond with a list of the patient’s releasable documents based on patient’s authorization

f) At the direction of the record-holding institution, release specific documents with patient’s authorization

The EHR initiating the query 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 send, based on the preference of the record-holding institution, either:

1. a copy of the signed form to the entity requesting it 2. an electronic notification attesting to the collection of the patient’s signature

*Note: The authorization text may come from the record-holding EHR system, or, at the direction of the patient or the record-holding EHR, could 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.

IEWG 101 Query for Patient Record

6

Stage 3 RecommendationMENU objective: For patients transitioned without a care summary, an individual in the practice should query an outside entity. The intent of this objective is to recognize providers who are proactively querying.Certification criteria: The EHR must be able to query another entity for outside records and respond to such queries. The outside entity may be another EHR system, a health information exchange, or an entity on the NwHIN Exchange, for example. This query may consist of three transactions:

a) Patient query based on demographics and other available identifiers, as well as the requestor and purpose of request.

b) Query for a document list based for an identified patient c) Request a specific set of documents from the returned document list

When receiving inbound patient query, the EHR must be able to: d) Tell the querying system whether patient authorization is required to retrieve the patient’s records and

where to obtain the authorization language*. (E.g. if authorization is already on file at the record-holding institution it may not be required).

e) At the direction of the record-holding institution, respond with a list of the patient’s releasable documents based on patient’s authorization

f) At the direction of the record-holding institution, release specific documents with patient’s authorization

The EHR initiating the query 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 send, based on the preference of the record-holding institution, either:

1. a copy of the signed form to the entity requesting it 2. an electronic notification attesting to the collection of the patient’s signature

*Note: The authorization text may come from the record-holding EHR system, or, at the direction of the patient or the record-holding EHR, could 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.

IEWG 101 Query for Patient Record

7

8

HITSC Response to IEWG101• The workflow required here is a labor-intensive, paper-based workflow that barely works in a paper-based

environment. I don’t think it’s reasonable to attempt to replicate this workflow electronically. The EHR receiving the query should mediate the request and then tell the querying system what documents are available to them. The receiving system should then protect those documents i.a.w. its own policy and the patient's preferences. We need to think through how this should happen in an electronically connected world -- not how to replicate a paper workflow electronically. For increased convenience, reduced complexity, and easier comprehension, I suggest a measure that enables a provider to obtain a patient's privacy preferences from another provider or third party service. This would enable a patient to register her preferences once, and then simply provide a pointer to those preferences for subsequent encounters with other providers. A number of providers and HIEs already are implementing such a service, making the need to specify a standard service interface (e.g., RHex) and coding more urgent.

• Unfortunately no universal patient health identifier exists, and the lack of a reliable means of identifying patients is broadly viewed as a significant challenge to care quality. The proposed model involving the use of demographics to identify patients is not sufficiently reliable to support query for individual patients’ information. Multiple efforts currently under way are addressing the challenges around “directed query” (i.e., query for a specific patient’s information) through the use of a voluntary identifier, and we think it is important that regulations allow progress to continue to be made in this area. Lacking standards to support either the positive and unequivocal identification of patients or query for a specific patient’s information, we urge the ONC not to include in regulation a detailed description of how directed query is performed. Policy and standards around trustworthy identity proofing and authentication are rapidly evolving, and should provide a strong foundation for trusted query. We encourage the ONC to continue to support the development of new models for using voluntary or other high-quality identifiers and authentication methods.

IEWG 101 Query for Patient Record

9

Summary

•102 comments

• Many commenters expressed support for the inclusion of this objective in Stage 3.

• A number of commenters stated that HIE/HIOs should be able to support providers in achieving this objective.

• Quite a few commenters seemed confused about the focus and scope of this objective.

Many seemed to think it was focused on requiring providers to utilize a HIO. Some commenters requested clarification on if the proposed functionality is for peer-to-peer exchange driven by EHRs or is it focused on HIO?

• Some commenters expressed concerns that many providers do not practice in an area

covered by a fully functional HIO/HIE entity which could provide this type of service. These commenters recommended that before such an objective be included that ubiquitous access to and use of these types of queries be in place. Some commeters were concerned that this requirement required the EP or EH to be held accountable for processes outside of their control. A few commenters also expressed the need to ensure sufficient provider directories existed before this type of requirement goes into effect.

Summary

Quite a few commenters raised questions around the privacy and security aspects of this objective. • Some requested additional information on what would be required to be included in the

standard authorization? Would it include content beyond the HIPAA requirements for a valid authorization?

• Some were concerned that the standards for patient authorization/consent management would not be ready into for inclusion of this objective in Stage 3. Other felt the standards could be ready in time if HHS made a significant dedicated push in this area.

• Some stated that non-prescriptive requirements will need to be put in place for establishing a trusted query.

• A few asked for definition of what consitiutes ‘a list of patient’s releasable documents.’• A few asked if this objective could raise concerns about possible accidental disclosures of

patient information from unforeseen technical issues.• A few raised concerns that the association of an individual with a particular covered entity is

considered PHI and that receiving such a confirmation before receiving an authorization would be a disclosure of PHI.

• Some said a privacy and security framework would need to be established to ensure tight controls that prevent abuse.

A few commenters recommend that certification include the requirement that when sensitive or confidential information, such as information covered by 42 CFR Part 2, is shared, the system must ensure that a Non Redisclosure Notice is provided to the receiving institution, that the receiving EHRs be capable of recognizing and processing this notice and also be restricted from redisclosing the information without specific consent.

IEWG 101 Query for Patient Record

10

IEWG 101 Query for Patient Record

11

• Summary

• A few commenters noted it might be advisable to break this requirement into two separate certification criteria, one for sending queries and one for responding to queries to allow modular technology deployments to address the requirements.

• There was a sprinkling of comment in regards to the standards readiness to support this objective:•A few commenters state that existing IHE profiles (XCA, XDS-b, XCPD, PIX, BPPC) could support the query requirements. •A number of commenters felt this was an important objective but questioned if the standards and required infrastructure would be ready in time for its inclusion in Stage 3. •A few thought the Direct Protocal was well suited to this objective. •A few commenters recommended the criterion focus on web services approaches for query rather than only on IHE XDS-like workflows and clinical documents.

• A few commenters noted they could meet this objective today with other providers on the same EHR but not those using another vendors EHRs. They also mentioned that for providers in communities that are dominated by a single EHR vendor it could be difficult to achieve a requirement of querying a different vendor’s EHR system. • A couple of commenters expressed concern that this approach of allowing EHRs to query one another is not feasible and would make it difficult to search for data cross patients. • A few commenters asked about the allowable timeframe for response to inbound patient queries? • A couple of commenters felt the goals this objective were already meet through the ToC objective. • A few commenters requested that public health registries be added as an example of potential outside entities to be queried

11

IEWG 101 Query for Patient Record Measure

12

Summary

Should the measure for this MENU objective be for a number of patients (e.g.25 patients were queried) or a percentage (10% of patients are queried)? What is the best way to identify patients when querying for their information?

•The majority of those who commented on the measure suggested it should be based on percentage. •A few commenters requested additional detail be provided about the measure.

• How is a query that failed counted?• How is outside entity defined?

•A couple of commenters recommended that this measure be considered in tandem with the Receipt Acknowledgement measure (SGRP305), and that queries only be counted towards the numerator if they are completed successfully or if a failed query is reported to a patient safety organization or ONC-ATB.

Discussion - IEWG101

• During previous meetings the Workgroup discussed reducing the specificity of the workflow identified in the objective.

• What if any changes does the Workgroup want to make based on comments?

13

14

Background

15

IEWG 102 Provider DirectoryStage 3 Recommendation

Certification criteria: 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).

Comment Summary

•62 comments•Most commenters agreed that there are not sufficiently mature standards in place to support this criteria at this time. •Comments were fairly evenly split on if the criterion should be kept in Stage 3.•S&I Framework, attempts were made to find simpler approached, e.g., web mark-up. There was support for the work completed through S&I but that the initiative lost momentum. •Currently, only closed provider directories are available, each with its own application programming interface (API), with no mechanism or set of standards to support broader access. Keeping provider directories up-to-date is difficult. • If a provider is participating in an HIE/HIO, and this HIE/HIO usually serves this function for the provider, then the provider should receive credit for MU for their participation in an HIE/HIO that meets this objective

15

16

IEWG 103 Data portability

RFC Question

What criteria should be added to the next phase of EHR Certification to further facilitate healthcare providers’ ability to switch from using one EHR to another vendor’s EHR?

Stage 2 Certification Criterion: Enable a user to electronically create a set of export summaries for all patients in EHR technology formatted according to the standard adopted at § 170.205(a)(3) that represents the most current clinical information about each patient andincludes, at a minimum, the Common MU Data Set and the following data expressed, where applicable, according to the specified standard(s):(i) Encounter diagnoses. The standard specified in § 170.207(i) or, at a minimum, the version of the standard at § 170.207(a)(3);(ii) Immunizations. The standard specified in § 170.207(e)(2);(iii) Cognitive status;(iv) Functional status; and(v) Ambulatory setting only. The reason for referral; and referring or transitioning provider’s name and office contact information.(vi) Inpatient setting only. Discharge instructions.

Comment Summary

•56 comments•The majority of commenters felt this criterion was important and that further progress needed to be achieved around data portability. •A number of commenters felt this criterion was unnecessary or duplicative of other criteria.•A few commenters questioned if this criterion would add significant value as substantially more data would need to be migrated to maintain continuity.

IEWG 103 Data portability

17

Comment Summary

•Commenters suggested a number of new data types that should be added:• Many commenters suggested new data elements included in Stage 3 should be added to this criterion • Many said any historical data that is required to calculate the Stage 3 CQMs• In future stages this requirement should be changed to include any additions to objectives and CQMs. • Other structured data where possible and document export as readily viewable documents where

structured data is not available. • All currently accepted elements of the CCD formatted according to the standard. • Patient notes• Allergies• Past medical history• Nutrition/diet orders• Family/social history data (fluoride status of home water, second hand smoke exposure, alcohol use, drug

use, cessation counseling, etc.) • Non lab screening data (depression screen (PHQ9), asthma screen, hearing screen, autism screen, vision ‐

screen, etc.)• Free text narrative• Consent• History of present illness• Review of systems documentation• Physical examination documentation• Progress notes• Signed notes• Consultations• Provider data

18

IEWG 103 Data portability

Comment Summary

•Two commenters expressed a specific concern that the CCDA could not adequately provide/represent the information a provider needs to switch from one EHR to another. One felt that HL7 Quality Reporting Document Architecture (QRDA) category 1 might be better able to populate a patient record for historical quality measurement needs. While the other thought significant work would be required to support this functionality this criterion aims for.

•A few commenters questioned if this criteria could wait for a future Stage of meaningful use. One commeter requested this criterion be removed from Stage 3.

•One commenter felt the criterion should require certified EHRs to be able to export data based on either number of encounters of by a specified time period. Another commenter requested the ability to transfer by diagnosis.

•One commeter raised the point that in the long-term EHRs may not be viewed as the central repository for a patient’s entire medical record as this function might be assigned elsewhere.

•A few commenters felt more work was needed to ensure EHRs are able to import this data when a provider switches systems.