Chair:  Julie Maas , Carmen Smiley , Aaron Nusstein 

Scribe: Dana Marcelonis 

Meeting Schedule

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

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. 





xJulie MaasEMR Direct

Vijey Kris SridharanUHC

Catherine SchultenChange Healthcare

Robin Poirier Ready Computing


Rick FrenchAllscripts

Priti DaveSafe Identity

John McCoyAllscripts

Jeff Brown Lantana

MA Health Data Consortium



Velvet Hanes-RitchieAllscripts

Jim StClair Interoperability Institute

Steven Hoffer

Paul VaughanOptum

Richard Hornaday Allscripts
xRita TorkzadehAEGIS

Tammy FowlerAllscripts

Nick Radov UHC

Liz BuckleCommonWell

Jaime Smith

Alex Kontur ONC

Olivia Bellamou-Huet Philips

Charles Ye 

Smile Digital Health

Brian Pech 

Ryan Howells CARIN, Leavitt Partners

Alberto S. Llanes FEHRM

Josh Mandel 

Independent Health
xAudacious Inquiry

Kimberly TaverniaONC

John RancourtONC

Liz Palena Hall

Rachel E. Foerster Rachel Foerster & Associates

Chandrakant Bhonsle 



Sequoia Project


Gary WordAvaneer Health

Marc Mar-YohanaOtis Health


Michelle DurbinAltera

Liz TuriONC

Napoleon RussMITRE

Michael Golden

David DeRoode Lantana

Elevance Health

Gail HodgesOpenID Foundation

xSmile CDR
xJoseph ShookSurescripts

Peter Muir 

Deborah Bucci 

Stephanie Murphy POCP

Elevance Health

Jason Vogt CommonWell/ MEDITECH

xAaron Nusstein Lantana

Scott Fradkin Flexion
xRonald Wampler CVS Health/Aetna

Linda Michaelsen Optum

Rick Lisseveld AEGIS
xMark NeumuthAetna
xChelsea Arnone
xKevin GeminiucKaiser
xStephan BaurKaiser

Minutes Approved as Presented 


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 Conduct

Minutes Approval 

2023-01-26 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:


May 2022 Ballot Cycle

Ballot VotingComplete
Ballot ReconciliationIn Progress
STU 1 PublicationQ1 2023


Ballot Reconciliation

T Key Summary Assignee Reporter P Status Resolution Created Updated Due

FHIR-37957 - Getting issue details... STATUS

  • JM: thought about how we could adjust the existing weights to arrive at a 10 if we were to have the combination of three items in the 3-5 row of the screen shot (in the Zulip thread). May want to reduce the weight of address so that you have to have first/last name, DoB and two other items from the middle category.  
  • Will modify to explicitly call out that last four SSN should be included in that category. 
    • From Julie Maas to Everyone at 13:13: so expand to say "for example, Digital Identifier, last 4 of SSN, OR Insurance..."
  • JM: Also discussed combining these values into a level 2 invariant profile totaling 20 (a total of 10 nominally but if doubling, 20 due to attributes being verified). 
  • Ticket marked ready for vote

Kevin Geminuic and Stephan Baur joined the call to discuss FHIR-37054 - Getting issue details... STATUS . This ticket was divided into nine different issue tickets to facilitate discussion. Kevin noted that they are also working on CARIN IG implementing some of these components.

FHIR-40347 - Getting issue details... STATUS

  • AN: Doing some significant updates to Section 1.3 which he displayed. 
  • KG: Like the expanded narrative. Re: Use cases TEFCA - is this going to be aligned with TEFCA or is this standalone. Understood that TEFCA moving away from CCDAs. 
  • KG: Is this IG going to be used for TEFCA or is TEFCA going to use their own flavor? 
  • DP: TEFCA reviews FHIR IGs for consideration and use them where they can. 
  • KG: Just want to be sure that the TEFCA use case is considered. It sounds like they review it and that's the extent. Now that we understand that, feel it's sufficient. 
  • SB: Is the Facilitated FHIR IG related here? 
  • JM: Was derived from Security IG and UDAP dovetails with this work. Our work is not intended to be inconsistent with UDAP Security IG. 
  • This ticket has been marked duplicate of an existing ticket that addresses the concern. 

FHIR-40348 - Getting issue details... STATUS

  • This ticket has been marked duplicate of an existing ticket that addresses the concern (updates to section 1.3).

FHIR-40349 - Getting issue details... STATUS

  • KG: The various levels identified in the spec, do you see ONC standardizing on the levels? 
  • JM: UDAP publishes those levels and live on page. My understanding it would be up to NIST to take up normal levels 
  • This ticket contains a related question and was addressed through discussion on the call. 

