openEHR Transition: Web-based tools?
Hi Ian My interest is the pain we get as the tools get developed and tweaked as does ADL and multiple versions. Also, if we are to use Thomas' engine it should tip the balance a bit further as installing and updating numerous layers gets even more painful. Finally, web tools are easier to access on multiple devices including mobile. Cheers San Sent from my phone On 10/09/2011, at 1:10 AM, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: Hi all, One of the suggestions in the White Paper which appears to have universal support is a move to support much more open-source tools development. Clearly some tooling must be web-based e.g repository management and associated formal and informal discussion e.g. CKM and any new community repository. However, I am much less clear on why we might need web-based primary authoring tools for archetypes and templates. Diego, Pablo and Sam are all keen on this approach but I remain unconvinced that this is really a key requirement, given that archetype authoring is in essence a solitary activity much like any other code development. By all means build in much better integration with repositories and other mechanisms to allow joint working, but even with modern javascript libraries and Flex-style components, HTML-based tooling just feels like it adds a layer of development complexity and probably some usability-clunkiness which is not offset by the benefits. Maybe I am just an old-timer but having waited for may years to get the kind of development environment that Visual Studio, Eclipse and equivalents bring, and that I think is equally required for archetype development, I am loathe for us to get slowed-down by insisting on a 'web-based'. What do others think? 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 ___ 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
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
openEHR Transition: Web-based tools?
Hi Ian, You are raising concerns from a tool user perspective, and anything related to your user experience IMHO belongs to another discussion. Web based applications are not there because they are supposed to be collaboration hubs. The recent explosion (and in a way, a bubble) of social networking may give that impression, but web apps are also about easy deployment and management. These two key aspects of software become extremely important especially in small development teams. Unfortunately, most modern software development technologies arrive with their own runtimes, (.net framework, jre etc) and it quickly becomes a nightmare to deploy and update software. Even with a limited amount of people doing something such as developing archetypes, support quickly gets out of control. If you can match a desktop application using a web application, you almost always win the competition (from the supply side of view). Given the state we are in, I'd still choose web based apps. Kind regards Seref On Fri, Sep 9, 2011 at 5:53 PM, Sam Heard sam.heard at oceaninformatics.com wrote: Hi Ian My interest is the pain we get as the tools get developed and tweaked as does ADL and multiple versions. Also, if we are to use Thomas' engine it should tip the balance a bit further as installing and updating numerous layers gets even more painful. Finally, web tools are easier to access on multiple devices including mobile. Cheers San Sent from my phone On 10/09/2011, at 1:10 AM, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: Hi all, One of the suggestions in the White Paper which appears to have universal support is a move to support much more open-source tools development. Clearly some tooling must be web-based e.g repository management and associated formal and informal discussion e.g. CKM and any new community repository. However, I am much less clear on why we might need web-based primary authoring tools for archetypes and templates. Diego, Pablo and Sam are all keen on this approach but I remain unconvinced that this is really a key requirement, given that archetype authoring is in essence a solitary activity much like any other code development. By all means build in much better integration with repositories and other mechanisms to allow joint working, but even with modern javascript libraries and Flex-style components, HTML-based tooling just feels like it adds a layer of development complexity and probably some usability-clunkiness which is not offset by the benefits. Maybe I am just an old-timer but having waited for may years to get the kind of development environment that Visual Studio, Eclipse and equivalents bring, and that I think is equally required for archetype development, I am loathe for us to get slowed-down by insisting on a 'web-based'. What do others think? 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 ___ 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
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
openEHR Transition: Web-based tools?
On 09/09/2011 17:53, Sam Heard wrote: Hi Ian My interest is the pain we get as the tools get developed and tweaked as does ADL and multiple versions. well, changes to formalisms are different from changes to tools. All these things are already or can be version managed, so this is just a question of release management. Also, if we are to use Thomas' engine it should tip the balance a bit further as installing and updating numerous layers gets even more painful. Sam, I am not sure what you mean by this. Which 'layers' are you referring to? Finally, web tools are easier to access on multiple devices including mobile. that's one advantage for sure. But we don't see any 'heavy' tools being used over the web yet, e.g. Eclipse, Visual Studio. The time may well come when this happens, which would in theory be nicer in terms of tool distribution and updating. But it is not as simple as you think: * the individual workspace / common repository / check-in check-out model never disappears, it can only be made less obvious * individuals make choices to do with tools themselves - o which version to stay on, o plug-ins, o tool configuration, e.g. views, colours, accessibility, o integration with other tools All of this has to live in some individual-specific place, which could be on the web. Maybe. So actually while one aspect of distribution is reduced, others get more complicated. Examples of the distribution problem being solved very elegantly and cleanly: Debian apt-get (takes care of all dependency checking and compatiblity) and Mozilla FireFox (remember it's on your desktop, not on the web - its how you get to the web!). - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110910/20ff2655/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
openEHR Transition: Community Knowledge repository
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 ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110910/d7dccb31/attachment.html
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
openEHR Transition: Web-based tools?
Hi Ian, We develop web based systems because we are web developers. In my case I have started my programming skills on web based systems, and now I have learned a lot of tools, frameworks and web standards and I have very little experience on desktop based tools. Said that, I think desktop based tools have the same value and usability as the web based ones. There are tools that by nature have to be web based, but other tools like the template editor is ok on desktop. I have the dream that one day I open just one program (a web browser) and get free access to all the archetypes and templates available in the cloud (multiple CKMs), and may create, edit and share those artefacts also online. Sometimes I think about something like an openEHR facebook, where archetypes are people, templates are groups, and all are related by slots (friend relationships). This is just a dream... -- 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 From: Ian.McNicoll at oceaninformatics.com Date: Fri, 9 Sep 2011 16:10:10 +0100 Subject: openEHR Transition: Web-based tools? To: openehr-technical at openehr.org Hi all, One of the suggestions in the White Paper which appears to have universal support is a move to support much more open-source tools development. Clearly some tooling must be web-based e.g repository management and associated formal and informal discussion e.g. CKM and any new community repository. However, I am much less clear on why we might need web-based primary authoring tools for archetypes and templates. Diego, Pablo and Sam are all keen on this approach but I remain unconvinced that this is really a key requirement, given that archetype authoring is in essence a solitary activity much like any other code development. By all means build in much better integration with repositories and other mechanisms to allow joint working, but even with modern javascript libraries and Flex-style components, HTML-based tooling just feels like it adds a layer of development complexity and probably some usability-clunkiness which is not offset by the benefits. Maybe I am just an old-timer but having waited for may years to get the kind of development environment that Visual Studio, Eclipse and equivalents bring, and that I think is equally required for archetype development, I am loathe for us to get slowed-down by insisting on a 'web-based'. What do others think? 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110910/b1bca7a3/attachment.html
