Stream: argonaut
Topic: universal read/write IRL
Eric Haas (Feb 04 2021 at 19:21):
@Josh Lamb asked
Thanks, I am mostly interested in ANY resource that has "universal" read/write.
Brendan Keeler (Feb 05 2021 at 05:19):
Huh? None do today
Josh Lamb (Feb 05 2021 at 18:54):
It's important that consumers can add the "identity proofed" value of their choice (some certification standard needed), regardless of the EHR used. This will enable a consumer to participate in linking systems together. My instinct is that this is a great PE usecase.
Josh Lamb (Feb 05 2021 at 18:56):
Data producers can assist in this process by agreeing to use open access identifiers. Both use cases can follow same IG.
David Pyke (Feb 05 2021 at 18:58):
Most Hospitals, etc. Identity proof as part of the EHR remote access enrollment
Josh Lamb (Feb 05 2021 at 19:00):
Yes, this is a good opportunity to create an open id.
Josh Lamb (Feb 05 2021 at 19:49):
I would also like for EHRs to begin capturing health plan member identifiers in a predictable way. There are several viable options. This will be key for uniform access across healthcare nodes. Currently there will be an organizational OID, that the organizations create. This makes it difficult to predict what the identifier system will be.
Lloyd McKenzie (Feb 05 2021 at 19:51):
I think the issue there is for insurers to expose health plan member identifiers in a predictable way. In my experience, every member 'card' exposes the information differently and sometimes uses different names for what turns out to be the same information.
Lloyd McKenzie (Feb 05 2021 at 19:52):
If there was an easy way to look at the card and easily capture the information in a way that allowed it to be used as a globally unique identifier, that would be wonderful.
Josh Lamb (Feb 05 2021 at 19:52):
@Lloyd McKenzie thanks, there is another initiative led by Humana to create a virtual id card. I think this could be a great input into the "add a user id" endpoint. we will follow wedi standards and can ID proof via our portals (and trust relationships). but as I think through this some more I think a simple post of a key value pair is enough..
Lloyd McKenzie (Feb 05 2021 at 19:53):
"we" =?
Josh Lamb (Feb 05 2021 at 19:54):
fixed, when i was in school I was taught to use inclusive language. Sometimes it creates the wrong impression.
Josh Lamb (Feb 05 2021 at 19:57):
So @Lloyd McKenzie do you think education about how ids are submitted when using X12 may help? @Cloud Cray if you know this one.
Cooper Thompson (Feb 05 2021 at 21:00):
Josh Lamb said:
I would also like for EHRs to begin capturing health plan member identifiers in a predictable way.
Not all organizations use their EHR for registration. Many organizations use an EHR for clinical documentation, but have a separate system for registration and billing. Typically the reg/billing system will know the member identifiers. The clinical EHR system may not.
Lloyd McKenzie (Feb 05 2021 at 21:00):
That's not necessarily going to help if patients are trying to provide their ids. Admissions clerks eventually get to recognize the patterns and figure out where to put stuff, but patients would presumably have much less of a clue. Also, member ids don't act as proper FHIR ids because they're not globally unique. For proper FHIR (or CDA) identifiers, you have two elements - a root which is a URI (or OID for CDA) which humans generally never see and a 'value' which is a single identifier string that humans do see. If an id has multiple parts, all must be expressed in that one string and expressed consistently in every usage. RIght now, Da Vinci has a special operation where you pass in all of the card information to the target payer and it comes back and tells you its "unique member identifier" for that patient. That's not necessarily even something that appears on the card.
Josh Lamb (Feb 05 2021 at 23:50):
To your point @Lloyd McKenzie patients created IDs will need guardrails. We cannot let people misuse the system with a weak ID or claim ownership of an ID that is not identity proofed. The creation of an id (and allowing someone to create an ID) requires trust. A HIPAA covered entity (US Realm) will have this status.
Regarding endpoint awareness, a payer should be able to determine via claims history where claims have been submitted (NPI/tin-> trust directory-> fhir endpoint). This is important because this allows us to avoid the negotiation process we see with a single patient launch sequence (by taking advantage of HIPAA status and a requirement to trust that a request has been proofed and authorized, prior to being created). It is the requester that is responsible for ID proofing, not the fulfiller.
Josh Lamb (Feb 05 2021 at 23:54):
It is important that we can push IDs because if we over-rely upon a member ID (a weak id), it could cause security vulnerabilities.
Lloyd McKenzie (Feb 06 2021 at 00:01):
I don't think we can expect systems to support patient-generated ids at all. If we're going to standardize something, it should be something the EHRs already store - like insurance ids. Expecting them to store patient-generated ids doesn't sound like something they'd already have capability for and there's a long line of "essential new features" that would probably be ahead of this one.
Josh Lamb (Feb 06 2021 at 00:02):
The patient does not generate the id, good point. It's federated.
Josh Lamb (Feb 06 2021 at 00:02):
So HIPAA (us realm) entity can push federated IDs.
Lloyd McKenzie (Feb 06 2021 at 00:02):
Is it something that EHRs already do?
Lloyd McKenzie (Feb 06 2021 at 00:03):
I.e. there's a database slot and an ability to render via their UI, etc.?
Josh Lamb (Feb 06 2021 at 00:04):
This exists but not universally (VA has a federated ID you can buy and CARIN mentioned a PASS ID).
Josh Lamb (Feb 06 2021 at 00:04):
If an EHR or portal wants to integrate, they can.
Josh Lamb (Feb 06 2021 at 23:29):
(deleted) meant for another thread
Josh Lamb (Feb 07 2021 at 21:37):
For efficiency sake, what is the easiest way to enable search across multiple patient identifiers?
In today's world you will search like this normally (using scoped FHIR patient id): GET base/Condition?Patient=Patient/123
How can I search for conditions, for a patient, that may have multiple "sovereign" identifiers? I saw discussions about this before (I believe we were playing with a list in the smart token payload, which I like!).
This will prevent duplication of data in the receiving system and reduce the number of duplicate calls to a source.
Josh Mandel (Feb 07 2021 at 22:55):
As far as the FHIR API is concerned, you can query for Condition?patient.identifier=https://system.example.org|123. There are some major drawbacks here though:
- Not every system you talk to is necessarily going to have the identifiers you need
- Not every system you talk to is going to support this kind of "chained" searching (it tends to be much more resource-intensive than matching on a "simple" indexed search param)
- The "extra" work of resolving an identifier would need to be re-spent on each query
A more pragmatic approach would be to:
- Resolve the patient so you learn the remote-system-specific FHIR id (e.g., by calling
$matchor doing a search against Patients) - On subsequent queries, use this remote-system-specific FHIR id directly
Josh Lamb (Feb 07 2021 at 23:00):
Thanks @Josh Mandel , I will put together a few alternatives and will look forward to more feedback.
Josh Lamb (Feb 07 2021 at 23:04):
If we can coordinate identifiers between X12 submissions and what is exposed through the EHRs (and coordinate search against US Core standards and requirements) we should be able to address a few of the bullets you listed.
Josh Lamb (Feb 07 2021 at 23:31):
I like your suggestion better @Josh Mandel . This does not require changes from the EHRs.
Josh Lamb (Feb 07 2021 at 23:51):
This output could be significant and a bulk operation may be needed (especially given the negotiation process highlighted above).
Last updated: Apr 12 2022 at 19:14 UTC
