# Interoperability with HL7 **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2010-01-29 07:41 UTC **Views:** 8 **Replies:** 46 **URL:** https://discourse.openehr.org/t/interoperability-with-hl7/14960 --- ## Post #1 by @Alberto_Moreno_Conde I would like to address the interoperability with the HL7 standards. As I understand it is possible to map between OpenEHR to HL7 CDA, this allows us to create systems that are based on the openEHR reference model compatible HL7. This system would be able to send HL7 v2 and HL7 v3 messages from the CDA and EHR_EXTRACTS from the OpenEHR reference model. I don't understand what consequences have that the HL7 RIM is still not fully compatible with the OpenEHR reference model if we can send messages from HL7 CDA. Is there other problems in the interoperability between HL7 and OpenEHR? I hope that Thanks Alberto --- ## Post #2 by @williamtfgoossen Alberto, at the large reference model, there are differences. But at the level of an Entry on OpenEHR and a clinical statement in HL7 v3, I have not seen other problems than only technical changes. Semantically the way data are expressed and linked to codes are similar. A clinicial statement does allow to include relationships between variables, for instance like in assessment scales (Apgar, Glasgow COma etc). That should be added on the level of an archetype if that information needs to be send. But normally five Apgar values and the sixt Apgar total at point X in time can be sent as a set of 6 HL7 v3 clinical statements following exactly the archetype format. Met vriendelijke groet, Results 4 Care b.v. dr. William TF Goossen directeur De Stinse 15 3823 VM Amersfoort email: Results4Care@cs.com email: williamtfgoossen@cs.com telefoon +31 (0)654614458 fax +31 (0)33 2570169 Kamer van Koophandel nummer: 32133713 --- ## Post #3 by @thomas.beale Hi Alberto, In practical terms, performing mapping between HL7v2 messages and openEHR, and also CDA and openEHR is certainly possible. It takes some work - the complexity of the HL7 RIM doesn't make it that easy for CDA or other v3-based structures. In a theoretical sense, the key thing to understand is that in HL7 there is a pervasive approach of restriction-based modelling - in the RIM, the data-types, and all *MIMs. In this kind of modelling, abstract classes have numerous attributes, in theory all that would ever be needed, and descendant classes are defined as restrictions of the parents. You will have noted for example that the Act class in the RIM has 22 attributes, and the Act-relationship class 18. I won't go into the problems that this causes, but there is one other key fact to note: the RIM classes contain a mixture of domain information related attributes and message-related attributes. However, if your interest is not hand-building messages, it can be hard to see past these attributes to get a pure domain model of the concept in question, e.g. cholesterol test result, or whatever. This is one of the reasons CDA has become popular, because it is a more generic, less message-oriented RMIM than other message types. It nevertheless contains the same fine-grained (level 3) concepts as the RIM, albeit in a restricted form. At a more concrete level of analysis, you need to compare the reference models. The openEHR reference model is a standard OO style of modelling, and has been heavily influenced by the development of archetypes over the years. It now appears to accommodate most clinical models pretty naturally and has been very stable for nearly 3 years. It contains useful structures like history-of-events, various design patterns for referencing demographic entities, a generalised state machine for instructions and activities, and a comprehensive model of distributed versioning. In terms of solving practical interoperability problems, the above analytic comparisons have been useful in implementing the required transformations. If you can provide more detail on the problem you are trying to solve, I could probably describe more detailed and relevant points of comparison. - thomas beale --- ## Post #4 by @Charles_McCay Alberto I would say that EHR systems based on the openEHR specification face similar interoperability challenges to to those based on other proprietary or open source architectures. I will take a step back and observe that two implementations of openEHR or any other EHR system design will not interoperate fully unless there are coherent information structures used. This is certainly true of a system as flexible as that defined by the openEHR architecture. Agreeing on a reference model (HL7 RIM, 13606, openEHR, ...) and a terminology certainly helps, but even with that agreement in place there are many ways to represent the same clinical content. More is needed to ensure that information can be safely reused and combined. Within an openEHR installation this is achieved by using a single coherent set of archetypes, much as data structures are localised in other EHR architectures. If your requirement is limited to communicating within an openEHR community, then developing and agreeing to use a suite of common archetypes and templates is sufficient. If you wish to interoperate with the broader healthcare information systems installed base, then it makes sense to work with HL7 specifications which are focused on delivering this, and broadly adopted for this purpose. For external communication of entry-level detail using HL7v3 there is a need for agreed static models (R-MIMs). These are implemented as templates (eg with CDA), or as CMETs in V3 messaging - and a corresponding sets of archetypes for 13606 or openEHR can be defined if these are what you use to configure your system. All the best Charlie --- ## Post #5 by @Stef_Verlinden1 > More is needed to ensure that information can be safely reused and combined. Dear Alberto, Can you please explain what this 'more' is and provide some examples for a non-technical person like myself. Cheers, Stef --- ## Post #6 by @Alberto_Moreno_Conde Dear Stef, As I understand when Charlie McCay says "More is needed to ensure that information can be safely reused and combined.". It is because when you have an agreed reference model and terminology, for example openEHR and SNOMED you can define the clinical concepts relation using the archetypes but your archetype definition for one concept may vary between different solutions. Each of these possible solutions would be valid archetypes that can be used therefore to avoid problems is better store your archetypes in an agreed repository. Then both sides, the source and the receptor, can express the medical concepts with the same structure (archetype) and avoid interoperability problems. The same situation can happens defyning clinical concepts in other reference models such as HL7 CDA or 13606 archetypes. This is only my opinion maybe I am not the right person to answer about other people comments Alberto 2010/2/1 Stef Verlinden <[stef@vivici.nl](mailto:stef@vivici.nl)> --- ## Post #7 by @Charles_McCay Alberto You are correct. An example would be the XMLEPR project [1], which in 1999 asked a number of suppliers to write ENV 13606 instances for the same GP medical record. The results showed that each used different combinations of 13606 structures to represent key concepts such as allergies. Since these structures need to be recognised and used by the receiving systems, further specification is needed. In the case of the english GP2GP project, an HL7v3 implementation of 13606 (ie clinical statement) was used, with additional implementation guidance to say how allergies, family history, and many other such patterns should be represented. This has been successfully adopted and implemented within the NHS CFH program [2]. The language defined by ENV13606+Read codes was too flexible for the receivers to be able to be able to identify all the allergies (among many other things). The GP2GP specification effectively established a more specific language for expressing GP record contents, that was easier for receivers to process. In the time since then formalisms (archetypes, HL7 static models as templates, etc) have been developed to help express those additional constraints. One other question to ask is why you want interoperability. Often it is fine to define structures that will only be used locally, and often it is all that is possible. OpenEHR defines a particular architecture that can be used for EHR systems which manipulate locally defined data, as well as data that needs to be shared in a wider community. HL7 provides a framework and set of specifications for sharing healthcare information. All the best Charlie [1] [http://xml.coverpages.org/isis-healthcare.html](http://xml.coverpages.org/isis-healthcare.html) [2] [http://www.connectingforhealth.nhs.uk/systemsandservices/gpsupport/gp2gp](http://www.connectingforhealth.nhs.uk/systemsandservices/gpsupport/gp2gp) --- ## Post #8 by @thomas.beale Based on Charlie's reply, maybe my own was not clear. openEHR is mostly not about solving the problem of openEHR systems talkng to each other (that is rare at this stage, as you might imagine; when it happens, there is not much problem to solve, obviously - openEHR is a single data standard), but in fact solving normal interoperability problems with other systems and formats. Connecting to HL7v2 messages, HL7v3 messages (these seem to be pretty rare so far, apart from the UK and Canada) and CDA documents, other formats like text, PDF, proprietary data structures, but also the IHE framework, Microsoft CHF services framework.... all this is already happening in the openEHR world. The main point is _how_ it is done. Instead of manually building a message specification for say 'microbiology', the openEHR approach is as follows: - build or source archetypes, like you can see at [http://www.openEHR.org/knowledge](http://www.openEHR.org/knowledge) e.g. see Apgar at [http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.172](http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.172) - create templates from the archetypes for use-case specific use - from templates we create various computable artefacts - such as template-based message schemas (XSD) and template-based programming objects. - template-based message schemas are used to implement messages, either as an integration solution, or as an end-to-end solution - template-based programming objects are used to enable integration with existing applications - all querying done with AQL or other archetype-path based languages, which enable portable, semantic querying for all data represented in openEHR format. This singe-source semantic modelling approach is visualised at [http://www.openehr.org/160-OE/version/default/part/ImageData/data/single_source_models.jpg](http://www.openehr.org/160-OE/version/default/part/ImageData/data/single_source_models.jpg) . I would go so far as to say that the age of hand-built messages will be over soon - it won't make people in HL7 happy I guess, but the technology is now beyond that approach, and firmly in the arena of model-driven content and SOA infrastructure. The final standardisation within openEHR of the templates and template-related artefacts are happening at the moment, based on the last couple of years' experience with this technology within some of the commercial openEHR vendors. Our experience of archetype-based querying has been extremely successful, in both EHR and population modes. Querying is one of the weakest areas in the published standards, yet it is probably the single most important factor in the use and re-use of data in health. Having a comprehensive and semantically solid querying approach is therefore crucial for useful interoperability (after all there is not much point moving data somewhere else, or transforming it if you still can't query it properly). We believe that the combined power of archetype-based templates and archetype-based querying will become a major advance for the field of health informatics, along with the emerging openEHR service infrastructure. - thomas beale --- ## Post #9 by @William_E_Hammond Not trying to start a war, but I am disappointed at the continued dialog that is negative toward HL7\. If, in fact, openEHR has solved all of the problems of interoperability and is being picked up around the world, I, and I think, many of my HL7 colleagues will be delighted\. Very few of the members of HL7 make money from HL7, so I think our motivations are driven by our companies and the market place\. Solving the problems of interoperability will certainly open the door for many more important accomplishments\. I hope archetypes are engaged by the clinical community and help us make a key step forward\. However, there are still hurdles to be overcome before we have systems working together\. Let's join forcesa and publicize successes in a demonstratable way\. Whether HL7 or openEHR, I think one's success is the others success\. W\. Ed Hammond, Ph\.D\. Director, Duke Center for Health Informatics              Thomas Beale              <thomas\.beale@oce              aninformatics\.com To              > openehr\-technical@openehr\.org              Sent by: cc              openehr\-technical              \-bounces@chime\.uc Subject              l\.ac\.uk Re: Interoperability with HL7                                                                                          02/01/2010 10:33              AM                                                                                          Please respond to                 For openEHR                  technical                 discussions              <openehr\-technica              l@chime\.ucl\.ac\.uk                      >                                                                             Based on Charlie's reply, maybe my own was not clear\. openEHR is mostly not about solving the problem of openEHR systems talkng to each other \(that is rare at this stage, as you might imagine; when it happens, there is not much problem to solve, obviously \- openEHR is a single data standard\), but in fact solving normal interoperability problems with other systems and formats\. Connecting to HL7v2 messages, HL7v3 messages \(these seem to be pretty rare so far, apart from the UK and Canada\) and CDA documents, other formats like text, PDF, proprietary data structures, but also the IHE framework, Microsoft CHF services framework\.\.\.\. all this is already happening in the openEHR world\. The main point is \_how\_ it is done\. Instead of manually building a message specification for say 'microbiology', the openEHR approach is as follows:       build or source archetypes, like you can see at       http://www.openEHR.org/knowledge e\.g\. see Apgar at       http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.172       create templates from the archetypes for use\-case specific use       from templates we create various computable artefacts \- such as       template\-based message schemas \(XSD\) and template\-based programming       objects\.       template\-based message schemas are used to implement messages, either       as an integration solution, or as an end\-to\-end solution       template\-based programming objects are used to enable integration       with existing applications       all querying done with AQL or other archetype\-path based languages,       which enable portable, semantic querying for all data represented in       openEHR format\. This singe\-source semantic modelling approach is visualised at http://www.openehr.org/160-OE/version/default/part/ImageData/data/single_source_models.jpg \. I would go so far as to say that the age of hand\-built messages will be over soon \- it won't make people in HL7 happy I guess, but the technology is now beyond that approach, and firmly in the arena of model\-driven content and SOA infrastructure\. The final standardisation within openEHR of the templates and template\-related artefacts are happening at the moment, based on the last couple of years' experience with this technology within some of the commercial openEHR vendors\. Our experience of archetype\-based querying has been extremely successful, in both EHR and population modes\. Querying is one of the weakest areas in the published standards, yet it is probably the single most important factor in the use and re\-use of data in health\. Having a comprehensive and semantically solid querying approach is therefore crucial for useful interoperability \(after all there is not much point moving data somewhere else, or transforming it if you still can't query it properly\)\. We believe that the combined power of archetype\-based templates and archetype\-based querying will become a major advance for the field of health informatics, along with the emerging openEHR service infrastructure\. \- thomas beale --- ## Post #10 by @thomas.beale regarding any war - me neither ;-) Ed, I hope you see that it is reasonable to respond in some way to disinformation like 'only use openEHR if you are trying to talk to openEHR systems' - on an openEHR list! Nearly the only problem of interest in openEHR is adding semantics to existing environments. It is obvious by inspection that openEHR would not need to exist in its current form in order to talk to itself. There are theoretical difficulties with HL7v3 messaging & RIM, I don't think there is any way around that, and they do manifest in practical ways; there are also difficulties with CDA. But above all, I still (really, honestly, sincerely) want an answer from HL7 to the question: - how can I define a piece of domain content (microbiology result, Apgar result, ENT exam, etc) once and re-use it in multiple concrete technologies such as a) XSD, various GUI forms development, various programming languages, and b) for various different purposes, e.g. EHR persistence, messages, screen forms, and especially for creating portable queries from. As far as I know I can't really. I can make an RMIM, or a CDA template, but I can't really use these together without treating them like different data schemas. And I can't *directly* re-use either for EHR persistence, querying, reporting or screen display or data capture. I am not saying that openEHR has got every last detail on this solved, but it does have large chunks demonstrable, including fully generated message schemas, programming objects, querying and reporting. The formal infrastructure is proving to be very solid and extensible - and yet it retains simple features like only one XSD for all openEHR data (well it is literally a collection of 6 or 8 component XSDs but you know what I mean). Within the openEHR framework we can generate the equivalent of any HL7 message or CDA - via a tool chain using archetypes, templates and terminology. And we can query the date with archetype-based queries. On the other hand, HL7 has a big community, much better marketing, and probably a better handle on use cases. To me the question about joining forces (which is what we in health informatics owe the world at large, I think) is how it can be done: it must have technical things like: - a solid, open formal platform framework - a clear, useful reference model - a single source domain modelling approach - a solid querying methodology - an integrated set of service definitions - a clean way of integrating with any terminology It must also have the qualities of a community: - a recognised meeting place and culture - agile but defensible governance - buy-in from industry - an on-the-ground network of affiliates - a wide-ranging handle on the requirements of the domain I would say openEHR's strengths are in the first list, and HL7's largely in the second - I am the first to recognise the community-related weaknesses of openEHR. What the world really wants here is a) ONE technical framework and b) ONE open community and governance framework. It could be possible, at the price of some dented egos. History says it will remain a dream. What would it take to overcome that? (Proper funding might be one answer) - thomas beale --- ## Post #11 by @William_E_Hammond I like your reply\. I am willing to commit to putting energy behind merging al standards groups, probably under ISO\. W\. Ed Hammond, Ph\.D\. Director, Duke Center for Health Informatics              Thomas Beale              <thomas\.beale@oce              aninformatics\.com To              > openehr\-technical@openehr\.org              Sent by: cc              openehr\-technical              \-bounces@chime\.uc Subject              l\.ac\.uk Re: Interoperability with HL7                                                                                          02/01/2010 12:02              PM                                                                                          Please respond to                 For openEHR                  technical                 discussions              <openehr\-technica              l@chime\.ucl\.ac\.uk                      >                                                                             regarding any war \- me neither ;\-\) Ed, I hope you see that it is reasonable to respond in some way to disinformation like 'only use openEHR if you are trying to talk to openEHR systems' \- on an openEHR list\! Nearly the only problem of interest in openEHR is adding semantics to existing environments\. It is obvious by inspection that openEHR would not need to exist in its current form in order to talk to itself\. There are theoretical difficulties with HL7v3 messaging & RIM, I don't think there is any way around that, and they do manifest in practical ways; there are also difficulties with CDA\. But above all, I still \(really, honestly, sincerely\) want an answer from HL7 to the question:       how can I define a piece of domain content \(microbiology result,       Apgar result, ENT exam, etc\) once and re\-use it in multiple concrete       technologies such as a\) XSD, various GUI forms development, various       programming languages, and b\) for various different purposes, e\.g\.       EHR persistence, messages, screen forms, and especially for creating       portable queries from\. As far as I know I can't really\. I can make an RMIM, or a CDA template, but I can't really use these together without treating them like different data schemas\. And I can't directly re\-use either for EHR persistence, querying, reporting or screen display or data capture\. I am not saying that openEHR has got every last detail on this solved, but it does have large chunks demonstrable, including fully generated message schemas, programming objects, querying and reporting\. The formal infrastructure is proving to be very solid and extensible \- and yet it retains simple features like only one XSD for all openEHR data \(well it is literally a collection of 6 or 8 component XSDs but you know what I mean\)\. Within the openEHR framework we can generate the equivalent of any HL7 message or CDA \- via a tool chain using archetypes, templates and terminology\. And we can query the date with archetype\-based queries\. On the other hand, HL7 has a big community, much better marketing, and probably a better handle on use cases\. To me the question about joining forces \(which is what we in health informatics owe the world at large, I think\) is how it can be done: it must have technical things like:       a solid, open formal platform framework       a clear, useful reference model       a single source domain modelling approach       a solid querying methodology       an integrated set of service definitions       a clean way of integrating with any terminology It must also have the qualities of a community:       a recognised meeting place and culture       agile but defensible governance       buy\-in from industry       an on\-the\-ground network of affiliates       a wide\-ranging handle on the requirements of the domain I would say openEHR's strengths are in the first list, and HL7's largely in the second \- I am the first to recognise the community\-related weaknesses of openEHR\. What the world really wants here is a\) ONE technical framework and b\) ONE open community and governance framework\. It could be possible, at the price of some dented egos\. History says it will remain a dream\. What would it take to overcome that? \(Proper funding might be one answer\) \- thomas beale --- ## Post #12 by @thomas.beale --- ## Post #13 by @William_E_Hammond I agree that ISO is not the place to develop standards, but it is a body recognized by all the world\. The concept of the JIC appears to be functional \- not smooth and not easy, but progress is being made\. It is not so much that one organization is better than another or that one standard is better, but there are good and bad with some of what we do\. I think the good outweighs the bad, and we can fix some problems\. Why don't we go off line, and try to come up with a plan, then bring back to the larger community\. Ed W\. Ed Hammond, Ph\.D\. Director, Duke Center for Health Informatics              Thomas Beale              <thomas\.beale@oce              aninformatics\.com To              > openehr\-technical@openehr\.org              Sent by: cc              openehr\-technical              \-bounces@chime\.uc Subject              l\.ac\.uk Re: Interoperability with HL7                                                                                          02/01/2010 01:01              PM                                                                                          Please respond to                 For openEHR                  technical                 discussions              <openehr\-technica              l@chime\.ucl\.ac\.uk                      >                                                                                   I like your reply\. I am willing to commit to putting energy behind       merging       al standards groups, probably under ISO\. Not wanting to be more of a trouble\-maker than usual, but I would have to say \- if we could work this out together, let's do it, but I don' t think ISO is the place to do it, only to a\) have wide\-ranging background discussions and b\) to rubber stamp the result\. ISO might be the appropriate background community, but it can't come up with the framework or standards \- it is in fact quite bad at that\. My more detailed opinions on this are here: http://wolandscat.net/2009/09/17/the-crisis-in-e-health-standards/ I know \(once again\) that what is stated there won't be popular with some people, but the feedback has been very interesting indeed\. \- thomas --- ## Post #14 by @Charles_McCay Thomas Offense was not intended — I have always been more taken by the similarities between the openEHR and HL7v3 approaches, than the differences. I also agree that SOA and modelling are mainstream – in HL7 and elsewhere. I do not know anyone in HL7 who is unhappy about this. Messages and documents continue to have a role alongside and within SOA frameworks — I am not aware of anyone within HL7 or elsewhere who is upset by this either. I too agree that collaboration is the way forwards All the best Charlie --- ## Post #15 by @Stef_Verlinden1 Hear, hear\. Don't know if I can be of any help but count me in\. In response to Thomas reply in ISO\. I agree that ISO is not the first place to create new standards\. but it is the place to bring them to get worldwide acceptance\. If we can come up with something that is agreed upon by HL7, openEHR, ISHTDO \(and maybe some other parties I'm forgetting right now\) there is a more than fair change it will get ISO acceptance\. Cheers, Stef --- ## Post #16 by @system Hi All and thanks Ed and Thomas, This sort of discussion has been going on for some time\. Describing what happened with ENV13606 \(pre\-standard\) trials which did not have archetypes and the problems with HL7 this and that is helpful to a point \- we need reality checks\. This standards domain is difficult and highly complex\. HL7 CDA provides for a document which has more than a Word file but does struggle with structured content\. openEHR struggles to get the engineering solutions, which are still complex and debated, into production\. What I do believe is that openEHR has the best way to model content at the moment\. It is not perfect, particularly as the tools are designed for clinicians\. Further, we have a Web 2\.0 enabled process to create content and I think we all know that we cannot proceed on content specification using traditional meeting or government sponsored approaches\. We also have a growing set of tools, some open source, some not, and an agreement with IHTSDO to work together on this front\. Deciding to model information as it is to be used WITHIN systems is new and not without dissent\. This approach is a threat to some in the terminology industry \(because it reduces the requirements substantially\) and to large system providers who, on the whole, dictate the environment at the moment\. It is not realistic to expect to get everyone on board\. When HL7 move to version 4 it will probably be a lot more like openEHR than version 3, but that remains to be seen\. I would love version 4 and openEHR to be the same or at least a united front\. I am not sure if that is possible within the standards funding structures that exist at the moment\. Let's think about it anyway\. Cheers, Sam --- ## Post #17 by @Stef_Verlinden1 Hear, hear\. Don't know if I can be of any help but count me in\. In response to Thomas reply in ISO\. I agree that ISO is not the first place to create new standards\. but it is the place to bring them to get worldwide acceptance\. If we can come up with something that is agreed upon by HL7, openEHR, ISHTDO \(and maybe some other parties I'm forgetting right now\) there is a more than fair change it will get ISO acceptance\. Cheers, Stef --- ## Post #18 by @William_E_Hammond Thanks for your input\. W\. Ed Hammond, Ph\.D\. Director, Duke Center for Health Informatics              Stef Verlinden              <stef@vivici\.nl>              Sent by: To              openehr\-technical For openEHR technical discussions              \-bounces@chime\.uc <openehr\-technical@chime\.ucl\.ac\.uk>              l\.ac\.uk cc                                                                                                                                                Subject              02/02/2010 05:20 Re: Interoperability with HL7              AM                                                                                          Please respond to                 For openEHR                  technical                 discussions              <openehr\-technica              l@chime\.ucl\.ac\.uk                      >                                                                             Hear, hear\. Don't know if I can be of any help but count me in\. In response to Thomas reply in ISO\. I agree that ISO is not the first place to create new standards\. but it is the place to bring them to get worldwide acceptance\. If we can come up with something that is agreed upon by HL7, openEHR, ISHTDO \(and maybe some other parties I'm forgetting right now\) there is a more than fair change it will get ISO acceptance\. Cheers, Stef > I like your reply\. I am willing to commit to putting energy behind merging > al standards groups, probably under ISO\. > > W\. Ed Hammond, Ph\.D\. > Director, Duke Center for Health Informatics > >             Thomas Beale >             <thomas\.beale@oce >             aninformatics\.com To >>                        openehr\-technical@openehr\.org > >             Sent by: cc >             openehr\-technical >             \-bounces@chime\.uc Subject >             l\.ac\.uk Re: Interoperability with HL7 >             02/01/2010 12:02 >             PM >             Please respond to >                For openEHR >                 technical >                discussions >             <openehr\-technica >             l@chime\.ucl\.ac\.uk > regarding any war \- me neither ;\-\) Ed, I hope you see that it is reasonable > to respond in some way to disinformation like 'only use openEHR if you are > trying to talk to openEHR systems' \- on an openEHR list\! Nearly the only > problem of interest in openEHR is adding semantics to existing > environments\. It is obvious by inspection that openEHR would not need to > exist in its current form in order to talk to itself\. > > There are theoretical difficulties with HL7v3 messaging & RIM, I don't > think there is any way around that, and they do manifest in practical ways; > there are also difficulties with CDA\. But above all, I still \(really, > honestly, sincerely\) want an answer from HL7 to the question: >      how can I define a piece of domain content \(microbiology result, >      Apgar result, ENT exam, etc\) once and re\-use it in multiple concrete >      technologies such as a\) XSD, various GUI forms development, various >      programming languages, and b\) for various different purposes, e\.g\. >      EHR persistence, messages, screen forms, and especially for creating >      portable queries from\. > As far as I know I can't really\. I can make an RMIM, or a CDA template, but > I can't really use these together without treating them like different data > schemas\. And I can't directly re\-use either for EHR persistence, querying, > reporting or screen display or data capture\. I am not saying that openEHR > has got every last detail on this solved, but it does have large chunks > demonstrable, including fully generated message schemas, programming > objects, querying and reporting\. The formal infrastructure is proving to be > very solid and extensible \- and yet it retains simple features like only > one XSD for all openEHR data \(well it is literally a collection of 6 or 8 > component XSDs but you know what I mean\)\. Within the openEHR framework we > can generate the equivalent of any HL7 message or CDA \- via a tool chain > using archetypes, templates and terminology\. And we can query the date with > archetype\-based queries\. > > On the other hand, HL7 has a big community, much better marketing, and > probably a better handle on use cases\. To me the question about joining > forces \(which is what we in health informatics owe the world at large, I > think\) is how it can be done: it must have technical things like: >      a solid, open formal platform framework >      a clear, useful reference model >      a single source domain modelling approach >      a solid querying methodology >      an integrated set of service definitions >      a clean way of integrating with any terminology > It must also have the qualities of a community: >      a recognised meeting place and culture >      agile but defensible governance >      buy\-in from industry >      an on\-the\-ground network of affiliates >      a wide\-ranging handle on the requirements of the domain > I would say openEHR's strengths are in the first list, and HL7's largely in > the second \- I am the first to recognise the community\-related weaknesses > of openEHR\. What the world really wants here is a\) ONE technical framework > and b\) ONE open community and governance framework\. It could be possible, > at the price of some dented egos\. History says it will remain a dream\. What > would it take to overcome that? \(Proper funding might be one answer\) > > \- thomas beale > >      Not trying to start a war, but I am disappointed at the continued >      dialog >      that is negative toward HL7\. If, in fact, openEHR has solved all of >      the >      problems of interoperability and is being picked up around the world, >      I, >      and I think, many of my HL7 colleagues will be delighted\. Very few >      of the >      members of HL7 make money from HL7, so I think our motivations are >      driven >      by our companies and the market place\. Solving the problems of >      interoperability will certainly open the door for many more important --- ## Post #19 by @Andrew_McIntyre Hello Charlie, The biggest issues with inter-operability relate to the use of Semantic attributes in both HL7 and openEHR. They are not really semantic in the SNOMED-CT sense in either format, and because they are different, inter-operability between openEHR and HL7 is difficult. OpenEHR has attributes such as "data", "state" etc and HL7 has Act Relationships that are supposed to be semantic rather than just compositional. OpenEHR also has a lot of specific CLUSTERS such as ITEM_TREE and subclasses of ENTRY such as "EVALUATION" which have semantics that are in the implicit in the model, rather than pure clinical knowledge. This makes a DCM (Detailed Clinical Models) format that both agree on a difficult proposition. There are other differences, such as the ability of HL7 Observations to have both a value and child acts via Act Relationships, where as openEHR does not have CLUSTERS with values. The best way to resolve these is to accept that openEHR and HL7 cannot use the same models without adding extra information to the format ie extending ADL or adding attributes to the RMIM. If the clinical knowledge was modelled in ISO-13606 there are only compositional attributes ie "items" and only one of them and the data structures defined require the terminology to impart the meaning and not semantic attributes. This could be translated into openEHR and HL7 in a loss less way. There are obviously some issues with the 13606 reference model, but the pure clinical content is then representable with a tree of Name=Value pairs, with the meaning in the terminology rather than the attribute names. It is also an international standard that gives a degree of certainty and stability to the format, even if its not a perfect fit for every system. I think in most cases the demographic content is able to be mapped, as people have a lot of practice at that. A bigger issue is things like Medication, which has specific classes in HL7 V2 and 3. However the ability to model clinical knowledge outside the contentious areas and represent the clinical knowledge in a standards based format that can be adapted to other formats would be a huge leap forward. It is even possible to represent this in a loss less way in HL7 v2. For things like Medication and Allergies an archetype that can be mapped to HL7 V2 and V3 Segments/classes is needed for interoperability. The use of Semantic or "named" attributes specific to a format is the major barrier to a common DCM format. The HL7 V3 assessments and scales RMIM is and example of a HL7 V3 format that is adaptable to an archetype, although it does have a cluster with a value, which would have to be mapped to the "value" ELEMENT of an archetype. The formula for calculated values is also undefined, but GELLO, which is a standard could be used for this and this is what we use with ISO-13606 archetypes. I cannot see how openEHR archetypes can be used for a general DCM format, but ISO Archetypes could, as long as they were modelled in a fashion that is neutral to final implementation format. A common format would require both sides to either map the generic structures into their own specific classes or adopt a more generic model with the semantics in the terminology. The overlap between the information model and the terminology model is probably at the heart of the conflict. Andrew McIntyre Monday, February 1, 2010, 7:33:09 PM, you wrote: --- ## Post #20 by @thomas.beale Hi Andrew, this description of 'semantic' attributes is quite useful. People should indeed realise that the named attributes in various health reference models are often semantic concepts that just happen to be defined in the information model, not a terminology. The same occurs at the class level. The point of doing this is that such models commit to some level of meaning-of-structure rather than being completely agnostic. In terms of your explanation, a few points: - all models (openEHR, ISO13606, CDA usage of RIM) provide a structural container concept, which can be understood as a 'document' or 'recording'. Classes for this purpose include COMPOSITION (= CDA Document) and SECTION, and also many classes and attributes for defining audit & context attributes. openEHR & 13606 have a similar model for this. - the openEHR reference model uses 'semantic classes', e.g. OBSERVATION, EVALUATION, INSTRUCTION, 'semantic attributes' e.g. 'CARE_ENTRY.protocol', as well as generic compositional attributes like CLUSTER.items. Some of these classes, like HISTORY and EVENT are for extremely generic concepts in science/mathematics. - the HL7 RIM uses 'semantic classes', e.g. Observation, 'semantic attributes', e.g. 'activityTime', special attributes like 'contextControlCode', 'contextConductionInd', generic compositional attributes like ActRelationship.source and target. There are some data structure classes within the HL7v3 data types, like HXIT (a generic history concept) as well as hardwired classes like Person name, address etc. - ISO 13606 uses no 'semantic' classes at the domain level - everything is just an Entry, but it does include a couple of 'semantic attributes' in the wrong place (a specific attribute should never be on a generic class) - ITEM.obs_time, ENTRY.act_status. All three approaches use some special 'programmable attributes' which are given values at archetype design time, or at runtime to provide the actual meaning of the instance: - openEHR: there is just one such attribute, LOCATABLE. archetype_node_id, which marks any object with the concept code from an archetype (thereby for example making an ELEMENT instance into a systolic blood pressure measurement) - HL7 attributes like Act.code, moodCode, classCode, levelCode etc - ISO13606 has a few attributes for this purpose: RECORD_COMPONENT.archetype_id, ITEM.item_category, CLUSTER.structure_type. Another key difference that contributes to the difficulty of mapping & harmonisation: HL7v3 uses a pervasive 'restriction' approach in all its modelling, which means that all RIM classes contain numerous attributes (in theory sufficient to cover every possible situation in the universe of healthcare), and these have to be constrained out to come up with classes that mean something for any given concrete situation - the high level classes like Act and ActRelationship don't have any meaning as such. On the other hand, openEHR and 13606 take a standard object approach to the information model, and have only very general attributes defined on general classes; more specific descendants then add relevant attributes. To give an analogy: in the HL7 approach, if you had a model of 'animals', the top class Animal would contain every kind of defining characteristic of particular animals, such as 'wing', 'claw', 'fin', 'spine', 'horn' etc, and the class Bird would be created by the removal of 'fin', 'horn' etc. These differences not just in modelling but in modelling paradigm are what make harmonisation difficult. My question is: why do we want harmonisation? What we need is a clean clear information model for the health information domain, carrying sufficient semantics to be useful, while being 'prgrammable' in some way. Trying to 'harmonise' 3 different models & theories of modelling won't achieve that, it will simply create a frankenstein. Do we need convertability? If we have a world in which all 3 of these models exist, then there is no avoiding it. The only question is whether it can be achieved in a generalised manner - e.g. a converter than can take any CDA and generate the equivalent 13606 Extrtact - or a custom ad hoc manner - i.e. every CDA => 13606 conversion requires its own converter, or, something in between. We should also be interested in the qualities of the models themselves. Many government programmes are paralysed trying to work out which one to use. In a different world, the problem could have been solved by an information model so generic as to be a 'node/arc' construct; this would be like having to build a car from individual atoms of iron rather than nuts, bolts and sheet metal. ISO 13606 has stayed more generic, based on the idea that it is a lowest common demominator model of interchange, that can't impose a view of semantics on originating systems. HL7 (both message and CDA forms) is intended to be a model of message & document interchange, and is quite generic in the sense that you have to make everything you want out of Act/ActRelationship nodes (essentially a node/arc idea). openEHR on the other hand models some of the basic structures found in science and computing, to help the definition of models. Hence in openEHR there is quite a good model of time-based data, in the HISTORY & EVENT classes. These classes allow the easy definition of structures via archetypes for: - any time series of instantaneous measurements, like vital signs - inclusion of 'interval' events, representing e.g. 4h average, max, etc Another inclusion in the model is OBSERVATION.state (also in EVENT), where the state of the subject of recording can be recorded. This enables a very clean representation of the history of events in an oral glucose tolerance test, where not only is there timing involved, but also the state of the patient at each point is key information (post fast, 1 minute post 75g glucose challenge, 1hr post 75g glucose challenge etc). As mentioned above, there are various kinds of specific attribute in HL7, including in Act descendant classes. The key question here is: how easy is it to create technology-independent models of content, based on these models? In other words, can I create a model of the many medical concepts found in clinical information in some framework based on an information model - and can I reuse that one definition for a) messages, b) screen display c) screen capture d) reporting, etc. This is what archetypes offer: a method of single-source semantic modelling. Now the choice of information model becomes critical. If the information model is just node/arc, we get no help, and we have to soft-model different ontological categories like Observation and Instruction over and over again, and build every simple common structure like 'history of events with state' from scratch every time. If it provides some of this help, then the clinical models of content don't have to re-invent such things, and life is easier. If it doesn't modellers will model all of these things differently every time, and greatly reduce the chances of the information being interoperable. One of the other key values of archetypes is that they support a coherent and portable query methodology, called Archetype Query Language - based on archetype paths. This provides a lot of power over using and reusing health data. In summary, openEHR has opted to provide some ontological and structure concepts in its information model that are common across healthcare, rather than force its archetypes to have to re-invent everything each time - in other words to standardise common structure concepts that otherwise get reinvented in incompatible ways. This is the reason that there are some hundreds of archetypes in the CKM right now, and the NHS was able to fairly quickly build over 1000 archetypes in 2007. It has proven much harder to do the equivalent thing with HL7 v3. There are RMIMs, but these contain a lot of messaging attributes and it is hard to see how to reuse them in non-message situations. One can create CDA templates, but as they rely on HL7 RIM constructs at level 3, you still get hit by the difficult RIM semantics, and lack of common structure classes. So, here is an existential question: what it the so-called Detailed Clinical Models activity trying to do in fact? Use a node/arc model and create its own domain models for everything (including having to replicate History-of-events everytime)? It could do this easily enough: just choose a model with some document/section container semantics, and a simple Cluster/Element internal structure, and then use archetyping. In the history of openEHR we were doing this in about 2002. What we found was that being too simple came with a huge cost - limited clarity, and unnecessary replication of typical structures. Over a period of some years, we improved the openEHR RM to include things that domain modellers should not have to keep re-inventing. The openEHR RM is the only model I know of that has been actively re-engineered over time to directly absorb requirements from domain modellers using it. I would suggest that DCM thinks very carefully about what its goal is, and how many years it wants to take to get there. openEHR already offers a very solid basis for doing much of what DCM could be aiming for, and could greatly reduce the time taken to make progress. - thomas beale --- ## Post #21 by @Carlos_Luis_Parra_Ca Dear All, I think that the discussion should be guided by the following assumptions: \* Society demands standardization organizations to develop interoperability standards rather than reusability standards\. \* Society demands that these standards are applicable now\. \* Society does not demand perfect standards, but standards sufficiently to allow the representation of clinical knowledge to the care continuum\. \* This should not be a story of winners and losers, it's the wrong approach\. Today our hospitals lack semantic interoperability, companies are afraid of being wrong about which option to choose, and doctors do not have all the information to make the best decisions about the health of their patients\.                 Without this perspective all the work loses its meaning                 As the Spanish proverb, "ni quito ni pongo rey pero sirvo a mi señor"\. Carlos Parra\. --- ## Post #22 by @system Dear Andrew, See some reactions in the text below. Gerard as former chairman of CEN/tc251 wg1, responsible for the EN13606 > The biggest issues with inter-operability relate to the use of Semantic attributes in both HL7 and openEHR. > > They are not really semantic in the SNOMED-CT sense in either format, and because they are different, inter-operability between openEHR and HL7 is difficult. OpenEHR has attributes such as "data", "state" etc and HL7 has Act Relationships that are supposed to be semantic rather than just compositional. OpenEHR also has a lot of specific CLUSTERS such as ITEM_TREE and subclasses of ENTRY such as "EVALUATION" which have semantics that are in the implicit in the model, rather than pure clinical knowledge. Yes. HL7 RIM based messages and EN13606 extract are different. No. Both transport the same clinical information from a proprietary system A to B. The clinical information is expressed in a limited set of expressions. Each semantic expression has one specific pattern using HL7 and another specific one using EN13606. When we think about looking at the differences between HL7 CDA and EN 13606 than we see a lot of similarities since CDA (at the semantic level) is a subset of the EN13606 part one. As chair of CENtc251 I was part of that process. > This makes a DCM (Detailed Clinical Models) format that both agree on a difficult proposition. There are other differences, such as the ability of HL7 Observations to have both a value and child acts via Act Relationships, where as openEHR does not have CLUSTERS with values. I disagree? Each DCM is expressing a limited set of semantic constructs that can be represented using a DCM reference model. This DCM Reference Model uses the same classes as EN13606/CDA to indicate the structure. And per class possible semantic constructs (also called documentation patterns) A complete DCM model defines 'MEDSPEAK'. A controlled language. Examples in other fields are AIRPSEAK (air trafiic) and SEASPEAK (sea traffic). An other terms I use is: Model of USE, Model of Documentation/Archiving, and DCM ONTOLOGY. > The best way to resolve these is to accept that openEHR and HL7 cannot use the same models without adding extra information to the format ie extending ADL or adding attributes to the RMIM. > > If the clinical knowledge was modelled in ISO-13606 there are only compositional attributes ie "items" and only one of them and the data structures defined require the terminology to impart the meaning and not semantic attributes. This could be translated into openEHR and HL7 in a loss less way. There are obviously some issues with the 13606 reference model, but the pure clinical content is then representable with a tree of Name=Value pairs, with the meaning in the terminology rather than the attribute names. It is also an international standard that gives a degree of certainty and stability to the format, even if its not a perfect fit for every system. Perhaps we do not disagree after all. One of the issues is the fact that EN13606 and therefor openEHR allows too many degrees of freedom to express the same semantic construct. The next version of EN13606 must be designed such that these degrees of freedom are reduced to none. The way to do this is via an additional accepted Model of Use (DCM Model) that defines all semantic constructs plus one mapping to the EN13606 or CDA. > I think in most cases the demographic content is able to be mapped, as people have a lot of practice at that. A bigger issue is things like Medication, which has specific classes in HL7 V2 and 3. However the ability to model clinical knowledge outside the contentious areas and represent the clinical knowledge in a standards based format that can be adapted to other formats would be a huge leap forward. It is even possible to represent this in a loss less way in HL7 v2. For things like Medication and Allergies an archetype that can be mapped to HL7 V2 and V3 Segments/classes is needed for interoperability. > > The use of Semantic or "named" attributes specific to a format is the major barrier to a common DCM format. The HL7 V3 assessments and scales RMIM is and example of a HL7 V3 format that is adaptable to an archetype, although it does have a cluster with a value, which would have to be mapped to the "value" ELEMENT of an archetype. > > The formula for calculated values is also undefined, but GELLO, which is a standard could be used for this and this is what we use with ISO-13606 archetypes. > > I cannot see how openEHR archetypes can be used for a general DCM format, but ISO Archetypes could, as long as they were modelled in a fashion that is neutral to final implementation format. It is imperative that DCM's are absolutely free to use and in the public domain. CEN/ISO and ANSI assure that with the standardisation IP rules in general. DCM's must be absolutely free from IP problems, well maintained in a formal, flexible, organisation, owned and controlled by all that use them. OpenEHR as we know it today is a private company. (See under Status: [http://www.openehr.org/about/foundation.html](http://www.openehr.org/about/foundation.html)) > A common format would require both sides to either map the generic structures into their own specific classes or adopt a more generic model with the semantics in the terminology. The overlap between the information model and the terminology model is probably at the heart of the conflict. I produced (but not published) a draft document with the DCM Ontology as addition to the EN13606 and my thoughts about the next version of EN13606. But also with my thoughts about the Boundary problem with coding systems and ontologies. In collaboration with the Technical University in Valencia we started a project to think about the next version of EN13606. For this purpose a website is created as focus point for discussions: [www.EN13606.EU](http://www.EN13606.EU) > Andrew McIntyre Gerard Freriks Electronic Record Services B.V. Ditlaar 7 NL-1066 EE Amsterdam PO Box: 376, NL-2300AJ Leiden the Netherlands **M:** +31 620347088 **E:** [g.freriks@e-RecordServices.EU](mailto:g.freriks@e-RecordServices.EU) **W**: [www.e-recordservices.eu](http://www.e-recordservices.eu/) Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- ## Post #23 by @Andrew_McIntyre Hi Gerard, I agree that we need a DCM model that is free of association with a specific messaging/document specification, but is transformable into the desired one in a reliable manner\. Currently EN 13606\-2 is the closest to this, but because it is linked to its own EHR reference model, is not free of issues\. While transformation to CDA is possible, using CDA with compositional Act Relationships, the reverse is not always possible\. eg CDA, in the form of CCD as an example, uses semantic ACT relationships in places, rather than compositional ones and EN\-13606\-2 uses only compositional ones \(ie items\) The semantic Act Relationships would need to become ?CLUSTERS in EN13606\-2\. I think a DCM format should exclude the administrative attributes, such as Author and Observation Time and leave those to the Information model\. Drawing that line is potentially tricky, but needs to be done in order to allow each Information model to do it the way it wants to\. Things like order numbers and links to orders should also stay out of the DCM model\. In the end we want the pure clinical hierarchical structure that does not conflict with the information model and ideally does not conflict with the Terminology Model\. The line between the DCM and terminology is also hard to draw as it varies depending on the ability of the terminology\. eg SNOMED\-CT is quite rich wrt its models and ICD\-X is quite poor\. A DCM optimised for SNOMED\-CT will be inadequate if the only coding system is ICD\-10\. I guess including SNOMED\-CT context structures with the option to use them for ICD\-10 and move them to the terminology for SNOMED\-CT is one possibility? 2 similar DCMs \(?archetypes\) with stated terminology affinity would be another\. wrt a "DCM Format" I am sure OWL could provide what's needed, but is not a format that widely understood and optimised for uptake\. An Archetype with a DCM Reference model would also be possible\. That reference model would not try and be a full EHR model, but the glue to join an information Model to the terminology Model and the gaps to the information models would be filled differently in different information Models\. The DCM elements may well be represented in a specific way, but they would need to be transformable back to the DCM model\. DCM models in UML and mindmaps/spreadsheets capture pieces of the puzzle but are all inadequate in some way or lack adequate constraints\. There is a project in the HL7 Patient Care committee to try and work on a DCM format\. Are you suggesting something like this? We have been using EN\-13606\-2 to structure HL7 V2 messages in Australia, and that works, but you have to design the archetypes in a neutral way\. In HL7 V2 we have managed to create the EN13606\-2 ENTRY/CLUSTER\-ELEMENT hierarchy within OBX segments and there are no Semantic attributes available \(ie Act Relationships\) so it fits well with the EN13606\-2 Model\. All the EN13606 reference model outside the COMPOSITION/ENTRY/CLUSTER/ELEMENT relationships has to be mapped, so we are in effect using EN13606\-2 as a DCM format\. A true DCM format would in my view not have those other attributes, but allow the information model to specify how to do Author, Observation date, Attestation, Patient etc etc\. As a clinician I think I can identify what the clinical model is, ie "MEDSPEAK" is\. It should be possible to transform that into any information model which then added the administrative attributes about the patient, the author and Observation date etc in its own specific way\. I appreciate this is an openEHR list, and maybe this discussion should be transferred to a DCM list, but I don't think there are enough resources to model every clinical concept in every information model and there is enormous value in a neutral DCM format\. The archetype concept is a good way to achieve this, but perhaps a generic "DCM only" Reference Model that does not try and be a EHR model would help? Andrew McIntyre Wednesday, February 10, 2010, 8:37:08 PM, you wrote: --- ## Post #24 by @Stef_Verlinden1 Hi Gerard, What has happened? For years and years you have been the initiator of many disputes between 13606/openEHR and HL7 and! now all to have become the 'enemy'. OpenEHR is a not-for profit organisation and it's knowlegde is in the open domain. If you had Googled around a litte bit you could have found the following: A company limited by guarantee is an alternative type of incorporation used primarily for non-profit organisations that require corporate status. A guarantee company does not have a [share capital](http://www! .ukincorp are-capital.html), but has members who are guarantors instead of shareholders. The guarantors give an undertaking to contribute a nominal amount towards the [winding up of the company](http://www.ukincorp.co.uk/s-1C-uk-company-dissolution-and-restoration.html) in the event of a shortfall upon cessation of business. It cannot distribute its profits to its members, and is therefore eligible to [apply for charitable status](http://www.ukincorp.co.uk/?s=R&p=uk_chr_1_a) if necessary.&n! bsp; So I would like you to withdraw this unfunded accusation or provide some solid facts to prove the contrary. This really doesn't help the discussion. I do like the fact that you've turned around and see opportunities to harmonize HL7, 13606 and openEHR, so let's keep working on that track. Cheers, Stef --- ## Post #25 by @Stef_Verlinden1 For one or another reason a part of the text in my reply is 'meshed' up when I receive it back via the mailinglist. The first sentence of my reply was intended to be: What has happened? For years and years you have been the initiator of many disputes between 13606/openEHR and HL7 and now all over sudden openEHR seems to have become the 'enemy'. I hope it shows up correctly this time. Does anybody know why/how this 'mesh-up' happens? Begin doorgestuurd bericht: --- ## Post #26 by @system > It is imperative that DCM's are absolutely free to use and in the public domain. CEN/ISO and ANSI assure that with the standardisation IP rules in general. > DCM's must be absolutely free from IP problems, well maintained in a formal, flexible, organisation, owned and controlled by all that use them. > OpenEHR as we know it today is a private company. (See under Status: [http://www.openehr.org/about/foundation.html](http://www.openehr.org/about/foundation.html)) It is not the juridical status of a company that makes the difference for the IP-status of something. If an organization is not-for-profit or for-profit, both can issue all kinds of IP-licenses. The company form has nothing to do with the licenses it issues Bert --- ## Post #27 by @system Dear Stef, It is simple. Customers demand Archetypes that are completely free ti use in a commercial product. All openEHR artifacts have an IP owned by a a not-for-profit company with two owners. For academic use it is free. But for commercial use things are not free. Archetypes/Templates and Detailed Clinical Models must be completely public, owned democratically by all. The present situation is not good for business at all. I'm as a fervent supporter of the ideas behind EN13606 as ever. We need requirements for DCM's (and Archetypes) that go beyond the present ones. With regards, Gerard --- ## Post #28 by @system Bert, There is only one answer. Hospitals we talk with have problems with the way IP is handled by openEHR. IP owned by two organisations (One UCL and the other Ocean Informatics) they consider not PUBLIC. I agree that the form of the company is not the issue. What is important who controls the IP. All Archetypes/Templates/ DCM's must be in the public domain, as is language, as is HL7 CDA, as is EN13606, as are ISO standards, XML, etc, etc. Gerard --- ## Post #29 by @Stef_Verlinden1 I agree, but the way Gerard puts it, seems to imply it does. About the IP licenses. The OpenEHR board issued an e-mail on Okt 2nd 2099 in which they announce that: '.... We have discussed the issues set out above, at length, and they cannot be quickly decided upon, safely. We view it as our role, at this stage, to publish here an interim statement of the policy issues we have identified and the direction of travel we are following, for the Foundation, which is as follows: 1. _**To meet immediate needs, we are minded to publish archetypes managed at**_ [_**http://www.openEHR.org/knowledge**_](http://www.openEHR.org/knowledge) _**from the Foundation under the Creative Commons license – specifically the**_ [_**Attribute and ShareAlike**_](http://creativecommons.org/licenses/by-sa/3.0/) _**(CC-BY-SA).**_ This is the same license that Wikipedia is using. 1. _**We also propose, at a minimum, that the copyright of all archetypes managed at**_ [_**http://www.openEHR.org/knowledge**_](http://www.openEHR.org/knowledge) _**should be assigned to the Foundation.**_ This is needed to ensure that the Foundation can give permission to others to adapt the work (see the CC license for details). _**We will continue to listen and consult on the wider issues discussed in this interim statement. We must align the Foundation’s approach with the requirements and plans of our partners in IHTSDO and EuroRec and with the development of the new governance framework and business plan now needed for the Foundation.**_ We will keep the plan under close review over the period ahead, as we work with EuroRec, IHTSDO and others to fund a major experimental and clinically driven project for clinical content quality assurance, embracing archetypes and terminology. This interim statement is now on the wiki at [http://www.openehr.org/wiki/display/oecom/Archetypes+-+Copyright+and+Licensing](http://www.openehr.org/wiki/display/oecom/Archetypes+-+Copyright+and+Licensing). Subject to any necessary rethinking as a Board, arising from responses we receive before December 1st 2009, we plan that it will become official *open*EHR Foundation policy from January 1st 2010, when a set of rules covering its implementation will also be published. We will also consider whether and in what form we might usefully propose guidelines for how copyright in archetypes might best be managed in other contexts, such as a) when managed by governments on national or regional servers, b) when managed privately by healthcare organisations, professional bodies or companies, and c) when managed experimentally, eg in research programmes.' As far as I'm aware the above has become openEHR foundation policy as of January 1st 2010. I have to admit that these changes in the IP status can't be found on the openEHR homepage at this moment. Can somebody please place the renewed 'Statement on Copyright and Licensing of Archetypes' at a prominent place at the openEHR website. Cheers, Stef --- ## Post #30 by @system Gerard, It is possible to reject non\-free archetypes and replace them by free archetypes\. We have seen this mechanism many times, mostly the open standard wins, even when it is technically slightly inferior, the openness is much more important\. Than the non\-free\-snake will often byte its own tail, and the open standard will become the market\-standard\. There is no need for discussing this issue, anyone can start immediately with creating free archetypes\. But is it really the case that the published archetypes are non\-free? Because the company\-form cannot indicate this, we need to read the accompanying licenses\. In the Netherlands IP\-free materials must have a positive indication\. Everything which has no indication must be regarded as non\-free IP\. Anyone have a clue about the archetypes form the OpenEHR\-website? Op 10\-02\-10 14:26, Gerard Freriks schreef: > Dear Stef, > > It is simple\. > Customers demand Archetypes that are completely free ti use in a > commercial product\. > All openEHR artifacts have an IP owned by a a not\-for\-profit company > with two owners\. > For academic use it is free\. But for commercial use things are not free\. Can you give a link the the license which says so? Bert --- ## Post #31 by @system Op 10\-02\-10 14:32, Gerard Freriks schreef: > Bert, > > There is only one answer\. > Hospitals we talk with have problems with the way IP is handled by > openEHR\. > IP owned by two organisations \(One UCL and the other Ocean > Informatics\) they consider not PUBLIC\. What is the problem, and on what is the problem\. On the archetypes? Many come from NHS, as I remember, are they also a problem? We must specify this problem before discussing it\. > I agree that the form of the company is not the issue\. > What is important who controls the IP\. Not who controls the IP is important, but first the IP\-license, and eventually \(if not free licensed\), second, who\. It is an important issue you bring up Gerard, i am glad you did\. I think clarity in this is very important\. But it is also late that you bring it up, why not two years ago? Has something changed? Bert --- ## Post #32 by @Stef_Verlinden1 If you read my reply to Bert, which probably crossed your response, you can see that all archetypes are available under CC\-BY\-SA license\. Unofficially since Okt 2009 and officially since Jan 1th 2010 Do you agree that this means that all openEHR archetypes are in the public domain and that since these archetypes fall under the CC license is really doesn't matter who controls them? Cheers, Stef --- ## Post #33 by @system Stef, It is a good step\. But not sufficient\. That OpenEHR artifacts are published with such a Creative Commons License policy attached to it is a good thing, I agree\. But when a new Reference Model, Archetype Model, Template models change and are published that decision is made by the owners because they own the IP and can issue any new License policy they wish\. Our customers do not want to be held hostage when they invest in the exiting new technology based on En13606/openEHR\. They are taking enough risks already, they feel\. Gerard --- ## Post #34 by @system Op 10-02-10 15:35, Gerard Freriks schreef: > ``` > Stef, > > It is a good step. > But not sufficient. > > ``` > ``` > That OpenEHR artifacts are published with such a Creative Commons License policy attached to it is a good thing, I agree. > But when a new Reference Model, Archetype Model, Template models change and are published that decision is made by the owners because they own the IP and can issue any new License policy they wish. > > Our customers do not want to be held hostage when they invest in the exiting new technology based on En13606/openEHR. > They are taking enough risks already, they feel. > > ``` Then minutes ago you did not now about this, you were talking about the organization-model which would impose IP? No that is proven wrong and still you know it is not sufficient? How do you know what you customers feel about this new knowledge you just (ten minutes ago) heard of? I come back to this later, because your remarks do raise questions. Anyone considering using OpenEHR, read carefully It looks to me that you misunderstand IP-laws. It is also impossible to attach IP to an RM-implementation. It is not patented, so anyone can build an implementation. Same story for the Archetype Model. You can only protect an idea by patents, on no other way. You can protect an implementation of an (ICT) idea by copyright on sourcecode, but that only applies to the specific implementation. Is there a patenting application? Do you know, does it seem likely? To me it does not. Let me explain: As soon as the OpenEhR foundation would consider that, it would be a big problem because many people volunteered, and I think OpenEHR would be quickly out of business. In my opinion it is impossible to patent it because many people volunteered, and a lot can be considered as "prior art" So if it is not patented, anyone can build an implementation without considering any IP. That is very sure. I have dealt a lot with patents. Anyone who does business with me can go to a lawyer to check, and if it is not true what I write in here, I pay the lawyer-bill. Conclusion: OpenEHR-foundation has no IP on implementations. Maybe there is IP on the published archetypes, IP in the form of copyright. I don't know. But if that is the case anyone is free to create his own archetypes, IP-free. end of subject It looks to me as if you are looking for ways to publicly discouraging hospitals to use OpenEHR. Why is that? What is the matter Gerard? You used OpenEHR for years, you invested lots of time and money, even build your own implementation, and now you discovered that you cannot use it? That you have to pay? Where you sleeping that you did not think about these urgent IP-questions you bring up here? A strange story. regards Bert Verhees --- ## Post #35 by @system Please consider the previous as not being send. Thank you Op 10-02-10 15:35, Gerard Freriks schreef: > ``` > Stef, > > It is a good step. > But not sufficient. > > ``` > ``` > That OpenEHR artifacts are published with such a Creative Commons License policy attached to it is a good thing, I agree. > But when a new Reference Model, Archetype Model, Template models change and are published that decision is made by the owners because they own the IP and can issue any new License policy they wish. > > Our customers do not want to be held hostage when they invest in the exiting new technology based on En13606/openEHR. > They are taking enough risks already, they feel. > > ``` Then minutes ago you did not now about this, you were talking about the organization-model which would impose IP? No that is proven wrong and still you know it is not sufficient? How do you know what you customers feel about this new knowledge you just (ten minutes ago) heard of? I come back to this later, because your remarks do raise questions. (IP = intellectual property) Anyone considering using OpenEHR, read carefully It is impossible to attach IP to an RM-implementation to build. It is not patented, so anyone can build an implementation. Same story for the Archetype Model. The only thing that can carry IP is a RM-implementation (copyright) but that is as with any software-product you license. You can only protect an idea by patents, there is no other way. You can protect an implementation of an (ICT) idea by copyright on sourcecode, but that only applies to the specific implementation. So we must ask: Is there a patenting application? Do you know, does it seem likely? To me it does not. Let me explain: As soon as the OpenEhR foundation would consider that, it would be a big problem because many people volunteered, and I think OpenEHR would be quickly out of business. In my opinion it is impossible to patent it because many people volunteered, and a lot can be considered as "prior art". We also have the lache-doctrine. You cannot patent anything which you let people use for years. I think an patent-application on the OpenEHR: RM or AOM is impossible. So if it is not patented, anyone can build an implementation without considering any IP. That is very sure. I have dealt a lot with patents. Anyone who does business with me can go to a lawyer to check, and if it is not true what I write in here, I pay the lawyer-bill. Conclusion: OpenEHR-foundation has no IP on implementations. Maybe there is IP on the published archetypes, IP in the form of copyright. I don't know. But if that is the case anyone is free to create his own archetypes, IP-free. end of subject It looks to me as if you are looking for ways to publicly discouraging hospitals to use OpenEHR. Why is that? What is the matter Gerard? You used OpenEHR for years, you invested lots of time and money, even build your own implementation, and now you discovered that you cannot use it? That you have to pay? Where you sleeping that you did not think about these urgent IP-questions you bring up here? A strange story. regards Bert Verhees --- ## Post #36 by @system Op 10-2-2010 17:24, Bert Verhees schreef: --- ## Post #37 by @system I wrote it confusing, so I try again, it is because English is not my first language and the subject is a bit complicated to explain in another language.. There is no IP-claim on any part of the kernel-concept, except from on the literally text of the specification (copyright) So anyone building a kernel can license it to his customers as he wants, open source, closed source, whatever. There is no payment at all required to the OpenEHR-foundation. When using sourcecode trom the OpenEHR-website, one must comply to the terms agreed when using that sourcecode. That can differ. But one can always (without any payment done to who-ever) write a kernel from scratch and sell it to who-ever he wants for any price which seems reasonable. I hope it is clear now. If someone disagrees please report this. Also if Gerard Freriks disagrees I would like him to report this, and discuss this. Thanks Bert Verhees Op 10-2-2010 17:24, Bert Verhees schreef: --- ## Post #38 by @Koray_Atalag Hi All, interesting discussions but I am afraid it does not take use anywhere… Yes we all need (we=all of us) some better means to develop health information systems; not only limited to EHR space but the whole continuum including the long waited clinical applications which would help doctors and other healthcare professionals make informed decisions etc. etc. I think what we are all up to is first a solid methodology to build better systems – no brainer ha? OK look at other domains, well technical mostly, Telecom, Tourism, Marine, even Entertainment and eGovt. As far as I know (I may be slightly wrong though) neither of these is based on “special home delivery” standards, BUT have adopted development methodologies which worked for everybody – ultimately benefiting the consumer. Why on earth we are going down this pathway? It is absolutely silly to have all these standards in same direction with slight differences. I don’t understand how public money is spent so irresponsibly…. Why don’t we just build systems with what we have and then drive the standardisation process with real evidence…an evolutionary rather than regulatory path. As a developer myself when I see ISO, CEN etc. imposing constraints on me just because they are strong and have powers I feel offended. How many of those people have really built systems, or let alone sat at the same table with clinicians to talk about what they need, gone through procurement processes with RFP’s that don’t even mention about interoperability? I wonder… Having said these, I will soon publish the results of my research on software maintainability of openEHR based vs. classical OO/Procedural with RDMS model by building a full working application with C# .Net. The implementation is almost complete and I am expecting to have initial results by March. So let’s see if openEHR really works and future-proof! These will be quantitative evaluation results by employing formal software measurement. We need evidence gentlemen, why don’t we focus on that first. IP is nonsense wrt. Archetypes and openEHR and everybody knows that. So what are the vendors and governments waiting for??? EVIDENCE!!! Cheers, -koray --- ## Post #39 by @thomas.beale > ``` > I think a DCM format should exclude the administrative attributes, > such as Author and Observation Time > ``` Andrew, I could agree in principle, but how could Observation time be an 'adiministrative' attribute? > ``` > and leave those to the Information > model. Drawing that line is potentially tricky, but needs to be done > in order to allow each Information model to do it the way it wants to. > Things like order numbers and links to orders should also stay out of > the DCM model. > > In the end we want the pure clinical hierarchical structure that does > not conflict with the information model and ideally does not conflict > with the Terminology Model. > > ``` is DCM now trying to be totally model-agnostic? > ``` > The line between the DCM and terminology is also hard to draw as it > varies depending on the ability of the terminology. eg SNOMED-CT is > quite rich wrt its models and ICD-X is quite poor. > ``` well... sometimes. Have a look here for SNomed's context model - it is in poor shape... [http://www.openehr.org/wiki/display/term/Information+Model+-+Terminology+Equivalence](http://www.openehr.org/wiki/display/term/Information+Model+-+Terminology+Equivalence) > ``` > A DCM optimised for > SNOMED-CT will be inadequate if the only coding system is ICD-10. I > guess including SNOMED-CT context structures with the option to use > them for ICD-10 and move them to the terminology for SNOMED-CT is one > possibility? 2 similar DCMs (?archetypes) with stated terminology > affinity would be another. > > ``` many countries are using things like ICD9 or 10, ICPC+, vocabularies for nursing, procedures, devices, prostheses and drugs. Snomed actually doesn't figure that highly in the list of currently used terminologies - i.e. actually in production. Re-imbursement-related terminologies and vocabularies are far more important right now. So optimising DCM (whatever DCM now is) for Snomed would be quite wrong-headed, unless DCM is also destined for 'in 5y+' time. > ``` > I appreciate this is an openEHR list, and maybe this discussion should > be transferred to a DCM list, but I don't think there are enough > resources to model every clinical concept in every information model > and there is enormous value in a neutral DCM format. The archetype > concept is a good way to achieve this, but perhaps a generic "DCM only" > Reference Model that does not try and be a EHR model would help? > > > ``` I am still interested to see what the concrete objections to the openEHR reference model classes as the basis forDCM archetypes are. - thomas beale --- ## Post #40 by @thomas.beale --- ## Post #41 by @thomas.beale yes that needs to be done ASAP. I had forgotten about the Jan 1st condition. - thomas beale --- ## Post #42 by @Andrew_McIntyre Hello Thomas, Thursday, February 11, 2010, 8:24:53 AM, you wrote: >
| On 10/02/2010 12:00, Andrew McIntyre wrote:

