Stream: implementers
Topic: Recommending medication as a custom operation
Philip Simonsen (Apr 15 2019 at 09:14):
Hey guys. I am trying to implement a system to recommend medication for a patient automatically as a microservice. The plan is that the system updates the patient with a new recommended amount of medication to take based on previous Observations and previous MedicationStatements posted to the server, then returning a RequestGroup with the recommended steps to take. The new MedicationRequest will then be posted to the server to use for the algorithm. Looking into the best ways of automating this though, it seems like a PlanDefinition or ActivityDefinition doesn't fit the bill, as running the $apply operation on them is idempotent, so it shouldn't change the state of the server, which is required. It seems to me like the only way for this to work is through a custom operation defined on the server. Is this the correct way of doing this? Or is there a better, more generic way?
Jose Costa Teixeira (Apr 15 2019 at 10:27):
The plan is that the system updates the patient with a new recommended amount of medication to take based on previous Observations and previous MedicationStatements posted to the server, then returning a RequestGroup with the recommended steps to take.
First, I think you do not mean Update the patient, but update the patient's medication plan with the request group, right?
Jose Costa Teixeira (Apr 15 2019 at 10:30):
I don't understand what you want as output - a medicationrequest with the medication? a requestgroup with more medications? a treatment plan (with what?)
Jose Costa Teixeira (Apr 15 2019 at 10:32):
the apply simply instanciates the plan to a given patient / context.
Jose Costa Teixeira (Apr 15 2019 at 10:33):
what do you mean "automating this"? what do you want to automate? The application of a given algorithm to a patient?
Jose Costa Teixeira (Apr 15 2019 at 10:35):
the $apply operation creates a careplan. In my understanding it is idempotent in that if you $apply several times, you still get the same care plan. Not sure what you mean with changing the state of the server.
Jose Costa Teixeira (Apr 15 2019 at 10:35):
(sorry for many questions, jsut trying to guess your goal from your statement)
Philip Simonsen (Apr 15 2019 at 11:09):
No problem. Not too sure on what my goal is right now, as I keep finding alternative ways to do this.
Yes, I just want to update the current medication plan for the patient on the server, not the actual patient. As for the output, I ideally want a RequestGroup with all the steps needed for the patient to do to improve. A MedicationRequest will be a part of this, which should also be posted to the server as the new medication plan for the patient. By automating this, I mean that this should run as a standalone service, on it's own server. The people using the server should just have to post the a new observation for the patient, and that should automatically generate the RequestGroup output based on previous observations and medication plans. I also want the people using the server not have to give all the parameters needed for the algorithm to run (previous medication plans and observations), it should be stored on the server.
I guess a PlanDefinition would not be good enough then, as I want to do more than just generate a plan given a context.
Jose Costa Teixeira (Apr 15 2019 at 11:14):
k, interesting stuff. I would actually do CarePlan, not Request group. For a shorter scope, PlanDefinition can hold requests or reques groups, so it is an envelope. and when you want to also put dependencies and advanced steps, plandefinition will cover it, and requestgroup won't.
Jose Costa Teixeira (Apr 15 2019 at 11:16):
sounds like your request is:
How to automatically trigger the creation / update of a careplan for a patient, from a given trigger e.g. posting of an observation for that patient, and having the server consult whatever information is needed to create that plan beyond what has been provided in the observation.
Correct?
Jose Costa Teixeira (Apr 15 2019 at 11:17):
I don't think that falls into the scope of what FHIR does now. I may be wrong.
Grahame Grieve (Apr 15 2019 at 11:19):
we've never really discussed stanardising triggers for consequential actions. We have event definition... but not any way to express an expectation that it will work like that. We probably wouldn't make any such rule in the base standard, but it would make sense for IGs to do exactyl that
Philip Simonsen (Apr 15 2019 at 11:24):
Alright, I'll look into other ways of doing this then. Thanks a lot the help!
Last updated: Apr 12 2022 at 19:14 UTC
