Hi Ian, > 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? I think we could break down the problem into certification for students (what they have learned) and certification for trainers (who is validated by the foundation to give quality courses). E.g. a not certificated trainer could make a course for students to study for the certification evaluation, and if they pass, they receive a certification (as students). What is certified here is the evaluation process, not the course itself. The course and the evaluation could be different things, like in english courses (here we pay for a course, and if we want the certificate, we pay for the exam). Obviously, a course given by a certified trainer could be more costly than a course given by a not-certified trainer, but students from both courses could be certified because de evaluation process is the same, and is supported by openEHR.org. I totally agree that certification processes should have a fee for the foundation, but I think the current funding model should change in order to do that (I participated in a discussion not so long ago where we discuss about funding and governance http://www.openehr.org/wiki/display/oecom/Community+Governance).
> 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. About the tool chain, I've joined archetype and template editors (semantic/structural artifacts), looking forward the new specs, and there is another tool for GUI template edition.I totally agree with the inclusion of AQL/a-path/other querying mechanisms/formalisms and message tools should be included on the chain. Kind regards,Pablo. > > 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/AAAAAAAAE-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 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 > >> > >> _______________________________________________ > >> openEHR-clinical mailing list > >> openEHR-clinical at openehr.org > >> 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 > > _______________________________________________ > 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/20120106/d507a4cd/attachment.html>
