Archetype & Template ANNOTATIONS - requirements?
Hi! On Tue, Jan 4, 2011 at 02:07, Heath Frankel < heath.frankel at oceaninformatics.com> wrote: > Hi Tom and Erik, > > > > that's two innovative ideas in one post - you must have had a great > christmas ;-) > 1. in the 'languages' space, allow formalisms as well - e.g. "rdf" > 2. the annotation structure, simple as it is, is in fact sufficient (or > close) to support representation of RDF-like triples. > > *[HKF: ] I think we are overloading the use of the annotations for two > different purposes and should look at the distinction made in XML Schema > where they have documentation and appinfo, where the former is used by > humans and the later by applications for things such as GUI directives.* > Overloading or not, the technical structure would be very similar. I don't think the border between data for human and machine use always will be completely clear. You might want to annotate information intended mostly for human consumption (i.e. documentation) by using a small ontology constraining allowed values under certain field names. Tools can in such cases easily show localized human language labels from ontologies instead of the URIs (owl ontologies have multilingual support). However if there are strong reasons to split "documentation" and "appinfo" at root level rather than with the "language" in the annotation section, then of course that would be OK. The main thing is that we need a good place to experiment with some formalized machine readable annotations (or appinfo if you prefer to call it that). Using RDF-ideas to make connections out from archetypes and templates to RDF/RDFS/OWL entities might open many possibilities. While we are at it, what bout the other way around? Is there an official algorithm to convert an archetype/template-node to a URI (perhaps a URN) that can be used to reference archetypes and archetype nodes in semantic web formalisms? If not, then perhaps we should create one (in a separate discussion thread perhaps). I think we have a lot of owl wizards reading this, don't be afraid to dive in to the discussion. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 ** -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110104/0de19c40/attachment.html>
Clinical Documents, openEHR, 13606, CDA and CCR
t round of tooling will need make it easier for designers and not create constraints where none are required. The main opportunity for which everyone will be grateful is if we can use openEHR archetypes to create consistent CDA and provide the transforms required to move seamlessly from CDA to openEHR and back. This provides a single source of truth and is what many people are seeking. What we need to take this further is: 1. A standard transformation of a template of an openEHR Composition to HL7 CDA ? converting EHR attributes to CDA attributes ? that does not require explicit modelling of data that is already captured in the openEHR RM. The transformation may require renaming of openEHR RM attributes that are specific for that the template as CDA documents may have different labels that are the same thing in an EHR system (e.g. a prescription may have a ?prescriber? whereas a document may have an ?author? where both are the legal creator of the document). 2. An archetype to CDA transform (and back) that labels the CDA data in a way that it is clear which archetype this CDA data conforms to. This is needed for each archetype and should be available on CKM. The openEHR RM should also consider adding a CLUSTER to participation to allow structured data or include participation data in the composition. Other_participations may be the location for this with IDs that are referenced within the composition ? but this is not the planned use and will need some consideration. Some may argue that this should be from the demographic model but I do not think so. Thoughts? Cheers, Sam Heard ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110104/0636419b/attachment.html>
Archetype & Template ANNOTATIONS - requirements?
Hi Tom and Erik, that's two innovative ideas in one post - you must have had a great christmas ;-) 1. in the 'languages' space, allow formalisms as well - e.g. "rdf" 2. the annotation structure, simple as it is, is in fact sufficient (or close) to support representation of RDF-like triples. [HKF: ] I think we are overloading the use of the annotations for two different purposes and should look at the distinction made in XML Schema where they have documentation and appinfo, where the former is used by humans and the later by applications for things such as GUI directives. I can't really comment on these ideas other than to say they look quite interesting - I had not thought of either before. The main decision for the ADL 1.5 spec and implementation is: whether to stick with annotations as a hash of Strings, with String keys, or to make the keys some kind of codes, defined elsewhere in the archetype. At the moment I am inclined to leave it as all Strings, let people experiment with it, and decide to enhance it once people have messed around with it. [HKF: ] I agree with this (as per my other email) Maybe Koray and other implementers might want to work on some of their own ideas, plus Erik's, within some archetypes. The next ADL workbench beta (any day now) will support String-only annotations, arranged per language as shown in an earlier post. We don't have an XML version of this yet, and would rather hold off on the XML version until we are more slid with the ADL version. But - advice, disagreement from others is welcome (or even better if others want to mess around with the XML on their own and feed it back in here). [HKF: ] The Operational Template XML schema used by the Ocean Template Designer defines an annotations element, which is a sibling of the description and definitions elements. The type of the annotations element is defined as follows where the StringDictionaryItem is defined in the existing openEHR Resource.xsd. Regards Heath Frankel Product Development Manager Ocean Informatics -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110104/180b7ed8/attachment.html>
