EN/ISO 13606 openEHR - harmonisation possibilities
':' are not valid as names in most operating systems, so it would be a problem even for adl file names. That's why I don't think it is wise to allow this one in particular. The other issue was already 'discussed' on the list http://www.openehr.org/mailarchives/openehr-technical/msg05294.html I have also checked the ISO norm and you were right with the attribute names. I suppose that scopingOrganisation was changed to underscores to keep the same style, but I think that we should fit to the standard. I have fixed it and will inform the 13606 association so they can update it to a new version 2011/9/10 Thomas Beale thomas.beale at oceaninformatics.com: On 10/09/2011 14:22, Diego Bosc? wrote: ADL parser. and I am not saying it should be allowed, just that this kind of things happen :) Diego, I am still not clear on the actual problem - if it is the ADL workbench parser, would you mind reporting it here? If it is the Java parser, you should report it on the ref_impl_java mailing list. - 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
On 12/09/2011 08:51, Diego Bosc? wrote: ':' are not valid as names in most operating systems, so it would be a problem even for adl file names. That's why I don't think it is wise to allow this one in particular. I don't remember anywhere in ADL/AOM where filenames are specified, and ':', certainly would not work - can you point me to the part of the specification you are talking about - I don't remember ay part that talks about filenames. The other issue was already 'discussed' on the list http://www.openehr.org/mailarchives/openehr-technical/msg05294.html My response would still be the same ;-) David has created this issue http://www.openehr.org/issues/browse/SPECPR-55on the tracker, which is all we need to remember it. I have also checked the ISO norm and you were right with the attribute names. I suppose that scopingOrganisation was changed to underscores to keep the same style, but I think that we should fit to the standard. I have fixed it and will inform the 13606 association so they can update it to a new version there are a lot of attributes with this problem... - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110912/6bf69e2a/attachment.html
EN/ISO 13606 openEHR - harmonisation possibilities
-Original Message- From: Diego Bosc? yamp...@gmail.com Sender: openehr-technical-bounces at openehr.org openehr-technical-bounces at openehr.org Date: Sat, 10 Sep 2011 09:45:17 To: For openEHR technical discussionsopenehr-technical at openehr.org Reply-To: For openEHR technical discussions openehr-technical at openehr.org Subject: Re: EN/ISO 13606 openEHR - harmonisation possibilities yes, what I mean is attributes like ID or even invalid characters in the names (like ':'). This is a problem with the parser (and also with classes identifiers) 2011/9/10 Thomas Beale thomas.beale at oceaninformatics.com: On 10/09/2011 12:59, Diego Bosc? wrote: This kind of problems has given us a lot of problems when using ADL to work with other models like HL7 CDA or CDISC ODM, where there isn't any kind of rule (for example, in ADL CLASSES must be upercase and the attributes lowercase, and in CDA this is not true) actually there is no rule in ADL. You can use CamelCase, and it has been working for the entire lifetime of the tools. Indeed you will see it in the 13606 and 21090 schemas, which are processed by the ADL Workbench. It's just that the documents use a particular convention which happens to be the underscore convention, for better readability. My view is that any given model should stick to one or the or the convention consistently, whatever convention that may be. - 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 La informaci?n contenida en el presente correo es privada y confidencial entre las partes y su uso, copia, reproducci?n o distribuci?n est? expresamente prohibida.
EN/ISO 13606 openEHR - harmonisation possibilities
As Dipak has explained, the attribution in ISO is not available. I believe attribution is a distraction from the task - I have seen lots of slides from others used in this space and ideas transferred here and there. Let's appreciate all work and try and build on it efficiently. Cheers Sam Sent from my phone On 10/09/2011, at 5:05 AM, Thomas Beale thomas.beale at oceaninformatics.com wrote: 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
EN/ISO 13606 openEHR - harmonisation possibilities
I currently don't have the norm with me, I'll check it on Monday morning. Second case looks like a typo on the schema, thanks for pointing it out. We will check it and correct it. We created a 13606 XML Schema (because there was none available) trying to follow the specifications (as we also did with openEHR demographic model). You can find both through linkEHR website. Just notice that those are not official XML schemas yet. I don't know the consensus about naming on the standard, as I'm just a user of it :) However using CamelCase is preferred in most programming languages as when you print code the underscore can be confused with '-' (and also, is faster to write CamelCase variables ;) I personally prefer CamelCase. I agree it would look prettier if everything had the same case, but as you know in 99% of the specifications this is mixed. This kind of problems has given us a lot of problems when using ADL to work with other models like HL7 CDA or CDISC ODM, where there isn't any kind of rule (for example, in ADL CLASSES must be upercase and the attributes lowercase, and in CDA this is not true) 2011/9/9 Thomas Beale thomas.beale at oceaninformatics.com: 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. ___ 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
David, no offence was intended (at all). I was trying to point out (badly) in the context of the current discussions on licensing and openEHR that, if CC-BY had been in place in the past, then: * the CEN 13606-2 standard, being a copy of work done by openEHR (with adaptations done to wording as required by CEN/ISO), would have been required to acknowledge the original authors and copyright, AND * that further derivative works would also have to do this. As I don't work in academia, I don't care as much about 'being recognised as the author' as some people might, but I do care about the impression being given of an organisation having invented something when this is not the case - mainly because it prevents readers from understanding where the technology came from in the first place, and referring back to it, e.g. to find more recent versions, software, and community. I don't think this is unreasonable. - thomas On 09/09/2011 20:51, David Moner wrote: 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110910/47115c4d/attachment.html
EN/ISO 13606 openEHR - harmonisation possibilities
On 10/09/2011 12:59, Diego Bosc? wrote: This kind of problems has given us a lot of problems when using ADL to work with other models like HL7 CDA or CDISC ODM, where there isn't any kind of rule (for example, in ADL CLASSES must be upercase and the attributes lowercase, and in CDA this is not true) actually there is no rule in ADL. You can use CamelCase, and it has been working for the entire lifetime of the tools. Indeed you will see it in the 13606 and 21090 schemas, which are processed by the ADL Workbench. It's just that the documents use a particular convention which happens to be the underscore convention, for better readability. My view is that any given model should stick to one or the or the convention consistently, whatever convention that may be. - thomas
EN/ISO 13606 openEHR - harmonisation possibilities
yes, what I mean is attributes like ID or even invalid characters in the names (like ':'). This is a problem with the parser (and also with classes identifiers) 2011/9/10 Thomas Beale thomas.beale at oceaninformatics.com: On 10/09/2011 12:59, Diego Bosc? wrote: This kind of problems has given us a lot of problems when using ADL to work with other models like HL7 CDA or CDISC ODM, where there isn't any kind of rule (for example, in ADL CLASSES must be upercase and the attributes lowercase, and in CDA this is not true) actually there is no rule in ADL. You can use CamelCase, and it has been working for the entire lifetime of the tools. Indeed you will see it in the 13606 and 21090 schemas, which are processed by the ADL Workbench. It's just that the documents use a particular convention which happens to be the underscore convention, for better readability. My view is that any given model should stick to one or the or the convention consistently, whatever convention that may be. - 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, I am not sure I understand that one - ':' is indeed illegal in most class / property identification systems - are you saying it should be allowed? Which parser do you mean? - thomas On 10/09/2011 13:45, Diego Bosc? wrote: yes, what I mean is attributes like ID or even invalid characters in the names (like ':'). This is a problem with the parser (and also with classes identifiers) 2011/9/10 Thomas Bealethomas.beale at oceaninformatics.com: On 10/09/2011 12:59, Diego Bosc? wrote: This kind of problems has given us a lot of problems when using ADL to work with other models like HL7 CDA or CDISC ODM, where there isn't any kind of rule (for example, in ADL CLASSES must be upercase and the attributes lowercase, and in CDA this is not true) actually there is no rule in ADL. You can use CamelCase, and it has been working for the entire lifetime of the tools. Indeed you will see it in the 13606 and 21090 schemas, which are processed by the ADL Workbench. It's just that the documents use a particular convention which happens to be the underscore convention, for better readability. My view is that any given model should stick to one or the or the convention consistently, whatever convention that may be. - 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 -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics http://www.oceaninformatics.com/* Chair Architectural Review Board, /open/EHR Foundation http://www.openehr.org/ Honorary Research Fellow, University College London http://www.chime.ucl.ac.uk/ Chartered IT Professional Fellow, BCS, British Computer Society http://www.bcs.org.uk/ Health IT blog http://www.wolandscat.net/ * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110910/5bf35293/attachment.html -- next part -- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110910/5bf35293/attachment.jpg
EN/ISO 13606 openEHR - harmonisation possibilities
ADL parser. and I am not saying it should be allowed, just that this kind of things happen :) 2011/9/10 Thomas Beale thomas.beale at oceaninformatics.com Diego, I am not sure I understand that one - ':' is indeed illegal in most class / property identification systems - are you saying it should be allowed? Which parser do you mean? - thomas On 10/09/2011 13:45, Diego Bosc? wrote: yes, what I mean is attributes like ID or even invalid characters in the names (like ':'). This is a problem with the parser (and also with classes identifiers) 2011/9/10 Thomas Beale thomas.beale at oceaninformatics.com: On 10/09/2011 12:59, Diego Bosc? wrote: This kind of problems has given us a lot of problems when using ADL to work with other models like HL7 CDA or CDISC ODM, where there isn't any kind of rule (for example, in ADL CLASSES must be upercase and the attributes lowercase, and in CDA this is not true) actually there is no rule in ADL. You can use CamelCase, and it has been working for the entire lifetime of the tools. Indeed you will see it in the 13606 and 21090 schemas, which are processed by the ADL Workbench. It's just that the documents use a particular convention which happens to be the underscore convention, for better readability. My view is that any given model should stick to one or the or the convention consistently, whatever convention that may be. - 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 -- Thomas Beale Chief Technology Officer, Ocean Informatics Chair Architectural Review Board, openEHR Foundation Honorary Research Fellow, University College London Chartered IT Professional Fellow, BCS, British Computer Society Health IT blog ___ 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
On 10/09/2011 14:22, Diego Bosc? wrote: ADL parser. and I am not saying it should be allowed, just that this kind of things happen :) Diego, I am still not clear on the actual problem - if it is the ADL workbench parser, would you mind reporting it here http://www.openehr.org/issues/browse/AWBPR? If it is the Java parser, you should report it on the ref_impl_java mailing list. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110910/ac36ef15/attachment.html
EN/ISO 13606 openEHR - harmonisation possibilities
As you may have noticed, the new release of the ADL Workbench http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.htmlenables exploration of multiple reference models and their classes. Although the 13606 schema http://www.openehr.org/svn/knowledge2/TRUNK/rm_schemas/cen_EN13606_0.95.bmm is not yet complete (in particular the data types require work), it is now possible to see the differences and similarities http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/adl1.5/apps/adl_workbench/doc/web/images/rm_schema_tool_duplex_classes.pngof the 13606 and openEHR reference models. Similarly, archetypes based on both reference models can be viewed, validated and compared. I see various possibilities: * *convergence of 13606 and openEHR onto one reference model*. The opportunity to do this is coming up in May 2012, where 13606-1 and 13606-2 reach their 3 year review point, at which ISO has to decide to either retire them or continue their use, depending on their use in industry. I don't know what use in industry they have to date, but let's assume the decision is made to continue - it is clear that changes could be made. Implementers of both openEHR and 13606 have now had some 3 years to discover real problems and deficiencies. In openEHR there are around 150 Problem Reports and Change Requests generated over this time; clearly some of these would apply equally to 13606. Some possible changes: o it is now possible to see how 13606 and openEHR could be merged into *one reference model *at the Entry level, e.g. with changes like: + openEHR has richer 'design-based' Entry types like Observation, Instruction and Action, but also a generic type called Integration_entry, which nearly a mirror image of the EN13606 ENTRY. A future standard could support all of these types, with the users choosing which ones best supported their data. + openEHR's data structures (ITEM_STRUCTURE, ITEM_TREE, ITEM_TABLE) etc may be able to be retired in lieu of the only simpler CLUSTER/ELEMENT structure in use by both standards, and a 'structure marker' as used by 13606 - this would further ease merging of the reference models. o a *common data types *model could be found. At the moment, openEHR's data types work very well and have been shaped by archetyping as well as normal software considerations. For 13606, in theory the ISO 21090 data types are supposed to be used. In their current state, they cannot be, and are both completely normalised and optimised for HL7v3 use http://www.healthintersections.com.au/?p=364, as well as suffering from key modelling problems http://wolandscat.net/2011/05/24/ontologies-and-information-models-a-uniting-principle/. It has been stated that an ISO 21090 'profile' will be developed for 13606, although this has not yet been done. In my view, the HL7 'profiling' process is almost unworkable, and I think a completely different set of data types is needed for 13606 - a far simpler set, e.g. based on a simplified version of openEHR, or Grahame Grieve's Resources for Health data types http://www.healthintersections.com.au/rfh/datatypes.htm (which include both openEHR and HL7 influences, as well as using proper object modelling). o a few useful Change Requests have been made based on CDA. Once these are done, the merged RM would be a superset of all models in use today, with the added value of being more rigorously defined and therefore usable for tool-based code generation, data transformation and the like. * *adoption of ADL/AOM 1.5 as a new 13606 part 2*. Although it seems as if ADL 1.5 is taking a long time (it is ;-) it is being continuously tested in real software on the way, so that what emerges will be something close to a 'stable' standard (openEHR might decide to give it DSTU status from the outset for example) rather than an untested set of proposals. It is backwardly compatible with ADL 1.4, while fixing all the main problems and limits http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Specialised+Archetypesof 1.4. It includes many (in fact almost only) features proposed by people working with real archetypes in real environments, so I think it is safe to say that the 40 or so changes (most very small) really reflect the last 4-5 years' industry validation rather than any kind of theorising. If ADL/AOM 1.5 were to become the next version of 13606-2, then we can contemplate: o *shared tooling*: doing this would mean that all 13606 efforts can use the openEHR tooling, which is growing by the day, and that
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
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
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
