Representation of Episodes of Care and Encounters in folders

Hi everybody,

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: 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.


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.


Hi Thomas,

thanks, your suggestion sounds very reasonable! I will try this and report back later.


Which ENTRY archetypes were you thinking of using?

1 Like

Another approach
What if the FOLDER was the episode?

Then you would model all attributes needed into the FOLDER archetype.

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 started to work on Archetypes that are aligned with FHIR EpisodeOfCare and Encounter Resources.

Hi Bjorn,

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.



First of all the ‘other_details’ is part of RM 1.1 release, not 1.0.4. See amendment record in, and
Tooling might not support yet modelling that other_details of the folder/directory, but is not impossible (you could still manually adl for that).

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.

Hi Sebastian,

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 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.

So in this case, SPECRM-56 was reported as being present on 1.0.3, and will be fixed in the (forthcoming) 1.1.0.

Agree, we certainly need this.

Thanks for clarification! Then (un)luckily we might have made a mistake as this change is already implemented in Archie under 1.0.4:


@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 :wink:

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.

Sorry about that, we acted in good faith.

1 Like

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.