Problem orientation in OpenEHR

How would we do this?

There is a method of implementation in problem oriented records whereby a header, generally the ‘problem’, is linked to other record entries or elements that are to do with that problem.

So ‘chest pain’ as a problem may be linked to blood tests, clinical notes, ECG, CXR and medications that were ordered or reported as part of the work up of that condition.

In interfaces this allows for views of the record showing the Problem and all linked events/entries/data. It’s essentially what Larry Weed used to talk about.

Of course things may relate to more than one Problem, Problems may link to each other, Problem headers and content will change over time. There is usually a fair amount of manual curation, which may be very contextual, but theoretical a lot of it could be automated.

By modelling this linkage in data it would become computable, and potentially make some clinicians very happy in their work!

Is this something that is part of openEHR specification or that can be modelled in archetypes? Or is it down to the application to manage this?

Thanks for any help. As always slightly anxious that am missing something completely obvious, so apologies if so!!

Paul

Dr Paul Miller

GP, Glenburn Medical Practice

Clinical Lead, NES Digital Service

Mobile/WhatsApp: +44 7711 346 938

Hi Paul,

things like Problem lists are ‘interesting’, and I consider them a second order informational artefact. The short answer on how to do them is probably something like this:

  • creating an artefact to represent a specific problem such as chest pain will mostly be done at execution time, by working clinicians deciding what things are ‘related to’ the given problem;
  • such choices are likely to be somewhat subjective, i.e. no guarantee that two clinicians would make the same choices;
  • technically a problem in the POMR sense could be represented as a dedicated Composition containing LINKs or DV_EHR_URI references to the bits and pieces of interest elsewhere in the EHR;
  • tag(s) could be added a priori to EHR content (e.g. lab results, physical exams, ECGs, etc) before it is committed, identifying it as part of some particular problem(s), or similarly, Compositions could be classified under Folders representing problems, just as they already are under Folders representing episodes - but of course this relies on health workers knowing what problems are ‘defined’ in the EHR, and whether the new content should be added.
  • Realistically, most linking of content to a problem is likely to be a post hoc process.

As yet, the machinery to do this mostly exists, but there is little in the way of standardised patterns or usage of it to achieve any kind of standardised ‘problem’ document (NB: not the same as ‘problem list’ - which is one level up, and is a managed list of issues considered to be problems, usually inclding current Dxs such as diabetes etc).

To go further, e.g. to automate any of this would be a question of creating rule-sets in which each rule detects a certain kind of content being committed (using an AQL query or AQL path matcher or ADL match expression), and adds a link to that content from the dedicated Composition. Such rules would be evaluated on data commits to the EHR inside a rule engine.

I suspect the best we can do at the moment is to standardise use of the above mechanisms to create problem descriptions in a generic sense. Experimentation with rules over time should eventually generate some reliable patterns.

  • thomas

Here was an earlier effort by me based on the Contsys approach.

https://github.com/openehr-clinical/shn-contsys

Ian

Hi Paul,

We can do it but I am increasingly of the view that although it makes some clinicians very happy it makes many others very unhappy as proper POMR requires huge discipline, and is hard to maintain. As others have said … links.. but manging those links both clinically and technically is challenging.

I spent much of GP career advocating (and doing) POMR but I’m not now at all convinced that the effort is worth it or sustainable.

Ian

Hi Paul,

In theorical, PMOR are estructured using some resources, but the essencial for your question is a SOAP method estructure used to organize your annotation in some encounter.

The link between the problem and others records is a SOAP estructure. Where section “A” report one or many problems when episode oriented record or cronological record. The Problem List, how said, are de second step, but very important to make a following.

These archetypes exists in openehr.org/ckm, are these:

openEHR-EHR-COMPOSITION.encounter.v1 - link SOAP (or SOAPs) with a time/event

openEHR-EHR-SECTION.soap.v1 - to link all record with a problem or problems

openEHR-EHR-EVALUATION.problem_diagnosis.v1 - problem inside the SOAP

openEHR-EHR-COMPOSITION.problem_list.v1 - link list with a time (update event)

openEHR-EHR-SECTION.problem_list.v0 - organize a list

openEHR-EHR-CLUSTER.problem_qualifier.v1 - status of the problem