I think a DCM format should exclude the administrative attributes,
such as Author and Observation Time

Andrew,

I could agree in principle, but how could Observation time be an 'adiministrative' attribute? | > - | - | The wording is probably wrong, its an attribute that is expected to be in the information model and how its there is not something a DCM needs to worry about. A "Follow up date" might belong in the DCM. In reality its a line that has to be drawn based on what is expected of an information model of the target systems. That is a vague line for sure but if u look at the dominant few information systems it can be drawn easily for many attributes. >
|

and leave those to the Information
model. Drawing that line is potentially tricky, but needs to be done
in order to allow each Information model to do it the way it wants to.
Things like order numbers and links to orders should also stay out of
the DCM model.

In the end we want the pure clinical hierarchical structure that does
not conflict with the information model and ideally does not conflict
with the Terminology Model.


is DCM now trying to be totally model-agnostic? | > - | - | Unless everyone wants to throw away their model and start afresh it has to be. Currently DCM is modelling in UML, mindmaps etc etc and they cannot be transformed in any algorithmic way unless they are constrained. They are however trying to be model agnostic currently. >
|

The line between the DCM and terminology is also hard to draw as it
varies depending on the ability of the terminology. eg SNOMED-CT is
quite rich wrt its models and ICD-X is quite poor.

