1. HITPC Meaningful Use Stage 3 RFC Comments March 1, 2013 Information Exchange Workgroup Micky Tripathi

2. Agenda Review IEWG 102, 103 and MU05 2

3. Tentative IE Workgroup Timeline DateTopic Friday, February 15th 2:00-3:00pm ETOverview of RFC comments Friday, February 22nd 2:00-3:30pm ETReview IEWG101 Friday, March 1st, 2:00-3:30pm ETIEWG 102, 103, MU05 Wednesday, March 13, 4:00-5:30pm ETIEWG 101 Tuesday, March 19 th, 12:30-2:00pm ETFinalize recommendations to HITPC on IEWG 101, 102, 103, MU05 Wednesday, April 3 rd, 10:00 am – 3:00pm ET HITPC Meeting - recommendations from workgroups 3

4. IEWG 102 Provider Directory 4 Stage 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 4

5. Discussion What if any changes does the Workgroup want to make based on comments. Key areas raised in the comments to consider: Standards readiness Others? 5

6. IEWG 103 Data portability 6 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 and includes, 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.

7. IEWG 103 Data portability 7 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

8. IEWG 103 Data portability 8 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.

9. Discussion What if any changes does the Workgroup want to make based on comments. Key areas raised in the comments to consider: Additional data elements requested Others? 9

10. MU05 10 RFC Question The HITECH ACT has given a lot of emphasis to EHRs as the central distribution channel for health information, but there may be limits on how much we can add on to EHR technologies. As additional program demands are added onto EHRs, what can be done to foster innovation to share information and receive intelligence from other, non-EHR applications and services that could be built on top of that data architecture? For example, Is it possible to create an application programming interface (API) to make available the information defined in a CCDA so that systems can communicate it with each other? Is the information defined in the CCDA the appropriate content for other uses of clinical information? Are the standards used to communicate between EHR systems (e.g. Direct, Exchange) adequate for communication between EHRs and other kinds of systems? What other technologies, standards or approaches could be implemented or defined to facilitate the sharing of clinical knowledge between EHRs and other systems? Comment Summary 78 comments There were many suggestions for what can be done to foster innovation. Key Points that were identified in the comments include: Implement standard interface specification to support integration for the EHRs and other systems Differing views on CCDA and Direct and Exchange ability to communicate between EHRs and other kinds of systems. Believe that publishing of healthcare APIs will speed the development of truly integrated systems

11. Discussion How would the Workgroup like to address the comments received? 11

12. Next Steps On the next call the WG will review IEWG 101 12