Stream: implementers
Topic: Create Identifier (MRN)
Michelle (Moseman) Miller (Oct 26 2017 at 16:12):
When creating a new Patient, we expect the server to generate a Patient.identifier.value (e.g. MRN). Since our server supports multiple organizations (i.e. assigners/systems), we need to know which organization should be the assigner of any new/auto-created identifiers for the patient. We can derive the system once we know the assigner.
We discussed Patient.managingOrganization, but dislike that approach since there isn't a single organization that acts as the custodian of the Patient record in our system.
Is it standard practice to interpret a Patient.identifier with assigner, but without value as an ask of the assigner to issue a value?
Jose Costa Teixeira (Oct 26 2017 at 18:22):
I think you mean "leaving identifier value empty but fill in an assigner, and then the assigner will know to assign a value". Could work in some cases, but perhaps not standard practice.
Could you also not resort to an operation?
Lloyd McKenzie (Oct 26 2017 at 18:40):
I think the standard interpretatin would be "I don't know the value of the identifier assigned by XYZ". There's no way using standard REST to say "please make the following modification to this record". That doesn't mean you couldn't adopt a local convention, but you'd need site-specific agreement for anyone to adhere to it. As Jose says, operations are your best bet for this sort of functionality
Elliot Silver (Oct 26 2017 at 22:32):
Wouldn't use of an operation also need a site-specific agreement for everyone to adhere to? I'm not suggesting one way is better than the other, just that I don't see an obvious advantage of a operation. You could also use a data-not-present extension to say "not yet assigned, please assign it."
Lloyd McKenzie (Oct 26 2017 at 23:45):
Well, with an operation, declaration of support or not is clear. And the definition of the expected behavior is clear. If you see a server supports the operation, no negotiation is required. Treating special partially populated data "specially" on the other hand is absolutely going to require site-by-site negotiation.
Michelle (Moseman) Miller (Oct 27 2017 at 15:43):
Seems like this might be a common use case (to request a new MRN or other identifier), so I may log a tracker to get some official guidance in the spec.
Michelle (Moseman) Miller (Oct 27 2017 at 15:53):
GF#14099 has been logged asking for guidance on a consistent approach to requesting an identifier from a given assigner (often MRNs when creating the Patient)
Jenni Syed (Oct 27 2017 at 15:54):
Specifically: This is essentially the patient registration process, which would be very common, correct?
Simone Heckmann (Oct 27 2017 at 16:57):
I wouldn't mind having a standard operation for that...
Simone Heckmann (Oct 27 2017 at 16:58):
Sounds fairly common (for Encounters, too)
Jose Costa Teixeira (Nov 01 2017 at 12:20):
options / Ideas:
$generate_identifier?assigner=<assigner_here> (explicit generate an identifier)
$obtain_identifier?assigner=<assigner_here> (can be used to obtain and also to lookup an identifier)
Depends on the scope we need, i guess
Michael van der Zel (Nov 01 2017 at 14:35):
Interesting. Normally the workflow to obtain an identifier is much more elaborate that just asking for a number, right?
Jose Costa Teixeira (Nov 01 2017 at 16:35):
yes, the operation is assuming that the workflow is "hidden" behind it. That is what I understand from Michelle's problem and the idea of a standard operation.
Jose Costa Teixeira (Nov 01 2017 at 16:35):
can we define an operation without specifying its implementation details? I assumed so.
Jenni Syed (Nov 01 2017 at 16:42):
My main concern about the operation: some systems won't let you assign the identifier without the patient being in the system. This also makes registration (just creating the patient) at least a 2 step process.
Jenni Syed (Nov 01 2017 at 16:45):
What you really want is "here is this patient I want to register, the identifiers that are automatically assinged should come from X system?"
Jose Costa Teixeira (Nov 01 2017 at 16:46):
you mean when you do the first POST, you provide some data to generate an identifier?
Jenni Syed (Nov 01 2017 at 16:46):
And then in the future: "here is this patient that already has some identifiers, I would like some more/for this patient to be recognized by a new system as well"
Jenni Syed (Nov 01 2017 at 16:47):
Yes, but as Grahame has pointed out on the tracker, I think there are "create both patient and identifier" and "create new identifiers for existing patient"
Jose Costa Teixeira (Nov 01 2017 at 16:47):
i see two things: create patient and create ID.
Jenni Syed (Nov 01 2017 at 16:48):
requiring them to actually be implemented in the API separately seems unfortunate
Jenni Syed (Nov 01 2017 at 16:48):
"let me write this patient with no identifiers, trust me, I'll come back and give you real identifiers eventually..." :)
Jose Costa Teixeira (Nov 01 2017 at 16:50):
seems less efficient, but i would not say unfortunate for that fact. It's easier to combine functionality than to split.
Jose Costa Teixeira (Nov 01 2017 at 16:51):
tracker says: An Identifier.assigner populated without Identifier.value populated
Jose Costa Teixeira (Nov 01 2017 at 16:52):
That could be an interesting option locally, as said above in this thread.
To make it global, this would mean that provider an assigner would ALWAYS create an identifier, right?
Jose Costa Teixeira (Nov 01 2017 at 16:52):
(sorry for caps)
Jose Costa Teixeira (Nov 01 2017 at 16:53):
this means that we would never support "here is a patient, i know his ID is a SSN but I don't know it now", right?
Jenni Syed (Nov 01 2017 at 16:56):
I don't think there's anything in the actual spec that prevents that right now, btw
Jenni Syed (Nov 01 2017 at 16:56):
this all comes down to business logic in the server or client itself. Technically, I could write something like "i bet he has an SSN but I don't know the actual value"
Jose Costa Teixeira (Nov 01 2017 at 16:57):
i am just saying that my reading of the option "An Identifier.assigner populated without Identifier.value populated" is "whenever we have an assigner and no ID, please create an ID"
Jose Costa Teixeira (Nov 01 2017 at 16:58):
and if my logic is correct, this means that we would not support "whenever we have an assigner and no ID, please lookup the ID"
Jenni Syed (Nov 01 2017 at 16:59):
I think there are currently 3 options (knowing there could be a better option still), one is unpopulated. One mentions operations, one mentions DAR with a special value asking the server to populate...
Jenni Syed (Nov 01 2017 at 16:59):
(on the actual tracker)
Jenni Syed (Nov 01 2017 at 17:00):
I agree just leaving it blank seems to leave intent open for interpretation
Jose Costa Teixeira (Nov 01 2017 at 17:00):
what _could_ be more global is
"if a resourceX has an assigner and no ID for that assigner, the system is in charge of finding out whether this needs to be created or looked up"
Jose Costa Teixeira (Nov 01 2017 at 17:00):
but i think even this could be challenged, e.g. if you just want to leave it as is.
Jose Costa Teixeira (Nov 01 2017 at 17:02):
this reasoning is for option 3 in the tracker (leaving empty implying some behaviour)
Grahame Grieve (Nov 01 2017 at 22:42):
we can define an operation to issue an identifier without requiring that it be a separate step. But if we want to describe a standard API for registering a patient... that's more than just 'create a patient resource'
Cooper Thompson (Nov 02 2017 at 18:31):
Do we want to include identifier assignment for national IDs? That might lean more toward a registration operation, since some national IDs encode patient demographics in the ID (I'm looking at you Denmark). P.S. I'm not endorsing or encouraging demographic encoding in IDs... just saying that it's a thing.
Brian Postlethwaite (Nov 10 2017 at 08:03):
I guess that could also be related, where there is a national identifier, and the need to start the process for getting one in maternity. But I suspect this is outside of this scope anyway.
Brian Postlethwaite (Nov 10 2017 at 08:03):
I like the way @Jose Costa Teixeira has worded it. Seems to cover Michelles case ok.
Brian Postlethwaite (Dec 19 2017 at 20:21):
This has been floating around for a bit, and we should discuss in person at the Jan WGM
Cooper Thompson (Jan 29 2018 at 21:11):
What do folks think of the option of adding a new value of "request-to-generate" to Identifier.use to indicate that an Identifier should be issued for the specified system/assigner/type?
Cooper Thompson (Jan 29 2018 at 21:12):
This seemed to make sense to several folks in the PA discussion, as (excepting "official"), the Identifier.use values basically track the workflow steps involved in managing the lifecycle of an identifier.
Jose Costa Teixeira (Jan 29 2018 at 21:34):
do we have a difference between "request-to-generate" and "an-identifier-was-requested-but-it-was-not-yet-given-so-i-can't-really-capture-it-here" ?
Cooper Thompson (Jan 29 2018 at 21:37):
So for now, PA is not going to pursue the Identifier.use. It was something we were considering at the end of Q3, but that was soooo last quarter. We've moved on. But if we had, I think the"an identifier-was-request-but-not-yet" scenario would just be an absent identifier. Since you aren't asking for any change to the identifier state.
Grahame Grieve (Jan 29 2018 at 21:55):
"soo last quarter"... excellent
Last updated: Apr 12 2022 at 19:14 UTC
