Hi,
I do like the Events idea that Giovanni suggested - and I think having a
doc for each time the patient (Alice) visits a pharmacy (be it Bob or
Carol) is a good idea as 80 or so MB per document sounds like a lot. Also I
finally think I get the phase concept where 1=first-time, 2=continue,
3=discontinue) - which can indeed be stored at the time Alice visits the
pharmacy I think
Coming back to the very first question: I think including docs is neither
related to the problem nor the solution. Including docs essentially allows
shipping more documents out of Couch with one request to the view; it does
not help in building the view or in correlating many events (what was
prescribed, continued, discontinued when).
I think taking a new and fresh perspective (e.g. on Giovanni's suggestion)
could be valuable here...
Good luck
Sebastian
On Sun, Apr 19, 2015 at 2:20 AM, Giovanni P <[email protected]> wrote:
> 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.
>
