Chair:  Julie Maas , Carmen Smiley , Aaron Nusstein 

Scribe: Dana Marcelonis 



Meeting Schedule

1st and 3rd Thursdays of the month, 2-3pm ET 

https://hl7-org.zoom.us/j/99145025586?pwd=bE01OFVHZkVta051SlRjbjJZMTFRQT09

Meeting ID: 991 4502 5586

Passcode: 568743 

NOTE: This attendance applies if you are present at the related meeting/call, regardless if you have signed a different attendance for your WG. 

Attendees

Present

Name

Affiliation

x

Carmen Smiley 

ONC
xJulie MaasEMR Direct
xVijey Kris SridharanUHC

Catherine SchultenChange Healthcare

Robin Poirier Ready Computing

Dana Marcelonis 

POCP

Rick FrenchAllscripts

Priti DaveSafe Identity

John McCoyAllscripts

Jeff Brown Lantana

Janice Karin 

MA Health Data Consortium

Gary Dickinson 



Cooper Thompson 

Epic

Michelle Barry 

Availity

Velvet Hanes-RitchieAllscripts
xJim StClair Interoperability Institute

Steven Hoffer
xPaul VaughanOptum

Richard Hornaday Allscripts
xRita TorkzadehAEGIS

Tammy FowlerAllscripts

Nick Radov UHC

Liz BuckleCommonWell

Jaime Smith

Alex Kontur ONC

Olivia Bellamou-Huet Philips

Charles Ye 

Joseph Quinn (Joe)

Smile Digital Health

Serafina Versaggi 



Brian Pech 

Ryan Howells CARIN, Leavitt Partners

Alberto S. Llanes FEHRM

Josh Mandel 

Christopher Gracon 

Independent Health
x

David Pyke 

Audacious Inquiry

Kimberly TaverniaONC

John RancourtONC

Liz Palena Hall

Rachel E. Foerster Rachel Foerster & Associates

Chandrakant Bhonsle 

Sanjay Sharma 

Optum

Ruby Nash 

Lantana

Didi Davis 

Sequoia Project

Sonja Ziegler 

Optum

Gary WordAvaneer Health

Marc Mar-YohanaOtis Health

Kathleen Connor 

MITRE

Michelle DurbinAltera

Liz TuriONC

Napoleon RussMITRE

Michael Golden

David DeRoode Lantana

Christol Green 

Elevance Health

Gail HodgesOpenID Foundation

Ming Dunajick 

Lantana

Shamil Nizamov 

Smile CDR

Joseph ShookSurescripts

Peter Muir 

Deborah Bucci 

Stephanie Murphy POCP

Sheljina Ibrahim 

Elevance Health

Jason Vogt CommonWell/ MEDITECH
x

Joseph M. Lamy 

AEGIS

Elliot Silver 

ResMed
x

Crystal Kallem 

POCP
xAaron Nusstein Lantana

Scott Fradkin Flexion

Ronald Wampler CVS Health/Aetna

Linda Michaelsen Optum
xRick Lisseveld AEGIS


Minutes Approved as Presented 

x

This is to approve minutes via general consent. "You have received the minutes. Are there any corrections to the minutes? (pause) Hearing none, if there are no objections, the minutes are approved as printed."


Agenda Topics

Agenda Outline

Agenda Item

Meeting Minutes from Discussion

Decision Link (if not child)
ManagementHL7 Antitrust PolicyProfessional 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 Conducthttps://www.hl7.org/legal/code-of-conduct.cfm

Minutes Approval 

2023-01-12 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

MilestoneDate
Ballot VotingComplete
Ballot ReconciliationIn Progress
STU 1 PublicationQ1 2023

Agenda

January HL7 Working Group Meeting & Connectathon Debrief

JM: Aware of some testing of UDAP tiered OAuth - crosses with the Identity IG. Some additional groupings of tests, client, identity, security service. Was also used as part of a CARIN Connectathon last year. Met folks from ONC, AEGIS, Lantana in person - nice to reconnect with folks. 

AN: Tested $match piece. Brought Identity RI to the table and had some successful testing of invariant and scoring. Also connected with AEGIS Touchstone and identified some items to enhance. Good discussion around the invariants/weighting during one of the breakouts. It was really great to meet everyone. 

AN: During WGM, reviewed status of IG with Patient Administration and let them know we will be reviewing further with them over the next couple months. 

JM: On Sunday afternoon, members sat around the table and worked through some open issues with invariants. Added to the Zulip stream based on this discussion.

JL: Also there and was able to test with the identity RI. Set up a simple Postman script to test it. Eventually able to get the default test script in Touchstone for testing the $match and does predictive check to match the sample patient in the IG. That test is in Touchstone and available for anyone else who wants to test against it.  Reach out to Joe or Rita if you would like to get setup in Touchstone for testing. Also plan to share postman collection for identity testing and security/UDAP testing. 

RT: Advantage of meeting everyone in person was invaluable. Everyone did a wonderful job. 



Ballot Reconciliation

T Key Summary Assignee Reporter P Status Resolution Created Updated Due
Refresh

