FHIR Chat · Resources and Identifiers · methodology

Stream: methodology

Topic: Resources and Identifiers

---

Grahame Grieve (Dec 19 2019 at 21:18):

There's this kind of permathread to the question of resources having identifiers

Grahame Grieve (Dec 19 2019 at 21:24):

right now, the rules that that, except for some named exceptions, it's a warning if an resource does not have an identifier element. So any resource crossing the FMM 3->4 boundary gets an identifier. That's kind of ridiculous, really. They should just have them, or not. Not be forced to add them for procedural reasons late in the game.

And now that reference can be identifier, there's basically an infrastructural reason for resources to have an identifier.

Let's say we decided to enforce that all DomainResources get an identifier : Identifier [0..*], here's what would change:

Add Identifier : Identifier [0..*] to:

• AuditEvent
• CapabilityStatement
• CompartmentDefinition
• GraphDefinition
• ImplementationGuide
• Linkage
• MessageHeader
• NamingSystem
• OperationDefinition
• OperationOutcome
• Provenance
• SearchParameter
• SubstanceNucleicAcid
• SubstancePolymer
• SubstanceProtein
• SubstanceReferenceInformation
• SubstanceSourceMaterial
• TerminologyCapabilities
• VerificationResult

Change identifier from [0..1] to [0..*] in:

• Composition
• ConceptMap
• Ingredient
• ObservationDefinition
• QuestionnaireResponse
• SpecimenDefinition
• SubstanceDefinition
• TestReport
• TestScript
• Bundle (? not an DomainResource, but has identifier [0..1])

Lloyd McKenzie (Dec 19 2019 at 23:59):

Not super thrilled with saying "we put identifier everywhere, even when there's no use-case and when existing systems don't support it just so we can have modelling elegance"...

Grahame Grieve (Dec 20 2019 at 01:35):

that wasn't the use case, though we already do that, just by stealth. The use case is based on Reference.identifier

Grahame Grieve (Dec 20 2019 at 02:35):

I think that the real question is, why should not have identifier. In that category:

• AuditEvent
• MessageHeader

But even those, there's reasons to refer to them by identifier rather than a direct link. Maybe the one most unlikely to use identifier is OperationOutcome. The others.... I think that they'd be better with them

Lloyd McKenzie (Dec 20 2019 at 15:04):

