Can a persistent list be considered the source of truth?

Clinical
1

I have always considered that the way of using a persistent list (for example, the problem list) is:

  1. First, an event composition is registered, with all its context information. For example, using the Encounter archetype.
  2. Then, a persistent list is created/updated, either automatically or curated manually, but using information copied from the original events.

We have been asked, as a proposal, to have first a a problem list as the source of truth. Any new problem will be included in that persistent list as the original record. And from it, we link to other additional information (encounter, etc.).

Is this approach conceptually correct? Does the scope of the Problem list archetype (or of any persistent list in general) cover this use case?

1 Like
2

The conceptual problem with this approach is that it obscures (or maybe even loses completely) the fact of recognising the problem at (usually) some encounter due to e.g. review of lab or other results, physical exam or similar. Consequently, a Dx of diabetes from 15 years ago would not be visible as such.

Secondly it sort of ignores the fact that over the patient’s life, numerous ‘problems’ will be noted, some of which will be entered on the active / master problem list - for some limited time, and then most will disappear off that list. Diagnoses for long term conditions will stay there.

My view at least (same as yours!) is that any managed list is a curated set of references to previously recorded information, and what it represents is some current care professional’s idea of what is under active management (including monitoring and review).

In a different kind of information model, it clearly would be possible to make the problem list the place where problems are initially recorded. To make it work, references to the original encounters / other activities where the problem was recognised would be needed, as well as the context data. The result over time will be a very large problem list for most patients, of which the top 3% are live problems, and the other 97% is dead stuff from the past.

This is not likely to be very convenient for various kinds of longitudinal querying, and any visualisation of diagnostic events in temporal context is going to be annoyingly difficult.

In summary, I would say: this is not the openEHR way of doing it.

2 Likes
3

That’s a great argument :smile:

1 Like
4

Hi David - beware, you are going ‘deep’ here!!

Your headline question ‘can a persistent list be considered the source of truth’ - absolutely. We have many persistent compositions in One London that we maintain as a source of truth.

However the ‘problem list’ is actually potentially the most difficult to do, not because of the technical challenges but because of governance, and the need for problem lists to be shaped to support very different users.

Over time, I have worked with / tried to build a variety of approaches, and there are definitely choices. some of which @thomas.beale has nicely described but I’m not sure we have ever really bottom-out ‘an openEHR approach’ mostly because there are very different use-cases and some hard realities of managing a ‘global problem list’ at scale. This is a good time to have these discussions as we move into much more strategic at-scale openEHR deployments.

For a time there was a very strong commitment to Problem oriented lists on GP systems in the UK but hit it actually proved very difficult to maintain clinical enthusiasm for keeping them well-maintained and curated, so they are now much less well supported in systems.

Before I try to give a more detailed response, first I have a couple of questions.

  1. Is the idea to maintain a full longitudinal problem list across all care settings.

  2. Who is actually going to curate/ maintain the list? This is probably the biggest challenge.

  3. Do you expect to also have ‘contextual problem lists’?

5

I would like to explain more of the mentioned use case and the questions that come to us in the process of trying to chose the correct way to model.
Is it correct to use the same archetype in two Templates in the same information system? In a Template with persistent composition spirit and in a Template event ?

I understand that it is one thing to use the same template more than once in different use cases, or in different information systems. But, if two or more Templates that make up a single clinical workstation and are related to each other, do we consider it to be ONE use case?

Let’s say we are modeling a Clinic Workstation. This station would cover the need for a primary care consultation. The healthcare professional has an assigned population group. She/he regularly visits his/her patients, gets to know them and manages their health problems throughout their lives. She/he jots down notes of his/her performances at each visit in a clinical course. Associated with this clinical course, the healthcare professional manages, medication, diagnosis record and makes requests if necessary.

In the process of structuring the information of this clinical workstation, it is divided into different projects that cover the modeling of each of these areas. This results in a project that models requests, another project models the diagnosis record and another the clinical course .

This generates, in principle, a Template for each of these functionalities or modules. A Template for the course, a Template for the requests, a Template for the list of the patient’s diagnoses throughout their life.

Many of the clinical courses are associated with one or more diagnoses .Requests also require a diagnosis (or a suspected diagnosis) to be processed and of course a medication must be associated with a diagnosis.

