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.
1 Like
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).
1 Like
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
1 Like
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!
1 Like
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.
1 Like
Hi Birger, I am not entirely sure what you are asking, but what we have done is the same as validating compositions given that our API used the same commit(Version) operation for EHR_STATUS, FOLDER and COMPOSITION.
If a template ID is specified in the archetype_details then this OPT is used to validate the object.
Hope this helps.
1 Like
Hi Heath,
I think this specifically about RM data structures that are outside the COMPOSITION and therefore not supported by current templates. e.g. (for good or bad) I have used Cluster-based objects to carry some anonymised demographics in EHR_STATIS.other_details. The data is structurally valid and based on some real archetypes but there is no way to properly validate that against any template, right now.
1 Like
Thanks Ian,
that’s a perfect example for our requirement. Additionally, I think it is not clear how to further constrain the use of RM fields outside the COMPOSITION. For example, I would like to only allow data to be put into the other details of EHR_STATUS that complies to a certain template. However, we need to make sure that the system can handle different Templates/Archetypes for different RM fields (the other details in the feeder audit will look differently compared to the one used in the EHR_STATUS).
Hope this clarifies it.
1 Like