for HiGHmed, we explore the use of the newly introduced other_details field to represent above mentioned concepts. We aim to concurrently allow the mapping to corresponding FHIR resources. For me this appears to be a natural fit, as the care episodes and encounters have a hierarchical relationship and encounters on hospital level can be nested with clinic encounters (I refer to encounter as defined by FHIR: https://www.hl7.org/fhir/encounter.html). Furthermore, this is a nice way to link versioned objects to encounters and episodes.
So far, so good. However, I find the following challenge(s):
-these concepts are typical admin entries. Folders only allow item_structures, i.e. clusters. I have found several situations where the entry types are making re-use quite difficult. Do you have any ideas for the future, how this can be solved more elegantly? For now, I can simply copy all elments from the admin entry into the cluster.
-As an alternative: might it make sense to add another field to the folders with an optional reference to a composition containing the admin entry? This might be a cleaner solution as we could keep everything inside the admin archetypes, we can use the known mechanisms for querying etc.
-As DIRECTORIES can be archetyped: would it be even better if we could define this extra reference in an archetype/template that defines contraints on the DIRECTORY structure? Only problem is that nobody has this implemented.
Would be great to get some feedback.
Birger
Edit: sorry for not making the title of this post more technically abstract. I may change this one after getting a bit more clarity on this topic.
Copying the Admin Entry data into the Folder meta-data doesn’t make sense to me… it hides that data from querying that would normally find it.
It seems to me that the natural thing would just be to establish a pattern whereby Folders used to represent episodes of care always have a ref to the Composition containing the Admin Entry representing the admission. Also for the Composition containing the Entry for the discharge. Folders can already point to any number of Compositions, so I don’t see the need for another special reference.
But if you want easier to find references to those two Compositions, i.e. the admission and discharge ones delineating the episode, you could include something in the Folder.other_details, e.g. Elements whose values are uid refs for those Compositions.
We use mapping to episode (admission, outpatient) and period of care all the time in our system. Since the patient administrative system is legacy and doesn’t handle versioning the optimal way we had to introduce tags on data. As such we have tags like:
Period of care
Episode of care
Folder (a legacy folder structure)
My idea was to model these existing and external entities as folders in openehr.
I think this is similar to creating a cluster archetype to describe the item_struct inside other_details in RM 1.0.4. Also I’m not sure how I would get additional attributes directly in the folder.
In general, I think the community needs to provide a standardized approach to solve this issue. I will try Thomas’ suggestion but I’m not sure yet about the consequences for handling possible scenarios as a developer.
The purpose of adding other_details to folder was to support archetyped data of a folder, including directory. Folder were/are used as tagging mechanism or as categorizing compositions inside EHR, so the added other_details it just gives you more options for context info associated with that tag/category.
In practice we could use that to assign some of episode related information to folder (so that we can ease searching, filtering, etc), but … a folder is not (necessary) an Episode. It just helps you as developer to build functionality, to categorize data, etc. At least that is my vision and my experience working with episodes and folders. You might still need an (ADMIN_)ENTRY composition to record all data that you might want to map from FHIR resources.
There were discussions in SEC around supporting even more entry-like data in the folder, transforming it into something even more closer to an episode-concept, holding clinical-information, etc - but we decided to keep it ‘simple’ at this time, in line with initial purpose of tagging EHR content.
that’s interesting, because we already use this feature in EHRbase which is based on Archie that implements 1.0.4
I think the PR you referenced has been resolved by [SPECRM-56] - openEHR JIRA which has been introduced in 1.0.3
Anyway, in my opinion Folders are not only about tagging but about hierarchical relationships of data collections + metadata. Otherwise, there would be no need for tagging that we agreed to put on the roadmap for the REST API.
There were discussions in SEC around supporting even more entry-like data in the folder, transforming it into something even more closer to an episode-concept, holding clinical-information, etc - but we decided to keep it ‘simple’ at this time, in line with initial purpose of tagging EHR content.
This is ok for me as Thomas’ suggestion seems to be a sensible approach. Not sure yet about handling this in practice (what if I need to filter depending on a folder that is higher in the hierarchy. Should be doable but how much effort does it take…) but we will figure out.
For me it’s a bit more important to get a standard patternd for episodes and encounters. Otherwise, we will not be interoperable between platform implementation.
Small note on how Jira CRs work: ‘Affects versions’ means what versions is this problem issue present in; ‘Fix version’ means what version (=release) will this problem be fixed in.
@thomas.beale I think it is even worse. When I remember correctly we directly asked you to change this in the offical BMM files for 1.0.4. and you happily agreed
Hm, you’ve got me there. That’s an error, appears being due to me regenerating the UML with a new generator, not realising that a post 1.0.4 change was in there. We’ll have to take that out.
I’m not sure that it matters too much in an implementation though, it just means you are ahead of the release by a month or two.
Indeed - not your fault at all. I’m currently building a new version of the publishing environment on an old laptop renovated with Linux Mint, so hopefully will avoid such errors in the future.
