There is discussion going on in the FHIR chat on this topic. I wanted to capture details as it seems that most of the problem is getting everyone understanding the same thing. The discussion is specific to an open system for recording and showing that an individual has received a COVID-19 immunization. (see HL7 effort on vaccination credentials and broader outreach). There are other COVID-19 immunization trancing efforts, the above just is the one I am most closely working with.
The summary is that there is likely good valid use for having a IAL like vocabulary to be used in Patient.meta.security to indicate to which level of assurance was this identity proofed. This because it is not uncommon to have some patients able to bring a government issued picture ID like a passport or REAL-ID, where other patients will not have this kind of an identifier, and other patients might have nothing, and others that are completely un-identifiable.
Where the use of an AAL vocabulary is theoretically useful as an attribute of the Immunization.subject binding to the Patient; but this is not as obviously needed. More realistic is that the whole of the Immunization resource (Immunization.meta.security) could hold an integrity confidence value. But event that is not likely to be needed as the system likely has a required assurance needed before ever giving an immunization and thus there is not a need to indicate the assurance as all records will be at the same level by policy.
Basics of Assurance Levels
There are two concepts that are very important and important to understand. I will use NIST 800-63, but the overall use-case is not a USA specific thing. The use of NIST here is simply because the discussion was USA specific, and the NIST specification are easily accessible. I welcome someone providing me the ISO equivalent, but ISO is too expensive and hard to access.:
- IAL -- Identity Assurance Level - refers to the identity proofing process
- AAL - Authentication Assurance Level - refers to the authentication process
- FAL - Federation Assurance level - refers to strength of an identity in a federated system.
Wrong but useful
IAL is broken down into three conceptually defined levels
- IAL1: There is no requirement to link the applicant to a specific real-life identity. Any attributes provided in conjunction with the authentication process are self-asserted or should be treated as such (including attributes a Credential Service Provider, or CSP, asserts to an RP).
- IAL2: Evidence supports the real-world existence of the claimed identity and verifies that the applicant is appropriately associated with this real-world identity. IAL2 introduces the need for either remote or physically-present identity proofing. Attributes can be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes.
- IAL3: Physical presence is required for identity proofing. Identifying attributes must be verified by an authorized and trained representative of the CSP. As with IAL2, attributes can be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes.
AAL is broken down into three conceptually defined levels
- AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber’s account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.
- AAL2 provides high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Proof of possession and control of two distinct authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.
- AAL3 provides very high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication SHALL use a hardware-based authenticator and an authenticator that provides verifier impersonation resistance; the same device MAY fulfill both these requirements. In order to authenticate at AAL3, claimants SHALL prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required.
Use of Assurance Levels in healthcare workflow
- getting the Patient identification information.
- recording the immunization that was given to the patient
- relying-party using the immunization credential to allow the patient to do something
Step 1: getting the Patient identification information:
Step 2: recording the immunization that was given to the patient:
Step 3: relying-party using the immunization credential to allow the patient to do something
IAL of the Patient Resource.
So it is important to understand which of these is going to be variable within your data. If you know that (1) is going to vary within your data, then you need a way to record which value of (1) each Patient resource has been proofed at. If you know that (2) is going to vary within your data, then you need a way to record the (2) for each reference.
AAL of the link between Immunization and Patient
Further (2) is not security meta about the content of the Immunization.patient element; it is specifically an AAL of the linkage confidence. Thus this is not a general extension carrying .meta.security at the element level (which is a task that DS4P is likely to add). The AAL need is different.