couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ken tashiro <presidenttash...@gmail.com>
Subject Re: how to use an included document's key?
Date Mon, 20 Apr 2015 11:12:21 GMT
Thank you Giovanni, Sebastian.

2015-04-19 9:20 GMT+09:00 Giovanni P <fiatjaf@gmail.com>:
> 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?

If I make a document per patient and each document includes all prescription
data, "phase"  information seems to be generated within a map function.
I am now trying to make a test database.
The number of the reason a drug is stopped is at least 15, which includes
the case that the drug is continued but not prescribed,and of course
the case the drug is no more needed.
For example, analgesic X is prescribed 1000 times,of which 300 prescription
was "phase 1",700 was "phase 2",and 200 was "phase 3".
Of 200 "phase 3"  cases, 150 cases patient said "the pain is over.so I don't
need this(this 'phase 3' information does not known until this patient goes to
pharmacy next time)."  and 50 cases "This didn't work well, so I changed to
analgesic Z(phase 1)."

Likely, analgesic Y is  prescribed 1500 times, of which 500 prescription
was "phase 1", 1000 was "phase 2" and 500 was "phase 3".
Of 500 "phase 3" cases 300 cases patient said "the pain is over, so I don't
need this." and 200 cases "switched to Z."

Since X worked for 150/200 cases(75%),and y worked for 300/500 cases(60%),
I should recommend X rather than Y(in fact I want to adjust the ratio with
patient's year,gender,etc.).
So the information of "phase 1" or "phase 2" is not so important here ,
and the bottleneck is to get the information of "this drug is stopped".
Of course if the patient never goes to the same hospital or pharmacy,
phase information stops at "2" or "3".
If a patient goes to another hospital or pharmacy, phase information is lost.
So the concept of "phase" may not fit to the use case and your suggestion
of "event" seems to be better than "phase".

> 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.

"One document for one event", documents are divided into immutable
prescription documents and mutable "stopped" documents, am I correct?

> 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:

I am sorry I am not yet  able to figure out the map function of this approach.
I will study this more carefully.

2015-04-20 4:50 GMT+09:00 Sebastian Rothbucher
<sebastianrothbucher@googlemail.com>:
> 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...

I abort "including docs" for this purpose ,"map function referring two
document",
and I am okay to abort "phase" concept.

Should my question be "how to know the differences of two documents?"?
Giovanni's suggestion seems to be
(1)  collect into one document and calculate the differences within a view
(2)  make another document only when difference occurs
(3)  update difference information as the past information
I have not thought of these ideas at all, and my understanding of the couchDB
or document database is getting cultivated(is this word correct?).

My development speed is very slow, but I will test the speed of (1) approach
first and report the result of it.

Sincerely yours, ken tashiro

Mime
View raw message