FHIR at Scale (FAST): Scalable Registration, Authentication, and Authorization for FHIR Ecosystem Participants PSS

1a. Project Name FHIR at Scale (FAST): Scalable Registration, Authentication, and Authorization for FHIR Ecosystem Participants 1b. Project ID 1689 1c. Is Your Project an Investigative Project (aka PSS-Lite)? No 1d. Is your Project Artifact being Reaffirmed or proceeding to Normative directly after being either Informative or STU? No 1e. Today's Date 1f. Name of standard being reaffirmed 1g. Project Artifact Information 1h. ISO/IEC Standard to Adopt 1i. Does the standard include excerpted text from one or more ISO, IEC or ISO/IEC standards, but is not an identical or modified adoption? 1j. Unit of Measure 2a. Primary/Sponsor WG Security 2d. Project Facilitator Luis Maas and Brett Stringham 2e. Other Interested Parties (and roles) 2f. Modeling Facilitator 2g. Publishing Facilitator 2h. Vocabulary Facilitator 2i. Domain Expert Representative Luis Maas, Brett Stringham 2j. Business Requirements Analyst Paul Oates, Patrick Murta, Aaron Seib 2k. Conformance Facilitator TBD 2l. Other Facilitators 2m. Implementers Humana, Cigna 3a. Project Scope The aim of this project is to expand upon the existing work by UDAP.org within the HL7 consensus process to produce a more complete set of implementation guides targeted at implementers of both client and server systems using FHIR for data exchange, standardizing how implementers integrate the UDAP profiles identified by the FAST Security Tiger Team into existing OAuth 2.0 and OpenID Connect workflows. Among other things, the deliverables of this project would provide the FHIR community with detailed instructions to implement the following: - integration of existing public key infrastructure mechanisms with registration, authentication, and authorization processes to establish robust trust networks with reusable credentials to identify actors - trusted dynamic client registration - client app submissions of self-assertions, third party certifications, or other endorsements to servers, and vice-versa - client app assertions of additional information for a given session so that resource holders can more finely scope access tokens, including information related to consent or purpose of use - increase security and assurance in identity of all actors by using asymmetric cryptographic methods for authentication, including specific protocols to support network-wide revocation of credentials - dynamic federation of user credentials to facilitate reuse of credentials and single sign-on This initiative is being sponsored by the US government and particpants involved have been from the US. Therefore the scope of this project is specific to the US Realm. For additional information: https://oncprojectracking.healthit.gov/wiki/download/attachments/118849815/FAST-PS-Security-v3draft-SEP8-2020.docx?version=1&modificationDate=1608220408000&api=v2 Attachments 3b. Project Need As the FHIR ecosystem grows and the number of deployed servers and clients multiplies, several aspects of the registration, authentication, and authorization processes that occur before the exchange of FHIR resources can take place have been identified as potential bottlenecks. To facilitate the effective scaling of the ecosystem, automated approaches for application registration and more robust mechanisms to reliably identify participants and manage credentials are needed. For larger ecosystems with numerous requestors and responders, a distributed system of authoritative information can be leveraged using digital certificates to enable a scalable dynamic solution for client (i.e., FHIR client / requestor) registration. The registration problem alone is exemplified by statistics shared from a scenario analysis that considered manual registration of 60 current BlueButton API clients across 907 US Health Plans. Extrapolating from the CMS experience, the time required by human facilitated administrative activities at the Health Plans to register 60 applications (e.g., review meetings, actual generation & sharing of API credentials with app developer, etc.) was estimated at 73 person-years (Seib A & Scrimshire M, “Making it easier for Patients and Data Holders”, EHNAC AHIP Webinar, 2020). This estimate only addresses one type of registration interaction (payer/consumer), with additional registration effort required for all provider/consumer, provider/provider, provider/payer, and payer/payer pairings. The Healthcare dollars expended in non-value, manual related client registration activities can be recaptured many times over as this solution is adopted across the FHIR API ecosystem nationwide. The ONC FHIR at Scale Taskforce’s Security Tiger Team was formed in late 2018 to investigate these issues and identify potential solutions. The Tiger Team identified the Unified Data Access Profiles (UDAP) for Dynamic client registration, client authentication, client authorization, and Tiered OAuth as building blocks to be used by implementers to address the issues above and enhance the overall scalability of the FHIR ecosystem, a recommendation that has received positive feedback from numerous cybersecurity subject matter experts. 3c. Security Risk No 3d. External Drivers 3e. Objectives/Deliverables and Target Dates Ballot for STU1 Sept 2021 Reconciliation for STU1 – Sept - Dec 2021 Publication STU1 – Jan 2022 Ballot for STU2 – Jan 2023 Ballot Reconciliation – Jan – April 2023 Publication – May 2023 Ballot for Normative – Jan 2025 Ballot Reconciliation – Jan-April 2025 Publish Normative – May 2025 3f. Common Names / Keywords / Aliases: Keywords: UDAP, FAST, Security, Authentication, Authorization, Registration 3g. Lineage 3h. Project Dependencies 3i. HL7-Managed Project Document Repository URL: https://confluence.hl7.org/display/SEC/FAST%3A+Scalable+Registration%2C+Authentication%2C+and+Authorization+for+FHIR+Ecosystem+Participants 3j. Backwards Compatibility No 3k. Additional Backwards Compatibility Information (if applicable) 3l. Using Current V3 Data Types? N/A 3l. Reason for not using current V3 data types? 3m. External Vocabularies Yes 3n. List of Vocabularies IETF: OAuth and JOSE related codes, e.g., OAuth and JWT params These codes are generally available and do not need specific licensing. 3o. Earliest prior release and/or version to which the compatibility applies 4a. Products FHIR Implementation Guide 4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to? FHIR R4+ 4c. FHIR Profiles Version 4d. Please define your New Product Definition 4d. Please define your New Product Family 5a. Project Intent Implementation Guide (IG) will be created/modified 5a. White Paper Type 5a. Is the project adopting/endorsing an externally developed IG? Yes 5a. Externally developed IG is to be (select one) Adopted 5a. Specify external organization UDAP.org https://www.udap.org/udap-ig-consumer-facing-health-apps.html https://www.udap.org/udap-ig-b2b-health-apps.html 5a. Revising Current Standard Info 5b. Project Ballot Type STU to Normative 5c. Additional Ballot Info Externally developed IG as base for additional development 5d. Joint Copyright Yes 5e. I understand I must submit a Joint Copyright Letter of Agreement to the TSC in order for the PSS to receive TSC approval. Yes 6a. External Project Collaboration ONC FHIR at Scale Taskforce (FAST) UDAP.org 6b. Content Already Developed 70% 6c. Content externally developed? Yes 6d. List Developers of Externally Developed Content ONC FHIR at Scale Taskforce (FAST) UDAP.org March 1, 2020: HL7 Board approved the SOU with UDAP and it covered joint copyright. 6e. Is this a hosted (externally funded) project? Yes 6f. Stakeholders Clinical and Public Health Laboratories, Immunization Registries, Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs), Payors 6f. Other Stakeholders 6g. Vendors Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS 6g. Other Vendors 6h. Providers Clinical and Public Health Laboratories, Emergency Services, Local and State Departments of Health, Medical Imaging Service, Healthcare Institutions (hospitals, long term care, home care, mental health) 6h. Other Providers 6i. Realm U.S. Realm Specific 7d. US Realm Approval Date Feb 23, 2021 7a. Management Group(s) to Review PSS FHIR 7b. Sponsoring WG Approval Date Feb 02, 2021 7c. Co-Sponsor Approval Date 7c. Co-Sponsor 2 Approval Date 7c. Co-Sponsor 3 Approval Date 7c. Co-Sponsor 4 Approval Date 7c. Co-Sponsor 5 Approval Date 7c. Co-Sponsor 6 Approval Date 7c. Co-Sponsor 7 Approval Date 7c. Co-Sponsor 8 Approval Date 7c. Co-Sponsor 9 Approval Date 7c. Co-Sponsor 10 Approval Date 7e. CDA MG Approval Date 7f. FMG Approval Date Feb 17, 2021 7g. V2 MG Approval Date 7h. Architecture Review Board Approval Date 7i. Steering Division Approval Date Apr 09, 2021 7j. TSC Approval Date Apr 19, 2021