well... sometimes. Have a look here for SNomed's context model - it is in poor shape... [http://www.openehr.org/wiki/display/term/Information+Model+-+Terminology+Equivalence](http://www.openehr.org/wiki/display/term/Information+Model+-+Terminology+Equivalence)

A DCM optimised for
SNOMED-CT will be inadequate if the only coding system is ICD-10. I
guess including SNOMED-CT context structures with the option to use
them for ICD-10 and move them to the terminology for SNOMED-CT is one
possibility? 2 similar DCMs (?archetypes) with stated terminology
affinity would be another.


many countries are using things like ICD9 or 10, ICPC+, vocabularies for nursing, procedures, devices, prostheses and drugs. Snomed actually doesn't figure that highly in the list of currently used terminologies - i.e. actually in production. Re-imbursement-related terminologies and vocabularies are far more important right now. So optimising DCM (whatever DCM now is) for Snomed would be quite wrong-headed, unless DCM is also destined for 'in 5y+' time. | > - | - | Yes I agree, its a question of the "lowest common denominator issue" Using a lowest common denominator does reduce the value of SNOMED-CT and many large realms have a license. There are some moves to allow (SNOMED-CT + information model attributes + logic) = Transformability to classifications which is usually the billing terminology. Some sort of "adapter pattern" to allow other terminologies could reduce the impact of allowing the use of less capable terminologies in some realms. Its not easy, but I would hate to give up the semantics that SNOMED-CT give to allow another terminology to be used in a realm that I don't interact with. I appreciate SNOMED-CT is not perfect, but it does have some very powerful features. >
|

