Stream: CARIN IG for Blue Button®
Topic: CARIN Practitioner references
Karl M. Davis (Sep 17 2020 at 15:43):
@josh lamb @Josh Mandel If I'm following the CARIN ballot discussion today correctly, someone was saying that the CARIN IG should have SHALL (lol) mandating that implementers return full-fledhed Practitioner resources, instead of just Reference.identifiers with NPIs in them. "It's more RESTy", "it's the FHIR way", etc.
This runs counter to advice I've heard on this subject in the past, which is more: if you _can_ return a full-fledged resources, you should, as that's easier for end users. But it's not a SHALL kinda' thing.
Any clarifications or thoughts or additional context I'm missing?
Josh Mandel (Sep 17 2020 at 15:51):
We don't have a lot more experience with Reference.identifier (e.g., resolving, including etc). Like in US Core, references baded on id (meaning we populate Reference.reference, not Reference.identifier). http://hl7.org/fhir/us/core/general-guidance.html#referencing-us-core-profiles doesn't even contemplate Reference.identifier (so there's no language one way or the other, but I expect this has just never come up -- @Eric Haas or @Brett Marquard may be able to confirm)
My default has usually been to recommend using FHIR ids for references, and if all you have is an identifier, then use a contained reference. I like the consistency of this approach for clients.
Josh Mandel (Sep 17 2020 at 15:52):
Overall, I think it is useful and appropriate for an implementation guide to lock these kinds of details down for consistency one way or the other, if possible.
Josh Mandel (Sep 17 2020 at 15:52):
(deleted)
Josh Mandel (Sep 17 2020 at 15:52):
So some kind of SHALL requirement does not seem out of place to me, if you can get consensus on it.
Josh Lamb (Sep 17 2020 at 15:58):
@Karl M. Davis The way the IG is currently published the only way to resolve a referenced resource is through the use of includes. We would more closely follow other FHIR implementations if we required support for reads of supporting resources. E.g. if I give you a resource reference for Practitioner/123 the expectation is that you should be able to resolve that resource id. If you included the practitioner as something other than a reference i would not expect to be able to independently read the underlying resource.
Paul Church (Sep 17 2020 at 16:11):
Given that the IG includes a profile on C4BB Practitioner, I think it should require Reference.reference and force implementers to fill out a resource, potentially using data absent codes as necessary. Otherwise, the constraints of that profile are moot as implementers can use Reference.identifier or Reference.display to avoid it.
Eric Haas (Sep 17 2020 at 16:49):
@Josh ...Can you make a tracker for USCore to propose this guidance?
Josh Mandel (Sep 17 2020 at 18:05):
Sure, created J#28573
Last updated: Apr 12 2022 at 19:14 UTC
