Stream: FHIR at Scale Taskforce (FAST): Identity
Topic: How to establish attribute and identity level of assuran...
Julie Maas (Jul 21 2021 at 19:55):
FAST Identity's recommended solutions for patient matching contain requirements that matching attributes are validated prior to including them in a match request. Building out a workflow for this, at today's connectathon we had a lengthy discussion of where to begin when assembling attributes to include in a cross-organization patient match request. The two main conversation threads were: 1) Is there a level to the broader patient record that we can use? To synthesize this, we might add an Identifier to the Patient resource that has an associated identity level of assurance and find a way to indicate which attributes in the record may be considered at that level. (This might be very difficult to understand the meaning of, for existing health records, unless an identity level of assurance is maintained from the inception of a subject’s health record; perhaps "HIPAA" LoA is a baseline assumption for any health record today; TBD what that means about any given attribute in the record, though.) 2) Does identity assurance & attribute verification make sense only in the context of specific Encounters or other more discrete parts of the record? (As in the current SHC implementation, where the Immunization encounter includes a meta security tag for identity assurance level which informs identity assurance of name, DOB.) Certain Encounters (or other FHIR resources?) may be noteworthy as meriting inclusion of an identity level of assurance moreso than others. If an encounter can be like a “re-registration” or reset/identity "step up", a best practice might be to require that subsequent activity in the health record is at that same level of identity assurance. Some of the work to do will involve interpreting and managing identity assurance in a health record over time. Hoping @Reece Adamson , @Jeff Helman , @Brenda Chin, @Josh Mandel and others will weigh in on this question.
John Moehrke (Jul 22 2021 at 11:51):
@Julie Maas I am not clear what the question is.
I would say that data in application level encodings (e.g. FHIR Resources) is dependent on the policy/process/technology used to acquire that data. (e.g., the home address put in by someone just listening to the patient say their home address is less LOA, than an organization with policy and procedure that has the registration clerks as the only ones that can change the home address and they only change the address when they confirm the address given is on a federal or state issued identity card) (PS. I hope no one has either of those policies). The home address format here is not the question, the LOA comes from the policy and process.
In healthcare today, we have survived nicely with an implied high LOA simply because getting these personal identity details right is important to the business of healthcare (follow the $$$). as other parties are added to the conversation, the priority is not as well aligned so some other mechanism is needed.
Julie Maas (Jul 22 2021 at 20:32):
I made some edits that should help clarify the discussion topic, which is generally asking about preferences for how to assess whether patient attributes have been sufficiently verified for use in cross-organization matching. Using local metadata might help with this, and for the purpose of interoperability, something like the encounter-level identity assurance on Name and DOB as in the SHC IG is another option. For a relied upon IdP that is not tightly coupled to a responding FHIR server, a way to assert the verification status of any given user attributes (or assert for all attributes) is another sub-topic.
Julie Maas (Jul 24 2021 at 17:32):
Another facet to this topic that the connectathon attendees wanted to bring back here: what are the minimum attributes needed by a query responder to return a match? Given the necessary workflow variations in this, focus is on: a) TPO b) Individual Access as in TEFCA aka Individual Right of Access (Patient Directed or Direct-to-Patient) c) 3rd party access with HIPAA Authorization and d) access to Immunization resource (a subset of patient's record) or only what is in the SHC.
Josh Mandel (Jul 24 2021 at 17:38):
It strikes me that any fixed rules here are likely to be brittle. Like, if an "attribute" of first name doesn't "match", it's surely different in a case like "Josh vs. Joshua" compared with "Julie vs Joshua". Similarly if an attribute is missing but other attributes provide a high degree confidence, that could be fine.
Julie Maas (Jul 24 2021 at 17:47):
We had discussed during the connectathon the following attributes as candidates for minimum required in at least some of the identified workflows (see a,b,c,d in my previous comment) in this conversation; to facilitate conversation here, I'll list some of the suggested attributes each in its own comment and we can use emojis to poll for what should be required for that workflow; I'll ask one of our connectathon participants to vote in line with the discussion we had to show what I mean but suggesting: :hospital: for TPO, :man: for Individual, :office: for HIPAA Authorization, :take_off: for Immunization/SHC (on this last one comments about authorization may be helpful to this discussion also). Suggestions of additional attributes welcome. Note that for each attribute, verification has occurred so that each element is confirmed to be consistent with the individual who is subject of a transaction before including in a match request OR result.
Julie Maas (Jul 24 2021 at 17:48):
First Name
Julie Maas (Jul 24 2021 at 17:48):
Last Name
Julie Maas (Jul 24 2021 at 17:49):
Date of Birth
Julie Maas (Jul 24 2021 at 17:50):
Home address (validated per USPS or proxy for USPS format)
Julie Maas (Jul 24 2021 at 17:51):
SSN (should be optional; privacy preserving considerations; often present by default in ADTs) or last 4
Julie Maas (Jul 24 2021 at 17:51):
Gender
Julie Maas (Jul 24 2021 at 17:51):
Driver's License Number
Julie Maas (Jul 24 2021 at 17:51):
Insurance Member ID Number or Medicare Number
Julie Maas (Jul 24 2021 at 17:52):
Email address
Julie Maas (Jul 24 2021 at 17:52):
Mobile number
Julie Maas (Jul 24 2021 at 18:00):
Photo of individual
Julie Maas (Jul 24 2021 at 18:01):
Here are some additional attributes that have previously been suggested:
Julie Maas (Jul 24 2021 at 18:01):
Unique Identifier from an Assigner (or other enterprise identifier)
Julie Maas (Jul 24 2021 at 18:09):
Level of Identity Assurance of attributes that are included in the match request=IAL2
Julie Maas (Jul 24 2021 at 18:12):
Level of Authentication Assurance (likely only relevant to Patient Mediated exchange OR when federated identity is used in Patient Directed exchange)
Julie Maas (Jul 24 2021 at 18:15):
@Josh Mandel you raise an important point which will be relevant when we include considerations of responders, which is something the project intends to address . My hope is that those stakeholders will join this conversation so we can first hear from them on the question of what the request must include, and soon after that, we will work on the topic of responding.
John Moehrke (Jul 24 2021 at 18:20):
The element list is less important than the quality of the data in the element.
John Moehrke (Jul 24 2021 at 18:21):
https://sequoiaproject.org/resources/patient-matching/
Julie Maas (Jul 24 2021 at 18:23):
@John Moehrke thanks for reminding the group of that. You'll see it explicitly above "confirmed to be consistent with the individual who is subject of a transaction" though I'll admit we are not yet firm on whether that means: "consistent with a unique IAL2 identity" as per 800-63-3 and related identity management practices (the best practice per latest revision of FAST Identity Solution document) or otherwise. For example, matching on a patient to determine COVID vaccination status is one potential lower level identity assurance workflow.
Julie Maas (Jul 24 2021 at 18:29):
Level of Identity Assurance of attributes that are included in the match request=IAL1.4
Julie Maas (Jul 24 2021 at 18:30):
Level of Identity Assurance of attributes that are included in the match request=IAL1.2
Julie Maas (Jul 26 2021 at 17:22):
@John Moehrke I would also emphasize that the question at hand seeks to stratify attribute requirements (and whether they vary) for a few workflows which are a little different from today's typical B2B transactions. For example, what attributes, verified to be consistent with an IAL2 proofing event, would an IdP need to share with a health system to give confidence that a certain unique individual patient is the user behind an Individual Access request and allow release to this user of any of the health data about that patient that is stored by the health system? Likely the vaccination related workflow where more limited PHI is shared, has less stringent minimum attribute requirements. Both cases may recommend "all available data so verified" but writing up a few patterns helps participants know what to expect if what's "available" is going to be too little for the responder to have sufficient confidence in their match to release any health data.
Jeff Helman (Aug 04 2021 at 19:11):
In Carequality, CommonWell and eHealth Exchange workgroup conversations about how to make provider organizations comfortable with responding to Patient Access requests (re: ONC/CMS rules), the blocker has been less about identity assurance (rock-solid identity proofing is a given) but more about avoiding this scenario: "If providers accidentally give Patient B's data to Patient A, they get hit with HIPAA sanctions." If the angle here is to convince providers that higher LOA during the identity proofing process will make providers more comfortable, I can see that helping, but I sense that's an incremental solution that will not be perceived by providers as a way to avoid headline risk/HIPAA fines for inadvertent disclosure. I get that this is a bit of a chicken-or-egg conundrum, and maybe the only way to make progress is to pursue this path, but I'm wondering if we can incorporate feedback from those provider orgs so their perspective (and buy-in) can help us substantively move that needle.
Jeff Helman (Aug 04 2021 at 19:16):
For example: If XX% of provider ogs say that more data about how a set of attributes were validated by the requestor will compel them to take that risk, that list of attributes is where we focus our attention. @Julie Maas this may be exactly where you are headed here, and if so, I think it is essential that we get providers to weigh in (and buy in, via participation) as we create that list.
Julie Maas (Aug 04 2021 at 21:43):
Yes that's what I'm thinking. Providers, please do weigh in on which attributes are important and how their verification helps increase your confidence in returning match results for B2B and/or B2C workflows. I'm going to be updating the Identity scenario of our connectathon track in the next couple of days with some more specific attributes & level of verification for feedback at the September connectathon.
Julie Maas (Aug 04 2021 at 21:44):
As a step toward that track update, here's a straw man proposal for attributes & level of verification from the latest FAST Identity solution draft; discussion invited!:
B2B (e.g. TPO)
Required attributes: all known patient demographic attributes, however responders are not required to return a result unless, at minimum, a) {(First and Last) OR DOB, Unique Enterprise Identifier} or b) {First, Last, DOB, full (normalized as a best practice) street address, administrative gender and birth sex} is provided. Additionally, results are returned only when match confidence is certain for: patient care delivery, coverage determination, or billing/operations
Attribute verification: Verifiable patient attributes within a match request are consistent with the LoA-2 or greater identity verification procedures performed for the patient
B2C
Required attributes: all known patient demographic attributes, however responders are not required to return a result unless c) {First, Last, Interoperable Digital Identity Identifier} or d) {First, Last, DOB, Street Address, City, State} or e) {First, Last, DOB, Insurance Member ID} or f) {First, Last, DOB, (mobile number or email address)} is provided and match confidence is certain
Attribute verification: Verifiable patient attributes within a match request are consistent with IAL1.8 (2 Fairs--for example, two of: photo ID, medical record, insurance card OR a gov't issued photo ID + mobile number billed to the person) or greater identity verification procedures performed for the patient
Facial photo has also been discussed as potentially helpful in matching, when also verified to be consistent with patient identity verification (the submitted photo is verified to match with the patient in person or remotely with their ID).
Jeff Helman (Aug 05 2021 at 01:30):
+10 to the "Interoperable Digital Identity Identifier" concept for B2C. If we can all grok how to make that happen, patient matching becomes significantly more accurate and safe.
Josh Mandel (Aug 05 2021 at 02:34):
Love it. I'd also generalize mobile phone to (mobile phone or email)
Julie Maas (Aug 05 2021 at 14:45):
Thanks for initial feedback; I updated (f) as @Josh Mandel suggests; will also note that the use of email is consistent with FAST Identity conversations and other SME feedback. Was the suggestion also that email address has an explicit role in attribute verification (and if so, please elaborate, since it's not typically considered a Fair piece of evidence so want to hear if email address should potentially have a role as a second Fair or otherwise in a consumer healthcare setting) or was the suggestion only related to matching?
Josh Mandel (Aug 05 2021 at 15:27):
Useful property that SMS and email both have in common is that they are easy to independently verify; I'm not sure if this is relevant in your context but it certainly plays an important role in a lot of the consumer facing portals we are seeing for accessing vaccine information
John Moehrke (Aug 05 2021 at 16:12):
I agree. and they are equal at public knowledge and equal at spoofing. So, if you allow phone number, you should allow email address. I know many people that have no phone number, but do have email.
Julie Maas (Aug 05 2021 at 16:54):
@John Moehrke the important difference I am wanting to highlight is that there are services which can be used (or a copy of the mobile phone bill) to verify a mobile number as a financial account linked to a person's name and address, giving mobile number greater standing wrt 800-63-*. This is not the case with email addresses generally, with corporate email addresses that have first and last name or first initial and last name certainly being one special case I've seen called out wrt evidence used for identity verification. This is not to say that both mobile # and email aren't good for matching but mobile # may have some role in Identity Verification that email address might not. At least not without further guidance.
John Moehrke (Aug 05 2021 at 17:09):
excellent point. I just checked about a dozen of my statements with organizations that "do" have my email address, and often send me emails... None of them had my email address on their (billing) statements. I think that is really important fact for your use, but also a really poor reality. These businesses are using my email address more than my phone number. Would seem they should all have the email address they are using printed. How else might a customer know that their email address had been changed improperly. grrr
Julie Maas (Aug 05 2021 at 17:47):
And @John Moehrke I am referring to/the NIST requirement is for something like this: my bill from A&T wireless for my cellular service may be used as evidence of the mobile number as a financial account in an Identity Verification event, not to suggest that any arbitrary utility bill that happens to list a mobile number and/or email address along with my name and address "verifies" the association of that mobile number or email address to my identity. But if I'm reading your comment correctly, there may be something interesting to explore there, for new Attribute Verification (to distinguish from Identity Verification) guidance under consideration. 1) the possibility of going beyond utility bills and financial statements to other account types and/or 2) Verification of email address or mobile number that goes beyond verification of control or does not leverage the actual mobile account statement.
John Moehrke (Aug 05 2021 at 18:07):
that is an optimistic read... actually it felt more like me turning into Eeyore as I came to the realization that current-state-of-the-art has stuck with the poor solution of phone number, while the population has moved onto internet identities.
Julie Maas (Aug 05 2021 at 18:17):
PayPal will indicate an associated email address; that's something useful IMO.
John Moehrke (Aug 05 2021 at 18:18):
good.. but paypal is not a highly respected org. but the more we find these cases, the better
John Moehrke (Aug 05 2021 at 18:28):
Lyft receipts include your email
Julie Maas (Aug 05 2021 at 22:59):
OK, I've dropped what we have so far into the track page description for September. Please let me know if other attribute suggestions come to mind or requirements about verification thereof; do these B2B and B2C workflows include sufficient attributes to give health system stakeholders confidence about responding? If no, what else would help increase that confidence?
Julie Maas (Aug 05 2021 at 23:15):
Another B2C patient matching workflow that has come up at Security meetings with @John Moehrke is: g) {[patient authenticates as non-native Interoperable Digital Identity Identifier (for example, an OIDC account issued by a different health system than the responder)], [responder has previously or can in real time obtain patient's consent to release their data to that Digital Identity]}
John Moehrke (Aug 06 2021 at 11:59):
that seems to me to be the more generic methodology of taking an identity at a general identity provider, for which authentication practices are acceptable, but for which identity proofing is low assurance. In these cases an organization (relying party) could elevate their perspective of that identity through identity proofing of their own. Thus in context the identity that may not natively have high enough provisioning assurance is elevated AT that relying party. Example where the user uses google/facebook/etc OIDC; and may be using 2-factor auth; but at these OIDC there is no identity proofing. But at the hospital relying on that identity they do additional identity proofing, such as a postal-mail confirmation pathway.
It would seem the case you outline is just this generic method as applied to an OIDC hosted by another healthcare provider rather than google/facebook.
Julie Maas (Aug 06 2021 at 14:41):
John, what you describe is one way to use (g) but the workflow is intended to include a third party OIDC provider offering a healthcare-grade Interoperable Digital Identity (with some identity assurance) and the other included step of obtaining consent would hopefully provide confidence to the responder in answering a FHIR request for this authenticated user (I've told the responder that this Identifier is also me, their patient, in some other interaction, so we are abstracting away most everything except whether the responder trusts the third party OIDC provider's authentication). If the responder elects to also perform their own proofing of me, is another possibility as you suggest, but I'd like to pose as a question to providers: would such proofing also be necessary to be confident about responding to a B2C match request as in (g), given that the responder has (perhaps at one time when they were in the office or through a secure digital interaction) obtained consent from the patient to authorize access to their health data by their alternative Digital Identity? What characteristics of this third party OIDC provider are essential for the responder to trust it to authenticate a known patient Identifier they manage?
John Moehrke (Aug 06 2021 at 14:56):
worthy question. (I suspect transitory trust at this distance might be within the scope of NIST FAL, but might also be a step too far. The healthcare organizations tend to be very conservative, so I suspect they would say "no". Some other authority would have to tell the community of covered entities that they "can trust their peers". I suspect it is this trust federation mechanism that is missing. If a trust federation mechanism existed, then it could be relied upon).
Julie Maas (Aug 06 2021 at 15:08):
Right; and similar to FAL but with added PKI based trust component there is a grammar for interoperable identity in the FAST Security solution that uses UDAP Tiered OAuth. What characteristics of the IdPs are necessary to accept these peers as trustworthy is the essence of the question that remains about (g). Beyond that, the next question is: would providers further trust the User Profile from a third party IdP and respond to queries from that authenticated patient without explicit consent available (g)? In other words, matching on verified identity attributes as in (c).
This topic of third party IdP trust, which is a lot all on its own and likely involves more than attributes & their level of verification, is in a separate thread here.
Julie Maas (Aug 06 2021 at 23:13):
John Moehrke said:
The element list is less important than the quality of the data in the element.
Question to all: given in the comment above, is there more to require wrt attribute quality than is currently described in the B2B & B2C workflows above?
Julie Maas (Aug 10 2021 at 15:57):
I've added details from this conversation to the upcoming connectathon track in Scenario 6 a-f. Please lmk as questions arise, as we begin to work toward testing this 9/13-15.
Julie Maas (Aug 19 2021 at 17:29):
Additional related question from FAST Identity team:
Some HIE's implement a $match-like operation by simply looking for records that match the input, possibly by forwarding the request to the affiliated systems. This makes it difficult for $match to consider identities as opposed to records – an identity is a set of records that is partitioned together as being the same person. Other systems compute this partitioning as records arrive and satisfy $match by searching the identities, not simply the records. This allows for advance manual stewardship on the partitioning and more sophisticated matching concepts (identity-to-identity vs record-to-record). It also impacts the semantics of the $match parameter:
IN onlyCertainMatches 0..1 boolean -> If there are multiple potential matches, then the match should not return the results with this flag set to true. When false, the server may return multiple results with each result graded accordingly.
The problem is that a system that considers records only will often have multiple records that appear to strongly match the input and likely represent the same person, making it very hard to find a person when using this parameter.
Is an implementation of $match that does not partition the existing records into identities even consistent with $match semantics? Should such a system be considered counter to best practice?
John Moehrke (Aug 19 2021 at 19:45):
is there an example? Because I can't figure out what this means.
Julie Maas (Aug 19 2021 at 20:00):
I can try to reiterate. If a request is for only a high-confidence, single patient match (return one or nothing at all), disallowing multiple matches, but the responding organization has not eliminated duplicates or (as the question literally states) does not tie the 5 records that may relate to the subject to a single identity within their system, then the requester can't get any data because the responder is not permitted to return 5 distinct records when onlyCertainMatches=true and at most 1 result accepted in a $match request. The team is discussing whether no results being returned is appropriate, whether multiple records should be permitted (otherwise systems that are not identity-aware would not be able to participate in exchange requiring such a match), or what alternative actions the community deems acceptable in this scenario. Separate topic is the case where multiple systems are responding/broadcast query, in which case obvs max=1 result does not apply.
John Moehrke (Aug 20 2021 at 12:25):
so is it like this... that responding community does not have a MASTER PATIENT, they have multiple instances of Patient that are linked.
I think this is where the meaning of "single patient match" needs to be very clear. It does not mean "one Patient resource" or "one Patient identifier". It means (I assert) all the identies you return must be considered by YOU to be the same single patient. Which is how IHE defines it in PIX, you can return multiple identifier/id values; but they must all be considered by the responding system/organization/community to be the same patient (at this time).
see IHE specification on this kind of environment in FHIR -- https://profiles.ihe.net/ITI/PIXm/index.html
The drawback of this is that the client must then query against every one of these, thus some might really want "single patient match" to mean "one Patient identifier", because the client in that case wants to query the community only once. In this definition, the community you describe simply has to invent yet-another-identifier-for-this-patient and return that. There is an infinite number of numbers, so we are not going to run out of identifiers. But it places a burden on the community to have yet-another-identifier-for-this-patient. This is commonly refered to as a "Master Patient" or a "Golden Patient" --
see IHE has an implementation guide for how a community can cooperate to have a master patent registry. https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_PMIR.pdf
Julie Maas (Aug 22 2021 at 17:38):
So @John Moehrke my takeaway from your response is that in those IHE transactions any responding entity is obligated to curate its records so as to itself be certain that multiple matching patient records (assigned a common identifier, if only for the sake of that response) do, in fact, correspond to a single identity, else that responder must not participate in exchange, correct?
Julie Maas (Aug 22 2021 at 17:40):
More specific questions:
1-Should an exchange participant allow showing several candidates and let the provider determine the one?
2-Should an exchange participant reveal no PII unless there is only one good candidate? -- leaning toward that.
3-Should an exchange participant use knowledge-based techniques to obtain further information to resolve candidates?
John Moehrke (Aug 23 2021 at 12:07):
All those alternatives would be reasonable when the transaction is allowed to return multiple 'different' patients. The responding agent would need to be comfortable with the requesting system ability to handle multiple 'different' patients. There might be a community policy on how this must be handled, and those community policy choices might be one or more of those you provide. Are you looking for one policy at the national level? That does not seem logical to me. Situations at the requesting side might fit only one of those choices. The ultimate policy might be decided nationally, for a community, or for a transaction. I don't think that national policy is possible or the right thing to do. Transactional obligations are not technically defined yet, although they could be. Transactional promise might be possible with an attribute in the security token.
Richard Hornaday (Aug 23 2021 at 18:57):
One thing I was thinking we would cover that I am not seeing in this chain:
1) In a request for matched information, an expression/value in the request regarding:
a) whether the information will be automatically assessed (I think you are referring to this as B2B) or if the information will have the opportunity to have human-assessment (I think you are referring to this as B2C).
b) an expected threshold for match confidence. This implies there is a universal standard for confidence possibly, but the idea is to genericize the idea that some requestors have more/less stringent needs for match accuracy.
The idea would then be that instead of trying to map to some predefined set of profiles (payer, clinical, etc) that would inherently vary and also likely become outdated, we would have a generic framework for information request/exchange that could evolve more fluidly.
Richard Hornaday (Aug 23 2021 at 19:13):
@Julie Maas @John Moehrke
1) I like/prefer the concept that "single patient match" means that all the identities returned to a query are considered by the query recipient to be the same single patient.
2) I agree that we need to be concerned about providing PII until
a) the requestor has identified the matches that they consider to be "same patient" for their purposes with the caveat that
b) we need to assess if there is any sort of authorization aspects that need to be addressed. There may not be if one presumes that the requestor has authorization to get info for PatientX and that the responder views all returned information to be for PatientX.
Many of these scenarios are not simple request/response transactions, so this needs to be accommodated and both the requesting and responding systems will need to maintain interaction state information in order to keep all the secondary/tertiary/etc interactions correlated.
Julie Maas (Aug 23 2021 at 21:58):
@Richard Hornaday B2B with human-assisted matching might be a better way to characterize the difference you bring up - B2C is really intended to mean a patient's (or their delegate's) access to the patient's data one person at a time and B2C workflows may also incorporate either human-assisted or fully automated patient matching.
Julie Maas (Sep 03 2021 at 18:15):
@Richard Hornaday regarding your "generic framework for information request/exchange" suggestion above, in our discussions within FAST Identity to date we have discussed whether the attributes included in the request might be used along with what matches to determine a rubric for confidence. We have also explored a scoring system used by one EHR that places weights on each matching attribute. The level of identity assurance on the requesting side and responding side may also influence this rubric; is this the type of framework you are suggesting? Appreciate your thoughts...
Julie Maas (Sep 03 2021 at 18:37):
@Richard Hornaday this comment may need follow-up by the community: would you please be more specific about the cases where "both the requesting and responding systems will need to maintain interaction state information in order to keep all the secondary/tertiary/etc interactions correlated"? For example, what else besides the requester's identity would the responder be keeping track of (I believe with organizational identity we're referring to the client app's, i.e. the requesting organization's, digital certificate used to sign token requests as per FAST Security workflow)? In other words, whether automated or after human intervention, what other actions might occur between the B2B $match request and return of a bundle of matching patients being returned?
Julie Maas (Sep 09 2021 at 17:13):
Just a heads up that this project's first public meeting is coming up just under an hour from now. Details on the project page.
Julie Maas (Sep 14 2021 at 20:58):
Some notes from our discussion at Connectathon 28 today:
We went through FAST Identity work to date and how we arrived at the motivation to create a strong assurance Interoperable Digital Identity for patients, the second best scenario being that probabilistic matching attributes, in the best case, correspond to a unique human person and have been verified with a high level of assurance. This builds on recommendations from work we researched in 2018-2019, including "A Framework for Cross-Organizational Patient Identity Management" by Sequoia, RAND's "Defining and Evaluating Patient-Empowered Approaches to Improving Record Matching", and the GAO's "Approaches and Challenges to Electronically Matching Patients’ Records across Providers."
Level of link assurance - or match confidence - came up multiple times; there was interest from stakeholders in guidance for establishing match confidence in a reproducible way. For example, what constitutes a confidence of 0.2? 0.9? And at what level can data be released directly to a consumer user, as a Certain/Single High-threshold match?
Also discussed the necessity of knowing what level of assurance attributes have been verified at, either by community policy, in user profile info for introspection, or in an assertion object. (Is there a need to express as part of $match - i.e. in patient resource data?)
Participants raised that multiple results seem OK when an aggregator is providing results from multiple organizations, implying that 1-result per organization is expected for targeted queries. We would appreciate hearing from entities that are unable to manage FHIR results grouped by real world identity, since it is sounding like the community expects this.
The use of $match and profiling of interoperable $match for use across organizational boundaries was positively received as being capable of more than a search string. This topic includes additional background.
Identity verification was discussed at different levels 1) for the business authenticating to the transaction 2) for the consumer authenticating to the transaction, if any and 3) for attributes about the subject that are included in a match request. Generally #3 is the focus of the scenarios we're testing at this connectathon, though the special case of #2 comes up in Tiered OAuth and may be asserted by the business that is authenticating itself as in #1.
Specific to identity verification, we discussed IAL1.8 for patient access to their own data (2 Fairs--for example, two of: photo ID, medical record, insurance card OR a gov't issued photo ID + mobile number billed to the person). One stakeholder offered that they require IAL2 for patient access but that they have also discussed how an insurance card might be used.
Of the required, verified attribute combinations a-f that we've discussed previously in this topic, combo (d) was discussed as resonating with stakeholders -- {First, Last, DOB, Street Address, City, State} though instead of Address/City/State one participant noted they (Commonwell) require zip code plus self-asserted gender plus one of: {Street Address Line 1 OR email OR phone}.
There is interest in guidance being written about use of a minimum bar as well as a maximum bar of attributes provided in matching. For example, under what circumstances are elements like blood type relevant/permitted, or should there be a maximum set of permitted attributes? We have also discussed a similar topic in FAST Identity: use of biometrics and any best practices or uses that are not recommended? In both cases this topic has privacy considerations to be addressed.
We also heard from at least one stakeholder who does not operate a FHIR server but would like to benefit from the IG elements we are writing in guidance about.
The conversation today provided rich discussion & I welcome others to join us tomorrow from 1-3 Eastern, reply to pieces here as they interest you, or join in on our HL7 Workgroup meetings...
Julie Maas (Sep 16 2021 at 14:34):
Here are some notes from our breakout session on identity on 9/15. Welcoming discussion...
A rubric for cross-organizational confidence scoring, beyond internally-developed scoring practices, is something that would be helpful to interoperable identity and matching.
There is interest in indicating both a minimum bound and an upper bound on attributes submitted for matching. For example, certain biometrics and PHI are not appropriate or would not be used by responders and requesters should be sensitive to not send more information than makes sense in a match request.
We explored the question of whether responders should be required to organize patient records into unique identities before responding to match requests. Participants tended to agree that requiring this was good for patient safety and data quality, though we thought of at least one emergency use case where access to some information was probably better than to not receive data unless appropriately scrubbed. We're going to continue discussing this after digging deeper at our own organizations to come back and write up a best practice on this topic. Previous discussion in this thread pointed to this being an expectation of IHE-based matching interactions.
We also walked through the draft UDAP Multihop Protocol which provides clarifications on how UDAP DCR and JWT-Based Client Authentication are used with Authorization Assertion Objects for exchanges involving intermediaries. Participants found this draft helpful in explaining UDAP in this context so the UDAP Community will likely proceed with development of this profile. A link to this draft document will be posted soon.
We discussed the combined meeting earlier that day with the SMART Health Cards track to discuss how identity information within SHC at the encounter level, with an eye toward applications for other FHIR use cases. Next steps have not yet been planned but this topic was created for further discussion and includes notes from the call.
Mikael Rinnetmäki (Sep 17 2021 at 07:50):
Hi @Julie Maas, interesting to read, thanks for the summary!
Just a quick question: were the participants mainly from the U.S.? Was there any notion of areas of the world where there is a multi-purpose national person identifier and a strong authentication infrastructure backing that? I'm not saying verifying the identity would not need efforts where it currently is not verified properly. I'm more concerned over guidelines or requirements being imposed for actors who would not need them.
Julie Maas (Sep 17 2021 at 14:48):
@Mikael Rinnetmäki, thank you for making this point! Participants I know of were US-based, though we are aiming to be internationally-aware as this IG is written, and I think you bring up a great use case for the scenario where the verification has already been done and there is just a need for a grammar to convey it in health IT transactions that may span systems to which the identifier is non-native, in a consistent manner, if I am following you correctly (if not, please clarify...).
The team is aware that there are some excellent identifiers already in use outside the US today and it's my understanding we would seek to leverage those rather than add anything on where it's not needed.
Thank you for providing some context & I'd like to check back with you in a few weeks to see if you think the IG language achieves this, if that's OK? Also I encourage you to tag in this thread folks you may know from other nations who might share your concern or who might be willing to suggest elements that would help those without a national identifier (such as the US) design one that merits such interoperability & reciprocity.
Acknowledging your related point about identity verification for authentication to one's own data too....
Question for you: are you aware of a best practice document for patient matching (I guess it would just be called lookup if the identifier is nationwide) across facilities within Finland (or between countries) that you or others would point to as a reference we can add to our collection? For example, are matches just on the identifier permitted, or is some minimal demographic data required to prevent errors due to mis-typing of the identifier? Thanks again!
Mikael Rinnetmäki (Sep 18 2021 at 12:13):
Julie Maas said:
Thank you for providing some context & I'd like to check back with you in a few weeks to see if you think the IG language achieves this, if that's OK?
Perfect, thank you.
Also I encourage you to tag in this thread folks you may know from other nations who might share your concern or who might be willing to suggest elements that would help those without a national identifier (such as the US) design one that merits such interoperability & reciprocity.
Thanks, I'll keep that in mind, and can raise this in our next #nordics call. I would advise checking at least the eIDAS specification (https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation) which is an EU wide scheme, being adopted quite widely.
Question for you: are you aware of a best practice document for patient matching (I guess it would just be called lookup if the identifier is nationwide) across facilities within Finland (or between countries) that you or others would point to as a reference we can add to our collection? For example, are matches just on the identifier permitted, or is some minimal demographic data required to prevent errors due to mis-typing of the identifier? Thanks again!
I don't know of such a document, or any requirements for demographic data. The personal identifiers I know of have a checksum character included that protects against mis-typing well enough. For the Finnish national identifier see https://dvv.fi/en/personal-identity-code. Recently the debate has rather been whether the identifier itself exposes too much information. It is formed from the birth date and sex, and both are clearly readable from the identifier. The fact that these pieces are visible could be considered as additional protection against errors, but that point has not been raised in any of the discussions I've followed. Sex change is one of the pressing problems - if you change your sex, do you get a new identifier, and what happens to all the services where you have been registered with your old one...
Also, it's nowadays quite common that no-one types your identifier, rather it is read from a bar code of your social security card or drivers' license. Or even more commonly, you use an identification service on your mobile (provided by your bank or mobile operator, it's up to you to choose which service you want to use, they are interoperable), with two-factor authentication (you have the device with the app where you've signed in, and you confirm with a pin code or your fingerprint), and the identifier is transferred as a parameter from the identification service to the service requiring identification or authentication.
Julie Maas (Sep 22 2021 at 17:22):
Another conversation we are discussing - this from an email sent by a participant who is not on Zulip; I believe we have some older research on how attribute verification impacts matching but will leave this for others who have anecdotal information to share or who may have specific references to cite, or other comments about the questions posed below:
"I also share the concern that @Richard Hornaday brought up that we want to avoid going into security concerns if possible because it is simply too large a scope to take on. I think at most we want to address security where it overlaps with matching. Here's some thought on that overlap:
Suppose a person has a verified digital identity where he has shown that he possesses a given phone and email account.
Knowing that a phone and email have been verified might be very useful to matching. Specifically, such a phone is almost certainly an individual cell phone, as opposed to a group phone for the family or at the fire station where the person works. Such an email is more likely to be a personal email rather than the shared family email. Those properties would help you discern that these two records are for the same person despite their differences:
Simpson, Homer, 1992-02-23, 101 Springfield Lane APT 23, (412)2311456 (verified) homer@simpson.com (verified)
Simpson, Homey, 1992-05-23, 101 Springfield Lane, (412)2311456 homer@simpson.com
Without that extra information, it might be easy to conclude that these records might represent siblings or something.
On the other hand
Simpson, Bart, 1012-02-23 101 Springfield Lane APT 23, (412)2311456 homer@simpson.com
Still probably doesn't link with either Homer because of the generational difference in DOB and the propensity of using the father's phone and email for a child.
Moreover, if we had two verified identities
Bouvier, Marge, 1992-08-14, 3424 Duff Lane, (412)5513467 (verified), margyB@yahoo.com (verified)
Simpson, Marge, 1992-08-14, 101 Springfield Lane APT 23, (412)2525555 (verified) margyB@yahoo.com (verified)
Then we could be extra sure that these are the same person, despite the change of name, address and phone given that we have strong reason to believe that this is a personal email.
A particularly interesting case is when the information in one record, including verified contacts, and pseudo secrets like an SSN indicate that the person behind that record could have created a digital identity corresponding to the other record in the other system, based on what they proved for the first system. At that point, one might say the correspondence goes beyond "probabilistic matching".
But note that this is pretty wild speculation on my part – I haven't actually tried to incorporate such information in matching, I've never had that kind of information available and I haven't analyzed the statistics on how that should score. That's one reason why I've shied away from talking about Identity that much – I don't actually know how it affects matching. Does anybody?
Finally, I've collected some of the guidance points I've suggested earlier into a powerpoint, attached ."
Catherine Schulten (Sep 22 2021 at 17:46):
This topic appears to touch on the concept known as VECTORS OF TRUST. https://datatracker.ietf.org/doc/html/rfc8485
The idea is that you can express a very granular level of confidence about the identity of the individual and how that confidence came to be.
"The identity proofing dimension defines, overall, how strongly the
set of identity attributes have been verified and vetted. In other
words, this dimension describes how likely it is that a given digital
identity transaction corresponds to a particular (real-world)
identity subject. For example, did the user have to provide
documentation to a trusted party to prove their legal name and
address, or were they able to self-assert such values?
This dimension uses the "P" demarcator, such as "P0", "P1", etc.
Most definitions of identity proofing will have a natural ordering,
as more or less stringent proofing can be applied to an individual
being granted an account. In such cases, it is RECOMMENDED that a
digit be used for this component and that only a single value be
allowed to be communicated in a transaction."
Mikael Rinnetmäki (Sep 23 2021 at 07:02):
I would advise checking at least the eIDAS specification (https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation) which is an EU wide scheme, being adopted quite widely.
Regarding that, the self-sovereign identity (SSI) is yet another buzzword around this. See, for instance, https://vm.fi/-/suomi-ja-saksa-tiivistavat-digitaalisen-henkilollisyyden-kehittamiseen-liittyvaa-yhteistyota?languageId=en_US:
The purpose of the cooperation between Finland and Germany is to explore and drive the development of solutions based on self-sovereign identity (SSI) and to promote the related European legislation. SSI-based solutions, combined with digital wallets for exchanging personal data and other verified information, would make citizens better equipped to manage their own personal data and to exchange and verify various types of personal data and certificates using a smartphone or other electronic media.
Julie Maas (Sep 23 2021 at 14:55):
Thank you for sharing, @Mikael Rinnetmäki. We had been following identity efforts in Europe as part of the background research; this announcement yesterday sounds like an important step in their progress. It's important to be able to use these credentials not just in one's home country.
Julie Maas (Feb 23 2022 at 18:35):
After receiving more stakeholder input, an additional level 1.5 was added to the IG just now...appreciate any feedback!
Julie Maas (Mar 16 2022 at 23:27):
FAST ID has been exploring methods of tagging relevant demographic elements within the Patient resource parameter that is input to $match, to indicate attribute confidence/attribute verification status as part of the requestor's demographics that are included in their patient match request and potentially also in results returned by the responder. This is likely a "much later" topic for the IG to be addressed in a later version but wanted to restart discussion sooner rather than later. A few suggestions have been made for this:
1) Use VerificationResult in a manner similar to vhdir - this has rather coarse grained source information (please advise if I am overlooking something there),
2) use Encounter-specific meta security tags as in SMART Health Cards or use those tags at another level such as element by element or for the overall record (the latter means difficulty in knowing which address(es) and phone number(s) were verified),
3) extend each relevant demographic element with a new verification status and/or assurance level or evidence type code yet to be established, and
4) share (with permission) the actual evidence used for verification instead of or in addition to other metadata as in 1-3; potential use along with photo.
Questions: a) what information might be reliably captured as part of patient registration (e.g. what specific evidence used to verify one demographic element or some combination of them; what date was the verification performed; did verification confirm binding to the identity named in the record, or just confirm a street address or phone number is valid), and b) what such information would be helpful from the match requestor's and query responder's perspective in answering a match request or processing its results?
Julie Maas (Mar 18 2022 at 01:15):
A common starting point that often comes up is: the date some government-issued photo ID was used to confirm name and birth date. Are systems recording these ID numbers and the verification date today, such that that status could be reflected in a match request, to increase its confidence strength for a responder who is lookng to answer a B2B query?
Catherine Schulten (Mar 29 2022 at 14:31):
My org is in the process of putting together our requirements around identity assurance and the metadata that will be collected. Our proofing service will be recording the id numbers of government issued document along with the date/time stamp that the document was verified and that the facial image compare occured. The resulting IAL will be recorded and can be conveyed to a partner should it be requested and we have put in place an agreement to provide that value.
Julie Maas (Mar 29 2022 at 19:04):
Hi Catherine, what metadata (or actual archives) from the proofing event do you expect to share with the partner? Or in an effort to encourage conversation, what data would others like to see shared and how does that vary with the claimed assurance level?
Last updated: Apr 12 2022 at 19:14 UTC
