Documenting procedure orders and fulfilment in OpenMRS

All of this sounds correct. A procedure should be recorded as an encounter (it is an interaction between a health care provider and patient) and encounter provider (and encounter provider role) should be used to document the role played by each clinician in the encounter.

2 Likes

Thank you @ibacher

While linking encounters with procedures, this is the desired payload that should enable us capture Procedure participants, results (Obs and text) and any complications (modelled as conditions) from the procedures. encounters: [ ] will just have a set of the usual encounter payload and linked with procedures using a join table (encounter_procedures) However when saving a procedure that has an ecounter am running into this error this this the exact line that is bugging out. I can use some help @wyclif @dkayiwa @ibacher

@jecihjoy is this an error that you can easily reproduce in a test?

The model implies that each procedure belongs to an encounter (rather than a set of encounters) and that seems more correct.

1 Like

@ibacher am working off this branch and not main

While working on documenting procedures and the outcome, we also need to document any complications that arise from a procedure. There could be a number of ways to document such complications but in our discussions internally (in Palladium), we favour designing and capturing them as conditions in the system so that we can have a single place for managing/tracking the statuses throughout the system. Does anyone have an objection to this approach, and if so, what would be the best approach? @dkayiwa @ibacher @angshuonline @mseaton @mogoodrich @burke

“Conditions” as a domain is designed to be a long-term clinical problem list. I’m not sure that that’s appropriate for complications—at the very least, it might lead to an overwhelming number of conditions per patient. I’d probably suggest just starting with an obs group.

Thanks, @ibacher, for the context on the conditions domain. I am tagging @jecihjoy on this response for her thoughts as well.

thanks @ibacher for pointing that out, however for procedures we were following the fhir recommended way of doing things, the other thing we thought about was modelling complications as condtions will make it easy to establish a management plan and easily update whether the condition is still active after followup evaluations of the patient. I believe we are open to using obs groups based on what we agree on.

So, in FHIR, Conditions are “A clinical condition, problem, diagnosis, or other event, situation, issue, or clinical concept that has risen to a level of concern.” However, in OpenMRS, our Condition domain is much narrower. Specifically, we’ve split our problem lists (conditions) and diagnoses (diagnosis) as separate and distinct domains—both of which were originally represented as ObsGroups prior to 2.2.

In general, while OpenMRS’s data model is inspired by FHIR and other standards, we’re not necessarily mapping things one-to-one, because sometimes we have slightly different concerns. One thing that makes the FHIR condition work is that conditions have a category that OpenMRS’s data model lacks, which helps to distinguish what the condition represents.

I think the right answers here either are:

  1. Using observations or
  2. Creating a “complication” domain which could be mapped to a FHIR condition

1 is easier because it doesn’t require a new domain to be added to the data model, but 2 is also doable

This makes sense, thanks @ibacher for the detailed explaination, for now I believe we should go we the first option

We imagined Procedures in the Order Basket as a Category (a ServiceRequest) as with Labs, Imaging and Referrals…

Thanks @pauladams. That is exactly what we have although we have radiology instead of imaging. That is a simple change that can be effected easily.

1 Like

@pauladams There’s a slight difference here in that there are orders for procedures and then the record of the procedure, which is a little more similar to a form. The order is the request to have the procedure performed. The record of the procedure records what actually happened during the procedure, similar to a visit note.

I’m not entirely sure we have a design pattern for this, but it’s likely similar to filling in a form, with a difference in the data structure it produces.

1 Like

Thanks @ibacher - I imagine we’d reuse the pattern from ‘Conditions’ or ‘Immunizations’ in that case.

A widget with a corresponding form that launches in the right panel.

If I can support with a design, just shout!

1 Like

We reused a lot from the labs app but @jecihjoy can share a few screenshots of what we have so far.

1 Like

@aojwang it would be great to get an update on your progress and how you are stiching up the UX for the entire flow of events right from order

This is fine with us. We’ll prepare and share a short video on the feature. We can then schedule a call for comprehensive feedback from the community. I hope this is fine.