I appreciate this is an openEHR list, and maybe this discussion should
be transferred to a DCM list, but I don't think there are enough
resources to model every clinical concept in every information model
and there is enormous value in a neutral DCM format. The archetype
concept is a good way to achieve this, but perhaps a generic "DCM only"
Reference Model that does not try and be a EHR model would help?



I am still interested to see what the concrete objections to the openEHR reference | > - | - | >
| model classes as the basis forDCM archetypes are. | > - | - | openEHR is a EHR system and its archetypes often include things like Result identifiers and order numbers and things that are built into the information model on other systems. openEHR has semantics in attributes and classes, as does HL7 V3 and they are different. Ideally a DCM format would exclude administrative attributes such as order numbers and result identifiers and not use semantic attributes and classes. It would be agnostic on patient identification and demographics etc etc A DCM could have attributes that allow automatic mapping to specific classes in a specific model. A DCM format on its own would not be the basis of an EHR, but the repository of the clinical knowledge alone and would be transformable, perhaps with a requirement of checking a few option checkboxes, into multiple models. The concept of two level modelling perhaps needs to be 3 level, 1. Information System 2. Glue layer 3. DCM Model In openEHR a DCM-> OpenEHR transform could combine 2 & 3. I guess its a question of how much value is placed on inter-operability between systems as waiting for one to become a mono-culture may require patience measured in geological time. Our own personal focus is mostly on HL7 V2 as that is likely to persist for a long time in Australia. However its the models that add the eHealth value, not the format that its currently held in. Andrew McIntyre --- ## Post #43 by @thomas.beale > Re: Fw: Interoperability with HL7 > I think a DCM format should exclude the administrative attributes, > such as Author and Observation Time > Andrew, > I could agree in principle, but how could Observation time be an 'adiministrative' attribute?    > The wording is probably wrong, its an attribute that is expected to be in the > information model and how its there is not something a DCM needs to worry about\. > well actually, I would agree with this, but whether such an attribute is in the information model depends on teh information model\. This attribute happens to be in openEHR, along with other related attributes to do with Observation timing\. This was precisely my point about why the reference model matters \- what does it supply, what does it not supply? HL7v3 and 1s013606 don't supply Event\.offset, or width for example\.\.\.\. so clearly DCM models have to assume a reference model, else they have no formal foundation\. A "Follow up date" might belong in the DCM\. In reality its a line that has to be drawn based on > what is expected of an information model of the target systems\. That is a vague line for sure but > if u look at the dominant few information systems it can be drawn easily for many attributes\. indeed\. This is exatly what DCM needs to do \- to decide what 'information model' it is usiing\. openEHR archetypes for example assume a reduced version of the openEHR RM\. Any archetype has to assume someting, else it is all on shifting sands\. > and leave those to the Information > model\. Drawing that line is potentially tricky, but needs to be done > in order to allow each Information model to do it the way it wants to\. well \- I could agree with true administrative attributes, such as version & audit innformation\. But attributes relating to observation timing, structure, order timing, conditionality, action timing & state machine states\.\.\.\.\. these are not administrative attributes\. Things like order numbers and links to orders should also stay out of > the DCM model\. this might be a reasonable position, but on the other hand you might want to build an archetype that says that an order number is mandatory \- how would you do this? In the end we want the pure clinical hierarchical structure that does > not conflict with the information model and ideally does not conflict > with the Terminology Model\. it depends on what you mean by 'pure hierarchy' \- if you literally mean node/arc, then you are forcing modellers to recreate basic data structures all the time, like 'list' used in Apgar, or the timing and state information used to define OGTT\. These things are basic; if you force every DCM model to reinvent this, you are inviting a whole raft of errors and problems that don't need to exist\. \(more comments later \- on horrible webmail right now\) --- ## Post #44 by @system Hi\! Tom Beale wrote: > is DCM now trying to be totally model\-agnostic? Andrew McIntyre wrote: > Unless everyone wants to throw away their model and start afresh it has to be\. \[\.\.\.\] Andrew McIntyre wrote: > The concept of two level modelling perhaps needs to be 3 level, > > 1\. Information System > 2\. Glue layer > 3\. DCM Model I wasn't involved in medical informatics at the age of the \(friendly\) dinosaurs when Arden Syntax was developed as way to represent detailed knowledge and rules for decision support, but parts of the research group were\. If I interpret them correctly, knowledge representation worked pretty good in the Arden based "medical logic modules", the problem was the cost and resource consumption required to make what you call "2\. Glue layer" since the layer "1\. Information System" was so different in different systems\. In the Arden days I believe a lot of the "glue" was called "data dictionary", neat services that you could ask for things like "latest fasting glucose value"\. As you can imagine this dictionary will be hosting a lot of complexity and development/maintenance costs\.\.\. A good paper describing parts of this is: Desperately seeking data: knowledge base\-database links G Hripcsak, SB Johnson, PD Clayton http://scholar.google.com/scholar?cluster=13853775547974845989 http://www.ncbi.nlm.nih.gov/pubmed/8130552 One way of looking at openEHR is that it is trying to achieve semantic coherence at level "1\. Information System", and if the detailed clinical models \(3\) are done using archetypes, then no "glue layer" is needed \(or the glue to e\.g\. decisions support can be AQL\-queries reusable between systems\)\. A model agnostic DCM \(in practice probably a DCM having it's own internal model\) can be useful in order to gather requirements, but I doubt that anybody will be able to invent general algorithms that can be used to automatically transform it to something that can be used in all information systems\. Instead manual reinterpretations will be necessary \- and BANG \- you are back at the "Desperately seeking data"\-problem and associated costs\. So yes, mindmap/UML\-model\-agnostic DCMs can be useful for requirements gathering, somewhat independent of information systems/specifications, if the people paying for this find it to be a useful exercise and are then willing to fund the manual transformation to archetypes, HL7 etc afterwards\. If a country/region on the other hand already has decided to use a specific information system model \(e\.g\. openEHR/13606\) then they might consider it wiser to spend the money on doing the detailed clinical modeling directly as templates and archetypes and avoid the extra reinterpretation cost/time/ambiguities\. I guess the same goes for HL7\-based thinking, except that the system owners will need to do one more reinterpretation anyway to map between HL7 and the "1\. Information System", but modelling directly using HL7\-building blocks instead of a model agnostic DCM will at least save them one reinterpretation\. I am curious; who is the driving force behind a model agnostic DCM? Is it the same force that will take the costs for the "2\. Glue layer"? Another question: Will it be cheaper to manually reinterpret from a "model agnostic" DCM to both HL7 and openEHR, than it would be to manually reinterpret from a openEHR\-based DCM to HL7 or from a HL7\-based DCM to openEHR? Personally I am working partly with EHR overviews, and from a practical point of view the restrictions/guidance from openEHRs information models regarding e\.g\. recording of timepoints are a true blessing\. I now know where to find many important timepoints without having to manually adjust to every single archetype/DCM\. I see it as another angle of the "Desperately seeking data"\-issue\. The same goes e\.g\. for finding the coarse grained state of care processes \(due to the built in state machine scaffolding\)\. Best regards, Erik Sundvall erik\.sundvall@liu\.se http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-286733 \(Mail & tel\. recently changed, so please update your contact lists\.\) --- ## Post #45 by @system Hi\! > As far as I'm aware the above has become openEHR foundation policy as of > January 1st 2010\. I have to admit that these changes in the IP status can't > be found on the openEHR homepage at this moment\. Can somebody please place > the renewed 'Statement on Copyright and Licensing of Archetypes' at a > prominent place at the openEHR website\. > yes that needs to be done ASAP\. I had forgotten about the Jan 1st condition\. And \_please\_ make them CC\-BY \_not\_ CC\-BY\-SA\! I still have not heard any well grounded non\-confused good arguments why SA would help the openEHR hosted collection of archetypes more than it would hurt it\. When it comes to software it's tricky enough to know what share\-alike \(SA\) means when "linking" or "using" code that is LGPL, MPL etc in a closed source system\. It works somewhat well because there is a fairly common understanding of the difference between calling a method in a class and on the other hand copying, inheriting from or modifying a class\. We don't want the techno\-juridical mess of trying to figure out what SA means e\.g\. in the context of building archetype\-based GUI\-stubs, forms etc\. in proprietary systems\. Companies want to avoid risk\. SA\-archetypes would be a risk in this context until proven in court not to be \(courts in every country where the company is working\)\. That risks setting back trust in openEHR a couple of years\. \(And no Sam, SA won't protect anything from stupid patenting claims, the possibility of showing well published prior art will though\.\.\.\) Best regards, Erik Sundvall erik\.sundvall@liu\.se http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-286733 \(Mail & tel\. recently changed, so please update your contact lists\.\) --- ## Post #46 by @thomas.beale As I have probably said before, I don't have the time or expertise to personally work out questions of CC\-BY versus CC\-BY\-SA, I just have one request: could people who have points to make about this consider updating the page http://www.openehr.org/wiki/display/oecom/Archetypes+-+Copyright+and+Licensing so that we have a clear exposition of the various points of view\. It may be that a legal professional at UCL or elsewhere could be solicited for an opinion \- but they would need something to read\. In any case, if it is the online community who makes the decision, I think we need a clear summary of the positions\. Maybe Erik you could take over the page initially to just set out your arguments so we can refer to them\. I have to admit that Eriik's basic argument seems solid to me: the link between archetypes \(as opposed to templates\) and final software or other artefacts is somewhat distant, and I think trying to promulgate rights and conditions of use through a large, uncontrollable and vague network of intermediate artefacts and organisations\.\.\.\. It would be nice to resolve this last details ASAP, so we can announce the decision, and change the archetypes accordingly to have the correct license\. \- thomas beale --- ## Post #47 by @thomas.beale > >
|


