| 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). |
|
| HL7 Code of Conduct | https://www.hl7.org/legal/code-of-conduct.cfm |
|
| Minutes Approval | 2023-02-02 Interoperable Digital Identity & Patient Matching Meeting |
|
| Project Links | Project Page: Interoperable Digital Identity and Patient Matching Capabilities Project Scope Statement: Patient Matching PSS Connectathon Track Pages: Implementation Guide: |
|
| Milestones | May 2022 Ballot Cycle | Milestone | Date |
|---|
| Ballot Voting | Complete | | Ballot Reconciliation | In Progress | | STU 1 Publication | Q1 2023 |
|
|
| Agenda |
|
|
|
| IG Status Update - Outcome of block vote
- Status of ballot reconciliation / Tickets to revisit
- Status of applying tickets to the CI Build
- Next steps and anticipated timelines
| IG Status Updates - Aaron submitted a block vote to the PA WG which was reviewed yesterday.
- Two tickets pulled from the block vote based on some questions/feedback.
- On other ticket was submitted by Julie with a technical correction
- Assuming we get through these tickets today, we can submit back to PA for an additional block vote next Wednesday.
- Aaron has been applying tickets from block vote 1 into the IG that he forked off from the master. Julie has also been incorporating updates from some tickets.
- Will be working on applying the remaining tickets to the IG by end of February.
- Julie mentioned that there is a bulk matching initiative that was discussed at last Connectathon. Focus of the problem is about how to formulate data intended for bulk match requests that are submitted at one time. Rather than getting results back about multiple patients, this is submitting a match request for multiple patients. Reach out to Julie if you have interest in being included in future conversations. There is a meeting occurring in the next hour.
Ballot Reconciliation
FHIR-40355
-
Getting issue details...
STATUS
- AN: There was a question about assigners within the resolution and whether or not it was representing the requesting or responding system.
- JM: The comments were two fold; there was someone at PA that asked if assigner had responder context; whether assigner needed definition. Assigners are generally understood in the space of FHIR when an identifier has an assigner attribute. Point of this requirement is that we are wanting to feed records with identifiers when they are being created.
- RT: In paragraph that has the disposition, "assigners which manage health records shall associate patient with their identifier...." What does this mean?
- JM: It means that if I get a request from another system and that patient HL7 identifier is included in match request, it's a perfect match and should be returned in the match results. At a minimum, that assigner will associate the respective patient with that identifier in their own system. Assigner is creating the global identifier. This SHALL puts requirement on those who create the identifiers to be aware of where it exists and is maintained in their own system. Because there is no identifier in USCDI today, it's a starting point. Need to start establishing the use of Identifiers in systems - if you are compliant with this IG and start issuing these identifiers, please save them in your systems and start using for identity management in your own systems. Can then later be used in cross organizational exchange.
- RT: Maybe it just needs to be reworded.
- JM: Anyone finding this language to be necessary?
- From Julie Maas to Everyone at 13:21: "to establish these identifiers within their own systems"
- RL: I like the added clarity.
- RT: I'm fine with that. It's the part that addresses the return. Maybe break sentence into two.
- Updated the proposed resolution to state "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."
AN: Another comment was, should we flag existing/new content, e.g. content for new requirements. The content within this one ticket alone appears to introduce several requirements to workflows where it's unclear if they have been tested. - JM: The other references were just examples that were supposed to be added, because at the end of that sentence there's a statement about shared in any other trusted context. So it doesn't intend to specify or limit how these exchanges can occur.
- AN: There was reference to “probabilistic” matching that we had a question about.
- JM: Doesn't intend to specify how these exchanges should occur. Although we hope probabilistic matching will phase out over time, we acknowledge it and this IG provides best practices to help make it better.
- RT: Re: probabilistic matching, when you describe weighting, do you see that as being deterministic or probabilistic?
- JM: So far, we defined invariant that we were expecting to be used only for probabilistic matching, but we have received feedback that it would be helpful to articulate an example invariant that would be useful for known industry matches of probabilistic matching and a different invariant for deterministic matching. Trying to think through what this might look like. That's where we discussed last meeting
FHIR-40354
-
Getting issue details...
STATUS
- AN: Rita had raised a question asking for clarity around organizational identity from NIST. Asked Rita if there was something specific she wanted to review about this ticket.
- RT: Like a lot of the other IAL tickets, that digital identities. specifically referencing the NIST 863, is only specific to people and not entities. I thought that was interesting in terms of how we use it, or or what we're saying about it.
- Aaron pulled this ticket out in case Rita had other questions.
- No other questions or changes made to the ticket.
FHIR-40386
-
Getting issue details...
STATUS
- JM: This ticket is related to a typo. The problem was that we ran the risk of implying that a drivers license is fair when the requirement is better stated as fair or stronger.
- RT: Do we plan to align with any of the new NIST requirements or just keep current publication requirements. General thoughts/discussion.
- JM: We intend to track and envision updates to this IG as these items evolve.
- RT: They actually present issues that relate to using a photo and we have mentioned as a potential attribute for weighting. Didn't know if that would be impacted.
- JM: Difficult to say until they have final text, and until they go so far as to speak about attributes for identity, resolution which is the concern for the invariant specifically. Certainly following this work.
- JM: Requiring IAL2 as a bar sometimes limits those who are able to provide a high quality selfie or video chat and may be limiting. So, that's the reason that having in-person alternatives, and possibly not requiring a liveness check is something that may be important to scaling and proofing of these sensitive populations.
- JM: Rita did raise another thought and will probably see in another ticket coming up. Recognizing that the guidance as it stands from NIST for 63-4 does soften to reduce when a driver's license is used the additional evidence becomes one fair instead of two fairs; if we step that down to when a drivers license is used, something else like a mobile number might help with equity concerns. It's appearing in another draft resolution but rounds out the conversation and addresses equity.
|
|
| Update on CARIN Identity Proof of Concept | Julie has been popping into the CARIN proof of concept - CARIN has strong interest in digital identity.
- CARIN has a presence in Washington and involved in recent legislation related to identity. There are a number of large scale identity services and health system that participate in these conversations.
- Ryan has participated in our WG as well. Have discussed open ID credentials, etc. and has been looking for ways to collaborate with this group and HL7 more broadly.
- There have been efforts to do a test - Ryan wanted to have a demo by ViVE and HIMSS. There are multiple levels of participation in the proof of concept. One of which is assertion of attributes without an open ID connect credential that authenticates a person. Another is HHS XMS service - go to their portal and pick a credential for logging in and interact with this identity broker server. Another is service provider.
- The paper offers these options in a discussion. The Tiered OAuth solution that is mentioned in our IG meets the mark on what they were hoping to do.
- The paper also highlights definition of IAL2 and concerns about equity opportunity.
|
|
| Planning for Upcoming Events - FAST Kiosk at HIMSS (April 17 - 21)
- HL7 May Connectathon (May 6-7)
- HL7 May WGM+ (May 8 - 12)
| - FAST Kiosk at HIMSS (April 17 - 21)
- FAST will have a Kiosk at HIMSS
- Currently working with FAST members to figure out what content to highlight at the Kiosk - Identity is one of those options
- Thinking about doing something collaboratively with CARIN, but nothing finalized yet
- If you are planning to attend HIMSS and have interest, feel free to reach out to Crystal or Dana
- HL7 May Connectathon (May 6-7)
- Planning to test identity at the Connectathon again.
- Still looking for implementers to test.
- HL7 May WGM+ (May 8 - 12)
- Sill be a modified format with dedicated tracks for the accelerators
- FAST has some proposed sessions (some specific to identity).
- Nothing finalized yet. More to come. Hoping folks plan to attend!
|
|
| Management |
| Next Meeting: March 2, 2023 |
|
| Next Agenda |
|
|
| Adjournment |
| Adjourned at 2:55 pm ET |
|
