1. 2015 Edition Certification NPRM - API April 23, 2015 Architecture, Services, and APIs Arien Malec, co-chair David McCallie, co-chair

2. Membership 1 MemberOrganization Arien Malec, co-chair RelayHealth Clinical Solutions David McCallie, co-chair Cerner Corporation Janet Campell Epic George Cole Allscripts Jeff Gunther Premier, Inc. Josh Mandel Children's Hospital Boston Albert Bonnema, ex-officio Defense Health Agency Gajen Sunthara, ex-officio Department of Health and Human Services David Waltman, ex-officio The Department of Veterans Affairs

3. Architecture, Services, and APIs NPRM Workplan MeetingsTask April 9, 2015 12:00 PM ET Certification NPRM Introduction Process for commenting on NPRM April 23, 2015 2:00 PM ET Review comments from group working towards consensus May 7, 2015 2:00 PM ET Review comments from group working towards consensus May 20, 2015 HITSC Meeting Certification NPRM Comments 2

4. App Access to Common Clinical Data Set (I) FHIR is not ready to become a certification criterion. Instead we recommend an optional criterion explicitly tied to FHIR DSTU 2. ONC should support the request for a document, because it is the next logical and incremental step from ToC and Download/Transmit and is more countable. Data request and return formats are overly prescriptive for a set of functional API requirements. – Do not specify “requests for each of the individual data categories” as a hard requirement; this would preclude innovative approaches like Facebook's Graph API or a semantic web-based SPARQL interface where applications can query for various dynamically-defined subsets of data. – Language like “the full set of data in that category” is also unnecessarily restrictive: this may prevents APIs from retrieving a relevant subset of data. Example “Get all serum glucose readings and return as an array of float values, where the units are mg/dL”. The “data categories request” language could be more generic example: The API must support discrete queries that allow client applications to search for relevant subsets of a patient's data based on some reasonable and useful query mechanism 3

5. Many vendors offer proprietary APIs that may fulfill the specifics of the proposed data retrieval requirements but the very nature of the proprietary implementations presents interoperable problems. Concerns re: respond in either XML or JSON”. – May exclude ability to wrap an HL7v2 payload or prohibit a whole class of innovative APIs that return formats such as semantic web data in the Turtle RDF syntax, low-bandwidth APIs that return structured data using highly efficient Protocol Buffers. – Conflicting message – either leave the implementation to the developer or to specifically constrain the implementation to the standard(s) ONC is trying to encourage – The requirement “in either XML or JSON” should explicitly indicate that the API is only required to return either XML or JSON, not both Patient selection: it's unclear why this should be an API requirement. Certainly an app needs to be authorized to access patient data, but it is probably an anti-pattern to have an API function like “haveUserSelectAPatientAndReturnTheId()”. Rather, a common pattern would be to engage in an OAuth authorization process during which the end-user signs in, sees a request for access, and approves or denies access. In this process, patient selection is a byproduct of the authorization flow. It's not wrong to call it out as in (ii), but it may be misleading to think of it as written in the NPRM. 4 App Access to Common Clinical Data Set (II)

6. Test procedure steps indicate that the proposal is about one system, one API, and multiple types or categories of query requests thru “the API”. However, the wording of the proposal, pg. 207, leaves this a bit more open to interpretation For example, an XCA Responding Gateway could fulfill the “all” requirement, with some other system providing the support for testing and certifying to the patient selection and data category request queries. Regarding documentation, it should be clarified that the documentation must be publicly available for free to developers, and that no NDA should be required to view it. Documentation should also include examples of requests and responses. And documentation should include a reference to some kind of sandbox or testing environment where application developers can actually try these APIs to see if they work. Current mandated response to the “all” data category request is a C-CDA R2.0 document. We suggest the floor/minimum be a C-CDA R1.1 or a FHIR Composition resource. 5 App Access to Common Clinical Data Set (III)

