Implementation of Adherence Module

I am working on the Motech Project. We are creating a platform upon which people can build software to support operations in the Health care sector. Adherence to dosage, clinic visits etc are important data in the health care domain. This post, is a technical one which elaborates the creation of a generic module for storing adherence information.

Adherence conceptually is (number of actual occurrences)/(expected number of occurrences) of any event. The event can be visiting the clinic on a specific date, taking a dose on time etc. Though conceptually very simple, adherence proved to be a quite complex data to model.

Adherence is continuous in nature. The adherence to a dosage for example depends upon data recorded from the time a patient was enrolled into the dosage. Let us assume that the patient has to take a dose every day according to the dosage, then adherence on fifth day is (number of doses patient has actually taken over five days) / 5.

A simple implementation is to record total number of doses taken, persist the information. Then when adherence is necessary, read the number of doses taken from the db, figure out the number of doses he is supposed to take from dosage information and calculate the adherence. There were some very serious implications when this model was followed.

For one, let us assume that the system is down for some time. Then the patient could not record the adherence. But still, the system would assume that the patient has not taken the doses and there by, adherence would decrease without any fault from the patient’s side. This combined with the fact that, adherence on specific dates in the past was a point of interest, we could not go ahead with this model.

Then we decided to record the information whether the dose was taken each day. Though this did not ensure that the adherence would not decrease when the system is down, we could calculate the adherence on any given date. This was a major plus.

We still had to solve the problem that, when the system if down, adherence percentage should not decrease. To over come this problem, we decided to create a log whether the dose is taken or not taken. In which case, adherence would be the number of (taken logs)/total no of logs. When the system is down, logs would not be created, and thus adherence percentage can be maintined.

Following the above model, severly restricted the system in a different way. For the model to work, it is necessary that each log should record the adherence information of one and only one dose. If the log recorded adherence for more than one dose, the date when each dose was taken, would have to be stored in a clumsy way. This does not bode well since the the queries on the model are date based.

The above restriction combined with the fact that adherence had to be captured on daily as well as a weekly basis, with the requirement that the switch from daily to weekly should be consistent, forced to look at a completely different way to model adherence

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s