Stream: implementers
Topic: ReferralRequest IDs
Tim Berezny (Jun 30 2017 at 11:52):
I have a question about handling IDs (& Identifiers) with a /referralRequest. Consider the following scenario:
SystemA sends a referralRequest to SystemB, with referralRequest.id = ABC
SystemB accepts the referralRequest, and assigns a new internal referralRequest.id = 123
SystemB now updates the referralRequest.status = completed, and wants to update SystemA.
To send the updated /referralRequest back to A, what value is used for referralRequest.id (ABC or 123?)? Does the .identifier field get involved at all?
Kevin Mayfield (Jun 30 2017 at 12:16):
You should be using identifier, id is a logical, system specific id.
Tim Berezny (Jun 30 2017 at 12:31):
So, @Kevin Mayfield , does the following sound like generally the correct process:
1) SystemA send referralRrequest.id = ABC
2) SystemB sends back with referralRequest.id = 123, but adds in identifier.value = ABC?
(with some more coding in the identifier.value field)
Tim Berezny (Jun 30 2017 at 12:34):
or... 1) SystemA sends identifier.value as ABC.
Kevin Mayfield (Jun 30 2017 at 12:42):
Ideally you would want all systems within an organisation to be referencing the Referrals by the same identifier. You could also say Organisation A will refer to it's Referrals by this 'identifier' e.g. ReferralRequest.idenitifer=https://sysA/ReferralID|ABC
Kevin Mayfield (Jun 30 2017 at 12:42):
ABC could be the same as ReferralRequest.id but that's down to implementors
Kevin Mayfield (Jun 30 2017 at 12:45):
System B should use the same identifier when talking to A, so ReferralRequest.idenitifer=https://sysA/ReferralID|ABC. System A wouldn't know System B's identifiers and likewise SystemB woudn't know System A ReferralRequest.id unless it's search for it using the identifier.
Tim Berezny (Jun 30 2017 at 12:59):
Ok, since we are talking about referrals, this is pretty much by definition across many organizations and systems.
So it sounds like focusing on the .identifier for connecting info between the referring/receiving systems is the way to go.
Grahame Grieve (Jun 30 2017 at 13:01):
one way to handle this is for system B to use the same local id.
Grahame Grieve (Jun 30 2017 at 13:02):
if that's not possible - it often isn't - another way is for system B to remember that system a know it as ABC
Grahame Grieve (Jun 30 2017 at 13:02):
have you read http://hl7.org/fhir/managing.html?
Thomas Lukasik (Jun 30 2017 at 18:59):
RE @Grahame Grieve's comment: "..another way is for system B to remember that system a know it as ABC"
That seems like the most correct and simplest solution to the problem.
It's no different than if you were loading a patient or an appointment into your system from an external system. Sure, you may give the patient or appointment or other entity a unique identifier for local use, but it's just common sense that you would use the native, external identifier (not your synthetic, local identifier) whenever you communicated with the external source about that patient, appointment, etc.
Last updated: Apr 12 2022 at 19:14 UTC