FHIR-40350 - Getting issue details... STATUS

  • AN: The specific terms are not used in the IG. If added, would need to create sections to define the different credential types.
  • JM: In this comment, feel we are getting into authentication methods which aren't in our current scope. Where we mention credential, it's a digital identity that is able to be validated but we don't deal with this. Do you think we need more clarification.
  • KG: Perhaps in the front matter, what we mean by credential going forward in the document. 
  • SB: There is often confusion about CSP issues. Might be helpful for these advanced digital identity concepts to define in the text. 
  • JM: Do you have a working definition.
  • SB: If you search for credential and context where it's used, we thought it meant password. Felt it was a bit of inconsistency there. 
    • From Kevin Geminiuc to Everyone at 13:38: Source(s): NIST SP 1800-17c under Credential. An object or data structure that authoritatively binds an identity, via an identifier or identifiers, and (optionally) additional attributes, to at least one authenticator possessed and controlled by a subscriber.
    • From Julie Maas to Everyone at 13:31: That seems fine to me
  • KG: Not sure there are inconsistencies with the definition, but would be helpful to include. 
  • RT: If not specifying authentication, it relies on UDAP and some aspects of those things?
  • AN: That was my other question, if we want to reference UDAP IG and/or take this and put into the glossary. 
  • KG: I'm ok with that. 
  • JM: If we are able to find a generic definition other than that reference, is that ok? 
  • KG: Yes, that's fine. 
    • From Julie Maas to Everyone at 13:46: This is the definition from 63-3 that we should use (please respond if any concerns): An object or data structure that authoritatively binds an identity - via an identifier or identifiers - and (optionally) additional attributes, to at least one authenticator possessed and controlled by a subscriber. While common usage often assumes that the subscriber maintains the credential, these guidelines also use the term to refer to electronic records maintained by the CSP that establish binding between the subscriber’s authenticator(s) and identity. Source(s): NIST SP 800-63-3 under Credential as per:,by%20a%20cardholder%20or%20subscriber.
  • Ticket marked ready for vote

FHIR-40351 - Getting issue details... STATUS

  • KG: There was threshold in one of the tables - 
  • AN: Scoring of the match and weighting of $match submission. The patient weighted input is more aligned with guidelines. 
  • KG: The TBD reference - these would potentially go into a repository, right? Would this be changed in the future or no weighting on those elements? 
  • AN: For now, yes. Ultimately hoping to obtain feedback from implementers to create a more useful/enhanced table in the future. 
  • KG: Is insurance member identifier equivalent to medical record number? 
  • JM: For your purposes, the numbers may be the same. 
  • KG: Will there be a weighting threshold recommended for a match. When people pulling records from Kaiser, if they are defining thresholds for us and we know the data quality of ours, it would be hard for us to control if good match or not. Could be implications for us. 
  • DP: We can't dictate the quality of data points in your implementation. 
  • KG: Would be helpful to call that out in the spec, that organizations can control that. Would like to see a disposition that enhances the text to say "Organizations would control their data quality matching algorithm." 
  • JM: I think we have a note above section 4.3 - we have attempted to keep algorithms out of scope. The reasons these scorings some info consideration, we wanted to publish an outwardly way to compute a score so that a score could be passed back. 
  • KG: This is very helpful for us. 
  • SB: Didn't other provider organizations request that patient ID numbers be included? In Kaiser's case, I would want to see the patient identifier (e.g., MRN).
  • JM: We had some discussion about this; it's not something we can condition return of records. 
    • From Carmen Smiley to Everyone at 13:51: we have heard that medical record numbers are not often useful between systems
  • KG: I think we are good, we can move on. 
  • JM: I do think identifier you are mention is included in that third line. A medical record number would qualify. 
    • From Carmen Smiley to Everyone at 13:51: +1 Julie
  • This ticket marked as duplicate

FHIR-40353 - Getting issue details... STATUS

  • KG: Maybe the FHIR spec covers this with FHIR IDs. It's an optimization we typically look for.
  • JM: We have discussed this workflow. If you return a resources that includes local identifier and requesting system can kick that up and use it later? 
  • KG: Yes, just wondering if we could add reference to that result. Sometimes its implied but not called out all the time. If possible to link back to FHIR query spec that there is possibility of probabilistic match for a period of time.
  • JM: Is there a specific section you have in mind from FHIR search? 
  • KG: I would have to go look for it but if there is something there, I would like to refer to it from here. 
  • Kevin will find the link and send to Aaron after the call.
  • Ticket marked ready for vote

FHIR-40354 - Getting issue details... STATUS  

  • There was a comment in the ticket with some starter text from Julie.
  • JM: This language aims to capture practices in place where certificates are issued for care quality and direct messaging purposes. 
  • SB: If there is a reference that can be made to organizational entities and issuing credentials/certificates.
  • JM: The items mentioned stem from Direct Trust entities. Is that helpful? The suggested text reiterates the spirit of this. Add to the end "as per" and the reference the Direct Trust Certificate Policy. 
  • KG: That's acceptable. 

Aaron will email Kevin and Stephan to work through final resolution of the last ticket. He will report back to the group during the standing meeting in two weeks. 


Next Meeting: February 16, 2023

Next Agenda

 Adjourned at 3:03 PM ET

Supporting Documents

Outline Reference

Supporting Document

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