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* **************************************************************