7. The idea of a “Common Clinical Data Set” is a very good one. But the definitions are not as clear as they should be. It would be very helpful to lay out the common clinical data set in a single place, rather than referring to and amending previous definitions. For example, someone reading the final rule should be able to answer questions like “When ONC says that RxNorm-coded medications are required in the common data set, what details does this include? Does it include the date on which a prescription was written? The reason for the prescription? Structured information about how often to take the drug, and how much to take, and when? Information about who prescribed it?” – and so on. There are dozens of things that one could say about a medication, and it's unclear how many of these things are part of the Common Clinical Data Set. Many C-CDA documents from 2014-certified EHRs that provide little information beyond an RxNorm code for each medication – effectively just a bag of codes. 6 App Access to Common Clinical Data Set (IV)

8. VDT – App Access to Common Clinical Data Set (I) Patient-facing API access is a valuable capability separate from clinician-facing access; the NPRM rightfully calls this out as its own certification criterion. It absolutely makes sense to allow vendors to document their APIs in a single place, and to provide a single set of developer documentation. The particular example provided is not necessarily realistic or illuminating: (e.g., a RESTful web service for § 170.315(e)(1) versus a SOAP web service for § 170.315(g)(7)). A more realistic example might be “e.g. a service that requires end-user authorization for patient- facing access, versus a service that allows direct server-to-server access for provider-facing access”. Certification criterion says that Terms of Use should be provided, but the Terms of Use would likely be created by the covered entity, wouldn’t they? In addition to return either XML or JSON, we recommend explicitly stating the need to provide the patient with human readable content. Is it appropriate for the EHR developer to assume that the third-party application has signed an agreement or terms of use with the EP or EH? Would requiring a pre-existing agreement for access to the data be considered “information blocking” on the part of the organization? 7

9. VDT – App Access to Common Clinical Data Set (II) The Common Clinical Data Set alone may not be enough to replace VDT-type portal functions. For example, does the Common Clinical Data Set include arbitrary documents about patients? These would include referral summary documents that are generated in the course of a referral workflow would have been available in a patient's portal through VDT. Will these referral summary documents also be made available through the API? If the API is to serve as a useful replacement for a patient portal, it must include the same content that the portal would expose – including, critically, clinician-authored referral and discharge summary documents Unlikely that the EHR-API would be the same as the VDT-API – Different requirements around authentication and authorization – VDT-API has different requirements for the data it shows: it needs to return data filtered for the patient’s view (at the decision of the organization). – Management of access by a designated representative includes even more complexity, because of state requirements over what, for example, a parent might be able to view about their child. As a result, the data source needs to know not only which patient is data being requested for but also which human is doing the requesting 8

10. In re: to the following “ …propose for this criterion to require ONC-ACBs to submit a hyperlink... that would allow any interested party to access the API's documentation and terms of use…It would help to clarify that the link must be to a public web page where anyone can read the API documentation without cost and without agreeing to non-disclosure terms. It would also help to clarify that the documentation should include examples of API requests and responses. To say this more concretely, the following language should be clarified : “… With respect to testing for this certification criterion, we expect that functional testing would focus primarily on the third capability we propose. Meaning that for each function call made the health IT developer would need to demonstrate to/show an Accredited Testing Lab the response (i.e., output) for each of the data category requests..” to indicate that these output should be provided not only to the testing lab, but to the public as well. Regarding security, it is unclear what the meaning of “including a means for the requesting application to register with the data source” means, exactly. Is this describing a dynamic registration process? If a dynamic registration process is implied, does this mean free and open dynamic registration for any application? If not, what people or organizations are responsible for making the final decision about whether a particular patient-facing app is approved? If a patient says “I want to use App X to access my data,” can the provider, or the EHR vendor, say “No, we choose not to allow App X to talk to our system”? To put it another way: will this API requirement support a patient's “right to access”? 9 VDT – App Access to Common Clinical Data Set (III)

11. VDT – App Access to Common Clinical Data Set (IV) What if the developer uses a standard for the API that is documented elsewhere? To what extent must the developer-provided documentation duplicate documentation around syntax, function names, required parameter, return variables, etc? 10