I am still interested to see what the concrete objections to the openEHR reference | > > - | - | > > >
| model classes as the basis forDCM archetypes are. | > > - | - | > > openEHR is a EHR system and its archetypes often include things like Result identifiers > and order numbers and things that are built into the information model on other systems. some such numbers are part of the openEHR reference model, but even where they are included in openEHR, they are in dedicated archetypes, mostly a CLUSTER archetype that is used to populate COMPOSITION.context. The Observation lab archetype has in its protocol attribute some order / filler id attributes. Other than that, as far as I know the occurrence of such ids inn openEHR archetypes is almost non-existent (might be in a few instructions). So here I would say two things: if 2% of openEHR archetypes have such ids, DCM has discounted the use of openEHR based on this? Secondly there has been discussion of included order/filler ids in the openEHR RM, which would remove even these identifiers. While I get the gist of the objection, I have to say it is very unconvincing (given the very low incidence of the elements you refer to) as a reason for DCM to avoid using openEHR archetypes, and instead re-engineer all the same semnatics in a different way. Do people in DCM have a lot more free time than the rest of us? > openEHR has semantics in attributes and classes, as does HL7 V3 and they are different. for very good reasons ;-) > Ideally a DCM format would exclude administrative attributes such as order numbers and > result identifiers and not use semantic attributes and classes. see previous post about 'semantic' attributes and classes. If you don't use any, then you have no foundation to do numerous simple things, and they will all get soft-modelled in non-interoperable ways. DCM will create more of the problem is is supposed to be solving. That is going to retard the health IT domain even more. > It would be agnostic > on patient identification and demographics etc etc A DCM could have attributes that > allow automatic mapping to specific classes in a specific model. > > A DCM format on its own would not be the basis of an EHR, but the repository of the > clinical knowledge alone and would be transformable, perhaps with a requirement of > checking a few option checkboxes, into multiple model here is the real nub of the problem. There is no way this is going to happen with 'checking a few option checkboxes'. A HL7v3 Act object has 22 attributes, and an ActRelationship has 18. A microbiology result has 40 logical nodes, i.e. 40 Act objects, and by implication some 40 ActRelationship objects. This is 22 x 40 + 18 x 40 = 1600 attributes. The source DCM (if it is even vaguely like the microbiology archetype will have 40 nodes, but only about 2-3 attributes per node or less - say 120 attributes. And the mapping into HL7 is not simple; you have to set things like all the type/mood/class codes, and esoteric things like contextconduction... If the DCM model is what I would consider 'sensible' then mapping to openEHR should be quite a bit simpler, but every difference you create (e.g. removing all inbuilt timing structures) just complicates things, and it will quickly get out of hand. Mistakes will be made by whichever users do this manual transformation; it will require reviewing, and in the end it won't be clear if the mapping has been correct in all cases. I would say (without trying to be alarmist) that here is where DCM could die: even if it creates a lot of decent models (and even accepting the extra effort to reconstruct all the missing support that the openEHR RM supplies), the transformation to target concrete models will be error-ridden and complex. This does not look like an attractive path to me. In fact, in pure engineering terms, you would be safer to start with openEHR archetypes (at least these are implemented and tested / implementable / testable) and generate DCM models out of the archetypes, if you really want 'model agnostic' pure hierarchies. > The concept of two level modelling perhaps needs to be 3 level, > > 1. Information System > 2. Glue layer > 3. DCM Model > > In openEHR a DCM-> OpenEHR transform could combine 2 & 3. > > I guess its a question of how much value is placed on inter-operability between > systems as waiting for one to become a mono-culture may require patience it doesn't require a monoculture in my experience. It is certainly possible to accommodate HL7v2, CDA, other formats but only do one set of archetypes. The current DCM strategy I think is most likely to lead to a lot of a) re-inventing the wheel and b) a set of models that remain largely disconnected from real systems, and there fore risk being wasted effort. - thomas --- **Canonical:** https://discourse.openehr.org/t/interoperability-with-hl7/14960 **Original content:** https://discourse.openehr.org/t/interoperability-with-hl7/14960