CDS Pharmacy FHIR request
|
Related Links |
primary CDS contact: Bryn Rhodes
The Issue / Request
The CDS Work Group as part of reconciling ballot comments for the CQF-on-FHIR Ballot has created a resource in FHIR that can be used to describe "templates" for intent resources like MedicationOrder, ProcedureRequest, etc. The resource is called ActivityDefinition (https://hl7-fhir.github.io/activitydefinition.html).
As part of specifying the template for a MedicationOrder, we need to be able to specify the dosageInstruction and dispenseRequest elements. Rather than copying the element from the MedicationOrder resource definition, we are planning on defining a DosageInstruction and a DispenseRequest type that we could reference, rather than duplicating the maintenance of those elements. Question to Pharmacy WG: Do you have any questions or concerns with this approach? The initial step is just to define the data types based on the MedicationOrder structure and will not involve any changes to the MedicationOrder resource.
- Pharmacy WG has some concerns about the fact that CDS may be creating concepts that duplicate constructs managed by Pharmacy WG
Options
- Convert backbone elements to datatypes in MedicationOrder essentially the request, with some response/analysis. (summarized by Scott R on 7/18/2016 ... Bryn and others should validate)
- ActivityDefinition has some elements of MedicationOrder
- As different possible activities are added to ActivityDefinition, various structural pieces are added rather than the resource associated with the activity. Where the new activity has a structural piece that already exists in ActivityDefinition, that piece does not have to be added a second time.
- however, MedicationOrder.dosingInstruction is a backbone element. Cannot reference, must recreate in ActivityDefinition. This is the core of the request, convert select(/all?) MedicationOrder backbone elements to datatypes.
- Concern: If MedicationOrder.dosingInstruction was converted to a datatype, then ActivityDefinition could use that datatype and maintain consistency with Pharmacy domain.
- Positive: Pharmacy could re-use the datatypes to insure consistency in Pharmacy resources
- Have ActivityDefinition use a definitional form of MedicationOrder (summarized by Scott R on 7/18/2016 ... others should validate)
- MedicationOrder is a complete concept. Using various parts independently to specify how to build a new MedicationOrder will require ActivityDefinition to "understand" what makes a valid medication order.
- FHIR Workgroup discussions have requested Pharmacy add an element to identify the resource as a definition rather than an instance. (do I have that right? -smr)
- Positive: ActivityDefintion stays aligned with MedicationOrder as MedicationOrder elements are added/changed
- Concern: seems that there is not a consistent recollection of what FHIR Workflow intended their new element to do. Potential blurring of Definitional / Intentional / Event applied to Resources.
July 18 Update
- discussion
- enable vendors to share order sets and definitions
- used an instance of a Request resource such as Medicationorder - status portions and dynamic portions
- moved to Activity Definition resource - conceptual definition
- for MedicationOrder - what to include dosageInstruction and dispenseRequest - don't want to recreate all of that content
- Want Pharmacy WG to define the content - define a datatype in FHIR - e.g. dosage instruction - in the activity resource would include a usage context
- allows all work groups to re-use the same content
- discussion of how CDS has defined the prescription or medication activity - currently don't point to medicationOrder
- suggestion that a datatype may be an option but that it will not be done it time for the freeze for STU3 - would need special permission to put a substantive change in to the release
- continue to discuss on our teleconferences and possibly include time on the agenda for Baltimore
