Crikey @Leuschner!! That’s a serious bit of summarisation., thanks.
In practical terms, here’s how I would start the ‘perfect’ POMR implementation, at least of a GP system.
-
THe app would be wholly POMR-driven .i.e. every encounter, or part of an Encounter has to start with assigning the record to an existing problem or creating a new one. In the UK , most of the GP systems at one time offered quite sophisticated POMR. The ones that worked (ie POMR well-maintained) were POMR-driven, not POMR as secondary exercise. You can decide what you like the fact that the best POMR app is no longer in business!!
-
The problem/diagnosis archetype is a good basis for virtually all problem list records. I would expect that original problem-diagnosis to be captured ‘in-context’ - that would normally mean in a GP encounter composition,i.e not normally entered directly into a POMR composition directly, though there might be some exceptions for ‘Contextual Problem lists’ (later!!).
-
There is a completely separate Problem List composition which manages the list itself, linking out to the original Problem-diagnosis records i.e it does not carry any problem-diagnosis archetypes it self, just points to their original locations. It also manages the status (active, inactive etc) , the start and stop dates, nesting and meaning of linkages. This will need some kind of Problem Thread header and Issue header archetypes or RM component.
was my effort at picking up some of the ideas from Contsys-2.
The main openEHR challenge in here is in managing the linkages and querying across them. It is certainly do-able but it would be nice to work out a more generic RM and/or archetype and associated AQL that made this a little easier. Thomas and I spent a day head-bashing this last year.
I’d strongly re-iterate my suggestion to look at Contsys-2 in this area. Although I don’t agree with all of the ideas in there, I think it does give us some useful new vocabulary to talk about the information structures and relationships without getting tangled in pre-existing ideas and terms.
https://github.com/openehr-clinical/shn-contsys (I will fix the formatting!!)
One of the key ideas that Contsys-2 gets right is that although there is clearly a place for a single longitudinal Problem list (best, I think co-curated by patient and GP) , Problem list type structures appear in Care plans, referral documents, discharge documents, End of life treatment plans etc, etc. Contsys-2 acknowledges that. @johnmeredith (I am a co-author) was due to present a paper at MIE that talks about the ‘contextual problem list’, arguing that the typical Key Condition, Co-morbidities, Complications, Other Problems format is just another kind of Problem list, just with an arrangement of key problem information to fit a particular condition or presentation.
Your example of ‘diabetes’ as a co-morbidity in a surgical admission record is the perfect example. A good surgical record will have constructed a contextual problem list that best prioritises and organises (hinding many immediately unimportant issues) that gives the surgical team the best possible snapshot of ‘things they need to know about’ in terms of their immediate responsibility. It may not function as a true WEED POMR in terms of active/inactive etc but fulfils the same purpose - organise/re-organise potentially very complex and voluminous ‘problems’ into a useful order and level of visibility.