Modelling expected events

Development
1

The requirement is as follows (this is really early draft of the requirement)

  • when a patient is enrolled in a program, there should be a schedule created which captures things like expected dates of visits, expected dates of sample collection/getting test results and perhaps few other things.
  • the system should be able to present the actual events (visits, sample collection) along with the expected dates in helpful ways to allow for assessment of how “well” a patient treatment is happening vis a vis the treatment protocol
  • perhaps some reports which also allows for assessment of the overall program across patients

My question is about how should the calendar be stored in OpenMRS. The reason I feel storing is a good idea is because it will help in performing reports in future.

2

I agree that you want to store these expected events in the DB to be able to rapidly query them (as opposed to only having the schedule definitions stored, and recalculating them all the time).

But I don’t know of anything appropriate in the data model to store this. (It’s not an order. You could store an observation representing the intention to do something on a future date, but this doesn’t really fit.)

I would lean towards introducing something like this via a module:

class ExpectedEvent {
    Date scheduledOnOrAfter;
    Date scheduledOnOrBefore;
    // alternately, instead of two dates, do Date scheduledDate + Integer gracePeriod
    OpenmrsObjectRef triggeredBy; //e.g. the program enrollment (OORef probably means class + uuid)
    OpenmrsObjectRef fulfilledBy;
    // also a ref to the protocol itself, if we're storing that in the DB
}

That said, you might want something even more specific, like “Program Driven Treatment Protocol” (e.g. this way you could explicitly foreign key to a PatientProgram, rather than having a bulky class + uuid construct).

3

Maybe this is a bit out of scope, but are these expected events similar to vaccination regimens but extended to include more than a single type of event.

It would need some description of the event. Is it really a future dated order (but maybe not in the OpenMRS sense)?

On the dates question, the grace period may not be symmetrical around the scheduled date. This would require three dates (earliestDate, scheduledDate, latestDate) or (scheduledDate, and before and after grace periods). The latestDate might be used to raise alarms within the program?

If a patient does miss a scheduledDate, and is late, would that in some cases cause a rescheduling of the later events? If so it seems important to keep these dates in their own object and not just a reference to the schedule definitions. Another reason to support Darius’s first statement.

4

I like the ideas around dates and references to objects.

Right now I know of two scenarios which fit this kind of use case.

  • management of TB treatment which spans over long period, involving expected events like followup visit, sputum taken, results received (data associated to the event like result being positive, negative or subjective)
  • management of vaccination/immunization schedule consisting expected events like followup visit, vaccination done

In my earlier project, we had modelled it like this - https://github.com/motech/ananya-care/tree/master/ananya-care-web/src/main/resources/schedules. I felt then it was quite hard to understand and only very few people could really define schedules like this. So simplification without loosing too much flexibility would be desired. Also, wouldn’t be a good idea to be too generic (that is becomes a platform for modelling almost anything) and too restrictive.

Any other pointer how someone else may have done this will be useful. Also examples of scenarios are really useful too.

5

there is already fairly defined logic for childhood immunizations that is open source - and can be flexed based on certain things like epidemic situations. From a clinical perspective, that is critical as it is too hard to figure out what we should be doing for whom and when. Have we ever looked at the logic part of those products to see if we can integrate that? (not the code, the logic)

peds imm is the hardest place, IMO, to figure out predictive testing/ evaluation. It would make sense to have this as a capability that could then be used for whatever needed testing/ results/ procedure (like an IMM) intervention. There is also some work on this in the open source HIT space within the US for what has been called ‘procedure tracking’ =; it accommodates light boolean logic ( if /then sort of stuff) as well as flexibility for individual patients- a concept that is critical for CDS.

6

My first gut reaction is to consider actually scheduling these appts using appointment scheduling, but I assume you’ve already considered this and figured it doesn’t meet your needs properly as you need to distinguish between when something should happen and when it is actually scheduled to happen?

7

There are few reasons which do not fit completely with the appointment scheduling functionality.

  1. It seems we would need some sort of virtual providers or appointment without a provider, to support certain expected events like visit expected to facility but not for a specific provider.
  2. Some of the items are different from patient-provider appointment. For example - Sample collection, Test Result Expected. Again, arguably sample collection can be thought of as an appointment.
  3. There is a need for multiple dates for each event and not just one date.

We could split the current appointment scheduling into two separate things. A module, may called event scheduling which is more generic and can take care of requirements like above and another piece which sits on top of it providing the patient-provider appointment functionality. I am not 100% sure yet whether this is a good or bad idea.

I will know more about the requirements around this in few days. But will be happy to hear what others think. Because it does have significant (but not complete) overlap with appointment scheduling.

8

Treatment schedules (immunizations, TB treatments, etc.) are typically defined by guidelines. Preventive care schedules are typically age-based. Treatment schedules are typically based on relative dates (e.g., 6 months after initiation do A; 12 months after initiation do B). Of course, nothing is black & white in medicine, since there are schedules like “immunize everyone at 65yo or anyone with diagnoses A, B, or C.” The requirement described by @petmongrels sounds more like treatment (program) schedules. It’s possible that we could represent preventive care guidelines as programs as well (e.g., Childhood Immunizations Program, Adult Immunization Program, Colon Cancer Prevention Program, etc.).

I would leave the appointment scheduler to focus on scheduling of appointments. A module to manage expected events could have a feature to create appointments within the appointment scheduler as a side effect, but the management of expected events and the associated logic would occur outside of the appointment module.

I’m imagining a “program schedule” module that would:

  • Contain/manage the program-based guideline schedule(s)
  • Be triggered based on program state changes
  • Leverage the platform’s decision support engine (when it exists) to execute logic
  • Potentially adjust the program state (e.g., automatically moving someone into the “lost to follow up” state if they have missed critical events)
  • Potentially auto-generate or assist with generation of relevant observations or messaging (record sentinel observations to the patient’s chart or notify a provider of a patient at risk of falling off schedule)
  • Potentially auto-generate or assist with scheduling program-driven appointments within the appointment module
  • Be able to generate screens/reports to show timeline (expected vs. actual timing of events)
  • Ultimately, support aggregate queries about program events to answer population-level program questions (e.g., at what point are TB patients most likely to fall off schedule)

To start out, I’d suggest (as @darius suggested) creating a “program schedule” or “program events” module to meet this need. I’d recommend architecturally separating the event handling from the logic, assuming that a logic engine will eventually exist to subsume the logic needs. For example, the program events module would know the schedule of expected events and track signals that the patient is following the expected program schedule, but the module would eventually leverage a CDS engine within the platform to determine the appropriate timing of the patient’s third immunization based on the guideline.

9

I agree with Burke/ Darius . Developing the capability within the program schedule ( i don’t know that it is really programs but… ) to allow for triggering in a static as well as a dynamic fashion would give a range of functionality ( and allow the CDS tool to be invoked when indicated).