Thank you for your advice, Giovanni. 2015-04-20 21:51 GMT+09:00 Giovanni P <[email protected]>: > 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.
