So need to nail down some design requirements so that we can finish off the db design.

As with any project getting the db design correct at the start will save a lot of pain and suffering later on in the project. To get the db design correct we need understand what we are trying to achieve with the overall system.

So some key questions and answers:

Q. Is the system 'device' or 'patient' centric?

A. Patient centric. We may even see a patient with multiple devices if they live at multiple locations or have dispensing needs beyond the capacity of a single device. Of course over a patient's life time they may have multiple devices (upgrades, failures). In either case we need to support the concept of multiple devices.

Q. Can a device have multiple cartridges?

A. The current design only allows for a single cartridge to be inserted at a time. A future design may allow 2 or more cartridges to be loaded into a single dispenser. Even with a single cartridge model we still expect each device to have more than 1 cartridge. Basically one in the device and the second one ready to be pre filled and then swapped into the device.

Q. Can a device have multiple patients?

A. At this point we don't foresee a single device dispensing to multiple patients. We have had some thoughts about a retirement home module that contains multiple cartridges with a cartridge per patient, but this is a long way away from any serious consideration.

Q. Can a patient be their own Carer?

A. Certainly. This is largely about the permissions model (e.g. who has permission to do what)

Q. Can a patient be their own Practitioner?

A. Whilst this isn't very likely (and perhaps not safe) it may be possible. But I think its fairly save to ignore this scenario.

Q. Can multiple devices be located at the same address?

A. This has to some extent already been answered. The reason I raise it again is that it has other possible ramifications. If you have two devices that are being used by TWO different patients, what is the risk that a patient will take a pill from the wrong dispenser.

I've suggested elsewhere that this could be dealt with by using an rfid bracelet which is used to identify that the correct patient is access the device.

Q. Can we share mediation descriptions between patients?

A. I've had some thoughts about using photos of tablets to help carers identify tablets when clearing the dump draw. I'm hoping that having access to a photo of each tablet that we might reduce the errors when recovering dumped tablets. The problem is that photos may not be sufficient for reliable identification and the size, shape and colouring of tablets may change over time and from manufacturer to manufacturer.

If the look of tablets from a given manufacturer is stable and photos are sufficient then sharing the medication descriptive data between patients may be beneficial. e.g. we load the data/photos once and then share the data between all patients.

I don't have sufficient information to make an informed decision on this one. As such I'm going to be conservative and assume that we won't share medicine data between patients.

Q. What type of scheduling do we need to allow for? Are there common patterns that we can provide or does the scheduler need to be fully customisable?

A. My experience with generic schedulers is that they are hard to use and hard to understand (just look at cron). As such I'm inclined to go with a template idea. Basically we load a set of standardised schedules into the system. When setting up a schedule the carer select an appropriate template and then does some simple customisation.

e.g.

Three times a day before a meal.

Three times a day with a meal.

Three times a day after a meal.

Before Bed

So this raises some issues that I've not previously considered. How do we convey information such as 'take before eating'. It also raises questions about timing. If I eat my meals at the same time every day then the dispensing schedule is easy, but if I have more irregular eating habits then a fixed schedule may not work. In some ways this is partially covered off by the concept of a 'travel pack'. The travel pack idea is where I'm off for an outing and won't be home for lunch therefore I need to take my tablets with me. The system can be configured to allow a patient to have the system dispense tablets early. This same sort of process could work for before/after/with food issues.

That still leaves us with the problem of how do we remind the patient that they need to eat the tablets with food, before food or after food.

More ideas/questions to come.