Stream: Canadian eReferral
Topic: For reference data types, use .reference AND .identifier?
Tim Berezny (Oct 19 2021 at 12:56):
For reference data types, is it ok to use both .reference AND .identifier - or should we choose only one of them to use?
Lloyd McKenzie (Oct 19 2021 at 13:16):
You can have both. The use-case for doing that is if you don't know whether your receiver will have the ability to resolve the resource, having just name (display) + identifier might be "good enough". For a receiver who understands the reference and can resolve it, the identifier doesn't really buy anything.
Tim Berezny (Oct 21 2021 at 13:12):
Great thanks, that's pretty close to the use case we were looking at.
Tag @Jonathan Fishbein
Tim Berezny (Jan 04 2022 at 21:12):
@Lloyd McKenzie For eReferral we need to include multiple identifiers for ServiceRequest.provider.identifier, which is restricted to 0..1
We're discussing three ways to add an extension to enable this:
1) add a valueIdentifier to ServiceRequest.provider
2) add a valueIdentifier to the reference dataType
3) add a valueIdentifier to the identifier dataType
(possibly called something like "additionalIdentifiers")
All three of these approaches could work for us I think, #2 feels the most intuitive to me. We MAY have a need for multiple reference identifiers in other elsewhere, unsure as of yet. Is there an approach that might be better than another from your perspective? Any of them feel like they might be useful to adopt into the standard extension set, if we do this thoughtfully.
Tag @Jonathan Fishbein , @Russell Buchanan
Lloyd McKenzie (Jan 04 2022 at 23:02):
I think adding it to Reference is the appropriate choice here. It's unfortunate that Reference.identifier is normative. If we'd been smart, it should have been marked as STU because it was new in R4. I think this makes sense to submit as a proposal for a standard extension.
Elliot Silver (Jan 04 2022 at 23:04):
Wasn’t there another discussion recently from someone wanting multiple Reference.identifiers?
Brian Postlethwaite (Jan 05 2022 at 20:31):
This sounds like a sensible change to me too (the multiple identifier in ref change - and yes shame to break Normative)
Tim Berezny (Jan 13 2022 at 17:48):
Is changing reference.identifiers to an array something I should submit, or another process (it's not a process i'm overly familiar with).
In the meantime then, I'll add an extension to reference.
Lloyd McKenzie (Jan 13 2022 at 18:53):
You can propose it. However, given that Identifier is normative, I expect it'll be a non-starter :(
Elliot Silver (Jan 13 2022 at 19:38):
I think it would be helpful for FHIR-I (?) to decide on a common pattern for moving max 1 cardinality elements to max *. This came up with Observation specimen I believe, and it would be good to use the same approach. I think their proposal was to add a new multipleSpecimen element and a constraint that only one of specimen or multipleSpecimen element is populated. Waiting on FHIR-I and an update to the spec doesn't solve your issue in the mean time, so an extension seems like an appropriate way to go.
Lloyd McKenzie (Jan 13 2022 at 23:29):
MnM has this as an issue to formally document. For a past release, an extension is your only option no matter what. For a future release, what makes sense may vary.
Rob Hausam (Jan 15 2022 at 04:54):
I think people probably don't want "may vary" to be too broadly and variably interpreted - it would be good to have a general pattern and approach that can be applied in most (even if not quite all) cases, when this kind of change needs to happen.
Lloyd McKenzie (Jan 15 2022 at 23:53):
May vary is unavoidable. As an example, the Specimen solution of a new "SpecimenGroup" target makes sense and works very will for that circumstance. It won't necessarily make sense in other places of type Reference, and it can't work in places that have differing data types. In other places, the solution might be adding a supplemental core element, adding an extension, deprecating the current element and adding a new (differently named) element that supports repetition, or possibly even making a breaking change if we're willing to go through the hoops needed and the whole community is on-side. All are viable and the trade-offs will need to be evaluated based on the circumstance.
Last updated: Apr 12 2022 at 19:14 UTC
