How is the patient reporting back their exercise activity to the clinician?
I think it is better to create a new Composition for each 'patient report' rather than re-versioning a single Composition. The question then is how and, how often, the patient sends a report. As an example, let's say the patient reports weekly. In that case I would generate a new event Composition for each weekly report. Perhaps you could use a CLUSTER archetype to represent both recommended exercise, and the patient reported outcome, to be used in both the INSTRUCTION/ACTIVITY and in the ACTIONs. Can you gove more information on some of the detail of the exercise recommendations and the patient reports. Ian On 9 August 2012 19:28, pablo pazos <pazospablo at hotmail.com> wrote: > Hi Ian, thanks for the input. > > I'm trying to do it "by the book", obviously clinical input is essential to > model things :) > > What do you think about the ACTION to report patient activity? > > Should I create a new composition every time the patient report something? > or > Should I version the same composition on every exercise report for the same > exercise program? > > > At first I was thinking about having one ACTIVITY and versioning > COMPOSITIONs to represent states, but then ISM states came into play :D > > > In this scenario, I could keep exercise scheduling and activation states > just in the app, and commit a COMPOSITION only when the exercise is > finished, so I can interpret the COMPOSTION as a finished activity/exersice > on our openEHR repository (without putting an explicit state on the ACTION > archetype), and as you said, changing the state of the ACTIVITY as a much > higher level by a clinician. > > -- > Kind regards, > Ing. Pablo Pazos Guti?rrez > LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez > Blog: http://informatica-medica.blogspot.com/ > Twitter: http://twitter.com/ppazos > >> From: Ian.McNicoll at oceaninformatics.com >> Date: Thu, 9 Aug 2012 18:45:56 +0100 > >> Subject: Re: Commiting ACTIONs for the same INSTRUCTION ACTIVITY >> To: openehr-technical at lists.openehr.org > >> >> Hi Pablo, >> >> Thanks for the example. It makes more sense now, although I have to >> say that it feels to me as if you are overloading the idea of >> ACTIVITY/ACTION in this scenario. My approach would have been to >> regard the whole exercise program as a single task modelled as an >> Activity, and just to capture the patient-reported progress as part of >> the ACTION archetype, and only change state at a much higher-level i.e >> when the whole program is scheduled, starts or stops. >> >> There is nothing technically wrong with what you are suggesting, of >> course. >> >> I would be interested in other's thoughts - not sure if this is more >> appropriate for the clinical list? >> >> Ian >> >> >> >> On 9 August 2012 18:28, pablo pazos <pazospablo at hotmail.com> wrote: >> > Yes! this is really clear and has been a great help. >> > >> > Thanks a lot. >> > >> > >> > Just to give info that may help other in the future: in our case, the >> > instruction is a recommendation to do some exercise, and we need to know >> > if >> > the activity (the exercise) is completed. We consider a completed >> > activity >> > to be one exercise instance, e.g. one walk in the park. But the >> > recommendation is something like "walk 30 min/day for 2 weeks", so I >> > think a >> > good approach is to create one ACTIVITY for each day, and let the >> > patient >> > change the state of each day's ACTIVITY (scheduled, started, completed). >> > >> > In this case, if the day passes and the activity was never "active", >> > we'll >> > mark it as "expired". >> > >> > Of course, any comments about this scenario are very welcome. >> > >> > -- >> > Kind regards, >> > Ing. Pablo Pazos Guti?rrez >> > LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez >> > Blog: http://informatica-medica.blogspot.com/ >> > Twitter: http://twitter.com/ppazos >> > >> > ________________________________ >> > Date: Thu, 9 Aug 2012 18:07:31 +0100 >> > >> > From: thomas.beale at oceaninformatics.com >> > To: openehr-technical at lists.openehr.org >> > Subject: Re: Commiting ACTIONs for the same INSTRUCTION ACTIVITY >> > >> > On 09/08/2012 17:44, pablo pazos wrote: >> > >> > Hi Thomas, >> > >> > I agree with that, but I think we are talking about different scenarios. >> > I >> > understand we can have various ACTIONs for "active" states (and >> > reschedule >> > or suspend/resume transitions). >> > >> > My question is: if an ACTIVITY is "completed" (or "aborted" or >> > "expired", >> > i.e. a terminated state) >> > >> > is it possible or valid to start another execution cycle for that >> > ACTIVITY >> > instance? or, >> > should I create another ACTIVITY instance with the same info in order to >> > execute it? i.e. create another ACTION with state "scheduled" or >> > "active" >> > for the same ACTIVITY that is "completed". >> > >> > >> > Ah - good question (sorry, didn't read your earlier post properly!) >> > >> > The current model is designed is that once an ACTIVITY is completed by >> > an >> > ACTION putting it into a terminal state, then that's it. So for things >> > like >> > long term asthma medication, contraceptive pill, or any chronic >> > condition >> > medication, where the intent of the prescription (or hospital order) is >> > to >> > be more or less indefinite, with the patient just getting repeats then >> > the >> > ACTIVITY is always active or suspended, and never terminated. But even >> > if it >> > is terminated, e.g. the asthma patient gets better (it does happen!), it >> > just means that if it has to be restarted, it will be a new order, which >> > reflects what happens in real life. >> > >> > The key to this is that what is recorded (in terms of >> > INSTRUCTION+ACTIVITY, >> > and ACTIONs) should reflect real life of orders/prescriptions, repeats, >> > not >> > just the taking of the drugs themselves. >> > >> > hope this is clearer. >> > >> > - thomas >> > >> > >> > _______________________________________________ openEHR-technical >> > mailing >> > list openEHR-technical at lists.openehr.org >> > >> > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> > >> > _______________________________________________ >> > openEHR-technical mailing list >> > openEHR-technical at lists.openehr.org >> > >> > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> >> -- >> Dr Ian McNicoll >> office +44 (0)1536 414 994 >> fax +44 (0)1536 516317 >> mobile +44 (0)775 209 7859 >> skype ianmcnicoll >> ian.mcnicoll at oceaninformatics.com >> >> Clinical Modelling Consultant, Ocean Informatics, UK >> Director openEHR Foundation www.openehr.org/knowledge >> Honorary Senior Research Associate, CHIME, UCL >> SCIMP Working Group, NHS Scotland >> BCS Primary Health Care www.phcsg.org >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org
