openEHR Transition: two procedural and one licensing question
Hi Tom It is normal practice with CC to include clarifications and the whole structure of the license is designed to do this. Let's stay with the issue of how we stop someone copyrighting and charging for a specialised archetype? Or a template that is fundamental to health care (like an antenatal visit)? Cheers, Sam -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Thomas Beale Sent: Thursday, 8 September 2011 10:30 AM To: openehr-technical at openehr.org Subject: Re: openEHR Transition: two procedural and one licensing question On 07/09/2011 21:46, Sam Heard wrote: Thanks Stef The previous Board did not want to make an error and use too loose a licence given that there is no going back. Our concern is that someone could specialize an archetype and claim copyright, or create a template and do the same. It is our intention at this stage to have a specific clause in the licence that limits it to derived archetypes and templates. I don't think actually changing the text of any accepted, well known license is a good idea at all - then it becomes something for which no legal analysis is available, and won't be trusted by anyone. Instead, openEHR should simply state which kinds of artefacts require which kinds of license (if any). - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
openEHR Transition: two procedural and one licensing question
Well that may be true but government agencies and companies will want to know that no one has recourse to legal action if they use an archetype. Cheers Sam Sent from my phone On 09/09/2011, at 8:21 AM, Timothy Cook timothywayne.cook at gmail.com wrote: On Thu, Sep 8, 2011 at 16:54, Sam Heard sam.heard at oceaninformatics.com wrote: Hi Tom It is normal practice with CC to include clarifications and the whole structure of the license is designed to do this. Let's stay with the issue of how we stop someone copyrighting and charging for a specialised archetype? Or a template that is fundamental to health care (like an antenatal visit)? Maybe that isn't such a bad thing. They are only roping themselves into their own corner. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
EN/ISO 13606 openEHR - harmonisation possibilities
, and that people working with openEHR can use tooling that is currently 13606 ADL specific. o *shared archetypes*: if the reference models were merged then '13606 archetypes' and 'openEHR archetypes' are just the same thing - it is just a question of different parts of the same reference model being archetyped. How could we go about this work? * we can all run back to our comfort zones and stick with our current models, and make the usual half-hearted attempt at harmonisation within the official standards processes, OR * *we could, starting today, develop a hybrid RM*, using the schema definition capability of the ADL Workbench, and analyse it, build some test archetypes against it and so on. In this way, we could come up with a proposal that could more or less be *directly used by the ISO process *to update 13606. o now, doing this is not just a case of - let's build a new model - we probably need a strategy where copies were made of both the current 13606 and current openEHR models, and agreed changes applied to each that brought them closer together, with the impact of the changes being known for existing users of the current models. But with a bit of discipline, I think it is doable. At this point, I would like to see what interest there is in an initiative like the above. If there is interest, we could create a dedicated mailing list and project workspace for it, and start to do some work on it. So - what are people's thoughts on this? - thomas beale -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110909/fa73512b/attachment.html
[openEHR-announce] ADL 1.5 Workbench beta 4 release - major new features
On 09/09/2011 10:39, Seref Arikan wrote: Hi Peter, We may be able to replace Eiffel Vision with something else, but that is the next step of experiments, and will take a long discussion before we get started with it. Thanks for the explanation! we can certainly do that - EiffelVision is only implicated in GUI builds of the AWB. But the AWB can be built (as you know ;-) in any back-form, e.g. DLL, .so, or a running service. The entire underlying design is predicated on this idea, so doing that is easy. - thomas
EN/ISO 13606 openEHR - harmonisation possibilities
On 09/09/2011 14:01, Stef Verlinden wrote: Great initiative. Let's go for it. Even though I agree with your previous remarks that this probably won't provide a long term solution, IMHO it's absolutely necessary in order to secure short term progress. Maybe a dumb question, but is there a way we can involve people form other standard initiatives (DCM, HL7) in order to speed up harmonisation. More specific: is there a mutual interest for all of us to invest in this. My experience is: the instant we 'involve every stakeholder' and set up some large forum / club / organisation, everything becomes paralysed and political, and tasks that should take 3 months take 3 years. So we need to be careful... Specifically: * myself and some others on this list are directly involved in an international DCM effort, led by Dr Stan Huff (Intermountain Health), and this should yield results before the end of the year * HL7 - here it depends on what we are talking about: o HL7v2 messages - there are specific approaches emerging to map v2 messages to openEHR, and I would see this as a seperate initiative (although hopefully taking advantage of the same tooling) o CDAr2 - this has its own UML model (recently) and we may be able to define some mapping rules / approaches. However, since the differences with openEHR / 13606 are far greater than between the latter two, it is a bigger effort * epSOS - this is a simple CCD that can easily be mapped to archetypes, and maybe representing it as an RM might be useful. My feeling is to get the 13606 / openEHR question sorted out first, because that is by far the easiest. If we stay focussed, unofficial (for now), and make progress on that then we can tackle bigger beasts... - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110909/73da1210/attachment.html
openEHR Transition feedback / ideas wiki page
There is this wiki page http://www.openehr.org/wiki/display/oecom/openEHR+Transition+Feedback+Pagefor feedback that some of you have already used. Please feel free to add to it, including subpages, for larger content. I re-organised the parent page http://www.openehr.org/wiki/pages/viewpage.action?pageId=196692(which points to discssions about licenses, among other things) as well to be more logical. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110909/1c02a302/attachment.html
EN/ISO 13606 openEHR - harmonisation possibilities
There are already epSOS EN13606 archetypes http://www.epsos.eu/uploads/tx_epsosfileshare/D3.5.2_Appendix_G_EN13606_Implementation.pdf 2011/9/9 Thomas Beale thomas.beale at oceaninformatics.com: On 09/09/2011 14:01, Stef Verlinden wrote: Great initiative. Let's go for it. Even though I agree with your previous remarks that this probably won't provide a long term solution, IMHO it's absolutely necessary in order to secure short term progress. Maybe a dumb question, but is there a way we can involve people form other standard initiatives (DCM, HL7) in order to speed up harmonisation. More specific: is there a mutual interest for all of us to invest in this. My experience is: the instant we 'involve every stakeholder' and set up some large forum / club / organisation, everything becomes paralysed and political, and tasks that should take 3 months take 3 years. So we need to be careful... Specifically: myself and some others on this list are directly involved in an international DCM effort, led by Dr Stan Huff (Intermountain Health), and this should yield results before the end of the year HL7 - here it depends on what we are talking about: HL7v2 messages - there are specific approaches emerging to map v2 messages to openEHR, and I would see this as a seperate initiative (although hopefully taking advantage of the same tooling) CDAr2 - this has its own UML model (recently) and we may be able to define some mapping rules / approaches. However, since the differences with openEHR / 13606 are far greater than between the latter two, it is a bigger effort epSOS - this is a simple CCD that can easily be mapped to archetypes, and maybe representing it as an RM might be useful. My feeling is to get the 13606 / openEHR question sorted out first, because that is by far the easiest. If we stay focussed, unofficial (for now), and make progress on that then we can tackle bigger beasts... - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
EN/ISO 13606 openEHR - harmonisation possibilities
Diego, Are the archetypes online anywhere? As an aside, it is an interesting document - 45 pages about archetypes, including a lot of directly copied openEHR material, and no attribution at all to openEHR! Lucky it is not an academic paper - thomas On 09/09/2011 15:28, Diego Bosc? wrote: There are already epSOS EN13606 archetypes http://www.epsos.eu/uploads/tx_epsosfileshare/D3.5.2_Appendix_G_EN13606_Implementation.pdf 2011/9/9 Thomas Bealethomas.beale at oceaninformatics.com: On 09/09/2011 14:01, Stef Verlinden wrote: Great initiative. Let's go for it. Even though I agree with your previous remarks that this probably won't provide a long term solution, IMHO it's absolutely necessary in order to secure short term progress. Maybe a dumb question, but is there a way we can involve people form other standard initiatives (DCM, HL7) in order to speed up harmonisation. More specific: is there a mutual interest for all of us to invest in this. My experience is: the instant we 'involve every stakeholder' and set up some large forum / club / organisation, everything becomes paralysed and political, and tasks that should take 3 months take 3 years. So we need to be careful...
EN/ISO 13606 openEHR - harmonisation possibilities
Hi Diego, Yes. I saw David Moner's presentation on these at the MIE conference in Oslo, and he and Gerard Freriks gave a very powerful account of the power of archetype development in messaging production. However, these archetypes also point to a somewhat different approach (at least for now) between the 13606 and openEHR communities, in that the 13606 epSos archetypes are COMPOSITION archetypes, directly modelled against the epSos requirement. In openEHR we would take a rather different approach, by re-using more generic Entry-level archetypes and building up the epSos requirement via a template. In many respects this is somewhat closer to the CCD approach where each CCD (medication, problem,etc) roughly equates to a single archetype. Although this is more complex than David's approach, it does let us re-use the archetypes in very different contexts. As one example, I am currently involved in a project which uses the NEHTA medication archetypes templated in a local vendor system, but will re-use the same archetypes to create the epSOS Prescribing summary and the Emergency summary. Both approaches are valid and both are still much easier than developing CDA but there is different design paradigm. Three-level modelling, rather than two-level modelling? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 9 September 2011 15:28, Diego Bosc? yampeku at gmail.com wrote: There are already epSOS EN13606 archetypes http://www.epsos.eu/uploads/tx_epsosfileshare/D3.5.2_Appendix_G_EN13606_Implementation.pdf 2011/9/9 Thomas Beale thomas.beale at oceaninformatics.com: On 09/09/2011 14:01, Stef Verlinden wrote: Great initiative. Let's go for it. Even though I agree with your previous remarks that this probably won't provide a long term solution, IMHO it's absolutely necessary in order to secure short term progress. Maybe a dumb question, but is there a way we can involve people form other standard initiatives (DCM, HL7) in order to speed up harmonisation. More specific: is there a mutual interest for all of us to invest in this. My experience is: the instant we 'involve every stakeholder' and set up some large forum / club / organisation, everything becomes paralysed and political, and tasks that should take 3 months take 3 years. So we need to be careful... Specifically: myself and some others on this list are directly involved in an international DCM effort, led by Dr Stan Huff (Intermountain Health), and this should yield results before the end of the year HL7 - here it depends on what we are talking about: HL7v2 messages - there are specific approaches emerging to map v2 messages to openEHR, and I would see this as a seperate initiative (although hopefully taking advantage of the same tooling) CDAr2 - this has its own UML model (recently) and we may be able to define some mapping rules / approaches. However, since the differences with openEHR / 13606 are far greater than between the latter two, it is a bigger effort epSOS - this is a simple CCD that can easily be mapped to archetypes, and maybe representing it as an RM might be useful. My feeling is to get the 13606 / openEHR question sorted out first, because that is by far the easiest. If we stay focussed, unofficial (for now), and make progress on that then we can tackle bigger beasts... - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
EN/ISO 13606 openEHR - harmonisation possibilities
What part do you said is copied? ._. Here the archetypes in ADL http://en13606.webs.upv.es/web13606/index.php/activities/ceniso-13606-workshop-mie2011-oslo 2011/9/9 Thomas Beale thomas.beale at oceaninformatics.com: Diego, Are the archetypes online anywhere? As an aside, it is an interesting document - 45 pages about archetypes, including a lot of directly copied openEHR material, and no attribution at all to openEHR! Lucky it is not an academic paper - thomas On 09/09/2011 15:28, Diego Bosc? wrote: There are already epSOS EN13606 archetypes http://www.epsos.eu/uploads/tx_epsosfileshare/D3.5.2_Appendix_G_EN13606_Implementation.pdf 2011/9/9 Thomas Bealethomas.beale at oceaninformatics.com: On 09/09/2011 14:01, Stef Verlinden wrote: Great initiative. Let's go for it. Even though I agree with your previous remarks that this probably won't provide a long term solution, IMHO it's absolutely necessary in order to secure short term progress. Maybe a dumb question, but is there a way we can involve people form other standard initiatives (DCM, HL7) in order to speed up harmonisation. More specific: is there a mutual interest for all of us to invest in this. My experience is: the instant we 'involve every stakeholder' and set up some large forum / club / organisation, everything becomes paralysed and political, and tasks that should take 3 months take 3 years. So we need to be careful... ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
openEHR Transition: Community Knowledge repository
Hi David, I think the current tools are as good as one can imagine for this moment, what I mentioned was of the tools we need to the future, and maybe some ideas to add to the whitepaper. (I wanted to be clear in this point, sometimes my bad english doesn't let me to express my ideas in a clear way, sorry for that). What I meant with freeopen tools was ment for the local and regional CKMs, and with a clear API, we could develope local CKMs that are interoperable with the global CKM (without changing any of the current great work). Thank you David, I'm here to help in any way I can. I'm sure that openEHR is the way to go and I'm sure that we need to move forward together. There are a lot of great professionals in this community and I have learned and grow a lot since the first time I worked with openEHR in 2006. I regret there aren't more coleagues from south america participating on this great community, that's why I insist with the local openEHR communities, to engage this people (and selfishly to don't feel so lonely :D). Cheers, Pablo. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Wed, 7 Sep 2011 20:39:05 +0100 From: rmhi...@live.ucl.ac.uk To: openehr-clinical at openehr.org Subject: Re: openEHR Transition: Community Knowledge repository Hi Pablo - re- your important observation below. It was a difficult decision to go with a proprietary product to underpin the openEHR CKM, but at the time there was no apparent open source tool to provide the first stage functionality required. It is complex and expensive software to develop and maintain and, through the good offices of Sam and Ocean, we secured a free license to support the CKM repository, which we were thereby enabled to make quickly available for experimental use. Of course, open-source tools are not cost and resource neutral options, but it is certainly easier for many to engage along an open source pathway of development. That said, I believe that going with the proprietary CKM was a sensible decision at the time (it was and had to be Dipak's and mine, I should say, and in no way an Ocean decision). It has certainly been fully vindicated, in my eyes, by the free use that has been made of it, which we can observe day by day, within both the openEHR community and several cognate groupings, all over the world, exploring and working with the archetypes now residing in the public CKM repository that Ocean has generously created and maintained throughout, for the openEHR community. Looking forward, Ian's link with Derek Hoy/Snowcloud and the offer he has made, is interesting and potentially a very useful new thread in the tooling agenda for openEHR. I don't think anyone imagines we are near to an ideal tooling environment to support effective clinical engagement with archetype/template/terminology development and support. The field will undoubtedly benefit from concerted and coordinated efforts to create new and better open source tooling in this area - a goal that is dear to many clinicians' hearts, I know - Tony Shannon and Dipak Kalra, to name but two! Forgive my inquisitiveness, Pablo, but I have just located and read your impressive CV and you seem exactly the right sort of person to join with others discussing here, in taking forward an initiative like that for the openEHR community. Once Sam and the new board (fully operational from October 1st) has given time for its current consultation about future governance to evolve into decisions about next steps, I very much hope there will be a way for you to do so. David I -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110909/9c69212d/attachment.html
EN/ISO 13606 openEHR - harmonisation possibilities
Thanks Diego, My mistake - that wasn't clear at David's demonstration or from the epSOS appendix. Are the ENTRY level component archetypes available, and are they designed to be for epSos use only or do they support a much broader context of use e.g a full hospital or GP medication use? It would be interesting to compare with the openEHR equivalents, especially as we intend to use the NEHTA archetypes as the basis for the official openEHR medication archetypes before long and I have been doing various mapping exercises to ensure that they meet are broad set of use cases. Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 9 September 2011 16:09, Diego Bosc? yampeku at gmail.com wrote: Well, in all of our projects we use ENTRY level archetypes and slots, but as epSOS defines that the requirement is a full document then it made sense to put everything on the same archetype (to show that all requirements could fit without problems) 2011/9/9 Ian McNicoll Ian.McNicoll at oceaninformatics.com: Hi Diego, Yes. I saw David Moner's presentation on these at the MIE conference in Oslo, and he and Gerard Freriks gave a very powerful account of the power of archetype development in messaging production. However, these archetypes also point to a somewhat different approach (at least for now) between the 13606 and openEHR communities, in that the 13606 epSos archetypes are COMPOSITION archetypes, directly modelled against the epSos requirement. In openEHR we would take a rather different approach, by re-using more generic Entry-level archetypes and building up the epSos requirement via a template. In many respects this is somewhat closer to the CCD approach where each CCD (medication, problem,etc) roughly equates to a single archetype. Although this is more complex than David's approach, it does let us re-use the archetypes in very different contexts. As one example, I am currently involved in a project which uses the NEHTA medication archetypes templated in a local vendor system, but will re-use the same archetypes to create the epSOS Prescribing summary and the Emergency summary. Both approaches are valid and both are still much easier than developing CDA but there is different design paradigm. Three-level modelling, rather than two-level modelling? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 9 September 2011 15:28, Diego Bosc? yampeku at gmail.com wrote: There are already epSOS EN13606 archetypes http://www.epsos.eu/uploads/tx_epsosfileshare/D3.5.2_Appendix_G_EN13606_Implementation.pdf 2011/9/9 Thomas Beale thomas.beale at oceaninformatics.com: On 09/09/2011 14:01, Stef Verlinden wrote: Great initiative. Let's go for it. Even though I agree with your previous remarks that this probably won't provide a long term solution, IMHO it's absolutely necessary in order to secure short term progress. Maybe a dumb question, but is there a way we can involve people form other standard initiatives (DCM, HL7) in order to speed up harmonisation. More specific: is there a mutual interest for all of us to invest in this. My experience is: the instant we 'involve every stakeholder' and set up some large forum / club / organisation, everything becomes paralysed and political, and tasks that should take 3 months take 3 years. So we need to be careful... Specifically: myself and some others on this list are directly involved in an international DCM effort, led by Dr Stan Huff (Intermountain Health), and this should yield results before the end of the year HL7 - here it depends on what we are talking about: HL7v2 messages - there are specific approaches emerging to map v2 messages to openEHR, and I would see this as a seperate initiative (although hopefully taking advantage of the same tooling) CDAr2 - this has its own UML model (recently) and we may be able to define some mapping rules / approaches. However, since the differences with openEHR / 13606 are far greater than between the latter two, it is a bigger effort epSOS - this is a simple CCD that can easily be mapped to archetypes, and maybe representing it as an RM might be useful. My feeling is to get the 13606 / openEHR question sorted out first, because that is by far the easiest. If we stay focussed, unofficial (for now), and make progress on that then we can tackle bigger
EN/ISO 13606 openEHR - harmonisation possibilities
Thomas, Could you please clarify this sentence? I'm the main author of that document. As you said, it is a 45 pages document of which only two and a half are a summary description of ADL to understand the proposed archetypes. And only there we can see some examples of ADL structures (yes, openEHR ones) taken directly from EN13606-2, which is the norm referenced at the document, and not from the openEHR specifications. I really think that your affirmation is misleading and unfair. David 2011/9/9 Thomas Beale thomas.beale at oceaninformatics.com As an aside, it is an interesting document - 45 pages about archetypes, including a lot of directly copied openEHR material, and no attribution at all to openEHR! Lucky it is not an academic paper - thomas -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110909/fa75f391/attachment.html
EN/ISO 13606 openEHR - harmonisation possibilities
On 09/09/2011 19:04, David Moner wrote: Thomas, Could you please clarify this sentence? I'm the main author of that document. As you said, it is a 45 pages document of which only two and a half are a summary description of ADL to understand the proposed archetypes. And only there we can see some examples of ADL structures (yes, openEHR ones) taken directly from EN13606-2, which is the norm referenced at the document, and not from the openEHR specifications. I really think that your affirmation is misleading and unfair. David, sorry - you are right, there is not 'a lot' of copied material, only p 11 12. But I do find it funny that there is no mention of openEHR, because it means that readers of the document won't realise that they should go to openEHR to see ongoing developments in the specification and tools (I am not saying the only development in tools of course, but since 13606-2 is a snapshot of an openEHR spec, it would make sense to make this clear, one would have thought). - thomas
EN/ISO 13606 openEHR - harmonisation possibilities
Ok, but again, the referenced documents at that epSOS annex are CEN EN 13606 part 1 and CEN EN 13606 part 2. If openEHR has to be mentioned is in those documents, not in this annex since it only deals with 13606 and the archetype/ADL summary is just for clarifying concepts for the reader and not a complete history about the technology behind. David 2011/9/9 Thomas Beale thomas.beale at oceaninformatics.com On 09/09/2011 19:04, David Moner wrote: Thomas, Could you please clarify this sentence? I'm the main author of that document. As you said, it is a 45 pages document of which only two and a half are a summary description of ADL to understand the proposed archetypes. And only there we can see some examples of ADL structures (yes, openEHR ones) taken directly from EN13606-2, which is the norm referenced at the document, and not from the openEHR specifications. I really think that your affirmation is misleading and unfair. David, sorry - you are right, there is not 'a lot' of copied material, only p 11 12. But I do find it funny that there is no mention of openEHR, because it means that readers of the document won't realise that they should go to openEHR to see ongoing developments in the specification and tools (I am not saying the only development in tools of course, but since 13606-2 is a snapshot of an openEHR spec, it would make sense to make this clear, one would have thought). - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110909/f8c1b5f3/attachment.html
EN/ISO 13606 openEHR - harmonisation possibilities
David, Diego, I just tried to compile the archetype CEN-DEMOGRAPHIC-IDENTIFIED_HEALTHCARE_PROFESSIONAL.HCP_Dispenser.v1 in the ADL Workbench... I had to make a few changes: * IDENTIFIED_HEALTHCARE_PROFESSIONAL has an attribute 'scopingOrganisation' in the standard, but the archetype had 'scoping_organisation' (the standard bizarrely mixes camelCase and underscore_form) * HEALTHCARE_PROFESSIONAL_ROLE has an attribute 'specialty' in the standard, but it was called 'speciality' in the archetype (admittedly an easy confusion in English) At the moment, the version of the 13606 and 21090 schemas available inthe openEHR SVN has the strange mix of attribute name styles in the published standard. The archetypes have used a consistent naming approach - the more_readable_form, from my point of view. What is the consensus on this aspect of the standard? Do we follow it slavishly or use a modified variant, as you have presumably done for your epSOS work? It may be that my copy of 13606 is out of date, and was superseded by some later update - I have a version from 2006-06-13. Were there later changes? - thomas On 09/09/2011 19:04, David Moner wrote: Thomas, Could you please clarify this sentence? I'm the main author of that document. As you said, it is a 45 pages document of which only two and a half are a summary description of ADL to understand the proposed archetypes. And only there we can see some examples of ADL structures (yes, openEHR ones) taken directly from EN13606-2, which is the norm referenced at the document, and not from the openEHR specifications. I really think that your affirmation is misleading and unfair. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110909/13689bc0/attachment.html
