Stream: implementers
Topic: Request.reasonCode and reasonReference
Travis Stenerson (Aug 28 2017 at 14:19):
Is it valid to use both of these fields for similar but different uses within the same resource? I don't see a constraint preventing both of their existences concurrently.
The use case is I would like to refer to the disease this Request is meant to address, and refer to the overall category of medication (endocrine therapy vs chemotherapy for breast cancer). Would .category be a better place for this than reasonCode despite the 'preferred' binding?
Thanks
Jose Costa Teixeira (Aug 28 2017 at 14:26):
which .category do you mean? if medicationRequest.category, then it seems a bit closer to what you describe.
medicationRequest.category is the category of the request, while you seem to want the category of the medication, right?
Jose Costa Teixeira (Aug 28 2017 at 14:27):
however, reason could also be used, if you wnt to express "i give this medication because this patient needs endocrine therapy"
Jose Costa Teixeira (Aug 28 2017 at 14:32):
it seems a very thin boundary. to me it seems that this would be determine by whether you mean to express that notion as a justification (reason) or as a group/class of treatment (category).
Travis Stenerson (Aug 28 2017 at 15:07):
Category fits better, but the preferred VS and description (where this medication is to be consumed) made me hesitant. The reasonCode fits too, but does not fit quite as well, this medication is given because the patient's tumor needs endocrine therapy, or because the patient's tumor needs chemotherapy. My preference for reasonCode is because a RequestGroup also has reason code, and some of these medications (endocrine as well as chemo) are given as regimens that I intend to group.
Lloyd McKenzie (Aug 28 2017 at 15:23):
@Melva Peters ?
Melva Peters (Aug 28 2017 at 15:50):
The reason codes in the MedicationRequest are intended to capture why the medication is being prescribed/ordered by the prescriber or the "indication for use". It isn't necessarily a diagnosis, it could be for a symptom. It is possible that the requester could include one or more reasons via codes - where it is a condition, diagnosis or problem. For example, medication is being prescribed for "Blood Pressure Elevation" (Snomed CT 24184005). The requester can also include one or more references to a specific condition or observation as the reason for requesting the medication. For example, I'm prescribing this medication because of the vital signs for Blood Pressure Measurement. Pharmacy WG hasn't considered limiting this to a code or a reference as it was felt that it could be either or both. I do not believe that category is the right place to capture this information.
Jose Costa Teixeira (Aug 28 2017 at 15:53):
I see "category" as any information that is used for categorizing the request. For example inpatient, ambulatory, daycare.. these are things that can condition the workflow.
Jose Costa Teixeira (Aug 28 2017 at 15:56):
The case described by Travis reminded me of one implementation where we had an element which determined the type of treatment. If it were "chemotherapy" it would be handled not by software app #1, but by software app #2. That is why i would point for that.
Jose Costa Teixeira (Aug 28 2017 at 15:59):
if you would want to express a group of reasons, reasonCode would be good. If it for a classification of a medication, i don't think there is anything. I would point to category in the unique case where that "reason" is actually an expected treatment of the order - type of order and where/how it is being processed. Does this make sense?
Travis Stenerson (Aug 28 2017 at 16:15):
@Melva Peters
So what is the best field to capture that this regimen or med-request is 'endocrine therapy' or 'chemotherapy'.
Melva Peters (Aug 28 2017 at 16:19):
I don't believe that there is an attribute in the MedicationRequest that is appropriate for that. I suggest that you add a Gforge tracker item that describes your use case for consideration.
Last updated: Apr 12 2022 at 19:14 UTC
