On 29/10/2010 17:18, pablo pazos wrote:
> Hi Thomas,
>
> My opinion is the grade of adoption of a standard depend in some aspects of
goverment agencies, in some of the industry and some of the academy.
>
> DICOM is a good example of an open standard heavily supported by the
industry, that's the point of it success. Can't be OpenEHR a de-facto standard
for EHRs? Like DICOM is for imaging. I think yes, but the progress of OpenEHR
to solve real the problems and make it usable, is slow.
>
> I think OpenEHR is strong on the academy area. It has poor industry
penetration (I mean enterprises developing tools and aplying a good part of
the OpenEHR specification in their systems, and that these systems where used
in some hospitals). I don't know what's the penetration of OpenEHR on
goverment agencies. There are some open tools but there is some stillness on
making improvements on them.
>
>
> For example, here in Latin America, almost nobody knows about OpenEHR in the
industry area, and very very few knows about it in the academy area.
>
> There are some ideas that may help de difusion and adoption of OpenEHR:
>
> - I think that regional OpenEHR communities are needed to empower the
adoption and spreading of the standard. In 2009 I send a message to the
mailing lists, but I get no answer from the community (this mail is below).
Now we have 36 members from Uruguay, Argentina, Chile, Colombia, Spain, and
more. They work on goverment agencies, big enterprises (like IBM), developers
and physicians. I think the international OpenEHR community needs to support
these regional communities, providing guidelines, general objectives, and
following their work. Here in South America, only few people know about
OpenEHR, that's a shame. People in goverment are making decissions, without
knowing that are good and open standards out there.
>
> - Formal training and education in OpenEHR is needed. It's very hard to the
newcomer to understand how to use OpenEHR, and people interested on the main
ideas of OpenEHR may be dissapointed when they try to use it in a real-world
software application. People in the industry must be trained, but how many
OpenEHR trainers are out there?
not enough yet ;-)
But there are two things that will improve the situation:
* with the arrival of better, more open tooling for templates and
operational templates, and downstream transformations, much of the need to
understand the mechanics of openEHR goes away; software developers can use the
generated products, which could be openEHR XSDs, or even HL7v2 message
definitions.
* in the future we would aim for more web-available self learning material
>
> In Set-2010 I've done a hands-on OpenEHR tutorial in Argentina, and people
(medics and TIC people) where amazed about building their archetypes and
having a tool that generates the EHR (this is my degree project). This was
done in the context of the "Argentine Congress of informatics and Health
2010". Now, the organizers want to make more time to discuss OpenEHR and its
posibilities. This is just an example that great things can happen if someone
has interest.
>
> Regional OpenEHR communities can build courses fucused on the regional
needs, may be made some money to support the open tool development (*).
this is the key; to get the money, authorities need to be convinced it is a)
going to do what they need and b) not going to isolate them. They are very
scared of the second, even though it is not rational (since most of the
standards in their comfort zone really don't work that well, and not at all
together).
>
> - Building and supporting open tools. The current tools have no regular
updates. We need developers to build new tools and improve the current tools.
We can use the money of the training courses (*) to pay developers to do this
job. If this depends only on the free time we have, tools just can die before
they are implemented.
actually, the ADL workbench and Archetype Editor are constantly being updated.
However, I only just realised that the link for the latter is not visible. I
will look into this.
>
> - In order to help any goverment adoption of OpenEHR, the decission makers
have some questions that today OpenEHR can't answer.
> - What is the state of the standard?
> - Is it stable?
> - Wich parts are stable?
should be fairly clear from the release page,
http://www.openehr.org/releases/1.0.2/roadmap.html
> - Is there any return of investment study done on efective use of OpenEHR?
that's a harder question ;-)
> - Or just, how much time and money I have to spend to effectively use
OpenEHR in a real world application? (I have to train people to make things
happen, not in an investigation project, but in a production project)
> - What real world products are using OpenEHR?
> - How these products are using OpenEHR? (they adopt the RM? the AOM? the
> SM?)
>
> There is page on "who is using OpenEHR" in the portal, but it is outdated.
My proposal is to do regular polls on the community in order to know: who is
working on what, and how they're using OpenEHR.
more up to date information would be good, however the information there is
not more than about 18months out of date, and in some cases more recent.
However, there is much activity that has no entry at all in these pages - it
would be good to obtain information on that.
>
> - Formal links with "formal" SDOs are needed. I think that OMG is in tune
with the way OpenEHR do things. They have the COAS standard, and OpenEHR RM is
mapped to COAS. This is a good starting point to have something in common.
in fact, there are ongoing talks with IHTSDO about close cooperation and
development. Making someting happen in the 'official' standards space is the
key. Currently, many governments have been too scared to go away from the
official standards, even though they have had little success with them
>
> I think there are very good posibilities in the OpenEHR adoption on the
industry adn goverment areas, but we need to build improve the lines of action
of the community to reach that.
>
agree.
- thomas
>
> Just my humble opinions.
> Best regards,
> - Pablo.
--
Thomas Beale
Chief Technology Officer Ocean Informatics
