Archetype authoring attribution
Hi David As the aim for all is interoperability of these things, I would hope that the information would be two way. I would suggest getting the new experts to comment on CKM and then derive a 13606 archetype (this is described in the 13606 standard). I would like that to be a future part of CKM but understand this may seem a little too controlling. If we start creating clinical content specifications in lots of places it will not really assist medicine a great deal. We estimate that it is costing health care dearly to do this again, again and again. Particularly when providers are interested in quality and sharing information. That said, I would attribute the work to openEHR, the original authors, contributors and any new expert inputs. The license is to openEHR so I guess it is openEHR that needs attributing if you want to stay with the legal requirement. The SA does mean that you have to share the derived work under a similar license, something that some have been worried about. I am interested in your views on this. Cheers, Sam From: openehr-technical-boun...@lists.openehr.org [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of David Moner Sent: Thursday, 22 March 2012 9:33 PM To: OpenEHR clinical discussions; OpenEHR technical discussions Subject: Archetype authoring attribution Hello, Back again with the licensing topic of archetypes, with a real use case. We have been asked to help in creating a set of 13606 archetypes for breast and prostate cancer. Although they will probably incorporate some new requirements, the main source will be some of the openEHR archetypes available at the CKM. Assuming that the have adopted a CC-BY(-SA) license (I cannot recall which is the state of that discussion), the doubts are the following: - Converting the archetype to a new reference model is considered as a derivation? Or the openEHR archetype is considered just as a reference material as could be any textbook or paper? - The author of the new archetype has to be the one of the openEHR archetype (Ian McNicoll btw) or the person who in fact creates the new RM-based archetype? The underlying question here that should be clarified is to define which is the extension of the concept derived work. David -- 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/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/38a41369/attachment.html
Archetype authoring attribution
On 22/03/2012 12:03, David Moner wrote: Hello, Back again with the licensing topic of archetypes, with a real use case. We have been asked to help in creating a set of 13606 archetypes for breast and prostate cancer. Although they will probably incorporate some new requirements, the main source will be some of the openEHR archetypes available at the CKM. Assuming that the have adopted a CC-BY(-SA) license (I cannot recall which is the state of that discussion), the doubts are the following: - Converting the archetype to a new reference model is considered as a derivation? Or the openEHR archetype is considered just as a reference material as could be any textbook or paper? - The author of the new archetype has to be the one of the openEHR archetype (Ian McNicoll btw) or the person who in fact creates the new RM-based archetype? The underlying question here that should be clarified is to define which is the extension of the concept derived work. if it is the same archetype, then it is a derived work. Which is fine, that's what CC-BY is for. My understanding of the term is that a machine conversion to another format (which is essentially what you are saying) would be a derived work - legally not different from JPG - PNG I suspect. - thomas
Suggestion to replace use of generics with inheritence in future RM versions
David Moner wrote: I was exaclty thinking about this while seeing this proposal for the ITEM_STRUCTURE change to a VALUE_CLUSTER: http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model#openEHR2.xRMproposals-lowerinformationmodel-CandidateA.1AddVALUECLUSTER%2CRemoveITEMSTRUCTUREtypes It is an example of multiple inheritance not supported by Java and some other languages. Multiple inheritance is easily implemented in Java and C# ... via interfaces. The problem is that you often need to duplicate code. For example, in that diagram, VALUE_CLUSTER inherits from both ELEMENT and CLUSTER. In C# you can't do that, so you would probably declare ValueCluster as implementing two interfaces, IElement and ICluster; then you would copy the implementations of Element and Cluster into ValueCluster. Java would do something similar, although the naming convention of the interfaces might be different. (In C#, you might even decide to avoid some of the code duplication by using extension methods. Or maybe not ... it might cause more trouble than it solves.) Peter
Suggestion to replace use of generics with inheritence in future RM versions
Generally, you can do things in specifications that can't be reproduced in actual implementations. Since there is one specification, but many implementations, the list of things that the specification contains that aren't easy to implement varies widely between implementations. The things that are hard to implement are sometimes also very useful for expressing meaning and purpose. So a good specification balances between using things that are useful without using things that are too hard to use. With regard to generics, my normal implementation contexts do not support generics (XML/XSD, old versions of various languages), but I still find them useful in the specifications and would prefer the specification expressed itself cleanly Grahame On Fri, Mar 23, 2012 at 11:51 AM, Peter Gummer peter.gummer at oceaninformatics.com wrote: David Moner wrote: I was exaclty thinking about this while seeing this proposal for the ITEM_STRUCTURE change to a VALUE_CLUSTER: http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model#openEHR2.xRMproposals-lowerinformationmodel-CandidateA.1AddVALUECLUSTER%2CRemoveITEMSTRUCTUREtypes It is an example of multiple inheritance not supported by Java and some other languages. Multiple inheritance is easily implemented in Java and C# ... via interfaces. The problem is that you often need to duplicate code. For example, in that diagram, VALUE_CLUSTER inherits from both ELEMENT and CLUSTER. In C# you can't do that, so you would probably declare ValueCluster as implementing two interfaces, IElement and ICluster; then you would copy the implementations of Element and Cluster into ValueCluster. Java would do something similar, although the naming convention of the interfaces might be different. (In C#, you might even decide to avoid some of the code duplication by using extension methods. Or maybe not ... it might cause more trouble than it solves.) Peter ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- - http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065
Archetype authoring attribution
Hello, See in-line. 2012/3/22 Sam Heard sam.heard at oceaninformatics.com Hi David ** ** As the aim for all is interoperability of these things, I would hope that the information would be two way. I would suggest getting the new experts to comment on CKM and then derive a 13606 archetype (this is described in the 13606 standard). I would like that to be a future part of CKM but understand this may seem a little too controlling. ** ** If we start creating clinical content specifications in lots of places it will not really assist medicine a great deal. We estimate that it is costing health care dearly to do this again, again and again. Particularly when providers are interested in quality and sharing information. ** Of course, sharing these models is the only way to achieve global agreements I do not know which kind of changed they would require for the archetypes (if any) but I think they will be related to the real data available at the EHR system of the hospital. So they will be probably very localized changes. What clinicians have done right now is to translate most of the archetypes into Spanish, and that can be very easily incorporate into the openEHR CKM archetypes. ** That said, I would attribute the work to openEHR, the original authors, contributors and any new expert inputs. The license is to openEHR so I guess it is openEHR that needs attributing if you want to stay with the legal requirement. The SA does mean that you have to share the derived work under a similar license, something that some have been worried about. I am interested in your views on this. ** ** Cheers, Sam ** There is no doubt about the attributions and original references that must accompany the new archetypes (by the way, maybe in this sense the archetype metadata could be improved. Diego Bosc? has been working on this topic for his PhD). The question as I said before is about the authorship attribution and the meaning of derived work. See below. 2012/3/23 Thomas Beale thomas.beale at oceaninformatics.com if it is the same archetype, then it is a derived work. Which is fine, that's what CC-BY is for. My understanding of the term is that a machine conversion to another format (which is essentially what you are saying) would be a derived work - legally not different from JPG - PNG I suspect. - thomas Probably the problem is not so simple. I will put different options of things that can happen as an example (any new case is welcome): 1- If I take an openEHR archetype and modify/specialize it as a new openEHR archetype it is a derived work. 2- If I take an openEHR archetype and generate an implementation guide document of it, it is a derived work. The change of the format does not affect as you said. 3- If I take an openEHR archetype and generate software, schemas, etc. as Thomas said in a different thread they are not derivative works, they are original works based on the specification 4- If I take an openEHR archetype and generate another archetype of a different reference model based on it (could be 13606, HL7 CDA or whatever), is this a derivative work? The fact that the openEHR to 13606 conversion is nearly straightforward is not relevant here. It could be not the case. At the end someone (or some automatic process) will have to decide the correspondence between different reference models. For me this is exactly the same case as point 3. Thus, should not be considered a derivation but a new work which uses the original archetype as a reference, as could have been any textbook or paper. 5- If I take an openEHR archetype and generate an HL7 CDA implementation guide based on it, is this a derivative work? The answer to this depends on the previous one. The fact of representing clinical models in a different format (if we see ADL just as a format for defining models) should not change the essence of the problem as we saw in point 2. See that I'm just trying to set out the limits of the problem to find a general rule if it is possible. David -- 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/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/44753655/attachment.html
Are you doing an academic project using openEHR?
Hi Tom, we're here: http://gastros.codeplex.com/ Country: New Zealand Institution: The University of Auckland, National Institute for Health Innovation Team: Koray Atalag, Hong Yul Yang Project Description GastrOS is an endoscopic reporting application based on open standards: openEHR and MST. GUI is driven by Archetypes/Templates. It is part of our research at the University of Auckland to investigate software maintainability and interoperability. Uses openEHR.Net on CodePlex Cheers, -koray From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Thomas Beale Sent: Monday, 19 March 2012 3:30 a.m. To: Openehr-Technical Subject: Are you doing an academic project using openEHR? The academic projectshttp://www.openehr.org/shared-resources/usage/academic.html page on the website lists currently known projects. I am sure that there are more today. Please let us know if you have a project, and the details of it, we will post it on this page. - thomas beale __ Information from ESET NOD32 Antivirus, version of virus signature database 6991 (20120323) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/d8abbdb7/attachment-0001.html
Are you doing an academic project using openEHR?
Hi Thomas, Here is another entry from Sweden. Institution: Karolinska Institutet Team: Nadim Anani, Rong Chen, Sabine Koch Project Description: Ongoing PhD program to explore how semantic EHR technology, openEHR in particular, can be extended to support distributed clinical processes. This will be done by exploring how to incorporate clinical practice guidelines and clinical pathways into openEHR, using guidelines from the clinical domain of stroke care. /Rong On 18 March 2012 15:30, Thomas Beale thomas.beale at oceaninformatics.com wrote: The academic projects page on the website lists currently known projects. I am sure that there are more today. Please let us know if you have a project, and the details of it, we will post it on this page. - thomas beale ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Are you doing an academic project using openEHR?
Greetings, I think Opereffa can ask for a place in the academic works list. Institution: University College London, CHIME Team: Seref Arikan, Professor David Ingram, Project Description: Opereffa ( http://opereffa.chime.ucl.ac.uk ) is a proof of concept implementation of key aspects of openEHR specification. Its initial version explores the key requirements of implementation, all the way from a web based UI to a RDMS based back end. It includes some Eclipse plugins and Eclipse BIRT (Business Intelligence and Reporting Tools) integration. Kind regards Seref On Fri, Mar 23, 2012 at 10:48 AM, Rong Chen rong.acode at gmail.com wrote: Hi Thomas, Here is another entry from Sweden. Institution: Karolinska Institutet Team: Nadim Anani, Rong Chen, Sabine Koch Project Description: Ongoing PhD program to explore how semantic EHR technology, openEHR in particular, can be extended to support distributed clinical processes. This will be done by exploring how to incorporate clinical practice guidelines and clinical pathways into openEHR, using guidelines from the clinical domain of stroke care. /Rong On 18 March 2012 15:30, Thomas Beale thomas.beale at oceaninformatics.com wrote: The academic projects page on the website lists currently known projects. I am sure that there are more today. Please let us know if you have a project, and the details of it, we will post it on this page. - thomas beale ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/caa09786/attachment.html
Suggestion to replace use of generics with inheritence in future RM versions
://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org __?_ openEHR-technical mailing listopenEHR-technical at lists.?openehr.org openEHR-technical at lists.openehr.orghttp://lists.openehr.org/?mailman/listinfo/openehr-?technical_lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- [image: Ocean Informatics] *Thomas Beale Chief Technology Officer, Ocean Informaticshttp://www.oceaninformatics.com/ * Chair Architectural Review Board, *open*EHR Foundationhttp://www.openehr.org/ Honorary Research Fellow, University College Londonhttp://www.chime.ucl.ac.uk/ Chartered IT Professional Fellow, BCS, British Computer Societyhttp://www.bcs.org.uk/ Health IT blog http://www.wolandscat.net/ * * ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/fe2a0e86/attachment-0001.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/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/fe2a0e86/attachment-0001.jpg
Archetype authoring attribution
On 23/03/2012 08:07, David Moner wrote: There is no doubt about the attributions and original references that must accompany the new archetypes (by the way, maybe in this sense the archetype metadata could be improved. Diego Bosc? has been working on this topic for his PhD). I would be very interested to see proposals for improvement of the meta-data structures. We could get these into ADL/AOM 1.5 - t
Suggestion to replace use of generics with inheritence in future RM versions
and inheritance in an appendix of Bertrand Meyer's Object Oriented Software Construction, 2nd edition. (http://se.ethz.ch/~meyer/??publications/acm/geninh.pdf http://se.ethz.ch/%7Emeyer/publications/acm/geninh.pdf seems to be the original paper that the appendix is based upon.) Generics can be simulated in a language with inheritance, but there is a cost: * Duplication of code. * Extra verbosity. I don't want to have either forced upon me. If I'm unfortunately forced to use a language that doesn't support generics, then I can always simulate it the generics with inheritance. But I certainly wouldn't want the specs to be obfuscated by hacks like that, thanks very much ;-) Peter __??_ openEHR-technical mailing list openEHR-technical at lists.??openehr.org openEHR-technical at lists.openehr.orghttp://lists.openehr.org/??mailman/listinfo/openehr-??technical_lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org __??_ openEHR-technical mailing listopenEHR-technical at lists.??openehr.org openEHR-technical at lists.openehr.orghttp://lists.openehr.org/??mailman/listinfo/openehr-??technical_lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- [image: Ocean Informatics] *Thomas Beale Chief Technology Officer, Ocean Informaticshttp://www.oceaninformatics.com/ * Chair Architectural Review Board, *open*EHR Foundationhttp://www.openehr.org/ Honorary Research Fellow, University College Londonhttp://www.chime.ucl.ac.uk/ Chartered IT Professional Fellow, BCS, British Computer Societyhttp://www.bcs.org.uk/ Health IT blog http://www.wolandscat.net/ * * __?_ openEHR-technical mailing list openEHR-technical at lists.?openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/?mailman/listinfo/openehr-?technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org __?_ openEHR-technical mailing list openEHR-technical at lists.?openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/?mailman/listinfo/openehr-?technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/664fa3c1/attachment-0001.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/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/664fa3c1/attachment-0001.jpg
Archetype authoring attribution
-- 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 Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/e3a13ff9/attachment.html
13606 revisited - list proposal
like a structured series, mainly because ACTIONs usually need to get recorded when they are done. IMO ACTION.time:DV_DATE_TIME could have the same semantics as ACTION.data.events[0].time, if ACTION.data:HISTORY and events[0]:POINT_EVENT. The easier example is a repetitive INSTRUCTION like give 5mg of XXX for 10h every 30m: * The ACTION would register the same information structure * The proposed POINT_EVENT of the ACTION could record the information like the current ACTION.time attribute * There is a series of ACTIONS recorded for the same INSTRUCTION (instead of creating one ACTION instance for each XXX administration, one ACTION could handle all the information, time series and data, for all the susbtance administrations for the same INSTRUCTION/ACTIVITY). For example, a regular IV drug administration _could_ in theory be represented by an ACTION with a HISTORY, each of whose events described the action (say: admin Morphine 20 mg IV) but to achieve this you would have to wait until all the administrations were done before writing the data. So for some hours it would look like no drugs were being administered, then a long series of them would suddenly appear in the EHR stretching back... days? I can't see the difference with the current ACTION model: the ACTION could be created when the administration starts, and the date/time of that event could be written in INTERVAL_EVENT.time attribute, and when the administration ends, the duration could be written in the INTERVAL_EVENT.width. Maybe I'm missing something here, but that's whay I understand. I am not saying ACTION is perfect - there have been suggestions for example that an ACTION + link + OBSERVATION structure should be available for when the prescribed 'action' was in fact a new observation, such as 'check patient reaction to drug'. It would be nice to discuss this proposals with more members of the community. I'm not saying we need to do the changes, what I say is lets discuss if we can improve the model in some way, analize the pros and cons, and write down a decision. I mean: we need to try to not leave these kind of discussions die on the maillist, this things are valuable assets that could be explored/exploted in the future. Another question of time comes up with EVALUATION - e.g. the diagnosis archetype. This is full of times, and tries to follow a disease course model. Currently there is no RM class for this, but if a standardised temporal disease model were agreed across medicine, I suppose there is no reason why not. But it also is not a simple HISTORY - it is more 'bumpy'... and I don't know if there is any agreed standard model of this. Maybe is something like a HISTORYENTRY or a HISTORYCOMPOSITION? Thanks a lot for sharing, Kind regards, Pablo. ___ 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/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/5d1c932d/attachment-0001.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/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/5d1c932d/attachment-0001.jpg
Units, Quantities, etc
, the question of units is thorny. Although we technical people would like to mandate UCUM or some other well-designed computable syntax, on its own, it won't work. There seem to be two reasons for this: it doesn't take care of the need for a displayable form of units, e.g. the computable form 'mcg' or 'ug', where as the displayable is '?g' (Greek mu followed by 'g') it doesn't take care of 'units' like puffs, tablets, patches, vials, strips, and other discrete delivery units it doesn't take care of discrete delivery units per time, e.g. '2 puffs / hour' Grahame and others have already done a lot of thinking on this here - there are a lot of excellent examples from Linda Bird on the Singapore programme. The more I think about the last two above, the more I think it is not about quantities per se but about an administration directive (how the patient should take something). Trying to make Quantity do that kind of stuff doesn't make sense to me - there is obviously a Quantity to indicate the dose in scientific form, but another data element may be needed to indicate how (in what discrete measures) to take the medication. I would therefore expect a distinct data element in the Medication Cluster archetype rather than a re-engineered Quantity type to deal with these last two. For the first one - displayable v computable, we will need a CR to change DV_QUANTITY, and make it work like the FHIR Quantity - i.e. have a second units field. Some of my earlier thoughts are actually on the above wiki page - the concept of a DiscretisedQuantity type inheriting from Quantity, which I think is also a reasonable alternative. what do others think? - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/7f557f8b/attachment.html
