Stream: implementers
Topic: Logical Reference and non-uniqueness
Jose Costa Teixeira (May 04 2021 at 15:04):
Any expectations or good-to-knows about using a logical reference that is not unique?
e.g. a reference to a patient by EHR but there are 2 patient resources with same EHR number...
Vassil Peytchev (May 04 2021 at 15:30):
This is an error condition, and should be treated as such.
Morten Ernebjerg (May 05 2021 at 07:31):
The R4 specification of the Identifier type states that "The value SHALL be unique within the defined system and have a consistent meaning wherever it appears." That sounds to me like it would preclude using a business ID in an Identifier type if the ID may point to more than one entity. Or are there indications otherwise in the spec?
Jose Costa Teixeira (May 05 2021 at 07:38):
Right, so I guess this SHALL is not a conformance requirement, but it is a statement of a dependency. It means "if you want to do this, you must ensure somehow that the value is unique in the system".
Grahame Grieve (May 05 2021 at 07:56):
note that the sentence carefully does not say that the association between the object containing the ID and the ID itself is 1:1 such that the value is unique within any given collection of objects
Grahame Grieve (May 05 2021 at 07:57):
as long as the business id is unique within it's own system, with a consistent meaning, it may be found in lots of objects, sometimes with different kinds
Morten Ernebjerg (May 05 2021 at 08:28):
Just to clarify, I read the sentence as saying that you cannot use a (system, code-value)-tuple in Identifier if that tuple identifies more than one real life entity (e.g. multiple patients).
Rik Smithies (May 05 2021 at 09:04):
in practice, you may not know if things beyond your boundaries are unique and it is out of your control. Or this may start off as true, but later be false. It is fairly weak.
Grahame Grieve (May 05 2021 at 12:27):
if an identifier identifies more than one real world entity, I would think it's use is problematic, but it sill might be unique within the defined system and have a consistent meaning. Or it may be that the system is degenerate, and it should not be used
Morten Ernebjerg (May 05 2021 at 12:31):
Just realized I might be barking up the wrong tree :grimacing: @Jose Costa Teixeira, in your initial question with the two Patient resources with the same EHR number - would those two resources represent two different individuals or just be duplicate records for the same individual?
Jose Costa Teixeira (May 05 2021 at 12:40):
My question was a bit more basic, but I see further now.
My answer would be: the system can't guess if they are different patients or the same, right?
Jose Costa Teixeira (May 05 2021 at 12:41):
as Rik explains. It depends on the boundaries and may change
Lloyd McKenzie (May 05 2021 at 15:59):
Simple real-world example. You have a U.S. social security number. There's a standard system for it. Within that system, each social security number is supposed to refer to exactly one person. However, that identifier can appear on a variety of Patient, Practitioner and RelatedPerson resources in a variety of systems. Also, due to fraud, error, etc. the same social security number may appear on records for individuals who aren't all the same human being. That would still meet the expectations of the wording of the "SHALL be unique within the defined system and have a consistent meaning".
Ezequiel Morales (May 05 2021 at 20:59):
"within the defined system" seems to be the key concept here
Debbie Bucci (May 11 2021 at 14:39):
Newbie question -kind of ... Looking at using identifiers to help with potential matches in target system. Assume "business" identifiers MAY be sent but not required and perhaps done so for privacy reason but ... beyond full blown PIX like functionality - is there a simple way to request known identifiers up front? This looks like the closest thread to ask
David Pyke (May 11 2021 at 14:43):
If you request a Patient resource, it SHOULD give you all the information you're allowed to see, so you shouldn't have to specify what you're looking for. That being said, if you need to set up specific requirements, you can profile Patient to force the use of specific information
Debbie Bucci (May 11 2021 at 15:44):
So you are suggesting negotiate with trading partner not something that can be requested in code beyond knowing specifics about the sourceIdentifier you may be looking for ?
David Pyke (May 11 2021 at 15:59):
Correct. They should be sending you all available information but if that's not the case, then you have to open a dialogue with them and see how to correct it.
Elliot Silver (May 11 2021 at 16:19):
IHE has also defined the PIXm profile which defines an operation that provides alternate patient identifiers only for a given identifier, without returning the entire patient resource. The argument at the time it was developed was that access to the rest of a Patient resource may have different permissions. (https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_PIXm.pdf; I think there's an informal FHIR IG equivalent)
Debbie Bucci (May 11 2021 at 16:29):
yes I've been studying that ... its seems to be a layer above the existing pix backend messaging. Something definitely to consider but if we could resolve other ways ...
Debbie Bucci (May 11 2021 at 16:50):
will search for the informal FHIR IG ..
Mahesh Chiliveri (May 11 2021 at 19:16):
Hi Everyone, We have requirement to test against these guidelines "HL7 CARIN BB, DaVinci PDEX, PlanNet & Formulary guidelines" , Do you know how can i get the inferno community addition deployed on my local firewall inside docker to have validator up and running and test against these guidelines.
Robert Scanlon (May 11 2021 at 19:17):
Hi @Mahesh Chiliveri -- could you ask this question over in #inferno?
John Moehrke (May 12 2021 at 19:18):
Informal draft, not approved, warning warning ..... IHE-PIXm in IG form http://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/index.html
Debbie Bucci (May 12 2021 at 21:06):
So the informal draft essentially points back to the IHE draft. Assume the The goal is to have th3 $ihe-pix be a base operation that FHIR servers MAY support this like $merge? In theory it could be an extended operation for testing if partners willing to support?
Ruth berge (Mar 22 2022 at 14:57):
for an Identifier 2.24..0.12 type... I understand this to mean that a fhir repository should not store identifiers that are not unique for that resource - though it seems that properties such as a period could also make them unique (but harder to search against). If that is true, then an implementation guide like the DaVinci ATR that specifies a tax id to identify a group is either assuming that this identifier will only ever by used in one group or is breaking the rules. I asked in the Da Vinci ATR in January and the answer did not address my question so I'm bringing it up here. I see it as an issue if a given provider organization belongs to two contract groups and is compliant with ATR da Vinci that the repository would then have two fhir groups with the same tax id identifier and npi identifier. I may be misreading something in ATR but I want to make sure that this question is raised and answered here in the broader community. I would appreciate a better understanding of the wording in Da Vinci ATR. Again I did ask in that thread in January but the response doesn't address my question and I asked again but no further response.
Lloyd McKenzie (Mar 22 2022 at 17:17):
FHIR's "uniqueness" requirement is a SHOULD. There'll be lots of situations where a given identifier might not be unique.
Lloyd McKenzie (Mar 22 2022 at 17:19):
There is an expectation that a fully populated identifier (i.e. system + value) corresponds to only one business object. I.e. there aren't two completely different organizations that have the same tax id. However, the same 'business object' might well surface in multiple resource instances on the same server. And sometimes errors or fraud happens where an identifier ends up on a resource it shouldn't.
Ruth berge (Mar 22 2022 at 20:57):
What is the expectation for people building profiles and igs? Do we expect that they would build these profiles such that SHOULD will not be violated by design?
John Moehrke (Mar 22 2022 at 20:59):
no specification ever existed that can keep people from doing stupid things... however claims of compliance are claims of compliance to ALL normative requirements, and claims of compliance are enforceable by either certification testing or contract terms.
Lloyd McKenzie (Mar 22 2022 at 22:11):
People building profiles and IGs have limited power to change the real world. In most systems, there SHOULD only be one patient record with a particular U.S. SSN. However, there are situations where that gets violated: fraud, old records brought over from a merged system; partitioned demographics between the hospital and the family medicine unit; [insert your reason here].
FHIR doesn't impose business rules. It's up to systems to do that based on what works (and is necessary) in their context. You'll absolutely find systems that will fail a POST that would duplicate an SSN and even enforce that down at the database level. There will be other systems where 2 or 3 hits on a single SSN is typical. Both types of systems can be fully FHIR conformant.
Ruth berge (Mar 23 2022 at 15:42):
Agreed that people building igs and profiles can't change the real world and they shouldn't. Their design should handle the real world situations and their designs and documentation should illuminate when they have enforced something that isn't recommended. In the ATR case, they chose to use identifiers that will be reused. But back to identifier, Lloyd you use the verb SHOULD in relation to the identifier. Is there someplace in the FHIR documentation that uses that (since "SHOULD" is meaningful in FHIR)? The identifier type , comparison with HL7 v2 conformance- neither of these say that. I would appreciate if you share the reference. Maybe its just the interpretation of what an identifier is and what it means? It helps to see where these references are for other issues. Maybe there should be something in identifier type that addresses this?
John Moehrke (Mar 23 2022 at 15:49):
the FHIR core specification is not the right place for SHOULD language. There are many use-cases of the resources in FHIR core that are not the clinical-treatment; for which the FHIR core needs to be able to support. So FHIR core focuses only on SHALL (minimal cardinality of 1), and MAY (minimal cardinality of 0). Should comes in during an Implementation Guide, which has a specific (set of) use-case(s), and setting.. thus can explain what Should means and when Should is allowed to be not.
Lloyd McKenzie (Mar 23 2022 at 16:35):
SHOULD establishes what's desirable/ideal/best practice. It's something to think about during design. But it's not enforced/enforceable.
Gino Canessa (Mar 23 2022 at 18:39):
Otherwise stated: the difference between MAY and SHOULD is entirely conceptual =)
John Moehrke (Mar 23 2022 at 20:20):
the difference between MAY and SHOULD is well defined in the IETF standard on normative words upon which FHIR is based -- https://www.ietf.org/rfc/rfc2119.txt
John Moehrke (Mar 23 2022 at 20:21):
https://www.hl7.org/fhir/conformance-rules.html
Gino Canessa (Mar 23 2022 at 20:40):
Sure - but from a 'practical use' standpoint developers have to handle both cases (e.g., present and not present).
During any given individual test/use, it could be either way and there is no realistic way to determine the difference.
John Moehrke (Mar 23 2022 at 20:57):
we don't have a mechanism in conformance resources (e.g. StructureDefinition) to differentiate between SHOULD and MAY... correct. But there is a difference.
John Moehrke (Mar 23 2022 at 20:59):
although SHOULD is often conditional, so invariants are one way to express those SHOULDs.
Gino Canessa (Mar 24 2022 at 14:14):
Perhaps I was a bit too loose in my language when talking about conformance language =)
That said, I do know the difference between the terms. From the point of view of someone consuming the specifications, having delineation between (loosely ;-) "do this if you want to" and "well-behaved systems are expected to do this" is important. To me, having the ability to use either in the core specification makes sense.
But practically, that boils down to a conceptual difference - well-behaved systems will need to handle either case gracefully. I am against adding rules/testing around those terms because I am not convinced we do not have the ability to do so reliably. Having invariants that often fail 'correctly' teaches people to ignore them, and I would prefer to discourage using 'SHOULD' as a replacement for conditional 'SHALL'.
(as a random note, we added an RFC filter (e.g., RFC2119) to the regex so you don't have to type out URLs a while back - I think this is even the one that annoyed me enough to ask for it)
Last updated: Apr 12 2022 at 19:14 UTC
