Stream: implementers
Topic: Protocols & FHIR
Julia Davis (Jul 10 2017 at 23:41):
Hi,
As part of our Medications Management application the clinicians can prescribe protocols. The basic details of the protocols are created and stored so that the clinician can select to 'prescribe by protocol', choose the category of protocols then work through a tree to the protocol required. e.g. Bacterial Infections --> Urinary Tract Infections --> ..... When they select the required protocol the details are returned with most of the order information prepopulated and ready for acceptance / edit by the clinician. It is possible for the protocol to define 'optional' medications and a choice of medications "OR" orders. The clinician decides whether to include the optional medications and which of the OR medications at the point of prescribing.
I would appreciate any help / clarification on:
1) How should we pass results / handle tree structures in FHIR when another application requests to prescribe via protocol?
2) How do we provide details of optional medications, OR medications etc.?
At the moment we are considering bundles of bundles of bundles of MedicationRequests but we are not sure this is the correct / best way to achieve what we need.
Many thanks
Julia
Lloyd McKenzie (Jul 11 2017 at 00:59):
Look at the RequestGroup. It's intended to handle requests where there's conditional and/or temporal constraints between them. So your root would be RequestGroup (probably with intent=proposal) and all of your MedicationRequests would have intent=option.
Julia Davis (Jul 11 2017 at 02:12):
Thanks @Lloyd McKenzie McKenzie
I will take a look at the RequestGroup.
We have structures something like those in the attached document. We may receive a request simply for "protocols" or we may receive a request for protocols with a name / partial name for searching so there may be multiple levels
Protocol-Document-for-FHIR-Chat.pdf
Grahame Grieve (Jul 21 2017 at 10:41):
@Bryn Rhodes RequestGroup really does need a better name.
Rick Geimer (Jul 21 2017 at 13:51):
@Bryn Rhodes @Grahame Grieve What about RequestList, then align it with the List resource (i.e. add RequestList.code to identify the purpose of the list, etc.)?
Grahame Grieve (Jul 21 2017 at 14:12):
I think the 'request' bit is the misleading part
Lloyd McKenzie (Jul 21 2017 at 15:15):
We don't want to align it with List - it's not necessarily a flat list. It can group things in complex sequential patterns. "Request" is what we use for proposals, plans and orders. What other name would you propose @Grahame Grieve ?
Bryn Rhodes (Jul 21 2017 at 16:50):
Plan?
Grahame Grieve (Jul 21 2017 at 20:40):
ConditionalAction
Grahame Grieve (Jul 21 2017 at 20:41):
RequestGroup makes it sound like a group of things you've asked to happen - so maybe, TaskGroup
Lloyd McKenzie (Jul 22 2017 at 21:01):
That's what RequestGroup is - a group of things you've asked to happen - either a proposed group, a planned group or an ordered group.
Julia Davis (Jul 24 2017 at 01:11):
Hi All,
This is very interesting for me to be following as I have looked at the RequestGroup and could see how I could use this for the protocols but the above conversation has me wondering if I would be using it correctly.
If the RequestGroup is a group of things you've asked to happen I can see that working for a selected protocol where there are multiple steps and medications involved as you would be requesting that the medications contained in the protocol are ordered / administered etc.
I'm not sure though that I should be using this to return the list of available protocols / protocol categories would this resource still be appropriate?
Also, are there any generally accepted practices when it comes to returning large amounts of data? The application wishing to access the protocol data has documented that all the data should be returned i.e. all the medications, in all the protocols, in all the categories..... this could be a vast amount of data depending on the number of protocols established within an organisation.
We have suggested that they search for the appropriate protocol category in 1 step and then drill down from there but I would be very keen to hear peoples opinions.
The original attached document shows the structure for the protocols within the source application.
Lloyd McKenzie (Jul 24 2017 at 01:14):
Protocols (definitions of what can/should happen on a patient-independent basis) are covered by PlanDefinition. Patient specific plans/proposals/orders are handled with RequestGroup. There are definitely people experimenting with large data sets for FHIR - I'll let them express their experiences/recommendations.
Sadiq Saleh (Jul 27 2017 at 19:43):
Look at the RequestGroup. It's intended to handle requests where there's conditional and/or temporal constraints between them. So your root would be RequestGroup (probably with intent=proposal) and all of your MedicationRequests would have intent=option.
MedicationRequest.intent is currently bound to valueset MedicationRequestIntent with a required behaviour. This valueset does not contain "option" as a value. Should I file a tracker to update this valueset, or to bind it to the valueset RequestIntent?
Bryn Rhodes (Jul 27 2017 at 23:16):
Yes, please do. That may be true of the other request resources as well.
Lloyd McKenzie (Jul 28 2017 at 05:47):
We're close to being able to run a report that will identify all of these, but in the meantime, change request is your best bet.
Sadiq Saleh (Jul 28 2017 at 16:10):
Gustav Vella (Aug 05 2018 at 10:00):
Hi Julia,
I'd be intersted to know how you tackled this. Does your Medications Mgmt App generate and consume fihr resources? Is it exposed to the FHIR API and reference libraries?
I'm dealing with something similar with study protocols. The regimen & dosage and allowable dosage & schedule modification are in focus and the requirements similar to those in standard protocols. https://www.hl7.org/fhir/researchstudy.html Among other attributes it also contains the “protocol” attribute, which also defines PlanDefinition https://www.hl7.org/fhir/plandefinition.html). In order to define Study Medication we can use RequestGroups (https://www.hl7.org/fhir/requestgroup.html. The name is confusing but it does the job. CarePlan https://www.hl7.org/fhir/careplan.html actually does allow 0..* references to RequestGroups, but PlanDefinition doesn't. The PlanDefinition Resource allows ActionDefinitions.
As to your question on how to "pass on results" - do you mean Pre-populating a questionnaire? or Extracting data from a questionnaire after entry and populating other resources? In that case take a look at @Grahame Grieve's recent article http://www.healthintersections.com.au/?p=2835 on "active questionnaires" .. sounds a bit like science fiction. I'm trying to find out follow up/ people trying it out and am surprised there's not more buzz about it here.
Gustav
Bryn Rhodes (Aug 05 2018 at 22:37):
@Gustav Vella "but PlanDefinition doesn't." In the PlanDefition space, the definition element can point to another PlanDefinition, which should support what you're after here.
Last updated: Apr 12 2022 at 19:14 UTC
