Duplicating data for reports, or some smarter solution?

Clinical
1

Reposting my post in Specifications (Safety features in AQL: subject):

When it comes to data that are exclusively registered for reporting (research, financial, sick leave formulas to authorities dealing with sickness benefit, etc) purposes, we’ve for now abandoned the report flag on compositions, and instead making , ugly, local archetypes to be used to duplicate data born in “real” archetypes made for primary documentation. Example: Diagnose in “Sick leave formulas” is not always the correct diagnose in the EHR, hence polluting the patients diagnose history.

If we could avoid making this duplicate, “monster-archetypes” and instead rely on an attribute in the RM indicating this particular information is a duplicate or for a reporting purpose only … Is this possible?

2

IMO archetypes are not the right metamodel to express report data. A higher level model is needed for that, since for a report for not only need data, but the queries, rules, aggregations and indicator definitions, that goes beyond what archetypes are for, but archetypes and templates are a required layer for a reporting model layer.

1 Like
3

@varntzen - I still not sure I wholly understand your issue here - can you perhaps post a little for - examples of ugly archetypes, or just expand this a little?

Example: Diagnose in “Sick leave formulas” is not always the correct diagnose in the EHR, hence polluting the patients diagnose history.

If I am right you are saying that in the context of a ‘sick leave document’ the problem/diagnosis archetype might be a good candiate for ‘Diagnosis’ i.e the reason for the sick leave but you do not want to get this mixed up with ‘proper’ diagnoses.

If so I agree. This is going to be a growing issue as the scope and coverage of what is in the EHR grows. There are other more subtle examples.

I do think the ‘probem/diagnosis list’ issue is so potentially messy with very many contextual usages, that in any large-scale system , we will have to maintain a single master problem list which is tightly governed. And not all ‘diagnoses’ belong in the problem-diagnosis archety[e. The sick not example is one where I might well simply hardwire that as an ‘Reason for leave’ element in a custom sick-leave archetype. It all comes down to data-sharing potential. We have similar use case in Medication order where there is a clinical Indication element.

And in case anyone thinks this openEHR stuff is hard, this is a generic clinical informatics issue. It is simply brought more to litght since we are working more in theopen and have access to the whole data tree - with power comes responsibility!!

4

Well there’s a question of ‘report data’ and a question of report definition, behaviour etc. For the data part, there are some basic needs we have discussed in workshops a few times, that I summarised here - Reports support in RM

This gives support for representing the data that gets created in the act of ‘writing a report’, that typically references other content and query results.

Reporting in its more general form of data extraction, aggregation and presentation is a different thing. My impression is that @varntzen is talking about the first.

5

Sorry for late response here. Days are too short!

With “ugly” and “monster-archetypes” I mean separate archetypes made for one purpose only, even though the data points are clinically valid and stored in their correct archetypes. One report form = One archetype and (at least some of the) data is duplicated.

For example the “Sick leave note”, which is a big form - approx. 100 elements - and consists of a variety of information: Date the individual got sick, the ability to work, reason for the leave, is it related to pregnancy? or injury? if the individual can work some hours - at what percentage?, … and it goes on and on. But two elements are interesting: Diagnose (-s) and Employeer. Those are in published archetypes. If we use those “proper” archetypes, say the Diagnose/Problem, it is not always the medical “truth” - and will in queries and in display not be correct.

Other example: A report to a quality registry of a particular diagnose or group of diagnoses, which can be a mix of observations during a hospital stay, some aggregated data, and also subsets of data, or even “the most relevant value from a number of registred values”. If this is to be made in a query, which data points to pick? Even though the specification from the registry is clear enough, it’s still needed for a clinician to evaluate and make decisions. “Which of the 15 systolic BP’s measured is the one representing the BP during the stay?”. It may be an average, but that is not a measured value at the time of recording, it’s just in the BP archetype for reporting. By storing the data in the clinically correct archetypes, we intoduce erronous data, as the data entries for this reporting purpose is a duplicate, or even “made up”.

And as the form for this reporting ideally should “grow” during the stay, it will be populated by a number of clinicians, at several times: “Radiology showed this and this finding, a lab result showing this value, then decision to do surgery date, the procedure, <which of theese 4 medications were given>, then complications (if any), outcome, and so on <50 - 100 data points>”. If this is to be stored in their “proper” clinical archetypes , how do we show the previously recorded values from a user earlier in the stay, to the next clinician to register his/hers data points?

6

Data is enteredand reused in different ways. The precision and quality of data will differ. Sometimes the data entered is the primary source (the real data capture and first time presented to the EHR/CDR). Often the data entered is secondary usage, and there might be need to change the precision of the data for this secondary usage.

Put another way; the clinical concept is almost the same but not identical.

Another problem we face is the idea that clinical data already is well defined and we assume there is existing workflows to capture data the right way. This is seldom true. Most of the time we experience that the introduction of a moderately simple form to a clinical registry either local or national opens the door to clinical modelling perfectionism.

Based on these experiences we’ve found that the best approach is to use archetype modelling to describe the model as specific as possible. Working this way we see openehr at its best. Providing a great reference model, an archetype modelling language and well defined terminology bindings. This makes it possible to build solutions today which are open for future extensions.

I don’t like words like “monster” or “ugly” for this kind of modeling. This is actually beautiful archetypes showing the best of openehr, and they opens the doors into more advanced workflows combining good quality data with automatic reporting.

1 Like