I have separately discussed this topic with a few folks and thought it wise to get everyone’s views.
We are increasingly faced with a need to document and track procedure orders in our implementation. The ask is to enable a provider to request a procedure i.e. wound dressing and have the status of this request tracked and documented accordingly.
Currently, the concept dictionary provides concepts of procedure class and in addition, provides a terminology construct for documenting a procedure. This can work well in contexts where interest is in the procedures that are performed. It doesn’t support a seamless tracking process and user experience from the time a request is made through fulfillment of the request in a lab, theatre, etc.
I would like to propose a domain object in OpenMRS that will allow seamless ordering and tracking of procedure fulfillments in the system. This will help us to also support the FHIR procedures out of the box in the system. Do we have any previous or current efforts in this area in the community? Kindly share one, or a thought.
Just to mention, for procedure orders that are Imaging studies (Radiology) additional information is captured about the fulfilment of the request. This has been represented in fhir as Imaging study resource and can as well be mapped into an OpenMRS data model
We discussed this on our last Bahmni PAT call and also subsequently with the team who are working on the IPD side. We are primarily looking at Surgeries, but that can be modeled for any type of procedure (surgical or not). Bahmni’s OT scheduling is about scheduling surgery blocks and planning for the surgery, and not really for documentation of the procedure. Some thoughts
Bring in a “procedure” model onto OMRS that can be based on an order (service request).
Through this procedure, we record all possible documentation relevant to the surgery. I.e participants, complications, reports, pre+post op details, also if any reports (e.g. biopsy from extracted tissue) and any other surgical notes, interventions etc
We don’t want just another “Form” capturing some details, not correlated together and without recording/associating relevant details for a specific procedure/surgery.
We can collate and aggregate all information relevant to a surgery to the model
Checklist can be either through tasks or obs form.
Similarly pre and post op details can be also attached to the procedure. Since the procedure itself is another concept, we can leverage concept Attributes to define specific instances of PAC, Pre & Post Op Forms.
Build a comprehensive UI around procedure collating all information and displaying appropriately and any task done or to be done relevant to that - pre/post of notes, outcomes, reports, complications, performers etc
The procedure and relevant workflows can be be initiated from Bahmni’s OT module.
I think procedures are already basically orderable as-is in OpenMRS using the ServiceOrder class. If there are additional details we need to capture as part of orders, we should make them there.
It probably makes sense to have some sort of domain to document the procedure itself as @angshuonline suggested. Could we potentially at least move the data model for this into a module shared between OpenMRS and Bahmni to allow for collaboration?
Requesting a procedure be done would be done through an order (ServiceRequest) and probably doesn’t need a new resource (properties needed to request a procedure and are likely provided by base Order model in OpenMRS).
I believe FHIR’s approach would be to use ServiceRequest (OpenMRS Order) to request the procedure, Task to track completion (missing in OpenMRS model, but would be a great addition to OpenMRS), and Procedure to record details about the procedure event itself (missing in OpenMRS, but would be a great addition).
We would want to extend the frontend, the order basket, to support the additional procedure order. Is there a way we can nicely extend the order service through this new module and just add logic to handle the new order? I am trying to avoid an implementation that will still require customization of the existing order basket to support the new order. One approach is the use of @primary annotation. Does anyone have reservations on it’s use in such context?
Just to expound on that we exploring on how to reuse existing orders logic as much as possible while exploring addition of procedures through a module. When persisting any type of order there is a helper method ensureOrderTypeIsSet that sets order types if it has not been set.
Order Type is passed as part of the order’s create payload but if it’s not set the method tries to infer this from the ordered item concept class and checks where the order is an instance of Drug, Test, Referral. The later is what always executes, I saw the setting of order type at rest was skipped but I don’t fully understand the design behind this.
So the question is, while doing an instance of order within a module, how could we possibly handle setting of order types
On the design call it was suggested that you can choose to treat Procedure orders as plain Orders unless there is extra data fields you want to include on the order, in this case you would have to add an order type row that maps to your new order subclass which in turn is mapped to concept classes via OrderType.conceptClasses field, the API will auto assign the order type based on the orderables’ concept classes as seen here
@jecihjoy to your last question, you will need to create a subclass of BaseDelegatingSubclassHandler for your Procedure order subclass in the module, override the getTypeName method to return a logical type name, and then when submitting your ProcedureOrder via rest include a type field in the payload with its value set to the logical type name to tell the rest API to create an instance of Procedure order.
@wyclif I tested the assigment of order type and it was not being done from the value specified from rest but rather these was the logic that was doing the order types assignment which requires core to know the Order classes
if (orderType == null && order instanceof DrugOrder) {
orderType = Context.getOrderService().getOrderTypeByUuid(OrderType.DRUG_ORDER_TYPE_UUID);
}
if (orderType == null && order instanceof TestOrder) {
orderType = Context.getOrderService().getOrderTypeByUuid(OrderType.TEST_ORDER_TYPE_UUID);
}
if (orderType == null && order instanceof ReferralOrder) {
orderType = Context.getOrderService().getOrderTypeByUuid(OrderType.REFERRAL_ORDER_TYPE_UUID);
}
Ideally it should be this using data passed from rest but the data is not being passed and orderContext is always null
if (orderContext != null) {
orderType = orderContext.getOrderType();
}
Are you saying that you are placing a TestOrder via rest where the orderable’s concept class is included among those defined for the test order type row in the database and it is still not working, right? Can you confirm this in the database? If that’s the case then it sounds like a bug. Surprisingly, when I comment out that line that assigns the order type based on a concept class no test in OrderServiceTest fails which implies a dev forgot to include tests for that feature, so may be it does not working as expected. It would possibly be nice to add this test and if it fails, you submit a ticket to get it to work.
Introduced a new ProcedureOrder that extends ServiceRequest
Introduced a Procedure domain to document procedure-related information. This has borrowed so much from FHIR specification
Extended REST resources to support for Procedure and the orders
Areas for further design
How should we capture procedure participants? Is it OK to leverage the existing EncounterProvider, and document the participants as providers? This, however, will require introducing an encounter property in the procedure model. The good side of this might be the ability to document any observations related to the procedure as the encounter will provide a direct link to obs. Is this an anti-pattern?
If we can’t leverage the EncounterProvider model then we’ll need to introduce a ProcedureParticipants domain to take care of the participants. That will also mean that we introduce a procedure-obs link table if there is any need to record any observations about the procedure.
Here is the module we are using for these work. We understand the data modelling could change based on the different implementations use cases but for a start we’ve tried to align with fhir am much as possible.