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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120911/43df772d/attachment.html>
