Polishing node identifier (at-codes) use cases.
Op 20-9-2013 17:01, Thomas Beale schreef: > it's simpler than you think - we made that property mandatory so that > programmers would never get a null exception. Must have been along time ago, nowerdays, programmers have no problem handling a null property. I wonder what the idea behind stuffing the archetype_id in the archetype_node_id property is? Here you make it harder for programmers because the archetype_id has another syntax in archetype-paths then the archetype_node_id has, and anyway, lots of other functions, and a programmer has to check the string-layout to find out if it is an archetype_id or an archetype_node_id. It also blocks the possibility to store the "at"-code for the root, and check the ontology for its contents. Bert
Polishing node identifier (at-codes) use cases.
On 20/09/2013 12:01, Diego Bosc? wrote: > By the way, I just found out that archetype_node_id from locatable > class from the reference model (common_im document, page 22) is > obligatory (!!!). > > The meaning of the attribute is as follows: > "Design-time archetype id of this node taken from its generating > archetype; used to build archetype paths. Always in the form of an > ?at? code, e.g. ?at0005?. This value enables a "standardised" name for > this node to be generated, by referring to the generating archetype > local ontology. At an archetype root point, the value of this > attribute is always the stringified form of the archetype_id found in > the archetype_details object." > If you have to put the at code and the archetype does not have it, > what do you put there? What should expect the systems? > > > There is even an invariant defined as "Archetype_node_id_valid: > archetype_node_id /= Void and then not archetype_node_id.is_empty" > How does this work in your current implementations when sometimes the > at code is not present? it's simpler than you think - we made that property mandatory so that programmers would never get a null exception. If it doesn't contain an at-code or an archetype id, it can be empty (but not null), or (what the ADL workbench currently does) - it can contain a dummy id like 'unknown' that the software can easily spot and strip out. I'm not against making it an optional property if developers would prefer that. - thomas
Rich text format in DV_TEXT
Hello, we are using an archetypes from the CKM called *openEHR-EHR -EVALUATION.clinical_synopsis.v1*. Over there is an DV_TEXT element called * Synopsis* One of our clients want to use rich text format inside that field. According the specification it is not allowed to put formatted text over there. I rather should use a DV_PARSABLE. How should i handle this correctly? The options i see are : - specialise the archetype and add an DV_PARSABLE, and leaf the existing DV_TEXT empty - create my own archetype where I set the Synopsis element to a DV_PARSABLE beside this question, i wonder if it will be better to give the DV_TEXT datatype the possibility to put over there rich text. If we also add the parameter formalism to it, there is no really need any more for a DV_ PARSABLE. -- Alessandro Torrisi -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130920/401ed47b/attachment.html>
Polishing node identifier (at-codes) use cases.
By the way, I just found out that archetype_node_id from locatable class from the reference model (common_im document, page 22) is obligatory (!!!). The meaning of the attribute is as follows: "Design-time archetype id of this node taken from its generating archetype; used to build archetype paths. Always in the form of an ?at? code, e.g. ?at0005?. This value enables a "standardised" name for this node to be generated, by referring to the generating archetype local ontology. At an archetype root point, the value of this attribute is always the stringified form of the archetype_id found in the archetype_details object." If you have to put the at code and the archetype does not have it, what do you put there? What should expect the systems? There is even an invariant defined as "Archetype_node_id_valid: archetype_node_id /= Void and then not archetype_node_id.is_empty" How does this work in your current implementations when sometimes the at code is not present? 2013/9/2 Thomas Beale > On 02/09/2013 08:49, David Moner wrote: > > > > > 2013/9/2 Thomas Beale >> >> >> Well, LinkEHR is a real implementation in use by several organizations, >> and we think these identifiers are needed both technically and >> methodologically, so we will continue our way of doing thing :-) >> >> >> To be clear, I didn't mean modelling tools, I meant production EHR >> systems that use the resulting models. >> > > Of course, me too: > http://www.eurorec.org/news_events/newsArchive.cfm?newsID=239 > > > Yep, I know about that (the more systems the better!). But I would be > interested to know what the clinical models look like - are they posted > anywhere? And what is the clinical modelling process? I would think after a > few years of it, there would be some ideas on which nodes need to be > defined and which don't? I'm just trying to get some evidence here, so we > can better understand the right set of rules to use in the formalism and > its tooling. > > - thomas > > > > > ___ > 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/20130920/a0a089a9/attachment.html>
AOM 1.5 update published
The latest version of AOM 1.5 is now published here <http://www.openehr.org/releases/trunk/architecture/am/aom1.5.pdf>. Changes: * remodelling / rationalisation of C_PRIMITIVE_OBJECT classes (types expressing constraints on Integer, Boolean, Date, String, Terminology_code etc) * simplification of Tuple model, to achieve the same effect as before - complete replacement of openEHR 'special syntax' o all ADL 1.4 openEHR archetypes now parse to the new tuple syntax o the 'openEHR Archetype Profile' is now obsolete These changes have all been implemented and validated in the ADL Workbench, which will be released in a new beta in the next week or so. The Java implementation group at Marand are working on upgrading the Java ADL compiler to the same models. Any questions, complaints, wish list, etc, as usual - please post here. - thomas beale -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130920/ff30505f/attachment.html>
