Archetype licensing - CC-BY-SA proposal clarified
It turns out that the white paper does not describe very clearly what was intended by the use of CC-BY-SA for archetypes. After discussion with Sam, I have created a new wiki page <http://www.openehr.org/wiki/display/oecom/Archetype+licensing+-+the+case+for+CC-BY-SA>describing in detail the intended proposal. I think wider understanding and more informed debate of the proposal will now be possible. - thomas beale -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110912/8ee52951/attachment.html>
openEHR and ISO EN 13606
Dear Colleagues, I am often asked about the relationship between ISO EN 13606 and openEHR, and I note this topic has recently been raised on our lists. To say straight off, some people imagine there are tensions between these, but most of the people active in taking forward 13606 are also active in openEHR, and see value in both. I certainly do. Inevitably those close up to this subject tend to focus on fine differences, while those further away cannot understand what the differences are or why they might be important. If one looks at the modest quality and poor consistency of clinical data and the limited interoperability of EHR systems today, the differences between openEHR and 13606 are really rather slight. 13606 was developed drawing on a long thread of R&D on EHR representations, starting from the early 1990's and embodied in two past generations of European Standard as well as openEHR's specifications. All of this background work was inter-linked through time and people, many of whom contributed to the development of the standard, directly or indirectly. The priority during the development of the standard - expressed especially by the vendors and the health ministry representatives - was to find the simplest possible model for communication between heterogeneous EHR systems, whilst meeting published requirements including medico-legal requirements e.g. ISO 18308. The goal was to keep the complexity of the interoperability models low, and not to require a large number of information properties that many legacy systems might not be capable of providing for export or of safety storing on import. As the work migrated from its origins in CEN to ISO, this philosophy was endorsed by the broader international community: for example the ISO version of Part 1 (2008) is identical to the CEN version (2007). Archetypes were very much liked, and there was a wish to support the sound use of archetypes as promoted by openEHR, but optionally - recognising that archetypes will take some years for marketplace penetration, and that EHR interoperability has to work in a non-archetyped, a fully archetyped and in a transitional mixed economy. We have tried to support these options in 13606. When developing ISO 13606 Part 2 we recognised that the then current version of ADL would evolve, and also that other representations of archetypes might gain favour over time e.g. XML, OWL. That part-standard is therefore deliberately called an "Archetype Interchange Specification" - i.e. it is for sharing archetypes, not for operationalising them within particular systems. The normative parts are the requirements and the UML logical representation, and the conformance requirements are to be able to map any physical representation of archetypes to this local expression. ADL 1.4 was included as it was then stable and implemented within tools (i.e. the paint on it was dry), but with optional conformance. (Readers of the standard are invited to go to the openEHR Web site for more on archetypes.) It is therefore permitted by the standard to use, for example, ADL 1.5. Other part of 13606 deal with confidentiality policy interoperability and with interface specifications, and some internal vocabularies. (There is a data type "inter-regnum" that should be addressed in the near future.) Some vendors and countries have found 13606 attractive because of its stability: since the time line from design to return on investment for EHR system products can be many years, an evolving specification is considered by some to be a disadvantage. 13606 is considered to be easy on the learning curve and potentially well suited to feed a national EHR network that has to federate multiple (legacy) systems from multiple vendors. openEHR, of course, offers a more detailed and comprehensive EHR reference model and other specifications targeted primarily as an EHR system architecture. This suits other use cases and budgets. I won't elaborate on openEHR here as you all know it well. Since both support archetypes, investments in clinical modelling activities by health professional bodies or eHealth programmes can be exploited by both kinds of specification. This is important since a significant investment is now needed, globally, in scaling up archetype development and validation. When 13606 is revisited over the next few years we will see what experiences have been gained across all dimensions of health record interoperability globally, in order to identify deficiencies and new priorities for it to meet. Since openEHR is also learning hugely as its implementation base grows, I would expect the shared learning to result in better alignment between the two specifications next time. However, as I have often made clear, I am strongly resistant to modelling by "religion" so I do not like to be drawn yet on how close that alignment might be, nor on how close we can align with HL7 CDA - desirable as t
openEHR Transition: two procedural and one licensing question
Hi Sam, > 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 > Why we need to define a license to stop someone to copyright or charge for a specialized archetype? I think this could be done by defining "user terms" to the archetypes downloaded from the CKM (and every CKM around the world must have the same "use terms". You can include something like this on the user terms: all artefacts (archetypes, templates, term sets, etc) downloaded from *here* are public and free to use and to specialize. All artefacts derived from those, alse must be free. This is a copyleft scheme. If I want to use artefacts from a "public CKM", I must follow those rules. Of course, anyone can create its own CKM and create artefacts from scratch and do whatever they want with those artefacts. I think you can charge for the time you invest in specialize artefacts from public CKMs, but not sell the artifact itself. If you create the artefact from scratch its the creators desition to charge or not. What do you think? Regards, Pablo. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110912/1cdf546a/attachment.html>
openEHR Transition: two procedural and one licensing question
Hi! > On Thu, Sep 8, 2011 at 16:54, Sam Heard > wrote: >> 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)? So, Sam have you finally dropped the thought that CC-BY-SA would protect against patent system abuse? We have not gotten a clear answer to this yet. Is your only remaining concern now that you believe copyright law might be so strong that it would stop possibilities to do specialisations with the same main functionality as possibly copyrighted useful specialisations? Is that your only remaining "SA" motive? Sam, since you are and have been so extremely powerful in the formal openEHR decision process, we really need to understand your thoughts, thus I and others have been probing to figure out your reasoning for years. On Fri, Sep 9, 2011 at 00:21, Timothy Cook wrote: > Maybe that isn't such a bad thing. ?They are only roping themselves > into their own corner. :-) We as a community could always provide help in highlighting those "ropes" via: - Technical means: license detection upon import of archetypes and EHR data (as described on the wiki) - Social & political means: questioning the fairness and wisdom of parties trying to block the common good of semantic interoperability. Their income often somehow originates from public funding and they should be concerned about potential badwill. We can probably also get around the hypothetical/potential problem by making a similar (hopefully even better) specialisation ourselves (not an exact copy) that covers the same needs. It will be hard for the "copyrighting and charging"-bad guys to claim that another implementation of the idea is a verbatim copy (prohibited by copyright) and that their work has enough innovation height that is not obvious to skilled persons (and thus patentable). The same argument goes the other way too - even ideas from a CC-BY-SA licensed archetype from openEHR may be fairly closely re-implemented as completely closed/copyrighted and it would be both hard and time-consuming for the openEHR foundation to try and stop this (anti-interoperable) approach, so let's reduce the temptation by simply using CC-BY. Copyright does not stop ideas the same broad way patents do. To software people I believe it's obvious that improvement-ideas in commercial closed source forks of e.g. apache-licensed software projects does not prevent the open source original project to reimplement similar ideas (as long as the closed source code is not copied). Copyright is not nearly as harmful as patents in these cases. On Thu, Sep 8, 2011 at 01:37, Sam Heard wrote: > Our advice was that having copyright simplifies the world. Having said that > the same archetypes now exist in other repositories with copyright assigned > to the national provider, so it is already murky. Well, if the national providers had been encouraged to use CC-BY instead of CC-BY-SA then it wouldn't matter at all who had the copyright (as Tom has pointed out several times over the years)... On Fri, Sep 9, 2011 at 05:25, Sam Heard wrote: > ...government agencies and companies will want to know that no one has > recourse to legal action if they use an archetype. Is that a "copy" of the ideas behind my argument _against_ CC-BY-SA? :-) Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
openEHR Transition: Web-based tools?
Ian, This is exactly the reason I've been using Flex. Flex 3.5 requires Flash player 9, which is 6 years old. Runs without an issue in IE 6, gives me more power than the HTML 5 frameworks etc etc. Naming technologies is dangerous due to possibility of spontaneous flame wars, but what I've been describing is the reason I've had to use Flex. (and don't even get me started on HTML 5) On Sun, Sep 11, 2011 at 11:45 AM, Ian McNicoll wrote: > Hi Seref, > > I accept that , but you can say exactly the same thing about browsers > and web connectivity generally. Until very recently the NHS in the UK > mandated IE6 - go figure. How long before we see snazzy new HTML5 > browsers in these environments? > > 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 11 September 2011 11:21, Seref Arikan > wrote: >> Peter, >> The problem is not necessarily about the capability of frameworks to >> manage updates or side by side execution. >> 90% of the time problem is about the IT policies of the institutions. >> If you develop with .NET 4.0, which would require a .net framework 4.0 >> runtime, you assume that the people using the software would be able >> to install the runtime, and install the software. >> many corporate/institutional machines do not allow their users install >> software. Most of the corporate/institutional IT is running on >> horribly old software. IT policy is the real issue I was referring to. >> I don't want to go into a long description of things that went wrong >> for me in the past, but let me just say that I've personally had >> enough issues with both Java and .NET deployment and upgrades that >> makes web based apps a much better option when it comes to this >> particular aspect of software life cycle. >> >> Regards >> Seref >> >> >> On Sat, Sep 10, 2011 at 2:18 PM, Peter Gummer >> wrote: >>> Seref Arikan wrote: >>> ... ?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. >>> >>> I'm not aware of any such deployment problems with .NET. I'm sure >>> there must be some, somewhere, but they must be edge cases. In ten >>> years of .NET development I haven't bumped into them. Different >>> versions of .NET sit side-by-side on the same machine just fine; ditto >>> for DLLs targeted towards different .NET versions. My daily work >>> involves a .NET 4.0 application that has dependencies on a lot of .NET >>> 2.0 DLLs; it just works seamlessly. >>> >>> - Peter >>> ___ >>> 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 >> > > ___ > 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-55>on 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
':' 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 : > 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 > >
openEHR Transition: Web-based tools?
Pablo Pazos wrote: > Web developers can easily tackle those problems ... I'm afraid the word "easily" is wrong, Pablo. I've been doing mostly web development for the last few years. I specifically mentioned those things because they are _hard_ to do in in web development, whereas in desktop applications they are extremely easy to do or, in the case of session time-outs, the problem doesn't exist at all. > Just use HTML: http://en.wikipedia.org/wiki/Access_key This doesn't address keyboard shortcuts. Access keys are not keyboard shortcuts. I'm sure there must be some way to do keyboard shortcuts in a web application, because googling for "cloud9 keyboard shortcuts" comes up with some relevant-looking results, but I really have no idea how to achieve it. It also doesn't address at all my question about setting focus to the appropriate control automatically. When I open a page, I want keyboard focus set to a sensible place, probably the top-left entry control. If I select an item from a drop-down list, I probably want focus to remain on that drop-down list. If there's an OK or Save button on the page, then I should be able to click it without being forced to reach for the mouse. Simple usability stuff that is programmed routinely with almost no effort into a desktop app, and that is essential for me personally, if I am to spend hours on end, day after day, using that application. My experience of trying to get basic stuff like this working properly in a web app is that it's doable, but with a huge amount of effort. > One way to maintain a session open is to send heartbeats using > AJAX ... That's interesting. When I have a whole day free to investigate, I might work out a way to implement this for my current project. Hopefully that day won't turn into a week, as such things have a tendency of doing :-( Anyway, this pretty well proves my point. The problem simply doesn't exist in desktop apps, but in developing a web app you have to devote significant time to this problem instead of working on real functionality. These are just a few examples of the many things that I take for granted when programming desktop apps that suddenly become very difficult for web apps ... - Peter