You're free to think that, but if it's not something there's a current use for, it should be an extension at best. Reference doesn't have an identifier because everything can be referred to by identifier. It has it because many things can be referred to that way. (And several of these resources aren't generally referred to using Reference anyhow.)

John Moehrke (Dec 20 2019 at 15:19):

I understood that .identifier is different than .id. The Reference.reference is the place to use the .id. The Reference.identifier is to be used when the thing being referenced does not (yet) have an .id, but does have a business identifier. Thus the only Resources that really need to have a .identifier are those that might have a business identifier outside of FHIR...Said another way, in a perfectly (100%) FHIR world, there would be no .identifier(s). We know that is not realistic, for example Patient.identifier holds many identifiers that will never be FHIR resources. Hence, .identifier is 'added' to a resource when there is an identified real-world evidence that an .identifier exists.

John Moehrke (Dec 20 2019 at 15:21):

that said... I get that by adding a 0..* .identifier more liberally, that we are not really forcing .identifiers to exist. But I am with Lloyd that this feels like adding an identifier just for modelling elegance.

Paul Church (Dec 20 2019 at 16:02):

Even in a 100% FHIR world, we are looking at using identifiers in the context of $import to represent resource IDs from a different server. Those are being attached to an extension in meta because they're not part of the content, but I think this calls into question whether a 100% FHIR world would actually have no identifiers.

Grahame Grieve (Dec 20 2019 at 20:23):

well, here's what I think:

• people keep asking about this - implementers do
• Reference.identifier exists because you need to reference resources that exist in potential or on another server that you know it's address
• so that means, resources should have an identifier unless we feel that there's no need to refer to them on an unknown server
• hence my list, AuditEvent and MessageHeader

Grahame Grieve (Dec 20 2019 at 20:23):

in fact, by that logic, Binary should too

Jean Duteau (Dec 20 2019 at 21:55):

No, I agree with Lloyd here. You are mixing up the logic. If a resource has no business need for a business identifier, then there is no need to give it one. How can I reference a resource via identifier if it doesn't have one? And just giving all resources an identifier element so they can be referenced, doesn't make sense unless you tell me what that resource's business identifier is going to be.

Grahame Grieve (Dec 20 2019 at 22:04):

"reference a resource via identifier" is not a business need?

Grahame Grieve (Dec 20 2019 at 22:04):

what that resource's business identifier is going to be

Whatever people assign it, so it can be referenced

Grahame Grieve (Dec 20 2019 at 22:05):

I point out that this use case arises not infrequently for system architects - the was a thread on this for binary a week ago in the implementers channel

Grahame Grieve (Dec 20 2019 at 22:05):

why is an infrastructural architecture requirement not a business requireement?

Jean Duteau (Dec 20 2019 at 22:06):

so you have a resource that has no natural business identifier that you want to reference somehow? how do you do that?

Grahame Grieve (Dec 20 2019 at 22:07):

then you give it an id so that you can

Jean Duteau (Dec 20 2019 at 22:07):

so you give it a Resource.id

Grahame Grieve (Dec 20 2019 at 22:07):

what's a natural business identifier?

Grahame Grieve (Dec 20 2019 at 22:07):

umm no. Resource.id is not stable

Jean Duteau (Dec 20 2019 at 22:07):

Patient's health care number
Hospital's encounter number

Grahame Grieve (Dec 20 2019 at 22:10):

what makes them "natural"?

Jean Duteau (Dec 20 2019 at 22:13):

let me step back a bit to try and understand your argument:
we have some resources where the FHIR community has agreed that assigning a business identifier to it is not in the 80% mainly (I suspect) because the real world objects do not usually (or ever) have business identifiers assigned to them. Someone has decided that they want to reference a resource instance, not by it's resource.id but by its business identifier. And one of these resources that they want to reference is of a type that does not have business identifiers. So they will assign some arbitrary string to it so that they can reference it by identifier rather than referencing it by using that same arbitrary string as its resource.id?

Jean Duteau (Dec 20 2019 at 22:16):

let me posit a related argument:
we have some resources where the FHIR community has agreed that assigning a NAME to it is not in the 80% mainly because the real world objects do not usually or ever have a NAME. A number of system architects have decided that they want to refer to all resources by NAME, including one of the resources that has a type that does not have a NAME element. So we are going to force all resource types to include a NAME element if it doesn't make sense from a business need.

Grahame Grieve (Dec 20 2019 at 22:18):

if we thought that architects had a valid argument argument there - which I can't imagine - we'd have to consider it.

Grahame Grieve (Dec 20 2019 at 22:18):

why not use Resource.id... because (a) that is not reliable - it is changed from server to server and (b) we have not made that available as a target for Reference.identifier (because of (a))

Jean Duteau (Dec 20 2019 at 22:19):

you missed a resource type in your list: MedicationKnowledge. It has no identifier because it is describing a kind and having a business identifier makes no sense. The Pharmacy committee has intentionally not given it an identifier element.

Jean Duteau (Dec 20 2019 at 22:19):

I suspect the SubstanceX resources are similar

Grahame Grieve (Dec 20 2019 at 22:20):

actually, it does have an identifier.

Grahame Grieve (Dec 20 2019 at 22:20):

and so it should.

Grahame Grieve (Dec 20 2019 at 22:21):

unless you're going to claim that (a) MedicationKnowledge is only ever represented as FHIR resources (I think not) and (b) there would never be a reason to refer to a MedicationKnowledge resource on another server whose address is presently not known ,perhaps because it has not yet been defined.

Jean Duteau (Dec 20 2019 at 22:21):

hmm, I see that it does in the build. it didn't originally and I'll have to look into why it does. Because there is no sensical identifier that you could give to a MedicationKnowledge resource.

Grahame Grieve (Dec 20 2019 at 22:21):

and I don't know why why you think that those are not real requirements and also why you don't think that those are business requirements

Jean Duteau (Dec 20 2019 at 22:21):

that's what the MedicationKnowledge.code is for. That describes what the MedicationKnowledge is about

Grahame Grieve (Dec 20 2019 at 22:22):

so code is unique? There can only be one statement per code? really?

Jean Duteau (Dec 20 2019 at 22:23):

you're saying that the Patient.identifier is unique? that there can be only one patient instance per identifier?

Grahame Grieve (Dec 20 2019 at 22:23):

on some systems yes but in general no,, but so what?

Jean Duteau (Dec 20 2019 at 22:24):

i'll just echo that back to you - there can be multiple knowledges per code, but so what?

Jean Duteau (Dec 20 2019 at 22:24):

within FDB, I use the Medication code to reference all of the knowledge that I have access to about that Medication. There is no other "identifier" for the knowledge

Grahame Grieve (Dec 20 2019 at 22:25):

so what you are saying is that there's never any need to reference another particular medication knowledge somewhere else, because you can just state the code, and there can be no ambiguity about which instance you are referring to

Grahame Grieve (Dec 20 2019 at 22:25):

and that's true not just within a single system (FDB) but across all systems

Grahame Grieve (Dec 20 2019 at 22:25):

whether FHIR or no

Jean Duteau (Dec 20 2019 at 22:26):

how do you get that non-ambiguity with Patient.identifier???

Grahame Grieve (Dec 20 2019 at 22:27):

umm, because Patient identifiers are assigned once and conserved as patient information is copied from system to system however the information is copied

Jean Duteau (Dec 20 2019 at 22:27):

How does this <reference><identifier system="AB-ULI" value="Jean-s ULI"/></reference> relate to one specific instance of my patient record?

Grahame Grieve (Dec 20 2019 at 22:28):

cause you look it up. I'm really not sure what you're getting at here

Jean Duteau (Dec 20 2019 at 22:28):

The information that you get back, using that reference, will be completely different if you use that reference against the AB Health registry versus my doctor's EHR vs my local FHIR repository.

Jean Duteau (Dec 20 2019 at 22:29):

you just told me that I had to reference a PARTICULAR medication knowledge using an identifier. But I'm asserting that an identifier does NOT get you a PARTICULAR instance of information.

Jean Duteau (Dec 20 2019 at 22:29):

there's never any need to reference another particular medication knowledge somewhere else, because you can just state the code, and there can be no ambiguity about which instance you are referring to

Grahame Grieve (Dec 20 2019 at 22:30):

completely different if you use that reference against the AB Health registry versus my doctor's EHR vs my local FHIR repository

really? that would be a surprise.

Grahame Grieve (Dec 20 2019 at 22:31):

the records may vary, but they should be about the same person. And on most clinical systems, there will be a business rule: one record per patient identifier. but on some systems (MPIs) there will be many

Jean Duteau (Dec 20 2019 at 22:32):

okay, and there is a business rule for kinds (like MedicationKnowledge) - one record per MedicationKnowledge.code

Grahame Grieve (Dec 20 2019 at 22:33):

really? in all cases?

Jean Duteau (Dec 20 2019 at 22:33):

yes. why would a knowledgebase have multiple knowledge records for the same medication?

Grahame Grieve (Dec 20 2019 at 22:34):

because it serves a reconciliation purpose? because different people (/systems) came up with the statements and they are different, even they though are about the same code. Or could that never happen?

Jean Duteau (Dec 20 2019 at 22:34):

i suspect that many systems will just duplicate the code into the identifier for things like MedicationKnowldge, SubstanceX, eg. for the resources that are representing kinds of things.

Grahame Grieve (Dec 20 2019 at 22:35):

why would they do that? hopefully only because they need an identifier. And if they did, would it be wrong?

Grahame Grieve (Dec 20 2019 at 22:36):

but if you want to argue that you don't need an identifier, you'd have to move from 'many systems would' to 'no systems wouldn't', which is something quite different

Jean Duteau (Dec 20 2019 at 22:36):

a) because you just said that every resource needs an identifier and they don't have a natural identifier to use
b) maybe not but it loses the distinction of what identifier has been used for

