Template-based validation on other_details

Hi everybody,

for EHRbase, we would like to support validation of other_details like in Folders or EHR_STATUS. I was wondering if there are any existing approaches used by any vendor/project and what is the experience so far. We will need to make some decisions (attaching the template, likely based on a cluster) to a single EHR, all EHRs and the CDR also needs to know on which context (is other_details part of a feeder_audit, EHR_STATUS, a particular FOLDER or all folders…).

Would be great to get some opinions. It’s not something we will do immediately but personally, this is something that I missed several times in practice.

I did use other_details to hold some ‘anonymised demographics info like Yer of birth and gender to speed up population queries, basically cghunks of canonical openEHR JSON objects - nicely queryable but no validation- I know don’ hate me for it.

so yes a way of validating that against an ‘EHR template’ might be useful ( for something else evidently - not for my stupid example).

FOLDER.other_details is part of upcoming release 1.1, so I don’t have yet any example, but our plan was to use it to capture episode details (which we now do in an admin entry composition).
As for the EHR_STATUS.other_details we use it to store merge info about EHRs. For this we created an archetype/template, and the other_details data looks like: https://pastebin.com/5wFaEMTy

But do you also have a functionality how you handle the validation based on the template? Would be great if we could talk about the episode details. I’m currently working on an archetype that is closely aligned with the FHIR resource and it would be great if we could define a standard pattern for this!

No I don’t really have that - merging is backed and performed by the backend, no end-user interaction is done on the data of that attribute. Basic validation is done based on XSD and RM, hmm … and under certain circumstances via a (proprietary) json-schema based on the archetype/template. As you might remember, we don’t use ADL2/BMM or other java solutions.

About FOLDER/episode sure, I’m also interested in your plans/approach on EHRbase, and also in relation with FHIR. In Netherlands we use https://simplifier.net/NictizSTU3-Zib2017/nl-core-episodeofcare referenced by many of the ZIBs at https://zibs.nl/wiki/HCIM_Release_2019(EN). The admin-entry composition we store at this time: id, title, status, start/end-date, comments and feeder_audit.