openEHR-RM-LINK discussion - now also on mailing list :-)
Hi Erik, I am still catching up from some time-off, interesting discussion seem to happen while I am away... I will start with my comments at the start and likely to respond to later responses. Heath Some of the interesting bits I've picked up so far from discussions: - Maybe it would be a good idea to make LINK inherit from LOCATABLE and thus become archetypable in itself [HKF: ] LINK does not need to be LOCATABLE to be archetyped unless you are talking about LINK being the archetype root. I don't see why we need to do this, a LINK only make sense to me within the context of its parent. If there truly is a need for LINK to be an archetype root then perhaps the ARCHETYPED association should be moved to PATHABLE. - Tooling support for using LINK in archetypes is currently poor or non existent [HKF: ] This is partly my fault, Sam started supporting LINK in the openEHR Archetype Editor but I could not see how the constraints being specified could be usable at the archetype level, so we stopped its development until we had better understanding of the requirements. - There is very little (if any) reported usage experience of LINK in openEHR [HKF: ] True, although this is changing, we are using it in a significant development exactly in the way that Rong talks about his response, to relate content within the same thread of care, in particular an indication of proposed care and the plan of actions for that proposal. We are implementing these in the application without archetyping them because we still think this is not something that can be archetyped and we are learning how they can be used at the template level (as indicated by Rong). - I believe the NHS has somewhat explored LINK usage in LRA using ISO 13606 - If archetyping LINKS, then it would in _some_ cases be desirable to be able restrict the type of the target, especially defining what archetypes the target objects must adhere to (similar to the archetype slot mechanism). [HKF: ] Absolutely, this is was evident to me when I asked Sam to stop his support for LINKs using RegEx on the target uri. It needs to be some sort of AQL or A-Path expression. Tom's target type is somewhere towards it but as indicated elsewhere we need to constrain it further to an archetype ID or even an archetype path, but definitely not a data path/uri. Please fill in with nore details and thoughts. Implementers, would it have a big impact on your implementations if LINK was made LOCATABLE? (Let's say in v 1.0.3) [HKF: ] I am against this proposal. I originally thought this was necessary for PARTICIPATION to allow it to be archetyped, but now I don't. I realised that for an item to have a node_id in the archetype, it doesn't need to have a node_id attribute in the class. As long as the constraints on the class attributes in the archetype are distinct for each class constraint (when you have multiple LINK constraints, the meaning/type/target_* combinations are disjoint), then we have enough information to match a data instance at runtime. The node_id in the archetype is only necessary to allow further constraints to be applied on the node in specialised archetypes/templates. The need to populate a name on each LINK would be quite painful and redundant as it is now for every other LOCATABLE. Although the existing Type attribute could be made a function taking the value of Name as is done in the Demographic RM. If this is necessary so that we can create a LINK archetype then I suggest moving the association to the ARCHETYPED class to the PATHABLE class, this would be a non-breaking change. I wonder, is it currently safe to archetype the DV_EHR_URI used in the target attribute of LINK just using a string matching pattern or do we need additional mechanisms? The URI value represents an identifier of some node inside a versioned object, do string patterns matching DV_EHR_URI values cover for all kinds of target range restrictions we'd likely want to express if archetyping LINKs? [HKF: ] As I indicated, I don't believe this is useful and why we stopped development of LINK in the archetype editor. Maybe they actually do work using wildcards in the right places? [HKF: ] Yes, I guess if you ignored all the first part of the URI and just provide the data path part, then it may be possible. But as I indicated above, I think it needs to be more of an archetype path than a data path. I realise difference is semantic but relevant in this case. I think A-Path or AQL (or ADL rules) would be a better representation than a URI. I know Sam was of the opinion early that URIs could be used for queries, and this support by the RESTful service community, this is probably the origins of his intent to use a URI constrain for LINK target. I just don't see URIs supporting more complicated query requirements, hence AQL (and I am also a fan of A-Path) How tricky will it be to implement that constraint checking at runtime data creation? [HKF: ]
openEHR-RM-LINK discussion - now also on mailing list :-)
Hi Erik 1. Will the XML schema get updated to make sure patient data instances carry along the archetype/template inheritance in a good way? [HKF: ] I have spoken with Tom on this topic considerable, we are looking at extending the ARCHETYPED class to support a list of archetype_ids (similar to HL7 CDA class having multiple template_ids) to support matching on any of these in queries. We think this is the least impact change while supporting queries without the need for an external archetype ontology service. 2. Should AQL be modified to include a convenient way of specifying if we are asking for data only entered using a specific archetype or if we are looking for data entered using that archetype any of its specialisations? (Previously wildcards might have worked depending on interpretation/implementation of AQL documentation, now with the 1.5 change they definitely won't.) What should be the default behaviour if just writing an archetype name in part of the query? [HKF: ] Yes, RegEx expression will not be useful any more. Quoting from the 01 Feb 2010 version of Knowledge Artefact Identification Section 5.3.3: ...given an archetype X used to create data, the following archetypes could be used for querying: . X, i.e. exact same version, revision commit; . any previous revision of X; . any of the specialisation parents of X; . any previous revision of any of the specialisation parents of X. Does the could be used wording here mean that the default behaviour of an AQL response should be to retrieve data matching all these cases? [HKF: ] From my discussions with the clinicians, this seems what they want. When we designed AQL to use RegEx based on the structured archetype IDs, it seemed technically reasonable that we wanted to query a generic archetype without its specialisations so we made it explicit to request a generic archetype and its specialisations. This will need to be considered in the next iteration of query engines. We probably need some implementation guidance on this (along with many other topics). 3. Will the semantics and syntax of the path strings used in PATHABLE objects be affected? Where is that path syntax actually defined, is chapter 11 of the Archetype Overview the authoritative source? Has it ever been possible to find data from specialisations using calls to methods of PATHABLE? Should it be? [HKF: ] I would not expect paths to have the same subsumption rules as queries, I would expect paths to be specific to a data instance. Heath
openEHR-RM-LINK discussion - now also on mailing list :-)
Hi!
A question regarding naming/identifiers.
According to
http://www.openehr.org/releases/1.0.2/architecture/am/archetype_semantics.pdf
parts of the grammar for identifiers is...
archetype_id: qualified_rm_entity ?.? domain_concept ?.? version_id
qualified_rm_entity: rm_originator ?-? rm_name ?-? rm_entity_name
domain_concept: concept_name { ?-? specialisation }*
Surely you must just have been sloppy in...
http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/openEHR_examples/link_archetypes/
...where the identifiers as of this writing (Revision 20) are:
openEHR-EHR-EVALUATION.problem.v1.adls
openEHR-EHR-EVALUATION.diagnosis.v1.adls
openEHR-EHR-EVALUATION.diagnosis_sweden.v1.adls
openEHR-EHR-LINK.indication.v1.adls
Should not the identifiers instead be:
openEHR-EHR-EVALUATION.problem.v1.adls
openEHR-EHR-EVALUATION.problem-diagnosis.v1.adls
openEHR-EHR-EVALUATION.problem-diagnosis-sweden.v1.adls
openEHR-EHR-LINK.indication.v1.adls
Or have the identifier syntax and semantics requirements changed in
ADL/AOM 1.5? I hope note, because that would make AQL querying
implementation a lot harder when asking for an archetype including any
of it's speicialisations...
Isn't there any automatic check in AWB that specialisation identifiers
are correct?
Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
openEHR-RM-LINK discussion - now also on mailing list :-)
Erik Sundvall wrote: openEHR-EHR-EVALUATION.problem.v1.adls openEHR-EHR-EVALUATION.diagnosis.v1.adls openEHR-EHR-EVALUATION.diagnosis_sweden.v1.adls openEHR-EHR-LINK.indication.v1.adls Should not the identifiers instead be: openEHR-EHR-EVALUATION.problem.v1.adls openEHR-EHR-EVALUATION.problem-diagnosis.v1.adls openEHR-EHR-EVALUATION.problem-diagnosis-sweden.v1.adls openEHR-EHR-LINK.indication.v1.adls Or have the identifier syntax and semantics requirements changed in ADL/AOM 1.5? This has changed in ADL 1.5. The hyphen is no longer used. I'm sure I remember Thomas starting a discussion about this on the mailing list about a year ago. - Peter Gummer
openEHR-RM-LINK discussion - now also on mailing list :-)
Shouldn't archetype identifiers and file names be separated? 2010/10/28 Peter Gummer peter.gummer at oceaninformatics.com: Erik Sundvall wrote: openEHR-EHR-EVALUATION.problem.v1.adls ? openEHR-EHR-EVALUATION.diagnosis.v1.adls ? ? ?openEHR-EHR-EVALUATION.diagnosis_sweden.v1.adls openEHR-EHR-LINK.indication.v1.adls Should not the identifiers instead be: openEHR-EHR-EVALUATION.problem.v1.adls ? openEHR-EHR-EVALUATION.problem-diagnosis.v1.adls ? ? ?openEHR-EHR-EVALUATION.problem-diagnosis-sweden.v1.adls openEHR-EHR-LINK.indication.v1.adls Or have the identifier syntax and semantics requirements changed in ADL/AOM 1.5? This has changed in ADL 1.5. The hyphen is no longer used. I'm sure I remember Thomas starting a discussion about this on the mailing list about a year ago. - Peter Gummer ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
openEHR-RM-LINK discussion - now also on mailing list :-)
The draft spec for 1.5 knowledge identifiers can be accessed via http://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts The '-' based specialisation syntax is proposed to be dropped, as it became very unweildy once you srart to consider how to handle namespaces within specialisations , particularly when the specialisation has a different namespace to the parent. It gets even more confusing when you add in the requirements for templates and complex archetypes i.e aggregations. To get around the querying problem that Erik describes, it is proposed to carry the specialisation inheritance list in the data. Archetype identifiers are separate from filenames, but in practice, archetypes and templates do find themselves expressed as individual files on filesystems and it can be all too easy for versions/ namespaces to get mixed up, if the file names do not carry the same sort of uniqueness as is embodied in the offical archetype_id. From Idenitifer document 5.3.3 The other possibility is to include archetype lineage information in the data itself. This could be a modified form of the identifier reference in the case of specialised archetypes to allow lineage information to be stored. TBD_14: proposed RM change: ARCHETYPED.archteype_id - List[ARCHETYPE_ID]; in LOCATABLE, just continue to use the direct archetype id as currently done. The simplest form of this would be as a list of operational identifiers, e.g. se.skl.epj::openEHR-EHR-EVALUATION.genetic_diagnosis.v1.12, org.openehr.ehr::openEHR-EHR-EVALUATION.diagnosis.v1.29, org.openehr.ehr::openEHR-EHR-EVALUATION.problem.v2.4 Ian Dr Ian McNicoll office / fax? +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst,?Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 28 October 2010 09:46, Diego Bosc? yampeku at gmail.com wrote: Shouldn't archetype identifiers and file names be separated? 2010/10/28 Peter Gummer peter.gummer at oceaninformatics.com: Erik Sundvall wrote: openEHR-EHR-EVALUATION.problem.v1.adls ? openEHR-EHR-EVALUATION.diagnosis.v1.adls ? ? ?openEHR-EHR-EVALUATION.diagnosis_sweden.v1.adls openEHR-EHR-LINK.indication.v1.adls Should not the identifiers instead be: openEHR-EHR-EVALUATION.problem.v1.adls ? openEHR-EHR-EVALUATION.problem-diagnosis.v1.adls ? ? ?openEHR-EHR-EVALUATION.problem-diagnosis-sweden.v1.adls openEHR-EHR-LINK.indication.v1.adls Or have the identifier syntax and semantics requirements changed in ADL/AOM 1.5? This has changed in ADL 1.5. The hyphen is no longer used. I'm sure I remember Thomas starting a discussion about this on the mailing list about a year ago. - Peter Gummer ___ 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-RM-LINK discussion - now also on mailing list :-)
In ADL 1.5 they are - you can name the archetype files however you like, and put them where you like. - thomas On 28/10/2010 09:46, Diego Bosc? wrote: Shouldn't archetype identifiers and file names be separated? 2010/10/28 Peter Gummerpeter.gummer at oceaninformatics.com: Erik Sundvall wrote: openEHR-EHR-EVALUATION.problem.v1.adls openEHR-EHR-EVALUATION.diagnosis.v1.adls openEHR-EHR-EVALUATION.diagnosis_sweden.v1.adls openEHR-EHR-LINK.indication.v1.adls Should not the identifiers instead be: openEHR-EHR-EVALUATION.problem.v1.adls openEHR-EHR-EVALUATION.problem-diagnosis.v1.adls openEHR-EHR-EVALUATION.problem-diagnosis-sweden.v1.adls openEHR-EHR-LINK.indication.v1.adls Or have the identifier syntax and semantics requirements changed in ADL/AOM 1.5? * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101028/466330a1/attachment.html
openEHR-RM-LINK discussion - now also on mailing list :-)
As Peter said, ADL 1.5 changes this. The hyphen is not nedeed (but it is accepted to allow backward compatibility). See http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf and also http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/dist_dev_model.pdf for a full description of why this is. - thomas On 28/10/2010 09:36, Peter Gummer wrote: Erik Sundvall wrote: openEHR-EHR-EVALUATION.problem.v1.adls openEHR-EHR-EVALUATION.diagnosis.v1.adls openEHR-EHR-EVALUATION.diagnosis_sweden.v1.adls openEHR-EHR-LINK.indication.v1.adls Should not the identifiers instead be: openEHR-EHR-EVALUATION.problem.v1.adls openEHR-EHR-EVALUATION.problem-diagnosis.v1.adls openEHR-EHR-EVALUATION.problem-diagnosis-sweden.v1.adls openEHR-EHR-LINK.indication.v1.adls Or have the identifier syntax and semantics requirements changed in ADL/AOM 1.5? This has changed in ADL 1.5. The hyphen is no longer used. I'm sure I remember Thomas starting a discussion about this on the mailing list about a year ago. - Peter Gummer * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101028/f426b584/attachment.html
openEHR-RM-LINK discussion - now also on mailing list :-)
The culprit is lack of time... as usual So far I have created a simple test LINK archetype, showing how a jurisdiction, in this case Sweden, might use it. To see it, follow these steps: 1. if you don't have it, download the ADL workbench (http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.html) 2. SVN checkout or update http://www.openehr.org/svn/knowledge2/ - this will get both the latest test archetypes, and the required updated RM schema file, called openehr_rm_200exp.dadl 3. you will have to install the new RM schema manually, by copying it from the rm_schemas directory in the above checkout, to the directory of the same name in the ADL Workbench install area / rm_schemas directory (i.e. C:\program files\openEHR\ADL workbench\rm_schemas, on Windows). 4. To see the test archetypes, create a profile in the ADL Workbench for the path ...\knowledge2\TRUNK\archetypes\openEHR_examples\link_archetypes (see here for help - http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/learning_adl_15.html) 5. you can now compile the test Swedish specialisation EVALUATION archetype, that adds a standard LINK archetype to the existing CKM problem-diagnosis archetype I have added a constraint of the 'target' property of the LINK classes, based on a new experimental 'target_type' computed property of the DV_EHR_URI class (added in the new schema). This shows how it would be possible to constraint the target to OBSERVATIONs, but I am pretty sure something stronger than that is needed, more like the semantic archetype slot constraints described here - http://www.openehr.org/wiki/display/spec/Towards+a+definition+of+%27slot%27+semantics . If anyone has problems with these steps, let me know on this list, and I will provide further information, but normally the above should be enough. Others are welcome to have commit access to the knowledge2 repository, and help to grow the test archetype set, as well as experiment with ideas on the RM schemas is welcomed. - thomas beale On 27/10/2010 09:56, Erik Sundvall wrote: Hi! I hear of a lot of interesting off-line discussions regarding the openEHR RM object named LINK. I guess they have not yet reached the mailing list because of time restrictions and/or the exploratory/initial nature of the discussions. But now let's get more good brains involved... Just to make sure we talk about the same thing, it is the class LINK described in section 3.2.4 in http://www.openehr.org/releases/1.0.2/architecture/rm/common_im.pdf and in XML schema http://www.openehr.org/releases/1.0.2/its/XML-schema/documentation/Structure.xsd.html#h518145503 (An excerpt from the spec is attached by the end of this mail) Some of the interesting bits I've picked up so far from discussions: - Maybe it would be a good idea to make LINK inherit from LOCATABLE and thus become archetypable in itself - Tooling support for using LINK in archetypes is currently poor or non existent - There is very little (if any) reported usage experience of LINK in openEHR - I believe the NHS has somewhat explored LINK usage in LRA using ISO 13606 - If archetyping LINKS, then it would in _some_ cases be desirable to be able restrict the type of the target, especially defining what archetypes the target objects must adhere to (similar to the archetype slot mechanism). Please fill in with nore details and thoughts. Implementers, would it have a big impact on your implementations if LINK was made LOCATABLE? (Let's say in v 1.0.3) I wonder, is it currently safe to archetype the DV_EHR_URI used in the target attribute of LINK just using a string matching pattern or do we need additional mechanisms? The URI value represents an identifier of some node inside a versioned object, do string patterns matching DV_EHR_URI values cover for all kinds of target range restrictions we'd likely want to express if archetyping LINKs? Maybe they actually do work using wildcards in the right places? How tricky will it be to implement that constraint checking at runtime data creation? Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 Excerpts from section 3.2.4 in common_im.pdf: Purpose: The LINK type defines a logical relationship between two items, such as two ENTRYs or an ENTRY and a COMPOSITION. Links can be used across compositions, and across EHRs. Links can potentially be used between interior (i.e. non archetype root) nodes, although this probably should be prevented in archetypes. Multiple LINKs can be attached to the root object of any archetyped structure to give the effect of a 1-N link - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Use: 1:1 and 1:N relationships between archetyped content elements (e.g. ENTRYs) can be
openEHR-RM-LINK discussion - now also on mailing list :-)
On 27/10/2010 13:28, Erik Sundvall wrote: Wow Tom! That was a fast, nice and somewhat unexpected answer, now we're just awaiting the caption text to explain the image :-) You at least got me poking around for the archetypes, finding http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/openEHR_examples/link_archetypes/ - So tooling support already does exist, AWB for viewing validation and text editor for editing :-) (Or is there more?) I don't think editing capability in the AWB will be out of the question in the near-ish future, but I don't have any bandwidth to go there right now - What about the target range constraints, will string matching expressions cover all likely use-cases? well I think string matching can work, but any lexical matching to achieve semantic purposes is always dodgy. I think we need to be more careful with how we do this, but I have not analysed it that much yet. - This means a small modification (inherit LOCATABLE) to the LINK class in the RM to make the reference to used archetype possible to store in the EHR, right? yep - see the experimental RM schema file (you could diff it with the 102 file and you would see the addtions; they are also explained at the top). (The un-archetyped LINK information storage is already supported I believe, so data entered this way would be readable in the current 1.0.2 RM, even if archetype info will not be present, is that correct?) yep - there would just be no at-code.* * - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101027/3b0d47e3/attachment.html
