This only works if the archetype details are removed. My understanding is that they are mandatory, although in fact the archetype described is not actually ‘real’. It is not defined in any way in either CDR.
We might change EHRbase in a way that makes it more aligned with Better’s implementation. Personally, I think the archetype_node_id is mere noise and not really helpful here
I agree but I think EHR_STATUS inherits from LOCATABLE so it may be mandatory in RM terms. We could agree that the CDR handles that aspect, of course!!
and there is perhaps a case for formalising how we handle non-Composition archetyping as there are cases where other_details carries archetyped info.
IMO what we are really missing here is the opportunity to spec what should be an EHR_STATUS archetype and tolling support for such archetypes. The EHR_STATUS should be archetyped, even though there is only one archetypable structure there.
Short solution would be doing what Better does, good solution would be spec + tooling support.
I agree but just as important than tooling is some way to ‘register’ these archetypes with the CDR. It is the other_details aspect that does lend itself to being archetyped.
This is actually on the roadmap for us (because it bugs me on many occasions) but not sure yet how this would be designed. I think @sebastian.iancu mentioned that they do this already in their implementation. Would be great to learn what works (best).
We would really need something like an EHR_STATUS template, I think, so that we could add other archetype into other_details. That could be uploaded to the CDR like any other template??
Exactly, in fact the ehr_status can be updated through a contribution, and everything updated that way should have archetypes and templates. Including folders, but that’s another discussion
Some limitations and workarounds I implemented in the EHRServer on the status and folder are because archetypes are not clear for those classes.
I’m strongly against making exceptions or workarounds or relaxing things in rest api specs - let’s keep specs consistent and predictable. So we should keep name and archetype_node_id mandatory, those are not really noise.
If you need some artifacts, here I’ve upload some close to what we use in our production: EHR_STATUS a locatable?
I agree with Sebastian, I think we need to keep the canonical format inline with the RM. Simple formats and SDK can take shortcuts where they see fit to make implementations more efficient.
The EHR_STATUS template is implementation dependent, so what we need is the ARCHETYPE and a sample template.
The EHR_STATUS archetype used by Ocean is very similar to Sebastian’s except it includes the other_details ITEM_TREE as part of the archetype and has an items SLOT. openEHR-EHR-EHR_STATUS.default.v1.adl (1.2 KB)
The benefit of this approach is that you can include multiple ITEM and CLUSTER archetypes in the template, not just a single ITEM_TREE, providing a lot more flexibility with the data you have in the EHR_STATUS.
Sebastian has a merge use case in his templates, some include demographics, the Ocean EHR_STATUS template has a VIP status, I can think of other research cohort data that may need to be included. ehr_status.opt (7.7 KB)
To enable this same flexibility to support multiple other_details use cases with an ITEM_TREE slot requires you to have another ITEM_TREE archetype with just an items ITEM slot, which seems cumbersome to me.
thanks @heath.frankel I think you are right - I did not payed too much attention to that part, and it is also true that we use that part at this time only for merge-info. The VIP info we store it on PARTY, as well as all associated patient IDs.
Thanks Heath - your use-case is what I had in mind. Are there any other places in the RM where we might need this sort of non-composition based templating and how do we design the service that would allow us to register these against a particular CDR? I can see that uploading the template would be simple enough but how do you associate it with the correct part of the CDR data tree?
@ian.mcnicoll, I think we need to be looking at supporting EHR_ACCESS templates. This obviously needs some archetypes, including an EHR_SETTINGS structure, which has not been defined in the RM. Ocean implemented a subtype of EHR_SETTINGS with archetype structures that supported various access control use cases including allow/deny PERSON, ORGANISATION, ROLE, AGENT and specifying compositions that are public and private that override a default access policy. It would be good to provide a draft specification and implementation guidance before too many implementers invent their own solutions.
Others have suggested Folders should have templates, which is not something I have had much experience with.
I don’t see ourselves (Better) supporting archetyping of EHR_STATUS anytime soon, but I will take a note to at least ignore the two fields so that we at least accept what the specification demands.
I agree in which we need to look for support in specs and tooling, also on ITS artifacts. To be consistent with the specs, everything that is archetypable should be able to have ADL/OPT support, even if the structure has no constrant, that should be stated by the AOM/TOM, not by the RM. Without archetypes, there is no consistency in the specs and on implementations. A side effect is those structures are not queryable without archetypes and real paths.
Then, each implementer is open to support our not those areas, but at least would have some specs, samples and tooling supporting constraining EHR_STATUS and FOLDER.
Technically you can query the data without any templates. This is how it is done inside Better and EHRbase at the moment. But of course this is not something that I recommend, it’s pretty much freestyling on the RM
Yup - we have done that already on Better CDR and have the queries to prove it (good to know it is supported on Ehrbase) but as you put it Birger it is ‘freestyling’ and @matijap, I think you should consider moving it up your roadmap, on that basis.
It would be much better to use a template to document and constrain the expected structure.
Just to be a pedant, what is meant here is that you can’t query data that has not been committed using a template. You can and indeed mostly should query only with archetypes. (Just adding this here in case any openEHR newcomers happen to read this and misunderstand it).
Yes, technically data instances can be queried because all objects/instances will have paths even if there is no archetype for that structure.
That is like a schemaless approach, an will need to have information about the structures beforehand. To have predictable structures, and formal compliance with the specs, archetypes are needed, even if there are no constraints there, like having an { * } constrain.
In the implementation side, having an archetype or opt allows to precalculate some indexes to make queries faster. If also allows to create query builders, because you have some paths to work with without looking at the data (like looking at a schema to build a query).