In the legacy system where we come from, (relational databases) a table with diagnoses is persisted, each with diagnosis_id. When a clinical course was carried out, that table was associated with its corresponding id, but the information was NOT saved in two tables at the same time.

But what about OpenEHR, which is a documental database? There may be inconsistency of information if in some way we persist the information twice in different places of the same information system ?

I’ll explain it in another way with an exemple:

Do we have to persist a Diagnosis alongside the clinical course and also in a Problem List (with the same problem/diagnosis arquetype in both)?

See model 1 of the scheme

Scheme_1_2
Scheme_1_2838×332 39.4 KB

For the way Instruction and action Archetypes are designed, makes me doubt of it. Those are solved with a reference to this diagnosis, without the problem diagnosis archetype, instead they use an element (text) Clinical indication. So it makes me think a better approach wolud be the model 2 of the scheme.

Wich is the correct approach to model this use case ? Any other options ?

Thank you in advance for your time. I hope someone faced this situation before and can bring solutions to the puzzle.

Postscript: We consider making a runtime aql to call a list of the registered diagnosis of patient, in order to select one to fullfill the clinical threat / clinical indication, but whe guess this will be too much requirement for the system.

6

Here we are talking of different scopes. There is a difference between modeling a problem and modeling a problem list, and that’s what I tried to ask in my original question. The fact of having a diagnosis could (should?) be documented per se, independently of being later incorporated to a summary list.

image
image1741×955 79.4 KB

This approach also provides much more flexibility, since you can build multiple list: a complete list of problems, a list for just open problems, lists for primary care/specialized care problems… And for each list we could use different templates for the problem/diagnosis.

There are well known problems about building those lists, including:

  • Is the information copied/duplicated of just referenced from the list to the original composition? More about this in How accurately do we model "copied" data?
  • Is the list manually maintained and curated or the result of an on-the-fly query?
  • Are the systems able to deal with those queries efficiently? Are we even able to express them?

Finally, having the problems originally recorded in the list might not be an error depending on the circumstances, but I think you will lose many contextual information.

7

Hi David,

Thanks for the detailed response.

The simple answer to your question is that there are choices in the scenario you have outlined. In a GP system we helped develop, we discussed the options is some detail. THe options range from

  1. Just record each diagnosis in each encounter and use querying to surface these. It is easy to manage but the big problem there is that you easily end up with duplicate or conflicting diagnoses as someone’s disease evolves.

  2. You try to manage a separate longitudinal problem list which is derived from these individual diagnoses but which is separately curated, and adds additional information like major/minor active/inactive . At this point you have to at least partially disconnect the problem list from the original diagnoses , as although they may have been correct at the time, they may no longer be an accurate reflection of the patients current problems (or may even have resolved).

  3. You try to mange not only a longitudinal list, but something that further groups related problems and other information by theme or date or both. That I suspect is closer to what you mean by ‘Clinical course’

As you go from 1->3 the data tree becomes increasingly complex, as does the human curation/management challenge.

For now can I clarify that this is to support primary care and a longitudinal record, and is not a ‘universal problem list’ for all clinical care across a region? In UK terms a typical GP/primary care record?

Can you also give an example of a ‘clinical course’? I probably understand what you mean but I’m aware that these definitions can be ‘slippery’ and often have some degree of different local meaning, often imposed by reporting/billing requirements.

As an example

Let’s say a patient has life-long asthma. They normally visit the practice nurse every 12 months for a routine check but recently sees their GP weekly for 3 weeks because of a flare-up which requires steroid medication. 2 weeks later, they see the GP for an unrelated skin infection (a single visit)

Which of these is a ‘clinical course’? How does the overall ‘Asthma course’ relate to the flare-up? Is every encounter allocated to a’clinical course’ even if it is a one-off visit.

The other thing you might want to consider, is is to use openEHR Folders as a way of managing the grouping of ‘course’/ episodic’ information.