FHIR-37054 - Getting issue details... STATUS

  • DP: This really should be broken into 9 different tickets to support the process of review/disposition. 
  • Aaron will create separate tickets and reach back to Kevin with the ticket numbers by end of day tomorrow (1/27/23).
  • JM: Can we email him the links to the new tickets so he can review them in advance and perhaps comment in advance of the meeting. 

FHIR-40302 - Getting issue details... STATUS

  • This is a ticket that Julie recently submitted
  • JM: This is context that we can add to V2. If folks want to add this context now, we can consider. This came up because of feedback received about quesitons on how identity relates to matching. Julie suggested that we not worry about this for the current ballot.
  • No concerns raised by the group.
  • Aaron will mark the ticket "consider for future use"

FHIR-38801 - Getting issue details... STATUS and FHIR-38802 - Getting issue details... STATUS

  • JM: Tried to nudge Cooper for input. He hasn't requested in person so we can act on it without a response.
  • Crystal noted that both tickets were discussed on 10/20/22. Aaron will review meeting minutes from 10/20/22 where the tickets were previously discussed to draft proposed disposition and bring back to the group. 
  • RT: Noted that Cooper raised some related topics during the WGM as well. 
  • Aaron will do some research and bring back to the group.

FHIR-39349 - Getting issue details... STATUS

  • JM: Feel like we talked about this one and it was already closed out.
  • AN: I think we discussed something similar to this. 
  • JM: Any objective to inserting the words "email address and mobile number, except where otherwise noted." We have discussed value of email and mobile number as a differentiator. The last four of SSN and a verified email address or a mobile number are nice differentiators because people can share homeless shelters, apartment numbers, hospitals, etc. as last address of record. First/last name, DoB, and physical home address are not unique enough for identity resolution. Strengthening identity verification is expected to help matching where those attributes are considered important. 
  • DP: Makes sense. 
  • There is group consensus to insert this text. 
  • AN: Should it say "and/or"? 
  • RT: What if someone doesn't want to provide that much personally identifiable information?
  • DP: That's why it's a SHOULD. 
  • Ticket marked ready for vote

FHIR-39629 - Getting issue details... STATUS

  • JM: In a different group, was reminded about network requests, looking for medical records wherever they may exist, how should we consider places I've formally lived and if they should be included in match requests? Would we like for an identity service to be cognizant of timeframe and including former addresses in my verification and in match requests. 
  • DP: In TEFCA sense, you should be sending historic addresses. 
  • JM: What does that mean for our matching policies and identity verification practices as well? Could contemplate leaving to future version of IG; could add a note that considering networked query requests. May ask for identify verification services to verify multiple former addresses over given timeframe.
  • AN: For invariant/testing scenario, where matching would occur with multiple addresses, may be good to create an invariant for this, so may want to hold off until next version.
  • JM: Although our example may not, does invariant only allow for a single address? 
  • AN: I don't think it does - passing along the patient resource that you want to do the $match on. Assume the matching would occur on former addresses but would want to test it. Former addresses would probably be helpful.
  • PV: Matching in general is difficult to use period information or time scope; is it active, knowing if it's active, etc. Often times don't have a period. 
  • JS: Makes me think about how to drive toward patient identity with inaliable factors only. You are the same "James" no matter which address, phone number, etc. 
  • PV: On national population, if all you have is name, DoB, and gender, the probability of false matches is high. An address, phone number, email may tip it over and verify that you are not making a false match. These variables are used and important. 
  • JL: Is there any understanding that certain data sources are better/more faithful at populating those periods to figure into algorithm. 
  • PV: When you compute golden records, we definitely employ mechanism that says this system is given more weight than others. 
  • AN: What should we do with this ticket? Consider for future use?
  • VS: I would support that approach.

FHIR-37957 - Getting issue details... STATUS

  • Will add to the agenda for next meeting 
  • Patient Match Input Weighting is the title of the Zulip thread: https://chat.fhir.org/#narrow/stream/294750-FHIR-at-Scale-Taskforce-.28FAST.29.3A-Identity/topic/Patient.20Match.20Input.20Weighting
  • RL: Can you describe what you mean by term "invariant" -
  • DP: Invariant is a FHIR path imposed restriction
  • JM: We look to define these invariants so we have a computable way to validate match input requests being sent to them 
  • JM: We talked about trying to shape definition of a level 2 invariant and the attributes that would go into that. A lot of the feedback received in person at Connectathon - if this isn't required, what are the levels for? We've been designing these so they can be picked up and used without stating that they are explicit requirements for probabilistic and or individual access, perfect matches respectively. That's that's kind of what we've been shooting for is let's define levels that we think are suitable for probabilistic matches, and that a higher level that we think might be suitable for patient request matches. 
  • Aaron will change this ticket from a technical correction to a change request. 

Management

Next Meeting: February 2, 2023



Next Agenda



Adjournment
 Adjourned at 4:02 pm ET

Supporting Documents

Outline Reference

Supporting Document

Minutes Approval
$match input/outputZulip chat and Connectathon track
Meeting recording


Tasks

  •