FW: Archetype Template ANNOTATIONS - requirements?
Hi Tom, I tend to agree with same that annotations are most likely to be localised and the need for language translations will be minimal, hence the need to support annotations with a code is overkill and too complex for the 90% of use cases. The only use case I have seen that would utilise annotations with multiple languages is where a multi-lingual application wants to draw its context sensitive help from an archetype/template annotation based on a user's language setting. Although this use case may seem compelling, I still think this can be supported simply with an optional language attribute on each annotation. I would suggest that the current pattern of ontology language translations being grouped by language, then by concept/node is difficult to consume by a human reader (yes I know, I should use a tool, but I am a geek and I read computer code, XML and ADL as my native tongue). Having an annotation for a node and each of its translations in the one place would be much easier to read the translations. However, I do understand it would be easier for CKM or other tools to manage a set of annotations by language, but this is where the tools can do the work rather than the human J. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sam Heard Sent: Thursday, 30 December 2010 9:50 AM To: 'For openEHR technical discussions'; 'For openEHR clinical discussions' Subject: RE: Archetype Template ANNOTATIONS - requirements? Thanks Tom My experience is that annotations are organisation specific rather than national. They are often used to link to other data that is in use in a particular setting. There seems to be two sensible approaches: 1. A separate section of the archetype for annotations which have a language and organisation sections. The tag for an organisation can be their reverse statement. 2. An annotation syntax that can be used as required anywhere in the archetype with optional organisation and language sub tags. The former would allow CKM to present annotations required by a specific organisation on download, or in a specific language. This would help management a great deal. Cheers, Sam -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110106/abde1f41/attachment.html
Archetype Template ANNOTATIONS - requirements?
Thomas and Koray, The Operational Template XML schema used by the Ocean Template Designer has a view constraints element, which is a sibling of the description and definition elements. It is used to represent the Template Designer's hide on form property (labelled more generically as pass_through in the OPT view constraints). This was designed to support GUI (and other view) directives. The type of the view element is defined as follows. xs:complexType name=T_VIEW xs:sequence xs:element name=constraints minOccurs=0 maxOccurs=unbounded xs:complexType xs:sequence xs:element name=items maxOccurs=unbounded xs:complexType xs:sequence xs:element name=value type=xs:anySimpleType/ /xs:sequence xs:attribute name=id type=xs:string use=required/ /xs:complexType /xs:element /xs:sequence xs:attribute name=path type=xs:string use=required/ /xs:complexType /xs:element /xs:sequence /xs:complexType An example of its use is below. view constraints path=/context/other_context[at0001] items id=pass_through valuetrue/value /items /constraints constraints path=/context/other_context[at0001]/items[at0002] items id=pass_through valuetrue/value /items /constraints ... /view Regards Heath Frankel Product Development Manager Ocean Informatics From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Thursday, 30 December 2010 10:40 AM To: openehr-technical at openehr.org Subject: Re: Archetype Template ANNOTATIONS - requirements? On 29/12/2010 23:53, Koray Atalag wrote: Hi Tom, a very comprehensive set of questions to determine the requirements... I will provide my point by point feedback shortly but I have one objection/suggestion re using annotations for GUI matters. As name implies annotations seem to me something for the humans; providing context and additional information about a particular data point. Exploiting this section for GUI generation which will be consumed by GUI tools/generators do not seem all too appropriate to me. What I have in mind is a separate section for GUI Directives or at least introduce a reserved keyword for this purpose within annotations section. I think that'll ensure more consistent and safe implementations by different groups. Both support your points about tag standardisation... Hi Koray, the annotations section is not connected with GUI directives. I think we are all agreed they will be in a completely separate artefact. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101230/8dfce5e9/attachment.html
ISO 21090
I too are concerned, as you know Isolated 21090 is being balloted now, how should we recommend our member countries vote given this new viewpoint? Should we at least be requesting a name change? What form would the new spec take, another standard or a profile? Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Grahame Grieve Sent: Tuesday, 23 November 2010 11:54 PM To: For openEHR technical discussions Cc: Rene Spronk (Ringholm) Subject: ISO 21090 Hi All I have been having a long discussion with Tom off the list about ISO 21090, and we've come to agreement about the general picture. When I teach ISO 21090 tutorials, and I get to the implementation part, the first thing I say is that the data types are completely denormalised, and that I would never implement them as is inside my system (as anything but an object model for exchange.) And Tom says that they are all designed wrong to be used as data types inside a system We're both saying pretty much the same thing. The 21090 data types are designed, as Stef pointed out, for *exchange*. Specifically, for exchange between systems that are otherwise unconnected in any effective way. When you use the data types inside a system, then they aren't so appropriate. Now we have to be careful about using the term inside a system because even within systems, we have multiple connection/exchange points. So by inside a system I mean, for exchange between different entities that are connected by a common architecture that establishes, to a greater or lesser degree, common infrastructure that is used to normalise the content. That normalisation might be - the 5 normal forms of classical relational databases - moving audit information away from the content to a specialised audit/logging functionality - moving constraint information out of the data into the system metadata - re-organising content that has been conflated by semantic intent to more clearly draw apart management concerns. - moving concerns out of the data into the code There's more, but that list will suffice for now. (so it should be clear that I am using normalise in a somewhat loose sense). Tom sees these gaps, and responds negatively, whereas I just accept them, knowing that they exist, and that I have plans to deal with them, plans that vary across my different systems as their architectures change. But we do both share the concern that the degree to which the 21090 data types are designed and optimised for exchange is not understood by casual adopters. It's not that it's impossible to adapt non-normalised models built for exchange to serve as system architectures (there's an active group in HL7 - RIMBAA - doing just that), but that you need to know that what you are doing is going to present certain challenges you will need to prepare for. Users could easily start to implement them in systems and find themselves later with a series of bad choices that they could have avoided earlier, and then they'd blame 21090.. It appears that Tom and I may jointly develop a variant of ISO 21090, that features the same basic semantic content, but in a format that is suitable for use in systems rather than for exchange. It will describe clearly how to interoperate using 21090, but will be suited for system/case design. I am a little uncertain, because I am concerned that the particular normalisations you anticipate will affect the way that you design such a variant, and I don't see how to pick a particular set - a logical obvious candidate around which an implementation community would coalesce. Tom and I are still talking about that. Tom and I hope that this explanation will bring some clarity to any observers who have been left confused by our somewhat passionate debate to this point ;-) Grahame ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
World Peace
It would also seem that the SVN is also down, or at least very, very, very, very slow. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Diego Bosc? Sent: Monday, 22 November 2010 9:22 PM To: For openEHR technical discussions Subject: Re: World Peace I think the wiki is down 2010/11/22 Thomas Beale thomas.beale at oceaninformatics.com On 22/11/2010 00:23, Stef Verlinden wrote: Dear all, As Ed Hammond said it somewhere earlier in this discussion: It's like World Peace - a great idea but probably not achievable. I agree with Ed if we think along the line of ?one solution should fit all? and I also think that if we create different solutions for different purposes World Peace is achievable after all. Please let me explain. The 21090 standard is a fact, is here to stay and is not going to change (soon). As William G. said it has been a tremendous accomplishment and Graham did a hell of job in finding consensus between all parties involved. Based on the reactions of some in this list and the fact the the majority of CEN and ISO voted for it, 21090 fits it?s current purpose which is: ?provides set of data type definitions for representing and exchanging basic concepts that are commonly encountered in healthcare environments in support of information exchange in the healthcare environment? unfortunately this is not the case. If it were, we would already have the CEN use of these data types sorted out. See the openEHR wiki page on 13606 and 21090 mapping, about halfway down. The way I see it, the main point of discussion untill now is the question: exchange between who and/or what. This is also where the solution lies. Although it isn?t stated specifically the current use of the 21090 seems to be primarily at the level of functional interoperability (? the ability of two or more systems to exchange information (so that it is human readable by the receiver) (ISO/TR 20514:2005)). I?m sure it?s intended use is also at the level of (some) semantic interoperability but allow me to make this distinction to explain the need for different solutions. What Tom and many others on the list here are striving form is (let?s say an ?advanced level? of) semantic interoperability (? the ability for information shared by systems to be understood at the level of formally defined domain concepts (so that information is computer processable by the receiving system) (ISO/TR 20514:2005)). Obviously I would like to achieve that as well, but it is not the 21090 data types that will primarily achieve it. Actually, what we need is simply data types that do not have all the HL7 specific use case attributes and value restrictions all through them. For anyone other than HL7v3 messaging users, the first question is: ok, how do we set all the attributes coming from HXIT? From ANY? and the various other ones sprinkled throughout? How do we obey this rule about setting NullFlavor when we don't even want to use NullFlavor in our context. Etc... I am not arguing for anything sophisticated actually, just that the basics be done properly, so that we (all) would actually be able to use this standard. With advanced I mean that systems can not only support but eventually take over certain critical functions in the medical process. This goes beyond the level of decision support. In in the (not so far) future also fully automated systems based on input from several parties will be created. For instance automated triage of after hours GP visits, assess whether someone can get a refill prescription, an agent that checks for medication interaction, automated screening for certain risk profiles, follow up of patients with a certain diseases, etc, etc. Whether we like it or not, systems have to support and even take over some functions of healthcare providers in order to be able to provide sufficient care 10-15 years from now. If not for that reason alone, this type of applications can (hopefully) help to improve the quality of healthcare. For instance by making personalised medicine possible at a large scale. These advanced systems are (potentially) going to decide on matters of life and death and therefore they need to be reliable in that the outcome must be correct and similar in every system that uses the same standard(s). yes, we can't argue with this. If the software is full of ambiguities due to the developers not knowing how to create the data, due to standards being full of stuff they cannot use, then this will be dangerous. As for proposals about what to do, I would be interested to see what the list members think. My only addition to Stef's proposal below would be to say that the scope is much greater than only semantically enabled healthcare processes, but basic ones too. The way the current specification is written (I mean the subtractive modelling style, requiring 'profiling') will mean that
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
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. 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. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Wednesday, 10 November 2010 11:16 PM To: For openEHR technical discussions Subject: openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?) Hello again! Here comes a more complete version of the mail I happened to send unfinished this morning. I hope you don't mind me breaking out a side thread with concrete harmonisation suggestions. First an openEHR change request (CR), then an ISO 13606 change request. 1. item_structure (openEHR CR) Regarding ITEM_TABLE (and the other classes in the openEHR item_structure package) there was a change request from Sam that went pretty unnoticed by a while ago, see: http://www.openehr.org/mailarchives/openehr-technical/msg04994.html I'm not saying we should go exactly by the letter in Sam's CR, but somehow skipping the things currently in item_structure package in openEHR could simplify understanding and slightly reduce implementation complexity. (It might also shorten paths in object traversal (and thus storage depth) one step - a possible performance gain in some implementations.) Probably letting the data attribute of openEHR ENTRY subtypes point straight to ITEM (or possibly CLUSTER) would be best. If something should be suggested to be shown in a GUI as a table, list (or other non-tree formalism) it might be possible to define using any of the following... a) ...a GUI directive/hint in archetype annotations similar to the directives shown by Koray Altag at Medinfo 2010, see slide 30 and onwards in http://www.openehr.org/wiki/download/attachments/5996988/3_GastrOS_Atalag.pd f b) ...a new attribute in the CLUSTER or ITEM class (with accompanying controlled vocabulary). c) ...some other way I have not thought of Suggestion a) means the directive/hint might not be available in instance data, only in the archetype, that might be bad for safety reasons. If b) is chosen, then that new attribute could of course be archetyped if you want the information in the archetype as Andrew suggests. Shortcuts to UML diagrams for comparison: CEN/ISO: http://www.chime.ucl.ac.uk/resources/CEN/EN13606-1/13606-1Diagramsv3e.pdf openEHR: http://www.imt.liu.se/~erisu/2008/openEHR-tour/print/openEHR-RM-1.0.1-may23- 17.54.gif I'd suggest that this change, after refinement and discussion with openEHR implementers followed by successful prototype implementation, be introduced as soon as possible before there is too much real patient data stored using the present item_structure package. Perhaps it can be introduced at the same time as ADL 1.5 and enhancements of the LINK class which anyway will require code changes. 2. OBSERVATION et. al. (ISO 13606 CR) == I can understand the CEN/ISO-urge for simplification of the openEHR ENTRY package if the main intention of the standard is to
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?
Hi all, For those that remember me, I was quite active in HL7 up until about 5 years ago. About that time I attended an ISO meeting in Berlin as an Australian delegate to try to facilitate the harmonization of HL7/CEN/ISO data types for healthcare. At the meeting there were a lot of frustrated people trying their best to move this project ahead for some time and it was looking like a hopeless cause. There was one last ditch effort by the leader of the project at the time (whom I can't remember his name, but he was from the UK). To do this, we agreed that we would build on top of the existing ISO 11404 IT - General Purpose Datatypes standard rather than reinventing the wheel and we would only include the data types that we could agree on. Unfortunately the project leaders could not continue his task (his boss must have been more frustrated than he was) and this directive must have gotten lost as the project transitioned to the new leader. I have a lot of respect for Grahame for taking on the task that no one else wanted (including myself), but it would appear to me that Grahame has tried to do a too good a job by trying to incorporate everyone's requirements. As an ISO standard, I believe that it should be an intersection of all the input specifications, rather than a union and if ISO 21090 followed the committee's directive from the Berlin meeting, we would have a usable standard that would not require profiling. Extensions could be made by parties knowing that they are just that, but at least the core data types would support knowledge development and system interoperability. This is not a criticism of Grahame, in fact it is probably my fault for dropping away from this project and the standards world in general , but this was something I had to do for my own sanity (it hurts when you constantly hit your head against a brick wall, I needed to do something that I thought was more practical). This might be all too late, I am not sure what the status of ISO 21090 is, but I thought it may be useful to have this hindsight considering people are looking for better ways. Heath Frankel Ocean Informatics -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Grahame Grieve Sent: Tuesday, 9 November 2010 5:21 AM To: OpenEHR technical discussions Subject: Re: ISO 21090 data types too complex? hi All A roll up of comments: 1. ISO 21090 is often (always?) profiled It seems remarkable to me that people think it's a problem that ISO 21090 needs to be profiled. Who would've guessed that a full standard that meets many requirements is simpler to implement if you profile out the features that reflect requirements you don't have? I'm pretty sure that this is true of every other standard as well. It's certainly true of all my implementations of W3C, IETF, and OMG standards. 2. Some people have responded vehemently to Tom's initial comments I suppose I'm a little guilty. I don't mind people criticising ISO 21090. Other's people's list of criticisms will never be as a long as mine. But it's frustrating to respond to the same wrong comments repeatedly, especially when the come from people who are widely and rightfully regarded as genuine experts 3. In health informatics, standards are done differently. We had this discussion last week. I made the point that this is true of IT vertical industry integration standards. I don't believe Tom offered a counter example to this. 4. The ISO process is flawed Yes. As is every other process, each in it's own way. 5. Cryptic type names. Yes. Sorry. But we do actually define both short and long names, so that people can use either. But people always choose the short name. So there's a bit of market influence at work there. 6. Eric's comments about typing Eric, we do allow OID as a reference to value set. We expect that you need the OID registry and CTS to make this work (since you asked how it would). We discussed the notion of putting the entire value set in the data type, but this is not properly in the scope of the data types. I think that models can and should use the data types to communicate the possible set of values, but I'm comfortable that we didn't do this in data types Grahame ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
ISO 21090 data types too complex?
As an ISO standard, I believe that it should be an intersection of all the input specifications, rather than a union extension has it's own difficulties, as does union. We were aware of the berlin decision, but ISO 21090 resulted from a deliberate decision to do something different. Was that a right decision? Unfortunately, time won't tell, since the alternatives are purely hypothetical. [HKF: ] Obviously this deliberate decision was made without the parties that were in Berlin who had come to that conclusion for a very good reason, they had already tried that approach without success. So we are back to the same position we were in 5 years ago, with another data types standard that is unable to be used out of the box ubiquitously in healthcare information systems.
ISO 21090 data types too complex?
Have a look at ISO 11404, it is an intersection (datetime is defined elsewhere ) and every programming language, database system and serialisation format uses it and extends it as required. On 09/11/2010 7:13 PM, Grahame Grieve grahame at kestral.com.au wrote: which is more likely to be used out of the box? intersection, or union? Union at least has everything Grahame On Tue, Nov 9, 2010 at 7:14 PM, Heath Frankel heath.frankel at oceaninformatics.com wrote: As ... [HKF: ] Obviously this deliberate decision was made without the parties that were in Berlin who ... openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mail... -- Grahame Grieve, CTO A: Suite 8a / 17 Burgundy St, Heidelberg VIC 3083 P: + 61 3 9450 2230 M: + 6... openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/li... -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101109/4ed69914/attachment.html
existence and assumed value
Hi Bert, Assumed value is different to default value (see the AOM spec for definition of assumed value, default value is further defined in the new 1.5 AOM spec). If an element has a assumed value defined and its value is not present, the assumed value should not be used in the data, it remains not present. The meaning of not present is the assumed value from a clinical perspective, but does not get injected into the data. Compare with a default value which does get injected into the data when the value is not originally present. My understanding is that assumed values are most usually used in state, not data (e.g. assumed value of blood pressure position is sitting). Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Bert Verhees Sent: Monday, 20 September 2010 12:15 AM To: For openEHR technical discussions Subject: existence and assumed value Hi all, I noticed that the JAVA ADL-parser marks a CObject existence as required if it is not specified in ADL If there is also an assumed value specified, then this is, in my opinion conflicting, because the function of the assumed value is to use it when there an attribute is not used (page 21 AOM.pdf). Or am I wrong? Thanks for your attention Bert ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
proposed ADL 1.5 simplification
The Canonical MD5 hash generated by the archetype editor is based on the definition and ontology attributes of the AOM, therefore the concept is not considered. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sebastian Garde Sent: Tuesday, 6 July 2010 4:30 AM To: For openEHR technical discussions Subject: Re: proposed ADL 1.5 simplification Hi Thomas, That makes a lot of sense in my opinion. Don't think it will be a major problem, at least in the Java space this particular change in ADL 1.5 is not worrying me as there are others that are a lot more fundamental. Not sure if this change would has an impact on the canonical MD5 hash generated by the Archetype Editor - ideally it would be the same for an archetype with or without the concept clause? Sebastian Thomas Beale wrote: In all archetypes that I have ever seen, the 'concept' at the top of the archetype is always the at-code of the root object constraint of the archetype. It would make sense to turn this into a function, and remove this clause from archetypes templates. In fact, the concept code is by definition the node_id of the root object. In ADL 1.5, the root object must hae a node_id, according to the following rule: * VACCD: archetype definition code validity. The node identifier of the root node of the definition section must be the concept code mentioned earlier in the archetype. So... it seems logical to remove it from the archetype as data, and change the 'concept' property to a function which simply retrieves the node_id of the root object. It seems to be that this would be a useful change to put into ADL 1.5. Would this impact badly on tools and parsers? I think that most parsers could be left as they are, and so could most archetypes; the 'concept' clause would be sliently ignored in future. New ADL 1.5 archetypes being created would have no concept clause. - thomas beale _ ___ 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/20100707/64848e9a/attachment.html
proposed ADL 1.5 simplification
Sorry, I was wrong, only the description element is removed from the Canonical Archetype Model Digest, the concept is included and so is the adl_version as indicated by Peter. Heath From: Heath Frankel [mailto:heath.fran...@oceaninformatics.com] Sent: Wednesday, 7 July 2010 10:41 AM To: 'For openEHR technical discussions' Subject: RE: proposed ADL 1.5 simplification The Canonical MD5 hash generated by the archetype editor is based on the definition and ontology attributes of the AOM, therefore the concept is not considered. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sebastian Garde Sent: Tuesday, 6 July 2010 4:30 AM To: For openEHR technical discussions Subject: Re: proposed ADL 1.5 simplification Hi Thomas, That makes a lot of sense in my opinion. Don't think it will be a major problem, at least in the Java space this particular change in ADL 1.5 is not worrying me as there are others that are a lot more fundamental. Not sure if this change would has an impact on the canonical MD5 hash generated by the Archetype Editor - ideally it would be the same for an archetype with or without the concept clause? Sebastian Thomas Beale wrote: In all archetypes that I have ever seen, the 'concept' at the top of the archetype is always the at-code of the root object constraint of the archetype. It would make sense to turn this into a function, and remove this clause from archetypes templates. In fact, the concept code is by definition the node_id of the root object. In ADL 1.5, the root object must hae a node_id, according to the following rule: * VACCD: archetype definition code validity. The node identifier of the root node of the definition section must be the concept code mentioned earlier in the archetype. So... it seems logical to remove it from the archetype as data, and change the 'concept' property to a function which simply retrieves the node_id of the root object. It seems to be that this would be a useful change to put into ADL 1.5. Would this impact badly on tools and parsers? I think that most parsers could be left as they are, and so could most archetypes; the 'concept' clause would be sliently ignored in future. New ADL 1.5 archetypes being created would have no concept clause. - thomas beale _ ___ 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/20100707/1c56b73a/attachment.html
Unique Name Rule - RE: ADL 1.5 - relaxing a conformance rule - feedback sought
Thomas, the above kind of thing happens (to my knowledge at least) only when multiple instances of a given node defined in a system of archetypes and templates, are created at runtime. These are then only distinguishable by name or some other attribute. The current rule in openEHR is that the name field has to be made unique across children of an attribute; this needs to be relaxed so that name only needs to be unique across those siblings having the same at-code. Now, one of the big changes in ADL 1.5 is that anything you change in a template (+/- the discussion we are now having about occurrences etc) forces a new at-code specialisation, just like in an archetype, whereas in the current de facto template standard, it doesn't - a lot of overriding of the name field is done in current templates. So a large proportion of his problem will go away with ADL 1.5. [HKF: ] I would suggest that this unique name constraint is relaxed altogether. It is a relatively undocumented constraint that is not formally expressed in the RM, it is alluded to in one place in the COMMON Directory package. This constraint is an artificial constraint enforced by the RM, which no other information model has, purely to ensure unique data paths. Although this reasoning is valid, I do not believe that enforcing this in the reference model is reasonable and is overly restrictive. It requires either the system or user to provide a unique name on every multiple occurrence of a node. In the case of the user this is onerous and makes user interfaces unfriendly. For systems to generate a unique name simply results in names such as Blood Pressure #1, or complex algorithms such as a series of concatenated data items to produce a unique name that may not conflict with another node, which long and replicates data specified elsewhere and still doesn't guarantee uniqueness, e.g. Blood Pressure 2010-05-35 08:55:30. My biggest concern is the overloading of the responsibilities of the name attribute, originally it was seen as the local name of archetyped concept, allowing data to be rendered with captions using these local names. Auto generated naming algorithms make these impossible to use for display purposes. I think we have two choices: * if an application context requires uniqueness then it is the responsibility of the modellers and implementers to ensure there is some combination of attributes that can be used to identify data nodes uniquely using the attributes that make sense in that context. This may be name, uid, event time, an archetyped node. * provide a real identifier attribute designed for the purpose that can optionally be used when uniqueness is required. The benefit of allowing non-unique paths is that we have a solution for the multi-value problem without any need to change the existing reference model (except for removing this informal unique name rule), allowing us to use a non-unique path to retrieve all answers for a multi-value question. Regards Heath -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100525/5ea3ceee/attachment.html
Can a single CONTRIBUTION ever affect two separate EHRs?
Erik Thomas, I had the same question a while back for the same use case. I could not find anything in the specifications/models that indicates that contributions are restricted to a single EHR, as Erik says contributions can be associated with any VERSION OBJECT_REFs. I think this topic needs to be discussed further and clarified in the specifications. For the record, the Ocean EHR Server currently requires two contributions. If we compare the EHR repository with a SVN repository, SVN allows us to commit movements of data from one folder to another to ensure integrity of repository content at any point of time and an audit trail of the operations performed to the repository. I see moving data from one EHR to another within the same repository as a similar operation and if we need to do this in two contributions then the integrity of the EHR repository is compromised and lacks the audit tracing of the move operation. The order of the add and delete contributions will change the way the repository looks like between the two contributions, if we add the items to the target EHR before deleting them from the source we actually have duplicates of the same data, potentially affecting population queries at this intermediate state. Deleting the items from the source EHR before adding them to the target has the opposite affect but perhaps not quite as problematic. Allowing this to happen in a single contribution avoids this intermediate state and provides a better audit trace of the operation. The other issue I found with this use case was the need to create new version UIDs for the compositions in the target EHR contribution due to the need for the source compositions to be retained and marked as deleted. This would be required no matter if this was done as 1 or 2 contributions due to the add/delete nature of the operation. If we had a specific move operation, we could physically move the existing VERSIONED_OBJECT to the target EHR, but we would need to ensure that the repository still reflected the fact that the VERSIONED_OBJECT was part of the source EHR prior to the move contribution. This would be difficult to represent because the VERSIONED_OBJECT.owner_id would need to be changed to the target EHR as part of the move operation, which breaks the versioning model and has no means to record the fact that it used to be part of the source EHR. I think we need some implementation guidance on this Use Case, the Wiki is probably a reasonable place to do this for now. Heath From: openehr-technical-boun...@chime.ucl.ac.uk [mailto:openehr-technical-bounces at chime.ucl.ac.uk] On Behalf Of Thomas Beale Sent: Thursday, 28 January 2010 11:26 PM To: openehr-technical at openehr.org Subject: Re: Can a single CONTRIBUTION ever affect two separate EHRs? Hi Erik, in principle your reasoning is correct, and we could solve merge demerge problems with some kind of uber-Contribution. However, at the moment the formal modelling only allows for Contributions to be associated with single EHRs. One of the reasons is that EHRs could be separated, due to decease, archiving, one patient moving etc, so a cross-EHR Contribution would then be broken up in some way. I think that at a practical level the correct approach is simply to ensure that certain kinds of updates are handled at the database transaction layer, i.e. either they succeed or they are rolled back. In any case, if health data for person A is found in person B's record, that has to be removed ASAP, and regardless of whether it could be added to A's record at the same time or not - thomas beale On 28/01/2010 11:59, Erik Sundvall wrote: Hi techies! A possibly stupid question: Can a single CONTRIBUTION ever affect two separate EHRs? I understand that a CONTRIBUTION normally only affects a set of VERSIONED_OBJECTs within a single EHR, but are there any exceptions? Technically the class CONTRIBUTION can point to any OBJECT_REF, but what should be allowed for real? A possible use case could be when moving some compositions between records (e.g. due to entry mistakes or temporary records for unidentified patients). Then one could either create a single CONTRIBUTION describing the move or two CONTRIBUTIONs: one in the source record indicating deletion and one in the source record indicating addition. I guess the last one (creatinig two CONTRIBUTIONs) is the preferred one, but I just want to be sure if the first case is ever allowed. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 (Mail tel. recently changed, so please update your contact lists.) ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Ocean Informatics Thomas Beale Chief Technology Officer, Ocean http://www.oceaninformatics.com/ Informatics Chair
data types and structures questions
Masourmeh, There is no generics in XML Schema, hence you cannot define a single type for all intervals. The XSD does what compilers that support generics do and creates a real type for each type of T that is used with the generic type. It should also be noted that these IntervalOf* types are only used in XML Archetypes to make it easier to validate and use the resulting archetype document without an AM implementation. These IntervalOf* types are not used in openEHR RM data but instead uses the DV_INTERVAL type that allows any DV_ORDERED as the lower and upper without any insurance that they are of the same type and requires an RM implementation to enforce these RM assertions. Heath From: openehr-technical-boun...@chime.ucl.ac.uk [mailto:openehr-technical-bounces at chime.ucl.ac.uk] On Behalf Of Masoumeh Seydi Sent: Monday, 21 December 2009 3:53 PM To: openehr-technical at openehr.org Subject: data types and structures questions Hi All, I've got some questions about data types and structures. I was wondering if someone could help me. 1. Why an item_single can,t be empty but other structures may be. I mean 'items attribute's cardinality in item_single is 1..1 (and this is logical. coz' an item_single without element is meanless). But in other structures, the cardinality of items attribute is 0..1. What's the point of having an empty list or tree or table (without ant item in it)? 2. What's the difference between CLUSTER and ITEM_TREE? Both can have CLUSTERs and ELEMENTs. And why in all structures in CKM, there is a Data branch shown in archetype mindmap but in cluster archetypes, there is a Items branch? 3. There is an Interval intrface containing lower and upper attributes. Other intervals like IntervalOfReal, IntervalofDate, IntervalofDateTime, IntervalofTime and IntervalofDuration with lower and upper attributes in xsd file in the site. My question is, why there is not an Interval class that contains an attribute for declaring the type of interval and so get rid of other interval classes for every type? Thanks in advance Masoumeh -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091222/de20a131/attachment.html
DV_DATE definition mismatch
Hi David,
There is nothing wrong in the openEHR specifications or the Ocean Archetype
Editor?s construction of the ADL representation of an ELEMENT of type
DV_DATE.
The RM specifies the DV_DATE class as having a value attribute of type
string that represents an ISO8601 date, which supports partial dates, e.g.
?1934-05? or ?1934? (also note that ?193405? is also a valid ISO8601
representation of ?1934-05?). These partial dates are not supported by
XML?s xs:date and hence it has not been used in the schema.
The constraint specified in the ADL fragment you have provided below is a
further constraint on this ISO8601 representation, as specified in
http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf section
5.4.6.1. This particular constraint indicates that the month is optional
and day is not to be provided, so valid date must be a partial date like the
examples above.
What Java Parser are you using? Are you sure that the parser is not
producing a DvDate object that represents the value attribute of the
ELEMENT, which itself has a value attribute which has a constrained string
representation of a partial date?
Regards
Heath
Heath Frankel
Product Development Manager
Ocean Informatics
heath.frankel at oceaninformatics.com
+61 (0) 8 7127 5574
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of David Moner
Sent: Friday, 13 November 2009 9:09 PM
To: For openEHR technical discussions
Subject: DV_DATE definition mismatch
Hello everybody,
I have detected what it seems a mismatch between the DV_DATE definition of
the reference model and the ADL parser/AOM model specifications.
At the RM, the DV_DATE value is defined as a String constrained as an
ISO8601 pattern. This is both at the RM specification and at the XML Schema.
Following the ADL/AOM specifications, something such as (this code has been
generated by the Ocean Archetype Editor)
DV_DATE matches {
value matches {-??-XX}
}
will be parsed as a C_Primitive_Object of the type Date (in fact, DvDate at
the java parser that I use).
The problem then is that the DvDate type parsed does not correspond to the
String definition of the RM, generating then a non valid archetype that does
not correspond to the RM.
There are two possible solutions. Or the RM is changed to represent
correctly the DV_DATE value as a xs:date type with the appropriate ISO8601
facet or the archetypes should take the form
value matches {-??-XX}
to be parsed as a String according to the RM definition.
I'm right with this?
--
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091116/f6e54fd3/attachment.html
xml-instance of archetypes
Hi Karl, Have a look at http://southern.oceanehr.com/Ehrview15/?ehruri=ehr://6421a888-e1cb-4741-b629 -e69a92c2812a/fc995f12-e8bf-4c86-b292-0434bef0c9ad::B9D93A96-52C0-4401-8DC8- 882413140145::1. You can login using username test and password test. Click the OpenXML button in the bottom right hand corner to see the underlying XML. Regards Heath Heath Frankel Product Development Manager Ocean Informatics heath.frankel at oceaninformatics.com +61 (0) 8 7127 5574 -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Karl Holzer Sent: Sunday, 15 November 2009 12:17 AM To: openehr-technical at openehr.org Subject: xml-instance of archetypes Hi all, Me and my colleague are trying to create ehr extracts in form of instances of different openehr archetypes (body mass index for example) as XMLs. Our problem is that we don't know if the structure of our xml is absolutely right. So, does anyone have valid xml-instances of the body mass index or similar archetypes (with anonymised or some kind of dummy data)? The most useful file for us would start from the composition class. We know the .xds files but can't figure out the right structure. Thanks in advance, Karl -- DSL-Preisknaller: DSL Komplettpakete von GMX schon f?r 16,99 Euro mtl.!* Hier klicken: http://portal.gmx.net/de/go/dsl02 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
xml-instance of archetypes
Please note that the composition instance provided below may be using archetypes that are either older than those available in CKM or not available at all. However it should serve your purpose of seeing what an openEHR composition that contains a BMI looks like in XML. Heath -Original Message- From: Heath Frankel [mailto:heath.frankel at oceaninformatics.com] Sent: Monday, 16 November 2009 10:45 AM To: 'For openEHR technical discussions' Subject: RE: xml-instance of archetypes Hi Karl, Have a look at http://southern.oceanehr.com/Ehrview15/?ehruri=ehr://6421a888-e1cb- 4741-b629-e69a92c2812a/fc995f12-e8bf-4c86-b292-0434bef0c9ad::B9D93A96- 52C0-4401-8DC8-882413140145::1. You can login using username test and password test. Click the OpenXML button in the bottom right hand corner to see the underlying XML. Regards Heath Heath Frankel Product Development Manager Ocean Informatics heath.frankel at oceaninformatics.com +61 (0) 8 7127 5574 -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr- technical- bounces at openehr.org] On Behalf Of Karl Holzer Sent: Sunday, 15 November 2009 12:17 AM To: openehr-technical at openehr.org Subject: xml-instance of archetypes Hi all, Me and my colleague are trying to create ehr extracts in form of instances of different openehr archetypes (body mass index for example) as XMLs. Our problem is that we don't know if the structure of our xml is absolutely right. So, does anyone have valid xml-instances of the body mass index or similar archetypes (with anonymised or some kind of dummy data)? The most useful file for us would start from the composition class. We know the .xds files but can't figure out the right structure. Thanks in advance, Karl -- DSL-Preisknaller: DSL Komplettpakete von GMX schon f?r 16,99 Euro mtl.!* Hier klicken: http://portal.gmx.net/de/go/dsl02 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Sending a new object using the Contribution
Hi Soheil, An EHR repository requires a service interface which is yet to be defined by openEHR. Some of the classes such as EHR, Contribution and VERSIONED_COMPOSITION are not classes used for containment purposes, they are intended to be used as part of a service interface. This is why the draft ehr_extract_rm defines the classes EHR_EXTRACT, X_VERSIONED_OBJECT and X_CONTRIBUTION separately. The draft ehr_extract_rm define the X_CONTRIBUTION as part of the SYNC_EXTRACT in Figure 11 (section 7), but the draft has some errors left over from previous versions. The MESSAGE_CONTENT parent type of SYNC_EXTRACT I believe is equivalent to the EXTRACT_CONTENT parent type of EHR_EXTRACT_CONTENT in Figure 7 (section 5), which is equivalent to EXTRACT_ENTITY_CONTENT in Figure 6 (section 4). Based on that premise, the X_CONTRIBUTION is contained within EXTRACT_CHAPTER (see Figure 6), via the content relationship to the SYNC_EXTRACT (subtype of MESSAGE_CONTENT/EXTRACT_CONTENT/EXTRACT_ENTITY_CONTENT) that contains the list of X_CONTRIBUTIONS and the EXTRACT_CHAPTER has an entity_identifier which is the EHR ID providing an explicit relationship between the CONTRIBIUTION and the EHR. The Ocean Informatics EHR Server, provides a service interface that directly operates against the EHR repository through the EHR and VERSIONED_COMPOSITION classes rather than extract interface. This EHR Server service interface provides a CommitContribution method that has the following parameters (among others): * ehrId: HIER_OBJECT_ID * audit: AUDIT_DETAILS * versions: ORIGINAL_VERSIONT[] You will notice that audit and versions are similar to those specified in X_CONTRIBUTION, but the ehrId is an additional parameter to ensure the versions are added to the correct EHR. The Ocean EHR Server derives the contribution UID from the contribution attribute in the versions. I believe that the development of the EHR Service interface is soon to begin, but until then I hope this helps. Regards Heath Product Development Manager Ocean Informatics -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Soheil Hassas Yeganeh Sent: Thursday, 15 October 2009 9:42 PM To: For openEHR technical discussions Subject: Sending a new object using the Contribution Dear All, According to the reference, common, and extract information models changes made to an EHR, including additions, should be sent through a contribution. There is no implicit or explicit link to an EHR neither in X_CONTRIBUTION nor in CONTRIBUTION. So, would you please let me know what is the scenario to send new objects (addition change type) using contribution or x_contribution classes? Bests, Soheil ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Issues around UI technologies and bindings to back end
There is an open source ADL to XML conversion library for .NET written in c# located at http://www.openehr.org/svn/knowledge_tools_dotnet/RELEASES/BlueChina/XMLPars er. This is used by the Archetype Editor to generate a pure XML representation of the ADL file via the ADL_Parser so that it can create a canonical xml representation of the archetype model for hashing purposes. The XML displayed and files generated directly from the Archetype Editor uses a different (legacy) mechanism and is not as reliable as that produced by the conversion library, the result is slightly different XML output. We just have not had enough volunteer time to replace this legacy approach within the Archetype Editor. If anyone need assistance in using this conversion library I can provide an NUnit test library that shows how it can be used, or you can sift through the Archetype Editor code if you prefer VB. We actually have a publishing tool using this library that can run a batch process against an entire Archetype file repository that can be run within an auto-build process and committed back into svn. This is how the XML archetypes on openEHR used to get generated prior to CKM. I am not sure if CKM supports XML output of archetypes as yet but if it is felt that not having archetypes available in XML is holding back openEHR adoption then I am sure this can be put on the change request list for prioritisation. Regards Heath Heath Frankel Product Development Manager Ocean Informatics heath.frankel at oceaninformatics.com +61 (0) 8 7127 5574 Regards Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Greg Caulton Sent: Thursday, 23 July 2009 8:45 PM To: openehr-technical at openehr.org Subject: Re: Issues around UI technologies and bindings to back end Date: Wed, 22 Jul 2009 15:16:20 +0200 From: hepabolu hepab...@gmail.com Subject: Re: Issues around UI technologies and bindings to back end To: For openEHR technical discussions openehr-technical at openehr.org Message-ID: 4A671124.7020002 at gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Seref Arikan said the following on 22/7/09 11:39: Now about UI - model relationship, my view is the GUI layer is way too complex and diverse to include in openEHR specifications, even a subset of the UI related stuff would be enough to introduce more problems than it solves. IF there emerges a cross platform AND cross technology declerative markup for GUI and GUI interactions and bindings, and this is a big if, then it may be considered, otherwise, my personal opinion is to simply I agree, to start integrating UI related content into the archetypes is a very bad idea. Most modern UIs follow a Model-View-Controller http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller approach. For PatientOS Archetypes provide the data elements. The relationships and constraints within the archetype data elements is implemented in our model. We have different views - fat client, web client which are implemented through controllers written in java or javascript. Atttempts to push everything into the archetype definition would create a complex beast which would defeat KISS principal. As a side note I also think the ADL files is hampering adoption - not for us as there is a Java parser. Since everything that is the ADL must be expressable in XML (otherwise interoperability of the definitions would be problematic) - why have both - XML is ubiquitous and I think the benefits of readibility of an ADL file is no longer needed since there are tools which replace it - how many people read an ADL file any more? -- Gregory Caulton Principal at PatientOS Inc. personal email: caultonpos at gmail.com http://www.patientos.com corporate: (888)-NBR-1EMR || fax 857.241.3022 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090725/3ad435d6/attachment.html
optional existence, cardinality and occurrences.
Hi David, We need to differentiate the AOM from ADL, just because the AOM makes cardinality optional doesn?t mean that ADL does not require a cardinality keyword. Remember that ADL is just a serialisation of the AOM just as the AOM can be serialised using XML. On a related topic, I think that the attributes of cardinality may need to be optional for the same reasons as occurrences and existence. Therefore for the reasons that David states below, I wonder if it is reasonable to make cardinality mandatory and its attributes optional instead. Regards Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of David Moner Sent: Friday, 3 July 2009 4:40 PM To: For openEHR technical discussions Subject: Re: optional existence, cardinality and occurrences. I agree with the initial idea about the optionality of existence, occurrences and cardinality; there is no need to state them if they are not changed from the reference model. But one problem arises with the cardinality. As far as I know, the only way to differenciate a C_Single_Attribute and a C_Multiple_Attribute while parsing the ADL and generating the AOM instance is through the 'existence' of the cardinality constraint. If we don't have that keyword it is imposible to choose the correct attribute object. At the Jira issue we can read with reference model checking..., but making the ADL parsers dependent of the RM is absolutely not a good idea in my opinion. 2009/6/30 Thomas Beale thomas.beale at oceaninformatics.com Dear all, as part of the specialisation semantics, which are nearly all implemented in the ADL workbench, we have made existence, cardinality and occurrences all optional. This is sensible for 'source' form archetypes - i.e. it is natural that only overridden constraints be stated in an archetype, if there is no override of either the reference model or a specialisation parent archetype, where the latter is relevant, then no constraint is needed. The change is described in http://www.openehr.org/issues/browse/SPEC-303 We have not yet released a new version of the ADL workbench with this change, but will soon. What I would like to know is if the implementers of other archetype parsers, compilers etc can deal with this change. Note that it would normally be part of implementing the wider ADL 1.5 semantics, since it is logically part of the specialisation semantics. has anyone else considered implementing these semantics yet? thanks - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090703/6a004da5/attachment.html
distributed development, governance and artefact identification for openEHR
Tom and Sam, Page 11: Current text: Archetypes based on different classes from the same information model to have the same name, e.g. An archetype for 'vital signs' headings based on the SECTION class, and a 'vital signs' archetype based on OBSERVATION. Comment: I believe there will be archetypes for sections and entry that have the same name but this is not a good example. The entries for vital signs are BP, Pulse etc. I think it would be better to just raise the problem or get an example. The nearest one I can think of is a plural form - e.g: Problems (Section) and Problem (Entry). [HKF: ] The example that exist at present is INSTRUCTION.medication, ACTION.medication and ITEM_TREE.medication. This happens for procedure as well.
Archetyping links
Hmm, interesting idea. H -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Peter Gummer Sent: Wednesday, 10 June 2009 5:50 PM To: For openEHR technical discussions Subject: Re: Archetyping links Rong Chen wrote: I would say our use case for the link is also between compositions. For the reasons you mentioned, it would be nice to just use the archetypeId in the constraint for the value (URI) of the link. Then it starts to look like a mini query. It starts looking like a kind of slot too, but whereas a slot has aggregation semantics (i.e. the data in the slot is owned by the containing archetype), a link is just an association. So maybe links could use the same regular expression patterns that slots use. - Peter ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetyping links
Hi Rong,
Ocean certainly has runtime support for LINKs. The Ocean Archetype Editor
used to (and perhaps it is still there) have an initial implementation of
constraining LINKs but it became unclear if this was viable, useful or
appropriate. We tend to now think it is a template constrain if anything.
The common use cases we have used links is between compositions, whereas
your example below tends to be a relative uri within the current
compositions, which is quite legitimate but I want to ensure we consider the
more general case. For absolute URIs, the URI pattern becomes difficult to
determine because you have version specific URIs, relative version URIs
(e.g. latest_trunk_version), and system specific URIs. In addition, your
example assumes an exact understanding of the composition structure in which
the target is located, i.e. that the diagnosis exists within some section.
This is most likely not know at the time of creating the archetype with the
LINK and likely to be variable. Wildcards and RegEx patterns can make this
possible but start to get very complicated.
It is for these reasons that it became unclear how we can constrain the
target URI in an archetype. I have considered some extensions to AQL to be
able to query compositions that contain LINKs to specific object types. I
would need to review these thoughts but from memory it was along the lines
of the following.
... CONTAINS LINK CONTAINS EVALUATION
e[openEHR-EHR-EVALUATION.diagnosis.v1] ... WHERE e/...
The point here (and it may not be clear from my attempt to relate it to AQL)
is that there may need to be some indirect constraint required for LINKs,
i.e. something that does not physically exist in the current instance such
as a constraint on the target URI, but something that makes a assertion
about the real target of the URI.
I don't think there is an easy answer to these questions and only
implementation and ongoing discussion is likely toi find viable solutions.
Heath
-Original Message-
From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
bounces at openehr.org] On Behalf Of Rong Chen
Sent: Tuesday, 2 June 2009 7:04 PM
To: For openEHR technical discussions
Subject: Re: Archetyping links
Just want to be more specific about the questions (Daniel and I are
working together on this issue), I created the ADL following the
example from Daniel's post.
ELEMENT[at0002.1] matches { -- Diagnosis
value matches {
DV_CODED_TEXT matches {
defining_code matches {[ac0.1]
}
}
links matches {
LINK[at0003.1] matches { -- complication of
target matches {
DV_EHR_URI matches {
Value matches
{/content/items[openEHR-EHR-EVALUATION.diagnosis.v1]/}
}
}
}
}
The ADL is created manually, so it might not have the correct syntax.
But you probably get the idea anyway.
The general question is if LINK is intended to be a runtime
facilitator or something that could be used in design time
(archetyping) as well?
Secondly, what's the status of tooling support, both in authoring
environment (archetype editors) and runtime systems (querying for
instance)?
Any feedback will be appreciated!
Cheers,
Rong
2009/6/1 Daniel Karlsson daniel.karlsson at imt.liu.se:
Dear Everyone,
what are the possibilites of constraining the LINK.target attribute
(DV_EHR_UIR datatype) in an archetype? This was possible in earlier
versions of the Ocean Archetype Editor (although its use never was
clear
to me). Let's say that I want to constrain a link from an archetype
to
only allow linkage to instances conforming a specific set of
archetypes
(e.g. allowing linkage only to Diagnosis-archetype instances for
links
with complication of meaning.) Is it allowed to use a regexp
constraint on the DV_EHR_URI and include the archetype id? Is it
guaranteed that the archetype id can be used in the path as in 11.2.3
in
Architecture overview in run-time systems?
Regards,
Daniel
___
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
[Fwd: [JIRA] Created: (SPEC-302) Translations embedded in the ADL are not efficient and should instead use 'gettext' catalogs.]
Tim, As I mentioned, the requirement was to have a hash that can be referenced at runtime without the need to reference an online service. For example a recent version of the Ocean Template Designer includes integrity checking of archetypes used in a template to ensure that the archetype is the same as the one used when the template was last saved. If this process needed to perform these hash lookups using an online service there would be significant impact on the user experience. The latest version of the Ocean Archetype Editor provides this hash in the description other_details so that it can be easily ignored by systems that don't utilise it. The other point you make about the hash being provided by CKM is also worth commenting on. A simple hash on the ADL was not considered useful for the process above. For one, the hash of the archetype would be different for ADL and XML files. Secondly, any insignificant change (comments, whitespace, description meta-data) to the ADL file will change the hash even though the content (Archetype) model has not. For this reason we developed a canonical archetype serialization algorithm ensuring that the hash would be constant as long as the content model was the same. Unfortunately, this algorithm did include the ontology and its translations but this was deemed to be a change to the content model, hence a new hash value was necessary. I will contribute this canonical archetype serialization and hashing specification to the openEHR wiki as soon as I can get Thomas to create me a page. Regards Heath -Original Message- From: Tim Cook [mailto:timothywayne.cook at gmail.com] Sent: Thursday, 30 April 2009 7:08 PM To: Heath Frankel Cc: 'For openEHR technical discussions' Subject: RE: [Fwd: [JIRA] Created: (SPEC-302) Translations embedded in the ADL are not efficient and should instead use 'gettext' catalogs.] On Thu, 2009-04-30 at 16:28 +0930, Heath Frankel wrote: Hi Koray, I will let others respond about translations etc, but I did want to pick up on your point about multi-part file. This was an option recently consider when we were looking at a mechanism to record an MD5 Hash of the archetype. There was a desire to provide this hash external to the ADL itself whilst making it available to the archetype consumer locally so it was not necessary to query some external notary service to do the integrity check. Using a multi-part file would allow the usual PGP message and signature parts to be used. It was thought to be quite a disruptive change, but if there are other reasons to do this... The MD5 for an archetype is now available in the CKM. IIRC, this was to verify the validity of the actual ADL source aas having come from the CKM. But, since archetype exports are being generated as .zip files there is no reason (that I can think of) why this couldn't be applied on the fly if a user selects only a few languages (as Hugh suggested) or if a bundle is created that includes the original language plus specific .po translation files. As I said in my response to Hugh, this is certainly a long term issue but I think it should be addressed sooner rather than later. Cheers, Tim
[Fwd: [JIRA] Created: (SPEC-302) Translations embedded in the ADL are not efficient and should instead use 'gettext' catalogs.]
Hi Koray, I will let others respond about translations etc, but I did want to pick up on your point about multi-part file. This was an option recently consider when we were looking at a mechanism to record an MD5 Hash of the archetype. There was a desire to provide this hash external to the ADL itself whilst making it available to the archetype consumer locally so it was not necessary to query some external notary service to do the integrity check. Using a multi-part file would allow the usual PGP message and signature parts to be used. It was thought to be quite a disruptive change, but if there are other reasons to do this... Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Koray Atalag Sent: Wednesday, 29 April 2009 9:17 AM To: timothywayne.cook at gmail.com; For openEHR technical discussions Subject: Re: [Fwd: [JIRA] Created: (SPEC-302) Translations embedded in the ADL are not efficient and should instead use 'gettext' catalogs.] Hi Tim, an important issue for me too! The archetypes I am working with (Endoscopy ones) are already quite big and there are 11 (yes eleven) languages! I completely translated one of them (MST Colon) and it is 6359 lines long. I also had quite an experience with localisation of software in past where strategies similar to gettext was quite practical and successful. BUT: I think all aspects of the knowledge - including the translations should better stay within the Archetypes. Because: 1) If the purpose if for 'resuse', then having multiple files around can be quite problematic. 2) same with specialisations - have to maintain a complex versioning process 3) For non-English primary language archetypes, this will make it impossible for others (well 99% of the rest of the World I guess) to understand without using tools (i.e. a text editor). However, with the current scheme we must also decide how to modify translations. I don't know if this has been discussed before but translation changes are frequently needed and as I can see this does not necessitate specialisation. Perhaps with versioning of archetypes - but then this might create many versions out there and can make things complicated. In this case your proposal seems more appropriate. One straightforward solution might be to adopt a propriety file type for representing archetypes - i.e. a multipart file. Still human readable but can accomodate more than a single file and perhaps support other file types as wellHowever I fear this is how usually things get very complicated and result in the increase of the ciriticism that openEHR is too complex and technical! So as result, I am inclined towards keeping it all in archetypes - unless we find a sound and sensible approach ;) -koray -- Koray Atalag, MD, Ph.D Clinton Bedogni Research Fellow The University of Auckland, Department of Computer Science, Private Bag 92019, Auckland 1142, New Zealand Tel: +64 (9) 373 7599 ext. 87199 Fax: +64 (9) 308 2377 Email: koray at cs.auckland.ac.nz Tim Cook wrote: Hi All, I raised the below CR and I wanted to open up discussion on this issue. Actually I brought it up a few years ago but I don't have a record of where/when; now. I know that this have a major impact on implementers but I think the current way we handle translations in ADL is a monster that is only going to get worse. Thoughts? --Tim Forwarded Message From: Tim Cook (JIRA) mailto:jira-ad...@openehr.org jira-admin at openehr.org To: timothywayne.cook at gmail.com Subject: [JIRA] Created: (SPEC-302) Translations embedded in the ADL are not efficient and should instead use 'gettext' catalogs. Date: Tue, 28 Apr 2009 21:47:02 +0100 (BST) Translations embedded in the ADL are not efficient and should instead use 'gettext' catalogs. -- Key: SPEC-302 URL: http://www.openehr.org/issues/browse/SPEC-302 Project: Specification Issue Type: Change Request Reporter: Tim Cook Archetypes like openEHR-EHR-OBSERVATION.blood_pressure.v1 with four translations are huge and tedious to process the languages. openEHR should adopt the standard use internationalization (i18n) and localization (i10n) tools that use gettext catalogs. This is the industry standard approach to performing translations. Tools like POEdit are open source and cross platform http://www.poedit.net/ More info about gettext is here: http://www.gnu.org/software/gettext/manual/gettext.html though it is about the GNU set of tools there are others. What will openEHR-EHR-OBSERVATION.blood_pressure.v1 look like with 10, 15, 100 translations? _ ___ openEHR-technical mailing list openEHR-technical at openehr.org
possible error small error in BaseTypes.xsd (version 1.0.1)
Hi Bert, Yes I agree, it should be xs:complexType name=DV_AMOUNT abstract=true ... Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Bert Verhees Sent: Saturday, 11 April 2009 7:00 PM To: openehr-technical at openehr.org Subject: possible error small error in BaseTypes.xsd (version 1.0.1) According to the documentation (http://www.openehr.org/releases/1.0.1/architecture/rm/data_types_im.pd f) should xs:complexType name=DV_AMOUNT be marked abstract. Bert ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Definition of persistence for a composition
Hi Tom, Would this be a template on the EHR_EXTRACT? Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Thomas Beale Sent: Sunday, 5 April 2009 6:50 PM To: For openEHR technical discussions Subject: Re: Definition of persistence for a composition Leonardo Moretti wrote: Hi Sam, thanks for your reply. I try to explain which is my issue. Generally in an application form we can have persistent and not persistent data. Actually template specifications allow at most one composition in each template, but this means that a template contains or all persistent data or all not persistent data. In order to define template with both persistent and not persistent data, we should be able to have template with more than one composition. Has anyone solved this problem? leo * It is not currently in the template concept, but it has been talked about. The design question is whether we should have 'multi-root point' templates, or whether there should be a construct at a higher level than a template which puts templated top-level objcets (like Compositions) together, and which allows not only multiple templates, each of which could be from a different data source, but other, external data sources, i.e. other databases in the environment. It would also be able to include queries, so that some fields would be the results of this, rather than entry fields. This concept might be thought of as a 'form' or 'data package' of some kind. I am in favour of this higher level concept, which allows each included template and other data items to be bound to different data sources. - thomas beale * ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Why is the editor not opening ADL files?
William, When you say browsing existing archetypes from Ocean, where exactly are you browsing? Heath From: openehr-clinical-boun...@openehr.org [mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Williamtfgoossen at cs.com Sent: Saturday, 14 March 2009 12:59 AM To: openehr-clinical at openehr.org; openehr-technical at openehr.org Subject: Why is the editor not opening ADL files? Dear all, I am browsing through the existing archetypes from Ocean, obviously created by the Ocean Archetype Editor given the file name. E.g. openehr-demographic-person.person.draft.adl When I try to open it with the AE, I do get continuously error messages similar to: cid:image001.jpg at 01C9A636.08E17D50 Is there anything wrong with the archetypes, or is this an error in the archetype editor. Anyone els experiencing such problems? Sincerely yours, dr. William TF Goossen director Results 4 Care b.v. De Stinse 15 3823 VM Amersfoort the Netherlands emails: Results4Care at cs.com williamtfgoossen at cs.com info at results4care.nl phone + 31654614458 fax +3133 2570169 www.results4care.nl Dutch Chamber of Commerce number: 32133713 -- next part -- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 15133 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090316/594084a3/attachment.dat
Why is the editor not opening ADL files?
Bert, The Ocean Archetype Editor was the first Archetype Editor written some 6+ years ago. It was implemented to support only EHR archetypes in a way that these RM types where implemented explicitly within the Editor providing the specific capability for clinicians to easily develop archetypes with minimal knowledge of the RM. Certainly a generic archetype editor would need to support the features you suggest below, but the Ocean Archetype Editor is not a generic Archetype Editor. Even with its limitations known best by Ocean, I think we can all agree that it has served the openEHR community well in bringing the mind shifting concepts of archetypes to a point where the openEHR architecture is in demand internationally. Regards Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Bert Verhees Sent: Sunday, 15 March 2009 11:26 PM To: For openEHR technical discussions Subject: Re: Why is the editor not opening ADL files? Williamtfgoossen at cs.com schreef: In a message dated 14-3-2009 17:23:18 W. Europe Standard Time, caultonpos at gmail.com writes: How many more types of archetypes are we envisioning to support? I think the tools need to support ANY archetype that represents valid content in health care. An archetype editor should simply support any archetype which represents a valid locatable according to the reference model, plus, it must adapt the other archetype-rules as defined in the reference model, such as header requirements, etc. That is why I don't understand the trouble with supporting demographic archetypes, it are just locatables, with a few extra characteristics, but that is also the case for composition or other archetypes. It are all just locatables. Maybe some one can explain this. In a few months, I will have more time, I will add the support myself, I even install Windows, if necessary. Maybe I find out by then what I have overlooked all the time. Bert -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090316/bd0a9595/attachment.html
AQL-parser in Java? + AQL response format (using the AS operator)
Hi Erik, Response to 2, the Ocean EhrGate Web Service provides a ResultSet as defined in the following WSDAL fragment: xs:complexType name=ResultSet xs:sequence xs:element minOccurs=0 name=name type=xs:string / xs:element name=totalResults type=xs:int / xs:element minOccurs=0 maxOccurs=unbounded name=columns nillable=true xs:complexType xs:sequence xs:element minOccurs=0 name=path type=xs:string / xs:element minOccurs=0 name=name type=xs:string / /xs:sequence /xs:complexType /xs:element xs:element minOccurs=0 name=rows xs:complexType xs:sequence xs:element minOccurs=0 maxOccurs=unbounded name=row xs:complexType xs:sequence xs:element minOccurs=0 maxOccurs=unbounded name=items nillable=true / /xs:sequence /xs:complexType /xs:element /xs:sequence /xs:complexType /xs:element /xs:sequence /xs:complexType I am very interested in the idea of basing a query result class on the ITEM_TABLE class for consistency reasons, however ITEM_TABLE cannot be used directly because it is limited to rows of ELEMENTs. A query result class needs to support rows of ANY items as is the case above. In addition, it may also be necessary to have a query result class that is based on the ITEM_TREE class to support more complex hierarchical query results that are difficult to unambiguously represent using a traditional table structure, which requires cross-join logic to be applied as mentioned recently (sorry we have not had time to respond to that post, day-job priorities). Heath -Original Message- From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Tuesday, September 30, 2008 6:35 PM To: For openEHR technical discussions Subject: AQL-parser in Java? + AQL response format (using the AS operator) Hi! 1. Has anybody planned, or started, to create an AQL-parser in Java? Maybe the basics from AQL to parse tree could be common for several different persistence implementations and then the rest of the implementation will be different for different persistence mechanisms. Our first interest will be in transforming AQL queries to queries against an XML-database containing versioned Compositions. (It's for an educational system where performance isn't crucial.) 2. Are there any suggestions for standardised response formats? It would be interesting if we could query each others' implementations (Python and various Java based ones) and interpret the response :-) When returning entire openEHR subtrees (an entire Composition or Entry for example) I guess the current XML-format could be used to start with. The response is likely to often be a list of such subtrees and the format of that list Would need to be standardised. Another case is when using the AS operator, how do we in a standardised way identify the named parts. Best regards, Erik Sundvall erisu at imt.liu.sehttp://www.imt.liu.se/~erisu/Tel: +46-13-227579 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
AQL-parser in Java? + AQL response format (using the AS operator)
Sorry, I didn't realise when I responded to this that it was such an old post (having email management problems). Anyway, it seems to be current hot topic so it probably won't go to waste. Heath -Original Message- From: Heath Frankel [mailto:heath.fran...@oceaninformatics.com] Sent: Wednesday, March 04, 2009 12:25 PM To: 'erisu at imt.liu.se'; 'For openEHR technical discussions' Subject: RE: AQL-parser in Java? + AQL response format (using the AS operator) Hi Erik, Response to 2, the Ocean EhrGate Web Service provides a ResultSet as defined in the following WSDAL fragment: xs:complexType name=ResultSet xs:sequence xs:element minOccurs=0 name=name type=xs:string / xs:element name=totalResults type=xs:int / xs:element minOccurs=0 maxOccurs=unbounded name=columns nillable=true xs:complexType xs:sequence xs:element minOccurs=0 name=path type=xs:string / xs:element minOccurs=0 name=name type=xs:string / /xs:sequence /xs:complexType /xs:element xs:element minOccurs=0 name=rows xs:complexType xs:sequence xs:element minOccurs=0 maxOccurs=unbounded name=row xs:complexType xs:sequence xs:element minOccurs=0 maxOccurs=unbounded name=items nillable=true / /xs:sequence /xs:complexType /xs:element /xs:sequence /xs:complexType /xs:element /xs:sequence /xs:complexType I am very interested in the idea of basing a query result class on the ITEM_TABLE class for consistency reasons, however ITEM_TABLE cannot be used directly because it is limited to rows of ELEMENTs. A query result class needs to support rows of ANY items as is the case above. In addition, it may also be necessary to have a query result class that is based on the ITEM_TREE class to support more complex hierarchical query results that are difficult to unambiguously represent using a traditional table structure, which requires cross-join logic to be applied as mentioned recently (sorry we have not had time to respond to that post, day-job priorities). Heath -Original Message- From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Tuesday, September 30, 2008 6:35 PM To: For openEHR technical discussions Subject: AQL-parser in Java? + AQL response format (using the AS operator) Hi! 1. Has anybody planned, or started, to create an AQL-parser in Java? Maybe the basics from AQL to parse tree could be common for several different persistence implementations and then the rest of the implementation will be different for different persistence mechanisms. Our first interest will be in transforming AQL queries to queries against an XML-database containing versioned Compositions. (It's for an educational system where performance isn't crucial.) 2. Are there any suggestions for standardised response formats? It would be interesting if we could query each others' implementations (Python and various Java based ones) and interpret the response :-) When returning entire openEHR subtrees (an entire Composition or Entry for example) I guess the current XML-format could be used to start with. The response is likely to often be a list of such subtrees and the format of that list Would need to be standardised. Another case is when using the AS operator, how do we in a standardised way identify the named parts. Best regards, Erik Sundvall erisu at imt.liu.sehttp://www.imt.liu.se/~erisu/Tel: +46-13-227579 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
International representation of decimal magnitude in DV_QUANTITY
Hi all, Our.NET implementation of the openEHR RM DV_QUANTITY is dependent on the regional setting on the system, for example a magnitude of 1.0 on a system with 'en' regional settings will be represented as 1,0 on a system with 'de' regional settings. Thilo has recently identified an issue where our serialisation of these RM objects when in the 'de' culture produces an XML instance of DV_QUNATITY as follows: value xsi:type=DV_QUANTITY magnitude1,2/magnitude unitsmm/units /value When validated against the openEHR XML schema, this is not valid because DV_QUANTITY.magnitude is declared as type=xs:double. We can resolve this issue in our implementation, but the question is if openEHR wants to support DV_QUANTITY.magnitude representations containing a comma. The openEHR data types specifications indicates that assumes built-in primitive types such as Character, Boolean, Integer and Double based on ISO 11404 within an implementation environment such as Java, .NET. and XML. This was the rational of using the xs:double type in the openEHR XML Schema for DV_QUANTITY.magnitude. Having said that, the openEHR XML schema has implemented its own ISO8601_x assumed Date/Time types because the built-in XML Schema DateTime type does not support the openEHR assumed ISO8601 capability of partial date/time, nor the separate Date and Time types. The ISO8601_x types implemented in the openEHR XML Schema does support both period (.) and comma (,) for fractional seconds. I have spoken to Tom about this and we feel that openEHR has two options: 1) Update the XML Schema to implement an culture aware double type to be used in DV_QUANTITY.magnitude. This change would not invalidate any existing data instances but would make instances based on that new schema invalid against previous revisions. 2) Leave the XML Schema as is and make culture-aware serialisation and rending responsible for converting the representation of DV_QUNATITY.magnitude into the local cultures representation. Can anyone suggest another option? It is Thomas and my preference for option 2. Are there anyone from the regions that use the comma representation of decimal points that feel that option 1 is necessary? Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 mb: +61 (0)412 030 741 email: mailto:heath.frankel at oceaninformatics.biz heath.frankel at oceaninformatics.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090129/688dc2a6/attachment.html
Q on openEHR XML-schema versioning
Andrew, There was a decision by Heath (and others at Ocean) to have a single namespace for all the openehr XML classes around the time of the 1.0 release. The schemaLocation of XSD files is a separate issue and one that I would not worry about - assume that all XSD files bundled together in the same directory belong to the same release set (as is currently the case) Actually the namespace decision including its current format was made in conjunction with other openEHR members including yourself and Rong as far as I remember. Heath
{Disarmed} Re: Q on openEHR XML-schema versioning
Thomas,
The original namespace was designed in a way that would not require a change
until there was a radical RM (or schema design) change.
I would suggest that the principles are similar to archetype versions and
revisions, the namespace will require a change when the schema change breaks
existing data, otherwise it is just a version change.
The version attribute in the schema does not affect the data at all, it is
for version control information to the users of the schema. I don't care
what goes there but at the time the openEHR release seemed logical. If a
new release changes the schema (in a compatible way) the release number of
that specific schema can change otherwise I don't see any need to upgrade
the version ID just because of a new release, but as I said I don't care
that much because it has no affect on the data as long as I know what schema
I need to deploy with my version specific openEHR components.
The question is, what do we do when we do have a data breaking schema
change, like potentially in r1.1? I suggest that we just go with
http://schemas.openehr.org/v1.1 and we can assume the old
http://schemas.openehr.org/v1 meant r1.0.x. It wasn't expected to have such
a substantial schema change until r2 but I guess that is the reality of
software.
Jumping ship to another style such as http://schemas.openehr.org/2009/03
would also be reasonable, it would just mean we have to correlate release
dates with release numbers.
BTW Andrew,
There is an optional rm_version in the archetype_details attached to any
archetyped locatable. We currently populate this only when we specify a
template_id on the composition, which is all compositions in our
applications. We could suggest that this is required for all compositions
and make this the handle to determine what schema to use for validation.
Heath
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Wednesday, 10 December 2008 10:23 PM
To: For openEHR technical discussions
Subject: {Disarmed} Re: Q on openEHR XML-schema versioning
Andrew Patterson wrote:
ok - this approach more or less replicates the release id approach
already in use, but converts it to a URL.
Except, this is a change that occurs in all xml _instances_, not just
the schema files. So every reference model document in every
system in existence now has to handle two different schemas
and convert between them. We have to decide whether this is
what we want.. do the xml schemas aggressively track the
exact spec versions, or do we only increment xml schema
versions when necessary (and therefore should the xml
schemas have a separate version)
I don't think this is the case - each document should just indicate which
schema it is derived from. There will always be new and improved XML-schemas
- that is just the nature of a formalism that is inherently inefficient -
people will keep coming up with ways to improve it. Any document created
from a previous version of the schema will point to the earlier version.
Since all schemas in openEHR are designed to convert into the same reference
model, the data remain interoperable (unlike purely schema-based approaches
to health data).
The main point it seems to me is what the schema should carry as its
namespace... is it (as today):
xs:schema xmlns:xs= http://www.w3.org/2001/XMLSchema MailScanner has
detected a possible fraud attempt from www.w3.org claiming to be
http://www.w3.org/2001/XMLSchema; xmlns= http://schemas.openehr.org/v1
MailScanner has detected a possible fraud attempt from schemas.openehr.org
claiming to be http://schemas.openehr.org/v1;
targetNamespace= http://schemas.openehr.org/v1 MailScanner has
detected a possible fraud attempt from schemas.openehr.org claiming to be
http://schemas.openehr.org/v1; elementFormDefault=qualified
version=v1.0.2
id=BaseTypes.xsd
or more like:
xs:schema xmlns:xs= http://www.w3.org/2001/XMLSchema MailScanner has
detected a possible fraud attempt from www.w3.org claiming to be
http://www.w3.org/2001/XMLSchema; xmlns= http://schemas.openehr.org/v1
MailScanner has detected a possible fraud attempt from schemas.openehr.org
claiming to be http://schemas.openehr.org/v1;
targetNamespace= http://schemas.openehr.org/v1 MailScanner has
detected a possible fraud attempt from schemas.openehr.org claiming to be
http://schemas.openehr.org/v1.0.2; elementFormDefault=qualified
id=BaseTypes.xsd
I don't know what weight the 'version' attribute carries in the xs:schema
tag - I don't understand why there appear to be two ways of indicating the
version in fact.
The schema identifier is a URI - there is no requirement that it is
accessible at the same identifier, and in fact it seems like there
is a trend towards using other URN syntaxes rather than
URLs.
so sticking with the current style of URI is no problem.
- thomas beale
-- next part
{Disarmed} Re: text and description
This was the exact approach that was proposed in work within Standards
Australia to represent Archetyped data in HL7 v2. The at-codes defined in
the ontology section of the archetype was used in a coded element concept ID
and the archetype ID was used as the coding system (compared with local
when refer to internally). This approach could certainly be extrapolated to
localised coded terms specified in templates using the template ID (assuming
that it is globally unique).
Heath
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sam Heard
Sent: Wednesday, 3 December 2008 12:45 PM
To: 'For openEHR technical discussions'
Subject: RE: {Disarmed} Re: text and description
Hi All
I think we are addressing an issue that will come up in templates as well.
How to add terms from a local terminology directly into a template. Local is
used for the archetype terms - I have wondered if we should use a template:
namespace for terms that are created only in the template but for
internationalisation.
Cheers, Sam
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Ian McNicoll
Sent: Wednesday, 3 December 2008 3:44 AM
To: For openEHR technical discussions
Subject: {Disarmed} Re: text and description
Same patten less the dots should be ok then?
e.g. sechalmersMUKOS::
Ian
Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian at mcmi.co.uk
Clinical Analyst - Ocean Informatics ian.mcnicoll at oceaninformatics.com
Member of BCS Primary Health Care Specialist Group - www.phcsg.org
2008/12/2 Thomas Beale thomas.beale at oceaninformatics.com
Ian McNicoll wrote:
Hi Thomas,
According to Support_IM 5.3.2
Valid identifiers that can be used for this attribute for
terminologies include but are not limited to the
following:
. openehr
. centc251
. an identifier value from the first column of the US National Library
or Medicine (NLM)
UMLS terminology identifiers table below, in either of two forms:
- as is, e.g. ICD10AM_2000, ICPC93;
- with any trailing section starting with an underscore removed, e.g.
ICD10AM.
So, as far as I can see it should be possible to use a local
identifier, although not supported by the editors at present, the
issue being how to namespace the terminology uniquely.
I could not see anything in other documentation
For Olof's project I am proposing to use e.g.
se.chalmers.MUKOS::mukos-reaktion
Ian,
only problem - that identifier would not be allowed in the (imminent)
Release 1.0.2 of openEHR (see
http://www.openehr.org/svn/specification/BRANCHES/Release-1.0.2-candidate/pu
blishing/roadmap.html)
http://4.3.12.1 MailScanner has detected a possible fraud attempt from
4.3.12.1 claiming to be MailScanner warning: numerical links are often
malicious: 4.3.12.1 Identifier Syntax
The syntax of the value attribute is as follows:
# production rules
terminology_id: name [ '(' version ')' ]
name: V_NAME
version: V_VERSION
# lexical patterns
V_NAME: [a-zA-Z][a-zA-Z0-9_-/+]+
V_VERSION: [a-zA-Z0-9][a-zA-Z0-9_-/.]+
*
*
___
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/20081203/b7f029f2/attachment.html
text and description
Erik, I don't see the difference. The same approach can be used with different query parameters and terminology identifiers. We just need to find a way to uniquely identify local terminology ids, some sort of namespacing mechanism such as a terminology source organisation UID should do the trick. This would not be that much different to uniquely identifying templates which is also under development. Heath -Original Message- From: e.sundvall at gmail.com [mailto:e.sundvall at gmail.com] On Behalf Of Erik Sundvall Sent: Tuesday, 2 December 2008 7:03 PM To: For openEHR technical discussions Cc: Heath Frankel; hugh.grady at oceaninformatics.com Subject: Re: text and description Hi! I know that there are suggestions for defining terminology queries/subset-selections using URIs. We discussed this a bit in a conference paper that was selected for republication in BMC: Integration of tools for binding archetypes to SNOMED CT freely available at http://www.biomedcentral.com/1472-6947/8/S1/S7 This kind of URI-encoded queries with semantics have come and gone and seem to be coming again in openEHR discussions. Sometimes the URIs have contained semantics similar to what you describe below. Sometimes they have just contained ID's of queries that have their semantics hidden, sorry I mean stored/maintained, in some query server. See especially the appendix in the paper above for discussion and references. However, my recent question/suggestion did not have much to do with those URI-encoded terminology queries. Instead, I was asking about two specific use-cases: 1. directly pointing out single codes/concepts that already have URIs and 2. a way of creating local bindings using URIs as unique identifiers. Please re-read the previous post and feel free to ask more if I have not made the difference clear enough. Best regards, Erik Sundvall erisu at imt.liu.sehttp://www.imt.liu.se/~erisu/Tel: +46-13-227579 On Mon, Dec 1, 2008 at 22:28, Heath Frankel heath.frankel at oceaninformatics.com wrote: Hi Erik, As you know Ocean has been doing a lot of work making terminology and openEHR Archetype work. Hugh Grady is the best to describe this but in summary we are proposing the use of terminology URIs for bindings. Bindings can reference a whole terminology, a branch of a terminology hierarchy or a complex query which extracts specific subset of a terminology. To identify these there at least four identifiers; terminology ID, subset ID, query name and query version id. There are other parameters such as language and terminology version. In simply cases where you just want to reference a terminology it might look something like the following (NOTE: these are examples to illustrate the point and are certainly not a final proposal). terminology:snomed-ct?language=en-GB or for a specific version of SNOMED terminology:snomed-ct(2003)?language=en-GB For a hierarchy of a terminology it might look something like terminology:snomed-ct(2003)/hierarchy?rootConcept=28374832 and for a pre-specified query terminology:snomed-ct(2003)/query?name=AllBacteria There are also more specific URIs for terminology queries by using subset and query version identifiers (UIDs) mentioned above. I believe this work is ongoing and is being proposed through IHTSDO. I suggest we wait for that work to conclude but I thought I would let you know that Erik's thinking is certainly the way things are being proposed. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Monday, 1 December 2008 11:20 PM To: For openEHR technical discussions Subject: Re: text and description Hi! Would it be a good or bad idea to have URI:: as a valid terminology prefix in openEHR terminology bindings, with the intention to host... 1. local bindings that are not foreseen to be of public general use: URI::http://www.cs.chalmers.se/~oloft/terminologies/odont-123/local-Mucos- txtur 2. Potentially universally interesting terminologies that already have official URIs but do not (yet?) have openEHR-defined prefix: URI::urn:miriam:obo.go:GO%3A0045202 I guess opening up for any URIs would lead to a risk of having double representations (URI+openEHR-prefix) for the same thing, like... URI::urn:UMLS/CID=C0037658 ...and the example URI::urn:miriam:obo.go:GO%3A0045202 is just one of several URI-ways to point out an entry in the gene ontology.. What are the other pitfalls and/or benefits? I guess there will probably never be only one ultimate updated registry fitting every purpose, not from openEHR, not from EuroRec not from anybody else. Best regards, Erik Sundvall erisu at imt.liu.sehttp://www.imt.liu.se/~erisu/Tel: +46-13-227579 P.s
Is originalAuthor required?
Adam,
As previously requested, provide us an example (one will do) of an archetype
failing, we can then work out why.
Heath
-Original Message-
From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
bounces at openehr.org] On Behalf Of Adam Flinton
Sent: Monday, 10 November 2008 1:37 AM
To: Rong Chen
Cc: Java OpenEHR; For openEHR technical discussions
Subject: Re: Is originalAuthor required?
Rong Chen wrote:
Hi Adam, Heath
The attribute in question, original_author is an attribute of Class
RESOURCE_DESCRIPTION from rm.common.resource package. According to the
specs (common_im.pdf), the type is HashString,String NOT a string
and the invariant on it is Original_author_valid: original_author /=
Void and then not original_author.is_empty.
The Java implementation (see below) of this invariant is, I believe,
faithful interpretation of the specs.
if (originalAuthor == null || originalAuthor.size() == 0 ) {
throw new IllegalArgumentException(null or empty
originalAuthor);
}
The thing I am not sure here is the XML schema. If the schema is not
compliant with the RM specs, perhaps the schema should be updated so
the parsing code generated from schema can catch errors like this,
thoughts?
Any idea then which is right?
I can chuck you our ADL XML ant task so you can look at all the
various errors against a given set of our ADL held on the openEHR svn.
Adam
***
This message may contain confidential and privileged information.
If you are not the intended recipient you should not disclose, copy
or distribute information in this e-mail or take any action in reliance
on its contents. To do so is strictly prohibited and may be unlawful.
Please inform the sender that this message has gone astray before
deleting it. Thank you.
2008 marks the 60th anniversary of the NHS. It's an opportunity to pay
tribute to the NHS staff and volunteers who help shape the service, and
celebrate their achievements.
If you work for the NHS and would like an NHSmail email account, go
to: www.connectingforhealth.nhs.uk/nhsmail
***
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-- next part --
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3498 bytes
Desc: not available
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081112/09270902/attachment.dat
Is originalAuthor required?
Rong,
Thanks for the clarification, I was assuming the error was coming from the
value of the hashtable rather than hashtable itself.
The XML schema contains the following:
xs:element name=original_author type=StringDictionaryItem
maxOccurs=unbounded/
This seems to reflect the spec (i.e 1..*).
It may be possible that the Ocean parser is not currently validating against
the schema but I would be interested to see the archetype causing this issue
to test this.
Heath
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Rong Chen
Sent: Friday, 7 November 2008 11:04 PM
To: For openEHR technical discussions
Cc: Java OpenEHR
Subject: Re: Is originalAuthor required?
Hi Adam, Heath
The attribute in question, original_author is an attribute of Class
RESOURCE_DESCRIPTION from rm.common.resource package. According to the specs
(common_im.pdf), the type is HashString,String NOT a string and the
invariant on it is Original_author_valid: original_author /= Void and then
not original_author.is_empty.
The Java implementation (see below) of this invariant is, I believe,
faithful interpretation of the specs.
if (originalAuthor == null || originalAuthor.size() == 0 ) {
throw new IllegalArgumentException(null or empty originalAuthor);
}
The thing I am not sure here is the XML schema. If the schema is not
compliant with the RM specs, perhaps the schema should be updated so the
parsing code generated from schema can catch errors like this, thoughts?
Cheers,
Rong
On Thu, Nov 6, 2008 at 2:10 AM, Heath Frankel
heath.frankel at oceaninformatics.com wrote:
Hi Adam,
Can you provide details of the offending archetype?
Looking at the AOM, the originalAuthor is a required attribute and this is
reflected in the Resource.xsd. However apart from the list being non-empty,
I see no other invariant to that states that the value of the originalAuthor
item cannot be an empty string.
Therefore I would suggest that the Java IllegalArgumentException null or
empty originalAuthor is too tight. A not null invariant seems
reasonable.
However, not being a member of the java implementation I will leave that to
them to decide what to do here.
If there is an issue with the Ocean XML output please feel free to contact
me directly.
Heath
-Original Message-
From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
bounces at openehr.org] On Behalf Of Adam Flinton
Sent: Thursday, 6 November 2008 1:30 AM
To: Java OpenEHR; openEHR technical discussions
Subject: Is originalAuthor required?
Dear All,
Running the Java ADL XML I get a fair few errors of the type:
Error Class: java.lang.IllegalArgumentException Message: null or empty
originalAuthor
Is originalAuthor a required structure?
If so then the Ocean ADL XML is not picking that up.
If not then could the Java code be amended to not error if it is not
present.
TIA
Adam
***
This message may contain confidential and privileged information.
If you are not the intended recipient you should not disclose, copy
or distribute information in this e-mail or take any action in reliance
on its contents. To do so is strictly prohibited and may be unlawful.
Please inform the sender that this message has gone astray before
deleting it. Thank you.
2008 marks the 60th anniversary of the NHS. It's an opportunity to pay
tribute to the NHS staff and volunteers who help shape the service, and
celebrate their achievements.
If you work for the NHS and would like an NHSmail email account, go
to: www.connectingforhealth.nhs.uk/nhsmail
***
___
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
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081108/abce26f0/attachment.html
Description of files from Template Designer?
Hi Olof, Ocean currently does what you are intending to do here but we do not use the .OET file. As mentioned by others, the .OET only represents the references to archetypes and the additional constraint rules to apply to those archetypes. To utilise this for anything of use you need to combine the template, archetypes and rules together in memory before applying any additional logic to the template definition. BTW, the latest OET schema is always deployed with the Template Design in the schemas folder. As indicated by Ian, the Operational Template is what is intended to be used for software operations beyond the knowledge design process. The Ocean Template Designer has an Operational Template export function (File/Export/ as Operational Template). This features is continuing to be debugged with new template use case so depending on what version of the Template Designer you have, the resulting Operational Template may still have some issues. Using the latest Beta release (https://wiki.oceaninformatics.com/confluence/display/TTL/Template+Designer+ Beta+Release) is recommended and to return to for Beta updates on a regular basis. I can provide you with the current Operational Template schema that extends the Archetype schema. This schema (see https://wiki.oceaninformatics.com/confluence/display/TTL/Template+Designer+R esources) is relatively close to the new Template Object Model draft (available on the Wiki) but will be updated in the next couple of months to align with this new draft. Any migration from this OPT format to the new TOM will be much smaller than transitioning from OET to the TOM. From this OPT you can produce all sorts of artefacts, we produce an abstract form definition from which we can produce web forms in ASP.Net, Template Data Schemas (XML Schema), Template Data Objects (c# classes), HTML Documentation, Composition Prototypes (empty composition data instances). The OPT is a pivotal artefact bridging between the Knowledge Designs and Operational Software. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Olof Torgersson Sent: Thursday, 6 November 2008 8:39 PM To: openEHR technical discussions Subject: Description of files from Template Designer? Hi, Sorry if this is the wrong forum. Is there a description somewhere of the oet-files produced by the Ocean Informatics Template Designer? I would like to use the templates in an application as a basis for input forms, but then I need a specification of the file-contents. Regards Olof Torgersson --- Olof Torgersson Associate Professor Department of Computer Science and Engineering Chalmers University of Technology and G?teborg University SE-412 96 G?teborg, Sweden email: oloft at chalmers.se phone: +46 31 772 54 06 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081107/261c34dd/attachment.html
Is originalAuthor required?
Hi Adam, Can you provide details of the offending archetype? Looking at the AOM, the originalAuthor is a required attribute and this is reflected in the Resource.xsd. However apart from the list being non-empty, I see no other invariant to that states that the value of the originalAuthor item cannot be an empty string. Therefore I would suggest that the Java IllegalArgumentException null or empty originalAuthor is too tight. A not null invariant seems reasonable. However, not being a member of the java implementation I will leave that to them to decide what to do here. If there is an issue with the Ocean XML output please feel free to contact me directly. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Adam Flinton Sent: Thursday, 6 November 2008 1:30 AM To: Java OpenEHR; openEHR technical discussions Subject: Is originalAuthor required? Dear All, Running the Java ADL XML I get a fair few errors of the type: Error Class: java.lang.IllegalArgumentException Message: null or empty originalAuthor Is originalAuthor a required structure? If so then the Ocean ADL XML is not picking that up. If not then could the Java code be amended to not error if it is not present. TIA Adam *** This message may contain confidential and privileged information. If you are not the intended recipient you should not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents. To do so is strictly prohibited and may be unlawful. Please inform the sender that this message has gone astray before deleting it. Thank you. 2008 marks the 60th anniversary of the NHS. It's an opportunity to pay tribute to the NHS staff and volunteers who help shape the service, and celebrate their achievements. If you work for the NHS and would like an NHSmail email account, go to: www.connectingforhealth.nhs.uk/nhsmail *** ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
AQL querying by internal code
Hi Greg, If I understand your requirement correctly the following is the correct AQL (take note of the RM class capitalisation): Select pupils From EHR e CONTAINS COMPOSITION anyComposition CONTAINS OBSERVATION pupils[openEHR-EHR-OBSERVATION.pupils.v1] Where pupils/data/events[at0002]/data/rows[at0013]/items[at0015]/value/defining_co de/code_string = 'at0016' A possible variation of the WHERE expression is as follows: Where pupils/data/events[at0002]/data/rows[at0013]/items[at0015]/value/defining_co de = 'local::at0016' Regards Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Thursday, 2 October 2008 11:43 PM To: For openEHR technical discussions Subject: AQL querying by internal code Will the AQL queries qualifying on Archetype internal codes do so using the value of the code and if so will it use the full path to that value. For example if we wanted to find all patients with pupils observed to be sluggish/slow would the query be: Select pupils From EHR e CONTAINS Composition anyComposition CONTAINS Observation pupils[openEHR-EHR-OBSERVATION.pupils.v1] Where pupils/data/events[at0002]/data/rows[at0013]/items[at0015]/value = pupils/data/events[at0002]/data/rows[at0013]/items[at0015]/value/defining_co de /[at0016] where [at0016] is the internal code for that archetype. I couldn't find an example on the wiki. thanks! Greg ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
AQL
Hi Tim, It is great to here that you are taking AQL seriously and plan to write a python implementation, your feedback I am sure will be invaluable. We have not done a lot of work on queries for some time but have recently been doing some work related to projects and have started to think about some changes to the current AQL proposal published on openEHR, to simplify and generalise the grammar and supporting more advanced queries features such as a matches operator. I have started a wiki page, http://www.openehr.org/wiki/display/spec/Proposed+AQL+changes, to briefly list what changes we are thinking about. When we get the time to update the BNF for these proposed changes, we will attach it. If you have a look at these proposed changes you will see that they are significant from a grammar (and parser perspective) but does not change the general intent. I would appreciate your (and anyone else) early feedback on these proposed changes even if you have not had a chance to implement AQL yet (even at a high level). My main concern is that you invest time into implementing the current proposal and make comments about issues when the proposed changes should make that task easier and shortcut some of the issues you would have commented on. I would like to think that we can work closely together during your implementation to ensure that we can address issues in real-time. Heath -Original Message- From: openehr-decisionsupport-bounces at openehr.org [mailto:openehr- decisionsupport-bounces at openehr.org] On Behalf Of Tim Cook Sent: Friday, 25 July 2008 1:59 AM To: Discussions relating to enabling decision support in openEHR Subject: Re: AQL On Thu, 2008-07-24 at 21:28 +0930, Sam Heard wrote: I am trying to start a conversation here for those seeking to use AQL and openEHR. We could provide a some tooling to get this moving and would even be very pleased to have feedback on how the Query Interface might go best. Hope to hear some ideas about how to progress this the best. We have recently enabled interactive editing of the language which does make it easier to test the capability of the engine. We would be happy to support people working in the open source space with developing the language further. I just noticed that there is a new BNF. I have been waiting for it to appear since the one I had was dated 2006. I have someone that will build a parser for this BNF and I will then map the query to the query engine that we have in OSHIP. This will take 3-4 weeks and by then we should be able to persist some sample data and start testing queries. But at this point I do not have any feedback on the existing status of AQL. Maybe in a couple of months. Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* **
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
Hi All, This extension idea is used in XForms in a similar manner. In fact this extension mechanism is actually something that I played with 18 months ago to represent AOM constraints of data associated with each form control expressed in XForms. I shelved this approach due to the complexity of implement this approach. I would be interested in revisiting this again with the aid of the community. However, Rong is proposing the opposite, having form extensions within the template. This could be viable. The other consideration I had when I objected internally to the Hide-on-form attribute provided by the Ocean Template Designer, was to have a separate section within the template for form definition details. This again is borrowed from XForms where it has the multiple sections including the Model (similar to template definition but in an instance form, although you can also reference an XML schema in XForms I believe), and View (form definition). Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Thilo Schuler Sent: Friday, 27 June 2008 10:12 PM To: For openEHR technical discussions Subject: Re: GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts)) Very interesting - maybe we could have seperate namespaces for the core tags and extensions. Could be a good compromise! While I see the advantages of keeping GUI stuff out of the template, I also see that this more and more complicated as we add additional abstraction layers. On Fri, Jun 27, 2008 at 2:26 PM, Rong Chen rong.acode at gmail.com wrote: Hi all, My thoughts on this is so far our experience with templates are mostly related to screen forms and GUI widgets. It's probably easiest to relate to screens when engage clinicians for templates reviewing, hence the need for visual presentation of templates from the NHS work. We also want to reuse the semantics in templates to generate messages, reports etc. The question is how much 'generic' semantics can be reused from the templates built for specific purpose - screen templates, message templates and report templates. Surely the content for all types of templates will be quite different and we probably would like to have special syntax to support GUI hints, but do we need special syntax to support other uses? How about indicators for decision support, clinical research data and information lifecycle management? I am thinking about an extendable markup language that can be plugged into the core template language as a way to add extensions to templates if there is any application specific meta-data required. I am also in favour of the idea to store these extra meta-data inside the templates to ease the maintenance. When passing these templates around, the template engines can ignore the extended markup and only process the standard part if they don't recognize the extended syntax. Something like gui_markup_plugin hide_in_GUI path=.../ hide_in_GUI path=.../ /gui_markup_plugin Cheers, Rong On Fri, Jun 27, 2008 at 12:30 PM, Thilo Schuler thilo.schuler at gmail.com wrote: Would also want GUI things like hide_in_GUI to be in a separate artifact on top of a template. It is good to hear that Ocean only did that as quick fix to meet customers requirements, which is very plausible. As mentioned before templates are great to initially SCAFFOLD a GUI, which has to be further adapted by humans for the best possible usability results (use-case and device specific). This allows verification of the templates and archetypes from a user point of view and is very important as Richard pointed out. I can understand Josinas comments about clinicians not caring about the difference between semantics and GUI stuff, so a tool like the Template Designer should hide this important separation, where appropriate. Thilo On Fri, Jun 27, 2008 at 10:03 AM, Hugh Leslie hugh.leslie at oceaninformatics.com wrote: Hi Erik Personally, I don't think that templates should contain GUI rendering hints as they should remain purely about the semantics. There are others that don't agree with me. The hide on form function in the Template designer was partly to meet requirements for documentation of the templates for some groups using this technology. I am not sure if the hide_in_ui parameter is going to make it into the final template spec - Tom will have something to say about that. Personally, I think that there should be some other artifact that details GUI specs - if we mix up the two things, then the purpose of the template becomes confused. Templates can be used for everything from GUI, to data instance, persistance and query. If we add a whole lot of parameters around GUI, then we will also probably need
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
Hi Thilo, It is interesting you have talked about the idea of scaffolding a GUI. This is exactly the work Ocean is doing at present. We have redeveloped our Web Forms engine to work based on this principle. From a template developed using the Ocean template Designer, we now generate a Form Definition file based on that template using a basic (and modifiable) presentation transformation. This assumes nothing about layout and only specifies the existence of controls within groups and incorporate the AOM constraints for the corresponding data bound object from the reference model. This gives forms engine all the information it needs to generate a basic form at runtime straight from a template. The advantage of having this form definition over simply creating a form straight from the template/archetype as demonstrated by Greg is that we can use the same artefact to customise the layout of the form using an editor. The forms engine can then process both designed (after initial scaffolding) and auto-generated forms as required. The Forms Definition format we are currently using is proprietary, but I would be interested give some time and reason to see how we can import/export into a standard format such as XForms. However, I am sceptical about the use of XForms unless we utilise extensions significantly otherwise we lose way too much information available in the AOM constraints. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Thilo Schuler Sent: Friday, 27 June 2008 8:00 PM To: For openEHR technical discussions Subject: Re: GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts)) Would also want GUI things like hide_in_GUI to be in a separate artifact on top of a template. It is good to hear that Ocean only did that as quick fix to meet customers requirements, which is very plausible. As mentioned before templates are great to initially SCAFFOLD a GUI, which has to be further adapted by humans for the best possible usability results (use-case and device specific). This allows verification of the templates and archetypes from a user point of view and is very important as Richard pointed out. I can understand Josinas comments about clinicians not caring about the difference between semantics and GUI stuff, so a tool like the Template Designer should hide this important separation, where appropriate. Thilo On Fri, Jun 27, 2008 at 10:03 AM, Hugh Leslie hugh.leslie at oceaninformatics.com wrote: Hi Erik Personally, I don't think that templates should contain GUI rendering hints as they should remain purely about the semantics. There are others that don't agree with me. The hide on form function in the Template designer was partly to meet requirements for documentation of the templates for some groups using this technology. I am not sure if the hide_in_ui parameter is going to make it into the final template spec - Tom will have something to say about that. Personally, I think that there should be some other artifact that details GUI specs - if we mix up the two things, then the purpose of the template becomes confused. Templates can be used for everything from GUI, to data instance, persistance and query. If we add a whole lot of parameters around GUI, then we will also probably need to add specific things for these other uses and it might get very messy. regards Hugh Erik Sundvall wrote: Hi! On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: Thanks to the java reference implementation I have a demo of importing archetypes to auto generate forms which have the references to the archetype. Nice. Keep up the good work. On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: One thing I noticed in the conversion that I don't have any way of distinguishing between a line of text and multiline text in the archetype (I would generate an appropriate pane in the latter case). Perhaps not a big deal. This might be a useful requirement for the current template specification currently being worked on, or possibly a new kind of related specification. I first thought that templates so far had been considered as purely specifying semantics and that they were not supposed to give hints regarding GUI rendering. But now I see a parameter hide_in_ui in the class T_COMPLEX_OBJECT found in the draft template specification. (A similar function is present in the Template Designer tool from Ocean Informatics there is an option to hide elements instead of constraining them to zero occurrence, in the output file this is persisted as hide_on_form=true.) Could anybody detail it's intended use a bit more? I think GUI rendering hints can be appropriate to specify at the same point in time as template design is taking
openEHR Querying specifications
The v1draft convention is already deprecated. The BNF for AQL doesn't support it deliberately, to ensure only non-draft archetypes are used when committing/retrieving data. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Peter Gummer Sent: Thursday, 5 June 2008 11:14 AM To: For openEHR technical discussions Subject: Re: openEHR Querying specifications Heath Frankel wrote: [openEHR-EHR-COMPOSITION.encounter.v1*] (or perhaps more correctly [openEHR-EHR-COMPOSITION.encounter.v1.*], where the dot means any character not the version delimiter) and [openEHR-EHR-COMPOSITION.encounter.v\d+] are different. The first allows all revisions of .v1 (e.g. v1.1, v1.2, ..) Close, but not quite! [openEHR-EHR-COMPOSITION.encounter.v1.*] allows all revisions of .v1, .v10, .v11, ... .v100, .v101, etc. To allow all revisions of .v1, we would need this: [openEHR-EHR-COMPOSITION.encounter.v1\..*] But what about .v1draft? This regex wouldn't catch it. Does this matter? Or is that old draft convention going to be phased out? - Peter ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
openEHR Querying specifications
Versions should be handled using the regular expression syntax of the archetype ID, as is done in ADL to represent slot constraints and action_arcehtype_id in ACTIVITY. E.g. [openEHR-EHR-COMPOSITION.encounter.v1*] BTW, using the OR operator you could have had ... CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1] OR COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v2] ... Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Ian McNicoll Sent: Wednesday, 4 June 2008 6:06 AM To: For openEHR technical discussions Subject: Re: openEHR Querying specifications Fair point. Perhaps AQL should support ranges of version numbers to simplify the query as in many cases the query will not be affected by a structrural change to the archetype e.g. FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v[BETWEEN 1.5 AND 2] CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v[=1] WHERE ( obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value = 140 Versions and revisions would need to be handled. Ian 2008/6/3 Greg Caulton caultonpos at gmail.com: -- Message: 2 Date: Tue, 03 Jun 2008 16:39:37 +0100 From: Thomas Beale thomas.beale at oceaninformatics.com Subject: openEHR Querying specifications To: Openehr-Technical openehr-technical at openehr.org Message-ID: 484565B9.6030805 at oceaninformatics.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed The current material is therefore intended as a resource for discussion and definition of a query language for openEHR. A team can be defined after sufficient time for the community to react to this material and determine if it makes sense to use AQL as the basis or to seek other solutions or candidates. - thomas beale Perhaps this has been answered but as the archetypes change version is it expected that the AQL will need to keep up with that - I assume our historic data would be specific to the archetype version - not 'upgraded' ? i.e. after v1: FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1] CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1] WHERE obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value = 140 after v2: FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v2] CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1] CONTAINS OBSERVATION obs2 [openEHR-EHR-OBSERVATION.blood_pressure.v2] WHERE ( obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value = 140 OR obs2/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value = 140 ) not sure if that is exactly right. thanks! Greg http://www.patientos.org ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr Ian McNicoll office +44(0)141 560 4657 fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com Consultant - IRIS GP Accounts Member of BCS Primary Health Care Specialist Group - http://www.phcsg.org ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
MIE-2008
Sounds good to me. I think the sub-page for the paper could be an optional thing but the link from the conference page can either go to a sub page or directly to the paper. The sub-page approach also assists with the attachment limit issue (which will need to be administered by someone) and allow comments to be made about the paper or presentation. Heath -Original Message- From: Tim Cook [mailto:timothywayne.cook at gmail.com] Sent: Monday, 2 June 2008 9:49 PM To: heath.frankel at oceaninformatics.com Cc: 'For openEHR technical discussions' Subject: RE: MIE-2008 On Mon, 2008-06-02 at 17:16 +0930, Heath Frankel wrote: Labels only work on pages, not on attachments. Are we looking at a page per paper or page per conference? If the former then this suggest could work, but I don't think is as good as an index, however much more automated. My full thoughts on this were: A main conference index page linked to a single page about the individual conferences. On the individual conference page there could be a brief description as well as dates/times and location of the conference. Each paper, presentation, poster, etc. is attached to a child page of this conference where the author could add the abstract or a brief description. This page carries the Labels for the attachment. This way only the main conference index has to be maintained by a single person and future conferences can be added as soon as we know of a planned openEHR event. This gives us everything linked to a specific conference as well as being able to search for specifically labeled subject matter across the site. --Tim -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* **
MIE-2008
Rong, The only limit on attachments I have found is the default maximum number of attachments per page, however this is configurable (not sure if there is any limits to the configuration). Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Rong Chen Sent: Friday, 30 May 2008 7:34 PM To: For openEHR technical discussions Subject: Re: MIE-2008 On Fri, May 30, 2008 at 11:48 AM, Thomas Beale thomas.beale at oceaninformatics.com wrote: Lisa Thurston wrote: Andrew Patterson wrote: Actually, is it possible to have a conferences page on the wiki that is a bit of a one-stop shop for documenting openEHR related contributions to conferences. Somewhere where authors could attach their presentations from last years Medinfo, the MIE 2008 etc - and maybe also lists of future conferences of interest to openEHR folks. I know I can create pages myself on the wiki but I'm still a bit unsure where things are supposed to go in the wiki tree. Andrew, I think this is a really good idea. A link from the homepage or static part of the website into a place on the wiki where users can upload papers and continue the discussion has potential as both a reference and a way to provide feedback and/or engage in discussion on each paper in one location. *I am fine with that - I don't think we had the wiki running when we did the MedInfo pages. Probably we should move that to the wiki as well and make a small web page. How do others feel about this. Note, if we go this way, I am likely to leav it up to conference paper-writers to put their own entries up in the relevant pages! Can we have reactions from a few more people - if the response is positive, I will organise the conference material onto the wiki. It sounds like a good idea to me. Is there any limit on the type/size of file that can be uploaded to the wiki page? Cheers, Rong - thomas beale * ___ 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/20080602/093470ac/attachment.html
Data-entry for OpenEhr
Bert,
I think you might be on the right track with your pathed values, it is very
similar to an approach that Tom and I discussed as a more efficient XML
representation of openEHR data. However, I think you are going to have to
keep in mind the complexity of the openEHR Data types, values will not be
able to be represented as attributes unless you have pathed items that go
down to the datatype attribute level such as .../value/magnitude, or invent
a whole new schema representation for each Data Type. You also need to
consider RM attributes such as LOCATABLE.uid, not just archetyped data
elements.
Again, I think the persistence model article on the WIKI is relevant here.
I know you have your own database persistence representation but you could
consider this an intermediate persistence representation. You are certainly
welcome to represent the data within your application as you wish, but it
would be good to work collaboratively to ensure that we don't have a huge
number of alternate intermediate formats and that we learn from these
experiences.
One comment I will make is that when working with application developers
unfamiliar with openEHR that the paths are very difficult for them to
comprehend and if you are at all expecting third parties to utilise an
intermediate format through some API rather than being completely
encapsulated within your software that paths will be problematic to the
uptake of that API. The comparison of openEHR paths with XPath is often not
useful to these kind of developers either.
Ocean is also developing the idea of a Template Data Schema, which will be
published as a draft on openEHR in the coming months. This does provide a
specific XML schema for a template (or combined collect of archetypes) where
the XML element names come from the archetype element names, but there is
additional meta-data in the schema and the XML document based on that schema
which links each XML element back to the archetype element such as the
node_ids so that generic transformation logic can be written to generate an
openEHR instance for any set of archetypes. These Template Data Schemas can
be automatically generated from the archetype/template models based on a set
of rules. I can give you a sample of this if you would like but I suspect
that you don't need this template specific approach, which is intended more
for those that unfamiliar with openEHR or you want a intermediate data
representation that is closer to a specific use-case for integration
purposes.
Heath
-Original Message-
From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
bounces at openehr.org] On Behalf Of Bert Verhees
Sent: Thursday, 24 April 2008 12:42 AM
To: For openEHR technical discussions
Subject: Re: Data-entry for OpenEhr
Tim Cook schreef:
Hi Bert,
Please note that this is MY understanding of the reference model and is
subject to change by the expert opinion of others.
On Wed, 2008-04-23 at 16:16 +0200, Bert Verhees wrote:
Archetypes are in fact RM-objects, I have a way to store RM-objects
efficiently.
Okay...good. :-)
My question: In what form should I shape the data, so that form is
usable with every possible valid archetype?
A, I think that this is the crux of the issue.
My answer is that you do not.
When data is captured (or changed) it is valid for THAT time and place
in accordance with the constraints of that version of that archetype.
That data is is not standalone, it is invalid anywhere else.
In order to maintain the semantic context; that data is tied to that
archetype, in a composition and submitted as part of a contribution.
I agree, that is what I do, what I try to find is a form to hand over
the data, with the archetype. So both, at the same time will be eaten
and stored by the kernel.
For example, I have a very simple archetype, only one data entry
The definition looks like this
definition
PERSON[at0] matches {
identities cardinality matches {0..*; unordered; unique} matches {
PARTY_IDENTITY[at1] matches {
name matches {
DV_TEXT matches {
value matches {legal identity}
}
}
}
I want to hand this archetype with data, for example from a webform, or
a message interpreter to my kernel which knows what to do with it.
At this moment, I am thinking about something like this, an XML form
which contains the archetype-ID, and there in, nodes with path and value
Because only leaf-nodes can contain data, there only leafnodes in the
XML-file
For example for this archetype it would be:
ArchetypedData
archetype_id=openEHR-EHR-CLUSTER.person_demographics.v1draft
ArchetypedDataset path=/identities[at0]/name[at1]/value
value=Johnsson/
/ArchetypedData
But I don't know if this is sufficient.
Anyway, this XML file will be given to the RM-builder,
TDS, public development on openEHR wiki instead? (Was: Data-entry for OpenEhr)
Erik, The only reason for keeping it internal at this point is resources, having the time to document what has been done thus far in a publishable form. We have also been refining the rules and transformation based on implementation experience which has made this even more difficult. However, we feel that we are very close and are working on the documentation as quickly as we can (given priorities). I understand that you want us to simply publish what we currently have, but this is not the approach that Thomas wants to take at this point. Our intent is to provide a description of the transformation rules, and an XSL transform. The other factor is that the source of this transform is an Operational Template document, which is yet to be stabilised as we are awaiting the next draft of the Template Specification. I suspect that the TDS transformation will be published after this. I will leave it to Thomas to make any further comment on his return from leave. Heath -Original Message- From: e.sundvall at gmail.com [mailto:e.sundvall at gmail.com] On Behalf Of Erik Sundvall Sent: Monday, 28 April 2008 5:44 PM To: heath.frankel at oceaninformatics.com; For openEHR technical discussions Subject: TDS, public development on openEHR wiki instead? (Was: Data-entry for OpenEhr) Hi! I believe TDS is a very nice approach for som especific integration purposes. Simple and wonderful invention (the best ones are often simple...) For those new to TDS there was a thread regarding this earlier: http://www.openehr.org/mailarchives/openehr-technical/msg03116.html Are there any specific reasons for keeping the development internal to Ocean Informatics? As I understand it you sometimes internally use a wiki for these kinds of developments, I would suggest that you move the TDS (and if possible the AQL) development to the public openEHR wiki instead as they are of strategic importance to openEHR. Just post what you have right now including a comment that this is only experimental. This way you might get more input and wider testing.Certainly people/projects wanting to use TDS early will feel a lot more confident regarding progress and might trust it as a viable path to go for certain projects that would be riskier if there was only an expected release date from a company that may need to revise it's at priorities any time (as most companies do). Preliminary implementation experiments could be started right away and updated+launched when the real specification is finished. Best regards, Erik Sundvall erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579 On Mon, Apr 28, 2008 at 3:46 AM, Heath Frankel heath.frankel at oceaninformatics.com wrote: Ocean is also developing the idea of a Template Data Schema, which will be published as a draft on openEHR in the coming months. This does provide a specific XML schema for a template (or combined collect of archetypes) where the XML element names come from the archetype element names, but there is additional meta-data in the schema and the XML document based on that schema which links each XML element back to the archetype element such as the node_ids so that generic transformation logic can be written to generate an openEHR instance for any set of archetypes. These Template Data Schemas can be automatically generated from the archetype/template models based on a set of rules. I can give you a sample of this if you would like but I suspect that you don't need this template specific approach, which is intended more for those that unfamiliar with openEHR or you want a intermediate data representation that is closer to a specific use-case for integration purposes.
On Information and Interoperability
Adam, If binary standards have dried up then why is W3C producing the Efficient XML Interchange http://www.w3.org/XML/EXI/? There is also ISO standard based on ASN.1 (http://asn1.elibel.tm.fr/xml/finf.htm) that also produces a binary encoding of XML. Perhaps there is a need to reduce XML document size? Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Adam Flinton Sent: Friday, 18 April 2008 11:21 PM To: timothywayne.cook at gmail.com; For openEHR technical discussions Subject: Re: On Information and Interoperability Tim Cook wrote: Hi Adam, On Fri, 2008-04-18 at 11:55 +0100, Adam Flinton wrote: Stepping outside of well supported standards increases maintenance requirements much much more. Well, I am not certain I would say much much more but in any case there are reasons why new standards are developed. Oh indeed however there are some givens wrt stds etc: A) Binary stds (esp on the wire) stds have died off (CORBA, COM etc) formatted text has taken off as a result of the plethora of langauges uses. I used to be a big OpenDoc/SOM person then I used to like RMI etc buttest messaging is a more survivable approach when people look at systems with long shelf lives (which is esp the case in terms of things like the CFH program). Like Python.OK this will work with itPerl? OK..C++? OKetc.etc. Being able to read a text file/stream is just about the lowest common denominator wrt inter-systems comms. B) wrt XML the std mark up of an element / etc attributes as basically properties/ini format of x=y is so std now (esp wrt the prevalence of HTML) that I can not see much shifting that. Wrt actual low level designs etc within that sphere (W3C Schema vs Relax or XSLTv1 vs V2 etc) then the higher level (e.g. HL7 Mif or XMI or SVG etc) will be subject to change the strady growth in new standards. The recent ODF/OOXML fight is an example of this. Heck why not write your ADL handling etc in PICK ? You might find it hard to get Dell et all to support Pick on your choice of hardware so why not try build your own hardware with Pick optimised chips while you're at it? I assume you meant to surround this with sarcasm tags. Only just. Once you start down the roll your own route where do you stop? If you want to write your very own persistence mechanism/db I cannot but admire your ambition but I would caution wrt expecting others wishing to use it vs spending a bit more on hardware. This wasn't the subject. I used the SQL database use as an analogy. I don't need to create my own (even if I could) object databases prove themselves very useful in implementation. See above. How this applies to healthcare is that healthcare information must contain truth. That truth is fully dependent on the complete context of where, when and how it was recorded. This context needs to be understood in all spatial and temporal instances where this information is or may need to be used. An obvious response would be that Heisenberg would argue with the above. Well, I am not a quantum physicist and would not argue with him in that domain of course. However, a lot has changed in information processing since he passed away in 1976. I would venture to guess that he might have made some adjustments to his uncertainty principle in the process. There is certainly a great deal of vagueness in healthcare information and the ARB has had MANY discussions about handling these situations. But I still maintain that vagueness nor uncertainty negates the expected truth value of healthcare information. The truth of healthcare information exists in the context of which it is collected. It may later proved to be incorrect but if the complete context of the information is known, it will be understood by the receiver. An interesting subject indeed but we are drifting off the subject to some extent. :-) G However the whole point of an object model (as opposed to an object implementation) is that it is implementation neutral. True. But the implementation must faithfully represent the semantics of the model or it isn't an implementation. No argument from me. However to take the example of UML ( please note I am not a great fan of UML as it is more of a meta-standard (try taking a xmi/model from one UML tool to another)) you can design your class diagram etc then persist/implement that model in all sorts of ways. So long as you can faithfully re-create that model then.. e.g. A mate of mine called Bob has built this: http://umlspeed.sourceforge.net/ Which I often use for quick modelling. As an example from the above, Were there an AOM/MOF mapping then in theory you could persist an archetype out as XMI. BTW sidenote: I have
Archetype documentation using XML + XSLT
Adam, Indeed however there are ways of persisting a model they require at the end of the day a recognizable document design/format. I have already noted how using text children of an element to use a value vs a std value attribute in the archetype xml inflates the file sizes. A Some value /A A value=Some value/ Are both persisting/serializing the same data. Adam Your example here is contrary to your statement, example 1, 17 characters, example 2, 23 characters. Not sure how you get a 1/3 size reduction. Heath
Understanding XML archetypes..
An archetype not based on a reference model is impossible (or at least pointless). Erik Sundvall Erik, I love this comment, it should be put up on the openEHR Web Site as the Play of the Day. So many times I see people trying to use Archetypes without a RM, or even worse using openEHR Archetypes without using the specified underlying openEHR RM. Although the later is better than the former, it still causes major confusion and badly designed Archetypes that cannot be used for implementation. Heath
Understanding XML archetypes..
- The fact that the current tools do not expose or use these attributes, is a design decision made by the people writing the tools. Well probably often a decision in lack of time/resources or (less likely) lacking ideas of good/useful ways to present them. A tool exposing the RM has to deal with both RM and AM in detail and thus takes more time building than dealing with AM only. Actually I think it was more to try to keep the task of archetyping simple as it is a task targeted at Domain Experts (Clinicians) without them requiring to know about the RM (well so we thought). Unfortantly, hiding some attributes that are commonly required by the clinician forces them to put it in the archetype so they can see it. We are also finding more and more RM attributes that we want to archetype other than just data structures such as participations. The challange is to find a visualisation of the archetype that is still simple but can also expand out to include relevant RM attributes. In Ocean's next generation of tools, mainly inspired by the requirements of the Archetype Query Builder where criteria on RM attributes is common, we will have a configurable tree view of templates where individual RM attributes can be turned on or off, right down to the data type attributes if needed. We are also looking at alternate visualisation of archetypes for the next iteration of the Ocean Archetype Editor. Regards ? Heath ? Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ? ph:?+61 (0)8 8223 3075 mb: +61 (0)412 030 741 email:?heath.frankel at oceaninformatics.com
persistence
Bert, I think there might be a few reasons why a discussion on persistence might come to a halt: * lack of time * lack of interest * lack of knowledge on the topic I certainly don't think anyone is deliberately trying to stop this discussion and I agree that discussion would be beneficial to the community. Sure there might be some commercial interest on the topic but that does not stop others having the discussion. However, the topic of a persistence API I don't see as much of a commercial issue as a persistence model. In fact the persistence model becomes more irrelevant when a common persistence API is available. Tom has already indicated that Ocean intends to publish its APIs, which takes resources, so the task gets assigned a priority alongside many other high-priority tasks. In addition, I think there is some misinterpretation about the terms being used in this discussion such as persistence API. The original email from this thread talked about a particular implementation of a persistence API using a particular DBMS. Tom, then talked about publishing an API specification and Bert, you are advocating discussion about an persistence API which I interpreted as being the specification of an API but perhaps it was more a OS Java implementation so that it can be used with the OS Java Kernel so that you can replace it with your own by changing the facade of your persistence API to comply with the OS API. Well, if you want that discussion about implementing a Java Persistence API then I will not stop you, but I will not participate as I have no interest. This is why a discussion on an API specification would be more appropriate for the wider community and leave the discussions about a specific Java implementation to a smaller group of people that are interested and base that implementation on the API specification. Having said all that, I do have a comment about the OS Java Kernel binding to a persistence API. If we a look at the openEHR Architecture Overview, there is an Architecture diagram (Figure 37) that suggests that the openEHR Kernel (within the Virtual EHR built into a clinical application) does not directly bind to a persistence API, but uses an EHR Service (I use the term 'Service' in it most generic sense, it does not need to be a Web Service). Therefore, I suggest we should be working on this EHR Service API specification and a reference implementation that might use some specific persistence implementation. If there is enough interest to define the Persistence API also then that could be done also, but that would not directly affect the OS Java Kernel. BTW, leading up to MedInfo '07 Rong implemented an EHR Service binding to the Ocean EhrBank Web Service within the OS Java Kernel. I am not sure if this was committed to the svn repository but if it has been then you will be able to see the Ocean EhrBank Service API. This API has been refined slightly since MedInfo but it will give you some idea of what it looks like. It is quite a simple course-grained API and relies heavily on AQL (formerly known as EQL) and openEHR RM (as you would expect) to provide its capability. Regards ? Heath ? Heath Frankel Product Development Manager Ocean Informatics -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Bert Verhees Sent: Saturday, 5 January 2008 1:00 AM To: For openEHR technical discussions Subject: Re: persistence Karsten Hilbert schreef: On Fri, Jan 04, 2008 at 02:31:57PM +0100, Bert Verhees wrote: Exactly that is what I am doing, and to not reinvent wheels unnecessarily, Good ! I am calling others to help do it. Makes sense. Because, I am already figuring out how to do it, others can share and use my experience, No they (currently) cannot (easily in an OSS way) because ... But I am not going to do the first step, because, there is no one who is wanting to help, and an Open Source project from one person is small, it can stay in my house. Then publishing is of no use to me. ... they do not have access to your experience (in code). Note that I am NOT saying you *have* to share the code. What I need is a strongly expressed intention to do something in a way I suggest. Serious people, not , say, pbublish your thing, and we will see. That is not good enough. If we have a few people which want to join, and they seriously have thought about in what way to join, then we discussi further how to proceed. And I am not suggesting that I have found the holy grail, or that I am looking for it, it is, like you said before, there is a job to do. Bert ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
persistence
Bert, Well why don't you start a blog on the openEHR WIKI (confluence uses the term News for a Blog article) about your experience as a starting point rather than waiting for someone else to start it. It does not need to be anything too in depth initially just to test the interest. Others might then write their own blog articles and from these we can start a Wiki page consolidating the agreed ideas. Another good blog topic might be the changes you made to the OS Java Kernel. Using the Blog is better than an email thread as it will serve as a permanent record of those ideas which get lost and fragmented in email. I think you will find that the majority of Open Source Software is written by one person or a very few people (small company) and this is reflected in the current openEHR reference implementations (Java Kernel, ADL Workbench, both Archetype Editors). The interest in these tools were probably not known until they were released as open source. As the interest grows in the open source project, additional parties come on board and contribute, but there always needs some ONE to plant the seed. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Bert Verhees Sent: Sunday, 6 January 2008 7:35 PM To: timothywayne.cook at gmail.com; For openEHR technical discussions Subject: Re: persistence Tim Cook schreef: On Sat, 2008-01-05 at 16:59 +0100, Bert Verhees wrote: Thomas Beale schreef: Probably you need to clarify the concrete basis of this discussion from your point of view. The fact is, I have a persistence layer running, can be optimized on some places (working on that), but is does it job. I don't need others to help me. Hi Bert, H, I find this a little confusing. In your many posts you are calling for people to help develop a persistence API. Yet here you are saying that you have one and do not need help. Maybe some clarification will help. Is there a place where you have made your Java implementation open source and available to others for assessment? (I do not, at this moment want to publish my code. I worked two years on my code, I keep it for myself until there will be a good reason to publish it) First, we can discuss an API, maybe my code this not fit at all in the results of this discussion. I am not important, nor is my code important, the *plan* is important, and that I explained a few times. Do we need the code from other participants before we can discuss a good way to implement the ideas behind it? I can explain how I did things, for assessment-purposes, if you like, better is, explain it for progress-purposes. That is, maybe important, that is part of the discussion. Others can have others ideas or like what I have done, or have on some parts the idea that it can be done on a better way, that is discussion. That is what I call for. But first we need people who want to discuss, A discussion on my own is a lonely thing. I want with others to build an API, with or without me (I am not important), so problems that will show up during doing this will reflect to the Java-kernel. (the way is important (Buddhist saying)). Also I hope this project then will facilitate others to build their products, so the market potential of Openehr is boosted because of more products coming to that market. If needed and wanted, I will be happy to share my experience, and work/code, but there must be some reason to do so. Maybe my code does not fit at all in what others are going to do, why should I publish it then? Open Source in my opinion means, working together, not one does the job, others look. This last statement is not personally pointing to someone special. Open Source, can be, in my opinion, develop a plan together, an architecture, and build it together, so others of that community have ways to analyze and judge the progress on criteria they made up together before. If others have other opinions on this, please say. I discussed about one/two month ago with Rong, on this very same mailinglist. He agreed an open source API would be a good idea, but the discussion stopped without coming to further plans. Every month or few months, we see emails appear from people the ask where to start, or how to do persistence. They always get an answer. From some of these people we never hear again, because, I can only guess, maybe, they give up. That is not good, we need implementers, we must facilitate them, make it easy to step in, making openehr become something that will be important worldwide. Now I stop writing about this, for the moment, I believe I explained every aspect a few times in a few days. Thanks for your attention Bert ___ openEHR-technical mailing list openEHR-technical at openehr.org
Suggestion wrt XML Archetypes Templates
Adam Lisa, There is a very specific rationale and it is consistent. The XML Schema is a direct serialisation of the UML openEHR reference models. Every class is an XML schema type and every attribute is an element except for archetype_node_id as it is a metadata attribute. So in the case of CODE_PHRASE, it has an attribute of terminology_id (hence the element template_id) of type TERMINOLOGY_ID. TERMINOLOGY_ID has an attribute of value of type string (hence the element value). Paths are absolutely critical in openEHR and they are based on XPath. If we start arbitrarily changing the schema based on what someone thinks is good XML we will break the openEHR path to XPath correspondence making any mapping rules more complex and error prone. This is why the terminology ID value is not represented as a value attribute or element text node. Yes it might seem inefficient but it was deemed to be important to make sure the logical model to implementation mapping was consistent and ensure paths worked. In comparison to HL7 v3, the data:noise ratio is still considerably less. Regards Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Lisa Thurston Sent: Tuesday, 11 December 2007 10:23 AM To: For openEHR technical discussions Subject: Re: Suggestion wrt XML Archetypes Templates Adam Flinton wrote: I would like though to enquire wrt the rationale of containing _id info in a separate value/ element. If you are being consistent instead of : terminology_id valueISO_639-1/value /terminology_id it should be simply: terminology_idISO_639-1/terminology_id or terminology_id value=ISO_639-1/ Adam There is no special rationale. It is simply the default serialisation of the type TERMINOLOGY_ID. Lisa ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Suggestion wrt XML Archetypes Templates
No XML Schema changes required, in fact the schema already indicates that the string data should have space preserved as per the W3C references provided by Adam. The problem is that because the schema specifies something is a string type it is not required to be specified in the XML document and when a tool such as XMLSpy reads the document it doesn't know what type the element is without referencing the schema, so it doesn't apply the default space='preserve' attribute when it does a pretty-print. So technically there is nothing wrong with the current XML. However, to support these tools that apply pretty print before checking the schema to determine if they are allowed too, we could explicitly add this space attribute in the data (alternately, we might be able to provide the type attribute instead, but we haven't tested this yet). The problem is forcing the XML serialiser to put these explicit attributes in the data. We will explore this. Stepping back a bit, would it be sufficient (in the short term at least) to just have the XML pretty printed out of the tools rather than a single line so that you are not inclined to use the problematic XMLSpy pretty print? Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Thomas Beale Sent: Monday, 10 December 2007 7:34 AM To: adam.flinton at nhs.net; For openEHR technical discussions Subject: Re: Suggestion wrt XML Archetypes Templates Adam Flinton wrote: I reserve my views wrt attributes vs text() however that would do on the proviso of a bit of testing with many tools as it used to be patchily supported by different tools. I accept that was a few years back things may well have improved. So then next question then is when will the tools support this? looks like we have arrived at a useful point - first thing we need is an analysis of changes to the XML-schemas. If Lisa's change is all that is needed and someone wants to update the current schemas to make thi work, we can put it on the main TRUNK so that everyone can have access to it. Further analysis will be needed for the tools, but I would not expect big problems. Generally they are using orthodox XML parsers whcih I assume respect the whitespace settings in an XML schema... - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Compact XML format...?
Hi Thilo, One theoretical question (probably you Ocean guys have already looked into it), would it be possible to generate a second schemtron schema to express the asseration type constraints that can't be expressed with XML schema. If possible, by validating against both schemas there wouldn't be a need to use an openEHR kernel component in this integration by TDS scenario. But maybe this is (1) to complicated or (2) superflous as the data is checked anyways with a kernel before being committed. The only advantage would perhaps be that a more or less complete validation could take place in an XML based environment at the client side. [Heath Frankel] No reason why you couldn't use schematron as far as I can see. We choose to use the kernel. Heath
Compact XML format...?
Were HL7 messages exist and are working, we will continue to consume them using the TDS intermediate form. As stated previously, the TDS is not intended for information exchange, but as a tool for integration. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Tim Cook Sent: Tuesday, 27 November 2007 11:11 AM To: For openEHR technical discussions Subject: Re: Compact XML format...? Hello Hugh, Thanks for the reply. I think we have a communications issue though. My questions/comments weren't about the technical aspects. As I understood the proposition. It was to encourage other system vendors to create these templates in order to communicate with an openEHR based application. My argument is that the world of healthcare data exchange has been built (so far) on HL7 v2.x If my understanding of your proposal is correct then I will argue that we will have very little success in getting these vendors to incorporate a message format for openEHR. I believe it is better to just continue doing what you are now by consuming HL7 messages. Again, I think we are saying the same things but I'm not positive. :-) Cheers, Tim On Tue, 2007-11-27 at 09:12 +1100, Hugh Leslie wrote: Hi Tim Yes, I absolutely agree with this - our tools are capable of receiving V2 messages and producing openEHR data - we did this at MedInfo for the interoperability demo. The problem with V2 is that the ability to put clinical content in there is limited (which is why all the work on v3!) and so we are also working on these other methods. As I said previously we are currently capable of creating and sending CDA R2 messages from openEHR and so as soon as there are applications out there capable of receiving them, we are capable of sending. regards Hugh Tim Cook wrote: Hugh, Tom, Heath, et.al. I agree that openEHR systems MUST interact with everyone else. I also agree that MOST healthcare information providers only have a small segment of healthcare information to consider. I agree that if we (as an openEHR community) do not work with the broader, more established world we will be isolated (no matter that our approach is superior :- ). However, (I always have a BUT or a HOWEVER to present) I do think that it is more prudent to do these translations INSIDE an openEHR implementation instead of trying to coax outside entities into doing them to communicate with openEHR implementations? A different approach says that; openEHR can translate ANYTHING thrown at it via these really cool translations (TDS?). Instead of trying to get various vendors to support our (strange) formats that they do not understand. We certainly know that not many vendors are providing HL7 v3 messages at this point. Shouldn't we concentrate on providing HL7 v2 lab, rad, etc. input to EHR's/PHR's instead of trying to convince the uninformed world that they should be giving us openEHR EHR_Extracts or even transformed XML data? Thanks, Tim On Mon, 2007-11-26 at 20:25 +1100, Hugh Leslie wrote: I also think the problem is that we have to accept the pragmatics of the current situation in health care where companies are not immediately going to re-engineer their systems to become openEHR compliant, no matter how much we would like that. In time, many companies will re-engineer their software, and other new applications will arrive on the scene that are fully openEHR compliant. In the meantime, this pragmatic approach allows for archetypes and templates to completely model clinical medicine and to enable everyone to participate at, initially, minimum cost and effort. The exciting thing about the openEHR approach, is that these Template Data Schemas are not hand coded, but are generated directly from templates and archetypes using tools. In Australia, we are using this approach to enable the completely tool driven generation of CDA R2 documents (because in a pragmatic world, we have to interact with everyone!) with data going both in and out of CDA. Of course we are doing this with openEHR as well. Hugh Leslie Thomas Beale wrote: Rong Chen wrote: Hi Heath, Tom and others, I clearly see there is a need for TDS based integration. But I am also concerned with the side-effects of it. By offering this 'easy' way of integrating openEHR systems, we make it possible for vendors to ignore the 'hard' way of integrating openEHR systems using archetypes and the generic RM. As you have indicated TDS doesn't contain all the semantics of the archetypes and RM, some semantics will be forever lost when data are received using TDS. Without the knowledge of archetypes and RM,
Compact XML format...?
Rong, XML documents populated against a Template Data Schema are turned into pure openEHR, so you do not lose any semantics. There is enough meta data in the TDS to maintain the semantics. What you may lose are some of the ADL assertions which cannot be expressed in XSD, but these will be picked up by an openEHR kernel before being committed. The schema provides enough constraints to get a non-openEHR developer started. All this will become clear when we publish a draft of the TDS generation and transformation rules on the wiki. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Rong Chen Sent: Monday, 26 November 2007 1:38 AM To: For openEHR technical discussions Subject: Re: Compact XML format...? On Nov 25, 2007 10:09 PM, Heath Frankel heath.frankel at oceaninformatics.com wrote: Hi Erik, I will forward a schema based on a Microbiology Result generated using the Ocean Template Designer separately. See comments below, you have stated exactly the problem that the TDS was designed to solve. We are using this approach to integrate existing vendor software to the Ocean EhrBank where the vendor has no openEHR expertise or desire to do so (yet), they just want to have an openEHR repository. Hi Heath, Tom and others, I clearly see there is a need for TDS based integration. But I am also concerned with the side-effects of it. By offering this 'easy' way of integrating openEHR systems, we make it possible for vendors to ignore the 'hard' way of integrating openEHR systems using archetypes and the generic RM. As you have indicated TDS doesn't contain all the semantics of the archetypes and RM, some semantics will be forever lost when data are received using TDS. Without the knowledge of archetypes and RM, some intelligent use of the data won't be possible, e.g. AQL queries of the data. Also one-template-one-schema seems to imply software changes whenever new templates are introduced. Such changes will not be necessary if the openEHR RM can be mapped directly into a generic internal model, which is constrained in runtime using semantics in the archetypes/templates. So even it seems to be harder than TDS based integration, it does offer full benefits of using archetypes and makes the system more adaptive. Regards, Rong Heath The reason for asking is that in a context where openEHR/13606 has been compared to HL7 (mainly v3 I believe) some parties claimed it would be easier for vendors to support HL7 than openEHR. In practice, what they mean is probably that they are used to follow (map their internal/legacy structures to) specific HL7 xml schemas that come out after the long HL7 modeling process. I doubt that the vendors in this case internally are using any HL7 v3 models. This is sometimes forgotten when comparing HL7 and openEHR. So far we have had a look at some fairly equivalent examples of XML instances (e.g. blood pressure) from HL7 CDA (v2) and openEHR RM. Both were fairly easy to understand when knowing the underlying models (HL7 RIM +CDA and openEHR RM+AM) and both were a bit verbose if you were just interested in the blood pressure. To be honest if I was a vendor not interested in underlying models I'd probably prefer whichever I was already used to and had people trained to work with - since none of them tries to make life easier to me by being tailored to the specific use case. [Heath Frankel] As you know, a template is the knowledge artefact designed for a particular use case, the TDS is a technical artefact to support the implementation of that use case. To validate clinically both were dependent on other artifacts (HL7 Templates or openEHR archetypes). An information provider not interested in the underlying validation mechanisms could easily produce data instances that are clinically invalid even though they are valid from the perspective of the respective XML schemas. Does the TDS-approach produce an XML schema that enforces more or all of the specific archetype+template semantics? If not, could it be enhanced to do that? If so I believe that some safety would be gained - if data providers do not care to learn the full semantics of openEHR then at least their schema-based XML-validators would enforce some of the semantics. [Heath Frankel] Most but not all the semantics of the archetypes and templates are represented in the TDS. The reason it is not all, is due to the limitations of XML schema to do assertions between XML elements. If we could standardize the TDSs and have accompanying standard determinstic transformation mechanism then openEHR would have a competitive advantage in the just give me a simple XML schema and instance examlpe use-case. A use case more important than one might think at first... [Heath Frankel] The TDS is simply a set of XML elements with names from the archetypes. If you look at the schema in an graphical XML tool
Compact XML format...?
Tim, I don't know anything about MIRTH but I will assume it does something like take a HL7 v2 message and turn it into some XML document based on a provided schema, I would call this a transformation, just not XSLT. Assuming that the XML Schema used in MIRTH is a Template Data Schema, then you are only one further transformation away from openEHR. Any integration engine can be used to implement this approach using whatever mapping tools it provides. Again I don't know about how MIRTH works but the catch in this is the Template Data Schemas might be too specific to allow MIRTH to be used against the TDS in one step. What I mean by this is that a TDS is specific to a use case such as a Microbiology Report, not a generic Observation Result equivalent to the HL7 OUR message. When receiving a ORU message you need to determine that it has a Microbiology observation within and apply the transform to the Microbiology Report TDS, if it contains a Lipids result then you need to apply the transform to a TDS containing laboratory-lipids OBSERVATION archetype in it. You could certainly come up with a template containing a generic laboratory OBSERVATION archetype in it and map everything in an ORU to that but you lose some of the semantics of the specialised archetypes. Using our current integration engine of choice, we have a mechanism where we can apply logic to determine what kind of lab report has been received based on data within the message and apply the appropriate TDS transformation and anything else we don't yet support we transform to a generic laboratory report TDS. This gives the ability to take all results from a lab into openEHR but can progressively utilise specialised archetypes for common results as we develop those transformation mappings. The benefit of this Archetype-based Integration approach is that we can start building a library of HL7 V2 to TDS transformations that can be used as a starting point for integrating with a specific HL7 interface, customising to suit the local HL7 and terminology implementation. This library could be an open resource. This is something that I have not seen possible in system integration before. BTW, this approach is not limited to integration with openEHR, but it is the Archetype that makes it work. The Archetype is the implementation independent logical concept model that is used derive the implementation to semantic mapping in and out of the Archetype-based normalised intermediate format. Regards Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Tim Cook Sent: Sunday, 25 November 2007 7:35 AM To: For openEHR technical discussions Subject: Re: Compact XML format...? On Sat, 2007-11-24 at 08:47 +, Heath Frankel wrote: Think of it as standard mechanism for data transformation rather than a standard data exchange, where the semantics of the archetypes are maintained at each stage in the pipeline. Would it be fair to say then that when working with HL7 v2 messaging. I would want to use this data transformation process against the XML output of MIRTH ( http://www.mirthproject.org/ )so that I can use all the management facilities of MIRTH and only have to have (essentially) one transform?? Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Development Services http://timothywayne.cook.googlepages.com/home LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Compact XML format...?
Hi Erik, I will forward a schema based on a Microbiology Result generated using the Ocean Template Designer separately. See comments below, you have stated exactly the problem that the TDS was designed to solve. We are using this approach to integrate existing vendor software to the Ocean EhrBank where the vendor has no openEHR expertise or desire to do so (yet), they just want to have an openEHR repository. Heath The reason for asking is that in a context where openEHR/13606 has been compared to HL7 (mainly v3 I believe) some parties claimed it would be easier for vendors to support HL7 than openEHR. In practice, what they mean is probably that they are used to follow (map their internal/legacy structures to) specific HL7 xml schemas that come out after the long HL7 modeling process. I doubt that the vendors in this case internally are using any HL7 v3 models. This is sometimes forgotten when comparing HL7 and openEHR. So far we have had a look at some fairly equivalent examples of XML instances (e.g. blood pressure) from HL7 CDA (v2) and openEHR RM. Both were fairly easy to understand when knowing the underlying models (HL7 RIM +CDA and openEHR RM+AM) and both were a bit verbose if you were just interested in the blood pressure. To be honest if I was a vendor not interested in underlying models I'd probably prefer whichever I was already used to and had people trained to work with - since none of them tries to make life easier to me by being tailored to the specific use case. [Heath Frankel] As you know, a template is the knowledge artefact designed for a particular use case, the TDS is a technical artefact to support the implementation of that use case. To validate clinically both were dependent on other artifacts (HL7 Templates or openEHR archetypes). An information provider not interested in the underlying validation mechanisms could easily produce data instances that are clinically invalid even though they are valid from the perspective of the respective XML schemas. Does the TDS-approach produce an XML schema that enforces more or all of the specific archetype+template semantics? If not, could it be enhanced to do that? If so I believe that some safety would be gained - if data providers do not care to learn the full semantics of openEHR then at least their schema-based XML-validators would enforce some of the semantics. [Heath Frankel] Most but not all the semantics of the archetypes and templates are represented in the TDS. The reason it is not all, is due to the limitations of XML schema to do assertions between XML elements. If we could standardize the TDSs and have accompanying standard determinstic transformation mechanism then openEHR would have a competitive advantage in the just give me a simple XML schema and instance examlpe use-case. A use case more important than one might think at first... [Heath Frankel] The TDS is simply a set of XML elements with names from the archetypes. If you look at the schema in an graphical XML tool such as Oxygen you will see a tree that has the same structure as the template tree displayed in the Ocean Template Designer. Sometimes the use case is to decide on an XML format (for data exchange) based on one of the following 1. HL7 CDA 2. 13606/openEHR 3. A custom tailored XML schema Imagine that we using something like TDS could give an easy-to-produce alternative to 3 that with some deterministic transformations at the receiver also conforms to 2. (An open or free tool to produce the schema would be of tremendous help of course.) [Heath Frankel] This is exactly the plan for the TDS.
Antw: Re: Compact XML format...?
There is only one openEHR implementation, the template data schemas are just a tool to transform data from other formats into and out of the openEHR reference model using the semantics of the clinical archetypes models. The TDS are not intended to replace openEHR, but enable it for those that are not openEHR compliant. The result of using a TDS is openEHR for standard information sharing. The reality is, most systems are not built on a particular standard reference model such as HL7 or openEHR, they are proprietary models which move their data into these standard models for interoperable exchange. The TDS provides a means for these systems to move their data into clinical data models and mechanically transform them into technical data models, such as openEHR. Think of it as standard mechanism for data transformation rather than a standard data exchange, where the semantics of the archetypes are maintained at each stage in the pipeline. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Williamtfgoossen at cs.com Sent: Saturday, 24 November 2007 6:46 AM To: openehr-technical at openehr.org Subject: Antw: Re: Compact XML format...? In een bericht met de datum 23-11-2007 16:55:12 West-Europa (standaardtijd), schrijft timothywayne.cook at gmail.com: IHMO, any system that is not interested in the full semantics of the openEHR model is not compliant with openEHR and is just a stand alone system. Much like the various HL7 implementations that require interface engines to make the transition. This seems only relevant to compare with the HL7 v2. V3 has no various implementations, but one standard implementation of messages. The v3 content can vary, similar to archetype variations. Sincerely yours, dr. William TF Goossen director Results 4 Care b.v. De Stinse 15 3823 VM Amersfoort email: Results4Care at cs.com phone + 31654614458 fax +3133 2570169 Dutch Chamber of Commerce number: 32121206 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071124/83bd2f97/attachment.html
Compact XML format...?
Just to clarify one thing about these Template Data Schemas, they are NOT intended for exchange across system boundaries. They are used as an intermediary format, which is normalised based on archetypes and templates, for the purposes of integration between system components (note that I use the term system in the sense of a system of systems within an enterprise). For example, to import HL7 V2 messages into openEHR it is easier to move the data into an intermediate form and then into openEHR. Similarly, to export data from a proprietary database to openEHR, you can go via a intermediate form. The key here is that the intermediate form are based on normalised content models and can be the same for different data sources. It allows developers to work with the content models without being openEHR experts, resulting in reduced barriers to the take up of openEHR. The real clincher, is that there is a single transformation from any of these template-based XML schemas into openEHR. We are refining the rules for generating these schemas and the openEHR transformation and will share it with the openEHR community soon. Regards ? Heath ? Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ? ph:?+61 (0)8 8223 3075 mb: +61 (0)412 030 741 email:?heath.frankel at oceaninformatics.com -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Thomas Beale Sent: Friday, 23 November 2007 6:17 PM To: For openEHR technical discussions Subject: Re: Compact XML format...? I believe you are referring to what we call Template Data Schemas (TDSs). These are an alternate schema-per-message approach, where one template generates one schema - in such schemas, you find tagnames coming from the archetypes, e.g. systolic rather than the generic openEHR tag names. This is similar to HL7, except that here the message schemas are generated from content models (archetypes templates) rather than hand-built as in HL7. What this does is provide a message capability to openEHR based on the content models, just like any other generated artifact, e.g. Xforms or HML or code skeletons. We have only just developed this capability (it is still under test), and we expect it to be attractive to certain types of provider, e.g. pathology software vendors and labs, since it means they can use 'simple XML' to transfer their result messages, rather than having to understand all that weird openEHR stuff. This approach means any message (e.g. anything currently expressed in HL7 or Edifact) can now be generated from archetypes and templates (obviously the literal XML is different, we don't use RIM-based XML, but the logical purpose is exactly the same). I will find out about example messages. I would expect that we will provide the relevant specifications for this process to openEHR.org at some point, when it has stabilised. - thomas beale Erik Sundvall wrote: Hi! During Medinfo2007 I believe Ocean Informatics presented a compact XML format for interchange of predefined information snippets that was used for integration purposes. I do not believe it was based on the official RM-schemas that cover everything but instead a compact form for a specific purpose (e.g. using a specific template or set of archetypes). Does anybody understand what I am referring to or was I just dreaming? Could somebody please send a snippet with an example of that format and possibly some description or documentation. I believe a brief discussion regarding this on the list could be valuable since there are use cases where having a standardized such a format would be of value. Best regards, Erik Sundvall erisu at imt.liu.sehttp://www.imt.liu.se/~erisu/Tel: +46-13-227579 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- please change your address book entry for me to Thomas.Beale at OceanInformatics.com *Thomas Beale* /Chief Technology Officer/ Ocean Informatics http://www.oceaninformatics.com/ Chair Architectural Review Board, /open/EHR Foundation http://www.openehr.org/ Honorary Research Fellow, University College London http://www.chime.ucl.ac.uk/ * * ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML versions of the ADL
Greg, I suspect that there are so many objects that are possible that it is too difficult to identify them within the archetype. This should probably be an external terminology rather than an internal terminology, but that is up to the archetype developers (the clinicians) to say not me (a techie). Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Wednesday, 7 November 2007 10:18 PM To: For openEHR technical discussions Subject: Re: XML versions of the ADL Looks good to me, The only issues I am hitting so far are due to the original ADL e.g. openEHR-EHR-OBSERVATION.dimensions.v1.adl defines at0013 (Object: The object, axis or body part that is being measured) as a DV_CODED_TEXT but without associated codes. I don't know if it is helpful if I highlight those type of anomolies (or perhaps not anonomolies, just my misunderstanding of the definition). thanks! Greg http://www.patientos.org On 11/7/07, Heath Frankel heath.frankel at oceaninformatics.com wrote: Greg and others, We have configured an auto-build process to convert the ADL archetypes to XML located at http://svn.openehr.org/knowledge/archetypes/dev. They now all exist and are valid against the RM 101 XML Schema. Let me know if you find any issues with the XML content. Regards Heath -Original Message- From: Heath Frankel [mailto:heath.frankel at oceaninformatics.com] Sent: Wednesday, 7 November 2007 11:06 AM To: 'For openEHR technical discussions' Subject: RE: XML versions of the ADL Greg, I agree with Tim, that you can't always expect Ocean to provide these tools. We just happen to be one of the main contributors to the openEHR foundation. As Tim said, the openEHR specs are the normative artefacts including the XML schemas provided at http://svn.openehr.org/specification/TAGS/Release- 1.0.1/ITS/XML-schema. As for the archetypes, the ADL is probably the best source of truth but even then there are some archetypes that have some errors left over from previous versions of ADL and Editor tools. The XML archetypes have been generated using the Ocean Archetype Editor which is available free from http://downloads.oceaninformatics.com/products/ArchetypeEditor. The XML archetypes provided in http://svn.openehr.org/knowledge/archetypes/dev/xml are currently manually generated using an old version of the editor and committed to subversion. This is why a complete set is not available. These XML archetypes are NOT valid against the openEHR R1.0.1 archetype and openehrprofile XML schemas, they do not even use the correct namespace. They have not been updated since R1.0.1 was release. Ocean has provided a auto-generation process for the NHS archetypes which generate valid R1.0.1 XML and we will endeavour to provide this for the dev archetypes as well. BTW, I have noticed an error in the term bindings XML and will have this rectified ASAP. You could use the Ocean Archetype Editor to produce the required XML yourself. A similar error as mentioned above exists for term bindings but more critical as it does not produce valid XML when an archetype includes term bindings. Again I will have this rectified ASAP. I will provide some background on the automated XML conversion process. The ADL archetype is read using openEHR Eiffel ADL Parser reference implementation which generates Archetype Object Model representation of the archetype. Using the openEHR Archetype Model XML Schema based on the AOM we simply serialise this AOM representation to XML. One of the issues you have highlighted is in regard to namespace prefixes. The Ocean serialiser uses the openEHR AM schema namespace as the default namespace and hence does not require prefixes. The LiU Editor obviously uses an at namespace prefix. Both are completely valid XML. The second issue is the xsi:type of children. Look at the openehrprofile.xsd and you will see that C_DV_QUANTITY is the correct type. This is consistent with the openEHR profile specification. Thirdly, both DvQuantity and QUANTITY are wrong in this case. It should be DV_QUANTITY as per the openEHR RM. The Ocean Archetype Editor now produces this correctly and the XML converter used to generate the NHS XML archetype is working correctly in this case, see http://svn.openehr.org/knowledge/archetypes/dev-uk- nhs/gen/xml/openehr/ehr/entry/observation/openEHR-EHR- OBSERVATION.blood_pressure.v1.xml. Hope this helps. Regards Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Tuesday, 6 November 2007 8:05 AM
OpenEHR queries
Randy, We have already indicated that we store indexed blobs. We can store these blobs as XML, DADL or Binary. It doesn't matter, it is just a serialisation format and the MAGIC happens in the object layer. Another benefit of this is that it obfuscates the EHR content forcing the data access through the EHR Server to ensure that the semantics and security of the content is maintained. This is a deterrent to traditional application developers bypassing these important EHR requirements. Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 mb: +61 (0)412 030 741 email: heath.frankel at oceaninformatics.com mailto:heath.frankel at oceaninformatics.biz From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Randolph Neall Sent: Thursday, 8 November 2007 1:26 AM To: erisu at imt.liu.se; For openEHR technical discussions Subject: Re: OpenEHR queries Erik, as I ask my questions about the Ocean system, I'm getting the growing sense, perhaps mistaken, that I'm pushing against trade secrets. Have they told me as much as they're going to? If they're storing the real guts of their clinical information as blobs (low-level blobs, as Tom implies, which could be mere binary serializations of their objects) then it would seem querying would be an interesting issue. I assume Ocean is the premier implementation of openEHR, what with its ultimate champion in Tom Beale, and if they've had to go this route, this would be significant. Tom works there, and I'm assuming that what he says reflects how they do it. If they had all their data in MS Sql tables and columns, not blobs, and it worked well that way, I doubt Tom would be inveighing against relational databases for clinical data. Maybe they've got some serious magic in play. Randolph On 11/7/07, Erik Sundvall erisu at imt.liu.se wrote: On 11/7/07, Randolph Neall randy.neall at veriquant.com wrote: Can I assume that what Thomas here advocates, (relational databases can be used very effectively as a low-level store of blobs keyed by path) is what how the ocean persistence layer actually works? Beyond this, Thomas apparently has little use for the capacities of Sql-type RDBMS systems to handle clinical information. Does the Ocean system ultimately amount to blobs keyed by paths (presumably string paths)? If so, what kind of blobs, XML blobs, or some other structured text system? A guess from someone outside Ocean: If Tom has been involved I'd guess it's stored as blobs of DADL or something similar ;-) not XML... In a master thesis project here some time ago the students used db4o (http://www.db4o.com/) to store openEHR RM objects, but in a rudimetary way mostly as a simple datastore for Java objects. Query was not the focus of that project so they did not test proper advanced querying or scalability using db4o. // Erik ___ 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/20071108/e3940e94/attachment.html
OpenEHR queries
Randy, I have no control over this t_persistence_notes.htm link but I have sent an email to the webmaster about it. There are quite a number of complex archetypes, even OBSERVATION.blood_pressure.v1 is more complex than you would expect as archetypes are a maximal data set. The complexity comes when you aggregate archetypes together to construct a complete composition. Some of the NHS composition templates have dozens of archetypes aggregated together. The real killer for a persistence layer is the number of archetypes that could be used, their specialisations and the potential revisions over time. I would suggest that a good openEHR persistence model should be able to store data for any archetype and any of its specialisations and revisions without manual modifications to the software. The Ocean EhrBank EHR Server is able to do this and in fact does this without knowing about the archetype, just the openEHR RM. Another openEHR implementation may do this by requiring archetypes to be registered allowing it to support a new data structure. Hope this helps. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Randolph Neall Sent: Wednesday, 7 November 2007 6:27 AM To: For openEHR technical discussions Subject: Re: OpenEHR queries Heath, thanks much! I'd very much like to see the t_persistence_notes.htm, but that one cannot be reached at the moment. I hope to find it soon. I asked Chunlan for an example of your baddest archetype, one that involves some hierarchy and that would challenge a persistence layer. If one comes to mind, let me know. Thanks again, Randolph On 11/6/07, Heath Frankel heath.frankel at oceaninformatics.com wrote: Randolph, As openEHR has no specification for a persistence model, there is no such thing as a conformant DB schema. At Ocean we have developed a DB schema that is still evolving but this is transparent to any application as the API is based on the openEHR Information Model. We may explore alternate DB schema's and even alternate data store technology, but again this will be transparent to the application. The main article available on this topic was located at http://www.openehr.org/FAQs/t_persistence_notes.htm but has not yet been moved to the new web site. This is really just some suggestions about how a persistence layer could be implemented, it is by no means a specification for conformance. Regards Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Randolph Neall Sent: Tuesday, 6 November 2007 2:03 PM To: For openEHR technical discussions Subject: Re: OpenEHR queries Thanks. Of course, as you say, the Sql parser will vary depending on the structure of the underlying store, and underlying store designs can vary, one of the strengths of openEHR. It would still seem, however, that whole chunks of the AQL would have to end up in the Sql, and that, in turn, would have implications--at least some implications--how the underlying store would have to be designed. Only certain schemas would even work with openEHR. Does the openEHR community offer any suggestions? At Ocean you evidently felt that a certain design was best, not just any design, which you imply when you refer to the need to be conformant. What does it take for a DB schema to be conformant? The persistence model that Ocean uses is a trade off between completely atomising objects and storing them as blobs. Have you disclosed any of the details regarding this tradeoff? Randolph On 11/5/07, Hugh Leslie hugh.leslie at oceaninformatics.com wrote: Hi Randolph, Currently, the only AQL query parser that I know of is one that is part of the Ocean Informatics suite of products and runs against the Ocean EhrBank openEHR repository. Converting AQL to SQL will depend entirely on what your underlying persistence model is and also to some extent what relational database flavour you are using. openEHR doesn't mandate any particular persistence model and as has been already stated, the really nice thing about AQL is that queries are independent of any underlying relational (or object) data model. So an AQL query that is run against two separate and completely independently developed openEHR repositories that probably use a completely separate persistence model should return exactly the same data (as long as they are both conformant). The persistence model that Ocean uses is a trade off between completely atomising objects and storing them as blobs. This has been a process of optimisation and we are really happy with the current performance of the system. This is only one of many possible methods of openEHR persistence. regards Hugh Randolph Neall wrote: I think I understand. Thanks. What actually gets persisted, I suspect, are the paths--and values pointed to by those paths--implicit in your
XML versions of the ADL
Greg, I agree with Tim, that you can't always expect Ocean to provide these tools. We just happen to be one of the main contributors to the openEHR foundation. As Tim said, the openEHR specs are the normative artefacts including the XML schemas provided at http://svn.openehr.org/specification/TAGS/Release-1.0.1/ITS/XML-schema. As for the archetypes, the ADL is probably the best source of truth but even then there are some archetypes that have some errors left over from previous versions of ADL and Editor tools. The XML archetypes have been generated using the Ocean Archetype Editor which is available free from http://downloads.oceaninformatics.com/products/ArchetypeEditor. The XML archetypes provided in http://svn.openehr.org/knowledge/archetypes/dev/xml are currently manually generated using an old version of the editor and committed to subversion. This is why a complete set is not available. These XML archetypes are NOT valid against the openEHR R1.0.1 archetype and openehrprofile XML schemas, they do not even use the correct namespace. They have not been updated since R1.0.1 was release. Ocean has provided a auto-generation process for the NHS archetypes which generate valid R1.0.1 XML and we will endeavour to provide this for the dev archetypes as well. BTW, I have noticed an error in the term bindings XML and will have this rectified ASAP. You could use the Ocean Archetype Editor to produce the required XML yourself. A similar error as mentioned above exists for term bindings but more critical as it does not produce valid XML when an archetype includes term bindings. Again I will have this rectified ASAP. I will provide some background on the automated XML conversion process. The ADL archetype is read using openEHR Eiffel ADL Parser reference implementation which generates Archetype Object Model representation of the archetype. Using the openEHR Archetype Model XML Schema based on the AOM we simply serialise this AOM representation to XML. One of the issues you have highlighted is in regard to namespace prefixes. The Ocean serialiser uses the openEHR AM schema namespace as the default namespace and hence does not require prefixes. The LiU Editor obviously uses an at namespace prefix. Both are completely valid XML. The second issue is the xsi:type of children. Look at the openehrprofile.xsd and you will see that C_DV_QUANTITY is the correct type. This is consistent with the openEHR profile specification. Thirdly, both DvQuantity and QUANTITY are wrong in this case. It should be DV_QUANTITY as per the openEHR RM. The Ocean Archetype Editor now produces this correctly and the XML converter used to generate the NHS XML archetype is working correctly in this case, see http://svn.openehr.org/knowledge/archetypes/dev-uk-nhs/gen/xml/openehr/ehr/e ntry/observation/openEHR-EHR-OBSERVATION.blood_pressure.v1.xml. Hope this helps. Regards Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Tuesday, 6 November 2007 8:05 AM To: For openEHR technical discussions Subject: XML versions of the ADL In writing some code to parse the XML to populate my database I notice there is not always a matching XML on subversion for a given ADL. For example there is http://svn.openehr.org/knowledge/archetypes/dev/adl/openehr/ehr/entry/observ at ion/openEHR-EHR-OBSERVATION.blood_pressure.v1.adl http://svn.openehr.org/knowledge/archetypes/dev/xml/openehr/ehr/entry/observ at ion/openEHR-EHR-OBSERVATION.blood_pressure.v1.xml but not an XML for http://svn.openehr.org/knowledge/archetypes/dev/adl/openehr/ehr/entry/observ at ion/openEHR-EHR-OBSERVATION.respiration.v1.adl To get around this I started to use the LiU Archetype Editor but I realize now it generates a different XML than on subversion. For example the LiU editor generates nodes with type children xsi:type=at:C_QUANTITY rm_type_nameDvQuantity/rm_type_name but on subversion it has children xsi:type=C_DV_QUANTITY rm_type_nameQUANTITY/rm_type_name Is the XML unreliable such that I must use a Java ADL parser? thanks! Greg ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Exchanging codified content via HL7
Greg, Very interesting question, there is actually working being done within Standards Australia to determine how to represent archetyped content in HL7 V2. This work is not yet complete, but your suggestion is one of the options except the [at] is not required as all archetype root nodes have this node ID. The code system (3rd component of CE) is the Archetype ID. Regards Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Wednesday, 7 November 2007 3:51 PM To: For openEHR technical discussions Subject: Exchanging codified content via HL7 So I have completed a first pass at parsing the OpenEHR content, extracting some initial information I would import into to my application. More work to be done but if you look at this text file as a preliminary output from the process: http://www.patientos.org/forum_temp/openehr.txt My question is if I send the information out via HL7 in say OBX segments, what 'code' would I assign to the data elements. For example if my message is sending the 'Anaesthetic evaluation and history date/time of last liquid intake' - is the unique, interoperable identifier for that data element: [at]/data[at0001]/items[at0005]/items[at0006] thanks Greg http://www.patientos.org ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML versions of the ADL
Greg and others, We have configured an auto-build process to convert the ADL archetypes to XML located at http://svn.openehr.org/knowledge/archetypes/dev. They now all exist and are valid against the RM 101 XML Schema. Let me know if you find any issues with the XML content. Regards Heath -Original Message- From: Heath Frankel [mailto:heath.frankel at oceaninformatics.com] Sent: Wednesday, 7 November 2007 11:06 AM To: 'For openEHR technical discussions' Subject: RE: XML versions of the ADL Greg, I agree with Tim, that you can't always expect Ocean to provide these tools. We just happen to be one of the main contributors to the openEHR foundation. As Tim said, the openEHR specs are the normative artefacts including the XML schemas provided at http://svn.openehr.org/specification/TAGS/Release- 1.0.1/ITS/XML-schema. As for the archetypes, the ADL is probably the best source of truth but even then there are some archetypes that have some errors left over from previous versions of ADL and Editor tools. The XML archetypes have been generated using the Ocean Archetype Editor which is available free from http://downloads.oceaninformatics.com/products/ArchetypeEditor. The XML archetypes provided in http://svn.openehr.org/knowledge/archetypes/dev/xml are currently manually generated using an old version of the editor and committed to subversion. This is why a complete set is not available. These XML archetypes are NOT valid against the openEHR R1.0.1 archetype and openehrprofile XML schemas, they do not even use the correct namespace. They have not been updated since R1.0.1 was release. Ocean has provided a auto-generation process for the NHS archetypes which generate valid R1.0.1 XML and we will endeavour to provide this for the dev archetypes as well. BTW, I have noticed an error in the term bindings XML and will have this rectified ASAP. You could use the Ocean Archetype Editor to produce the required XML yourself. A similar error as mentioned above exists for term bindings but more critical as it does not produce valid XML when an archetype includes term bindings. Again I will have this rectified ASAP. I will provide some background on the automated XML conversion process. The ADL archetype is read using openEHR Eiffel ADL Parser reference implementation which generates Archetype Object Model representation of the archetype. Using the openEHR Archetype Model XML Schema based on the AOM we simply serialise this AOM representation to XML. One of the issues you have highlighted is in regard to namespace prefixes. The Ocean serialiser uses the openEHR AM schema namespace as the default namespace and hence does not require prefixes. The LiU Editor obviously uses an at namespace prefix. Both are completely valid XML. The second issue is the xsi:type of children. Look at the openehrprofile.xsd and you will see that C_DV_QUANTITY is the correct type. This is consistent with the openEHR profile specification. Thirdly, both DvQuantity and QUANTITY are wrong in this case. It should be DV_QUANTITY as per the openEHR RM. The Ocean Archetype Editor now produces this correctly and the XML converter used to generate the NHS XML archetype is working correctly in this case, see http://svn.openehr.org/knowledge/archetypes/dev-uk- nhs/gen/xml/openehr/ehr/entry/observation/openEHR-EHR- OBSERVATION.blood_pressure.v1.xml. Hope this helps. Regards Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Tuesday, 6 November 2007 8:05 AM To: For openEHR technical discussions Subject: XML versions of the ADL In writing some code to parse the XML to populate my database I notice there is not always a matching XML on subversion for a given ADL. For example there is http://svn.openehr.org/knowledge/archetypes/dev/adl/openehr/ehr/entry/observ at ion/openEHR-EHR-OBSERVATION.blood_pressure.v1.adl http://svn.openehr.org/knowledge/archetypes/dev/xml/openehr/ehr/entry/observ at ion/openEHR-EHR-OBSERVATION.blood_pressure.v1.xml but not an XML for http://svn.openehr.org/knowledge/archetypes/dev/adl/openehr/ehr/entry/observ at ion/openEHR-EHR-OBSERVATION.respiration.v1.adl To get around this I started to use the LiU Archetype Editor but I realize now it generates a different XML than on subversion. For example the LiU editor generates nodes with type children xsi:type=at:C_QUANTITY rm_type_nameDvQuantity/rm_type_name but on subversion it has children xsi:type=C_DV_QUANTITY rm_type_nameQUANTITY/rm_type_name Is the XML unreliable such that I must use a Java ADL parser? thanks! Greg ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo
OpenEHR queries
Hi Greg, o/items[at0004]/value is actually an invalid path as the identifier o represents an OBSERVATION class and an OBSERVATION does not have an attribute of items, it has a data attribute that is of type HISTORY, which has an events attribute that is of type LISTEVENT, an EVENT has an attribute of data of type ITEM_STRUCTURE which for a ITEM_LIST has an attribute of items. Just like in XPath you need to provide the full path unless you provide a wild card as indicated by Thomas. AQL and the Ocean Query Process does support this wild card and a path such as o//*/items[at0004] can be used. However, we don't really see that these paths will be used directly and the paths will be generated using tools such as the Ocean Template Designer and Archetype Query Builder. Therefore the length of the paths are not a concern and having the complete path actually allows the query processor to perform its job more efficiently as it does not need to search for the leaf node by traversing all possible paths within the data graph. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Monday, 5 November 2007 9:49 PM To: For openEHR technical discussions Subject: Re: OpenEHR queries Question on the query below, if at0004 occurs *only* once in the archetype model, in the position data[at0001]/events[at0002]/data[at0003]/items[at0004]/value, could one theoretically have the shorter query SELECT o/items[at0004]/value FROM EHR [uid = $ehrUid] CONTAINS OBSERVATION o [openEHR-EHR-OBSERVATION.respiration.v1] WHERE o/items[at0004]/value/magnitude $n The reason I ask is it would be tempting to store (in my data model) the single discrete value at0004 to map to my equivalent item. Of course that would break if a new data element was added in a position (fabricated) data[at0001]/events[at0099]/data[at00100]/items[at0004]/value but the simplicity is tempting. thanks Greg http;//www.patientos.org On 11/5/07, Heath Frankel heath.frankel at oceaninformatics.com wrote: Hi Greg, The Archetype Query Language (AQL, formerly known as EHR Query language or EQL) was developed by Ocean Informatics and a specification is being prepared to be offered to the openEHR foundation as a candidate openEHR specification. For now the paper referred to by Rong is the main reference but we hope to provide something on the openEHR WIKI soon. The Ocean Template Designer provides these openEHR (XPath-like) paths as a property of each node but Ocean is also developing an Archetype Query Builder tool that will actually generate the complete query for you. Here is the query generated by the tool as per your use case (it is slightly simpler than the example provided by my colleague Chunlan). SELECT o/data[at0001]/events[at0002]/data[at0003]/items[at0004]/value FROM EHR [uid = $ehrUid] CONTAINS OBSERVATION o [openEHR-EHR-OBSERVATION.respiration.v1] WHERE o/data[at0001]/events[at0002 and name/value='Any event']/data[at0003]/items[at0004]/value/magnitude $n The units can be included as an additional criteria as indicated by Chunlan but it is unnecessary as the archetype only allows one kind of unit for rate. Let me know if you would like further details regarding the Ocean tools. Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph:+61 (0)8 8223 3075 mb: +61 (0)412 030 741 email:heath.frankel at oceaninformatics.com -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Monday, 5 November 2007 9:30 AM To: For openEHR technical discussions Subject: Re: OpenEHR queries Thanks Rong, Just the thought for someone but it would be handy to have the XPath (such as o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value) for a data value somewhere accessible in the editor or in the html generated content such as http://svn.openehr.org/knowledge/archetypes/dev/html/en/openEHR-EHR- OBSERVATION.body_weight.v1.html Just easier for adhoc testing so not a big deal. On 11/4/07, Rong Chen rong.acode at gmail.com wrote: Hi Greg, There was a paper published at Medinfo2007 on this topic. The paper is available at: http://www.openehr.org/downloads/publications/archetypes/MedInfo_2007_EQL_MA .p df Cheers, Rong On 11/4/07, Greg Caulton caultonpos at gmail.com wrote: Hi, Somewhere I recall reading that there was an OpenEHR query that theoretically an OpenEHR compliant system could execute a return results for. Is there a spec somewhere, preferably with a simple example. So if someone knew my
OpenEHR queries
Randolph, You could consider AQL to be a logical query language, this allows semantic queries to be shared amongst heterogeneous (and potentially, non-openEHR) systems without the need to know the systems underlying data model. Therefore, AQL logically runs against the Information Model (using Tim's words) gaining its semantics from Archetype Models. The Ocean Implementation of the query processor physically uses both the data model and information model to execute a query. Another implementation might purely use the data model or information model. Non-openEHR or non-Archetype-based systems may support only a small subset of AQL queries where they have provided an AQL to native query mapping. The point is, AQL is independent of the implementation and are sharable, semantic queries based on shared archetypes. Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 mb: +61 (0)412 030 741 email: heath.frankel at oceaninformatics.com mailto:heath.frankel at oceaninformatics.biz From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Randolph Neall Sent: Tuesday, 6 November 2007 3:35 AM To: For openEHR technical discussions Subject: Re: OpenEHR queries As a developer from the US who sometimes tries to follow discussions here, I have a question probably well answered if I took more time myself to find the answer. Against what do your archetype queries run? Against the DB itself or some representation of the data in memory? I ask because a few months ago, someone from openEHR said in one of the discussions that a DB schema is not part of openEHR, that some private participant in openEHR had one for sale, and Ocean, maybe, but that was it. So, again against what do these queries (see example in Chunlan Ma's message below) run? Thanks, Randy Neall Veriqant, L.L.C. On 11/4/07, Chunlan Ma chunlan.ma at oceaninformatics.com wrote: Hi Greg, Rong has indicated there is a paper about archetype query language. Thanks Rong. That paper introduced basic query syntax. It was written at the beginning of this year. The query syntax has been enriched recently in order to support more complicated queries. I've already started to write the specifications, but need to resolve some known issues before release. Anyway, I handcrafted the following queries for you (I cannot build my query builder at the moment because of some integration issues). The query statement below shows that all observation instances with respiratory rate greater than n will be returned. SELECT o FROM EHR e[ehr_id/value=$ehrId] CONTAINS COMPOSITION CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.respiration.v1.adl] WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnituden AND o/data/events[at0002]/data[at0003]/items[at0004]/value/units = '/min' If you want the respiratory quantity object been returned, the query would look like: SELECT o/data/events[at0002]/data[at0003]/items[at0004]/value FROM EHR e[ehr_id/value=$ehrId] CONTAINS COMPOSITION CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.respiration.v1.adl] WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnituden AND o/data/events[at0002]/data[at0003]/items[at0004]/value/units = '/min' Just for your information, the single letter 'o' is the observation class variable name, /data/events[at0002]/data[at0003]/items[at0004]/value is the archetype path to respiratory quantity node. If you have the archetype workbench running, you can identify this path there. '$ehrId' is the parameter name which can be substituted with real EHR ehr_id value at run time. The query language supports parameterization. Some archetype query statements would be very long if the query criteria are complicated. In fact, we don't need to write the above queries by hand. Ocean Informatics has implemented a tool - Archetype Query Builder, which can be used to create/edit queries easily. Additionally, Ocean has also implemented a query parser and query engine as well. The above query statements are consistent to the query syntax introduced by the MedInfo paper. The current query tools also support this query syntax. However, as I have said that we have enriched the query syntax and all the enhancements can be found from the query specifications. Hope this helps. Regards, Chunlan -Original Message- From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Greg Caulton Sent: Monday, November 05, 2007 6:48 AM To: openEHR-technical at openehr.org Subject: OpenEHR queries Hi, Somewhere I recall reading that there was an OpenEHR query that theoretically an OpenEHR compliant system could execute a return results for. Is there a spec somewhere, preferably with a simple example. So if someone knew my patient and queried for all
OpenEHR queries
Greg, The AQL query parser or query processor is not intended to be implemented in Java by Ocean but it may be implemented by others in the openEHR Java reference implementation at some point. BTW, the openEHR Java reference implementation already has an interface to the Ocean EhrBank EHR Server using Web Services. Regards ? Heath ? Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ? ph:?+61 (0)8 8223 3075 mb: +61 (0)412 030 741 email:?heath.frankel at oceaninformatics.com -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Monday, 5 November 2007 9:48 PM To: For openEHR technical discussions Subject: Re: OpenEHR queries I appreciate the information. Writing new queries wouldn't be too hard, it is parsing the queries and then executing the corresponding queries or service calls against the implemented system that is the tricky part. Is Ocean Informatics planning to provide a open source java (or similar language) implementation of the query parsing engine (I am not implying you should, just a question in case you were)? If you were it would be useful to look at how I could plug in my integration, the early I look at these things in the design the easier it gets. thanks! Greg http://www.patientos.org On 11/5/07, Heath Frankel heath.frankel at oceaninformatics.com wrote: Hi Greg, The Archetype Query Language (AQL, formerly known as EHR Query language or EQL) was developed by Ocean Informatics and a specification is being prepared to be offered to the openEHR foundation as a candidate openEHR specification. For now the paper referred to by Rong is the main reference but we hope to provide something on the openEHR WIKI soon. The Ocean Template Designer provides these openEHR (XPath-like) paths as a property of each node but Ocean is also developing an Archetype Query Builder tool that will actually generate the complete query for you. Here is the query generated by the tool as per your use case (it is slightly simpler than the example provided by my colleague Chunlan). SELECT o/data[at0001]/events[at0002]/data[at0003]/items[at0004]/value FROM EHR [uid = $ehrUid] CONTAINS OBSERVATION o [openEHR-EHR-OBSERVATION.respiration.v1] WHERE o/data[at0001]/events[at0002 and name/value='Any event']/data[at0003]/items[at0004]/value/magnitude $n The units can be included as an additional criteria as indicated by Chunlan but it is unnecessary as the archetype only allows one kind of unit for rate. Let me know if you would like further details regarding the Ocean tools. Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph:+61 (0)8 8223 3075 mb: +61 (0)412 030 741 email:heath.frankel at oceaninformatics.com -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Monday, 5 November 2007 9:30 AM To: For openEHR technical discussions Subject: Re: OpenEHR queries Thanks Rong, Just the thought for someone but it would be handy to have the XPath (such as o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value) for a data value somewhere accessible in the editor or in the html generated content such as http://svn.openehr.org/knowledge/archetypes/dev/html/en/openEHR-EHR- OBSERVATION.body_weight.v1.html Just easier for adhoc testing so not a big deal. On 11/4/07, Rong Chen rong.acode at gmail.com wrote: Hi Greg, There was a paper published at Medinfo2007 on this topic. The paper is available at: http://www.openehr.org/downloads/publications/archetypes/MedInfo_2007_EQL_MA .p df Cheers, Rong On 11/4/07, Greg Caulton caultonpos at gmail.com wrote: Hi, Somewhere I recall reading that there was an OpenEHR query that theoretically an OpenEHR compliant system could execute a return results for. Is there a spec somewhere, preferably with a simple example. So if someone knew my patient and queried for all instances of Respiratory Rate greater than n? openEHR-EHR-OBSERVATION.respiration.v1.adl Rate at0004 n Units /min (is that a default or are the units passed in the query) Or is this future functionality? thanks Greg http://www.patientos.org ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
OpenEHR queries
Randolph, As openEHR has no specification for a persistence model, there is no such thing as a conformant DB schema. At Ocean we have developed a DB schema that is still evolving but this is transparent to any application as the API is based on the openEHR Information Model. We may explore alternate DB schema's and even alternate data store technology, but again this will be transparent to the application. The main article available on this topic was located at http://www.openehr.org/FAQs/t_persistence_notes.htm but has not yet been moved to the new web site. This is really just some suggestions about how a persistence layer could be implemented, it is by no means a specification for conformance. Regards Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Randolph Neall Sent: Tuesday, 6 November 2007 2:03 PM To: For openEHR technical discussions Subject: Re: OpenEHR queries Thanks. Of course, as you say, the Sql parser will vary depending on the structure of the underlying store, and underlying store designs can vary, one of the strengths of openEHR. It would still seem, however, that whole chunks of the AQL would have to end up in the Sql, and that, in turn, would have implications--at least some implications--how the underlying store would have to be designed. Only certain schemas would even work with openEHR. Does the openEHR community offer any suggestions? At Ocean you evidently felt that a certain design was best, not just any design, which you imply when you refer to the need to be conformant. What does it take for a DB schema to be conformant? The persistence model that Ocean uses is a trade off between completely atomising objects and storing them as blobs. Have you disclosed any of the details regarding this tradeoff? Randolph On 11/5/07, Hugh Leslie hugh.leslie at oceaninformatics.com wrote: Hi Randolph, Currently, the only AQL query parser that I know of is one that is part of the Ocean Informatics suite of products and runs against the Ocean EhrBank openEHR repository. Converting AQL to SQL will depend entirely on what your underlying persistence model is and also to some extent what relational database flavour you are using. openEHR doesn't mandate any particular persistence model and as has been already stated, the really nice thing about AQL is that queries are independent of any underlying relational (or object) data model. So an AQL query that is run against two separate and completely independently developed openEHR repositories that probably use a completely separate persistence model should return exactly the same data (as long as they are both conformant). The persistence model that Ocean uses is a trade off between completely atomising objects and storing them as blobs. This has been a process of optimisation and we are really happy with the current performance of the system. This is only one of many possible methods of openEHR persistence. regards Hugh Randolph Neall wrote: I think I understand. Thanks. What actually gets persisted, I suspect, are the paths--and values pointed to by those paths--implicit in your archetype object graph, correct? And to convert AQL query into an SQL query you somehow extract that path from AQL and convert it into some sort of SQL, right? Is there anything on your web site about this, about deriving a DB query from an archtype query? You can have whatever persistence layer as long as it can get expected results back based on the AQL statement. --That's the question. How do you get expected results back based on the AQL Statement? Thanks, Randy Neall On 11/5/07, Chunlan Ma chunlan.ma at oceaninformatics.com wrote: From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Randolph Neall Sent: Tuesday, November 06, 2007 3:35 AM To: For openEHR technical discussions Subject: Re: OpenEHR queries As a developer from the US who sometimes tries to follow discussions here, I have a question probably well answered if I took more time myself to find the answer. Against what do your archetype queries run? Against the DB itself or some representation of the data in memory? I ask because a few months ago, someone from openEHR said in one of the discussions that a DB schema is not part of openEHR, that some private participant in openEHR had one for sale, and Ocean, maybe, but that was it. So, again against what do these queries (see example in Chunlan Ma's message below) run? That's good question. You've noticed that I didn't mention anything about the data store here. In general, query languages are designed specifically for a type of data store. For instance, SQL is run against relational databases. XQuery is run against XML structured data. Object Oriented Query Language need to be run against Object oriented database management systems etc.
OpenEHR queries
Hi Greg, The Archetype Query Language (AQL, formerly known as EHR Query language or EQL) was developed by Ocean Informatics and a specification is being prepared to be offered to the openEHR foundation as a candidate openEHR specification. For now the paper referred to by Rong is the main reference but we hope to provide something on the openEHR WIKI soon. The Ocean Template Designer provides these openEHR (XPath-like) paths as a property of each node but Ocean is also developing an Archetype Query Builder tool that will actually generate the complete query for you. Here is the query generated by the tool as per your use case (it is slightly simpler than the example provided by my colleague Chunlan). SELECT o/data[at0001]/events[at0002]/data[at0003]/items[at0004]/value FROM EHR [uid = $ehrUid] CONTAINS OBSERVATION o [openEHR-EHR-OBSERVATION.respiration.v1] WHERE o/data[at0001]/events[at0002 and name/value='Any event']/data[at0003]/items[at0004]/value/magnitude $n The units can be included as an additional criteria as indicated by Chunlan but it is unnecessary as the archetype only allows one kind of unit for rate. Let me know if you would like further details regarding the Ocean tools. Regards ? Heath ? Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ? ph:?+61 (0)8 8223 3075 mb: +61 (0)412 030 741 email:?heath.frankel at oceaninformatics.com -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Monday, 5 November 2007 9:30 AM To: For openEHR technical discussions Subject: Re: OpenEHR queries Thanks Rong, Just the thought for someone but it would be handy to have the XPath (such as o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value) for a data value somewhere accessible in the editor or in the html generated content such as http://svn.openehr.org/knowledge/archetypes/dev/html/en/openEHR-EHR- OBSERVATION.body_weight.v1.html Just easier for adhoc testing so not a big deal. On 11/4/07, Rong Chen rong.acode at gmail.com wrote: Hi Greg, There was a paper published at Medinfo2007 on this topic. The paper is available at: http://www.openehr.org/downloads/publications/archetypes/MedInfo_2007_EQL_MA .p df Cheers, Rong On 11/4/07, Greg Caulton caultonpos at gmail.com wrote: Hi, Somewhere I recall reading that there was an OpenEHR query that theoretically an OpenEHR compliant system could execute a return results for. Is there a spec somewhere, preferably with a simple example. So if someone knew my patient and queried for all instances of Respiratory Rate greater than n? openEHR-EHR-OBSERVATION.respiration.v1.adl Rate at0004 n Units /min (is that a default or are the units passed in the query) Or is this future functionality? thanks Greg http://www.patientos.org ___ 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-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Multiple parents and max number of nested specialized archetypes?
I haven't followed this whole thread, in particular I haven't seen Rong's emails about templates and aggregation archetypes but I thought I would provide a little input about the future of the template specifications. If you have a look at the Template Object Model as published as a draft in R1.0.1 you will find two packages. The first is the TEMPLATE_SPEC package. This provides a mechanism to specify a template using references to archetypes and aggregating them together. In addition it provides a series of constraint rules of various kinds to do things like constrain cardinalities or specify default values. We have been recently comparing this with the current proprietary template definition used within the Ocean Template Designer and have found that there are very few required template semantics that cannot be expressed using the R1.0.1 TEMPLATE_SPEC draft. The second model is the operational template model. We have actually implemented this and have needed to augment and change this model slightly, but the principles expressed in the R1.0.1 draft (a Template object with definition specified by a C_COMPLEX_OBJECT and list of path and default value pairs) has work fine. This implementation experience will be feed back into the openEHR community for the next release. So in summary, Rong's premise that we can express templates using the AOM is true, but what he calls an aggregation archetype is an operational template. The TEMPLATE_SPEC is just another representation of the same template where it references the existing archetype artefacts and constrains them using rules. The TEMPLATE_SPEC is used to store and maintain the template definition within an authoring environment while the operational template is derived from the TEMPLATE_SPEC and is used within software at run-time. We are just completing the testing of a new export function in the Ocean Template Designer that generates an operational template from its proprietary template definition. This operational template will be used for all sort of purposes including the generation and validation of RM objects that conform to the template. Hope this helps keep you up to date with progress in this area. If you have interest in this area from the technical perspective I suggest that we progress this further in a collaborative manner. Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 mb: +61 (0)412 030 741 email: heath.frankel at oceaninformatics.com mailto:heath.frankel at oceaninformatics.biz From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Lisa Thurston Sent: Monday, 22 October 2007 1:32 PM To: For openEHR technical discussions Subject: Re: Multiple parents and max number of nested specialized archetypes? Hi all I think that in the absence of a template specification it is indeed difficult to see, from a technical viewpoint, the difference between templates and aggregation archetypes (which is what I think Rong means by all the constraints done in templates can be done with archetypes). Heather and Hugh point out that such archetypes would not be universal in their applicability and therefore less shareable. This still leaves a blurry line between where the archetype ends and the template begins. There are some features of templates that do make this line clear, however. The best example I can think of is default values (not to be confused with assumed values). At some point you'll want to be able to say things like the default temperature scale is Centigrade or the default number of foeti is 1. If the default value is free text or even a coded term, this implies that the template is targeted to a specific language/culture, thus NOT universal. Therefore the template specification, when it arrives, is likely to include ways to define default values and the target language/culture of the template. A template is language/culture-specific. There is provision made for default values in the AOM's archetype constraint model but the TYPE of a default is left open. Since the TYPE of these values cannot be constrained by the AOM, default values can never be meaningfully applied in ADL. Rather they can only be applied in the template (which knows about the reference model and target language/culture of the data). This connects to Rong's point about expressing template constraints in AOM semantics. I fully agree the template specification should make use all useful parts of the archetype constraint model or build on top of the AOM. If a template was ever suddenly considered to encapsulate a structure which was universally (or near-universally) applicable, as Hugh suggests, the default values would have to be discarded (as well as other culture-specific structures or assumptions). And for the archetype to be practical
ECG archetypes
David, FYI, There are forthcoming recommendations on including binary data in XML without using base-64. I expect that these would be used when available in implementation. Heath _ From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sam Heard Sent: Sunday, 11 March 2007 7:49 PM To: dclunie at dclunie.com; For openEHR technical discussions Subject: Re: ECG archetypes Hi David Absolutely not - what we need are readers that can make sense of data as a blob and get these specified as suitable for use in an EHR. Do you recommend any very good or very widely used specs which have readers that are publicly available? Cheers, Sam David Clunie wrote: Hi I hope you guys are not considering yet another standard for the encoding of bulk ECG data (as opposed to referencing it or wrap it as a blob). ECG's are analogous to images from radiology; large amounts of bulk data, highly specific meta-data of little or no interest to non-image aware applications and well-standardized already by DICOM. Unfortunately, ECG device and distribution vendors have been slower to adopt standards than the medical imaging device vendors, and so there are a plethora of them, SCP-ECG, DICOM waveforms, HL7 V2 waveforms, and the FDA HL7-CDISC XML submission standard, not to mention just storing a picture of the ECG in a PDF file (the IHE consensus solution). These standards also address the annotation of the waveforms and the conclusions drawn from them by the acquisition device, and it is probably only the latter that would be relevant to be extracted into the EHR. David PS. As to the wrapping versus referencing question for the bulk binary data, I just got through sending a 1.4GB 2,600 slice cardiac CT angiogram to a colleague, which I presume nobody would be crazy enough to base-64 encode and embed in an XML document, for example. The point being that wrapping things is not a scalable solution. Mie Faerch Jensen wrote: Greetings all; We are two graduate students from Aalborg University, Denmark, taking our master in Biomedical Engineering and Informatics. In this semester ?our finale, we are working with complex data interoperability to an Electronic Health Record (EHR). We are following the openEHR?s EHR architecture standard, and therefore also working with archetypes. We have a few questions we would like you to help us deal with. - What we are trying to investigate is how to represent a recorded ECG-signal in an archetype, and therefore we are wondering what the status is on dealing with ECG-signals as an archetype? So far we haven?t been able to locate an ECG- archetype, only the description of it as an observation-entry. - We have described workflows and clinical information guidelines for the observation and clinical evaluation of an incoming ECG-signal, but we are a bit confused on how to map the clinical information guidelines to an archetype. Can anyone give us an example on how this mapping is done? Best regards Mie F?rch Nielsen og Louise Pape S?rensen Aalborg University, Denmark, Master in Biomedical Engineering and Informatics, 10th semester Reply-email: 06gr956d at miba.auc.dk - This mail sent through IMP: http://horde.org/imp/ ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr. Sam Heard MBBS, FRACGP, MRCGP, DRCOG, FACHI CEO and Clinical Director Ocean Informatics Pty. http://www.oceaninformatics.biz/ Ltd. Adjunct Professor, Health Informatics, Central Queensland University Senior Visiting Research Fellow, CHIME, University College London Chair, Standards Australia, EHR Working Group (IT14-9-2) Australia Ph: +61 (0)4 1783 8808 Fx: +61(0)8 8948 0215 UK Ph: +44 (0)77 9871 0980 Fx: +44 (0)207 1174610 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070311/fa3e1f15/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML serializer (retry due to too large message)
Sam, It is only safe if the attributes are primitive types. However I think it would be a good saving considering the current attributes. Heath _ From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sam Heard Sent: Tuesday, 21 November 2006 11:09 PM To: For openEHR technical discussions Subject: Re: XML serializer (retry due to too large message) Hi We can add more attributes safely.which I think is all that could be done without changing the model in a major manner, Sam Mattias Forss wrote: 2006/11/21, Sam Heard sam.heard at oceaninformatics.biz: The Ontology is so huge I have wondered about having the Text and Description as attributes - it would save a lot of space and I do not think it would complicate things at all. What do others think? Sounds like a good idea as long as the two parts (text, description) of the description items will remain. If more parts are added though, it is not a flexible solution. Mattias Cheers, Sam _ ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr. Sam Heard MBBS, FRACGP, MRCGP, DRCOG, FACHI CEO and Clinical Director Ocean Informatics Pty. http://www.oceaninformatics.biz/ Ltd. Adjunct Professor, Health Informatics, Central Queensland University Senior Visiting Research Fellow, CHIME, University College London Chair, Standards Australia, EHR Working Group (IT14-9-2) Ph: +61 (0)4 1783 8808 Fx: +61 (0)8 8948 0215 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061122/41d71116/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML serializer (retry due to too large message)
Mattias,
You don't seem to follow the AOM when generating your XML instances. For
example, the C_MULTIPLE_ATTRIBUTE class has a property of 'members' which is
a list of C_OBJECT. This property name should be used in the XML instance
so you would get:
attributes xsi:type=at:C_MULTIPLE _ATTRIBUTE
members
item xsi:type=C_COMPLEX_OBJECT.../item
item xsi:type=C_COMPLEX_OBJECT.../item
/members
/attributes
The alternative is to have the following but I suggest that members is not
quite right similar to your use of children below.
attributes xsi:type=at:C_MULTIPLE _ATTRIBUTE
members xsi:type=C_COMPLEX_OBJECT.../members
members xsi:type=C_COMPLEX_OBJECT.../members
/attributes
I would also suggest that we should follow the AOM more closely and use an
existence element rather than minOccurs and maxOccurs. What you are doing
by using the later is mimicking ADL rather than following the AOM.
Therefore you would get by following based on the openEHR RM for the
Interval type.
attributes xsi:type=at:C_MULTIPLE _ATTRIBUTE
existence
lower xsi:type=xs:int1/lower
upper xsi:type=xs:int1/upper
...
/existence
members
item xsi:type=C_COMPLEX_OBJECT.../item
item xsi:type=C_COMPLEX_OBJECT.../item
/members
/attributes
Regards
Heath
_
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Mattias Forss
Sent: Friday, 17 November 2006 8:16 AM
To: For openEHR technical discussions
Subject: Re: XML serializer (retry due to too large message)
Hi Andrew,
I looked at your example and I think it could be a good way to use xsi:type
to indicate sub-types where the number of children elements are specified to
be only one. This will mean that we don't need to add an extra sub-element,
e.g. description xsi:type=RESOURCE_DESCRIPTION (details here:
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishi
ng/its/XML-schema/documentation/Archetype.xsd.html_h439624612.html).
However, I don't think the XML schema specification of the AOM explicitly
state that xsi:type should be in XML archetypes. I would appreciate if
openEHR published some XML archetypes that exemplified the standard way to
express them. I don't like the idea of having several ways of representing
archetypes in XML so it would be nice if some examples were out to lead the
way.
When there are more than one child inside an element, the idea with xsi:type
requires us to repeat the container element for each child instead of
placing all children inside a single container element, so you have
attributes xsi:type=at:C_MULTIPLE _ATTRIBUTE minOccurs=1 maxOccurs=1
...
children xsi:type=C_COMPLEX_OBJECT.../children
children xsi:type=C_COMPLEX_OBJECT.../children
/attributes
instead of
attributes xsi:type=at:C_MULTIPLE _ATTRIBUTE minOccurs=1 maxOccurs=1
...
children
C_COMLEX_OBJECT.../C_COMPLEX_OBJECT
C_COMLEX_OBJECT.../C_COMPLEX_OBJECT
/children
/attributes
The first example is of course more compact, but the element name children
doesn't make sense, since it doesn't contain all of the attribute's
children. The second example will collect all the children in one single
container element, but again, I don't know what the specification mean with
the occurrences brackets, e.g. what does [0..*] refer to in children
C_OBJECT
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publish
ing/its/XML-schema/documentation/Archetype.xsd.html_h-1665829344.html
/children [0..*] ? Does it refer to the children element or to the
C_OBJECT element? This should be clarified. I have been dealing a lot with
ADL and I can say that the second example seems more plausible to me and I
see the children element equal to an attribute's matches {} in ADL.
Any thoughts about this?
Regards,
Mattias
2006/11/16, Andrew Patterson andrewpatto at gmail.com:
Hi Mattias, I've attached my attempt at a serialized adl instance - perhaps
we can converge on a consensus as to what they should look like!
Mine is incomplete - especially around the ontology section - but I have
done the attributes and children nodes differently, using xsi:type to
indicate the sub-type. This is similar to the way Sam did the reference
model serializations I saw, so I thought similar techniques would be
applied here.
Anyhow, I'm off on another project for a few weeks, but I thought I'd
send you this instance as food for thought.
Andrew
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061117/88d32b2e/attachment.html
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
[Norton AntiSpam] RE: XML serializer (retry due to too large message)
Mattias, Sorry, I didn't realise this schema was available (I overlooked your reference to it in your original email). OK, so based on this schema the instance is similar to my second example (but using children as the element name rather than members) and your first example, which neither of us like due to the plural nature of the element name for a singular element. I think we need to pass this feedback on to Sam and see if we can ensure that the schema fully reflects the Reference Model including element names that reflect model attribute names such as members and existence. The usual way a list is represented is a container with multiple items, this is how I came up with this representation of a members element with item child elements. You are right in stating that this is not in the XML schema or AOM, I was looking at this from first principles. Looking deeper into how the openEHR RM XML schemata represent containment, I find that it has used the pattern suggested in the Archetype XML schema. For example SECTION has element called items that is repeatable. I guess we need to continue with that pattern unless we change the openEHR RM XML schemata as well. The problem with changing this is that the openEHR paths are designed to be compatible with XPath and converting a path such as /content[openEHR-EHR-SECTION-findings.v1]/items[openEHR-EHR-OBSERVATION-labo ratory.v1] into XPath and evaluating it will expect to have an XML element called items within an element called content. Therefore I suggest that based on the current XML schema your instance should look like your first example: attributes xsi:type=at:C_MULTIPLE _ATTRIBUTE minOccurs=1 maxOccurs=1 ... children xsi:type=C_COMPLEX_OBJECT.../children children xsi:type=C_COMPLEX_OBJECT.../children /attributes However, I would advocate that we should submit a change request to change the schema to use the element name of members rather than children. There are probably other AOM alignments required. Additionally I would like to see the use of an existence element of type INTEGER_INTERVAL (i.e. INTERVALinteger) rather than minOccurs maxOccurs. Thoughts? Heath _ From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Mattias Forss Sent: Friday, 17 November 2006 4:44 PM To: For openEHR technical discussions Subject: Re: XML serializer (retry due to too large message) Hi Heath, I know that the C_MULTIPLE_ATTRIBUTE class has a property of 'members' in the AOM (since I know the AOM very much in detail), but it's not in the XML schema specification. I have not followed the AOM, because I thought I was only supposed to look at the schema. Here's the XML schema and XML instance of C_MULTIPLE_ATTRIBUTE with the property 'children' and not 'members' as in the AOM: http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishi ng/its/XML-schema/documentation/Archetype.xsd.html_h783584366.html http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publish ing/its/XML-schema/documentation/Archetype.xsd.html_h783584366.html . If you could explain a bit more which strategy I should use when generating XML instances I would be very grateful. It seems you suggest I should follow the AOM more closely instead of the XML schema of AOM and its instance representations. By the way, your second example representation of 'members' is similar to Andrew's example and not mine. I have one container element called 'children', but no xsi:type specified. Where do you get the item element name from? I can't find it neither in the XML schema nor the AOM. Regards, Mattias 2006/11/17, Heath Frankel heath.frankel at frankelinformatics.com: Mattias, You don't seem to follow the AOM when generating your XML instances. For example, the C_MULTIPLE_ATTRIBUTE class has a property of 'members' which is a list of C_OBJECT. This property name should be used in the XML instance so you would get: attributes xsi:type=at:C_MULTIPLE _ATTRIBUTE members item xsi:type=C_COMPLEX_OBJECT.../item item xsi:type=C_COMPLEX_OBJECT.../item /members /attributes The alternative is to have the following but I suggest that members is not quite right similar to your use of children below. attributes xsi:type=at:C_MULTIPLE _ATTRIBUTE members xsi:type=C_COMPLEX_OBJECT.../members members xsi:type=C_COMPLEX_OBJECT.../members /attributes I would also suggest that we should follow the AOM more closely and use an existence element rather than minOccurs and maxOccurs. What you are doing by using the later is mimicking ADL rather than following the AOM. Therefore you would get by following based on the openEHR RM for the Interval type. attributes xsi:type=at:C_MULTIPLE _ATTRIBUTE existence lower xsi:type=xs:int1/lower upper xsi:type=xs:int1/upper ... /existence members item xsi:type
Normal and other ranges
So, it appears that we have no pathologists on the list to comment on the standardisation of these codes. I guess all I can suggest is that these are standard codes as per the HL7 V2.x standard but the interpretation of using them is unlikely to be but it is just that we are looking the capture and not loose in the translation from HL7 message to openEHR. Having said that, in Australia it is common practice by labs to use three levels of abnormality (i.e. HHH LLL(. Would an alternate approach be to include an additional element in the Archetype to store this abnormality flag rather than including it in the DV_ORDERED? Heath -Original Message- From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Sunday, 10 September 2006 12:32 AM To: For openEHR technical discussions Subject: Re: Normal and other ranges Heath Frankel wrote: Rodrigo, I am jumping in late in the The DV_QUANTITY (or technically the DV_ORDERED abstract class) data type represents the reference range specified by the lab using the the normal_range relationship. There is also other_reference_ranges to represent all possible reference range differentiated by various patient context such as pregnant female, etc. The normal_range is used for the range that is applicable to this subject. The is_normal method in DV_ORDERED allows it to compare the actual quantified magnitude with the normal range and return an indicate that it is normal or not. You can use this to raise your alert of abnormal results when is_normal returns false. The XML schema published with openEHR Release 1 actually went one step further and I believe it is a necessary addition to the reference model. It treats is_normal as an attribute and allows you to optionally specify the value of is_normal rather than it being calculated. This is useful when transforming HL7 Lab data into openEHR and Pathologists seem to not like downstream manipulation and interpretation of raw data in case the original data is mis-interpreted. This has lead to particular best-practice in Australia where lab data provided in atomic form also needs to have a full text report included along with the atomic data which should be used for display and audit purposes. Even though openEHR support an indicator for is_normal this still stops short of lab data provided in HL7 messages. The abnormal flag in HL7 lab results is coded with values such as L, H, LL, HH, N, A, AA, etc indicating more than not normal but which direction and the degree of abnormality. When transforming this source data into openEHR we loose this additional information about abnormality. Heath, the obvious question here is: how standardised are these letters and their meanings? Can we assume that all labs the attach HH to a serum sodium mean that the value is in the same sub-range? If not, this kind of data is not useful for longitudinal queries into the EHR, since a query for serum sodium with HH normal indicator would not have a consistent meaning or result. If standards don't exist for these flags, then they would need to be created - you can imagine that for the hundreds of pathology tests possible, defining the subranges corresponding to L, H, LL, etc would be a huge amount of work! And current normal ranges are getting revised all the time anyway (people getting taller, heavier, etc). I take the point that physicians don't in general want to see data from the lab removed, but I would like to hear from pathologists physicians on how they would see this kind of thing being used, standardised, and working in a longitudinal record whose contents are derived from all over the place. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: Antw: Re: Antw: Re: EHRcom/openEHR the new exciting paradigm
and Excel as you are now. What we need is equivalent openEHR archetype for each of your Care Statement RMIMs and in your mapping spreadsheet a couple of columns for the openEHR archetype mappings. Once we get the process right we can then develop the tools to support it. BTW, a member of my development team (who was a obstetrician) is going through the process of developing a pregnancy clinical scenario (mega storyboard) and mapping the data element and sample data into archetypes. I wonder of you would be interested in working with her or at least sharing your experiences and current process? Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 fax: +61 (0)8 8223 2570 mb: +61 (0)412 030 741 email: mailto:heath.frankel at oceaninformatics.biz heath.frankel at oceaninformatics.biz _ From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Williamtfgoossen at cs.com Sent: Tuesday, 19 September 2006 7:01 AM To: openehr-technical at openehr.org Subject: Antw: Re: Antw: Re: Antw: Re: EHRcom/openEHR the new exciting paradigm In een bericht met de datum 18-9-2006 10:45:04 West-Europa (zomertijd), schrijft Thomas.Beale at OceanInformatics.biz: There are guideline and workflow languages (not provided by HL7 or openEHR), and the beginnings of models for choreography coming from WfMC and other places. I have looked into the WfMC materials, and the basic process flow descriptions are currently met with the HL7 v3 Care Plan. (This is not a point if HL7 can do, it is the point that it is possible to define the clinical process using a standard, I think it is transferable to OpenEHR archetype as well). The key here is the use of the following mood codes: definition will tell you wat according to best practice or evidence base should be done for a patient with problem x. (including monitoring of observations, tests, meds etc). The OpenEHR template specification that links archetypes could perhaps do similar things. intent mood helps the clinician to carry over from guideline into the care plan what is necessary for individual patient P. Thus the set of data required can be determined, and it can be justified why items are not carried from guideline to plan. (E.g. you do not female things for a male patient). Then if some professional wants to order a observation this can be done with request. e.g. the doctor askes the nurse to measure the blood pressure 4 times a day. In the Goal mood, the expected value can be set, e.g. the expected value of BP in a week should best be 130/90. the observatoin is carried out say 7 days 4 times a day leading to 7 x 4 = 28 observations in event mood. The statement collecter allows to trend this. The comparison of goal versus the event(s) trends, or the last value of day 7 allows to determine if the goal is met (conclusion being then the 29th observation). The derivation method allows to specify also workflow rules like: do BP measurements until 4 x 130/90 or similar as a criterion for the do X until Y workflow standard. I am not telling this is best handled in HL7 v3, I just want to say that a] it is possible to express clinical meaningful workflows, that at EHR level are pretty handy for a nurse to pop up on the worklist every 6 hours, and that it is possible to exchange the semantics of such a workflow / careplan via a message. Yes, this is interesting stuff and needs a lot of work. William -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060919/6fb3e1b3/attachment.html
Sources of information on HL7 EHR/OpenEHR
Gerard, Interesting you raise this topic as it is becoming an interest of mine to start investigating the use of openEHR instructions to support the documentation requirements of clinical workflows such as medication prescriptions, dispense and administration, and referrals. The existing work of ContSys could certainly assist in this but being a techo, I need some clinicians to assist in developing these requirements and my Ocean clinician colleagues are already over extended. As you know, Ocean has and continues to develop the tools to support a simulation of these kind of clinical workflow scenarios and are looking for ways to gather more and varied clinical content to populate and test the OceanEHR suite. Are there people interested in providing clinical scenarios and data to assist in the requirements and content gathering process to be used in clinical workflow simulations? How can we initiate and progress this kind of activity and investigation? Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 fax: +61 (0)8 8223 2570 mb: +61 (0)412 030 741 email: mailto:heath.frankel at oceaninformatics.biz heath.frankel at oceaninformatics.biz _ From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Gerard Freriks Sent: Friday, 15 September 2006 7:39 AM To: For openEHR technical discussions Subject: Sources of information on HL7 EHR/OpenEHR Dear all, The 'next frontier' will be the various types of workflow and the interaction with the EHR and other components in an EHR-system. Before rushing into quick decisions and quick fixes I call for a study of: - CEN/tc251 System of Concepts for Contuity of Care, ContSys. - CEN/tc251 Health Information Services Architecture, HISA. The first contains the set of concepts dealing with co-operation between healthcare providers around the care of a patient. Several concepts dealing with care plans, clinical path ways in various sorts are defined. The second can help us think about the various levels where types of workflow take place because it defines in a generic way EHR-system components,their inter faces and behaviour. Each type of workflow will use its own model and behaviour of its components. The whole exercise needs to start with a validated set of requirements and the study of some important literature. It is my expectation that En13606/openEHR, ContSys and HISA contain more than enough ingredients to find a good solution. With regards, Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 there are two levels of expression of clinical knowledge, guidelines, evidence etc that we can use, namely a1) guidelines etc that are mentioned in an archetype, and inform the design of the archetype. This can be done as I described. In this case, the guideline or other knowledge reference is the same for all data built from the archetype. a2) resources that are referenced on a per-archetype basis, but not in the archetype, rather they are referenced from the archetype classification ontology that indexes archetypes b) guidelines referenced in data, i.e. on a per instance basis. On the model you see here: http://www.openehr.org/uml/release-1.0/Browsable/_9_0_76d0249_1109249648736_ 872559_12384Report.html the class CARE_ENTRY has the attributes protocol (how / why did I create this clinical statement/observation/whatever), guideline_id that enables the referencing of guideline that caused this Entry to be created (e.g. maybe some guideline told the doc to measure the BP and also ask questions about smoking); ENTRY.workflow_id may also be relevant, for Entries created due to workflow execution. I would think these go close to supporting today's requirements in this area, although I realise we cannot predict the requirements of the future... -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060915/5192fd8b/attachment.html
Sources of information on HL7 EHR/OpenEHR
Andre, Thanks for these links, this resource will be useful in the future. However, it is significantly more in-depth then I am looking for at the moment. It is probably a terminology issue also when I talked about clinical workflow, perhaps I should not have used this term as I wasn't talking about guidelines. Although I have an interest in guidelines my current issue is the day-to-day work of a clinician prescribing medication and writing referrals, and following the state transitions of these instructions through to conclusion by recording them in the EHR. It is mainly the generation of clinical scenarios and content that I am seeking assistance to allow me to simulate the scenarios using the Ocean openEHR suite of tools to test the application of openEHR in the process of medication orders to Pharmacies, and clinical and diagnostic referrals for starters. Once we get these day to day clinical processes supported then we can look at the more complex work flows like guidelines and care plans. Do you have any clinical scenarios and sample clinical content for your Asthma guidelines? Hope this clarifies. Heath -Original Message- From: Andre Duszynski [mailto:andre.duszyn...@adelaide.edu.au] Sent: Friday, 15 September 2006 12:17 PM To: For openEHR technical discussions Cc: heath.frankel at frankelinformatics.com Subject: Re: Sources of information on HL7 EHR/OpenEHR Hello Heath, As part of an Australian RACGP/GPCG informatics project, i've made tentative steps into generating a resource for clinicians in migrating traditional paper-based clinical guidelines to their equivalent within an EHR framework; openEHR being the type example. The web resource is an evolving project in that I acknowledge that I've bitten off too much to chew - had hoped to generate both the archetypes and templates for asthma management !! Anyways. This resource which is very much open to comment, refinement and collaboration is available at: http://www.adelaide.edu.au/health/gp/units/medic-gp/openehr/ Being semi-techo and straddling the clinical domain, i've used the Australian Asthma Management Handbook for primary care as the type example. In respect to clinical workflows for asthma management, you may want to look at the following link which aims to abstract clinical asthma workflows from the handbook: http://www.adelaide.edu.au/health/gp/units/medic-gp/openehr/asthma/ I very much believe that a generic set of archetypes would straddle many clinical activities and would act to bind management motifs across disease states (or alternate considerations). Thus very keen to see and add to this domain of knowledge ! Thanks additionally to Gerard for raising CEN/TC251 - interesting. Regards, Andre Duszynski. --- Heath Frankel wrote: Gerard, Interesting you raise this topic as it is becoming an interest of mine to start investigating the use of openEHR instructions to support the documentation requirements of clinical workflows such as medication prescriptions, dispense and administration, and referrals. The existing work of ContSys could certainly assist in this but being a techo, I need some clinicians to assist in developing these requirements and my Ocean clinician colleagues are already over extended. As you know, Ocean has and continues to develop the tools to support a simulation of these kind of clinical workflow scenarios and are looking for ways to gather more and varied clinical content to populate and test the OceanEHR suite. Are there people interested in providing clinical scenarios and data to assist in the requirements and content gathering process to be used in clinical workflow simulations? How can we initiate and progress this kind of activity and investigation? Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 fax: +61 (0)8 8223 2570 mb: +61 (0)412 030 741 email: heath.frankel at oceaninformatics.biz mailto:heath.frankel at oceaninformatics.biz -- -- *From:* openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] *On Behalf Of *Gerard Freriks *Sent:* Friday, 15 September 2006 7:39 AM *To:* For openEHR technical discussions *Subject:* Sources of information on HL7 EHR/OpenEHR Dear all, The 'next frontier' will be the various types of workflow and the interaction with the EHR and other components in an EHR-system. Before rushing into quick decisions and quick fixes I call for a study of: - CEN/tc251 System of Concepts for Contuity of Care, ContSys. - CEN/tc251 Health Information Services Architecture, HISA. The first contains the set of concepts dealing with co-operation between healthcare providers around the care of a patient. Several concepts dealing with care plans, clinical
Version and commit
Actually I suggested Import_Commit_Audit not Local_Commit_Audit. Heath _ From: owner-openehr-techni...@openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Sam Heard Sent: Wednesday, 8 March 2006 3:55 PM To: Openehr-Technical Subject: Version and commit Dear All Heath and I have been discussing issues about commiting and attesting data. We want to be able to attest something that is immutable - the data of the composition and the commit details. There are two types of versioned data (page 41 of the Common IM) - the Version and the imported version. The parts that need to be immutable are: * UID * preceding_version_id * lifecycle_state * create_audit - (presently a function which calls the commit_audit if not imported and the original_create_audit if it is imported) * data In the Ocean implementation we store the composition as a blob and would like to store everything that is immutable - nothing that changes (e.g. attestations, contribution ID etc). I have proposed that this set of attributes makes up the X_Version - that information to send as part of an extract - as it is unchanging. Heath is keen to have the Version be able to deal with this and store it consistently - he would like to make the reference model deal with this more elegantly. He has suggested that we change what is now called commit_audit to create_audit and change the IMPORTED_VERSION original_create_audit to local_commit_audit. This would mean that commit_audit became a function on each class (now called create_audit) returning the create_audit on the VERSION and the local_commit_audit on the IMPORTED_VERSION. Any ideas - it is a very minor change but I think meets both our needs. Cheers, Sam -- Dr. Sam Heard MBBS, FRACGP, MRCGP, DRCOG, FACHI CEO and Clinical Director Ocean Informatics Pty. http://www.oceaninformatics.biz/ Ltd. Adjunct Professor, Health Informatics, Central Queensland University Senior Visiting Research Fellow, CHIME, University College London Chair, Standards Australia, EHR Working Group (IT14-9-2) Ph: +61 (0)4 1783 8808 Fx: +61 (0)8 8948 0215 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060308/8a9f5c1d/attachment.html
Proposed slightly radical change to CODE_PHRASE in Text package in openEHR
Tom,
My only comments is related to the resulting XML schema. Any reason we
couldn't simplify the XML further to the following:
name xsi:type=DV_CODED_TEXT
valueclinical finding/value
defining_codeSNOMED-CT::404684003/defining_code
/name
Having data enclosed within the defining_code element indicates that this is
the value anyway so we don't need the additional value child element. The
only potential downside of this is if there are additional attributes or
associations added to code_phrase later which would need to then be
represented as follows:
name xsi:type=DV_CODED_TEXT
valueclinical finding/value
defining_codeSNOMED-CT::404684003
some_other_attributesome
data/some_other_attribute
/defining_code
/name
Even though the result is still valid XML it is not the normal
representation in XML. We would then need to change the schema to
include the value element again. What is the likelihood of additional
attributes to Code_Phrase?
Sorry for the discussion of what the XML looks like, but you started it :.
Heath
-Original Message-
From: owner-openehr-technical at openehr.org
[mailto:owner-openehr-technical at openehr.org] On Behalf Of Thomas Beale
Sent: Sunday, 15 January 2006 15:19
To: Openehr-Technical
Subject: Proposed slightly radical change to CODE_PHRASE in
Text package in openEHR
Dear all,
we just came across a feature of the current openEHR
Reference Model which, in the light of current
implementations (particularly XML), it seems would be good to
alter slightly. The change has no semantic effect, only
affecting how data are persisted. We are too close to the
Release 1.0 release date to be making such changes for my
liking at least, but on the other hand I suspect that this
change would be of universal benefit.
The class concerned from the current model is as follows:
class CODE_PHRASE
terminology_id: TERMINOLOGY_ID
-- Identifier of the distinct terminology from which
the code_string (or its elements) was extracted.
code_string: String
-- The key used by the terminology service to
identify a concept or coordination of concepts.
-- This string is most likely parsable inside the
terminology service, but nothing can be assumed
-- about its syntax outside that context.
end
The effect of this in XML data is to have to store:
name xsi:type=DV_CODED_TEXT
valueclinical finding/value
defining_code
code_string404684003/code_string
terminology_id
valueSNOMED-CT/value
/terminology_id
/defining_code
/name
The PROPOSED CHANGE to the class is as follows:
class CODE_PHRASE
value: String
-- the string concatenation form of the term, in the form
-- terminology_id::code_string, e.g. SNOMED-CT::404684003
terminology_id(): TERMINOLOGY_ID{}
-- NOW A FUNCTION
-- Identifier of the distinct terminology from which
the code_string (or its elements) was extracted.
code_string(): String{}
-- NOW A FUNCTION
-- The key used by the terminology service to identify
a concept or coordination of concepts.
-- This string is most likely parsable inside the
terminology service, but nothing can be assumed
-- about its syntax outside that context.
end
The effect of this in XML data is to have to store:
name xsi:type=DV_CODED_TEXT
valueclinical finding/value
defining_code
valueSNOMED-CT::404684003/value
/defining_code
/name
We believe this will also enable more powerful path
expressions using the syntax form of coded terms, since the
whole coded term code is now just one attribute, e.g.
SNOMED-CT::404684003.
openEHR already uses micro-syntaxes for various kinds of
identifiers, such as archetype id, and a few other things,
like units, so we see this proposed change as compatible with
the existing state of affairs. It also has no semantic effect
on the object-oriented view of CODE_PHRASE, since
terminology_id and code_string hoth return the same values as
before (it is just that now they are computed).
The only downside to this change we can see is that some
current implementors will need to change their softare and schemas.
In the balance of considerations, I would prefer to impose
the nuisance value now, and have a better reference model to
live with for the next 5-10 years.
Do others agree?
Are their violent objertions?
Does anyone see a flaw in the proposal?
thanks,
- thomas beale
--
__
_
CTO Ocean Informatics (http://www.OceanInformatics.biz)
Research Fellow, University College London
The semantics of archetype Specialization
Andrew, I thought that the archetype approach was certainly extension. In fact there examples of such. Refer to Adverse-Reaction and Adverse-Reaction-Medication. I am also sure it supports restriction, the same example also supports this. Unlike some people, I believe that restriction is a valid form of specialisation as far as UML is concerned. Certainly in OOP, I often have an abstract property that has its value set (sometimes in hardcode) in the concrete class. Heath -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Andrew Goodchild Sent: Thursday, 26 May 2005 13:36 To: openehr-technical at openehr.org Subject: RE: The semantics of archetype Specialization I would only hope that that is what is intended. However, the semantics at the moment that appears to be supported by the editor implies that archetype specialization is nothing more that cut and paste style semantics. We will have to wait for the answer from Tom and Sam. Also, I am wondering if archetype specialization only supports restriction or extension or both? -Andrew -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 12:08 PM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew Well, I'll defer to Tom or Sam. But from a computational perspective, what else could make sense? Grahame Andrew Goodchild wrote: Thanks Grahame, The UML specs definition of specialization matches what I thought it had meant. I guess what I would like to understand is whether such a definition is true or not for archetypes? Is specialization in archetypes meant to support the definition you provided and the archetype editor is missing some functionality to ensure that only correctly specialized archetypes can be built? - or - Is it that archetypes and the editor supports some new semantics around specialization that I don't quite understand yet? I am sure Sam or Tom could shed some light on this ... Cheers, Andrew -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 10:57 AM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew Does anyone know what it actually means to specialize an archetype? And what the rules are? The UML specification offers this definition for generalization: A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific element may be used where the more general element is allowed I think that this is a fairly watertight definition and quite relevent to your question. I looked at the archetype editor and created a specialized archetype of another. The editor seemed to just copy the parent archetype and then allowed the user to change anything about the archetype. For example, I can now make a mandatory field optional, or I can extend a parent archetype with new mandatory fields that don't exist as optional fields in the parent archetype By the UML definitions, these become ill-formed model. Of course, it's one thing to to state the definition, quite another to know how to compute whether a model is ill-formed. Grahame - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