In my opinion, in this existing structure, only miss one link in the current qualifier of the problem (openEHR-EHR-CLUSTER.problem_qualifier.v1) indicating the previous problem (and SOAP record). This would make it possible to trace a problem and connect all other records (blood tests, clinical notes, ECG, CXR and medications).

Regards,

Gaete

Thanks all that’s really helpful.

I do think it is a requirement though agree needs to be a balance between manual curation and automation which may not be possible at present, or even desirable?!?!

I’ll check out the SOAP archetypes tomorrow.

Good to know we have the capability if not the answer!

Of course it is up to the clinicians to tell us what they want to do, they need to shape the content of the records. I am pretty certain linkage somewhere has a role to play.

Paul

other than the SOAP heading structure, of course, as described in another post on this thread.

Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare <https://intermountainhealthcare.org/&gt;
Management Board, Specifications Program Lead, openEHR Foundation <http://www.openehr.org>
Health IT blog <http://wolandscat.net/&gt; | Culture blog <http://wolandsothercat.net/&gt; | The Objective Stance <https://theobjectivestance.net/&gt;

Hello all

I am a lurker von this list - don’t have the expertise of most of you blokes

(BTW I play music with Sam Heard regularly)

However I thought I should comment on this issue

As I understand it one of the major advantages of a properly designed data modelling system such as OpneEHR is that it is computable

For me one of the first tasks for an intelligent system of decision support after things like flagging abnormal observations in a score would be to create a “Careplan” ie a schedule of recalls and interventions to manage Chronic Disease and Multimorbidiity. This would of course depend on the relevant issues being defined as a “problem” or diagnosis.

Each Careplan would be different depending on the client’s problems

Yes I accept there is argument as to what constitiutes a “problem” - for me it is an ongoing, significant discrete issue or group of issues such as Diabetes, Renal failure, a cancer of some sort, Ischaemic Heart Disease etc

Much of our work nowadays in Primary Care is managing the demands of complex multimorbidty.

Would be interested in comments

R

Hi Richard
My quest after standards for health Information Systems content, representation and display has ended in 2007, curiously when attending a WGM HL7 meeting in San Diego.
There I met Sam, your band’s mate, which introduced me to OpenEHR view of the world of EHR.
Since there I am working hard to convince all people I know to adopt a common content and structural model for health IT systems, having some huge progresses so far, but also serious backlashes in this journey.
Like you, I really think that we do have to create models that can accommodate local requirements and at the same time to fit in a national or international digital health initiative.
Care plans are individual at some point, meaning they are personal, but, at the same time, they ought to share information archetypes, which will allow to build more generic templates or unique combinations for a particular subject of care. Archetypes comprise common and reusable structures and codes stored and managed in a knowledge repository for all community to use.
That’s why I think that templates are sheer conjunctures, while archetypes are the foundation structures. I really don’t care about mnemonics like SOAP. They are one of the many shortcuts created to help Clinicians to make a diagnosis and suppor their reasoning and decision in this new world of miriade of data sources.
Who learned clinical semiotics in Medical school before problem oriented weed’s model were taught that first you have to ask, then you observe meticulously all signs, after that you make a reasoning based on symptoms and signs observed, maybe you have to ask for more evidences to support your diagnosis and to help you to make an adequate decision. Was that wrong? Maybe it was not prepared for computers .
Maybe it was too abstract for that computer binary one zero Systems. Today I do believe it has contributed for the impoverishment of investigative and medical decision-making skills of diagnosis and reasoning skills among doctors.
My dream is that computers can support clinicians to do what they are trained to be, professionals that challenges all days the tasks of diagnosing and treating human disease, ailments, injuries, pain or other conditions. This must be done by listening to the patient, understanding the problem, and then using their scientific expertise to know how best to treat the ailment or concern. These skills can be really enhanced by computers systems, but to be effective computer systems need to share common information models and terminologies to them understand the complexities and different sets of care.
I agree with you that abnormal observations should be flagged, but abnormal information is contextual, means different things to different patients in differents care journeys.
Actually to be universal understood, clinical
Ideas must agree on semantics. This is the hardest part, people still prefer to map from a proprietary closed view to another, Schade’
I’d really like a feedback and apologize for my poor English skills.

Regards

Jussara Rötzsch

A few of my thoughts abd advice:

1- have a look at the CEN/ISO standard defining the concepts related to Continuity of Care.
2- For may years Dutch GP’s use the SOEP method of documenting the provision of health and care. (SOEP=Subjective, Objective, Evaluation, Plan)
3- For many years we collected data items under the heading of Problem in a Problem List f(PrL) or use by one Healthcare Provider (HcP)
4- Then the Episode (Ep) was introduced because GP’s started to collaborate with other HcP’s.
5-The progression of the developments in the Patient System over time cause changes in the title of the PrL and Ep.
E.g. PL title = Reason for Encounter (cough); then PL title=Pulmonary infection; then PL title=Tuberculosis;
Ep titles probably will have the same titles.
6- The Continuity of Care standard provides a lot a fine detail. In order to make things simple I used my compatible version of the medical treatment model of that standard,

  1. Observation in the Patient system (PS) that is documented
  2. Evaluation of the Observations, PrL, EL, etc leading to differential diagnosis, working diagnosis or determined diagnosis
  3. Planning. Differential Diagnosis will lead to plans with goals to prove or disprove diagnosis or start treatment
  4. Actions. Plans a re broken down to actioned and documented procedures influencing the PS or other (non-PS) systems for administrative purposes such as data exchange, requests, scheduling, updating the PL and/or Ep
  5. Followed by Observations that are documented.

Steps i to 4 each have a fixed Pattern Archetype as ENTRY archetype
All PS and Ep’s are collected in distinct FOLDERs the FOLDER shows the progress of the health and care process over time.

Gerard Freriks
+31 620 34 70 88
‭+31 182 22 59 46‬
gfrer@luna.nl

Kattensingel 20
2801 CA Gouda
the Netherlands

I’m not ready to give up on POMR just yet. It is a lot of work and difficult to maintain, as Ian points out, but as a locum GP, when I work in practices that use problem orientation it is MUCH easier and safer to treat people you don’t know. Practices that just dump everything into the record without Problem Orientation are just asking for trouble medicolegally IMO.

What worries me about this conversation is that, among UK GPs, I’m probably in the upper 0.1th percentile of health technology understanding among them. I’ve been learning about openEHR since 2012. And I still don’t fully understand this conversation. Is it me? Or are we going to have a bit of a problem getting your average clinician to participate in the design of future POMRs unless we make it much less technical?

Marcus

Just reflecting on what a SOAP note has traditionally been (in my non-MD understanding), the original idea was to use the 4/5 headings to capture things to do with a specific problem in a clean way during consultations and further ‘clinical thinking’. We don’t need to discuss this now; SOAP is a very good model, epistemologically speaking (the common 7+ headings used in many hospitals has another explanation - let’s avid for now), so let’s just assume that SOAP headings are a good idea.

In early attempts at the EHR, my impression is that a new SOAP note was created in each consultation, and that previous SOAP notes were treated like any other forgettable item in the EHR, like a BP measurement from 3 month ago. But is is pretty clear that SOAP notes (if they are to be used) should really be considered as ‘persistent’ Compositions (in openEHR, a ‘persistent’ Composition is one containing content that is at least potentially valid for all/much of the patient’s life, e.g. most managed lists, family history, vacc history and so on). If we treated SOAP notes as persistent things that were always retruned to with each new consultation, lab result, and intervention on that problem, the POMR view of things would be very clear.

The potential problem, at a computing/data level, is to implement the idea wrongly, and to actually include inline the data items being generated by all these activities, inside the SOAP note. This won’t really work for at least 3 reasons:

  • many Obs (including VS & labs) relate to multiple problems, e.g. most vital signs - do you record copies in all (say) 4 extant SOAP notes? No - that kind of data cloning destroys querying.
  • quite often, docs and nurses do Obs that don’t relate to a specific problem. In the ER, the problem might not be known for some time; a GP health checkup is not a problem-specific consult… so in these cases, you don’t have any SOAP note to which you would attach the data.
  • it is often only clear later on which problems any given Obs, Dx etc relate to, so really, the freedom is needed to commit isolated info (e.g. recorded by patient devices) to the EHR, and then (maybe) link it to SOAP notes later on.

In openEHR, most if not all implementations I know of already operate on a ‘commit-data-now’ basis, without trying to be very POMR. To make an openEHR EHR a POMR, I would say that any SOAP note has to be given a status of ‘persistent’ (or maybe some new status, like ‘ongoing’, which could be changed later), and then, as different treating docs work with patients, they will progressively compile the content of any SOAP note, using linking to committed EHR content. This means a) post-hoc SOAP note building can occur; b) more than one SOAP note can refer to the same Obs, labs, Dx etc; c) querying for clinical Obs, Dxs etc remains independent of SOAP notes and d) SOAP notes don’t get lost in the miasma of past event data, they are instead headline parts of the EHR.

