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 Tue, 21 Apr 2015 03:28:57 GMT
Thank you for your advice, Giovanni.

2015-04-20 21:51 GMT+09:00 Giovanni P <fiatjaf@gmail.com>:
> After thinking more about it, I think that the optimal suggestion (in the
> sense that I want you to consider that my only suggestion from now on) is
> to have one document for each patient visits to the pharmacy, as Sebastian
> said.
>
> The document structure could be something like this
> <http://pastie.org/10103158>.

I was puzzled about how to update efficiently a document each time
keeping consistencybut this "one document per one event"
structure is very easy to handle.

> At every visit, even if nothing happened on that visit, you would have a
> new document with all the current "state" information about the patient. It
> would list all the drugs being continuously taken, drugs that were stopped
> (after they being "stopped" in one document, they would not appear in the
> next documents), even drugs the patient reported to be taking before the
> first visit, or that he is taking because they were prescribed elsewhere.

I think you are pointing to the core of pharmacist business.
The patient information without prescription is now recorded on a paper,
and the problem is how it should be recorded electrically. Since this is
a difficult problem, I have lowered this priority, but I was wrong.

> The GUI interface should, them, get the last document for each patient, and
> display the "current state" for the pharmacist, who can ask about all the
> drugs, for example: "are you still taking xyz?", if the patient forgets
> about it. Then all the updates the pharmacist makes on the screen can be
> saved just as they are, but AS A NEW DOCUMENT, old documents should be
> considered as immutable (maybe editable only in case of error).

I also thought previous prescriptions should be immutable, so I put
optional "phase 3"  information  at the timing of creating a new document for
the current prescription document (The number of GET and PUT has
become relatively minor problem in my brain). Now your suggestion is to add
a new document whenever a patient gives any information, I should do this.

> Information about the patients (as you said you want to track reactions
> considering age, gender and other things) could be then emitted as you
> like. For example, for querying stopped drugs of some type for patients
> with ages between 24 and 34, you would have a view emitting keys like this:
> [phase, drug type, patient's age], and a result like this
> <http://fiatjaf.alhur.es/couchdb-mr-simulator/#{"params":"reduceFn:
> _count\nreduce: true\ngroup_level: 3\nstartkey: [3, X, 24, null]\nendkey:
> [3, X, 34, {}]","emitted":"# key: phase, drug type, patient age\n# value:
> drug name\n1, X, 21, Xoliryi-43\n1, A, 29, Aaayol-43\n1, Y, 24,
> Yaayol-43\n2, A, 22, Aaayol-43\n3, Y, 22, Yoliryi-43\n3, X, 39,
> Xoliryi-43\n1, A, 49, Aoliryi-43\n1, Y, 24, Yeeeu-43\n2, A, 32,
> Aeeeu-43\n2, A, 33, Aaayol-43\n2, X, 44, Xaayol-43\n3, Y, 22, Yaayol-43\n2,
> A, 43, Aoliryi-43\n1, Y, 31, Yoliryi-43\n2, X, 22, Xoliryi-43\n2, X, 23,
> Xoliryi-43\n2, X, 44, Xoliryi-43\n2, A, 23, Aeeeu-43\n3, A, 34,
> Aaayol-43\n1, Y, 21, Yaayol-43\n2, X, 22, Xaayol-43\n2, X, 23,
> Xaayol-43\n2, X, 24, Xaayol-43\n3, Y, 22, Yaayol-43\n3, X, 29,
> Xaayol-43\n1, A, 49, Aaayol-43\n1, Y, 24, Yaayol-43\n2, A, 22,
> Aoliryi-43\n2, X, 24, Xeeeu-43\n3, A, 34, Aoliryi-43\n1, Y, 21,
> Yoliryi-43\n1, Y, 21, Yoliryi-43\n3, Y, 22, Yeeeu-43\n2, X, 22,
> Xoliryi-43\n2, X, 23, Xoliryi-43\n2, X, 14, Xoliryi-43\n3, Y, 22,
> Yaayol-43\n3, X, 29, Xaayol-43\n2, X, 22, Xoliryi-43\n2, X, 43,
> Xoliryi-43\n2, X, 44, Xoliryi-43\n3, Y, 22, Yoliryi-43\n3, X, 29,
> Xoliryi-43"}>. Now, if you wanted to get the results discriminated by the
> drug name, the query would be this
> <http://fiatjaf.alhur.es/couchdb-mr-simulator/#{"params":"reduceFn:
> _count\nreduce: true\ngroup_level: 4\nstartkey: [3, X, 24, null]\nendkey:
> [3, X, 34, {}]","emitted":"# key: phase, drug type, patient age\n# value:
> drug name\n1, X, 21, Xoliryi-43\n1, A, 29, Aaayol-43\n1, Y, 24,
> Yaayol-43\n2, A, 22, Aaayol-43\n3, Y, 22, Yoliryi-43\n3, X, 39,
> Xoliryi-43\n1, A, 49, Aoliryi-43\n1, Y, 24, Yeeeu-43\n2, A, 32,
> Aeeeu-43\n2, A, 33, Aaayol-43\n2, X, 44, Xaayol-43\n3, Y, 22, Yaayol-43\n2,
> A, 43, Aoliryi-43\n1, Y, 31, Yoliryi-43\n2, X, 22, Xoliryi-43\n2, X, 23,
> Xoliryi-43\n2, X, 44, Xoliryi-43\n2, A, 23, Aeeeu-43\n3, A, 34,
> Aaayol-43\n1, Y, 21, Yaayol-43\n2, X, 22, Xaayol-43\n2, X, 23,
> Xaayol-43\n2, X, 24, Xaayol-43\n3, Y, 22, Yaayol-43\n3, X, 29,
> Xaayol-43\n1, A, 49, Aaayol-43\n1, Y, 24, Yaayol-43\n2, A, 22,
> Aoliryi-43\n2, X, 24, Xeeeu-43\n3, A, 34, Aoliryi-43\n1, Y, 21,
> Yoliryi-43\n1, Y, 21, Yoliryi-43\n3, Y, 22, Yeeeu-43\n2, X, 22,
> Xoliryi-43\n2, X, 23, Xoliryi-43\n2, X, 14, Xoliryi-43\n3, Y, 22,
> Yaayol-43\n3, X, 29, Xaayol-43\n2, X, 22, Xoliryi-43\n2, X, 43,
> Xoliryi-43\n2, X, 44, Xoliryi-43\n3, Y, 22, Yoliryi-43\n3, X, 29,
> Xoliryi-43"}>.

Thank you for detailed sample,and I am surprised that such a
simulation site exists.

Sincerely yours, ken tashiro.

Mime
View raw message