Ok, I'm still a little confused, but understand that all the things we
suggested will not work for the third use case:
> Third, at 5/1 another pharmacist Carol working at another pharmacy is
> consulted by a prescriber that "I have prescribed my patient drug S but
> this does not work well. So I am considering to switch drug S to drug Q
or R.
> Which drug do you recommend?" Then she ask the program and database
> queries with the key "[phase, left-side n digits of drug Q corresponding
to
> the category of drug, drug name, the reason of drug being
> stopped],value [ "1"].
> She gets a list of drug Q or other drugs with the frequency of the
stopping
> (and optionally its reason).
> Then she compares drug Q with R which is more suitable for Alice's case.
> Carol also accesses to web server via browser.
But I still don't see the need for the "phase" information. Its only use
case is that, of when a pharmacist wants to know how many times and why a
drug X was stopped? As a layman, I imagine that most of the time the drugs
will be stopped because the disease which needed it has gone, right?
Doesn't this breaks the case summing up all the times the drug was stopped,
like in your example?
Also, what happens when a drug Y is being taken continuously through the
whole life of the patient, then when he goes to some pharmacist, he does
not even tell her about that drug, the pharmacist goes to the database and
registers a new prescription, with another drug, not even mentioning the
drug Y. This breaks the case for automatic calculation of phases.
Now,you said that updating the phase under the key "optional_information"
in the current prescription (before creating a new prescription) is
inneficient because of two PUTs. Our first answer should be that you can
use one POST to _bulk_docs and update and create the two prescriptions at
the same time (now, if your documents are big, it is probably more
efficient to issue two PUT to an _update handler, I don't know), so your
approach is doable.
Here are two ideas, however, that could be considered:
1. Forget the "phase" element of prescriptions and have just "events". One
kind of event is the prescription. Each pharmacist creates a prescription
and never changes it, it's an event. Or the pharmacist can create a
"stopped" event, for when any drug is stopped, along with the date, reason
etc. This is flexible, understandable, maps greatly to the real world facts
allows you to do the third use case. You can have views that emit the
drug/patient keys from all the events and then you'll know if it was used
successfully till the end, stopped for some reason etc.
2. Add the "phase" in the next prescription instead of in the previous. In
your example, this would be: at 4/1, Alice tells Bob she stopped the drug
Q, Bob prescribes other drugs to Alice. Bob never touches the prescription
"22222", he only adds to the prescription "33333" the drug Q with a phase
3, indicating that it is not being used anymore:
{
"drugs":[
{
"name":"P",
"drug id":"1234",
"phase": 2
},
{
"name":"R",
"drug id":"2346",
"phase": 1
},
{
"name":"Q",
"drug id":"2314",
"phase": 3
}
],
...
}
Why not?
I'm probably missing something, but this is what I could think of.
