Steve Posnack, ONC

1. Privacy, Security, and Accessible Health Data through APIs Steve Posnack, ONC

2. About ONC • The Office of the National Coordinator for Health Information Technology • Sits within US Department of Health and Human Services • Created in 2004 under an Executive Order by President Bush • Codified in law in 2009 as part of the American Recovery and Reinvestment Act (“Recovery Act”) • Substantial new authority as a result of the 21st Century Cures Act (2016)

3. How’d we get here?Timing is Everything Microsoft HealthVault Ends FHIR Release 1 Microsoft HealthVault DEA EPCS Rule & Direct Project Google Health Ends Last Telegram* MACRA “MIPS” FHIR Release 4 Google Health 2008 2009 2010 2015 2016 2019 2007 2018 2014 2012 2006 Argonaut Project HITECH Act 21st Century Cures Act ONC Cures NPRM Apple Health Records App iOS11.3 iPhone Released MU Stage 2 2014 Edition MU Stage 3 2015 Edition MU Stage 1 2011 Edition ACA Still Faxing  • Citation: Siegel, Robert. “Western Union Sends Its Last Telegram.” NPR, NPR, 3 Feb. 2006, www.npr.org/templates/story/story.php?storyId=5186113.

4. FHIR Implementation Nationwide • Of the hospitals and Merit-based Incentive Payment System (MIPS) eligible clinicians that use certified products, we found that almost: • 87% of hospitals • 69% of MIPS eligible clinicians • are served by health IT developers with product(s) certified to any FHIR version. https://www.healthit.gov/buzz-blog/interoperability/heat-wave-the-u-s-is-poised-to-catch-fhir-in-2019

5. Broader Privacy & Security Context • 2016 Report • Examining Oversight of the Privacy & Security of Health Data Collected by Entities Not Regulated by HIPAA • https://www.healthit.gov/sites/default/files/non-covered_entities_report_june_17_2016.pdf • 2019 HIMSS Cybersecurity survey • While respondents in the present study report a myriad of cybersecurity threats and experiences, there is a pattern that is discernable; significant security incidents are a near universal experience in US healthcare organizations with many of the incidents initiated by bad actors, leveraging e-mail as a means to compromise the integrity of their targets. • https://www.himss.org/sites/himssorg/files/u132196/2019_HIMSS_Cybersecurity_Survey_Final_Report.pdf • Health Information Sharing and Analysis Center (H-ISAC) • https://h-isac.org/

6. Title IV of the 21st Century Cures Act Sec. 4001. Assisting doctors and hospitals in improving quality of care for patients. Sec. 4002. Transparent reporting on usability, security, and functionality. Sec. 4003. Interoperability. Sec. 4004. Information blocking. Sec. 4005. Leveraging electronic health records to improve patient care. Sec. 4006. Empowering patients and improving patient access to their electronic health information.

7. Two Statutory Sections Implemented Together45 CFR Part 170.4xx and Part 171.2xx Conditions of Certification • 170.401 Information blocking • 170.402 Assurances • 170.403 Communications • 170.404 APIs (without special effort) • 170.405 Real world testing • 170.406 Attestations • 170.40x EHR Reporting Program Information Blocking Exceptions • 171.201 Preventing harm • 171.202 Promoting the privacy of electronic health information • 171.203 Promoting the security of electronic health information • 171.204 Recovering costs reasonably incurred • 171.205 Responding to requests that are infeasible • 171.206 Licensing of interoperability elements on reasonable and non-discriminatory terms • 171.207 Maintaining and improving health IT performance

8. The Really Big PictureScope and Applicability • Applies to certified health IT developers, health information exchanges, health information networks, & health care providers • Electronic health information is expected to be accessible, exchangeable, & useable unless an “interference” is required by law or covered by an exception(s) • An action(s) covered by an exception(s) would not be subject to penalties or disincentives Information Blocking Proprietary APIs Contracts Business Practices Interfaces Conditions of Certification Technical Info • Applies only to health IT developers • Also include maintenance of certification requirements Services Licenses & Rights Certification Criteria • Specify the technical requirements that software products presented for certification need to meet. Etc.

