How to implement discharge summary, culture test results, leprosy examination results and operation notes in OpenMRS? We have modelled some of these as observations but the problem we are facing is that these are kind of reports or very long running encounters. We have an option of increasing the duration of encounter (session) for such users.
But we are also wondering if there are other ways in which it can be done in OpenMRS.
For the specific case of test results, in our Mirebalais system we create an encounter timestamped when we receive the result from the 3rd party system (a PACS system in the Mirebalais case). This would generally exist outside of a patient visit (unless the results came back when the user had a active visit).
However, I don’t know if we are consistent about this… I believe in our older MDR-TB implementation we add obsgroups with the test results to the “Specimen Collected” encounter, which has an encounter date of when the specimen was collected (though the obsgroups themselves have “Result Date” obs which store the date of the result).
Generally for discharge notes and operation notes, we’d just use a single encounter which, in a point-of-care system, would be timestamped with the time the note was first entered. I assume in these cases you are talking about a note that contains multiple observation collected over a period of time, and want to capture at a more fine-grained level when each individual obs were recorded? I don’t think we currently handle this use case.
As I understand it, the standard approach in typical EMRs is that some of these are a single note, and other are multiple interim reports, and both “note” and “report” would be OpenMRS encounters. (This is not how OpenMRS implementations have always done things though.)
discharge summary => A single encounter, that likely duplicates obs from other encounters that happened during the hospitalization. Most EMRs would let you save/edit a draft of this before you actually sign it.
operation notes => A single encounter. Draft functionality definitely helpful.
Both of those may fit your “increase duration of session” idea, but for the discharge summary you may need to handle the case where the clinician is writing more than one note at a time for the patient. (E.g. I have to write today’s progress note, but I also add some things to the discharge note, which I’m not ready to sign yet.)
–
culture test results => An order, an interim result (encounter 1) at t = 2 weeks, a final result (encounter 2) at t = 1 month. (Just as Mark describes for PACS results in Mirebalais.)
I don’t know how leprosy examination results work.
Notes would ideally be one more element of an encounter (e.g., a peer to observations, orders, diagnoses).
I’m not clear on what you mean by “very long running encounters.” Perhaps you are referring to the notion of pending encounters, like discharge orders, that may be started and worked on in a pending (e.g., “draft”) state for days before being activated.
The main problem I am looking to solve is that in some cases I want the user to have an edit view of a note (as meant by darius, set of observations) longer than usual. For people familiar with encounter session implemented in Bahmni, a note is in editable mode updating an encounter for a small duration (30 minutes), just to allow them to correct their mistakes.
This breaks down for the use cases I mentioned. (In leprosy example, the examining clinician, checks the complete body of the patient making observations about stiffness, etc. It takes long time to do around hour or more). This is usually not a problem if the observations have to be made by the system, like getting back results from PACS, or OpenELIS.
As I can make out from your responses, there are two options:
For the user’s perspective, we (in our system at Regenstrief) don’t show the user encounters and have them pick one to edit; rather, they are choosing by encounter types (we filter encounter types based on the user’s specialty) and we do not allow them to have more than one draft for a patient with the same encounter type. For example, on the clinician-facing patient dashboard, a doctor might see something like this:
indicating that they have a draft Release Orders session in progress for this patient. Selecting that encounter type opens the draft encounter. They can delete the draft, but there’s no way for them to create a second draft for the same encounter type.
An aside on Conflict Resolution
Of course, we’ve worked through conflict resolution in our system, which allows for longstanding drafts and eliminates the need to “lock” patient charts. In brief, it’s not safe to have multiple people writing orders for the same patient at the same time. In the past, we only allowed one draft encounter per user and would pessimistically lock users out of creating an encounter for a patient if someone else was working with the patient. In our new system, conflict resolution alerts and informs the user of intervening changes to the patient’s orders whenever they re-open a draft encounter or if they are signing an order session during which other orders have been written for the patient. With conflict resolution in place, users can safely keep longstanding drafts and we don’t have to lock people out of charts.
Eventually, I’d like to see conflict resolution implemented in the OpenMRS platform so everyone can benefit; in the near term, implementations are left to work through these safety issues on their own.
Since OpenMRS doesn’t currently support drafts, you’re forced to maintain the draft elsewhere (in the client or module) before submitting it to OpenMRS. Simply adding a draft attribute to encounter might work for you, but you could easily run into problems when the rest of the API isn’t aware of drafts – e.g., active orders will include any orders from a draft encounter and you will not be able to make drafts user-specific, so you’ll be limited to shared drafts (one draft per encounter type per patient across all users and people will be able to see and edit each others drafts, which may lead to messy business decisions on who’s responsible for what).
A better short-term solution for you would be to manage your own draft – i.e., maintain the encounter and any associated data in memory and only sending it to OpenMRS once its completed. You could serialize this encounter and store it server-side as a user-specific draft unique to that user+patient+encounter type. This could serve both as a backup for the session (you could do it in the background every 10 seconds and users, especially people writing long notes, will be glad when they can resume where they left off even if their browser crashes) and as a means to show the user she has a draft session for a given encounter type for a patient.
Burke, I was looking at something else on this site and found this explanation resalting to draft encounters and multiple concordant accesses to the patient’s chart extremely helpful. Terry