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

Inconsistent workflows, Proper use of IAL levels

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Duplicate
    • Icon: Highest Highest
    • Interoperable Digital Identity and Patient Matching (FHIR)
    • 1.0.0-ballot
    • Patient Administration
    • STU
    • (many)
    • Hide
      1. Update 1.1 text; 2. Clarify no match when authenticating patient (sub-topic: is B2B mediated considered “authenticating patient”?) 3.2/5.3 Insert example use cases into identity management and matching requirements 4.4 Add discussion re: match input weight use cases 4.5 Clarify that any known input attributes can be used 4.7 Respond wrt temporary local identifiers for subsequent workflows 5.1 add clarifying language re: how organizational credentials at a level of assurance are established in networks more generally 5.3 should ask the group if we should make 5.3 more than a non-normative example and establish a user level of authentication assurance

      UPDATE: We have split out this ticket into 9 separate tickets based on the individual questions/propositions in the description below. Tickets are linked as well.

      Show
      Update 1.1 text; 2. Clarify no match when authenticating patient (sub-topic: is B2B mediated considered “authenticating patient”?) 3.2/5.3 Insert example use cases into identity management and matching requirements 4.4 Add discussion re: match input weight use cases 4.5 Clarify that any known input attributes can be used 4.7 Respond wrt temporary local identifiers for subsequent workflows 5.1 add clarifying language re: how organizational credentials at a level of assurance are established in networks more generally 5.3 should ask the group if we should make 5.3 more than a non-normative example and establish a user level of authentication assurance UPDATE: We have split out this ticket into 9 separate tickets based on the individual questions/propositions in the description below. Tickets are linked as well.

    Description

      I am submitting this on behalf of Kevin Geminiuc

      Section 1.3
      Need more detail on section 1.1, 1.3 Use Case and Roles, FHIR patterns and how the query/matching flow is initiating.
      Recommend highlighting that use cases may use matching with

      Section 1.3
      The IG is inconsistently applying the list of workflows defined in 1.3 to the subsequent chapters "Identity Assurance", "Patient Matching" and "Digital Identity". A canonical formulation of protocol exchange (FHIR) should be described for each of the flow in which the conveyed PII and/or digital identifiers is defined. The different flows also will help to differentiate the authentication of flows from the authentication of the data and the authorization/consent provided for the responder. Note: this is different for B2C and B2B.

      Consider separating the topic of Identity Management to a different artifact that can have different timelines for adding specificity. This would allow to align with various ongoing initiatives like TEFCA and the CARIN/HHS Patient-centric Digital Identity Federation POC.

      Section 3.1
      Is HL7 endorsing IAL 1.x as a defacto standard if NIST is no longer involved in this specification?

      Section 3.2, 5.3
      Recommend to define credential in each type of reference (e.g. password credential vs verifiable credential vs "identity credential"

      Section 4.4
      How can we apply the match threshold by use case to ensure the appropriate use of an identity?

      Section 4.5
      Is this the fill list of attributes that can be used or is that still TBD?

      Section 4.7 - Scoring Matches
      When a match output is made, there is typically a temporary link/identifier created between organizations.
      This allows for subsequent referrals to the patient easier via Identifier so guest hospitals can send chart updates to the the queried "home" healthcare organization (if a agreement is in place)
      Recommend to address if this is in-scope and how it would work to support this workflow.

      Section 5.1
      The following text: "Note: digital identities involved in healthcare transactions may correspond to Patients, Providers, Payers, and other healthcare actors."

      Note that NIST Special Publication 800-63 is only targeting people, not entities.
      Could we further elaborate if NIST is being applied to Payer entities? How would assurance/digital work for each of these?

      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 INDIVDUALS, not entities.

      Attachments

        Activity

          People

            Unassigned Unassigned
            Brian_Pech Brian Pech
            Kevin Geminiuc
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: