Maybe I'm losing some clinical context by adopting a data view of the setting but would not a problem oriented record be a 'view' on clinical data ? The clinical problem is obviously context dependant (cancer, diabetes etc) so this sounds like a higher order view on top of clinical data to me. I'd see problem list as a 2nd order construct like you, but I guess I'd consider problem oriented record at 3rd and Care plan at 4th level.
If care plan is what the name implies than it involves actions to be taken on top of a particular problem view so I'd feel safer having that in its own layer. So I'd consider something like: Say an EHR with ~100 compositions (1st level). A problem list as a persistence composition (2nd level), A problem oriented view that consist of compositions that are related to a power set of the problem list (3rd level) A care plan that uses the problem view and other computable care action concepts (4th level) The definition of problem oriented view belongs to 3rd level and you can have different care plans for the same problem view at the 4th etc etc.. On Wed, Nov 19, 2014 at 1:35 PM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > On 18/11/2014 03:34, pablo pazos wrote: > > Hi all, just re-sending this question on the clinical list too. > > I'm wondering how to handle the link between documents and health > problems in a problem-oriented record. > > > I think the future will be that a Care Plan informational construct (note: > for US, something very closely related to an 'order set'), partially > manually written, partially machine populated with links to relevant items, > will be the thing that ties it together. Consider: the proof that something > really is considered a 'problem', out of all the non-problems and trivial > problems (e.g. one-off throat infection) is that some clinical professional > wants to create a care plan, to define ongoing treatment and track > interventions (all medications, other interventions etc). > > A flexible model of a Care Plan (for each major ailment) that allows tying > together of such information, and is machine-updated, I think will end up > being the main way clinical professionals can interact with the raw data. > We can imagine a Care Plan 'service' with an API for add/update/remove > items/rules and apps for looking at care plans. > > Behind the Care Plan(s) in the EHR we still need managed medication > list(s) and problem list. > > I see the latter two as 2nd order informational constructs, and Care Plans > as 3rd order constructs. > > - thomas > > _______________________________________________ > 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/20141119/c4e2c330/attachment-0001.html>
