# 13606 revisited - list proposal
**URL:** https://discourse.openehr.org/t/13606-revisited-list-proposal/15113
**Category:** Technical (archive)
**Created:** [15 December 2011 00:49 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113 "2011-12-15T00:49:20Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [15 December 2011 00:49 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/1 "2011-12-15T00:49:20Z")
At the CIMI meeting last week and elsewhere, I have noticed a lot of
interest in the ISO 13606 2012 revision, specifically in a) whether the
openEHR and 13606 reference models can be brought together for part 1 of
the revision and b) in finalising ADL/AOM 1.5 for providing a new
snapshot to ISO for part 2.
It seems to me that it would be useful to have a dedicated place to
discuss this, so I would like to propose a new mailing list,
13606-alignment@openehr.org
Does this seem like a useful idea?
- thomas beale
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [15 December 2011 04:03 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/2 "2011-12-15T04:03:22Z")
Great! this will be THE opportunity to think about an IM 2.0, and the first topic on my wishlist is the simplification of ITEM\_STRUCTURE & children 😃
---
### Author:  [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [15 December 2011 07:30 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/3 "2011-12-15T07:30:46Z")
technically speaking, CLUSTER is already simpler in current 13606 model 🙂
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [15 December 2011 07:52 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/4 "2011-12-15T07:52:48Z")
Hello Thomas,
The unofficial renewal process of 13606 (or pre-SDO process, as you prefer 🙂 will start next February at the EN 13606 Association General Assembly in Seville with an open and public consultation. Before that, to prepare a draft starting point, during January a consultation will be made to key actors, implementers and users of the standard, including openEHR.
There is more information at [http://www.en13606.org/index.php/activities/general-assembly-2012](http://www.en13606.org/index.php/activities/general-assembly-2012)
As you know, my opinion is that an harmonisation or at least a seamless transition between 13606 and openEHR is a key element to succeed.
David
2011/12/15 Thomas Beale \<[thomas.beale@oceaninformatics.com](mailto:thomas.beale@oceaninformatics.com)\>
---
### Author:  [@Seref](https://discourse.openehr.org/u/Seref)
#### Post date: [15 December 2011 08:47 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/5 "2011-12-15T08:47:09Z")
Hi Tom,
Yes, such a list would be good.
Regards
Seref
---
### Author:  [@Marcelo\_Rodrigues\_d1](https://discourse.openehr.org/u/Marcelo_Rodrigues_d1)
#### Post date: [15 December 2011 09:01 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/6 "2011-12-15T09:01:16Z")
Dear Thomas,
The creation of this list will be an excellent contribution to promote the harmonization process. In my opinion the alignment of these two initiatives is a concrete step to achieve interoperability among EHR systems.
Best regards,
Marcelo
2011/12/15 Seref Arikan \<[serefarikan@kurumsalteknoloji.com](mailto:serefarikan@kurumsalteknoloji.com)\>
---
### Author:  [@Isabel\_Roman](https://discourse.openehr.org/u/Isabel_Roman)
#### Post date: [15 December 2011 09:29 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/7 "2011-12-15T09:29:52Z")
Dear Thomas,
I think it is a good idea.
Best Regards,
Isabel
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [15 December 2011 10:04 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/8 "2011-12-15T10:04:01Z")
Great idea, Thomas!
/Rong
---
### Author:  [@Adolfo\_Munoz\_Carrero](https://discourse.openehr.org/u/Adolfo_Munoz_Carrero)
#### Post date: [15 December 2011 10:14 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/9 "2011-12-15T10:14:23Z")
Dear Thomas,
I also think it's a good idea.
Regards,
Adolfo Muñoz
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [15 December 2011 10:33 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/10 "2011-12-15T10:33:17Z")
Dear Pablos,
Internally in the EN13606 Association I started to work on this renewal.
The EN13606 Association will start to think about all 5 parts of the standard.
With respect to 13606 part 1 - the reference model- I think we will have discussions on topics such as:
- scope
- Folders
- Semantic links
- the structure below the Entry Class
- the type of relationships between the Composition/section classes used to structure documents and the Entry, Cluster and Element classes that define the clinical content.
Possibly other members will have their own topics they want to put on the table.
In our EN13606 Association meeting in February in Seville we start the discussions after a consultation phase.
_open_EHR will be part of this consultation phase. Any input from _open_EHR is welcomed.
A WIKI page will be started anytime soon on our website.
After these discussions our suggestions will be submitted to CEN/tc251 and ISO/tc215.
For more information about the EN13606 Association and the Seville meeting I refer to:
[www.en13606.org](http://www.en13606.org)
Non-members that want to participate in this meeting are invited to subscribe.
Gerard Freriks
+31 620347088
[gfrer@luna.nl](mailto:gfrer@luna.nl)
---
### Author:  [@Stef\_Verlinden1](https://discourse.openehr.org/u/Stef_Verlinden1)
#### Post date: [15 December 2011 11:43 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/11 "2011-12-15T11:43:23Z")
I asume there is no subscription fee for openEHR members.
Cheers,
Stef
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [15 December 2011 13:22 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/12 "2011-12-15T13:22:48Z")
Hi Stef,
There are no subscription fees, all activities are open to the public. The only requirement is to confirm the attendance in advance because the space will be limited.
David
2011/12/15 Stef Verlinden \<[stef@vivici.nl](mailto:stef@vivici.nl)\>
---
### Author:  [@Chang\_Wo\_L](https://discourse.openehr.org/u/Chang_Wo_L)
#### Post date: [15 December 2011 13:46 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/13 "2011-12-15T13:46:32Z")
Dear Thomas,
Wonderful and much appreciated for setting the special reflector for it, thanks!
Can you kindly provide the link how to join the new reflector?
Thanks!
--Wo
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [15 December 2011 14:02 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/14 "2011-12-15T14:02:58Z")
Hi!
> The unofficial renewal process of 13606 (or pre-SDO process, as you prefer
> 🙂 will start next February at the EN 13606 Association General Assembly in
> Seville with an open and public consultation.
Is there any formal link between the 13606 Association and the actual
standardisation process or is the "pre-SDO process" to be seen as
traditional lobbying?
Perhaps the best thing would be if the 13606 Association and openEHR
could bring forward a unified co-authored suggestion to the SDO
process rather than two suggestions? Perhaps we can use the new
mailing list Thomas suggested for mail conversations combined with the
wiki of the EN 13606 Association, instead of having separate mailing
lists and separate wikis for the alignment discussions in each
community?
> Before that, to prepare a
> draft starting point, during January a consultation will be made to key
> actors, implementers and users of the standard, including openEHR.
A great thing would be to actually have at least two independent
\_implementations\_ of change suggestions (both AM and RM) after initial
discussions but before any revisions to the standard are made. That is
how some other SDOs work with technical artefacts and it could avoid
some of the previous suboptimal approaches.
I assume AOM 1.5 is a candidate for AM? Is anybody already working on
an AOM 1.5 implementation in addition to Tom's Eiffel version? Are
there people interested in updating the Java implementation (or some
other implementation) before or during the SDO process?
Regarding the RM I know Tom is experimenting with simplified
ITEM\_STRUCTURE as a BMM-schema for the AWB. Are there any other
RM-redesign experiments going on anywhere?
What is happening in the 13606-world regarding thoughts about
practical datatypes?
What about (optional) reusable ENTRY subtypes in the 13606 world? (see
[http://www.openehr.org/mailarchives/openehr-technical/msg05285.html](http://www.openehr.org/mailarchives/openehr-technical/msg05285.html)
under the heading "2. OBSERVATION et. al. (ISO 13606 CR)")
> As you know, my opinion is that an harmonisation or at least a seamless
> transition between 13606 and openEHR is a key element to succeed.
I totally agree.
Bringing the communities tighter together is another important thing.
The way some leaders sometimes talk of the other organisation's
approaches might not be helpful in that sense. Those of you having
formal powers in each organisation please ask your leaders to speak as
honestly and nicely as possible of each others
organisations/communities/approaches, or else please change leaders.
Best regards,
Erik Sundvall
erik.sundvall@liu.se [http://www.imt.liu.se/~erisu/](http://www.imt.liu.se/~erisu/) Tel: +46-13-286733
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [15 December 2011 14:19 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/15 "2011-12-15T14:19:09Z")
That’s the simplification we need to the IM 2.0! 😃
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [15 December 2011 14:22 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/16 "2011-12-15T14:22:40Z")
Hi Gerard, is good to know! please publish the link to the wiki discussion when available.
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [15 December 2011 14:54 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/17 "2011-12-15T14:54:42Z")
Hi Erik,
I want to implement some simplifications of the item\_structure in the EHRGen ( [http://code.google.com/p/open-ehr-gen-framework/](http://code.google.com/p/open-ehr-gen-framework/) ) we talked about this: [http://www.openehr.org/mailarchives/openehr-clinical/msg02231.html](http://www.openehr.org/mailarchives/openehr-clinical/msg02231.html)
My focus is on the persistence layer, because we persist data using an ORM (object-relational mapping) component, and the complexity of the relational schema is proportional to the complexity of the object model.
BTW, the EHRGen has the complete cicle of information implemented: automatic gui generation (based on archetypes and our gui templates), data validation against archetype constraints, data binding (creation of RM structures from user data input and archetypes), persistence of those structures, and getting data to show on a GUI.
Now I’m experimenting with semantic queries (common SQL but based on arcehtype ids and paths).
Regards,
Pablo.
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [15 December 2011 15:38 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/18 "2011-12-15T15:38:48Z")
Dear Erik,
Some personal comments in the text below.
GF
Gerard Freriks
+31 620347088
[gfrer@luna.nl](mailto:gfrer@luna.nl)
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [15 December 2011 15:48 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/19 "2011-12-15T15:48:07Z")
I have started a [wiki page](http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model) for this ‘lower RM’ simplification. The top contains the existing models, feel free to add to the ‘problem’ list (why are we simplifying?). If you have a candidate solution to offer, please put it under a new heading - you will see a ‘Candidate B’ ready to be used by someone. If we proceed in that fashion, I think we can keep the proposals clear.
NOTE: I have only half done my proposal, Candidate A, so don’t bother looking at it yet.
- thomas
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [16 December 2011 05:11 UTC](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113/20 "2011-12-16T05:11:15Z")
Hi Gerard!
This will be an interesting process...
I think you will need to clarify several of your technical/modeling
statements and motivations during the process, I find several of them
a bit hard to understand.
Gerard wrote:
> We need to reduce the number of degrees of freedom producing archetypes.
If you in the RM predefine ways to model certain things (e.g. timing
in observations by introducing an OBSERVATION class) then you are in
practice \_reducing\_ the degrees of freedom compared to leaving it
completely open for free form modeling using clusters in an unspecific
generic ENTRY. Remember that an unrestricted cluster has unlimited
degrees of freedom.
Gerard wrote:
> We need to be able to use specialisations of the Entry class.
> My thinking is that these health specific specialisations ( Observation,
> Evaluation, Instruction, Action, etc.) must not play a role in the RM.
>
> We are working on an addition to the 13606 standard that defines how
> semantic interoperability artefacts are structured, used in other semantic
> artefacts, how standardised modeling patterns are used, etc.
> In this scheme all these things define a standard for the semantic layer on
> top of the present technical 13606 layer.
>
> I foresee a strict separation between the technical 13606 standard (as we
> know it) and a semantic artefact layer (that we will need to wok on)
> The technical layer is very generic, healthcare a-specific.
> The Semantic artefact layer will have some health specific items
> incorporated: e.g. Observation, etc. but even then contain many health
> a-specific constructs that can be used outside of healthcare.
> This thinking will have consequences for the present 13606 parts 1, 2 and 3.
I assume "healthcare a-specific" means something like "more general
and not specific to healthcare", is that a correct interpretation of
your words?
If so, why do you want to turn the 13606/openEHR into something
"healthcare a-specific"? Wouldn't that be an enormous deviation from
the current 13606 thinking and purpose? Was not 13606 intended exactly
for healthcare?
If you want a completely generic RM with the possibility of an
infinite number of meta-layers on top then something like RDF (as RM)
with OWL (as meta) on top seems to be what you are looking for. The
RDF+OWL approach definitely has both good use-cases and good
implementations but it is a very different approach than having a
healthcare specific 13606/openEHR RM in the bottom layer.
I think the approaches can co-exist perfectly and sometimes meet and
data/models partly be translated between them for specific purposes.
But if you try to completely morph one approach into the other you'll
likely run into trouble.
And what would a "healthcare a-specific" 13606 RM bring to the
"healthcare a-specific" scene that is not already there in one form or
another? What is the purpose of going "healthcare a-specific"?
The base classes of the HL7 v3 RIM (ACT etc) are sometimes said to be
"healthcare a-specific" and reusable in other contexts. But have they
really been extensively adopted outside healthcare? Why would 13606
want to go there? Can't we leave that exploration to HL7?
Another basic thing to explain is why things would get better or
easier by introducing even more (meta?) layers of modeling. I think
the levels of openEHR are many already, but they at least have been
tested in real systems and real modeling work and have somewhat clear
motivations for existing:
1. RM (for real software-implementable recurring stuff that you can
optimize storage and query for in order to get fast usable EHR
systems)
2. Archetypes (for finding/defining "maximal" datasets for closely
related documentation needs, this provides shared queryable search
paths)
3. Templates (for aggregating pieces and narrowing scope again to fit use cases)
(Also add management of the interaction with terminology systems to
all of the above before considering adding layers.)
Erik wrote:
> > A great thing would be to actually have at least two independent
> > \_implementations\_ of change suggestions (both AM and RM) after initial
> > discussions but before any revisions to the standard are made. That is
> > how some other SDOs work with technical artefacts and it could avoid
> > some of the previous suboptimal approaches.
Gerard wrote:
> So you agree with my NO.
What NO? Please clarify.
Best regards,
Erik Sundvall
erik.sundvall@liu.se [http://www.imt.liu.se/~erisu/](http://www.imt.liu.se/~erisu/) Tel: +46-13-286733
[Next page](https://discourse.openehr.org/t/13606-revisited-list-proposal/15113.md?page=2)