In this way, SOAP notes, inasfar as they are used in any given EHR, become a progressively built view of each problem, not just a way of structuring an encounter note.

What do the healthcare professionals here think about this view?

  • thomas

I do agree pomr has an important role in primary care and I like the proposal of Thomas to manage it in openEHR. I am not sure why pomr never took on in hospitals. Larry Weeds idea was not restricted to primary care.

Gunnar Klein, GP an professor of health informatics

Den tors 27 juni 2019 19:14Thomas Beale <thomas.beale@openehr.org> skrev:

If I wanted to solve POMR in a simple way without repetition, I’d use Tagging
You’d tag anything relevant to the Problem with that problem’s Tag, you index by Tags too, in a background job
Then when searching by Problem you get all entries Tagged as relevant.
M

In a slightly roundabout way, Links from Problem-SOAP Compositiions to Entries committed at other times is essentially the equivalent of tagging, and indeed the UI could easily be built to make it look exactly like tagging, by presenting a list of existing SOAP note problem names, and the ‘tag this under problem X’ action would create the relevant Link.

Literal tagging causes some issues in versioned, medico-legal EHRs, because you are updating the link target, not the logical link source, when there is nothing changing in the target.

it seems to me we should think a bit more about (?semi-)persistent SOAP Compositions, and maybe a related micro-service to make it easy to do logical tagging that actually does the correct linking…

  • thomas

Thanks for all the responses

I guess I see “problem” as a high level construct, decided by an expert clinician as a way of “coding” the client’s various ongoing, significant issues in a way that is relevant to management. It could be a formal diagnosis like Diabetes or a less structured problem like “smoker”. I am not sure how this could be coded in a consistent way - the definition of a problem can be quite subjective and in general it is the task of a sophisticated clinician. Short term issues like “Upper respiratory tract infection” or even “abscess” would not normally be defined as problems in my practice.

I agree with Marcus on the understanding - I have struggled with the whole concept of OpenEHR for a long time as a sophisticated clinician and perhaps somewhat less sophisticated IT enthusiast. I see it as a data modelling system accessible to clinicians to allow computable models - which in turn will allow decision support.

But I think the “problem” concept ids an important one

Perhaps we should relax a bit - allow the clinician to create problems at their discretion which are not necessarily connected to other elements of the record. This is effectively how it works now.

R

Great discussion.

I think there are semantic issues at play here as well – the POMR use of ‘problem’ vs the ‘ProblemßàDiagnosis continuum’ that is used as part of the conclusion to a consult etc. Problems are problematic! Add in Contsys and then we start to get into tricky territory.

In my discussions over the years, I think Ian’s view is closest to mine. And in a world where the reality of getting up-to-date Medication Lists or Problem lists of raw/real problems, diagnoses and procedures is not easy, the notion of the synthesised, coordinated, connected POMR Problems seems like a distant pipe dream.

The openEHR LINKs nicely allow for Marcus’ and Richard’s dreams of connecting items in the health record.

But imagine curating this for each of our patients with chronic disease – time and lack of funding will crush it in most clinical environments as they stand at the moment.

But let’s keep dreaming and planning. If we can put the building blocks in place, and there are many that are ready to go within openEHR now, with CDS, smart UI, AI etc maybe much of this could be automated, or at least collated presented to a clinician for verification.

Regards

Heather

Enjoying this thread but also finding it a challenge!

In my experience the load required to maintain a POMR is significant, as Heather points out, and thus it is often not done at all or done well and maybe Marcus’s suggestion of ‘tagging’ is simply a UI method for making it easier to do, but it does not really solve much more.

One of the problems here is that the medical profession has never agreed what it means by POMR in respect of EHRs and implementations vary significantly in different EHR systems, perhaps analogous the the diversity of clinical information models in silo-ed systems than the openEHR approach sorts.

Tagging could be helpful metaphor but I think the magic would lie in defining / agreeing what the LINK types were - ‘caused by’, ‘to investigate’, ‘prescribed for’??? Dunno - would need some work, but that would then allow people to view the data in more logical and useful ways.

