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
On 27/06/2019 13:36, Marcus Baw wrote:
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
On Thu, 27 Jun 2019 at 07:40, GF <gf...@luna.nl
<mailto:gf...@luna.nl>> wrote:
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
gf...@luna.nl <mailto:gf...@luna.nl>
Kattensingel 20
2801 CA Gouda
the Netherlands
On 26 Jun 2019, at 22:30, Thomas Beale <thomas.be...@openehr.org
<mailto:thomas.be...@openehr.org>> wrote:
On 26/06/2019 11:07, Thomas Beale wrote:
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 diabete
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/>
Management Board, Specifications Program Lead, openEHR Foundation
<http://www.openehr.org/>
Health IT blog <http://wolandscat.net/> | Culture blog
<http://wolandsothercat.net/> | The Objective Stance
<https://theobjectivestance.net/>
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
<mailto:openEHR-clinical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
<mailto:openEHR-clinical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation
<http://www.openehr.org>
Health IT blog <http://wolandscat.net/> | Culture blog
<http://wolandsothercat.net/> | The Objective Stance
<https://theobjectivestance.net/>
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
