openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
- openEHR ENTRY subtype archetypes - corresponding paths and AQL-queries ...to 13606 in a consistent way. I guess such a conversion could also be performed by someone else than CEN/ISO if the 13606 semantics is powerful enough. I do believe that archetypes autoconverted to 13606 format will be less readable, but I could be wrong. Anyway, if the archetype modelling and query building would take place in the openEHR-space before autoconversion, then such a readability issue would not matter. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ http://www.imt.liu.se/%7Eerisu/ Tel: +46-13-286733 P.s. Building up parallel efforts for developing and maintaining 13606 archetypes separate from openEHR archetypes as I have heard suggestions of seems like a huge waste of effort, modelling in one space and then machine-translate would be more reasonable. That HL7 and openEHR clinical models will currently be developed in parallel is something we'll just have to accept for now and let them inspire each other over time. P.p.s. I agree that openEHR governance could be more responsive and transparent. But learning learn more from management of successful volunteer projects e.g. in the open source world might gain more than copying SDOs. But discussing that probably fits better in another thread. On Tue, Nov 9, 2010 at 03:25, Andrew McIntyre andrew at medical-objects.com.au wrote: In reality the Observation status of an entry should have a terminological definition rather than an explicit attribute of the model and by declaring the eg TABLE cluster you are actually removing the knowledge from the terminology and moving it to the model. This means the archetype does not have the information. To function as a DCM the archetype should have that knowledge embedded in it so that it can be represented in a specific way in another model. You could declare a cluster that is marked, by terminology binding as a table structure and that would allow any model to represent it using its own table convention. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101112/02a2eb84/attachment.html
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
ISO 21090 data types too complex?: HL7 models are created with clinician ...
In a message dated 10-11-2010 8:41:09 W. Europe Standard Time, hugh.leslie at oceaninformatics.com writes: Hi William I didn't see anyone say that the hl7 models have been developed without clinical input. I am certain this isn't true. I don't completely agree with you about the ease of accessibility for clinicians of UML models and MIF models - it's not our experience. Regards Hugh Let us then agree to that we have different experiences with clinicians appreciating UML. William Met vriendelijke groet, Results 4 Care b.v. dr. William TF Goossen directeur De Stinse 15 3823 VM Amersfoort email: wgoossen at results4care.nl telefoon +31 (0)654614458 fax +31 (0)33 2570169 Kamer van Koophandel nummer: 32133713 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101112/9b705f6c/attachment.html
ISO 21090 data types too complex?
Hi Ed, I am a mouse that roars (sometimes) :-) Met vriendelijke groet, Results 4 Care b.v. dr. William TF Goossen directeur De Stinse 15 3823 VM Amersfoort email: wgoossen at results4care.nl telefoon +31 (0)654614458 fax +31 (0)33 2570169 Kamer van Koophandel nummer: 32133713 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101112/fe002b1c/attachment.html
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
On 11/11/2010 23:14, Heath Frankel wrote: Hi Erik, Interestingly, this is the same proposal I put to Thomas about 8 years ago and I go the same response. I do understand his rationale for making a table a class rather than an attribute with additional conformance statements to ensure a table is represented consistently, but we know how well implementation guides get followed by developers. In addition we would be missing the functions on the class that which make it more pertinent. My concern at this point is that we do already have patient data being collected using openEHR and collapsing the ITEM_STRUCTURE would be a breaking change, I think it would need to be a 1.1 or 2.0 change if it was going to happen. probably 2.0. The nice thing is, even if it is a breaking change, the data migration of older data (or equivalent on-the-fly processing) would be very simple. Having said that, looking at the requirements from the clinicians it seems that the need for TABLE is actually at the ITEM level rather than the DATA_STRUCTURE level and Sam's proposal of extending CLUSTER for TABLE and LIST (although I would suggest inheriting from the abstract ITEM) would not be quite as bad as we can simulate the same levels of structure for legacy data (although the class names would still be different unless we included all of the ITEM_STRUCTURE types as a type of ITEM to retain backward compatibility). I would also concur with your statements about the ENTRY sub types, as Sam mentioned we have built an INSTRUCTION index that tracks the current state/care flow step of instructions and their associated ACTIONs providing efficient access to this information. The effort required to implement this would have been much greater if these classes were not specifically modelled. I guess as openEHR penetrates the market, the more likely CEN 13606 would be updated with these enhancements. To be honest I think this is the right standards process, standardising of implementations that are known to work in practice. I am sure we will learn more and improve the ENTRY subclasses further before they go into the CEN standard, then the standard will be more useful. exactly! - thomas * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101112/04d04985/attachment.html
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Hi, I would also concur with your statements about the ENTRY sub types, as Sam mentioned we have built an INSTRUCTION index that tracks the current state/care flow step of instructions and their associated ACTIONs providing efficient access to this information. This complexity may be tackled with a good Service Model ,when it's completed. I think that we are looking too much at the model to solve all our problems, but we have a Service Model in draft status that can help to solve issues on the using of the model. The effort required to implement this would have been much greater if these classes were not specifically modelled. Obs., Eval., Inst. Act. are a great ontologic division of the clinical information, with them it'seasy to understand and easy to map to real concepts, I doubt that removing them from the model can help in any way. If these classes weren't modelled, we have to model them in all of our implementations, that's a waste of good modelling. just a couple of opinions. Kind regards, Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101112/619f5ade/attachment.html
ISO 21090 data types too complex?
I like it I hope others help me build my menangre. W. Ed Hammond, Ph.D. Director, Duke Center for Health Informatics Williamtfgoossen@ cs.com Sent by: To openehr-technical openehr-technical at openehr.org -bounces at openehr. cc org Subject Re: ISO 21090 data types too 11/12/2010 05:46 complex? AM Please respond to For openEHR technical discussions openehr-technica l at openehr.org Hi Ed, I am a mouse that roars (sometimes) :-) Met vriendelijke groet, Results 4 Care b.v. dr. William TF Goossen directeur De Stinse 15 3823 VM Amersfoort email: wgoossen at results4care.nl telefoon +31 (0)654614458 fax +31 (0)33 2570169 Kamer van Koophandel nummer: 32133713 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
