Hi Sam, I understood how to do it, what I don't understand is why previous data is "redundant" and not "invalid/incorrect". You mentioned this on your previous message:> 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).
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 Subject: Re: Commiting ACTIONs for the same INSTRUCTION ACTIVITY From: sam.he...@oceaninformatics.com Date: Wed, 12 Sep 2012 06:53:46 +0100 To: openehr-technical at lists.openehr.org Hi Pablo,You need to reversion the persistent composition without the medication in it. Ideally an action showing it has been ceased should be recorded in an event composition.Cries that help?Sam Sent from my phone On 12/09/2012, at 0:07, pablo pazos <pazospablo at hotmail.com> wrote: Hi Sam, What "redundant data" means in the context of persisten compositions? I.e. if I need to remove a medication from the medication list because the patient no longer takes that drug, as I see it the medication is invalid (not redundant) at the present moment. Please be as specific as you can, I really want to understand the difference. 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 > Date: Tue, 14 Aug 2012 07:35:49 +0930 > From: sam.heard at oceaninformatics.com > To: openehr-technical at lists.openehr.org > Subject: Re: Commiting ACTIONs for the same INSTRUCTION ACTIVITY > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120912/8b578a41/attachment.html>
