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.