9. Securing API Access 101With a focus on 3rd Party Apps & Patient Access How? What? 3rd Party App Many Possible Apps (programmatic access) “Tethered-Portal” The Only App (typically web application) Security Step Not Applicable (1-to-1 connection between portal and web server) Each app must be registered and receives a unique Client ID and Client Secret* App Registration HTTPS with TLS (https://fhir.drXYZ.com) App connects to the FHIR Server and the patient’s visual experience is handled by app HTTPS with TLS (https://portal.drXYZ.com) A patient’s visual experience is directly with the portal based on server responses Secure Connection App is redirected for patient authentication Patient enters credentials issued by Dr. XYZ App *never* sees/gets access to patient credentials Patient directly enters the credentials issued by Dr. XYZ into their portal User Authentication Dr. XYZ’s FHIR Server does not need to “trust” the App. Access to data is authorized by the patient After patient authorization, app gets time-limited “access token” All actions are trusted completely by web server (all data accessible to patient via portal) App Authorization Key points • Today, health information is made accessible to web applications over the internet via web servers. • What “tethered-portals” and 3rd party apps do programmatically to securely connect to HTTPS-based web servers is very similar. • The same information security steps used by the Health Insurance Portability and Accountability Act (HIPAA) Covered Entities for tethered-portals can be/are being used for 3rd party apps.

10. HHS Office for Civil Rights (OCR)HIPAA Privacy FAQs on Patient Access Go here: https://www.hhs.gov/hipaa/for-professionals/faq/health-information-technology/index.html#access-right,-apps-and-apis

11. FHIR Server Testing https://inferno.healthit.gov/inferno/

12. The US Core Data For Interoperability (USCDI v1)(proposed) Assessment and Plan of Treatment • Medications • Medications • Medication Allergies • Vital Signs • Diastolic BP • Systolic BP • Body height • Body weight • Heart Rate • Respiratory Rate • Body temperature • Pulse oximetry • Inhaled oxygen concentration • BMI percentile per age and sex for youth 2-20 • Weights for age per length and sex • Occipital-frontal circumference for children < 3 years old Problems Care Team Members Procedures • Patient Demographics • First Name • Last Name • Previous Name • Middle Name (incl. middle initial) • Suffix • Birth Sex • Date of Birth • Race • Ethnicity • Preferred Language • Address • Phone Number • Clinical Notes • Consultation Note • Discharge Summary Note • History & Physical • Imaging Narrative • Laboratory Report Narrative • Pathology Report Narrative • Procedure Note • Progress Note • Provenance • Author • Author Time Stamp • Author Organization Smoking Status Unique Device Identifier(s) for a Patient’s Implantable Device(s) • Goals • Patient Goals Health Concerns • Laboratory • Tests • Values/Results Immunizations https://www.healthit.gov/sites/default/files/nprm/ONCCuresNPRMUSCDI.pdf

13. API Conditions and Maintenance of Certification High-level Overview Cures Act Condition An API Technology Supplier must publish APIs and must allow health information from such technology to be accessed, exchanged, and used without special effort through the use of APIs or successor technology or standards, as provided for under applicable law, including providing access to all data elements of a patient’s electronic health record to the extent permissible under applicable privacy laws. Transparency Permitted Fees Openness and Pro-competitive • Publicly accessible documentation • Terms and conditions • Fees and structure • App developer verification process • Only specific types of fees are permitted • Must have objective and verifiable criteria • Three categories of permitted fees • Must keep detailed records for fees • Must grant API Data Providers sole authority • Terms must be non-discriminatory • All necessary “rights” must be provided • Must maintain service and support levels Maintenance of Certification • An API Technology Supplier must register and enable apps for production use within one business day of completing its verification of an app developer’s authenticity • An API Technology Supplier must support the publication of Service Base URLs (i.e., FHIR API endpoints) for all of its customers and make such information publicly available (in a computable format) at no charge • An API Technology Supplier with API technology previously certified to § 170.315(g)(8) must provide all API Data Providers with a (g)(10)-certified API within 24 months of a final rule’s effective date

14. The API Conditions of Certification & Information Blocking Healthcare Provider API Data Provider Information Blocking Information Blocking API Conditions of Certification e.g., App Developer Health IT Developer API Tech Supplier API User API Conditions of Certification Information Blocking

15. Ways to Engage • Health IT Feedback • https://www.healthit.gov/healthit-feedback • Interoperability Standards Advisory • https://www.healthit.gov/isa/ • Guide to Getting & Using Your Health Records • https://www.healthit.gov/how-to-get-your-health-record/ • Interoperability Proving Ground • https://www.healthit.gov/techlab/ipg/ • Certified Health IT Product List • https://chpl.healthit.gov/

16. Thanks & Questions