Grahame Grieve (Dec 20 2019 at 22:38):

I think by "natural" identifier you mean "an identifier that humans are concerned with'. So you are positing that there's only 2 levels of identifier:

• assigned in the resource, and reassigned from server to serve (resource id)
• assigned by humans to manage human processes (natural identifier)

but that's not the case - there's a need for a stable identifier that is unchanged as records are copied from system to system, but is not (always) relevant to humans.

Grahame Grieve (Dec 20 2019 at 22:39):

it's that 3rd case I am concerned about. Resource.id isn't it, and you're arguing that it cannot exist unless humans know about it. but that's very much not the case

Grahame Grieve (Dec 20 2019 at 22:42):

in my view there is no "natural" identifier - it's just a number that you assign to a record by some assignment process.

Grahame Grieve (Dec 20 2019 at 22:43):

In general, I agree that MedicationKnowledge resources would not be assigned an identifier i a knowledge base, since the system implicitly has one per code. But once you get into managing an eco-system of medication knowledge, then assigning identifiers becomes a natural thing to do, and it has to do with managing information records, not MedicationKnowledge

Grahame Grieve (Dec 20 2019 at 22:44):

if you want to insist that those things are different , and should be different elements, then we could add identifier to Resource.meta, and explain the difference, and see if people can manage that

Jean Duteau (Dec 20 2019 at 22:56):