The core issue is that the ‘diagnosis’ has 4 different masters

  1. To record faithfully the original clinical diagnosis made during a single encounter, which may actually only be a suspected diagnosis
  2. To tie that into some idea of a ‘care episode’ where the actual diagnosis may morph as more information is obtained
  3. To label referrals / prescriptions with some kind of reason for referral, clinical indication (again where that has to reflect what was known ‘at the time’, not what is known over time.
  4. Somehow to fit al of that of that into a master longitudinal problem list, where the length and complexity means that it has to curated to remove or at least re-order trivial problems or inactive problems

Now all of this can be done with compositions, folders and linkages but it does get more and more challenging technically (re-allocating references) and clinically.

So here’s my starter suggestion…

  1. I would keep the original diagnosis in it’s original encounter
  2. I would be comfortable with recording the referral reason as a coded term. You might want to add a link back to the original diagnosis but this can be brittle and I’m not sure it adds huge value
  3. I would maintain a separate longitudinal problem list with a set of problem diagnosis archetypes that act as the problem thread headers. You need this to allow those headers to change active<>inactive state and for them to be ordered or other meta-information to be added.
  4. You could then link individual diagnoses in under that problem thread header
  5. I think I would try to mange ‘clinical course’ with folders but perhaps ‘insist’ that each course is associated with one or more of the longitudinal problem headers (or a new
    header).

However it would be really helpful to understand how you are using ‘clinical course’ and indeed how well that is actually working right now.

A lot of these ideas have been tried and largely disappeared in UK general practice systems, really because of the maintenance burden.

2 Likes
8

I agree, because a useful summary list need to be curated, it is not just a direct copy of what was originally recorded as a problem in the encounter . It has state active/inactive, it may have start and end dates and it may go from major to minor or vice versa.

So one idea that is perhaps worth adding , and which is covered in Contsys and is also in FHIr Condition, is the idea of a ‘problem thread’ - each problem has its own header (which is basically the problem/diagnosis archetype but with a different ‘longitudinal’ flavour beneath which can be nested actual diagnosis references or clinical epsisodes.

So the ‘header’ problem is definitely copied because this cannot be tightly coupled to the original encounter problem.

However it might reference one or more original encounter problems (or lose those references over time).

Technically it is cleaner for these to be links but there is case for caching local copies for querying/performance reasons but nominally these should be a reference cache not separately managed copies

I think we are very aligned @damoca but I think that top-level longitudinal problem has to be separate entity from the encounter problem that initiated it.

I’m trying to dig it some work I do on this a few years ago. We also revisited it in a UK FHIR core context some years ago and agreed that the 'problem header; needed to be distinct from it’s original encounter diagnosis.

On queries - we can’t traverse links in AQL right now, which is one reason for having that local cache. That does not stop us querying , it just makes it less elegant and will require a two step query.

1 Like
9

This is work I did looking at how the Contsys Health Thread / Issue ideas might work in openEHR

image
image1037×501 51.3 KB

image
image1488×3718 496 KB

I’m really not sure if we need new Health Thread/ Hrealth Issuearchetype or whether the existing problem-diagnosis archetype could be extended slightly (more in line with the FHIR Condition approach)

10

Definitely, we cannot forget about Contsys during the modeling processes, at least to talk in the same terms.

1 Like
11

I haven’t looked at the latest version, but in previous versions the CONTSYS concepts were not really archetypable. More abstract concepts than data models.

However we have done some work on a Health thread archetype - see this thread for the discussion late last year.

3 Likes
12

As you know Heather , we share similar views on Contsys and direct implementability but it does introduce some clarity in places and I think the idea of Health Threads/ issues has some merit and at worst it does hep untangle some of the muddle.

That thread is interesting - we are definitely on much the same page. The main message is that you cannot manage a sophisticated problem list by just querying existing diagnoses or referencing original diagnoses in their encounters.

1 Like
13

Do ‘requests’ here mean orders, i.e. prescriptions and so on? Do we understand ‘clinical course’ as a care plan of some kind? Or are we talking about just documenting the course of illness - clinical summaries of some kind?

This is what @damoca and I were getting at in the earlier posts. Diagnoses (or other notes of ‘problems’ or ‘issues’) would be recorded once, as part of encounters when they were arrived at. Then a problem list is a list of references to some of those diagnoses / problems.

That is easy enough to achieve in openEHR. However, once information starts being copied around and local changes are made on copies, things get more interesting. What has to be solved:

  • references need to still be resolvable; if a problem list was copied but the things it references (those earlier diagnoses etc) are not, then the problem list won’t be displayable. This is a standard problem, not specific to openEHR. It means that if EHR items containing references are copied anywhere, the reference targets should potentially be copied.
  • how the problem list is being updated. If the local HCP at the clinical workstation is the ‘manager’ of the local patient records, then he/she should be the manager at all times. But what if someone in a hospital wants to update the problem list? They really shouldn’t, only the local clinic person should do that, based on what they see in discharge summaries.

In the ideal, there is no ‘copying’, only access to single-source-of-truth data. That solves both reference resolution and single access to managed lists like the problem list.

Right - in the evolution of the management of the problem, it turns out that the original ‘diagnosis’ isn’t that relevant, or even wrong - but the problem hasn’t gone away.

I think this argues for a separate description of each ‘problem’ within the Problem list, and within that, 0 to many refs to prior diagnoses (or other notes). I.e it just means that an entry in the problem list isn’t a bare reference to a prior diagnosis, but a little description of the problem, and within that, references to prior info.

This seems a conceptually correct way to understand the problem list and to model it. Is it far from how you are already doing it @ian.mcnicoll ?

This sounds about right.

No, that’s bad! They are designing a nice new shiny system, they should do it properly :wink:

14

@ian.mcnicoll That thread is very much based on our joint discussions over the years

2 Likes
15

This is to support primary care and longitudinal record. A GP/primary care record.

In practice, one single GP visit (the same day and time) can have different reasons for consultation. So lets imagine, the same day the GP has to manage the steroid medication for asthma, and the unrelated skin infection.

One visit, two different reasons of consultation (so two different diagnosis associated each one to its own agglutinating free text). TWO CLINICAL COURSES

Each visit related to Asthma with GP gathers new information and is reflected in the clinical course of asthma, no matter if its a routine control or a flare up (spontaneous non programed visit with GP). The GP does not change the (Chronic) diagnosis (or the attributes to say it properly).

That would be the first encounter (Clinical Course_1).

When the first issue has the orientation and plan fixed, within the same visit, the second issue is addressed.

So the skin infection would be the second encounter (Clinical Course_2).

You could see it in another way. One visit one clinical course. There is no clear line that defines the limit of the clinical course. One could consider its the whole visit (and it won’t be incorrect). But first approach mentioned allows Health professionals to filter the follow up for the diagnosis associated, and so to see the evolution clearly. This sort of semi structured information is already present in the legacy system, and we think it’s worth saving this feature.

1 Like
16

Thaks DAvid,

Very helpful indeed.

How do you mange a ‘new diagnosis’ in the context of an existing longitudinal problem e.g. a foot infection related to Diabetes, and does the longitudinal problem carry any other attributes e.g. active/inactive , start / end date, major/minor.

A screenshot of the existing app page might be helpful.

Sorry if we seem to be asking os many questions but from experience this is quite tricky to find the optimal approach, especially of we want to try to make it somewhat generic!

17

The Clinical course would be close to a problem oriented clinical note taken by a GP during a visit to handle current health threats. These visits occur alongside the life of a subject of care.

A free text, not structured, that gives context to the structured information gathered during the visit of a GP. It serves as a reminder (for the future) of the evolution and latest actions carried out, whether it is the same health professional, or a different professional or specialist who takes over and thus maintains the continuum of care.

Another way to explain it.

I think it would be close to a progress note (or perhaps a clinical synopsis) if you put all the text together.

I think it would be close to a SOAP if you Semi structure the information collected.

However, correct me if in this last statement, those arquetypes(not and semi structured) are not equivalent at all. Also correct me if there is a better arquetype to define a single free text for that concept, or if it would be better to create a new arquetype, free text, just to handle this with its own semantic rather than pushing the use of an existing one.

18

The way it is managed in the legacy System: The GP registers a new diagnosis (foot infection or diabetic foot). The GP write the note associated to this NEW clinical problem.
NO CHANGE is applied to the longitudinal problem (Diabetes).
There is no such thing like relation between problems, but: The GP can mark more than one diagnosis associated to a clinical note. This way, you can retrieve the notes taken, with a diagnosis filter. So the information gathered in the infection foot process, would also be available on the Diabetes longitudinal problem (as long as the GP mark both diagnosis).
Of course, if on the job of building this new system, we can manage to offer a new feature that enables to link related problems that would be awesome .
By the way, I am glad to answer all the questions you need. In the end it is all about being sure we are correctly aligned in the understanding of the use case. Furthermore, it demonstrates your interest in helping by sharing experience and know how. I am very grateful.