Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-40355

Inconsistent workflows, Proper use of IAL levels (9 of 9)

XMLWordPrintableJSON

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • Interoperable Digital Identity and Patient Matching (FHIR)
    • 1.0.0-ballot [deprecated]
    • Patient Administration
    • Digital Identity
    • Hide

      Revising the final bullet in 5.2 to instead be:

      • Identifier SHOULD be ‘FHIR-ready’. The Identifier can be associated with an OpenID Connect credential that is capable of OAuth 2.0 authentication via [UDAP Tiered OAuth Consumer-Facing](https://build.fhir.org/ig/HL7/fhir-udap-security-ig/branches/main/consumer.html), UDAP JWT-Based Authentication, asserted in a [UDAP B2B](https://build.fhir.org/ig/HL7/fhir-udap-security-ig/branches/main/b2b.html) transaction within an Authorization Extension Object, or shared in another trusted context. Assigners which manage patient health records SHALL associate a patient with their Identifier using Patient.identifier to establish these identifiers within their own systems. The match responder SHALL return the appropriate matching patient when a query from a trusted party includes an Identifier as a search parameter or in a match request. When it exists, the Identifier SHOULD appear in OpenID Connect identity claims made to trusted healthcare relying parties; note however that the Identifier defined in this Implementation Guide is distinct from the OpenID Connect subject identifier, as the following example demonstrates:
      Show
      Revising the final bullet in 5.2 to instead be: Identifier  SHOULD be ‘FHIR-ready’. The Identifier can be associated with an OpenID Connect credential that is capable of OAuth 2.0 authentication via [UDAP Tiered OAuth Consumer-Facing] ( https://build.fhir.org/ig/HL7/fhir-udap-security-ig/branches/main/consumer.html), UDAP JWT-Based Authentication, asserted in a [UDAP B2B] ( https://build.fhir.org/ig/HL7/fhir-udap-security-ig/branches/main/b2b.html ) transaction within an Authorization Extension Object, or shared in another trusted context. Assigners which manage patient health records SHALL associate a patient with their Identifier using Patient.identifier to establish these identifiers within their own systems. The match responder SHALL return the appropriate matching patient when a query from a trusted party includes an Identifier as a search parameter or in a match request. When it exists, the Identifier SHOULD appear in OpenID Connect identity claims made to trusted healthcare relying parties; note however that the Identifier defined in this Implementation Guide is distinct from the OpenID Connect subject identifier, as the following example demonstrates:
    • Aaron Nusstein / Brian Postlethwaite : 10-0-0
    • Clarification
    • Non-substantive

      Section 5.3
      We would also recommend

      • Digital Identifiers should not be tied to IAL. A separate step that defines the identity credential for the individual's identifier should be conformant to a globally specified identity verification process at IAL.
      • Authentication is dependent on the flow class (B2C vs B2B) and does not uniformly apply. Note: NIST 800-63-B does only apply to INDIVIDUALS, not entities.
      • should ask the group if we should make 5.3 more than a non-normative example and establish a user level of authentication assurance

            Unassigned Unassigned
            nussteja Aaron Nusstein
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: