Stream: implementers
Topic: Identifier practice in national profiles
Øyvind Aassve (Oct 08 2021 at 07:56):
HL7 Norway is in the process of defining national base profiles for Appointment and Encounter. With regards to identifiers we are discussing two alternatives:
• using OID identifiers (preferably in URL-format) that identifies the local clinical application in .system, and use the local identifier in the application in Value.
• use .system urn:ietf:rfc:3986.and use a UUID in value.
What is the most common or recommended practice? We can also define a slice with both alternatives and let it be up to projects to decide, but we do not want to have more variation than necessary.
Lloyd McKenzie (Oct 08 2021 at 16:21):
The primary way to refer to profiles is with their canonical URL. The URL should resolve to the source of truth for the profile, typically on a registry somewhere. There's no requirement to have StructureDefinition.identifier at all. If you don't have a specific need for it, I wouldn't bother.
Øyvind Aassve (Oct 09 2021 at 11:24):
@Lloyd McKenzie , the thing is that we need a unique identifier for the individual Appointment or Encounter instance. An example we are working with are sharing Appointments/ Encounters on a national patient portal which makes it is necessary to identify the correct instance of the Appointment/ Encounter in the clincal application that created it. When the patient accepts/ rejects an Appontment the AppointmentRespons must fed back to the correct clinical application.
We want the national base profiles to act as guidelines that helps harmonize profiling at the national level and provide templates that makes profling for later projects more efficient. So the question is what guideline - if any - to give on the identifiers of these resources.
Using an identifier.system that identifies uniquely the application (url-based oid) combined with the lnternal Appointment/ Encounter-value from the clinical application is uniquely identifying the instance using the clinial application's native identifier. Some argue that the clinical application should send a UUID as this will have a unique value in all contexts.
Is there any preferred practice for other doing base profiles? @Stefan Lang @Ben McAlister @Alexander Henket @Jens Villadsen I have heard of some using the primary approach, but also some arguing for using UUIDs. For what kind of use-cases would use of UUID be an advantage?
There is of course also the possiblity to slice the no-basis-xx.identifier with both oid and uuid-identifiers to show two equally recommended practices in Norwegian context.
Lloyd McKenzie (Oct 09 2021 at 15:21):
I misunderstood the issue. I thought you were talking about identifying the profiles, not identifying the appointments & encounters. For identifying those, the first question is whether humans need to see the appointment or encounter identifiers. If they do, then typically you won't want either an OID or a UUID as both syntaxes tend to be difficult for humans to wrap their heads around, let alone enter. If not, then UUIDs or OIDs are fine. (UUIDs having a slight benefit in that they don't require management of a hierarchy.) I'm not sure, however, that you should try to standardize the identification approach. All that matters is that the combination of system + value is globally unique. If one system uses UUIDs and another system uses a numeric identifier combined with an OID based system, both should work just fine.
Peter Jordan (Oct 09 2021 at 19:17):
@Øyvind Aassve Having written an Appointment Book for a GP system, back in the day, I'm quite surprised that the Appointment Resource doesn't have a CreatedBy property and would be tempted to create an extension for that, rather than use an Identifier. However, I'm guessing that may have already been discussed by the PA Work Group - @Brian Postlethwaite ?
Rik Smithies (Oct 09 2021 at 20:07):
@Peter Jordan in general "created by" is covered by incoming references from a Provenance resource - as a contained resource possibly.
But I am unsure if the issue is who created the resource or who created the identifier. Or if the identifier.system is being used as a proxy for who created the appointment (which isn't really correct).
Peter Jordan (Oct 09 2021 at 20:32):
@Rik Smithies Looks to me as if identifier is being used here as a proxy for who created the appointment, which could be any one of a number of different entities (patient, family member, practitioner, receptionist, software app, etc.).
Kevin Mayfield (Oct 10 2021 at 03:49):
No detailed (England) guidance but have been favouring making identifier mandatory on national profiles.
Not convinced on uuid, we aren't using them on central English profiles for central services. So not seeing this as a requirement elsewhere, think this is down to provider/supplier to manage.
Where we have mandated uuid, I believe we are still allowing the original identifier
Jens Villadsen (Oct 10 2021 at 08:37):
Hi @Øyvind Aassve - in regards to the use of Identifiers: it comes down to what trust you have to your applications. If you assign a url/uuid/oid pr. application/vendor it is essentially not of importance which one you pick for identifier.system. If you instead go with a single national-picked identifier.system eg. helse.no then you would need all application/vendors to figure out an identifier.value that does not gives you clashes across applications/vendors. If you're into that I recommend that you look into the use of UUIDv5 as they are scoped pr. issuer. meaning that UUID's can be used as globally unique identifier.value while being within the zone of a single application/vendor.
In regards to the 'created by': At least, in my perspective, it is usually not important who created a certain appointment. It is more important who that has the responbility of the Appointment, as entities such as appointments usually are created by proxies such as secretaries/assistants. Have a look at eg. https://docs.ehealth.sundhed.dk/latest/ig/StructureDefinition-ehealth-appointment.html where we've modelled the responsibleextension.
Øyvind Aassve (Oct 10 2021 at 11:10):
@Lloyd McKenzie @Peter Jordan @Jens Villadsen - with regards to people reading the profile I guess that would be restricted to logging and tracing-scenarios. When referring to OIDs I think of a URL-synonym to the numeric OID in our national OID-identification schemes, and thus human readable (slight advantage over UUIDs?). We have a distributed OID-regime with branches in place for identifying clinical applications, so I guess we will not go for one central identifier.system a la ehelse (for clinical applications).
However there is as of now no other information in the message to identify the sending application (and I know that is not the purpose of the identifier, but still). i guess Provenance - which we have not started using - also could be used for identifying responsible for the Appointment, or possibly Appointment.participant.Device? What is the most common/ correct practice?
Good point Lloyd that this mayebe not is the most important element to secure a common national implementation practice for. What we would do would be to provide an open slice that at least can act as something to help implemenation projects think less :), by providing a template to follow.
Jens Villadsen (Oct 10 2021 at 11:25):
@Øyvind Aassve are you sure that it is 'sending' you actually want to model, and not ownership/responsibility instead? Your auditlog will tell you who sent it/spawned it
Øyvind Aassve (Oct 10 2021 at 11:43):
@Jens Villadsen -agree sending is not the best word - original sender/ responsible/ owner of the Appoitment is more correct with regards to what we want to model
Jens Villadsen (Oct 10 2021 at 12:01):
@Øyvind Aassve - the modelling in the Danish national Telemedicin platform (the link above) is done by having an extension modelling the person / team / organization that is responsible for the appointment. Furthermore, there's an invariant that statest that the person / team SHALL be among the participants.
Jens Villadsen (Oct 10 2021 at 12:04):
but it looks like you just as well could use the participant.type (http://hl7.org/fhir/R4/valueset-encounter-participant-type.html) to model that part of the ownership
Jens Villadsen (Oct 10 2021 at 12:05):
@Lloyd McKenzie - the table on http://hl7.org/fhir/R4/valueset-encounter-participant-type.html might need some adjusting in R5 since teams and groups are now permitted as participants - and the wording on the participant types seems a bit 'singular' to me
Øyvind Aassve (Oct 10 2021 at 12:32):
@Jens Villadsen - with regard to the identifier issue we are considering the clinical application/ EHR that generates the identifier as the owner, responsible for the appointment instance. With regards to organizational ownership we have per now not done anything to define that beyond identifying the participants. What requirements makes participant not sufficient for you here? Could it be an option if this of interest in R5 to mirror the serviceProvider element in Encounter?
Lloyd McKenzie (Oct 10 2021 at 16:36):
Encounter shouldn't have Group as a participant - Groups can't have responsibility. I'll raise a change request. @Jens Villadsen You might want a change request to add support for CareTeam to the value set.
Lloyd McKenzie (Oct 10 2021 at 16:39):
FHIR#34100 (@Brian Postlethwaite FYI)
Jens Villadsen (Oct 10 2021 at 17:10):
(deleted)
Jens Villadsen (Oct 10 2021 at 20:38):
@Øyvind Aassve yep - very much. The service provider could be of value here - it could be a solution to introduce it or it could be transitively resolved through a link to the encounter
Kevin Mayfield (Oct 11 2021 at 06:58):
@Ben McAlister @Rik Smithies
I think this is also a gap in HL7 UK Core guidance.
I've logged this https://simplifier.net/nhsdigitalspine/~issues/1795 for NHS Digital perspective (so not national).
Brian Postlethwaite (Oct 11 2021 at 21:47):
If it's also tracking just the source record, there's the Meta.source property which can hold the full url of the original record.
Brian Postlethwaite (Oct 11 2021 at 21:47):
Otherwise using a unique identifier in the identifiers would do it as you've described.
Last updated: Apr 12 2022 at 19:14 UTC
