Hi All The openEHR specification is clear about the notion of update/versioning of a composition or creating a new event. The idea of a persistent composition is useful for information where new data ALWAYS makes previous data redundant not incorrect at the time (such as a medication list in a shared health record). This is useful for allergies and other lists which have to be maintained.
An event composition will relate to information at a particular time which may be collected again but does not replace the previous information. This is usually the case for most recordings. A new version of this composition will invalidate the previous version (as key data was missing or incorrect). Cheers, Sam On 10/08/2012 7:08 PM, Ian McNicoll wrote: > 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 > >
