Stream: implementers
Topic: How to map DSTU2 to STU3/R4 if it didn't exist?
John Silva (Dec 06 2021 at 19:55):
What is the guidance on how to map a field that didn't exist in DSTU2 to STU3 or R4 that is now a required property with a required ValueSet?
I have a specific example in mind, but I suppose this is a general question that come about across any two FHIR versions.
In DSTU2 CarePlan there is no .intent property but in STU3 (and R4) this is now a required property (1..1) and uses an FHIR Required ValueSet (CarePlanIntent)? The FML from DSTU2 to STU3 (where this prop was introduced) doesn't have any help or FML to describe what do do in this case. What should the .intent value be set to if a DSTU2 resource was converted to STU3 (or R4) --- 'plan'?
Grahame Grieve (Dec 06 2021 at 19:56):
the answer is that it depends on the context - you have to figure out from the context of use what the correct value should be
John Silva (Dec 07 2021 at 18:56):
OK, I'm trying to figure out "what context" you mean? Do you mean the use case around the CarePlan or something in the DSTU2 resource (reference to Encounter?) that helps determine that 'context'? For an automated conversion process, the only thing it has available is the DSTU2 FHIR resource instance. (I suppose, there could be a profile associated with it that could help.).
I guess this shows how problematic it is when a new required property is added in a subsequent FHIR version that doesn't have a "default or recommended value".
Grahame Grieve (Dec 07 2021 at 19:02):
the source of the data being converted
Grahame Grieve (Dec 07 2021 at 19:02):
if a committee does add a new required property, that means you have to figure out what the value should be based on information not found in the source resource
John Silva (Dec 07 2021 at 19:05):
OK, that's a non-computable thing then. It can't be done by an automated conversion process without some "external input". I guess the question is, how did the committee get to the meaning of the new property and make it required, that might help answer my (and other's) question.
Grahame Grieve (Dec 07 2021 at 19:10):
it always depends on the element
John Silva (Dec 07 2021 at 19:20):
OK, but whenever a committee decides to add a new elementX, they must have a use case for adding this new element and even more precise reasoning why it becomes a required element and with a (fixed) Required ValueSet. I guess for someone who was not intimately involved in committee discussions (like most of the FHIR user community) this is not something easily discovered. I guess I could go search committee ballot and discussions about this to discover this reasoning but that is "above and beyond" what most users would be expected to do.
Do you know of other examples of a new, required element being added with a (fixed) required ValueSet? Hopefully this is something that doesn't happen very often because it is 'painful' for implementers.
[I guess this also shows up in the "Functional status for this map" and "R(x) Validation Errors" section on the bottom of the auto-generated version-map pages.
Daniel Venton (Dec 07 2021 at 19:27):
Or perhaps you put conformance as a goal and recognize that historical data may never meet new requirements. The only thing you can do is record the data going forward.
You could also hope for an "unknown" value I suppose.
John Silva (Dec 07 2021 at 22:26):
@Daniel Venton - yes, I like the idea of an 'unknown' value, but I suppose the committee wouldn't like that if the use case is really to constraint the value in the Required ValueSet. (if it were only an Extensible ValueSet then it wouldn't be as much of a problem)
Grahame Grieve (Dec 07 2021 at 22:48):
sometimes that has been the case - the committee thinks that you should explicitly say that you don't know. Really, you should create a task asking the committee that owns the resource to at least provide some documentation about what to do if you don't know the value
John Silva (Dec 08 2021 at 17:33):
OK, but I can't find where to post this? There used to be a mechanism for posting 'change requests'; I haven't done this for a while, probably since the change to Jira. I thought the FHIR Zulip channel had an 'always available' link to submit 'change requests'?
At any rate, I was able to find out that CarePlan seems to be owned by the PatientCare committee and I've visited their Confluence page but can't seem to find a place to post this question or as a Jira ticket. (sorry if this is an FAQ).
https://confluence.hl7.org/display/PC/Care+Plan+Projects
Vassil Peytchev (Dec 08 2021 at 18:29):
You can create a Jira ticket and assign it to the specific workgroup. The most easy-to-remember mechanism is to start at the current build, and click on the "Propose a change" link in the footer. The direct link is http://hl7.org/fhir-issues and that will take you Jira, where you can use the "create" button to create your issue (if you are logged in).
Note that the field to specify the workgroup is on the Advanced tab.
John Silva (Dec 08 2021 at 19:51):
Added Jira ticket: FHIR-34430 for this CarePlan.intent problem.
Last updated: Apr 12 2022 at 19:14 UTC