Hi,
After some research with the current specifications, I would like to ask about the clinical use and the supported use by the apps with the “report” category in Compositions. It seems to be added in the OpenEHR Terminology but is missing in the EHR Information Model literature and in the Archetype Designer too.
Is anyone using it?
Hi Pau,
This was originally a request from @bna. As I understand it, the idea is to mark a composition as being wholly derived from data in other compositions, so tat it can be excluded from routine querying e.g. a Discharge summary where all of the data will originally have been recorded in the CDR, so we do not want to pick that up in a query for ‘All diagnoses’, or it will duplicate information in the original problem list and what is essentially a copy in the discharge composition.
Thats right. We use this in our system. Latest implementation was a solution for prostate cancer which started in production 28th of September. Use-case is reporting to national cancer registry. Data is reused from our patient note and MDT summary. The composition with report data is marked as report since no new information is added.
Just out of curiosity. Do you copy and persist the data (entries) inside those Compositions or are they just a collection of links to the original entries?
I guess the first option would be needed if the report if going to be sent out of the organization. The second option would be more space-efficient if the report is being used just internally.
I’m very keen to know more about your solution for prostate biopsies, @bna. A system for reporting prostate biopsies by pathologists for local use and allowing direct reporting to the registry was implemented in Skåne, Sweden more than a year ago. Now a pilot testing the system’s full capability, which is combining data from radiologist, urologist and pathologist in one report, is reaching its completion. But that is not an openEHR system, so insight into your solution would be very valuable.
I understand the need to identify data to be excluded from routine querying as part of EHR design/architecture, but I don’t understand why a ‘report’ tag is added to a value set comprising temporal-related COMPOSITION categories ie events (snapshot/point in time), episodic (‘shortish’ interval of time) and persistent (‘longish’/forever interval of time).
Are you suggesting the ‘Transfer of care summary’ COMPOSITION, currently described as an ‘event’ or snapshot, be recategorised as a ‘report’? It’s even more confusing when we have a family of explicitly modelled ‘Report’ COMPOSITIONs.
This example is a report, which is another ‘snapshot’ at a specific point in time ( or event category’).
If the designation of a COMPOSITION as derived from one or more original sources is needed, that’s fine, but isn’t it another completely separate attribute related to querying rather than temporal categories? And when you name it please avoid confusion by avoiding overlap with existing or anticipated archetype names.
Regards
Heather
This is an interesting topic covering different challenges in eHealth.
The first challenge is to define the primary source for a piece of information from all the derivates. Traditional (non-structured) notes contains lots of duplicate information. This is understandable and useful since the latest note will contain an up-to-date summary. The problem for structured data is that data will be copied and when querying it can be harder to identify the primary source.
The second is the reporting domain. Reporting in this context covers all use-cases when a health care provider is transferring health data to the next party in the patient trajectory. Here you need to transfer data already present in the EHR and you might add some information to present the context for the data. Often the report need to be stored in the EHR for versioning and for juridical reasons.
The third challenge is to handle data with different temporal contexts. In an discharge summary you might combine the persistent social summary with event based data like the latest body temperature. And if the data should be collected and stored as a whole we need a way to define a data set which contains duplicates from the primary source.
I mentioned the prostata cancer use-case above. Here we have three compositions with primary data:
Then there is a requirement to send data to the national cancer registry. Here we use a separate template/composition. We reuse data from the outpatient note and the MDT note by AQL. The clinician will look at the total dataset and make sure it is correct. Then the doctor will approve the data which is transferred as an openEHR Composition to the registry. Since the data is duplicates from other sources we use the REPORT category on this template/composition.
I think there are lots of details in such an use-case. It might be good to have a talk about it. Maybe we should set up a webinar to present our solution and discuss the modelling approaches and solution?
Hi
We make a copy of the data. The data is “signed”/approved as as whole and it is possible to make changes on the data if needed.
This is a pragmatic approach which works fine for some use-cases.
We have been discussing if we need to/should store the reference to the primary source. This could be solved using the RM and then make it possible to detect possible changes in the primary sources.
Our experience is that clinical data is a bit dirty. It’s not like an mathematical equation where everything can be calculated. So we need to balance the ideal technical solution with something that is manageable for both end users and software developers 