Outcomes & conclusions of the openEHR course in spanish (& ideas for the future)
Hi Pablo, and all I perfectly agree your idea. I have thought as you mentioned. I am planning my tool-chains on my Ruby implementation, too. Certification criteria are very difficult to evaluate. Training course would be a homework to localize. Shinji Kobayashi 2012/1/4 pablo pazos : > Hi everyone, > > Recently we have ended the first edition of the course with a huge success. > And now we are thinking about the next steps to take. > > Here is a post on my blog about the conclusions and future > actions:?http://informatica-medica.blogspot.com/2012/01/conclusiones-del-curso-de-openehr-en.html > (yo can see it in english by clicking ENGLISH on the top right corner of the > blog). > > > I want to share with the community a couple of ideas mentioned there. It > would be very nice to know what you think. > > openEHR certification: > > The first idea is on standarizing openEHR training, and to think about an > openEHR certification. I think this could be very good for the community and > for the openEHR organization too. > > It could be possible to create a mail list for openEHR trainers > (openehr-trainers at openehr.org)? So we could discuss about the topics and > ways of evaluation, and come out with an standard minimal program to all > openEHR courses. > > If we reach a standard minimal program for openEHR courses, could we get > formal support from openEHR.org to issue internationally valid openEHR > certificates? (obviously this is a question for the future, but IMO we need > to start thinking about it now). > > > 10 projects to adopt openEHR: > > We thought about 10 projects (or so) in two areas: software and clinical > modeling. > > Because openEHR propose a tool-chain based process of creating EHRs, we need > to have each one of the links of that chain in order to adopt and implement > openEHR easily. > > Now there is a little tooling available, and some of it is not open source. > In projects at a national level we need to use open source software, because > each country will need to make it's own customizations to each tool. > > In the other hand, we need to model other things that are clinical knowledge > too, like processes and rules to enable CDS, in order to support full EHR > implementation (e.g. I think we could recommend ways to express rules based > on archetype ids and paths, and create software tools to support that > specification, but we need to work the openEHR services specs first). > > There is a diagram on my blog post that shows the tools we propose to 1. > develope if there is no tool that support its functionality or it's > closed-source, 2. improve the current open source tools. > > On the clinical modeling side, we have engaged doctors and nurses on the > creation and translation of archetypes. Now there are two of our students > that already commited archetypes to the CKM: Dr. Domingo Liotta and Dr. > Leonardo Der Jachadurian. > > I hope we could propose to create prototypes of those projects in out local > universities and coordinate the projects so we do not overlap each other, > with the objective of completing the tool chain with open source > developments. > > > > What do you think? > > > -- > 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 > > ___ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
open source openEHR-related EHR systems; How do you want to be cited...
Hi! Thanks for nice replies, hints and suggestions regarding open source archetype based EHR systems. Is any relevant open source project left out, misquoted or misunderstood in the following formulation: ...and several open source alternatives that explore different approaches > to implement archetype based EHR systems are available. Examples > (programming language in parenthesis) are: > ? EHRflex [EHRflex], http://ehrflex.sourceforge.net/ (Java) > ? GastrOS [GastrOS], http://sourceforge.net/projects/gastros/(.NET+C#) > ? openEHRgen, > http://code.google.com/p/open-ehr-gen-framework/(Groovy+Java) > ? Opereffa, http://opereffa.chime.ucl.ac.uk/ (Java) > Also, implementations in Ruby [oe-ruby], > http://openehr.jp/projects/show/ref-impl-ruby, and Python [oship] > http://www.oship.org/ provide components for archetype-based EHR systems. With a reference list along the lines of: >- [EHRflex] Anton Brass, David Moner, Claudia Hildebrand, Montserrat >Robles Standardized and flexible health data Management with an archetype >driven EHR system (EHRflex). EFMI Special Topic Conference 2010 Seamless >care ? Safe care: The Challenges of Interoperability and Patient Safety in >Health Care. Proceedings of the EFMI Special Topic Conference, pp. 212-218. >IOS Press BV, Amsterdam. ISBN: 978-1-60750-562-4, 2010. >- [GastrOS] Atalag K, Yang HY, Tempero E, Warren J. Model Driven >Development of Clinical Information Systems using openEHR. Stud Health >Technol Inform 2011;169:849-853. >- [oe-ruby] Shinji Kobayashi and Akimichi Tatsukawa. Ruby >Implementation of the openEHR specifications. Journal of Advanced >Computational Intelligence and Intelligent Informatics, in press >- [oship] Luciana T Cavalini and Timothy W. Cook. Health Informatics: >The Relevance of Open Source and Multilevel Modeling. Proceedings of Open >Source Systems: Grounding Research (OSS 2011) Pages 338-347. Springer 2011 > > Please report any misunderstandings or comments to me or to the list. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 On Thu, Dec 8, 2011 at 10:02, Erik Sundvall wrote: > 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! -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120104/a08a9462/attachment.html>
Did anybody implement AQL with a LL parser framework?
So has AQL been selected as the official openEHR query language? 2012/1/4 Seref Arikan : > Greetings, > The AQL grammar from the wiki has direct and indirect left recursion. Which > means without changes in the grammar, LL parser generators (both JavaCC and > Anltr) can't generate parsers for this grammar. > > I'm curious if anybody has refactored this grammar for LL parser generators. > Shinji? Your latest release includes an AQL parser does not it? Could you > please share your method? I can always look at the code, but you'd probably > save me time :) > > I'm interested in experiences of others too. > > > Kind regards > Seref > > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
Did anybody implement AQL with a LL parser framework?
On 04/01/2012 15:54, Diego Bosc? wrote: > So has AQL been selected as the official openEHR query language? not officially. It has been implemented in at least 2 production systems (it may be 3), so we know it 'works'. But at least from my point of view, and I am sure the primary developers (Chunlan Ma, Heath Frankel) would agree - it can only benefit from wider inspection and testing by the community. I would suggest that the current AQL spec can be considered to be in a 'trial' state now. There is also a very good piece of work called a-path which Zilics did in Brazil a few years ago, and I think that should be integrated into ADL 1.5 (rules section) and probably also AQL. There are others thinking about an expanded AQL, with the equivalent of schema definition operations of SQL as well. Once the current specification governance has been clarified, I suggest that the current AQL spec be declared 'trial' just so we have something solid to work with, and then a Query project group be set up to consolidate work on a next generation AQL. - thomas
Did anybody implement AQL with a LL parser framework?
Antlr is LL(*), but LL can't handle direct/indirect recursion, which is a matter of grammar rules. Direct recursion is easier to handle, but indirect recursion makes my head hurt :) On Wed, Jan 4, 2012 at 4:02 PM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > On 04/01/2012 15:37, Seref Arikan wrote: > > Greetings, > > The AQL grammar from the wiki has direct and indirect left recursion. > > Which means without changes in the grammar, LL parser generators (both > > JavaCC and Anltr) can't generate parsers for this grammar. > > > > I'm curious if anybody has refactored this grammar for LL parser > > generators. Shinji? Your latest release includes an AQL parser does > > not it? Could you please share your method? I can always look at the > > code, but you'd probably save me time :) > > > > I'm interested in experiences of others too. > > there is no guarantee that the current grammar is the best one, and in > my view, a better grammar could be developed. We just need to make sure > it deals with the typical queries we write, and ones that are already > written (or at least that the latter could safely be translated). > > Other thing to keep in mind: many non-LL grammars are probably > computable as LL grammars with sufficient tokens of lookahead. > > - 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/20120104/06d0c6c7/attachment.html>
Did anybody implement AQL with a LL parser framework?
On 04/01/2012 15:37, Seref Arikan wrote: > Greetings, > The AQL grammar from the wiki has direct and indirect left recursion. > Which means without changes in the grammar, LL parser generators (both > JavaCC and Anltr) can't generate parsers for this grammar. > > I'm curious if anybody has refactored this grammar for LL parser > generators. Shinji? Your latest release includes an AQL parser does > not it? Could you please share your method? I can always look at the > code, but you'd probably save me time :) > > I'm interested in experiences of others too. there is no guarantee that the current grammar is the best one, and in my view, a better grammar could be developed. We just need to make sure it deals with the typical queries we write, and ones that are already written (or at least that the latter could safely be translated). Other thing to keep in mind: many non-LL grammars are probably computable as LL grammars with sufficient tokens of lookahead. - thomas
Reference Model based application development - RIMBAA March 8 in Gothenburg
The location and date of the Reference Model based implementers meeting (HL7 RIMBAA) have been confirmed: ** March 8, 2012, RIMBAA, in Gothenburg, Sweden Core topic: software implementation aspects of Refence Model based applications, focusing on both the 13606/OpenEHR RM as well as the HL7 RIM. Sweden has opted to use 13606/OpenEHR as the base standards for its national infrastructure, which means there should be lots of opportunities to discuss RM based implementation issues at this venue. Draft agenda: http://wiki.hl7.org/index.php?title=RIMBAA_201203_Agenda Please register at the bottom of that wiki page should you plan to attend, or send me an e-mail. This e-mail just serves to announce the data and location (thanks to Mikael Wintell, VG Region, for sponsoring the venue) - I'll get back to this list to announce a more detailed agenda, and to request speakers from amongst the Swedish [and other European countries] 13606/OpenEHR implementer community to speak to the 'implementation lessons learned' and the 'architectural approaches chosen'. With best regards, -Rene -- Rene Spronk Cell: +31 (0)655 363 446 Senior ConsultantFax: +31 (0)318 548 090 Ringholm bv The Netherlands http://www.ringholm.com mailto:Rene.Spronk at ringholm.com twitter:@Ringholmskype:rene_ringholm Ringholm is registered at the Amsterdam KvK reg.# 30155695 Ringholm bv - Making Standards Work - Courses and consulting
Did anybody implement AQL with a LL parser framework?
Greetings, The AQL grammar from the wiki has direct and indirect left recursion. Which means without changes in the grammar, LL parser generators (both JavaCC and Anltr) can't generate parsers for this grammar. I'm curious if anybody has refactored this grammar for LL parser generators. Shinji? Your latest release includes an AQL parser does not it? Could you please share your method? I can always look at the code, but you'd probably save me time :) I'm interested in experiences of others too. Kind regards Seref -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120104/e9263f32/attachment.html>
Outcomes & conclusions of the openEHR course in spanish (& ideas for the future)
Hi Pablo, > The first idea is on standarizing openEHR training, and to think about > an openEHR certification. I think this could be very good for the > community and for the openEHR organization too. > If we reach a standard minimal program for openEHR courses ... From experiences with an another standard (HL7) based training courses I'd say it may be hard to reach consensus as to what the minimum should be - there is a fair amount of difference between various countries, as well as how one structures a (set of) training courses [e.g. 1 long one, an introductory and an advanced], and the target audience [e.g. clinical, hardcore programmers without any clinical knowledge]. In general the most useful thing for all concerned is probably for the standards organization to make a statement like "we know that trainer X provides good quality training courses" [this aids the trainer in selling the training course, it aids the prospective attendee as a statement of quality, and it aids the standardization body because it has a known list of educators it can refer to]. Determining who provides a good quality training course may not always be that easy to quantify, but in these relatively small standardization communities (whether openEHR, HL7, DICOM, IHE, etcetera) the nomination for approval can be backed up / seconded (or the reverse: "thumbed down") by other known active volunteers. TTYL, -Rene -- Rene Spronk Cell: +31 (0)655 363 446 Senior ConsultantFax: +31 (0)318 548 090 Ringholm bv The Netherlands http://www.ringholm.com mailto:Rene.Spronk at ringholm.com twitter:@Ringholmskype:rene_ringholm Ringholm is registered at the Amsterdam KvK reg.# 30155695 Ringholm bv - Making Standards Work - Courses and consulting
Does XMLSerializer (java) create archetype slots with too much extra information?
Hi Diego
This was the result of some overzealous efforts in the past (designed to
make XML look verbose :-). The discussion has been about the fact that
Occurrences does not need an includelower/upper and unbounded is not
necessary as it can never be a constraint statement.
The expression is new to me...
Sam
> -Original Message-
> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
> bounces at openehr.org] On Behalf Of Diego Bosc?
> Sent: Wednesday, 4 January 2012 1:18 AM
> To: For openEHR technical discussions
> Subject: Does XMLSerializer (java) create archetype slots with too much
> extra information?
>
> This is a simple question: Why does a simple archetype slot like this
> (ADL)
>
> allow_archetype ELEMENT[at0001] occurrences matches {0..*} matches {
> -- Archetype slot
> include
> archetype_id/value matches {/.*/}
> }
>
> ends up like this?
>
>
> ELEMENT
>
> true
> false
> false
> true
> 0
>
> at0001
>
>
> archetype_id/value matches
> {/.*/}
>
> BOOLEAN
> 2007
> false
>
> STRING
> archetype_id/value
> CONSTANT
>
>
> String
>
> .*
>
> CONSTANT
>
>
>
>
> I'm not complaining about the ultra-verbose occurrences (surely can be
> improved, but there was already a discussion about this on this
> mailing list).
> I don't get the point of putting the 'expression' tags on this case.
> It's like putting the same thing twice.
> Is the 'operator' tag supposed to be understandable?
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
