# Integration Information Model revamp
**URL:** https://discourse.openehr.org/t/integration-information-model-revamp/410
**Category:** RM
**Tags:** fhir, iim
**Created:** [4 March 2020 11:46 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410 "2020-03-04T11:46:34Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [4 March 2020 11:46 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/1 "2020-03-04T11:46:34Z")
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](https://openehr.atlassian.net/browse/SPECRM-18): Change GENERIC\_ENTRY data attribute type from ITEM\_TREE to the abstract ITEM class
[SPECPR-297](https://openehr.atlassian.net/browse/SPECPR-297): Generic\_entry would greatly benefit from a “meaning” attribute
[SPECPR-296](https://openehr.atlassian.net/browse/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
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [4 March 2020 14:11 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/2 "2020-03-04T14:11:22Z")
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’?
FHIR example - good idea.
---
### Author:  [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [4 March 2020 14:31 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/3 "2020-03-04T14:31:36Z")
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](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?
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [4 March 2020 14:54 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/4 "2020-03-04T14:54:55Z")
> [@yampeku](#):
>
> 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 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…
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [4 March 2020 14:57 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/5 "2020-03-04T14:57:33Z")
> [@yampeku](#):
>
> 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?
Don’t forget all `LOCATABLEs` have `FEEDER_AUDIT` defined on them which has `original_content` attribute to carry or point to the original data.
---
### Author:  [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [4 March 2020 15:14 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/6 "2020-03-04T15:14:09Z")
Yeah, that would work. Seems like something to put in the example 😃
---
### Author:  [@sebastian.iancu](https://discourse.openehr.org/u/sebastian.iancu)
#### Post date: [5 March 2020 10:11 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/7 "2020-03-05T10:11:29Z")
I’m also ok with such changes, we don’t use this package. Ideally we should try to respect semver and not introduce a breaking change in 1.1
---
### Author:  [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [5 March 2020 10:44 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/8 "2020-03-05T10:44:08Z")
Probably releasing a completely new version is fine if we don’t need to wait for a new full version of the RM
---
### Author:  [@matijap](https://discourse.openehr.org/u/matijap)
#### Post date: [5 March 2020 13:42 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/9 "2020-03-05T13:42:10Z")
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. 🙂
---
### Author:  [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [5 March 2020 13:57 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/10 "2020-03-05T13:57:07Z")
My main question is how dependent does everyone see this over the main rm component. I.e. If we should wait to a major rm version change or not
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [5 March 2020 14:02 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/11 "2020-03-05T14:02:33Z")
I just noticed that the version of that spec is 0.6. That means we can make breaking changes. (Longest gestation period of all time. 🙂
---
### Author:  [@matijap](https://discourse.openehr.org/u/matijap)
#### Post date: [5 March 2020 14:29 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/12 "2020-03-05T14:29:08Z")
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.
---
### Author:  [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [5 March 2020 16:26 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/13 "2020-03-05T16:26:57Z")
I actually have the class loaded into LinkEHR to create archetypes from it, but again probably never has done that…
---
### Author:  [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)
#### Post date: [22 March 2020 08:14 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/14 "2020-03-22T08:14:04Z")
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.)
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [22 March 2020 09:20 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/15 "2020-03-22T09:20:37Z")
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.
I’m not bothered about protocol. In or out.
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [22 March 2020 09:26 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/16 "2020-03-22T09:26:17Z")
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.
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [22 March 2020 10:18 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/17 "2020-03-22T10:18:43Z")
> [@ian.mcnicoll](#):
>
> 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.
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.
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [22 March 2020 10:22 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/18 "2020-03-22T10:22:53Z")
> [@ian.mcnicoll](#):
>
> ad we add a ’ Date last updated’ element to every EVALUATION as we do need to record something like ‘date\_asserted’.
well we can potentially add ‘date\_asserted’ to EVALUATION.
> [@ian.mcnicoll](#):
>
> 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.
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.
---
### Author:  [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [22 March 2020 11:01 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/19 "2020-03-22T11:01:25Z")
> [@ian.mcnicoll](#):
>
> I’m not bothered about protocol. In or out.
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 🙂
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [11 August 2020 12:03 UTC](https://discourse.openehr.org/t/integration-information-model-revamp/410/20 "2020-08-11T12:03:42Z")
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.
[Next page](https://discourse.openehr.org/t/integration-information-model-revamp/410.md?page=2)