Active Lists in OpenMRS

I took some time this afternoon to brainstorm about active lists w/ Paul…in preparation for an OIP project this summer with Upul.

Fundamentally, we need to add support for allergy lists and problem lists within core OpenMRS.  In the end, we’ll have allergy and problem methods within the Patient Service; however, the pattern of list management cries out for a core list management machine.

We could either simply create new data points for these lists, but since we have traditionally and it makes sense to continue storing observations for these.  So, we imagined that these lists would, for the most part, be references to existing observations.  We’re even more confident in this approach after learning that some HL7 v3 RIM-based projects at Regenstrief are defining allergy and problem lists this way (as references to observations).

Here is the basic model for Lists we would propose:

• patient id — the subject for the list, do we want to open this up to person id?
• list type — allergy vs. problem, other types of lists could follow
• obs id — reference to the observation that created this list entry
• sort weight — for managing sequence of lists
• date started
• date stopped
• ?stop reason (resolved vs. error correction)
• voided — when the associated obs is voided, the list entry gets voided as well
• void reason
• creator
• date created
• changed by
• date changed

Start and stop dates could go on the obs (we considered putting these in obs before), but on further reflection HL7 v2 has these in the OBR and it’s for timed urines and other observations that may take some time — tracking how long it took to obtain the observation and not tracking the duration of the concept itself.

Active list entries for patient would be all rows of a certain list type that are not voided and have a null stop date.

Basic properties of an allergy:

• allergy type — drug, food, misc, etc. (see HL7 table 0127)
• allergen
• reaction
• severity — severe, moderate, mild, unknown (see HL7 table 0128)

Problem list properties:

• diagnosis/symptom concept
• certainty

Getting this done may depend on building the answer_class and answer_set features (ticket 73), so that — for example — the scope of possible allergens could be defined as any concept in the allergens set and any concepts with a class of medication, medication set, etc.

Here’s some ideas of possible service methods…

PatientService
List<Allergy> getAllergies(Patient p);

List<Allergy> getAllergiesAsOfDate(Patient p);

void addAllergy(Patient p, Allergy a);

void updateAllergy(Allergy a);

List<Problem> getProblems(Patient p);

List<Problem> getProblemsAsOfDate(Problem p);

void addProblem(Patient p, Problem p);

void updateProblem(Problem p);

This is a work in progress.  I wanted to get it posted for discussion on today’s developers conf call.