Hi Ian, It is an application for the patient (technically is a mobile web app). Data is stored in an openEHR repository, then another app (maybe an EMR or a care plan mgt system) let the clinician access the patient activity, evaluate the results, do another recommendation, .... I think the reporting frequency maybe daily or less (i.e. 3 times a week, once a week, etc.). Technically this could be different, e.g. if the patient doesn't have connection to the server, data is stored locally until synchronization could be done. Right now the recommendation is very simple: do this exercise/sport, for this time, with this frequency.The patient will report when he started and ended the activity,and what was the perceived effort (Borg scale).
thanks a lot! -- 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: Fri, 10 Aug 2012 10:38:30 +0100 > Subject: Re: Commiting ACTIONs for the same INSTRUCTION ACTIVITY > To: openehr-technical at lists.openehr.org > > 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 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120810/d0223269/attachment.html>
