I’ve always been a fan of this part of the model, as it can really allow for quick integrations, but from chatting with everyone else, seems like I’m in the minority here
So I would like to propose a revamp for the model, not only in the model itself, but also in the use cases presented in the specification. Here is the tasks I proposed in the past to enhance the model:
SPECRM-18: Change GENERIC_ENTRY data attribute type from ITEM_TREE to the abstract ITEM class
SPECPR-297: Generic_entry would greatly benefit from a “meaning” attribute
SPECPR-296: Add FHIR example in Integration Information Model
If anyone has other suggestions feel free to discuss them. Probably last enhancement could be more interesting to have, so it shows what can be achieved with this.
As far as I know nobody is using this part of the model, so probably makes sense to improve it now before any implementation (EHRBase?) occurs.
Another argument in favor of its use is to bring some other communities into openEHR (thinking explicitly in the ISO13606 and HL7 CDA communities). This model can also be of pivotal importance in the new ISO 24305 of Guidelines for implementation of HL7/FHIR based on ISO 13940 and ISO 13606-3, as with little effort could probably make openEHR ISO 24305 compliant
The change to data: CLUSTER makes sense, although it is technically a breaking change. We would need to be sure that no-one has ever used this model to do that. Other alternative is to create GENERIC_ENTRY2 with the desired structure.
I think an attribute indicating some sort of semantic typing is a good idea - but I think ‘meaning’ is not a good name (this is name is my fault BTW, it was used in early openEHR models and leaked into CEN 13606…), maybe ‘original_type’?
I personally don’t like the GENERIC_ENTRY2 name, I’d rather prefer to add CLUSTER as an alternative type to ITEM_TREE if it’s really needed.
I’m ok with ‘original_type’ name, I think it wasn’t really stated in the proposal, but it could be a CODE_PHRASE (so we could have something like termid:http://hl7.org/cda and code: Observation
Another thing probably worth considering is that if some kind of optional new attribute with an EHR_URI or similar would be interesting to have to point to the original data. Maybe would allow to point to original data if known or if we use it to create summary data with this model?
I don’t either - I was just indicating the standard approach to not causing breaking changes - leave the old class alone and define a new one with a new name.
Evil me would like to just fix what is there. Good me doesn’t want to break the versioning rules…
Our server supports the GENERIC_ENTRY, but our modelling tools do not allow it AFAIK, so i’m almost certain none of our customers ever used it; I’m indifferent if you change it in a minor version, although the purist in me is complaining quietly in the corner.
Such a change seems to break nothing for us at the moment (because we most probably store no such data), and if I’m wrong, we can hack deserialisation, and with some more effort the query engine as well, to accommodate for that, so that bill’s on me if it comes down to having to pay it. You should of course wait for other implementors to chime in.
Updating the integration information model would be good, I see many upcoming uses for it when we are going to encapsulate old data from legacy and “feral” systems into our planned main CDR.
Good thing it was 0.6 so that we can get it into 1.1 without breaking the hearts of purists…
(It would be wonderful to have this in place in procurement processes.)
I 've argued before that I actually do not see the need for this - we can create ‘integration archetypes’ pefectly well with EVALUATION - nothing relies soly on the archetype class name.
but … leaving that aside if we do upgrade GENERIC ENTRY - wwe would get much more benefit from making it inherit from ENTRY (or just make CARE_ENTRY concrete) and adding an extension slot and (controversially!) effectiveDate. That would give us much more value going forward and possibly prevent endless OBERVATION vs. EVALUATION discussions.
Right now we add an extension slot to every archetype. Yes it’s a Z segment but hugely valuable when trying to fit in to other people’s architecture e.g contsys
ad we add a ’ Date last updated’ element to every EVALUATION as we do need to record something like ‘date_asserted’.
So can we add that as some kind of abstract date to CARE_ENTRY or even entry that can be concretised as ACTION.time, OBS.origin and even INSTRUCTION - as the ‘start point’ - essentially overriden by the ACTION.
well it does create a problem though - tools like CKM and others (incl. ADL workbench) either default sort archetypes into groups based on the RM types or allow searching on that basis. This is sensible because the RM types indicate the design intention. An integration archetype is clearly not any kind of clinical assessment or evaluation, so it doesn’t make sense to use that class as the basis for one.
well we can potentially add ‘date_asserted’ to EVALUATION.
We could in theory add a ‘clinical_time()’ or ‘effective_time()’ abstract function to CARE_ENTRY that is defined as returning those things in the concrete descendants. I think for INSTRUCTION, it would have to be when the Instruction was either made (when were you prescribed this) or when the instruction was specified to be performed. Probably the former, since the ACTIONs give you the real time(s) when it was done.
one good thing about adding a “meaning” attribute is that model can be generic, and nobody stops us to even define meaning codes for typical openEHR structures
What might be quite interesting is to see if there is a way of 'associating a local archetype node with the generic RM attribute in kind of the way that ism_transitions work - generic time and status attributes which can stand alone but are given precise meaning via the archetypable careflow_step attribute. That gives us the best of both worlds.