In general, I agree that MedicationKnowledge resources would not be assigned an identifier i a knowledge base, since the system implicitly has one per code. But once you get into managing an eco-system of medication knowledge, then assigning identifiers becomes a natural thing to do, and it has to do with managing information records, not MedicationKnowledge

Then this seems like a meta-identifier that you are talking about. It is not a business identifier per se but a stable identifier that is maintained across all instances of the same patient. It can be sometimes be the business identifier but even then it might not, i.e. a patient identifier that a hospital assigns per encounter is a business identifier of a patient, but does not qualify as this meta-identifier that we need here.

Jean Duteau (Dec 20 2019 at 22:58):

if you want to insist that those things are different , and should be different elements, then we could add identifier to Resource.meta, and explain the difference, and see if people can manage that

As the argument developed, I was going to suggest just this. Resource.id is the instance-specific identifier of an business object in this specific information system. Resource.identifier is the cross-instance stable identifier that uniquely identifiers any instance of this business object in any information system.

Grahame Grieve (Dec 20 2019 at 23:03):

ok, progress. But Resource.identifier can't co-exist with [Resource].identifier - that's a name clash. But it's also a functional disaster, because whether an identifier is just a system assigned stable identifier, or something humans are concerned with has no fixed answer - it changes over time and across perspectives. Hence: put identifier on all resources unless we have a good reason not to have it there (and there are a few resources that are special in regard to these architectural concerns)

Jean Duteau (Dec 20 2019 at 23:06):

by your very earlier argument, what possible reason could there be not to have it be on a resource?

Jean Duteau (Dec 20 2019 at 23:07):

and by "functional disaster", you're saying that you don't want to have:
Resource.id
Resource.stableId
Resource.identifier

because what is a stableID today might be just an identifier tomorrow given context or perspective? Or vice versa.

Grahame Grieve (Dec 20 2019 at 23:15):

yes that's why.

Grahame Grieve (Dec 20 2019 at 23:16):

what possible reason could there be not to have it be on a resource

Apparent special cases: Parameters, OperationOutcome, AuditEvent. MessageHeader? Subscription?

Lloyd McKenzie (Dec 20 2019 at 23:49):

I think we are dealing with different things here. We have 'id' which is a pointer to a specific record on a particular system. We have 'identifier' which refers to a particular business object, which may have multiple records on the same system and which may appear on multiple systems. I think what Grahame/'the architects' are seeking here is a 'record identifier'. I.e. something that remains consistent when a record is copied from one system to another. I'm not sure that's common practice for many resources (even most resources). And I also don't think it's the same thing as a business identifier. There's no expectation that the content of multiple business records for the same object will be identical (though they would be expected to generally refer to the same business object). Whereas, I believe the expectation is that if the 'record identifier' were the same, the data would be the same (allowing for variation in version and system storage capabilities). Is that accurate?

Jean Duteau (Dec 20 2019 at 23:49):

yes, that is what I ended up understanding

Lloyd McKenzie (Dec 20 2019 at 23:50):

If we were going to add a notion of 'recordId', my leaning would be to do it as an extension, not to munge it in with our existing .identifier elements.

Jean Duteau (Dec 20 2019 at 23:53):

that was akin to my initial thought - add it to Resource.meta. Grahame seems to think that doesn't make sense.

Lloyd McKenzie (Dec 20 2019 at 23:57):

Resource.meta is generally info that's server-specific. The purpose here would be server-agnostic, so I tend to agree with Grahame on that.

Jean Duteau (Dec 21 2019 at 00:01):

sorry, didn't mean resource.meta, but in Resource (i.e. the same place where Resource.id is)

Grahame Grieve (Dec 21 2019 at 01:17):

adding it as a new field, or as an extension, that is different to [Resource.identifier], that will just create confusion, because these are - for a good reason - poorly differentiated use cases in practice.

Also, we do we have a rule that identifier gets added at FMM 3->4? Most of these resources will get identifier added for that rule alone - which we defined for this use case - later. I'm not seeing any sense there

Lloyd McKenzie (Dec 21 2019 at 02:56):

Where is the rule about adding identifier at FMM3->4 documented? I don't remember that (and have no clue why it exists...)

Grahame Grieve (Dec 21 2019 at 03:21):

it's in the code. I don't know where it came from but it's been there a long time

Thomas Beale (Dec 21 2019 at 14:23):

