Chair: Mohammad JafariJulie Maas, Ranjan Saxena, Aaron Nusstein 

Scribe: Crystal Kallem 

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

Ranjan Saxena Humana

Mohammad Jafari 


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

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

Michael Golden

David DeRoode Lantana

Elevance Health

Gail HodgesOpenID Foundation


Smile CDR
xJoseph ShookSurescripts

Peter Muir 

Deborah Bucci 

Elevance Health

Jason Vogt CommonWell/ MEDITECH

xAaron Nusstein Lantana

Scott Fradkin Flexion

Ronald Wampler CVS Health/Aetna

Linda Michaelsen Optum
xRick Lisseveld AEGIS

Mark NeumuthAetna

Chelsea ArnoneCHIME

Kevin GeminiucKaiser

Stephan BaurKaiser

Kathiravan PeriasamyAvaility

Mari SavickisCHIME

Luis MaasEMR Direct

Adam PhillipsLantana

Janice HsiehAetna

Jeff TaylorSurescripts

Durwin DayHCSC

Chris JohnsonBCBSAL

Sheryl Turney

Nehal ACVS

Christopher MuirONC
xPete Hermann
xAlec LawsIdentos
xElizabeth SpanglerWestat
xJames CarterIdentos
xSam DikemanNystec
xMaidul Islam

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

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-09-21 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:

STU2 Planning:

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
        • B2B-IAL1.5
        • B2C - IAL1.8
      • 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.


Upcoming Calls and Topics

  • October 19th at 2:00 PM ET - Splitting out concepts of patient and user (proxy user)
  • November 2nd at 2:00 PM ET - Linking parent to child identifier
  • November 16th at 2:00 PM ET - Recap of patient and user concepts and linking parent to child (documentation review

Chat Comments

13:02:17 From Crystal Kallem (POCP / FAST PMO) To Everyone:
    Today's Agenda:
13:15:08 From David Pyke (Audacious Inquiry) To Everyone:
    Cooper Thompson has a workup that shows provenance and a needed extension 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:

 Adjourned at 3:02 PM ET

Supporting Documents

Outline Reference

Supporting Document

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