Could YAML replace dADL as human readable AOM serialization format?
implementation (partly using JSON, Javascript etc) (primarily for RM objects) in this process I happened to see that YAML might do the job of dADL and that we then we could reuse parser/serializer work of others (for many programming languages) instead of maintaining dADL frameworks. I wanted to share this thought at an early stage and I do appreciate that some have at least responded with positive interest and curiosity. Sometimes time can be saved by discussion before implementation, especially carefully considering what should or should not be implemented. People at UCL or Ocean Informatics can probably regularly speak in person to core openEHR decision makers and designers, the rest of as have the mailing lists as major channels, please try to respect that too. Please do not get me wrong, all the discussion we are having here is useful, it is just that in my humble opinion, some discussions are more useful than others if this standard into which I am heavily investing is to go forward. You are not the only one having invested a lot of years and work in openEHR. I would ask you and others to please allow those that want to discuss things before and during implementation to do so if they wish to. Regarding YAML the p.s. on the start message of this thread said: P.s. Tom Beale and I sort of started a brief off-list discussion about YAML, here is now an attempt to get input from more people. I think it is better for the openEHR community to have things that are of potential interest to others, even things that are not yet tested, as on-list discussions rather then off-list discussions, but I am not longer sure everyone agrees and this is a bit worrying to me. I do still think there is enough people appreciating early open discussions and will try to continue along that path but try to remember tagging such sections with [Warning: may contain new thoughts] :-) Best regards, Erik Sundvall erik.sundvall at liu.semailto:erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 P.s. [Warning: may contain new thoughts] I suspect a current off-list discussion of scalable distributed alternatives to the CKM based on GIT might be unwelcome on the list too and it might be better to keep off-list for a long time until it has been at least partially tested some time in the distant future, since there are other things (like releasing other software) that need to be prioritized first before we have time to test anything. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111208/9bf47602/attachment.html
open source openEHR-related EHR systems; How do you want to be cited...
Hi! We now getting the LiU EEE paper Applying REST Architecture to Archetype-based EHR systems (by Erik Sundvall, Mikael Nystr?m, Daniel Karlsson, Martin Eneling, Rong Chen and H?kan ?rman) finished for submission, and in a background passage we mention other openEHR based EHR systems (where you can enter and query pateint data) that are open source: ...the situation has changed to the better and more open source alternatives [opereffa, openEHRgen, GastrOS, oship/MLHIM] that explores different approaches to implement openEHR systems... Now, if you are involved one of the mentioned systems [opereffa, openEHRgen, GastrOS, oship/MLHIM], what is your favorite or most up to date paper or other reference that you think describes your system best and that you would prefer that people considered citing in academic papers? If you feel that we have missed listing an open source openEHR system with non-viral permissive licence, then please enlighten us! Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111208/77d721f6/attachment.html
CKM new Release
Dear all, We have released a new version of CKM - up and running at openehr.org/knowledge The 1.1.5 release of CKM is a release that contains some major new functionality and some minor usability changes and bugfixes. Most prominently, it features the newly developed review functionality for terminology subsets (termsets) within CKM following a similar process to the currently available archetype content reviews. Some new functionality has been integrated into this release in an effort to streamline some of the tasks for CKM editors: For example, there is a new admin report on active branches of all resources that helps in keeping track of current (and outdated) activity. Also there is a new overview of users with a certain CKM-wide role (e.g. all administrators) and editors are now able to upload to branches that have not originally been checked out by them (used e.g. for merging). This release does not contain any major changes to the user experience but finetunes some aspects of user interaction, display and the handling of revisions. You can find all the details here: http://www.openehr.org/wiki/display/healthmod/CKM+Release+1.1.5 If you notice any oddities, please let me know! Best regards Sebastian
Wrong C_DOMAIN_TYPE subclass C_CODED_TEXT in aom and aom1.5?
Hi, I'm working with archetypes that have DV_CODED_TEXT nodes, and those nodes are always constrained by C_COMPLEX_OBJECT, not by C_CODED_TEXT. And the internal constraint is C_CODE_PHRASE. Is there any case that use the C_CODED_TEXT constraint instead of the combination of C_COMPLEX_OBJECT/C_CODE_PHRASE? Thanks! -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111208/41dea152/attachment.html
Wrong C_DOMAIN_TYPE subclass C_CODED_TEXT in aom and aom1.5?
On 08/12/2011 16:56, pablo pazos wrote: Hi, I'm working with archetypes that have DV_CODED_TEXT nodes, and those nodes are always constrained by C_COMPLEX_OBJECT, not by C_CODED_TEXT. And the internal constraint is C_CODE_PHRASE. Is there any case that use the C_CODED_TEXT constraint instead of the combination of C_COMPLEX_OBJECT/C_CODE_PHRASE? Thanks! -- Hi Pablo, there are three C_xxx special types, that allow CODE_PHRASE, DV_QUANTITY and DV_ORDINAL to be more conveniently constrained than if the standard C_COMPLEX_OBJECT approach were used: C_CODE_PHRASE, C_DV_QUANTITY and C_DV_ORDINAL. These types are described in the openEHR Archetype Profile http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/openehr_archetype_profile.pdf (There is no C_CODED_TEXT type defined there). Our experience is that these types are used nearly universally because they express the typical semantics much more easily that the standard ADL would. The parent class C_DOMAIN_TYPE is the plug-in point for more such classes. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111208/8b9d265c/attachment.html
Wrong C_DOMAIN_TYPE subclass C_CODED_TEXT in aom and aom1.5?
Thank you Thomas, I was creating some docs for the openEHR course and I missed that aom.pdf annex A was just an example!!! (there is where I saw the C_CODED_TEXT) My bad, sorry for that :D -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Thu, 8 Dec 2011 19:16:55 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: Wrong C_DOMAIN_TYPE subclass C_CODED_TEXT in aom and aom1.5? On 08/12/2011 16:56, pablo pazos wrote: Hi, I'm working with archetypes that have DV_CODED_TEXT nodes, and those nodes are always constrained by C_COMPLEX_OBJECT, not by C_CODED_TEXT. And the internal constraint is C_CODE_PHRASE. Is there any case that use the C_CODED_TEXT constraint instead of the combination of C_COMPLEX_OBJECT/C_CODE_PHRASE? Thanks! -- Hi Pablo, there are three C_xxx special types, that allow CODE_PHRASE, DV_QUANTITY and DV_ORDINAL to be more conveniently constrained than if the standard C_COMPLEX_OBJECT approach were used: C_CODE_PHRASE, C_DV_QUANTITY and C_DV_ORDINAL. These types are described in the openEHR Archetype Profile (There is no C_CODED_TEXT type defined there). Our experience is that these types are used nearly universally because they express the typical semantics much more easily that the standard ADL would. The parent class C_DOMAIN_TYPE is the plug-in point for more such classes. - thomas ___ 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/20111208/695e5aaf/attachment.html
Could YAML replace dADL as human readable AOM serialization format?
After reading Pablo's post on domain types I am curious about how should they be represented on each one of the different formats. I feel they should be 'expanded' before trying to represent them in any other format, but I might be wrong. Any ideas or opinions? 2011/12/8 Koray Atalag k.atalag at auckland.ac.nz: Oh, just my personal thoughts without any sanity check ? should have read the whole thread first! My reaction was just to what was written in the subject line of the thread and after reading Seref?s comments about the need to focus on outstanding/high priority issues. Sorry if I have offended ? I can?t possibly be against free discussions here ? even the most blue sky ones which I seldom broadcast myself ;) Cheers, -koray From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Wednesday, 7 December 2011 11:30 p.m. To: For openEHR technical discussions Subject: Re: Could YAML replace dADL as human readable AOM serialization format? Oh sigh... Trying to be open minded, thinking a few steps ahead, sharing thoughts and regularly reevaluating design decisions does not seem to be appreciated by all on this list. Perhaps we need to mark some discussions or sections with... [Warning: may contain new thoughts] ...so that those of us that enjoy such discussions may continue to have them and those that get distracted by them or can't stand them could filter out those parts. On Tue, Dec 6, 2011 at 22:23, Koray Atalag k.atalag at auckland.ac.nz wrote: Yeah I was also wondering what is the driver/motivation/aspiration behind using JSON, YAML etc. instead of good old ADL? Good old which ADL? Please go back in the thread and note the difference between dADL and cADL in the reasoning, dADL is a reinvention of the wheel (object tree serialization) cADL is an optimized DSL that I have not seen any obvious widespread alternative to if brevity and readability is sought for. Regarding the motivation you ask for, I would recommend going back in the thread again to the first message... http://www.openehr.org/mailarchives/openehr-technical/msg06186.html ...under the boldface heading Motivation:, that you may have missed, and read the three bullet points. You may not agree but that and the rest of this current message might reduce your wondering about the discussion origins. I also think that we as a community should look at getting more organised and get our efforts in tune Yes, a bit of diversity is good in order to best explore design space, but duplicating work is a waste of time. If we are allowed to discuss future-directed thoughts on this list (without people getting too upset) that may also help us tune our efforts. If we must implement first and then discuss it will be a lot harder to avoid duplication of work. as I know that quite interesting and though times are about to come? Are you referring to the CIMI-discusions or is it a general observation about how the future usually is :-) Regarding CIMI I think it is valuable to try to look upon openEHR with the eyes of newcomers. If there is unnecessary legacy in models or formats that we don't easily see because we have gotten used to it, then now is a good time to try reducing it while the amount of patient data using openEHR is limited. It will be harder to change things later. Getting the template formalism integrated with the AOM 1.5 was great in this sense, and so is?Tom's experimentation with RM 2.0 constructs that may reduce the ITEM_STRUCTURE hierarchy. From:?...?On Behalf Of Stef Verlinden +1 +/- infinity ?Yay, I love flame wars :-) On Tue, Dec 6, 2011 at 12:44, Seref Arikan?serefarikan at kurumsalteknoloji.com?wrote: Given this, if you or someone else thinks that YAML can be an alternative to dADL, there is nothing stopping anyone than implementing it and using it. Absolutely nothing. Do you assume that if somebody is talking about a subject, then they can't possibly be in the middle of implementing it and wanting to share thoughts at an early stage? Please try to be a bit more open minded, I did not ask you to be the first to implement YAML support.?You are not the the only one implementing openEHR stuff, but I will admit that you deserve credit for, and are great at release early, release often and I am not (yet). Thomas is heroically responding to all queries without judgement... I think that is an unfair description of Tom's judgment. I have a feeling that all these discussions about if this or that could replace dADL are too hypothetical. Most of the time they are academic discussions. There is nothing wrong with academic discussions, I am doing a PhD here, but if the openEHR community is spending its time and resources for academic discussions which do not necessarily connect to real life implementations in the near term, then
Questions about the relationship between Instruction, workflow and Action
Hi Sam, thanks for the answer... I'm having several hours of bad sleeping, trying to understand this :D Hi Pablo, The design principles are that the Instruction should remain unaltered by people basing actions on this instructions ? as the action and instructions could be disconnected at any moment. For example, the instruction (medication order) should not be changed by anyone just to give a medication etc. Sounds very reasonable. But I think that sometimes administrative entries could also change the state of an Instruction, like when scheduling a procedure. I asked Heather on that issue (http://omowizard.wordpress.com/2011/07/11/anatomy-of-an-procedure-action-archetype/) and her answer seems reasonable too: generaly scheduling tasks are done on external administrative systems (LIS, RIS, ...) and them a message is sent to the EHR to tell the Instruction had been scheduled. But: how is that change of the Instruction state recorded on the EHR?Receiving a message from an external system could trigger the creation of an ACTION?Is that the way you have implemented that? So the state of the instruction is carried in the record of the action (if appropriate). Is that recorded on ACTION.instruction_details.wf_details? We have decided to name the pathway steps and attach a machine readable state to that step. This makes it much easier for clinicians to model and to see what is going on. You will see an archetype ACTION in the openEHR repository and the careflow_steps are archetyped to provide a name and the current state matches an openEHR code for state. This means that a careflow step being carried out will set the state to a particular machine state. I think I saw that on the ehr_im.pdf as an example for UK GP medicaton order workflow. As I understand it, this can be done by constraining the ACTION.ism_transition attribute, with the Archetype Editor, for all the ACTIONS that will be used to execute ACTIVITIES of the medication order INSTRUCTION. If that's right (?), maybe there's a bug on the specs, because ISM_TRANSITION inherits from PATHABLE, and to be archetyped I think it should inherit from LOCATABLE (see ehr_im.pdf page 53). For the workflow definition, do you use the INSTRUCTION.wf_definition? I can't find an example on how to express a workflow there (maybe something like this could help http://doc.openerp.com/v6.0/developer/3_9_Workflow_Business_Process/index.html). In our openEHR repository we maintain an instruction index ? that is a pointer to all instructions and all actions that relate to that instruction ? and the current state of the instruction. Ok, so at an instance level, we should have all INSTRUCTION instances, the current state of each instruction, and all the ACTIONs executed for each INSTRUCTION/ACTIVITY.That is a great implementation consideration, I'll add that on the openEHR spanish course docs. :D Thanks a lot! Cheers,Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111208/d5cbedfd/attachment.html
