Python/ZCA Healthcare Project Announcement

Wed May 21 13:28:56 EDT 2008

Hi All,

I apologize for the length of and the cross posting of this announcement
in advance but I believe it will be of value to you if you have ANY
interest in the healthcare IT field.  Even if you do not have interest
now; you may well after you realize the staggering growth that is
occurring in this sector.

The healthcare sector is a very complex information management space.
Healthcare IT applications are notorious for their lack of real
interoperability.  This of course increases the overall healthcare costs
due to lost and/or missing information.  

While the rate of adoption of IT in direct patient care scenarios has
been slow in the past; it is expected to increase dramatically over the
next few years.  A recent study shows that there will be a demand for an
additional 40,000+ healthcare information technology workers IN THE US
alone: http://medir.ohsu.edu/~hersh/hit-workforce-hersh.pdf 

The current situation for funding healthcare IT projects is that
agencies will have a specific healthcare information management need and
can only fund for that project. Examples are; a diabetes registry or an
AIDS treatment tracking application.  The result is that they get the
application that fills that need but the information is in a specific
format for that project and is, more often than not, incapable of being
shared with any semantic meaning with any other application.  Can the
business of healthcare IT continue in this way?

While there has been much work done over the last 40 years on healthcare
IT standards, we still aren't ahead of the game on any major scale.  
However, a core group of people have been working for almost two decades
with a primary principle of 'implementation'.  Basically, if it can't be
implemented then it doesn't work. A history of their research and
development efforts is worth the quick read:
http://www.openehr.org/about/origins.html 

Implementation is already proven in an opensource Eiffel reference
implementation as well as an opensource Java implementation of the
Reference Model.  There is also a significant C# commercial
implementation by Ocean Informatics
http://oceaninformatics.biz/CMS/index.php 

These are complimented with various opensource tools for working in this
environment (see the Software link at http://www.openehr.org ).

The Python/Zope/Plone community will be very familiar with the concepts
of two-level modeling that is represented in the openEHR specifications:
http://www.openehr.org/releases/1.0.1/roadmap.html In a nutshell, the
openEHR specs. define a very broad, core reference model, that is
constrained by a knowledge model (called archetypes).  Any
implementation of the reference model knows how to deal with the
structure of an archetype and therefore information expressed in an
archetype instance can be exchanged between applications.  

These specifications are becoming more and more widely known. In fact,
the Archetype Definition Language (ADL) is now part of a CEN (European)
health record standard and is an ISO candidate. 

As you may have noticed, there is a non-profit foundation established to
care for the IP and insure that it is and always will be open. The
openEHR Foundation is open to membership by other organizations. In
fact, the Python or Zope foundations could easily become an influential
member. There are also governance processes in place to vet the changes
in the specifications.

The project that I am announcing is the Open Source Health Information
Platform (OSHIP).  I (as others) have tinkered with Python/Zope/Plone
over the past several years in healthcare applications.  These have met
with mixed results mostly due to the same problem; lack of
interoperability (search SourceForge for more info).  

The concept of OSHIP is that it can be an application framework for
interoperable healthcare applications.  This should be especially
appealing to governments and funding agencies worldwide. OSHIP operation
is envisioned as taking the archetypes expressed in ADL and store them
in an Archetype Repository as Python objects.  These instances are then
available to developers to use in healthcare applications.  Knowledge
workers can create/edit the ADL files (using existing opensource tools)
to create whatever knowledge model may be needed for a specific
application.

The current state of OSHIP is that I have entered the specifications as
ZCA interfaces and basic implementations.  But as I said, I am a
'tinkerer'.  I need your help in evaluating this basic implementation
and fleshing out the classes according to the specifications.  

The functioning components already include a parser for the ADL files
and an (almost complete) object builder to store these in the ZODB for
use by OSHIP users. 

While I am now appealing to the broader Python/Zope communities for
participation.  There is already interest in OSHIP.  There is a workshop
scheduled ( http://www.oshipworkshop.if.uff.br )for July 21, 2008 where
we will be spending 10 days on health informatics, openEHR and OSHIP.
The goal is to actually develop one or more OSHIP applications as
examples.  There is at least one PhD student that is using these ideas
for his project.  OSHIP is already considered to be the Python reference
implementation of the openEHR specs.  (BTW: for anyone interested there
is a Ruby implementation underway as well).

In order to promote the widest use of the openEHR specifications; OSHIP
is licensed under the Mozilla tri-license
http://www.mozilla.org/MPL/boilerplate-1.1/mpl-tri-license-txt

If you have any interest in helping move this project ahead please join
the developer's list at the SourceForge Project site:
http://sourceforge.net/projects/oship

The sourcecode will be placed on the openehr.org SVN server by 31 May,
2008. I also plan to put an egg on the SF site.  This will be 'alpha'
level code, though I hope that we can move to a beta stage at a fairly
rapid pace (mid July?). I do not envision that the Zope experts will
need to do the actual manual labor of fixing a lot of this code. If I
can get some helpful suggestions then I will gladly do the work as well
as manage others helping out.  

As an aside, one of the key benefits to this project is that the core
documentation is already complete.  The openEHR specifications do that
for us.  We just need to finish the implementation and some top-level
ZCA specific docs. 

Thank you very much for your kind attention to this project that holds
such a deep passion for me.

Sincerely,
--Tim Cook

-- 
Timothy Cook, MSc
Health Informatics Research & Development Services
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook 
Skype ID == timothy.cook 
**************************************************************
*You may get my Public GPG key from  popular keyservers or   *
*from this link http://timothywayne.cook.googlepages.com/home*
**************************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/python-list/attachments/20080521/60169f9f/attachment.sig>