Dear Tony,
I do not usually post here but I do read every email.
(NB Long+ email to follow...
Yep, it took me more than a week to tackle even reading it. 
Dare I
say it is well worth the read. There are several in-line comments and I
hope that they are worthy of the original email. The parts I have
snipped are no less important, just not germane to my
position/offerings.
(dare I say this may be easier to print and
digest)... the bottom line of which is that I believe the key answer to
Stefs question may require an open source clinical reference
application, as an important next step for the openEHR clinical community)
I agree.
We have been through a set of requirements workshops, done the
archetyping and templating, but what I do not have is an openEHR
compliant application to trial/use them in, so I'm unable to refine the
archetypes in any rapid prototyping way..
I also agree with this. However, I'd also like to point out that there
are literally thousands of clinical situations that need applications
and there is no one size fits all. A user wants something that does
what they need it to do; do it easily without a lot of other things in
the way. All the way from one off research projects to enterprise level
systems. We should be capturing all that data in a standardized manner,
for many reasons that everyone here already knows.
**The current health IT market
You might ask what about our existing/current suppliers in the UK. At
present while some are working to explore the potential of openEHR, none
have archetype enabled architectures and all will take some considerable
time (likely years) to change.
Very true. They need a competitive driver.
At the same time, despite championing openEHR for a couple of years now,
I have not yet seen an archetype based solution with a user interface
(UI) that would be fit for my purposes in my own hospital based
environment, which makes it somewhat difficult to champion openEHR wider
afield..
Again, the huge volume of needs vs. the impetus to provide them.
**The role of openEHR
openEHR clearly has the potential have a very significant and positive
impact on international health IT developments.
For me some of the key strengths of archetypes include the transfer of
(some) control to the clinical community, the fit with the complexity of
modern healthcare and the ability to share and reuse clinical content to
help with real savings of time and money.
Probably the top reason. But as you point out below; education is key.
Note that I didnt put semantic interoperability at the top of the list.
Of course I'm aware of the potential for archetypes to help solve the
semantic interoperability challenge.. but I do not think it is the sole
advantage that we should be pursuing. Nor do I think we can achieve
semantic interability in one move.
Not at all. We have major legacy systems to deal with and they will be
around for 15-20 years minimum. That DOES NOT mean that we can't start
small (think small office and research projects) to prove the case.
Re: 4)
**The need for better international governance of openEHR (archetypes et al)
This is a big topic and one that generates much discussion, and is at
the core of Stef's question.
<rant>
I won't go into this too far but it is a big frustration for me (so
standby for some ranting) as a developer of a system to go to the
website SVN and see all those draft ADL files and if I go to
archetypes/release ... nada, nothing; not one approved archetype. What
am I supposed to build an application on? So where is the CRB?
http://www.openehr.org/about/crb.html The CKM is a cool idea but (at
least on Firefox/Linux there is nothing there.
There has been an Architecture Review Board
http://www.openehr.org/about/arb.html in place for nearly five years
that on an international basis has managed to bring to you a very stable
reference model. Sometimes working on difficult and contentious issues,
using the proper tools to manage the process. I am certain that there
are people that will teach the CRB how this can be done if the clinical
community will step up to the plate. You want your applications? Then
join in the fight. </rant>
Another formal route for clinical governance/assurance may involve
linkage with more traditional Standards Development Organisations
(SDOs). David Ingram has announced to the list that discussions are
progressing with International Health Terminology Standards Development
Organisation (IHTSDO) and openHealthTools (OHT),
This can be very important not only from a knowledge perspective but a
publicity one as well.
While I am very familar with the pros and cons of a national ehealth
programme to coordinate clinical governance, I am wary of relying on any
international body to solve all our problems for us from the top down.
As you know things move very slowly at that level and are not usually
able to keep pace with developments on the ground.
In addition designing the perfect set of archetypes via international
mailing lists/committee is not the ideal/only approach that should be
pursued...
Again, there are tools and established processes. You do not have to
invent new ones. Maybe tweek the old ones here and there but you can
get started.
Re 2& 3
**What about "homegrown" archetypes- the wisdom of the crowds?
GREAT! They can be incorporated into the process.
I'll repeat I do not believe we can design archetypes
completely by committee, they must evolve from real time use and
learning as with many things the greatest innovation and learning will
come from real life experience.
True. But you do have to give someone something to start with so they
can offer feedback.
We also need to bear in mind the 80:20 principle, aiming
for "good enough" design and regular iterative development rather than
anything like perfection.
True.
Re 3)
**Tooling & the case for an open source openEHR clinical application to
support both top-down and bottom-up development.
So there is in my mind an increasingly strong case for a grassroots
movement that develops a clinical "reference" application i.e. can
support clinical care, that is openEHR based.
How about a platform instead of ONE application?
*The need to focus this on the UI challenge for clinical engagement
A user interface focussed openEHR project would provide several
advantages, including the real-time review of archetypes developed to
date and the development and refinement of ideal/varied UIs needed to
ensure ease of use for clinicians who want to use openEHR.
I also believe that it is difficult to seperate the layers of archetype
& template design from the UI layer, as they are much more closely
linked that most people realise.
Absolutely.
Clearly there is a variety of important clinical requirements that need
to be defined to provide a useful clinical application (inc. terminology
and messaging requirements that must be addressed in due course) but
lets look at those in stages.
Almost without exception, the very first archetype you use you will need
a terminology at some level.
My initial need is for a tool that allows me to capture the patients
history and examination findings for 80% of those who attend my ED, as I
was taught in med school, i.e not addressing 99/100% of my needs, but
something that is useful more often than not..
Note that I am not advocating the build of an open source HIS (though I
think there is merit in that too, see PatientOS), but to begin with a
very discrete application ("widget" if you like) that begins to support
the routine clinical documentation that I was taught at medical school.
As I pointed out above. Small niche applications are the best place to
start. Especially using open source.
*Again, the need to focus on clinical usability requirements
I know I share this need for ease of use with many many clinicians.
There are a number of key requirements (ease of navigation, ease of data
entry/data review, etc) that I am happy to elucidate & coordinate at a
later stage, but I hope some of you will understand what I'm suggesting....
As many frustated clinicians have developed their own homegrown database
Access/Filemaker solutions, I think openEHR could/should explore the
development of a solution that meet their needs too, as I think there
would be a large amount of international interest in such a solution.
(NB Regarding priority no 5.. Decision Support.. this needs to be
factored in as one of those requirements...albeit perhaps long term)
Your "key requirements" above are truly key. Now, who better knows
those requirements than the users themselves. As a side note; in my
previous experience with clinicians this is such an individual set of
requirements that it will drive developers crazy.
*The cons/threats of this suggestion?
Some of you will parry that openEHR should not be about providing an
open source application and any move in this direction would put us in
danger from the commercial world.
No problem. The open source world is very familiar with being "under
threat" (but not in danger) from the commercial interests.
Others will be concerned about the security challenges of such a solution.
Long fought idea. Many case studies prove otherwise.
Others still may suggest that someone else needs to do this.. (*e.g. the
NHS, other national programmes, the vendors etc) . I think all of these
could contribute to and be a part of the solution, but I do not suggest
we wait for their agreement before proceeding.
I agree we shouldn't wait. But some of us independents could use a
little funding here and there since they will be the ones benefiting the
most.
*Maybe this isnt the right time/Why now/What are we waiting for?
Simply put I do not suggest waiting for others to solve my/our
challenges. I suggest we get on with it. I'm happy to get on with
helping to focus the initial clinical requirements of such a solution
(I'd already suggest generic medical documentation/medical school
clerking may be a very good starting point.) This is not quite a call
to arms just yet.. though I feel myself moving in that direction.
In addition to my above rant about the ARB I WILL issue a call to arms
NOW!. Please allow me to explain.
Within 2-4 weeks I will be releasing the Python reference implementation
of the openEHR reference model. This is not just the RM itself, it is
built upon a complete application server framework. All of the
components are licensed under business friendly licenses so you can also
build commercial applications if you wish. We will in the near future
we plan to be adding APIs for Google Health (a CCR subset) and
Microsoft Health Vault (I think another CCR subset). If you need, you
can also use the full CCR and CCD schemas if you purchase their
licenses. In order to communicate with other services.
You can read a bit about the Open Source Health Information Platform
(OSHIP) here: http://www.openehr.org/wiki/display/dev/OSHIP+Developer%
27s+Wiki as usual, wikis are sometimes a little slow to be update so I
do not guarantee all the info there is perfect at this point.
Some more pragmatic stats about the project can be seen on Ohloh.net
http://www.ohloh.net/p/oship they use automated analysis routines to
examine the code. The first interesting thing is scroll down to the
Project Cost box on the right side. At the suggested rate of $55,000/yr
for developers the total cost is estimated at over $2.7M US. That
includes all of the documentation that Tom Beale and others have put
together. If you want to see the real cost of code development (98%
myself) then you can select Code Only from the pulldown. It's just over
$117,000 US. Funded by yours truly. Another interesting link is about
code quality and you can find that on the left side as "Code Analysis".
But this doesn't tell the whole story. Because remember that open
source is about re-use of quality products. You also need to checkout:
http://www.ohloh.net/p/zope3 and http://www.ohloh.net/p/grok in order
to fully appreciate what you get when you use OSHIP.
So my point is that there is an openEHR development environment just
around the corner. It is a development environment though, not a
specific application. My thoughts are that this puts us in a much
better place than one or two reference apps.
What's needed to build an application? Well, the openEHR Template
Object Model isn't ready for prime time yet. When it is; we plan to
incorporate it. Right now we use HTML pages and a special data template
language called TAL. Generally the users mock-up their user interface
in HTML and Python developers add the required data element calls in an
XML type markup so that the HTML can be edited by the user again if
required.
***SO MY CHALLENGE TO THE openEHR Clinical Community***
If you want your UIs the way you want them; then send me (via email)
some HTML with your entire page layout or just one archetype. In the
email explain which archetypes you used. BTW: All required elements
from the reference model are not included in the ADL. Therefore you will
have to look them up in hte documetation for the classes you are using
so you'll know what has to go on the page. But on the implmenters
mailing list Tom Beale JUST announced that within 2 weeks he'll have
the Archetype Workbench displaying those attributes. YEAH Tom!
As a caution though. If you use MSWord, OpenOffice or any other WYSIWYG
HTML editor I probably will not use your code. They create far too much
cruft (code bloat) to make it worthwhile to add the data elements. Take
some time and learn to use a good HTML editor like Bluefish
http://bluefish.openoffice.nl/ (not sure how well the MSWin users will
like the install), or any other non-WYSIWYG editor (Note pad works
too :-> )
One caveat to this is that if you wish to pay my consulting fee of $150
US /hour you can use any HTML editor you like. Just deposit the first
two hours worth in my PayPal account at timothywayne.cook@gmail.com and
I'll bill you for any remaining hours.
Anyway, the pages or just snippets (one or two archetypes) will likely
end up as examples in OSHIP and may eventually become a shipping
application it's self. Please be sure and add the text in an HTML
comment that the work is licensed under a Creative Commons License.
If some of you do not like my promotion of OSHIP here then I apologize.
But do remember that this work has been an investment for me and I plan
to hold one week workshops "How to develop healthcare applications with
OSHIP". If you have an interested group then please let me know
off-list.
**How does this sound...Your reaction please
Lets see what the reaction to this email and my suggestion of an open
source UI oriented clinical documentation project as a next step for the
openEHR clinical community.
I think I've accomplished this. 
Kind Regards,
Tim
(attachments)
