Yes - there must be some kind of misunderstanding. The intention have never been that end-user should do the important and challenging work on developing clinicial information models (archetypes). The idea have been that this gives the clinical community an opportunity to influent and co-operate in this work.
I think all agree that the development and deployment of ICT solutions for healthcare is a large socio-organizational-technical challenge. The work done by domain experts is only a (important and essential) part of that problem domain. Best regards Bjørn Næss Product owner DIPS ASA Mobil +47 93 43 29 10<tel:+47%2093%2043%2029%2010> Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På vegne av Thomas Beale Sendt: fredag 11. mars 2016 15.16 Til: openehr-clini...@lists.openehr.org; Openehr-Technical <openehr-technical@lists.openehr.org> Emne: Re: Socio-technical challenges when the openEHR approach is put to use in Norwegian hospitals I can only see the abstract for now, but I think the authors seem to have developed the misconception that end-users would somehow be designing applications. openEHR doesn't try to do that, and it's the first time I've heard anyone suggest it. openEHR just enables domain experts (generally = a small proportion of healthcare professionals, who might also be some kind of system user in some part of the world) to more directly define the information content of the system, in such a way that it can be processed and queried on a semantic level. The Business Purpose of Archetypes section in the Archetype Technology Overview <http://www.openehr.org/releases/AM/latest/docs/Overview/Overview.html#_business_purpose_of_archetypes> may help to show why this is useful and necessary (it's short!). There are still many other problems to solve such as clinical workflows and user interaction / UX. I am currently at Intermountain Health in Salt Lake City working with the Activity Based Design (ABD) group that has developed a new architecture that I think has a realistic chance of addressing a) workflow (e.g. typical nursing tasks like cannulation; more complex cooperative workflows that involve shared care) and b) some aspects of UI interaction within workflows. They are just at an early prototype stage, and it has taken nearly 2 years to get to the current architecture (naturally taking into account many previous attempts and experience). This effort is the first I have seen that has what I think may be the needed theoretical understanding and technical architecture to starting to solve clinical process and (some of) UI/UX. And what does it rely on? Formal clinical models, and it assumes that those models are created by clinical experts. Not only that, it explicitly assumes a 'template' concept of the same kind as openEHR's, in order to construct useful data sets. It considers these 'templates' as the basis of an 'Activity' description, which then adds new abilities to blend in some presentation directives, pre- and post-conditions, some workflow elements, cost-related items (e.g. ICD coding) and so on. The innovation here is to consider an Activity a unit of clinical work and to attach these process-related semantics into that level of artefact. So let's just reflect on the fact that this research is only now emerging from one of the leading institutions in the world that has historically specialised in workflow and decision support. openEHR as it is today is just a semantic content + querying platform, and I think we can reasonably say that we have some handle on generating developer-usable artefacts, i.e. things like TDS, TDO etc, but they are all content related. These are starting to be standardised now. The openEHR of today needs to leverage new work such as ABD (or something like it) to achieve many of the things that the Norwegian paper talks about. The paper seems to be critiquing a somewhat unrealistic set of expectations re: openEHR, although I am sure it has useful lessons. I'll provide a proper description of ABD ASAP, which I think will provide our community (particularly those working on clinical workflow, process etc) new ideas on 'the next layer' for openEHR. - thomas On 09/03/2016 23:58, Bakke, Silje Ljosland wrote: Hi everyone! As some of you may have noticed, a paper called "Evaluating Model-Driven Development for large-scale EHRs through the openEHR approach" (http://www.sciencedirect.com/science/article/pii/S1386505616300247) was recently published by a PhD student at the University of Tromsø. The paper has some pretty direct criticism of the ideal of wide clinical engagement in widely reusable information models, as well as the clear division between the clinical and the technical domain inherent in the openEHR model. I think a lot of the observations detailed in the paper are probably correct, for its limited scope (one Norwegian region and 4 years of observation, half of which was done before the national governance was established). We'll probably use the paper as a learning point to improve our national governance model, and I'd like to hear any international (and domestic Norwegian for that matter) takes on the implications of the paper. Kind regards, Silje Ljosland Bakke Information Architect, RN Coordinator, National Editorial Board for Archetypes National ICT Norway Co-lead, Clinical Models Program openEHR Foundation Tel. +47 40203298 Web: http://arketyper.no / Twitter: @arketyper_no<https://twitter.com/arketyper_no> _______________________________________________ openEHR-clinical mailing list openehr-clini...@lists.openehr.org<mailto:openehr-clini...@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org --
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
