Did anybody implement AQL with a LL parser framework?
Hi Seref, My ADL parser does not include AQL parsing. I used Treetop, which is an Ruby implementation of PEG/Packrat parsing algorithm, not LL/LR. PEG/Packrat parser algorithm was described in this paper. http://bford.info/pub/lang/packrat-icfp02/ Antlr is an implementation of PEG parser by LL techniques. I do not know Antlr so much. Packrat parser does not need to separate scanner/parser/lexer and is capable to infinite look ahead recursive. I do not know why are you parsing AQL, but this proceeding about querying EHR by archetype might be helpful for your research. http://web-ext.u-aizu.ac.jp/labs/sw-db/7108/71080109.pdf Best regards, Shinji 2012/1/5 Seref Arikan serefarikan at kurumsalteknoloji.com: 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
Outcomes conclusions of the openEHR course in spanish ( ideas for the future)
Hi Rene, 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]. I know it will be difficult to reach consensus, but it's not impossible. Firstly, I think we (trainers) need to sit down and talk about what we think and what we want to do in/with our courses, until now I have not seen any discusions about how to standarize openEHR training and I've been in the openEHR community since 2006, and maybe this initiative could have a good outcome and be beneficial to the community. Now we see many demands of the e-health community, from openEHR software tools, to openEHR training (there is place for everyone!), and I think we need to make a smart move as a community, because these are spreading adoption opportunities for openEHR as a standard. In my case, I think a openEHR course should include the core element: the dual model (IM+AM), at an above basic level, something to help students understand the concepts and let them continue investigating after the course ending. To do so, we need to include basic tooling use (I've included the use of the AR, ADLWB and our EHRGen). Maybe that is enough for a clinical modeler profile, but for a developer is not, they need to understand what to implement in software and in wich way. For that I've created a class on how to implement openEHR in an information system, and I included two approaches: the binding approach (used by Opereffa project) and the autogeneration approach (used by the EHRGen framework). An introductory level course could leave out the tooling chapter. 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. For this community this is very difficult to evaluate, e.g. right now I think I'm the only guy doing an spanish openEHR course, and maybe I'm terrible as a trainer, but there's nobody else to compare with. Obviously, I could show the student's evaluation of my performance on the course, but I'm more concerned about giving a better course (and maybe an openEHR certification) to my students than comparing me with other trainers, since I want to collaborate with them to agree on some topics and ways of evaluation. I know that maybe this is not the way of SDOs, but I believe this should be the openEHR way. I really want to get consensus and work on this subject in 2012 with anyone who want's to collabotare to improve openEHR training. Does anyone think that a openehr-trainers mail list would be helpful to focus the discussion on those subjects? Kind regards,Pablo. 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 ___ 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/20120105/f7d9cc3d/attachment.html
pass_through attribute in ADL 1.5
Put a couple of comments on the wiki, but I think it is a thing that should be discussed on the list. In ADL 1.5 a flag 'pass_through' was added. Its definition is 'Allows nodes required for structuring data but otherwise redundant for screen display and reporting to be detected by rendering software'. So now we have a GUI directive on the ADL. Shouldn't this be a part of the reference model information (if it is never supposed to be displayed) or part of a 'visualization template' (another different level). I would say that more information about visualization will be needed, and having visualization information separated between two different places feels like a bad design move.
Did anybody implement AQL with a LL parser framework?
Thanks Shinji, In general, Antlr has some convenient features, infinite lookahead being one of them. I've quickly checked, and Treetop does not seem to support left recursion either. So you must have modified the grammar to make it work. I'm referring to grammar rules such as A : A | B; Tom made the point earlier. At one point it would be good to unify various AQL implementation experiences. I'll check out the papers. Best regards Seref On Thu, Jan 5, 2012 at 2:21 AM, Shinji KOBAYASHI skoba at moss.gr.jp wrote: Hi Seref, My ADL parser does not include AQL parsing. I used Treetop, which is an Ruby implementation of PEG/Packrat parsing algorithm, not LL/LR. PEG/Packrat parser algorithm was described in this paper. http://bford.info/pub/lang/packrat-icfp02/ Antlr is an implementation of PEG parser by LL techniques. I do not know Antlr so much. Packrat parser does not need to separate scanner/parser/lexer and is capable to infinite look ahead recursive. I do not know why are you parsing AQL, but this proceeding about querying EHR by archetype might be helpful for your research. http://web-ext.u-aizu.ac.jp/labs/sw-db/7108/71080109.pdf Best regards, Shinji 2012/1/5 Seref Arikan serefarikan at kurumsalteknoloji.com: 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 ___ 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/20120105/7ab40933/attachment.html
Did anybody implement AQL with a LL parser framework?
Hi Seref, Left recursive rule is theoretically rewrite to equivalent right recursive. In ADL grammar, cADL has left recursive rule that cannot be parsed by LL, so I converted them to right recursive rules. For example of left recursive to explain(shorten for convenience) arithmetic_expression: arithmetic_leaf | arithmetic_node arithmetic_node: arithmetic_expression '+' arithmetic_leaf |... arithmetic_leaf: (an arithmetic element) I converted this grammar to this right recursive rule. arithmetic_expression: arithmetic_leaf | arithmetic_node arithmetic_node: arithmetic_leaf '+' arithmetic_expression |... These conversions were the most tough points. I wish I could help you. Regards, Shinji 2012/1/5 Seref Arikan serefarikan at kurumsalteknoloji.com: Thanks Shinji, In general, Antlr has some convenient features, infinite lookahead being one of them. I've quickly checked, and Treetop does not seem to support left recursion either. So you must have modified the grammar to make it work. I'm referring to grammar rules such as A : A | B; Tom made the point earlier. At one point it would be good to unify various AQL implementation experiences. I'll check out the papers. Best regards Seref On Thu, Jan 5, 2012 at 2:21 AM, Shinji KOBAYASHI skoba at moss.gr.jp wrote: Hi Seref, My ADL parser does not include AQL parsing. I used Treetop, which is an Ruby implementation of PEG/Packrat parsing algorithm, not LL/LR. PEG/Packrat parser algorithm was described in this paper. http://bford.info/pub/lang/packrat-icfp02/ Antlr is an implementation of PEG parser by LL techniques. I do not know Antlr so much. Packrat parser does not need to separate scanner/parser/lexer and is capable to infinite look ahead recursive. I do not know why are you parsing AQL, but this proceeding about querying EHR by archetype might be helpful for your research. http://web-ext.u-aizu.ac.jp/labs/sw-db/7108/71080109.pdf Best regards, Shinji 2012/1/5 Seref Arikan serefarikan at kurumsalteknoloji.com: 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 ___ 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
Did anybody implement AQL with a LL parser framework?
Hi! We implemented an AQL parser using JavaCC. My colleague Mikael Nystr?m made some transformations to make the published AQL grammar work in JavaCC. Mikael is on vacation right now, but I'm sure he does not mind sharing his experiences once he gets back. I do think it would be interesting to switch to ANTLR sooner or later in order to share efforts between projects with different implementation/target-languages and because the ANTLRWorks environment http://www.antlr.org/works/index.html looks promising compared to the pretty bad JavaCC-plugin in e.g. Eclipse. Our parser (and thus also the modified grammar) will soon be open sourced so you are free to use it. So if you are not in an extreme hurry I'd suggest using or getting inspiration from what we have already done. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 On Wed, Jan 4, 2012 at 16:37, Seref Arikan serefarikan at kurumsalteknoloji.com 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. Kind regards Seref -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120105/65a8a13f/attachment.html
Did anybody implement AQL with a LL parser framework?
P.S. I leaned much from Andrew W. Appel, the chapter 3 of Modern Compiler Implementation in ML 2012/1/5 Shinji KOBAYASHI skoba at moss.gr.jp: Hi Seref, Left recursive rule is theoretically rewrite to equivalent right recursive. In ADL grammar, cADL has left recursive rule that cannot be parsed by LL, so I converted them to right recursive rules. For example of left recursive to explain(shorten for convenience) arithmetic_expression: ? arithmetic_leaf | arithmetic_node arithmetic_node: ?arithmetic_expression '+' arithmetic_leaf |... arithmetic_leaf: ?(an arithmetic element) I converted this grammar to this right recursive rule. arithmetic_expression: ? arithmetic_leaf | arithmetic_node arithmetic_node: ?arithmetic_leaf ?'+' arithmetic_expression |... These conversions were the most tough points. I wish I could help you. Regards, Shinji 2012/1/5 Seref Arikan serefarikan at kurumsalteknoloji.com: Thanks Shinji, In general, Antlr has some convenient features, infinite lookahead being one of them. I've quickly checked, and Treetop does not seem to support left recursion either. So you must have modified the grammar to make it work. I'm referring to grammar rules such as A : A | B; Tom made the point earlier. At one point it would be good to unify various AQL implementation experiences. I'll check out the papers. Best regards Seref On Thu, Jan 5, 2012 at 2:21 AM, Shinji KOBAYASHI skoba at moss.gr.jp wrote: Hi Seref, My ADL parser does not include AQL parsing. I used Treetop, which is an Ruby implementation of PEG/Packrat parsing algorithm, not LL/LR. PEG/Packrat parser algorithm was described in this paper. http://bford.info/pub/lang/packrat-icfp02/ Antlr is an implementation of PEG parser by LL techniques. I do not know Antlr so much. Packrat parser does not need to separate scanner/parser/lexer and is capable to infinite look ahead recursive. I do not know why are you parsing AQL, but this proceeding about querying EHR by archetype might be helpful for your research. http://web-ext.u-aizu.ac.jp/labs/sw-db/7108/71080109.pdf Best regards, Shinji 2012/1/5 Seref Arikan serefarikan at kurumsalteknoloji.com: 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 ___ 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
Did anybody implement AQL with a LL parser framework?
Thanks Erik, AntlrWorks is nice, but it has a problem of slowing down for some reason, even if the grammar is not that big. Appears to be a known issue, but the latest version still has this behaviour. Still beats anything else out there though. For me, ANTLR's main advantage is its infrastructure to support multiple target languages. I've used JavaCC a long time ago, and I don't think it is inferior to Antlr, though Antlr has a bit of a learning curve. I'm working on the refactoring of the existing grammar via elimination of left recursions, but my point is pretty much the same with yours; moving grammars to Antlr would help different groups develop parsers/tools easier. I've asked the original question to see if people did the actual work of eliminating recursions and basically making grammar LL compatible, and based on the responses I can see that they have. This is good news, since it means we may be able to build a community around Antlr based implementations. Good to hear that you'll be putting something out soon, I'll try to do the same ;) Regards Seref On Thu, Jan 5, 2012 at 10:12 AM, Erik Sundvall erik.sundvall at liu.se wrote: Hi! We implemented an AQL parser using JavaCC. My colleague Mikael Nystr?m made some transformations to make the published AQL grammar work in JavaCC. Mikael is on vacation right now, but I'm sure he does not mind sharing his experiences once he gets back. I do think it would be interesting to switch to ANTLR sooner or later in order to share efforts between projects with different implementation/target-languages and because the ANTLRWorks environment http://www.antlr.org/works/index.html looks promising compared to the pretty bad JavaCC-plugin in e.g. Eclipse. Our parser (and thus also the modified grammar) will soon be open sourced so you are free to use it. So if you are not in an extreme hurry I'd suggest using or getting inspiration from what we have already done. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 On Wed, Jan 4, 2012 at 16:37, Seref Arikan serefarikan at kurumsalteknoloji.com 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. Kind regards Seref ___ 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/20120105/c839f5e4/attachment.html
Did anybody implement AQL with a LL parser framework?
Thanks Shinji, The conversions are indeed though :) The problem is with the indirect/mutual recursions. Even if you deal with recursions, Anltr manages to find ambiguities, but they can be dealt with backtracking or syntactic/semantic predicates of Antlr. Maybe I should fire up a Ruby environment and see your solutions :) Regards Seref Ps: For those who have lost precious brain cells to parsers at one point in their lives, I'm still resisting the idea of going back to the dragon book... On Thu, Jan 5, 2012 at 10:05 AM, Shinji KOBAYASHI skoba at moss.gr.jp wrote: Hi Seref, Left recursive rule is theoretically rewrite to equivalent right recursive. In ADL grammar, cADL has left recursive rule that cannot be parsed by LL, so I converted them to right recursive rules. For example of left recursive to explain(shorten for convenience) arithmetic_expression: arithmetic_leaf | arithmetic_node arithmetic_node: arithmetic_expression '+' arithmetic_leaf |... arithmetic_leaf: (an arithmetic element) I converted this grammar to this right recursive rule. arithmetic_expression: arithmetic_leaf | arithmetic_node arithmetic_node: arithmetic_leaf '+' arithmetic_expression |... These conversions were the most tough points. I wish I could help you. Regards, Shinji 2012/1/5 Seref Arikan serefarikan at kurumsalteknoloji.com: Thanks Shinji, In general, Antlr has some convenient features, infinite lookahead being one of them. I've quickly checked, and Treetop does not seem to support left recursion either. So you must have modified the grammar to make it work. I'm referring to grammar rules such as A : A | B; Tom made the point earlier. At one point it would be good to unify various AQL implementation experiences. I'll check out the papers. Best regards Seref On Thu, Jan 5, 2012 at 2:21 AM, Shinji KOBAYASHI skoba at moss.gr.jp wrote: Hi Seref, My ADL parser does not include AQL parsing. I used Treetop, which is an Ruby implementation of PEG/Packrat parsing algorithm, not LL/LR. PEG/Packrat parser algorithm was described in this paper. http://bford.info/pub/lang/packrat-icfp02/ Antlr is an implementation of PEG parser by LL techniques. I do not know Antlr so much. Packrat parser does not need to separate scanner/parser/lexer and is capable to infinite look ahead recursive. I do not know why are you parsing AQL, but this proceeding about querying EHR by archetype might be helpful for your research. http://web-ext.u-aizu.ac.jp/labs/sw-db/7108/71080109.pdf Best regards, Shinji 2012/1/5 Seref Arikan serefarikan at kurumsalteknoloji.com: 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 ___ 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120105/17f73d6d/attachment.html
How is assumed value marked on domain types? (in XML)
In ADL, the assumed value of a domain type is marked like this:
defining_code matches {
[local::
at1000, -- Standing
at1001, -- Sitting
at1002, -- Reclining
at1003, -- Lying
at1014; -- Lying with tilt to left
at1001] -- assumed value
}
but in the xml form, the assumed value is missing. The schema does not
reflect this (I know it is outdated)
children xsi:type=C_CODE_PHRASE
rm_type_nameCODE_PHRASE/rm_type_name
occurrences
lower_includedtrue/lower_included
upper_includedtrue/upper_included
lower_unboundedfalse/lower_unbounded
upper_unboundedfalse/upper_unbounded
lower0/lower
upper1/upper
/occurrences
node_idat0009/node_id
terminology_id
valuelocal/value
/terminology_id
code_listat1000/code_list
code_listat1001/code_list
code_listat1002/code_list
code_listat1003/code_list
code_listat1014/code_list
/children
Can we reach a quick consensus on how should this be stated? Can we
use an assumed_value label as in all other types?
Outcomes conclusions of the openEHR course in spanish ( ideas for the future)
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120105/52e1ac6f/attachment.html
Outcomes conclusions of the openEHR course in spanish ( ideas for the future)
Hi Pablo, I think we could probably agree the core training requirements quite quickly but the real problem is how any certification process could be policed and funded. Who trains the trainers, who checks that they are delivering the core content? In Ocean we certainly have a set of core training materials but these are adapted and amended for every specific customer - the requirements for a clinical audience is somewhat different from a technical audience or mixed audience and time avaialble differs half-day, one day, three day?? ... and again for a vendor client vs. a national organisation. If we have 'certified training', to what extent does that prevent us from adapting content for specific clients and circumstances - I know this is the case for some UK training certification processes. it is one thing to specify the core requirements but quite another to ensure that these are being properly adhered to. I think the only suggestion I would have for your tool chain diagram is that with ADL1.5 I think we will have the same tool for archetypes and semantic templates i.e non-GUI. We will also need mapping tools for mesage integration and requirements integration and an AQL editing tool. Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation ?www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care ?www.phcsg.org On 5 January 2012 15:38, pablo pazos pazospablo at hotmail.com wrote: Hi Shinji, I think (hope) that trainers could discuss and agree on the core topics of an standard openEHR course, and then create an upper level layer to localize this core topics to the student's profile and the depth level (basic, intermediate, advanced) required by each course. Maybe I'm oversimplifying something really hard to do, but why not give this a chance? IMO having a specific place to discuss training related topics is the very first step to reach consensus. I'd like to discuss tool chains too! Maybe we can agree on general concepts and implement them on different technologies, that would be the best proof that the openEHR approach works and that doesn't matter what technology do you like. I've a very basic requirement list on each tool mentioned on my blog post diagram (http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png). I've not included datawarehousing tools, but they should be part of the ecosystem too. -- 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: Wed, 4 Jan 2012 23:23:19 +0900 Subject: Re: Outcomes conclusions of the openEHR course in spanish ( ideas for the future) From: skoba at moss.gr.jp To: openehr-clinical at openehr.org CC: openehr-implementers at openehr.org; openehr-technical at openehr.org 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 pazospablo at hotmail.com: 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
Outcomes conclusions of the openEHR course in spanish ( ideas for the future)
openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- 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/20120105/f3716c50/attachment.html
Outcomes conclusions of the openEHR course in spanish ( ideas for the future)
Hi everyone! I've updated my post adding the students evaluation of the course: http://informatica-medica.blogspot.com/2012/01/conclusiones-del-curso-de-openehr-en.htmlFor being the first edition, the evaluation was quite positive. But we still have a lot of things to improve! -- 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 From: pazospa...@hotmail.com To: openehr-clinical at openehr.org; openehr-technical at openehr.org; openehr-implementers at openehr.org Subject: Outcomes conclusions of the openEHR course in spanish ( ideas for the future) Date: Tue, 3 Jan 2012 18:14:41 -0300 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-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/20120105/9bd61c04/attachment.html
