SNOMED-CT postcoordination support in ADL
Hello Luis, I think having available a terminology service is some kind of a prerequisite (which I don't agree with). I think openEHR should probably assume the IHTSDO postcoordination syntax for these cases. It would be interesting to know if someone has used or is planning to use this syntax for other terminologies. 2015-04-27 13:49 GMT+02:00 Luis Marco luismarco at gmail.com: Hi, I am trying to annotate a set of archetypes with SNOMED-CT. I have noticed that in the archetype editor, when I introduce a postcoordinated expressions, the editor deletes the bars and creates a continuous alphanumeric string. Do you know if postcoordinated expressions can be set in the ontology section of the archetype? What are current approaches to overcome this? A solution could be to insert an id representing the postcoordinated expression and resolve it in my terminology server. However, this would hide knowledge to other implementations based on that archetype outside the domain of my server. Example: Let?s assume (without caring about the correctness of it) that we had an archetype for the concept ?Laparoscopic appendectomy? and we annotate at000 with (80146002|Appendectomy|:424226004|Using device|=86174004|Laparoscope|). The result in the ADL is: [at] = [SNOMED-CT::80146002Appendectomy424226004Usingdevice86174004Laparoscope] Thanks, Luis ___ openEHR-implementers mailing list openEHR-implementers at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
SNOMED-CT postcoordination support in ADL
Hi Diego, We?re intending to use the IHTSDO syntax (or the idea) for semantic annotation of computational physiology models - using other domain specific languages like CellMLhttp://www.cellml.org/, FieldMLhttp://physiomeproject.org/software/fieldml/about, SBML etc. There are semantic tools like SemGenhttp://sbp.bhi.washington.edu/projects/semgen or openCORhttp://www.opencor.ws/ which support linking model items to external terminology/ontology similar to Archetypes. The idea is to couple clinical data and related physiological models to create personalised/predictive decision support tools using shared knowledge resources and I think this syntax has a great merit. Cheers, -koray -Original Message- From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Diego Bosc? Sent: Tuesday, 28 April 2015 8:08 p.m. To: For openEHR implementation discussions Cc: openeh technical Subject: Re: SNOMED-CT postcoordination support in ADL Hello Luis, I think having available a terminology service is some kind of a prerequisite (which I don't agree with). I think openEHR should probably assume the IHTSDO postcoordination syntax for these cases. It would be interesting to know if someone has used or is planning to use this syntax for other terminologies. 2015-04-27 13:49 GMT+02:00 Luis Marco luismarco at gmail.commailto:luismarco at gmail.com: Hi, I am trying to annotate a set of archetypes with SNOMED-CT. I have noticed that in the archetype editor, when I introduce a postcoordinated expressions, the editor deletes the bars and creates a continuous alphanumeric string. Do you know if postcoordinated expressions can be set in the ontology section of the archetype? What are current approaches to overcome this? A solution could be to insert an id representing the postcoordinated expression and resolve it in my terminology server. However, this would hide knowledge to other implementations based on that archetype outside the domain of my server. Example: Let?s assume (without caring about the correctness of it) that we had an archetype for the concept ?Laparoscopic appendectomy? and we annotate at000 with (80146002|Appendectomy|:424226004|Using device|=86174004|Laparoscope|). The result in the ADL is: [at] = [SNOMED-CT::80146002Appendectomy424226004Usingdevice86174004Laparosco pe] Thanks, Luis ___ openEHR-implementers mailing list openEHR-implementers at lists.openehr.orgmailto:openEHR-implementers at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.o penehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.orgmailto: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/20150428/bcf60a22/attachment-0001.html
Licensing of specs and artifacts
. Many open source projects on the other hand see forking-possibilities as a healthy emergency safeguard against potentially poor future governance/leadership. I agree with Bert in the Linkedin-discussion, that it will most likely be possible to continue creating openEHR-compatible software from currently published CC-BY-ND licensed specifications, even if there is a ?hostile takeover? or deadlock of the organization. Especially if all computable specification items (class definitions etc.) are released under Apache 2 license (I believe that is the current intention). What is published is already out there and free to use, it can never be taken back. The ND-clause mainly causes problems for those that in a deadlock/takeover situation want to fork the project and keep working on _new_ future/updated versions of the specification. What the ND actually in practice would protect openEHR against is less obvious to me though. Thus the ND only adds to the confusion/FUD without bringing any obvious big benefit. (W3C gets away with it though.) Compatibility issues are better managed through testing and certification than licensing. Licenses won?t stop errors, or non-conformance. Phew? amazing if you had the energy to read all the way down to here. Tom, regarding what it means to sell Share-Alike (SA) artifacts, I think you can compare that to http://www.gnu.org/philosophy/selling.html Best regards, Erik Sundvall Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or 010-1036252 in Sweden) Li?: erik.sundvall at lio.se http://www.lio.se/itc/ http://www.lio.se/testbadd LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ On Thu, Oct 2, 2014 at 4:14 PM, Grahame Grieve grahame at healthintersections.com.au wrote: Controlling Conformance: CC-0 just means 'public domain', no copyright. How do you exert any kind of control (which you mention) over the conformance not being messed with? The point of a trademark is that you can control what the name means. We say that we define what conformance to FHIR means. We expect that conformance will be messed with - that's just how it works. But no one else is allowed to say what it means to be conformant to FHIR because hl7 owns that trademark Also, we don't assert any rights around copying, but that doesn't mean that hl7 isn't the recognised author. Copyright: I don't see any harm in having a copyright notice if the original author(ity) demands it, e.g. Nehta is like this. Copyright is kind of useless in the land of software and formal models anyway, it's the licence that counts. Well, the way I understand it, with FHIR now, someone can asset a copyright on a derived work, but they could not effectively enforce copyright provisions on the content they include from the FHIR spec. There might not be much left... Attribution: Current thinking has been that if archetypes are copyrighted to whomever, the licence-to-use would require attribution, which just means listing authors. I think the value here is that artefact users know that wide consultation and expertise went into the artefact. I don't think there's any relationship between attribution and copyright. We could choose to attribute if we wanted to. Actually, we do it at the spec level: http://hl7.org/implement/standards/fhir/credits.html#credits Would't that 'contributors' list disappear under the new FHIR approach? No, they're still the contributors. Grahame - http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065 -- This e-mail message is intended exclusively for the addressee(s). Please inform us immediately if you are not the addressee. ___ 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/20150428/8080bbdd/attachment-0001.html
Licensing of specs and artifacts
] = com.bosca [original_publisher] = Bosca Enterprises [MD5-CAM-1.0.1] = D5C7A064A7345211256376F748D97B6B [custodian_namespace] = com.bosca [custodian_organisation] = Bosca Enterprises We are in the final stages of preparing a 'beginner's guide' that explains this stuff in more detail. Does the author change? I would probably say no, if the clinical content is unchanged. Probably the source archetype will also need to be referenced somehow. We would expect to see that attribution in References - see above What else should be changed/added? In the new world, you would need to change the namespaces, particularly as creating 13606 versions are definitely 'new' archetypes. I assume that also a 'generated' field should be added (I know ADL 2 has this as a explicit field ;) so for the moment probably the best is to store everything we can't put elsewhere in other_details. I would expect 'generated' to apply to same ref model ADLS-ADL kinds of transforms only but interesting question. @Thomas ?? Can the resulting ADL be publicly distributed? Yes, absolutely, as long as you do not try to re-sell the 13606 archetypes with a closed-source licence!! Ian -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150428/0ceb8c7e/attachment.html
Licensing of specs and artifacts
-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.orgmailto: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/20150428/81ab4122/attachment-0001.html
