| Management | HL7 Antitrust Policy | Professional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM). |
| Discussion Topics / STU2 Requirements | Synthesis from 9/7/23 and 9/21/23 discussions (Aaron) - Guidance on Identity Assurance
- Establish a grammar for expressing attribute verification status
| - Aaron reviewed a set of slides that summarized the past two meeting discussions
- Levels of Identity Assurance - takeaways
- Levels and criteria largely satisfactory, no changes requested
- Biggest hurdle lies in implementation
- Minimum levels in IG
- High burden for certain use cases (pharmacy, vision)
- How do we better encourage implementation of this IG?
- Rita noted that the group also discussed how we would test this and if it is testable - another possible burden and consideration
- Aaron agreed and moved to the topic of expressing verified attributes topic (Expressing Verified Attributes - other considerations) - which is where this is documented
- Julie asked if we documented the extension to the patient resource as a way to achieve this with provenance - yes, it is part of the takeaways
- Expressing Verified Attributes (slide 1)
- Noted as an important requirement for STU2
- Two locations where identity assurance occurs
- JWT used in digital identity workflow
- Not large priority, will consider updating if interest grows
- There are ways to declare IAL within JWTs and OIDC user profiles + ID tokens
- FHIR resource for Patient/Person
- Used in $match, as well as applications outside of match to verify attributes of a Patient/Person
- High priority
- Multiple avenues to achieve this goal
- Julie noted unsolved items are individual attribute level of assurance and other types of transactions
- Julie noted that there wasn't a need to deal with individual attributes at this time; any included attributes would be consistent with identity attributes; the other takeaway - we do have ways to declare levels of identity assurance in signed JWTs; this IG can have patient matching implications outside of FHIR and OAuth; the group modified the takeaways to reflect these points
- Elizabeth noted that with identity theft and identifiers that are compromised - can a device hardware token be another identifier?
- Julie thinks that falls under our guidance as a piece of evidence that you can demonstrate control of. If you have suggestions for additional language, we welcome that. We did receive some SME feedback that was reluctant; to rely on that as an identifier to facilitate consumer interaction at scale, but if we want to open that back up again, we can. Especially as 1.2 is under attack with digital photo topic.
- Expressing Verified Attributes (slide 2)
- Tagging each demographic in Patient/Person with a "verified" tag
- Explicit yet tedious and inefficient
- Utilizing an additional resource as a reference to determine the verification status, effective date, etc., of the Patient/Person
- Encounter - gives date on identity verification event, potentially awkward fit for general use
- Claim - proposed by Cooper T. can be used to match identifiers, requires more investigation
- Provenance - Can reference Patient/Person/RelatedPerson, proof of concept from Eric Haas that can be used as a starting point
- Can represent who, how, and when attributes were collected using targetElement extensions
- Rita - when talking about verified attributes, are we talking about source information or part of a particular transaction?
- These would be FHIR resources - the patient would be referenced within profiles that would provide additional information about verification event
- Aaron demonstrated an example of a FHIR patient resource and showed how to tag US Core / race - you would include an ID or extension that states the attribute would be verified, like through a Boolean event (true/false); can occur on sending or receiving side
- What do we mean by Claim? May need to get additional insight from Cooper to understand this better. Perhaps he meant SMART health card or ID claim.
- Aaron will start to draft content and commit to the CI Build so that the group can start looking at a draft and provide feedback.
- Expressing Verified Attributes (slide 3)
- Expression of IAL level within FHIR
- Extension on Patient/Person vs referenced resource
- How are patients who have been authenticated at different levels of assurance handled when a $match request is initiated
- e.g., Org A who authenticated at IAL1.8 sends query to Org B, who authenticated at IAL1.2
- Is this in scope? (up to the discretion of the organization to handle this, like our guidance on $match if a Patient resource fails to meet specific weighting criteria)
- As of today, we don't say that responders have to verify data at a certain level of assurance before answering a query. In STU2, should we say something stronger about matches not being returned or are we ok?
- It's tricky - if going from 1.8 to 1.2, probably not a problem, but if going from 1.2 to 1.8, may not be possible to verify.
- The problem is, we don't say anything about the responder side today; Org B could give a very nice match request, but we don't require identity management for a responder today. All matches may be returned and may be some false positives if only verifying name and date of birth. Should Org B be required to share at leads the IAL2 status with the requestor? In STU1, we didn't want to enforce requirements on responders.
- Is it possible to suggest a minimum IAL level? So everyone can at least start to move to the same level.
- Are you asking a responder to return an IAL at a particular level or are you asking them to make a calculation? We already ask responders to calculate the score; but where their identity management system that is at a low level of assurance, what do we require.
- What do we mean by minimum?
- The group ran out of time but will continue this discussion on a future call.
|
| Chat Comments |
| 13:02:17 From Crystal Kallem (POCP / FAST PMO) To Everyone:
Today's Agenda: https://confluence.hl7.org/pages/viewpage.action?pageId=184931455
13:15:08 From David Pyke (Audacious Inquiry) To Everyone:
Cooper Thompson has a workup that shows provenance and a needed extension
https://hackmd.io/dwGmKFuORlysFUReA7deIw?view that could be repurposed for verification levels
13:19:29 From Elizabeth Spangler - Westat To Everyone:
Tricky.... yes, I think hw token maybe? if email and or phone number or identity theft occurs the basic matching could be compromised if phone or email is highjacked , could impersonate/fraud. - a hardware token maybe could be assigned in certain needs?
13:24:11 From Elizabeth Spangler - Westat To Everyone:
Thanks again!
13:26:30 From Julie Maas To Everyone:
@Elizabeth Spangler - Westat I would point you to the Digital Identifier tab too--we have the foundation for defining these and the hardware token (hopefully with consumer friendly yet secure use) can be paired with that as authenticator in a use of this iG as it stands today.
13:32:49 From Elizabeth Spangler - Westat To Everyone:
note, recall there is some issue with the "verified" if fraud/falsely "verified", this has occured in instance with social media profiles... but could be re-credentialed with this case, or carry a token/key exchange to authenticate to the "verified" key, or some physical "refreshable" key/protected.. expereince a fraudster getting registered to a state clinic with little id creating a second record, how to cross verify? - or a future state implementation..
13:35:12 From Elizabeth Spangler - Westat To Everyone:
Nice! |
