My bad: using a consistent terminology is hard sometimes. When I say data view, I mean openEHR data.
So my 100 compositions are good old openEHR compositions in an openEHR implementation. All my layers are in openEHR, building on top of each other. So if you (and I) take openEHR clinical data as information (even though I called it data previously) I'm suggestion transformations of information to higher levels. Each level knows about what is below it (Problem lists know about clinical data, they don't know about care plans) but does not know in which context it is going to be used. So problem lists would not have any references to care plans. I can't agree or disagree with you regarding how fundamental problem orientation is; I am not a clinician. But I could enforce it in a clean and customisable way if I use the architecture I suggested. Some of these layers I've suggested may not be easily definable (if there is such a word..) in openEHR but that is OK, this is why there are PhD programmes out there. So I guess my point is; when Pablo asks how do I do problem oriented records with openEHR, I'd say "using an architecture like this", based on a slight modification of Tom's (IMHO) correct suggestion of computable care plans. Your points would all be mapped into that architecture and become software implementation tasks and decisions. Best regards Seref On Thu, Nov 20, 2014 at 1:03 PM, Karsten Hilbert <Karsten.Hilbert at gmx.net> wrote: > On Wed, Nov 19, 2014 at 02:00:46PM +0000, Seref Arikan wrote: > > > 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 ? > > Ah, putting it that way makes sense, too: the POMR approach > to be a view integrating "data" into "information". > > My point would be that problem orientation is so fundamental > a "view" that it should really be mandatory (even if only > internally -- if physicians can't be bothered with thinking > about which problem to attribute items to a coarsely grained > ordering, say along the lines of ICPC, might get applied > based on, say, provider speciality or some such). > > > 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. > > Interesting idea: "comprehensive" care plan, not necessarily > per-problem. Maybe per-goal (for which health goals must not > be per-problem ;-) ? > > > 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). > > IOW, a data store rather than an EHR. > > > A problem list as a persistence composition (2nd level), > > The minimum requirement for the data store to become an EHR. > > Thanks, > Karsten > -- > GPG key ID E4071346 @ eu.pool.sks-keyservers.net > E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 > > _______________________________________________ > 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/20141120/8240b3ef/attachment.html>
