Stream: questionnaire
Topic: SDC Extraction : simple with a profile
Brian Kaney (Dec 16 2020 at 14:33):
I would like to use the "simple" Observation -based extract option, but would like to specify a profile (for the eventual Observation) to use. I was thinking of two options:
1) Use item.definition (but do not include the # segment) to refer to the StructureDefinition for the profile
2) Create a new extension on item.
I am leaning toward (1) but it seems like it would conflict the guidance in the spec "Implementers are free to try combining this mechanism with the Definition-based approach. If they do, they should take care that a given item (and its children) are only handled by one approach or the other - not both."
Any thoughts/recommendations on how to do this?
Lloyd McKenzie (Dec 16 2020 at 16:26):
What are your objectives in specifying a profile rather than the base resource?
Brian Kaney (Dec 16 2020 at 17:20):
I have a profile on Observation. In this first specific case, it specifies the category.
Lloyd McKenzie (Dec 16 2020 at 17:23):
So your intention is that by specifying a profile, certain fixed values would be auto-populated into the extracted Observation?
Brian Kaney (Dec 16 2020 at 17:33):
Right. A variation on the Observation-based extract where you can also specify a profile on Observation. So the same extract rules apply, but would ensure the result conforms to the profile (in this case, fixed category code). I think there are lots of IG out there with Observation profiles that might be asked for in a survey as well, so I hope this is more than just my problem :)
Lloyd McKenzie (Dec 16 2020 at 17:36):
I don't think there's any way to ensure that the result complies with the profile. The best you could do is auto-populate fixed values, and perhaps have the item paths be aware of slicing names when performing extractions.
Lloyd McKenzie (Dec 16 2020 at 17:36):
Can you submit a change request for us to discuss this?
Paul Lynch (Dec 16 2020 at 18:49):
Would something doing the extraction just be expected to set meta.profile, or to know that a particular profile means add a particular category?
Brian Kaney (Dec 16 2020 at 20:37):
@Lloyd McKenzie -- that is a good point. e.g. there would be no way to specify to fix the category.
@Paul Lynch -- yes, the profile fixes category to be survey, and in this case the Questionnaire is an AOE survey. I want to be able to differentiate Observations from the survey from others.
Paul Lynch (Dec 16 2020 at 23:51):
@Brian Kaney Couldn't you differentiate by meta.profile? You could search for them using _profile.
Elliot Silver (Dec 17 2020 at 00:21):
Wouldn’t Observation.derivedFrom work? You could then tie that to the canonical URL of the questionnaire in QuestionnaireResponses.questionnaire? Alternatively, isn’t there a role here for providence?
Brian Kaney (Dec 18 2020 at 14:16):
@Paul Lynch - I will think about that. I haven't used profile in that way before (e.g. for querying purposes). So if I understand what you are proposing -- the semantics would be if an Observation is known to conform to a profile (e.g. it has a profile claim and we trust the server has validated it), it is of a certain kind of Observation?
@Elliot Silver - I think either of these could work in this case (of knowing the Observation came from a survey)
But I was wondering if there was a more general solution for specifying Observation profiles with questionnaires. For instance if we wanted to ask a question about a patient's TNM stage and would like to specify the Observation would use a profile such as http://hl7.org/implement/standards/fhir/us/mcode/StructureDefinition-mcode-tnm-clinical-primary-tumor-category.html
Paul Lynch (Dec 18 2020 at 14:25):
That sounds to me like what Observation.code is for. The page you link to suggests LOINC code 21905-5.
Brian Kaney (Dec 18 2020 at 14:32):
@Paul Lynch - So would a general solution be to ensure the questionnaire item would only ever allow for a valid Observation (e.g. code, available answers) and then specify the profile in item.definition (without a# segment). When extracting the Observation use the Observation-based technique, then simply copy over the definition and add to the Observation.meta.profile list?
Paul Lynch (Dec 18 2020 at 14:40):
Observation based extraction is based on item.code, which becomes the Observation code. It there is a list associated with that code (e.g. a LOINC answer list), you would make sure the Questionnaire definition has the correct list. The derivedFrom field would get set to the QuestionnaireResponse (a reference). Given a particular Observation, you could check derivedFrom to know whether it can from a Questionnaire, and you could query for Observations that came from a particular patient's QuesitonnaireResponse, but I don't think you could search the server to get a list of Observations that came from any QuestionnaireResponse. (I'm not sure if that is what you want, anyway.) item.definition gets used for other purposes, so I am uneasy about putting a profile URL there. If putting a profile on it is important (though I am still not sure why people do that, when there is there is Observation.code) then I think a new extension would be needed.
Brian Kaney (Dec 18 2020 at 14:52):
Thank @Paul Lynch for helping me think through this!
but I don't think you could search the server to get a list of Observations that came from any QuestionnaireResponse
My use-case is to know that an observation came from a survey (verses somewhere else, such lab results). So for me using derivedFrom will work nicely.
If putting a profile on it is important (though I am still not sure why people do that, when there is there is Observation.code) then I think a new extension would be needed.
Well I think it is important as I would like to validate the extracted Observation when it comes time to save it. But maybe I am alone in this thinking this is important...
Paul Lynch (Dec 18 2020 at 15:02):
You are definitely not alone, but I don't understand the reasoning behind it. If the profile just tells you that the Observation should have a certain code, then why not just validate the code? But, I think you started out saying the profile specifies a category for the Observation, and not it's code, so maybe there is some utility if you are trying to constrain more that one field.
Last updated: Apr 12 2022 at 19:14 UTC
