I just found http://fiatjaf.alhur.es/couchdb-mr-simulator/ on user@.
Would this make a great addition to Fauxton? Best Jan -- > Begin forwarded message: > > From: ken tashiro <[email protected]> > Subject: Re: how to use an included document's key? > Date: 21 Apr 2015 05:28:57 CEST > To: [email protected], Giovanni Parra <[email protected]> > Reply-To: [email protected] > > 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. -- Professional Support for Apache CouchDB: http://www.neighbourhood.ie/couchdb-support/
