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? orShould 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120809/1e3ecbdd/attachment.html>