Interesting discussion. Been here many times. To summarise, do I understand that in the abstract you want (I'll ignore the FHIR ids for right now):

• a business identifier that uniquely identifies a singleton thing in the real world, e.g. a patient Jane Dupont, a drug Amoxycillin, etc, and if there are records about this thing inside systems, such an id would be one way to search for such record(s)
• an informational identifier that is guaranteed unique for every informational entity known inside systems, including entities that appear to be not directly related to real world singleton entities (e.g. each med. rec. event on some patient's Rx list), aka things that don't have business identifiers;, aka things that are 'just information';
• an instance identifier, guaranteed to be unique for any distinguishable instance of each logical informational entity (i.e. doesn't change for exact copies, but does change as soon as changes are made)

The first and third are easy to explain and understand. The second one is the challenge. The difficulty is that (most likely) all informational entities have as their referent something in the real world, but only some are assigned real-world identifiers (patient numbers, DVLA numbers and the like). The vast majority of them are not - e.g. each medication reconciliation event is a real thing, so is each diagnosis of Mrs Jones hayfever, but these kinds of things don't get assigned ids in the way that patients or medications do.

You can easily see the difficulties in today's systems relating to this problem when trying to distinguish between e.g. repeated diagnoses of the same thing (say, tonsillitis, or a fracture of the toe) - are they really separate instances of tonsillitis / broken toe, or separate reports of the same occurrence, etc. Today, we rely on date/times of Dx and recording, but those are fallible. A patient can report to a new doc that he had tonsillitis in Jan and May last year - both these occurrences will be written to the EHR in the same note, only the date/time mentioned by the patient will distinguish them. And so on.

Thomas Beale (Dec 21 2019 at 14:26):

Solving this properly means adopting something like the referent-tracking system of Smith & Ceusters - http://www.referent-tracking.com/RTU/papers.html

Thomas Beale (Dec 21 2019 at 14:27):

The problem is that doing so would require the systems themselves to solve this properly; as a communications layer between systems, FHIR cannot easily inject identifiers that are going to 'stick', because receiver systems don't know what to do with them.

Thomas Beale (Dec 21 2019 at 14:28):

I'm not going to propose any solution for FHIR (right now, I don't have a proposal), I'll just leave the above as a contribution that might help clarify the discussion.

Thomas Beale (Dec 21 2019 at 14:31):

One thing to be aware of: if you start forcing systems to issue identifiers on things that they don't already identify, you may be creating a serious imposition on some systems by forcing them to track all ids, and versions of info entities, in a way that they don't do today. I once calculated out the cost of this for using ISO 13606, which forces Guids on every single data node, for a system that otherwise didn't create or track such ids, and it significantly increased the infrastructure, versioning, persistence requirements etc for the source system. (For this reason, openEHR only requires Guids in a few strategic places, and they are optional elsewhere.)

Thomas Beale (Dec 21 2019 at 14:45):

I'll just add one more thing: the most common and obvious example of the problem of ids and real world referents is the medication list. In reality, there is only one real list of medications being taken by the patient, and there should be a one single-source-of-truth medications list for any patient on the planet, with a transactional interface and that can be trusted by every other system. This list, if it existed, would be like your bank account - it would be a singleton information entity that corresponds 1:1 with the real world singleton thing it represents.

However, as we all know, nearly all systems don't do this - instead there are multiple competing copies in GP and hospital systems, almost always out of date w.r.t. to the patient reality. Hence the tiresome routine of questioning the patient on what pills they are taking, and the whole industry around 'medications reconciliation'. So the problem to be solved here is exactly this: the multiple competing variant representations of a real world singleton - an N:1 situation. FHIR ain't going to fix this, so it can only deal with is; the question is, by what means?

Thomas Beale (Dec 21 2019 at 14:46):

Whatever solution you arrive at for this example, it will probably solve all of the others.

Grahame Grieve (Dec 21 2019 at 19:25):

fortunately, we don't have to solve the problem, only let other people solve it their own way. But it was why I think we should be more consistent about allowing identifiers

Richard Townley-O'Neill (Dec 23 2019 at 03:27):

I think that whether or not we add identifier to more resources, the discussion of identifier (at http://build.fhir.org/resource.html#identifiers) should mention informational identifiers.

Richard Townley-O'Neill (Dec 23 2019 at 03:40):

FHIR-25404

John Moehrke (Dec 23 2019 at 14:59):

This problem of importing a resource that is primarily on another system needs far more clarity. If we add this identifier solution, then we should really get rid of the .meta.source as it would seem to conflict. I, possibly incorrectly assumed, that this was used for import workflows. Where the .id would be preserved, but the .meta.source would be the root. Thus I would always have the original URL...

Brian Postlethwaite (Jan 03 2020 at 11:07):

And then in all the conformance resources there is the canonical url too.

---

Last updated: Apr 12 2022 at 19:14 UTC