# CEN 13606 **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2006-11-03 09:27 UTC **Views:** 3 **Replies:** 14 **URL:** https://discourse.openehr.org/t/cen-13606/14598 --- ## Post #1 by @Andrew_Patterson Apologies that this is perhaps not the right forum, but I sense there is a fair crossover between the CEN and openehr communities so I thought this might reach the right ears\.\. I have been perusing the draft cen 13606\-1 specification in my exploration of all things openehr related \(given the large overlap in ideas\.\. two level modelling etc\)\. I was wondering if anyone had any ADL archetypes based on the 13606\-1 reference model? I am going to hand craft some as an experiment but would love some that are more clinically valid than my idle musings\.\. On related notes \- I do not normally have any access to cen materials and am completely in the dark as to the whole cen standards process, but I take it that 13606\-1 is in draft mode, awaiting a vote on acceptance? From my brief reading, it seems not ready for 'prime time'\.\. two that immediately came to my attention were the ED support type that has a compulsory "language" attribute \(which means what for a photo?\) and URI reference? Maybe the UML diagram is wrong or something but it seems to indicate that both of them compulsory, when surely they have to be optional attributes? \(I have just read it again, and in their defence, it does say they are waiting for a new datatypes standard to be published so perhaps they have not looked too much at this area\)\.\. But even the examples seem confused\.\. annex C has an 'informative' sample ehr\_system\.extension = Whittington ehr\_system\.assigningAuthorityName = NHS ehr\_system\.valid\_time = 1/1/1990 \- 1/1/3000 ehr\_system\.root\.oid = 9876543211 Why would any health standard be promoting an example using 'magic' dates to indicate infinite time ranges?? Surely these are open ended intervals rather than actually statements that this ehr\_system is going to cease to be valid in the year 3000? I know its just a sample, but if the sample doesn't show the proper techniques, what chance does any programmer reading the spec have to do it correctly\.\. I also am under the impression that 13606\-2 will be an effort to standardise the expression of archetypes? Is ADL in its current form a contender for that standard? How far along is the standards process and are there any avenues to review the work \(for non\-europeans\)? Andrew --- ## Post #2 by @grahamegrieve hi Andrew I can comment about the datatypes > not ready for 'prime time'\.\. two that immediately came to > my attention were the ED support type that has > a compulsory "language" attribute \(which means what > for a photo?\) and URI reference? Maybe the UML diagram > is wrong or something but it seems to indicate that both > of them compulsory, when surely they have to be optional > attributes? both are optional\. \(I have just read it again, and in their defence, it > does say they are waiting for a new datatypes standard to > be published yes, there will be something new, though it is not clear yet exactly what that will be > so perhaps they have not looked too much at > this area\)\.\. > > But even the examples seem confused\.\. > > annex C has an 'informative' sample > > ehr\_system\.extension = Whittington > ehr\_system\.assigningAuthorityName = NHS > ehr\_system\.valid\_time = 1/1/1990 \- 1/1/3000 > ehr\_system\.root\.oid = 9876543211 agree the valid\_time is confused and confusing Grahame --- ## Post #3 by @system Dear Andrew, There is a very substantial overlap between OpenEHR and EN13606. Both technically and personally. But there are differences. EN13606 EHRcom is the result of an European/Australian consensus process and can not be equated with OpenEHR. EN13606 can be used to map to legacy systems and interact with OpenEHR conformant systems. OpenEHR is a much richer specification that can be used to produce an EHR-system with real plug-and-play semantic interoperability. Within the framework of OpenEHR it is (will be) possible to use the CEN EHRcom extract. For all practical purposes I consider OpenEHR as a specific implementation specification of EN13606 with some important additional features. My advice is to use OpenEHR as an implementable specification and make and use archetypes derived from OpenEHR. The status of EN13606 EHRcom is that the parts 1,2,3 and 4 are stable. Part 1 is final and will be published soon, I expect. Parts 2,3 and 4 will be voted on soon and published next year. It is expected that soon ISO will adopt these standards as well. Your technical comments I will refer to Dipak Kalra the task force leader. ADL and part 2 of the EN13606 are identical. Gerard Freriks -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 --- ## Post #4 by @Andrew_Patterson > both are optional\. thanks Grahame, I thought they had to be optional \(given the ED datatype recursively refers to itself it would be hard to implement if they were mandatory\!\)\.\. am I misreading the UML diagram notation or are the diagrams not up to date? It uses notation like thumbnail: ED\[1\] which I would read as a mandatory attribute\. Or is the optionality introduced using the null\_flavour attribute on DATA\_VALUE? Andrew --- ## Post #5 by @Andrew_Patterson > EN13606 EHRcom is the result of an European/Australian consensus process and > can not be equated with OpenEHR\. > EN13606 can be used to map to legacy systems and interact with OpenEHR > conformant systems\. So 13606 EHRcom is very much a go\-between format \- something that can be used to transfer clinical data between systems, but not something around which you would build an actual running system i\.e\. a system sitting in a GP's office? Is that the correct thinking? > Your technical comments I will refer to Dipak Kalra the task force leader\. > > ADL and part 2 of the EN13606 are identical\. How does the openehr governance and CEN process mesh? At the moment, if we find a typo in the ADL spec, we mail Thomas and he fixes it \(I know there is an actual formal openEHR process but for simple changes, that is what is boils down to :\)\. When it becomes an ISO standard, do changes to the openEHR ADL spec automatically transfer across into the ISO standard? Is there any chance in a divergence between the languages? Andrew --- ## Post #6 by @system see below. Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 > So 13606 EHRcom is very much a go-between format - something that > can be used to transfer clinical data between systems, but not something > around which you would build an actual running system i.e. a system sitting > in a GP's office? Is that the correct thinking? Yes, this is how I understand things. > > Your technical comments I will refer to Dipak Kalra the task force leader. > > > > ADL and part 2 of the EN13606 are identical. > > How does the openehr governance and CEN process mesh? At the > moment, if we find a typo in the ADL spec, we mail Thomas and he > fixes it (I know there is an actual formal openEHR process but for > simple changes, that is what is boils down to :). > When it becomes an ISO standard, do changes to the > openEHR ADL spec automatically transfer across into the ISO standard? > Is there any chance in a divergence between the languages? For quite some time I'm of the opinion that conformance testing of standards is useless. We need to test conformance against an implementable specification. In general the standard will be the most generic stable point of reference. But in reality we all know that reality and experience evolve faster than any standardisation organisation is able to cope with. For all practical purposes OpenEHR is the fast track, quick response, organisation taking care of a version of an implementable specification. In the case of CEN13606 part 1 conformance testing should be done using the OpenEHR specification (the CEN Extract part) In the case of CEN13606 part 2 conformance testing should be done using a designated version of the OpenEHR ADL specification. It will be up to OpenEHR, the user community and possibly others (like governments) to decide when to correct, amend and update the standards. --- ## Post #7 by @Dipak_Kalra Dear Andrew, Your e\-mail, with some thoughtful questions, has generated some interesting discussion inputs already\. The relationship between 13606 and openEHR is long\-standing, since a number of the openEHR family have been involved in this standard's development but 13606 does, as you have gathered, have a different and narrower scope\. The openEHR Foundation is in the process of reviewing how best to reflect the relationship as it is now, and if you can wait a bit we shall be writing this up more clearly in future documents\. You have also raised a couple of technical points\. Graham has I think responded clearly on the data types \- in an ideal world the ISO data type standard would be ready to use before 13606 is finalised, but as this is not the case we have on a temporary basis referenced the CEN TS 14796 \(and included some explicit data types as you have seen\)\. These will eventually be superseded by the ISO ones\)\. openEHR data types are one of the input feeds to ISO\. The example OIDs in the worked sample in Annex C only have placeholder illustrative attribute values for the validity, root and extension attributes of the II data type\. Ideally I should have found an expert to give me more plausible values, but the main purpose of the example was to show how the clinical hierarchy and revision works and many of the attribute values for IDs and codes are very clearly made up ones \(such as the terminology ones\)\. If you have the time to send me some corrections \(more plausible values\) I can still incorporate them\. Most readers have accepted that examples such as this inevitably have limitations in their completeness, but I agree that it's not ideal\. Gerard has also responded to you on archetype specification currency within openEHR and 13606\. Standards need to be stable, and standards organisations assume that this stability is reasonable and desirable for the marketplace\. A innovative organisation like openEHR has the freedom to make changes more rapidly, but it also wishes for them to be validated in real implementations\. The rapid turn around that you describe is for a document change, not for a field\-validated improvement\! With best wishes, Dipak --- ## Post #8 by @Andrew_Patterson > You have also raised a couple of technical points\. Graham has I think > responded clearly on the data types \- in an ideal world the ISO data > type standard would be ready to use before 13606 is finalised, but as > this is not the case we have on a temporary basis referenced the CEN > TS 14796 \(and included some explicit data types as you have seen\)\. > These will eventually be superseded by the ISO ones\)\. openEHR data > types are one of the input feeds to ISO\. yes, good\. > extension attributes of the II data type\. Ideally I should have found > an expert to give me more plausible values, but the main purpose of > the example was to show how the clinical hierarchy and revision works > and many of the attribute values for IDs and codes are very clearly > made up ones \(such as the terminology ones\)\. If you have the time to > send me some corrections \(more plausible values\) I can still > incorporate them\. Most readers have accepted that examples such as > this inevitably have limitations in their completeness, but I agree > that it's not ideal\. Yes, I understand how difficult it is to put meaningful examples in a spec and keep them accurate\. I actually wasn't worried about the OIDS or codes\.\. I had a philosophical problem with the use of magic dates I would have though ehr\_system\.valid\_time = 1/1/1990 \- 1/1/3000 should be ehr\_system\.valid\_time\.lowClosed = false ehr\_system\.valid\_time\.highClosed = false to show that where no specific values are meaningful, the standard still has ways to represent the real intent \- i\.e\. that this extract has no restrictions on the time range in which it is valid\. I think its important that examples show best practice wherever possible \- as a programmer, there is always a temptation on my part, whenever reading a specifcation, to go straight to the examples section and see if there is an example that matches what I want to do\! And we'd hate lazy programmers like me from getting the wrong ideas\.\. > Gerard has also responded to you on archetype specification currency > within openEHR and 13606\. Standards need to be stable, and standards > organisations assume that this stability is reasonable and desirable > for the marketplace\. A innovative organisation like openEHR has the > freedom to make changes more rapidly, but it also wishes for them to > be validated in real implementations\. The rapid turn around that you > describe is for a document change, not for a field\-validated > improvement\! True, but there have been some changes e\.g\. the quoting rules for unicode, that have been more than cosmetic textual changes\. I am just concerned that the freedoms that openEHR has to change things rapidly might be lost if the spec gets tied to the CEN/ISO process\. Andrew --- ## Post #9 by @system Dear Andrew, > True, but there have been some changes e.g. the quoting rules for > > unicode, that have been more than cosmetic textual changes. I am just > > concerned that the freedoms that openEHR has to change things > > rapidly might be lost if the spec gets tied to the CEN/ISO process. This antagonism between: - the stability a formal consensus process and the need for quick responses to correct mistakes, make extensions, complete new version in the case of standards, - the need to do quick fixes and do innovative experiments with new features in the case of implementable code and specifications, is not something that has been solved. And then there is an other problem. -Nowadays the standards in medical informatics are very complex, needing several parts, depending increasingly on other standards - The texts in the standards describe specifications for complex software used by large portions of society. These texts are becoming so complex that we need colours and drawings. This results in documents that when printed on paper (as is the rule in formal standardisation organisations) are not very handy to use. Implementers prefer to read code based on the standards and not these complex unwieldy standards texts - On top of rather stable parts of the standards specification we will see an increased need for many small or large lists with codes, or even an actively changing ontology. These lists with codes are part of the standard but can not be printed or changed via the formal processes used in standardisation organisations. In addition these lists can be maintained and published only using databases. In summary we need new types of standards, standards producing mechanisms, standards publishing mechanisms and perhaps new, extra, types of standardisation organisations. For the moment, I think that all problems can be solved by co-operation between the formal standardisation organisations (like CEN and ISO) plus a supporting Open Source organisation (like OpenEHR for implementable specifications) plus not-for-profit organisation (like the European Institute for the Health Record, EuroRec for the maintenance and publication of lists of codes) I expect that in the near future we will need an extra function that will be added to the list. This is an organisation that is responsable for the testing and certification of applications that claim conformance to standards, implementable specifications and lists of codes. As many know EuroRec is executing a European project Q-REC (Quality labeling and Certification of EHR-systems) At this moment they restrict themselves to functional requirements and criteria of EHR-systems. It is inescapable that semantic interoperability and patient safety demand more attention to conformance testing of implementations that claim conformance to standards and other documents. EurRec will be the most likely candidate to organise this in Europe. Greetings, Gerard Freriks -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 --- ## Post #10 by @Hugh_Leslie Hi Andrew The development of openEHR is currently seen as an engineering process similar to a software design process with full version control, issue tracking and decisions on changes confined to experts rather than committees\. This has allowed the openEHR community to respond rapidly to the community of users where issues arise that directly impinge on implementation such as your example of the quoting rules for Unicode\. These changes are raised as issues and then resolved by incorporatng relevant changes into the next release of the specification\. I agree with you that putting all of this under a standards body would potentially slow down necessary development at this stage, however it is certainly useful to imprimatur of a standards body with some aspects of the work\. Regards Hugh --- ## Post #11 by @Christoph_Rinner Dear Dipak there were many questions concerning 13606 on this mailing list so I will also post my questions here\. YET wouldn´t it be possible to host an own mailinglist via openEHR for CEN 13606\. \(compared to technical/implementers\)\. It doesn´t feel right to bother you and the openEHR community with every small question concerning CEN 13606\. It would be great to share Information with the CEN community without feeling guilty when posting at the wrong place\. looking at the example in Annex C of prEN13606\-1 some questions arouse\. ENTRY rc\_id\.extension = 0251: this ENTRY has attributes based on committal\. Shouldn´t these attributes be based on the feeder\_audit? Shouldn´t "committal\.ehr\_sytem\.extension" be named feeder\_audit\.ehr\_system\.extension? Nearly all the elements of the revision \(second part of the example\) are copied from another part of the EHR\. Why do only some have the original\_parent\_ref attribute? \(prEN13606\-1 p\.39\)\. Why does for example the ELEMENT rc\_id\.extension= 0251 not contain an original\_parent\_ref? Is it a restriction of the \(imaginary\) information model, that created the ehr\_extract or of the 13606\-1 standard to update the COMPOSITION \(rc\_id = 213\) and ENTRY \(rc\_id=251\)? Or would it also be allowed to update ONLY the ELEMENT \(rc\_id=258\) where the actual change took place?? ELEMENT \(rc\_id=258\): why does this element not have the attribute previous\_version from the AUDIT\_INFO \(13606\-1 p\.46\)? This element is a revision of rc\_id=158\. It is the only element where change took place\. Why is it not indicated directly in this element? Thanks for you answer Christoph Rinner --- ## Post #12 by @Dipak_Kalra Dear Christopher, It is our wish to support the 13606 adoption path, through a web site, FAQ, discussion lists etc\. Regrettably \(with no formal resources\), all of us who are committed to this effort are already stretched in the actual standards drafting activity\. We are hopeful of gaining funds for this in the future\. I think we should not take over the openEHR lists for 13606 technical questions, and suggest that you all revert to mailing me personally with questions as a short term measure\. I am happy to share replies with several people who wish to be involved, or see if we can set up another list address if demand is there\. The example in Annex C might well be imperfect, for reasons that I explained on Friday evening\. I will look at it again in the next few days and send you back a reply with answers\. I'm also happy to have some help with correcting and enhancing it\. Examples can be very helpful, but a spreadsheet is a lousy tool for such fine grained fiddly work\! With best wishes, Dipak --- ## Post #13 by @Richard_Dixon_Hughes Dipak, Could you count me in on any informal list you operate\. Regards Richard --- ## Post #14 by @thomas.beale A few answers in addition to those provided by others here. 1. openEHR will soon (< 4 weeks) release a draft specification for its EHR Extract. The openEHR Extract is designed for use into and out of openEHR systems, as well as non-openEHR systems. Main features: - It uses a generic model of the concepts "Request" and "Extract" upon which 3 concrete types of Extract are based: - an openEHR EHR Extract, giving faithful representation of openEHR Versions, supporting distributed version merging etc. - a generic Extract, designed to act as a close mapping to the CEN Extract. This is simpler, and is designed to allow CEN 13606 Extracts to be exported or imported from openEHR systems. It can also simply be used as a replacement for the CEN Extract. Most likely the openEHR GENERIC_ENTRY will be used in Compositions in this Extract type. - an openEHR synchronisation Extract, that supports the request "give me all Contributions (i.e. change sets) since the last synchronisation for EHR 1234" between two openEHR system - i.e. EHR-level mirroring- it uses the openEHR data types. (My hope is that the CEN 13606 specification will one day use these as well, since there is a lot of software support and tools already built for them, whereas the CEN data types are currently disconnected, due to the unsuitability of the HL7v3 data types, and the perceived non-applicability of the openEHR data types due to not being issued by an official standards organisation.) - the Request part of the specification includes concepts that will also be useful in defining an Extract webservice: - a specification of the content required in the Extract - what versions are required (all, latest only, specific ones, revision histories only...) - update basis (persist in server, repeat, event-driven, once-only...)1. openEHR can respond quickly to things via a defined change control process, more in the mode of Apache.org than a standards organisation. Currently, although we have a problem report database, we naturally follow up on ideas and suggestions on this technical list - since often the final request for change only becomes clear after a discussion. Soon we will change the tools over to (we think at this stage) the Atlassian/Jira tracking tools, which will formalise the process more effectively (e.g. proper assignment of tasks to persons etc). We also have a release process for each project ("specification" is just one project); this means that no matter how fast the relevant project group responds, any given release will be self-consistent and users can always choose to stay on a particular release rather than having to take on changes they don't yet want. Of course this is not yet perfect, and for the implementation projects we are adding continuous integration tools to improve the management of build products, versions and so on. 1. We don't at this stage see any reason to put openEHR under the control of any standards organisation - indeed, I believe this would be detrimental, since the development mode of most standards organisations is hardly designed to create good quality technical artifacts (due to design by committee, sporadic attendance and involvement, lack of design process, undisciplined requirements gathering, nearly non-existent change management process and so on). This is in no way a comment on the efforts and dedication of people involved in this work (myself included for about 5 years), but rather an observation about the unsuitability of (some) current standards organisations processes for creating detailed technical artifacts which instead need to be engineered in an open community context. (BTW these observations apply far less to organisations like OMG and IETF). - thomas beale Andrew Patterson wrote: --- ## Post #15 by @Dipak_Kalra Dear Richard, Will do\. With best wishes, Dipak --- **Canonical:** https://discourse.openehr.org/t/cen-13606/14598 **Original content:** https://discourse.openehr.org/t/cen-13606/14598