Thank you Sebastian,Giovanni. I am afraid that I am posting an out of place question here with inaccurate english and annoying you.
2015-04-18 5:04 GMT+09:00 Sebastian Rothbucher <[email protected]>: > Hi Ken, > > I'm with Giovanni here - I think we still puzzle to get the actual use > case. Is it like the guy working behind the parmacy counter is to see which > drugs to hand out to a patient today based on the patient's prescriptions > or what exactly is the case? Maybe we can all be of more help as soon as we > understand what the analysis is supposed to yield (without yet jumping to > conclusions about implementation)... For example, at 3/1 patient Alice had a prescription filled which included drug P and Q by a pharmacist Bob. The document id corresponding to this prescription is "11111". At 4/1 Alice has a prescription filled which includes drug P and R by Bob. The document id is "22222". The phase of P ,Q, R will be "2", "3","1" respectively. Now I suppose three major use cases. At first, default use case. All prescription data is automatically uploaded to couchDB at the time of Bob processing the prescription electrically. I want to add phase information here. Second, at 4/1 when Bob dispenses the drugs to the patient, he asks to Alice the reason ("she experienced adversereaction", "switched to cheeper drug", "capsule is too large", etc.). Bob updates the document "22222 " by adding the reason why drug Q was stopped. Bob accesses to web server via browser and does not see couchDB(cloudant) directly. This action is left to Bob, and he can update information at 4/2 or later. 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. 2015-04-17 21:29 GMT+09:00 Giovanni P <[email protected]>: > Sorry, but I still don't get what are the application requirements. > > Each prescription is a document, right? Each prescription document has > { > "prescriber": "the id of the prescriber", > "patient": "the id of the patient", > "date": "the date", > "drugs": [ > "an array of the ids", > "of all the drugs", > "in this prescription" > ] > } > > Is that right? Yes, I have thought of "one document per one prescription". Actually each prescription document has more than 200 keys, but essentially you are right. Drug information is a list of dictionaries. Now my program adds "optional information" to the document at 4/1. { "_id":"22222", "_rev":"1-xxxxxx", "patient_information": { } "prescriber_information":{ }, "pharmacy_information":{"name":"Bob" ,etc. }, "date":"2015-4-1", "drugs":[ { "name":"P", "drug id":"1234", etc. }, { "name":"R", "drug id":"2346", etc. } ], "optional_information" { "1234": { "phase":2, "name":"P" }, "2345": { "phase":3, "name":"Q" "reason":["adverse reaction"] }, "2346": { "phase":1, "name":"R" }, }: } > But you also need the last prescription done by the same prescriber who is > consulting the database at the moment, regardless of it being the last > prescription for that patient or not? > > What is stopping you from getting all the previous (or, say, the last 20 > previous) prescriptions for each patient in the same query and > showing/using/calculating based on that data? Each time pharmacist Bob and Carol access the database , phase information is used. I understand that phase information can be made with three ways: 1. local browser generates phase information each time Bob or Carol needs it. 2. web server generates phase information each time client requests. 3. couchDB stores phase information permanently. (4. couchDB generates phase information each time web server requests. This is impossible) > Also important: it is impossible to link documents, each document is an > island. It can be broken into various different keys in a view (it can emit > various keys from one view), but it cannot be joined or directly referenced > by another. Update functions act on individual documents, I only > recommended using those when I suggested that you kept only one document > for each patient with all its prescriptions inside. I have not at all thought of "one document for one patient". It happens that patient Alice in pharmacy X is the same person as patient Cooper in pharmacy Y. But all individual is planned to have a common social security number within a year or two, so "one document for one social security number" seems to be more attractive than "one document per one prescription". My prescription document has 36kb in average. Patient Alice's document size will be less than 36 kb/prescription x 10 prescriptions/month x 12month x 20years = 86400kb. This size seems not too be large. I will test this document structure more deeply. Thank you again, Giovanni. ken tashiro
