Skip to end of metadata
Go to start of metadata




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


Version

13

Modifier

Dana Marcelonis

Modify Date

Apr 27, 2021 19:19

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 now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Service Oriented Architecture

2d. Project Facilitator

Luis Maas and Brett Stringham

2i. Domain Expert Representative

Luis Maas, Brett Stringham

2j. Business Requirements Analyst

Paul Oates, Patrick Murta, Aaron Seib

2k. Conformance Facilitator

TBD

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

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

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

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

3l. Using Current V3 Data Types?

N/A

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.

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR R4+

5a. Project Intent

Implementation Guide (IG) will be created/modified

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

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

6g. Vendors

Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS

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)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Feb 02, 2021

7d. US Realm Approval Date

Feb 23, 2021

7f. FMG Approval Date

Feb 17, 2021

7i. Steering Division Approval Date

Apr 09, 2021

7j. TSC Approval Date

Apr 19, 2021

Version

12

Modifier

Anne Wizauer

Modify Date

Apr 13, 2021 19:56

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 now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Service Oriented Architecture

2d. Project Facilitator

Luis Maas and Brett Stringham

2i. Domain Expert Representative

Luis Maas, Brett Stringham

2j. Business Requirements Analyst

Paul Oates, Patrick Murta, Aaron Seib

2k. Conformance Facilitator

TBD

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

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

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

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

3l. Using Current V3 Data Types?

N/A

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.

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR R4+

5a. Project Intent

Implementation Guide (IG) will be created/modified

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

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

6g. Vendors

Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS

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)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Feb 02, 2021

7d. US Realm Approval Date

Feb 23, 2021

7f. FMG Approval Date

Feb 17, 2021

7i. Steering Division Approval Date

Apr 09, 2021

Version

11

Modifier

Dana Marcelonis

Modify Date

Mar 23, 2021 22:20

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 now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Service Oriented Architecture

2d. Project Facilitator

Luis Maas and Brett Stringham

2i. Domain Expert Representative

Luis Maas, Brett Stringham

2j. Business Requirements Analyst

Paul Oates, Patrick Murta, Aaron Seib

2k. Conformance Facilitator

TBD

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

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

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

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

3l. Using Current V3 Data Types?

N/A

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.

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR R4+

5a. Project Intent

Implementation Guide (IG) will be created/modified

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

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

6g. Vendors

Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS

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)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Feb 02, 2021

7d. US Realm Approval Date

Feb 23, 2021

7f. FMG Approval Date

Feb 17, 2021

Version

10

Modifier

Dana Marcelonis

Modify Date

Mar 23, 2021 20:34

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 now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Service Oriented Architecture

2d. Project Facilitator

Luis Maas and Brett Stringham

2i. Domain Expert Representative

Luis Maas, Brett Stringham

2j. Business Requirements Analyst

Paul Oates, Patrick Murta, Aaron Seib

2k. Conformance Facilitator

TBD

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

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

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

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

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

Yes

3n. List of Vocabularies

IETF/OAuth related codes, e.g., OAuth and JWT params

These codes are generally available and do not need specific licensing.

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR R4+

5a. Project Intent

Implementation Guide (IG) will be created/modified

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

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

6g. Vendors

Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS

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)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Feb 02, 2021

7d. US Realm Approval Date

Feb 23, 2021

7f. FMG Approval Date

Feb 17, 2021

Version

9

Modifier

Dave Hamill

Modify Date

Mar 02, 2021 14:55

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 now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Service Oriented Architecture

2d. Project Facilitator

Luis Maas and Brett Stringham

2i. Domain Expert Representative

Luis Maas, Brett Stringham

2j. Business Requirements Analyst

Paul Oates, Patrick Murta, Aaron Seib

2k. Conformance Facilitator

TBD

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

For additional information: https://oncprojectracking.healthit.gov/wiki/download/attachments/118849815/FAST-PS-Security-v3draft-SEP8-2020.docx?version=1&modificationDate=1608220408000&api=v2

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

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

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

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR R4+

5a. Project Intent

Implementation Guide (IG) will be created/modified

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

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

6g. Vendors

Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS

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)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Feb 02, 2021

7d. US Realm Approval Date

Feb 23, 2021

7f. FMG Approval Date

Feb 17, 2021

Version

8

Modifier

Dana Marcelonis

Modify Date

Feb 23, 2021 19:21

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 now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Service Oriented Architecture

2d. Project Facilitator

Luis Maas and Brett Stringham

2i. Domain Expert Representative

Luis Maas, Brett Stringham

2j. Business Requirements Analyst

Paul Oates, Patrick Murta, Aaron Seib

2k. Conformance Facilitator

TBD

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

For additional information: https://oncprojectracking.healthit.gov/wiki/download/attachments/118849815/FAST-PS-Security-v3draft-SEP8-2020.docx?version=1&modificationDate=1608220408000&api=v2

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

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

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

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR R4+

5a. Project Intent

Implementation Guide (IG) will be created/modified

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

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

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

6g. Vendors

Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS

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)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Feb 02, 2021

7d. US Realm Approval Date

Feb 23, 2021

7f. FMG Approval Date

Feb 17, 2021

Version

7

Modifier

Dave Hamill

Modify Date

