1. 2015 Edition Certification NPRM Non API Group Report Out May 5, 2015 Architecture, Services, and APIs Arien Malec, co-chair David McCallie, co-chair

2. ASA Workgroup - Active Members 1 NameOrganization David McCallie, co-chairCerner Arien Malec, co-chairRelayHealth Clinical Solutions Janet CampbellEpic George ColeAllscripts Josh MandelChildren's Hospital Boston Jeff GuntherPremier, Inc. Gajen Sunthara, ex officioDepartment of Health and Human Services (HHS) Albert BonnemaDefense Health Agency Debbie Bucci, staff leadHHS, Office of the National Coordinator

3. Architecture, Services and Application Program Interfaces (APIs) Workplan 2 MeetingsTask April 9, 2014 12:00 – 1:30pm ET Overview of Certification NPRM and prepare to comment April 22, 2015 – HITSC meeting Interoperability Roadmap V.1 comments to the HITSC April 23, 2014 12:00 – 1:30pm ET API Group to Comment on Certification NPRM  May 5, 2014 4:00-5:00pm ET Non-API Group to Comment on Certification NPRM May 7, 2014 12:00 – 1:30pm ET HPD Group to Comment on Certification NPRM May 19, 2014 9:00 – 10:00am ET Finalize comments on Certification NPRM May 20, 2015 – HITSC Meeting Present Certification NPRM Comments to the HITSC

4. Architecture, Services & APIs Assignments 3 API Group - Workgroup Meeting, April 23Non API Group – Workgroup Meeting, May 7HPD Group - Workgroup Meeting, May 7 Homework due April 20 th Homework due May 5 th Homework due May 4 th VDT - Application Access to Common Clinical Data Set Application Access to Common Clinical Data Set XDM Package Processing Data Portability “Create” and Patient Matching Data Quality Healthcare Provider Directory – Query Request Healthcare Provider Directory – Query Response

5. XDM Package Processing 4 Comments: No comments received

6. § 170.315(b)(6) Data portability 4/27/20155 Comments: The purpose for Data Portability seems to have shifted from generating content to facilitate moving patient records from one system to another into something that is a hybrid of summary documents, messaging, and the original data portability stated purpose. While we might agree that having capabilities for user-focus, user driven, and configurability in general are beneficial, the mixture of triggers, data selections, etc. make for requirements that, again, may not at all represent what might be meaningfully useful in general practice. The requirements here are overly specific. We continue to question the mandate for C-CDA R2.0, a DSTU package with no track record, and for which we expect many, many, DSTU Comments as experience in the field shows where the implementation guide needs to be changed. We do not agree with the concept of mandating additional content above and beyond the Common Data Set or the C-CDA R1.1 (or R2.0) document type requirements. Let the implementation guides be the word on required content, and to not include additions in rules that are not apparent from the implementation guide

7. § 170.315(b)(6) Data portability 4/27/20156 General Requirements: “..A user must be able to set the following configuration options when using technology to create an export summary or set of export summaries for patients whose information is stored in the technology. A user must be able to execute these capabilities at any time the user chooses and without subsequent developer assistance to operate…” Would this allow for an organization to control this capacity via security, or is a developer expected to provide it to every user without the organization’s ability to suppress it? Is this capability expected for every user (schedulers, billers, clerks), or only EPs? 6-2-B Was the intent that any format other than the Unstructured Document could be used to meet the requirement, or is there an expectation that during certification the system would be asked to produce content using any, and perhaps all, of the structured document types of C-CDA 6-2-B-2 Where Cognitive Status is important to the care of a patient, we must rely on providers to determine the need for inclusion of this, or any other relevant content. 6-2-B-3 Where Functional Status is important to the care of a patient, we must rely on providers to determine the need for inclusion of this, or any other relevant content. R2.0? Expecting any site to have the capability to generate all of the mixed set of document types does not match business and practice use. 6-ii-C-iii: The timeframe should be defined more specifically to indicate how, if at all, it impacts the CCD, which typically contains all current patient-level data. 6-ii-C-iv: Event configuration seems unnecessarily specific. 6-ii-C-v: Is it expected that the developer can limit these locations to locations configured as safe to store PHI, as defined by the organization? Or should the user be able to, for example, save data to an unencrypted removable thumb drive? Why write a proposed rule that seems to indicate the use of file storage? Would need to be able to be configure and set the target to which the export summary or summaries are to be transmitted".

8. “Create” and Patient Matching Data Quality 7 Comments: Agree with this approach, especially about the clarification that the requirement is about the data as exchanged and not as captured, but suggest this matching criteria be extended to any data exchange and not just limited to CDA documents. We suggest that international standards be given additional consideration as many providers, patients and vendors are involved in health IT around the world.

9. Process for Responding Cert. NPRM Introduction Group Comments Develop Consensus Review Comments with HITSC 8 Cert. NPRM Overview Discuss process Review deadlines Members draft and submit comments to ONC staff by April 17th Prepare materials for assigned meeting reviews comments workgroup Workgroup refines draft recommend- ations Chairs brief HITSC April 9Offline workApril 23 May 7 May 20 HITSC Meeting