# Problem-oriented records and querying by problem **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2014-11-06 16:28 UTC **Views:** 2 **Replies:** 34 **URL:** https://discourse.openehr.org/t/problem-oriented-records-and-querying-by-problem/15630 --- ## Post #1 by @pablo 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! --- ## Post #2 by @pablo 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! --- ## Post #3 by @Sam 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 --- ## Post #4 by @pablo 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 Pazos [www.CaboLabs.com](http://www.CaboLabs.com) --- ## Post #5 by @Karsten_Hilbert "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 --- ## Post #6 by @thomas.beale 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 --- ## Post #7 by @Seref 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.. --- ## Post #8 by @Karsten_Hilbert 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 --- ## Post #9 by @thomas.beale 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 --- ## Post #10 by @ian.mcnicoll 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@freshehr\.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon\. Senior Research Associate, CHIME, UCL --- ## Post #11 by @pablo 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. --- ## Post #12 by @Karsten_Hilbert 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 --- ## Post #13 by @Karsten_Hilbert 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 --- ## Post #14 by @thomas.beale 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 --- ## Post #15 by @Karsten_Hilbert > 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\. --- ## Post #16 by @Karsten_Hilbert 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 --- ## Post #17 by @thomas.beale 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 --- ## Post #18 by @Karsten_Hilbert > 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 --- ## Post #19 by @Seref 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 --- ## Post #20 by @heather.leslie 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\. Regards Heather --- ## Post #21 by @thomas.beale 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 --- ## Post #22 by @heather.leslie Hi Thomas, You will need those statuses from every activity in every type of care plan, whether separated or aggregated\. > From the general coordinating provider point of view the overwhelming response we hear is that they want one single care plan that covers all problems rather than having to view multiple fragmented ones for each problem, although the ability to see the origins of each activity is also necessary for viewing, sharing in context etc\. This could either be implemented as a master view of an amalgamation of all 'problem'\-based care plans, with ability to reconcile equivalent or similar acitvities or lump some together to be achieved simultaneously eg send the patient off for a single blood test at which all due bloods can be done\. Or alternatively it can be a single care plan that uses some method to tag with the problem/s for separation out when clinically relevant\. I don't particularly mind \- it is largely an implementation question from my POV\. Our implementations tend to the single care plan Heather --- ## Post #23 by @system 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 10 --- ## Post #24 by @Koray_Atalag 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? --- ## Post #25 by @Koray_Atalag Sorry I meant ” I don’t think ‘natural order’ (as in DMBS) of an EHR **can** be of POMR type” --- ## Post #26 by @Karsten_Hilbert 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 --- ## Post #27 by @Karsten_Hilbert 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 --- ## Post #28 by @Koray_Atalag 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\. Cheers, \-koray --- ## Post #29 by @thomas.beale 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 . 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 --- ## Post #30 by @Karsten_Hilbert > 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 --- ## Post #31 by @system The FOLDER approach suggested by Sam looks interesting and flexible for some problem-oriented applications. Especially since folders can be hierarchical (problem vs sub-problem?) and are versioned (and thus easily can be updated without losing log/history info). What are the experiences positive/negative from using this approach for problem orientation? Any documented? --- ## Post #32 by @Sam Hi There are a number of possibilities and it will inevitably vary. First, some things get into “persistent” lists that are not ongoing. These are generally removed or demoted to being inactive. Second, some things need to stay in “persistent” lists and are very important even if there is no idea of care - breast cancer for example. The risk of recurrence gets very small after 10 years but it is never zero. Third, care plans will be multiple but need to be as consolidated as possible. There might be a different care plan for different professionals or activities linked to different professionals within the same care plan. A nursing care plan during respite care for a disabled person may be very different from that person’s ongoing care plan in the community. The interventions for hypertension, hyperlipidaemia, obesity, diabetes type II and ischaemic heart disease overlap massively. So the principles as I see them are: 1. As few care plans as possible - certainly not one per problem 1. The scope of the care plan to be visible - hospital, aged-care facility, community 1. Care plans need to be merged and separated and updated and closed. I think that a collection of instructions in a composition linked to actions undertaken is the best technical solution. If you want that linked to a particular problem or set of problems we could archetype that in the links….or have an explicit data point for the problem (with a link). Time will tell. Cheers, Sam --- ## Post #33 by @ian.mcnicoll Hi Erik, I am not sure that FOLDERS are the correct solution, since these can only contain Compositions \(or other folders\) which is a pretty clunky way of maintaining a problem list whose core artefacts will be ENTRY\-level archetypes\. it also prevents the roots and branch aspects of the tree\-like list from containing important meta\-info like a problem name or dates\. For a problem list, we are certainly looking at some sort of separate composition, maintained separately from the core event compositions in which the problems were originally entered, either by copying the original ENTRIES or \(I think more correctly, via LINKS, but that is partly an implementation issue\. Whilst the current 'persistent' composition arrangement works ok for GP\-type longitudinal problem lists, setting the composition\.type attribute to 'persistent' prevents the use of composition\.context which is too restrictive for e\.g an episodic problem list maintained across a hospital admission\. Both the HL7 Health Concern DAM and CEN Contsys Health Thread documentation are pretty well aligned in overall requirements\. In particular both envisage the use of problem thread type constructs within much more defined contexts such as a discharge/ referral document or even a Care plan\. The longitudinal problem list is just a very specific sub\-type of this construct\. https://github.com/openehr-clinical/shn-contsys with some example archetypes and mindmaps\. This approach does rely heavily on LINKS, which I think is unavoidable because of the need to nest ENTRY level constructs, whether these ENTRIES are held in\-line with in the same Composition or a referenced from a different composition\. The Health Thread archetype is the root ENTRY which contains one of more Health Issues which is the container for the real payload of ENTRIES, which can be of any ENTRY class\. Since developing this arrangement I have begun to wonder if Health Issue is actually redundant and that we could simply use the Problem /Diagnosis archetype in that role\. This would simplify the structure for simple uses case, whilst ensuring that the root of any Health Issue was a Problem/Diagnosis, beneath which any kind of ENTRY is allowed e\.g a medication statement, procedure or even in some cases and admin\_entry\. The other very tricky area is how to reconcile this approach with the more common arrangement in episodic care of e\.g\. Primary Diagnoses/ procedures, Co\-morbidity, other problems etc\. It would be nice to find means to bring these two approaches together\. Ian Dr Ian McNicoll mobile \+44 \(0\)775 209 7859 office \+44 \(0\)1536 414994 skype: ianmcnicoll email: ian@freshehr\.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon\. Senior Research Associate, CHIME, UCL --- ## Post #34 by @Sam Hi Ian I do not propose that Folders be the problem list, rather that it is possible to link compositions to problems by placing them in Folders. The advantage is that it is possible to create a query response that is determined consciously by clinicians rather than all the links people have created for whatever reason. Also, a problem has to be quite substantial to warrant organising the content of the EHR. I agree with your approach, I think I was talking about an additional means - it may only work in some settings but it is sustainable I think. Cheers Sam --- ## Post #35 by @Nadim_Anani This JAMIA article, published four years ago, relates closely to some of Ian's points below: [http://www.ncbi.nlm.nih.gov/pubmed/21106993](http://www.ncbi.nlm.nih.gov/pubmed/21106993) It also has an appendix containing a care plan EVALUATION archetype the authors created. Kind regards, Nadim --- **Canonical:** https://discourse.openehr.org/t/problem-oriented-records-and-querying-by-problem/15630 **Original content:** https://discourse.openehr.org/t/problem-oriented-records-and-querying-by-problem/15630