Feb 16, 2021 19:51

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 now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Service Oriented Architecture

2d. Project Facilitator

Luis Maas and Brett Stringham

2i. Domain Expert Representative

Luis Maas, Brett Stringham

2j. Business Requirements Analyst

Paul Oates, Patrick Murta, Aaron Seib

2k. Conformance Facilitator

TBD

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

For additional information: https://oncprojectracking.healthit.gov/wiki/download/attachments/118849815/FAST-PS-Security-v3draft-SEP8-2020.docx?version=1&modificationDate=1608220408000&api=v2

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

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

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

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR R4+

5a. Project Intent

Implementation Guide (IG) will be created/modified

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

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

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

6g. Vendors

Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS

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)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Feb 02, 2021

Version

6

Modifier

Dave Hamill

Modify Date

Feb 16, 2021 19:35

1a. Project Name

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

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Service Oriented Architecture

2d. Project Facilitator

Luis Maas and Brett Stringham

2i. Domain Expert Representative

Luis Maas, Brett Stringham

2j. Business Requirements Analyst

Paul Oates, Patrick Murta, Aaron Seib

2k. Conformance Facilitator

TBD

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

For additional information: https://oncprojectracking.healthit.gov/wiki/download/attachments/118849815/FAST-PS-Security-v3draft-SEP8-2020.docx?version=1&modificationDate=1608220408000&api=v2

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

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

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

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR R4+

5a. Project Intent

Implementation Guide (IG) will be created/modified

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

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

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

6g. Vendors

Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS

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)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Feb 02, 2021

Version

5

Modifier

Dana Marcelonis

Modify Date

Feb 15, 2021 20:29

1a. Project Name

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

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2d. Project Facilitator

Luis Maas and Brett Stringham

2i. Domain Expert Representative

Luis Maas, Brett Stringham

2j. Business Requirements Analyst

Paul Oates, Patrick Murta, Aaron Seib

2k. Conformance Facilitator

TBD

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

For additional information: https://oncprojectracking.healthit.gov/wiki/download/attachments/118849815/FAST-PS-Security-v3draft-SEP8-2020.docx?version=1&modificationDate=1608220408000&api=v2

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

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

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

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR R4+

5a. Project Intent

Implementation Guide (IG) will be created/modified

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

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

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

6g. Vendors

Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS

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)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Feb 02, 2021

Version

4

Modifier

Dana Marcelonis

Modify Date

Feb 09, 2021 16:32

1a. Project Name

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

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2d. Project Facilitator

Luis Maas and Brett Stringham

2i. Domain Expert Representative

Luis Maas, Brett Stringham

2j. Business Requirements Analyst

Paul Oates, Patrick Murta, Aaron Seib

2k. Conformance Facilitator

TBD

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

For additional information: https://oncprojectracking.healthit.gov/wiki/download/attachments/118849815/FAST-PS-Security-v3draft-SEP8-2020.docx?version=1&modificationDate=1608220408000&api=v2

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

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

3i. HL7-Managed Project Document Repository URL:

TBD

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR R4+

5a. Project Intent

Implementation Guide (IG) will be created/modified

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

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

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

6g. Vendors

Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS

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)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Feb 02, 2021

Version

3

Modifier

Dana Marcelonis

Modify Date

Feb 01, 2021 18:14

1a. Project Name

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

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2d. Project Facilitator

Luis Maas and Brett Stringham

2i. Domain Expert Representative

Luis Maas, Brett Stringham

2j. Business Requirements Analyst

Paul Oates, Patrick Murta, Aaron Seib

2k. Conformance Facilitator

TBD

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

For additional information: https://oncprojectracking.healthit.gov/wiki/download/attachments/118849815/FAST-PS-Security-v3draft-SEP8-2020.docx?version=1&modificationDate=1608220408000&api=v2

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

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

3i. HL7-Managed Project Document Repository URL:

TBD

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR R4+

5a. Project Intent

Implementation Guide (IG) will be created/modified

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

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

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

6g. Vendors

Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS

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)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

2

Modifier

Dana Marcelonis

Modify Date

Feb 01, 2021 18:13

1a. Project Name

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

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2d. Project Facilitator

Luis Maas and Brett Stringham

2i. Domain Expert Representative

Luis Maas, Brett Stringham

2j. Business Requirements Analyst

Paul Oates, Patrick Murta, Aaron Seib

2k. Conformance Facilitator

TBD

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

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

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

3i. HL7-Managed Project Document Repository URL:

TBD

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR R4+

5a. Project Intent

Implementation Guide (IG) will be created/modified

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

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

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

6g. Vendors

Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS

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)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

1

Modifier

Dana Marcelonis

Modify Date

Feb 01, 2021 18:10

1a. Project Name

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

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2d. Project Facilitator

Luis Maas and Brett Stringham

2i. Domain Expert Representative

Luis Maas, Brett Stringham

2j. Business Requirements Analyst

Paul Oates, Patrick Murta, Aaron Seib

2k. Conformance Facilitator

TBD

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

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

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

3i. HL7-Managed Project Document Repository URL:

TBD

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR R4+

5a. Project Intent

Implementation Guide (IG) will be created/modified

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

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

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

6g. Vendors

Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS

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)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR