Stream: implementers
Topic: DataRequirement
Stefan Dimitrov (Jan 16 2017 at 20:06):
How do we refer to extensions using DataRequirement? For example if we need birthTime what do we put in mustSupport? can't just put "extension" as this would match any extensions on Patient.
Bryn Rhodes (Jan 16 2017 at 23:42):
You would have the DataRequirement refer to a profile that specified the extension. I realize that doesn't quite convey the same meaning, so I'm thinking about how you would specify mustSupport.
Bryn Rhodes (Jan 16 2017 at 23:43):
I suppose if the extension is listed in the profile, you are effectively saying, you must give me a Patient that conforms to a profile that contains this extension, so that implies that you must support the extension, right?
Stefan Dimitrov (Jan 16 2017 at 23:43):
Yeah. profile is QI-Patient, it doesn't specify the field.
Stefan Dimitrov (Jan 16 2017 at 23:44):
But I want birthTime from the patient, mustSupport should indicate that birthTime is used.
Bryn Rhodes (Jan 16 2017 at 23:45):
QI-Patient includes birthTime: http://build.fhir.org/ig/cqframework/qi-core/qicore-patient.html
Stefan Dimitrov (Jan 16 2017 at 23:46):
but this doesn't tell the consuming system that birthTime is the field we are looking for, a QI-Patient has many fields.
Bryn Rhodes (Jan 16 2017 at 23:46):
Yeah, it's not quite the same as mustSupport, I agree.
Bryn Rhodes (Jan 16 2017 at 23:48):
So mustSupport is just a string, you could just put the code of the extension in, so patient-birthTime in this case.
Bryn Rhodes (Jan 16 2017 at 23:49):
Can you submit a tracker on this?
Stefan Dimitrov (Jan 16 2017 at 23:50):
sure, a tracker to update the documentation or to modify DataRequirement?
Bryn Rhodes (Jan 16 2017 at 23:51):
To support the use case. I'd propose using the code of the extension, but would want feedback and review from others about whether that's the right approach.
Stefan Dimitrov (Jan 16 2017 at 23:52):
Ok, thanks.
Stefan Dimitrov (Jan 17 2017 at 15:39):
Another question for DataRequirement: what is the correct FHIR way of indicating that a resource which was prompted for through a DataRequirement does not apply to a Patient? For example, the DataRequirement page gives an example of Procedure -> Total Colectomy Value Set . The expectation is if the patient had this procedure the system receiving the DataRequirement will add it to the patient record. What if the patient did not have the procedure performed or there is no information about it, how can the receiving system of a DataRequirement respond that the resource doesn't apply to the given patient?
Stefan Dimitrov (Feb 13 2017 at 22:41):
How do we specify the type of a choice or Reference field in "mustSupport" of DataRequirement (http://build.fhir.org/metadatatypes.html#DataRequirement) ? We need to communicate to the system that a specific type is required for a given field in mustSupport.
Bryn Rhodes (Feb 13 2017 at 22:43):
Specify a profile that indicates the type.
Grahame Grieve (Feb 13 2017 at 22:45):
e.g. http://hl7.org/fhir/StructureDefinition/Coding - that is the URI for the base Coding data type
Stefan Dimitrov (Feb 13 2017 at 22:47):
@Grahame Grieve so this means we need to create a profile on the DataRequirement "type" resource which restricts the type of choice/Reference fields in the mustSupport path?
Bryn Rhodes (Feb 13 2017 at 22:48):
No, you create a profile on the type that you want to restrict the type of the choice and specify that profile in the DataRequirement.
Stefan Dimitrov (Feb 13 2017 at 22:49):
Right. So if we have a DataRequirement for type "Observation" which requires valueQuantity we create a profile on "Observation", restrict the value field in it and add that profile to the profile field in the DataRequirement?
Bryn Rhodes (Feb 13 2017 at 22:49):
Yes, exactly.
Stefan Dimitrov (Feb 13 2017 at 22:50):
Ok, thanks.
Bryn Rhodes (Feb 13 2017 at 22:50):
mustSupport can only indicate that that element is referenced by the logic, it doesn't allow you to put any constraints on the type of the element, you need profiles for that.
Lloyd McKenzie (Feb 13 2017 at 23:17):
If you have a choice of data types and want to declare some as "must support" and others as optional, you can slice by type
Sadiq Saleh (Feb 16 2017 at 19:03):
@Lloyd McKenzie, using slices does not appear to fix the problem for our use case. Specifically for the following example:
1) A profile on Condition has a list of 6 slices for stage.Assessment.
2) Using DataRequirement I would like to specify that I require only slices 2, and 6
I can specify stage.Assessment in DataRequirement.mustsupport, but how do I specify that I only require specific slices?
As far as I understand the string in DataRequirement.mustsupport refers to the path which is the same among all slices.
Appreciate your feedback.
Eric Haas (Feb 16 2017 at 20:39):
the cardinality of siices 2 and 6 would be 1..1 and the rest 0..1
Sadiq Saleh (Feb 16 2017 at 21:49):
Can you set the cardinality of the slices in datarequirement? I thought that they can only be set in the profile, which would mean I would have to create one profile to use slices 2 and 6, and a second profile to use slices 1 and 5 at another time?
Bryn Rhodes (Feb 16 2017 at 23:45):
You can't specify slice cardinality with a DataRequirement.
Bryn Rhodes (Feb 16 2017 at 23:45):
The whole point of a DataRequirement is that it's potentially inferrable and that you can reason over them (combine them to produce a "covering" set).
Sadiq Saleh (Feb 17 2017 at 18:40):
So to come back to my original question then, how can I refer to specific sllice(s) in an array for datarequirement since the path is the same for all the slices.
Sadiq Saleh (Feb 21 2017 at 16:26):
Would it make sense to have a urifilter attribute for datarequirement, to allow references to specific profiles instead?
What this would mean is that you could specify a path (e.g. Condition.stage.assessment.reference.resolve().meta.profile) and specify a list of uri's that should be returned, and thus what profiles should be returned?
Bryn Rhodes (Feb 21 2017 at 16:34):
I'm not sure I understand, how is this different than what's there now? You can specify a type and an optional profile.
Stefan Dimitrov (Feb 21 2017 at 21:36):
How do you specify a type now @Bryn Rhodes ? DataRequirement only allows a path in "mustSupport", We need a way to tell the receiving system that a given reference on the path is a specific Profile. For example, if you have Condition, the context may be Encounter or EpisodeOfCare. If our mustSupport = "context.length" how does the receiving system know we want the length of an Encounter ? If we had a uriFilter like we have a codeFilter then we could put in there that "context" is a profile of Encounter and not EpisodeOfCare.
Bryn Rhodes (Feb 22 2017 at 04:49):
Okay, I see what you're saying, and I was referring to the ability to specify type and profile for the root type of the data requirement. For mustSupport, what you are saying is only that your logic references that path, not that it has to be of a particular type. For the Condition example, what you'd be saying with a path of context.length is that you accessed the length attribute of the context element. If you access the length and the runtime value happens to be an episodeOfCare, you'll get a null (the path is a FhirPath expression, so accessing length returns an empty list). If you want to require that the context is an Encounter, you need to specify that information with a profile of Condition.
Bryn Rhodes (Feb 22 2017 at 04:50):
@Stefan Dimitrov sorry, forgot to tag you.
Stefan Dimitrov (Feb 22 2017 at 14:39):
@Bryn Rhodes thank you for the detailed response. In the first case (null value) the end result will be a failed use case for users, largely because the two systems (DataRequirement provider and DataRequirement consumer) failed to communicate what type of data is needed. If we could add the uriFilter it would enable a more user friendly experience where the EHR system can pre-fill the resources according to the DataRequirement "mustSupport", leaving the physician to provide only concrete patient-specific details. The second option (specific profile per resource reference) would require defining the profile on the fly (based on the underlying library / CQL) and will put an unnecessary burden on the receiving system to retrieve, parse and process profile definitions on the fly. We can't just pre-define the profile, it depends on runtime CQL evaluation.
Bryn Rhodes (Feb 23 2017 at 23:28):
@Stefan Dimitrov for me there are two separate considerations here: 1) Is the consuming system likely to be able to use a uriFilter to determine what should be populated? and 2) What is the impact of adding the notion of a uriFilter to the DataRequirement? For the first consideration, I would suggest that it's currently not very likely, we're not even sure how likely it is that they'll be able to dynamically react to the currently specified information in a DataRequirement, so adding functionality without knowing where that line is seems premature. For the second consideration, which I think is more impactful to the design of DataRequirement, the question is how likely is a uriFilter to correlate with an underlying access mechanism (like an index). The current filters of code and date were specifically chosen because they are ubiquitous in storing and searching clinical information, so they are the most likely to match up with (and have the most selectivity for) existing systems. It's unlikely that a uriFilter would correspond to any specific access mechanism, so adding it to the DataRequirement would increase the implementation burden for an underlying data access layer but without any significant pefrormance improvement.
Travis Stenerson (Jun 27 2017 at 17:27):
Few questions about DataRequirement. First, is this metadata type going to be impacted at all by the GuidanceResponse deprecation?
Second (and if not), how does one signify in 'mustSupport' that you would like to interpreting system to include a particular extension. The path alone is insufficient to say "please send me a condition resource with the body-structure extension" unless you use FHIRPath filtering function like:
"mustSupport": [{
"extension.where(uri = http://hl7.org/fhir/StructureDefinition/body-structure"
}]
What is the proper mustSupport string value here? Is it sufficient to enforce this through the StructureDefinition of the profile referenced by 'dataRequirement.profile'?
Thanks
Grahame Grieve (Jun 28 2017 at 03:29):
@Bryn Rhodes - for you
Bryn Rhodes (Jun 28 2017 at 17:21):
For the first question, no, the GuidanceResponse deprecation will not impact DataRequirement, GuidanceResponse just used DataRequirement to communicate additional data needs as part of a decision support response.
Bryn Rhodes (Jun 28 2017 at 17:29):
For the second question, we've had discussions about that, but haven't landed on what it should look like. Right now, the mustSupport documentation just says "it can be a path", but doesn't give any specifics about what that path can look like.
Bryn Rhodes (Jun 28 2017 at 17:30):
Using a FHIRPath is a possibility, but it would need to be constrained to only allow for paths, and the need to allow for selecting extensions complicates that.
Bryn Rhodes (Jun 28 2017 at 17:32):
Of course, you could use a profile that specified the extension and indicated must support there, but that could lead to an explosion of profiles.
Bryn Rhodes (Jun 28 2017 at 17:33):
Do you mind submitting a tracker to clarify the allowed "paths" for DataRequirements and allow for selecting extensions?
Travis Stenerson (Jun 29 2017 at 14:26):
[#13593] Summary: Clarify allowed paths in mustSupport for DataRequirement
Let me know if there are problems with the submission, my first tracker. Thanks Bryn.
arif khan (Jul 03 2017 at 12:14):
does HAPI Fhir only support IBaseResource resources? or can we convert custom resource to IBaseResource.
Bryn Rhodes (Jul 03 2017 at 19:04):
This might get more traction as a HAPI stream posting
Catherine Hosage Norman (Jul 13 2021 at 03:53):
What would be the type code value in the DataRequirement metadatatype if I want to use the limit to indicate the number of results, i.e. repetitions of a goal in planDefinition? The target of the goal can be any of the detail types, and there are cases where there are many targets for a goal and they can be different types.
Lloyd McKenzie (Jul 13 2021 at 04:11):
@Bryn Rhodes
Bryn Rhodes (Jul 14 2021 at 19:25):
Hi @Catherine Hosage Norman , that sounds like a constraint you would express in a profile, rather than with a DataRequirement. Can you provide a bit more context to help me understand the use case?
Last updated: Apr 12 2022 at 19:14 UTC
