Problem-oriented records and querying by problem
On 28/11/2014 04:17, Koray Atalag wrote: Hi Karsten, I agree about episodicity not being particularly an issue with problem orientation. Re randomness I couldn't find the best expression I guess...What I was referring to is the fact that the information captured by today's systems can be quite diverse and that stems not from the differences about data entry, coding etc. but more to do with human factors such as the care setting, qualifications and interest of the health professional capturing information, business rules of the organisation, organisational culture and sometimes pure chance. So if the patient has seen been seen by a nurse, a GP, community worker, specialist etc. they may all have own views of the problems and their relationships to goals and actions etc. and eventually any causality type links to observations. I think the EHR specification and its implementation should provide firm hooks in the data collected to be able to generate different kinds of Problem Oriented Views. I assume this is one solid reason to incorporate some clinical semantics into RM as openEHR does. one of the lessons we learned in the past is that hooks are needed for the epistemic information types (observation, evaluation, action, instruction, admin) that occur in clinical process, but an ideal version of the process itself can not be a /requirement/. The Danish board of digital health instituted a model called G-EPJ in about 2005, which had a lot of similarities to the openEHR core Entry types and process. However, in G-EPJ, they made the idealised process, that is, the links from Observation - Diagnosis - Intervention etc, a requirement, and they published XML schemas and other artefacts that forced e.g. a Dx to be present as an 'indication' for every medication administration, and similar kinds of links. This didn't work with industry, for reasons Koray mentions here - in reality GPs sometimes prescribe without a diagnosis as such, nurses and docs administer drugs in hospital without always having an order. And of course historical records of such events can easily be incomplete, making it impossible to reconstruct data from a legacy EHR into the new required form. This Danish work was conceptually very good, but a bit naive, and we learned from that - provide appropriate information types, and make it possible to have process links but don't require them. There are some improvements that could be done today to this, but the basic decision has turned out to be right I believe, based on intervening years of use. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141128/bc3f9465/attachment.html
Problem-oriented records and querying by problem
On Fri, Nov 28, 2014 at 10:55:31AM +, Thomas Beale wrote: in reality GPs sometimes prescribe without a diagnosis as such In reality GPs (I am one) _often_ prescribe without a _diagnosis_. The proverb The Gods put the Diagnosis before any Treatment doesn't hold in GP land. However, GPs (better) never prescribe without a _reason_. That reason very much is the patient problem at hand. There is _always_ a reason for which to prescribe. (if the reason _isn't_ the patient problem the patient may need another GP ;-) If there doesn't appear to be a reason clinicians better think again. administer drugs in hospital without always having an order. And of course historical records of such events can easily be incomplete, making it impossible to reconstruct data from a legacy EHR into the new required form. While that seems like an excellent technical argument the very nature of having documented (generated by import from legacy data), say: reason = unknown / don't know / old stuff - drug 1 - order 2 - lab test 3 tells the clinician to think things over when needed and re-arrange. Of course, one might say that it behooves the system displaying such data to flag unlinked artifacts in the above way. This Danish work was conceptually very good, but a bit naive Are there links ? Thanks. , and we learned from that - provide appropriate information types, and make it possible to have process links but don't require them. From a technical point of view it is probably very prudent to not _require_ such links (as in, say, a non-nullable foreign key) but the user-facing side of the system as a whole (as long as it is used for individual-patient care rather then epidemiology) should make it, like, real hard to forego such links. I suppose I can agree with that approach. All in all this starts to remind me of whether NULLs should be allowed to happen in a given relational schema or whether any such schema should be further normalized to not require NULLs, right ? Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
Sorry I meant I don't think 'natural order' (as in DMBS) of an EHR can be of POMR type Cheers, -koray From: Koray Atalag Sent: Wednesday, 26 November 2014 9:52 p.m. To: 'For openEHR technical discussions' Subject: RE: Problem-oriented records and querying by problem Hi All, The single care plan giving way to multiple views makes sense to me as well. I don't think with so many degrees of freedom in modelling with openEHR we cannot possibly reconcile the many different care plans post-hoc to create the really valuable master view for purposes Heather nicely put. Having spend entire last week in a major HIS procurement evaluation I must say this looks like the way things are already been implemented in many places around the world! I also have noted the current immaturity of using links effectively to do things just like this - maybe we need some 'design patterns' which Tom had indicated some time ago. Another point is, although I haven't been practicing Medicine for too long now, I know the links between problems vs goals vs actions do not play nicely at all times - indeed for most of the time. They can be subjective and quite error prone. Therefore I don't think 'natural order' (as in DMBS) of an EHR cannot be of POMR type - it has to follow real life: randomness and episodicity. Maybe we should look at putting a quantifier for the likelihood of the links - any thoughts? Cheers, -koray From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Bj?rn N?ss Sent: Tuesday, 25 November 2014 8:02 p.m. To: For openEHR technical discussions Subject: Re: Problem-oriented records and querying by problem I like this approach. The master care plan is what we call Patient plan. There should be only one of this in a given EHR. This plan evolves over time as more items are addes or removed. To administer this plan you need a dashboard with functionality to filter on overdue, finished, etc. And of course you need commands like add, update, finish, etc. The plan is a master view on plan items from different systems and with contributions from all health care specialities. Depending on the users point of view it should be possible to dig into details about specific parts of the plan. I am not sure if it is possible to archetype this dashboard. I guess this is up to the application to implement this. The clinical modeller should archetype the content of different plan items. To make this work we need a basic set of INSTRUCTON/ACTIVITY/ACTION archetypes that make the outer boundaries of a care plan and care plan elements. Vennlig hilsen Bj?rn N?ss Produktansvarlig DIPS ASA Mobil +47 93 43 29 10tel:+47%2093%2043%2029%2010 Original message From: Thomas Beale Date:20/11/2014 19:07 (GMT+01:00) To: openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org Subject: Re: Problem-oriented records and querying by problem I wonder if the GP 'master care plan' is more like a 'care plan dashboard' rather than an actual care plan? With functions like 'show all overdue / suspended / etc etc'... - thomas On 20/11/2014 17:25, Heather Leslie wrote: Hi Karsten, I think in practice you will see a variety of care plans depending on the context. The endocrinologist will be using a diabetes care plan for their care of the patient, and likely not having access to, nor particularly interested in, what other specialists might be scheduling. The cardiologist will be using a cardiology-protocol-based care plan, probably developed in splendid isolation from the endocrinologist activities. The rehab specialist will be using a purpose-built care plan for the patient's recovery from a knee replacement. However it will be critical that the GP or coordinating primary care provider develop/need a single global care plan, (which can be separated out for the different purposes, if needed) that provides an overview of all activities that the patient requires - what is due, overdue, planned etc. This will ensure that the blood glucose and renal function tests required by both the endocrinologist and cardiologist iare coordinated, if clinically appropriate and tests/appts not repeated unnecessarily. They will have access to a 'master' plan that will detail all reviews/goals/test/appointments for each 'specialty' plan and have the ability to coordinate the components to suit the best interests of the patient as a whole - a care plan for the patient, not just one per problem. The patient or the parent/caregiver will also benefit with being able to schedule appointments/tests etc. And we will need to be able to break down that master care plan to see which components belong with each problem, or are shared between problems, and for context-based sharing with other health care providers. ___ openEHR
Problem-oriented records and querying by problem
On Wed, Nov 26, 2014 at 08:52:28AM +, Koray Atalag wrote: Another point is, although I haven't been practicing Medicine for too long now, I know the links between problems vs goals vs actions do not play nicely at all times - indeed for most of the time. They can be subjective and quite error prone. Therefore I don't think 'natural order' (as in DMBS) of an EHR cannot be of POMR type - it has to follow real life: randomness and episodicity. Problem orientation is -- of course -- a best-effort approach. An EHR which forces problem orientation facilitates good care by making clinicians think about what things really mean. What is meant by randomness ? Episodicity does not at all run counter to problem orientation. Karsten Hilbert -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
On Tue, Nov 25, 2014 at 07:01:50AM +, Bj?rn N?ss wrote: To administer this plan you need a dashboard with functionality to filter on overdue, finished, What you seem to be describing is a TODO list to do with solving of pressing issues and is, at best, _part_ of a care plan (in the form of planned repeat procedures, say). A short-term plan (handling AMI, gall-bladder removal, ...) is a protocol rather than a relevant care plan (feel well with diabetes, improve management of factors contributing to risk of depression, sanely approach cardiovascular risk management). Patient-centric care plans better concern themselves with long-term holistic goals in terms of salutogenesis. Karsten Hilbert -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
I like this approach. The master care plan is what we call Patient plan. There should be only one of this in a given EHR. This plan evolves over time as more items are addes or removed. To administer this plan you need a dashboard with functionality to filter on overdue, finished, etc. And of course you need commands like add, update, finish, etc. The plan is a master view on plan items from different systems and with contributions from all health care specialities. Depending on the users point of view it should be possible to dig into details about specific parts of the plan. I am not sure if it is possible to archetype this dashboard. I guess this is up to the application to implement this. The clinical modeller should archetype the content of different plan items. To make this work we need a basic set of INSTRUCTON/ACTIVITY/ACTION archetypes that make the outer boundaries of a care plan and care plan elements. Vennlig hilsen Bj?rn N?ss Produktansvarlig DIPS ASA Mobil +47 93 43 29 10tel:+47%2093%2043%2029%2010 Original message From: Thomas Beale Date:20/11/2014 19:07 (GMT+01:00) To: openehr-technical at lists.openehr.org Subject: Re: Problem-oriented records and querying by problem I wonder if the GP 'master care plan' is more like a 'care plan dashboard' rather than an actual care plan? With functions like 'show all overdue / suspended / etc etc'... - thomas On 20/11/2014 17:25, Heather Leslie wrote: Hi Karsten, I think in practice you will see a variety of care plans depending on the context. The endocrinologist will be using a diabetes care plan for their care of the patient, and likely not having access to, nor particularly interested in, what other specialists might be scheduling. The cardiologist will be using a cardiology-protocol-based care plan, probably developed in splendid isolation from the endocrinologist activities. The rehab specialist will be using a purpose-built care plan for the patient's recovery from a knee replacement. However it will be critical that the GP or coordinating primary care provider develop/need a single global care plan, (which can be separated out for the different purposes, if needed) that provides an overview of all activities that the patient requires - what is due, overdue, planned etc. This will ensure that the blood glucose and renal function tests required by both the endocrinologist and cardiologist iare coordinated, if clinically appropriate and tests/appts not repeated unnecessarily. They will have access to a 'master' plan that will detail all reviews/goals/test/appointments for each 'specialty' plan and have the ability to coordinate the components to suit the best interests of the patient as a whole - a care plan for the patient, not just one per problem. The patient or the parent/caregiver will also benefit with being able to schedule appointments/tests etc. And we will need to be able to break down that master care plan to see which components belong with each problem, or are shared between problems, and for context-based sharing with other health care providers. ___ 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/20141125/4881c919/attachment.html
Problem-oriented records and querying by problem
On Wed, Nov 19, 2014 at 02:42:57PM +, Thomas Beale wrote: 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). While I agree that that's something to consider I am creating care plans all day, for both complex and trivial problems. It is very much in the eye of the beholder what's trivial and what's not. My patients are so much the happier for their plan for one-off throat infection. well that's my point actually. If a doc wants to create a care plan for X, then X for patient P is by definition a 'problem' in that doc's opinion, and consequently in P's care. And that's where I think the care plan distinction breaks down. Good clinical practice would ideally mandate creating a plan for any issue brought up during a healthcare-patient encounter. Providers and patients may decide to ignore certain issues in a given setting but that doesn't help much either - the remaining issues would all become problems because they would all ask for a care plan. IOW, since all non-ignored issues want a care plan they all become problems. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
On Thu, Nov 20, 2014 at 12:57:38PM +0100, Karsten Hilbert wrote: 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). While I agree that that's something to consider I am creating care plans all day, for both complex and trivial problems. It is very much in the eye of the beholder what's trivial and what's not. My patients are so much the happier for their plan for one-off throat infection. well that's my point actually. If a doc wants to create a care plan for X, then X for patient P is by definition a 'problem' in that doc's opinion, and consequently in P's care. And that's where I think the care plan distinction breaks down. Good clinical practice would ideally mandate creating a plan for any issue brought up during a healthcare-patient encounter. Providers and patients may decide to ignore certain issues in a given setting but that doesn't help much either - the remaining issues would all become problems because they would all ask for a care plan. IOW, since all non-ignored issues want a care plan they all become problems. All in all we seem to mean the same thing except I contest the usefulness of requiring-a-care-plan to define problem. There can be problems which are of the nature take into account but don't directly act on for conducting other care. Say, a surgeon will be well aware of a patient's diabetes (as in considering causes for delayed healing, or considerate selection of drug therapies) -- and may want to record that as a patient problem -- but will not necessarily render associated care (until a toe needs to be taken off) and thusly will not establish a care plan. Perhaps the gist is: Issues for which a care plan is established are considered problems while there still may be problems without a care plan. Karsten Hilbert -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
Hi Karsten, firstly, I am not offering the Care Plan means of extensionally identifying problems as a bullet-proof method; it's just a working theory at this stage. For the above: wouldn't this patient normally have a diabetic care plan, and for surgery that is not diabetic related, then there will be a care plan for that, say 'left hip problem' or whatever. If the surgery is diabetic related, then it would presumably occur as an intervention that is part of the diabetic care plan? - thomas On 20/11/2014 12:05, Karsten Hilbert wrote: And that's where I think the care plan distinction breaks down. Good clinical practice would ideally mandate creating a plan for any issue brought up during a healthcare-patient encounter. Providers and patients may decide to ignore certain issues in a given setting but that doesn't help much either - the remaining issues would all become problems because they would all ask for a care plan. IOW, since all non-ignored issues want a care plan they all become problems. All in all we seem to mean the same thing except I contest the usefulness of requiring-a-care-plan to define problem. There can be problems which are of the nature take into account but don't directly act on for conducting other care. Say, a surgeon will be well aware of a patient's diabetes (as in considering causes for delayed healing, or considerate selection of drug therapies) -- and may want to record that as a patient problem -- but will not necessarily render associated care (until a toe needs to be taken off) and thusly will not establish a care plan.
Problem-oriented records and querying by problem
On Wed, Nov 19, 2014 at 02:12:31PM -0300, pablo pazos wrote: The question was not how to do X in a POMR, the question was how to model a POMR in openEHR. Please read my first message to the list. I certainly did. I was not precise in my first wording. What I wanted to point out was that if we ask the question How to _view_ (display) an existing medical record _as_ a POMR ? we seem to have missed the fact (as to my understanding) that any existing medical record very much IS a POMR and that it cannot be any other way. Non-POMRs would seem to be data storage containers (of instances of medical data) rather than clinically useful _medical_ records. It is only the clinical integration of biological data (of whichever quality or type) that turns data into information and thusly a medical record. Is not for me to define what a problem is, I don't need/care to do that, that's for a physician to define. What I need is to provide an structure in which a physician can do that, using openEHR of course. What I've been wondering is that the need to turn data into problem-related information (in order to be useful) will seem so fundamental to any clinician that doing so would seem to be one of the first and foremost functionality of any medical record software. Also, POMR in this context is by Weed's definition, so it has a specific structure not every record has: a master problem list, statuses for each problem, progress notes for each problem, etc. (I wasn't aware that Weed had defined statuses on problems -- is there a link for reading up on that ? So for I only found http://www.geritech.org/2013/05/medicine-in-denial-problem-oriented-medical-record.html ) I agree that the Weed model of POMR seems best suited to comprehensive, longitudinal care but I would really like to learn of just one counter-example to the following proposition: Any medical record lends itself to being structured according to the POMR model. Therefore it should in order to afford internal clinical sense (what I am not saying here is that every clinician must be presented with a problem oriented view or even that that would best suit every clinicians workflow). In the other hand, yes, that information is in every MR, but you have to read a lot to find all the info relevant to a specific problem. What we need to do is to have that information linked in an explicit way to avoid that manual search, and have all the relevant info at one click of distance. IMO that was Weed's idea. Here we are on the same side of things. What I am stressing is that I would really expect any _information_ model intended for clinical use as a patient-centric medical record to easily afford the POMR approach. In my personal view it should really even enforce problem orientation internally. Otherwise said model would be a _data_ model (of which being an excellent one is really desirable). So, back to your question, are we looking for where exactly (and how) OpenEHR turns from a data model into an information model (as per my attempt at definition above) ? Karsten Hilbert Declaration of potential conflict of interest: I have helped implement a POMR. -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
Hi Thomas, firstly, I am not offering the Care Plan means of extensionally identifying problems as a bullet-proof method; it's just a working theory at this stage. Sure, I am not trying to put people wrong (I can't, at any rate), just treading the line a bit of being advocatus diabolus... For the above: wouldn't this patient normally have a diabetic care plan, and for surgery that is not diabetic related, then there will be a care plan for that, say 'left hip problem' or whatever. Agree. If the surgery is diabetic related, then it would presumably occur as an intervention that is part of the diabetic care plan? Agree except that the primary diabetic care plan would live at the GP office (or the diabetes clinic office) while the surgeon would now set up her own diabetes-related surgery care plan under the problem diabetes. However, even before that the surgeon would certainly want to record the fact diabetes as a problem such that she is reminded of one potential cause of future wound infections, delayed healing processes, ... in surgery *not* related to diabetes itself. A considerate surgeon would want to be able to recommend getting blood sugars checked and/or even switch from oral diabetes medication to insulin application for the time of healing of a non-diabetes wound. But there wouldn't be a diabetes care plan per se (at the surgeon's) during such times. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
On 20/11/2014 12:45, Karsten Hilbert wrote: In the other hand, yes, that information is in every MR, but you have to read a lot to find all the info relevant to a specific problem. What we need to do is to have that information linked in an explicit way to avoid that manual search, and have all the relevant info at one click of distance. IMO that was Weed's idea. Here we are on the same side of things. What I am stressing is that I would really expect any _information_ model intended for clinical use as a patient-centric medical record to easily afford the POMR approach. In my personal view it should really even enforce problem orientation internally. Otherwise said model would be a _data_ model (of which being an excellent one is really desirable). So, back to your question, are we looking for where exactly (and how) OpenEHR turns from a data model into an information model (as per my attempt at definition above) ? this is my interest as well, and the reason for thinking about Care Plans as computational objects, that include partly computed (queried) contents. Note that the whole design of openEHR is more or less predicated on a POMR idea, fairly equivalent to models like the 'hypothetico-deductive model of problem solving'. That's why we included Entry types in the information model like Observation, Evaluation (meaning: any kind of assessment or opinion), Instruction, Action and AdminEntry. Experience has shown that these are a pretty good match for most clinical information, but that refinements are needed in future generations of the openEHR approach, most notably to decouple the epistemic types mentioned above from being 1:1 with fixed data structures, as Ian McNicoll has often argued. But the general principle won't change - each piece of information committed to the EHR will have an epistemic type/status related to the POMR approach. The current challenge in my opinion is to define computational objects that correspond to higher level entities, like 'medication list', 'problem list' and 'care plan', each of which is at least partly a computed index into the relevant 1st level information items (i.e. the raw obs, Dx, actions etc). There are some good preliminary pieces of work around on this that need to be put together. - thomas
Problem-oriented records and querying by problem
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 +, 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
Problem-oriented records and querying by problem
!--.ExternalClass .ecxhmmessage P {padding:0px;}.ExternalClass
body.ecxhmmessage {font-size:12pt;font-family:Calibri;}--!--.hmmessage P
{margin:0px;padding:0px;}body.hmmessage
{font-size:12pt;font-family:Calibri;}--!--p.MsoListParagraph,
li.MsoListParagraph, div.MsoListParagraph
{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;}p.MsoNormal,
li.MsoNormal, div.MsoNormal
{margin:0in;margin-bottom:.0001pt;}p.MsoListParagraphCxSpFirst,
li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst,
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle,
div.MsoListParagraphCxSpMiddle, p.MsoListParagraphCxSpLast,
li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast
{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;line-height:115%;}--
Nice! I didn't considered the alternative using folders.
I'm guessing there is no recommended way to implement the p-o record.
Does anyone else implemented this in a different way? What is your experience?
Thanks a lot!
Pablo Pazoswww.CaboLabs.com
It is really problematic in most systems. First there are often more than one
problem addressed. Second, a lot of them are trivial and one off and do not
need to be on the problem list (more reason for encounter).
I like the idea of doing this with folders in openEHR. No need to link from the
document so it can be done retrospectively. It can even be different for
different users potentially.
Cheers Sam
Dr Sam Heard
Chairman, openEHR Foundation
From: pablo pazos
Sent: ?Tuesday?, ?18? ?November? ?2014 ?1?:?04? ?PM
To: For openEHR technical discussions, For openEHR clinical discussions
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.
Thanks!
--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com
From: pazospa...@hotmail.com
To: openehr-technical at lists.openehr.org
Subject: Problem-oriented records and querying by problem
Date: Thu, 6 Nov 2014 13:28:40 -0300
Hi, another question related to querying:
I have a case of problem-oriented records, where I need to query all the
COMPOSITIONS related to a specific problem (evolutions, controls, etc).
Since we have a Problem List persistent archetype that records OBSERVATIONS
about the health problems:
- Would it be a good solution to use LINKs between those OBSERVATIONs and the
COMPOSITIONs related to those problems in order to solve the query
COMPOSITIONS by health problem?
Is there another solution for this? What do you think?
Thanks!
--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com
___ 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/b18b61ca/attachment.html
-- next part --
___
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Problem-oriented records and querying by problem
How to do X in a Problem Oriented Record If one poses this question one has not understood one fundamental aspect of ALL medical records pertaining to a single patient (as opposed to epidemiological records): _All_ data is _always_ problem oriented. Any record keeping system must support attributing things to problems. Exactly what constitutes a problem depends on the patient, the provider, the level and type of care, the current focus of attention, the granularity of record keeping, circumstantical happenstance, knowledge of the day, etc. It may go so far as to seem to not be a problem oriented record -- in cases of extreme speciality, say, a geneticist only giving advice on one specific mutation in a given patient. That is, however, only a special case -- a singular problem -- of a problem oriented record. One can choose to ignore this fact but that is choosing to ignore a part of reality. Not necessarily inappropriate for solving a given problem but still fundamentally wrong (as to our current level of understanding of reality, of course). Documents are a special case since they often display properties of a summary of care over a range of problems and thusly need to be linked with several problems in a target record. Lab results are another case to consider: All things considered every single result (rather than the battery that was ordered) needs to be linked to potentially several problems. Batteries may get ordered on behalf of a single problem but results rarely apply to only one. Such is the wetware reality of healthcare involving actual human beings. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141119/f16c82d9/attachment.html
Problem-oriented records and querying by problem
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
Problem-oriented records and querying by problem
On Wed, Nov 19, 2014 at 01:35:06PM +, Thomas Beale wrote: 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). While I agree that that's something to consider I am creating care plans all day, for both complex and trivial problems. It is very much in the eye of the beholder what's trivial and what's not. My patients are so much the happier for their plan for one-off throat infection. It's an interesting point of view. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
Hi all, Sorry. Coming late to the party. I think the Contsys 'Health Issue Thread' has this correct (similar) to the HL7 Concern structure, which expresses a need to restructure , re-prioritise or re-frame a list of originally recorded problems, diagnoses or issues to reflect a specific clinical context and requirement. So Health Issue Threads appear in Care Plans, Discharge documents, episodic Problem lists (as per Larry Weed) and, of course the longitudinal holistic Problem list as would be carried in a GP system. The main problem we have in openEHR is that these are often tree-like structures, reflecting groupings of conditions by episode or clinical relevance e.g. Ischaemic Heart disease 2004 Angina 2006 MI April 2006 June 2006 readmission Although we can, of course, create these structures with LINKS, we do not have an easy way to model thos kind of construct or to query it generically. This might be useful http://www.openehr.org/wiki/display/healthmod/Problem,+Issue,+Diagnosis+and+Concern A have built a wee Health Issue thread archetype to act as the container but Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 19 November 2014 14:42, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 19/11/2014 14:04, Karsten Hilbert wrote: On Wed, Nov 19, 2014 at 01:35:06PM +, Thomas Beale wrote: 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). While I agree that that's something to consider I am creating care plans all day, for both complex and trivial problems. It is very much in the eye of the beholder what's trivial and what's not. My patients are so much the happier for their plan for one-off throat infection. It's an interesting point of view. well that's my point actually. If a doc wants to create a care plan for X, then X for patient P is by definition a 'problem' in that doc's opinion, and consequently in P's care. So there it doesn't matter what the problem is - fractured toe or cancer, it's up to some health care professional to decide. I am just thinking of abstractions that can be usefully concretised to provide a good framework for applications to enable the patients care team to do their work, and to find create information in a natural way. - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Problem-oriented records and querying by problem
Hi Karsten, The question was not how to do X in a POMR, the question was how to model a POMR in openEHR. Please read my first message to the list. Is not for me to define what a problem is, I don't need/care to do that, that's for a physician to define. What I need is to provide an structure in which a physician can do that, using openEHR of course. Also, POMR in this context is by Weed's definition, so it has a specific structure not every record has: a master problem list, statuses for each problem, progress notes for each problem, etc. In the other hand, yes, that information is in every MR, but you have to read a lot to find all the info relevant to a specific problem. What we need to do is to have that information linked in an explicit way to avoid that manual search, and have all the relevant info at one click of distance. IMO that was Weed's idea. Hope that helps to clarify my question. -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com Date: Wed, 19 Nov 2014 13:57:04 +0100 From: Karsten.Hilbert at gmx.net To: openehr-clinical at lists.openehr.org; openehr-technical at lists.openehr.org Subject: Re: Problem-oriented records and querying by problem How to do X in a Problem Oriented Record If one poses this question one has not understood one fundamental aspect of ALL medical records pertaining to a single patient (as opposed to epidemiological records): _All_ data is _always_ problem oriented. Any record keeping system must support attributing things to problems. Exactly what constitutes a problem depends on the patient, the provider, the level and type of care, the current focus of attention, the granularity of record keeping, circumstantical happenstance, knowledge of the day, etc. It may go so far as to seem to not be a problem oriented record -- in cases of extreme speciality, say, a geneticist only giving advice on one specific mutation in a given patient. That is, however, only a special case -- a singular problem -- of a problem oriented record. One can choose to ignore this fact but that is choosing to ignore a part of reality. Not necessarily inappropriate for solving a given problem but still fundamentally wrong (as to our current level of understanding of reality, of course). Documents are a special case since they often display properties of a summary of care over a range of problems and thusly need to be linked with several problems in a target record. Lab results are another case to consider: All things considered every single result (rather than the battery that was ordered) needs to be linked to potentially several problems. Batteries may get ordered on behalf of a single problem but results rarely apply to only one. Such is the wetware reality of healthcare involving actual human beings. 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/20141119/dfcbfe68/attachment.html
Problem-oriented records and querying by problem
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. Thanks! -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com From: pazospa...@hotmail.com To: openehr-technical at lists.openehr.org Subject: Problem-oriented records and querying by problem Date: Thu, 6 Nov 2014 13:28:40 -0300 Hi, another question related to querying: I have a case of problem-oriented records, where I need to query all the COMPOSITIONS related to a specific problem (evolutions, controls, etc). Since we have a Problem List persistent archetype that records OBSERVATIONS about the health problems: - Would it be a good solution to use LINKs between those OBSERVATIONs and the COMPOSITIONs related to those problems in order to solve the query COMPOSITIONS by health problem? Is there another solution for this? What do you think? Thanks! -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com ___ 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/20141118/6dd1709c/attachment.html
Problem-oriented records and querying by problem
Hi, another question related to querying: I have a case of problem-oriented records, where I need to query all the COMPOSITIONS related to a specific problem (evolutions, controls, etc). Since we have a Problem List persistent archetype that records OBSERVATIONS about the health problems: - Would it be a good solution to use LINKs between those OBSERVATIONs and the COMPOSITIONs related to those problems in order to solve the query COMPOSITIONS by health problem? Is there another solution for this? What do you think? Thanks! -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141106/9776/attachment.html
