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
On Thu, 27 Jun 2019 at 19:32, Gunnar Klein <[email protected]> wrote: > 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 <[email protected]> skrev: > >> 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 <[email protected]> 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 >>> [email protected] >>> >>> Kattensingel 20 >>> 2801 CA Gouda >>> the Netherlands >>> >>> On 26 Jun 2019, at 22:30, Thomas Beale <[email protected]> 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 >>> [email protected] >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >>> >>> >>> _______________________________________________ >>> openEHR-clinical mailing list >>> [email protected] >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >>> >> >> _______________________________________________ >> openEHR-clinical mailing >> [email protected]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 >> [email protected] >> >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> > _______________________________________________ > openEHR-clinical mailing list > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >
_______________________________________________ openEHR-clinical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