Getting people to maintain all that is probably impossible, even with super UI, so probably we would need to find clever ways to automate it - but inevitably it will need some level of manual curation.

I maybe don’t quite understand yet the approach Thomas suggests for SOAP persistence. In my head SOAP is a way of structuring an encounter (not modelling a ‘problem’), and various other such encounter headings are present in other EHRs. Thus I think any encounter recorded in a SOAP structure may relate to a ‘problem’, but not actually be the definition of the problem itself. Although if an initial encounter record using SOAP or whatever was persisted and curated I can see how that may build a meaningful set of links, although still not sure we have the ‘Problem’ defined there?

Paul

Hi Paul,

Indeed confusing but that just reflects real-world complexity.

It is important not to mix up SOAP and POMR Problem lists , though both were Larry Weed’s invention. I used both in clinical practice.

SOAP is a way of organising information during a single consultation Subjective, Objective, Assessment, Plan.

POMR Problem Lists is a way of organising problems/diagnoses across multiple consultations or other patient contacts.

As part of SOAP style data-entry the Assessment part might well contain a Diagnosis/Problem entry which may (but may not) appear on the POMR Problem list. Ideally linked back to the original consultation. Problem Lists may be flat and have simple attributes like inactive/active major/minor but may have much more complex nesting to reflect condition grouping, process groupings, temporal groupings.

Some systems in the UK and Netherlands are entirely Problem driven i.e. for every new consultation the clinician must allocate it to an existing problem header or create a new one.

And in non-primary care settings it is common to see Contextual Problem lists - Care plans, Outpatient consults, Speciality Problem lists e.g Renal medicine.
https://www.archetextur.es/diagnosing-the-contextual-problem-list/?no-cache=1

Some stuff I wrote here https://openehr.atlassian.net/wiki/spaces/healthmod/pages/2949176/Problem+Issue+Diagnosis+and+Concern?focusedCommentId=2949237

and one of the best papers is http://www.differance-engine.net/chirad/healthrecords2007/The%20Problem%20Oriented%20Medical%20Record.doc

Ian

Lots of interesting thoughts and perspectives here!

In the NHS there is the added complexity that primary care and secondary care are different organisations, each maintaining their own patient records (with responsibility for maintaining accuracy), and even if it were possible for them to share the same problem list, it would be unclear who would be responsible for curating it.

I have been working on a project to try to scope out this area and produce guidance for improving problem and diagnosis recording. The project is led by the Professional Record Standards Body and the Royal College of Physicians Health Informatics Unit, and our report should be published in a couple of months (I can send the draft to anyone who is interested).

Personally I think that terminology (‘problem’ or ‘diagnosis’) can be confusing. In my understanding there is a concept of an evaluation which represents the clinical understanding of a fact about a patient (‘condition’, ‘diagnosis’, ‘sign’, ‘symptom’, ‘problem’). This is generally similar among all clinicians (although some may be interested in more detail than others), but can change over time either because the patient’s condition changes or the clinical understanding of the condition changes. This is distinct from the ‘problem attribute’ of an entry in a problem list, which is a statement of its importance to healthcare task planning (e.g. whether the problem is active or inactive, major or minor, high or low priority), and can legitimately vary between clinical specialties according to their particular focus.

The task for the EHR is to present the list of patient’s problems in a way that facilitates clinical decision making. This may be through the coded problem titles (e.g. diabetes is always important for every clinician to know about, a common cold is unimportant after X months), concurrent prescriptions (e.g. gastro-oesophageal reflux is considered active as long as the patient is prescribed antacid medication), explicit manually created problem links (e.g. shortness of breath is due to heart failure, amitryptiline was started because of pain), and explicit manual problem attributes (e.g. the GP has marked osteoarthritis as a major active problem).

Without any problem attributes the system should ideally be able to present a useful list by using problem attributes inherited from the code. However, creating the ‘problem profiles’ associated with diagnosis codes requires thought and broad consensus among clinicians, and is a major piece of work. But I think it is necessary in order to be able to reap the benefits of coding for clinical usability of systems. In parallel a change is needed in the way clinicians use problem lists, with a focus on trying to refine and improve the problem list with each consultation so that it becomes more precise and accurate over time.

Going forward we want to develop more thinking in this area through the Faculty of Clinical Informatics in the UK, and it would be good to hear from anyone who would like to get involved.

Thank you,

Anoop