oship-dev team mailing list archive

[Tim Cook <timothywayne.cook@xxxxxxxxx>]

Hello OSHIPers,

Before I get into the actual outcomes of the wonderful workshop we had
in Petroplis. I want to thank each of you for your work on OSHIP.  In no
way can any one person do this.  This project and the ideas for future
direction that we have and will evolve depend on us and all that will
come.

To help put a face on the actual global impact that your work will have
and so you know that the MLHIM group is not just a bunch of idealists
with some vision of grandeur. I would like for each of you to take 30
minutes of your time and watch this video. Please do so before reading
the rest of this email.

http://www.ted.com/talks/larry_brilliant_wants_to_stop_pandemics.html 

...some time later because you really did watch the video.  :-)

Now I would like for you to consider.  As we approach the actual
functioning applications built on top of OSHIP (irregardless of the
language, see below); what can those applications look like, platforms
they can run on, places they can be deployed? What will it mean to have
very small, purpose specific applications with decision support that can
help a healthcare worker, at whatever level, recognize the possibility
that THEY may have encountered some new viral variation.  Or even a
known one but not expected at that consultation?  By having REAL
inter-operable information. Built on open source foundations WE and all
those that we have yet to reach that will join us; can help
organizations like InSTEDD http://instedd.org/about and GPHIN
http://www.phac-aspc.gc.ca/media/nr-rp/2004/2004_gphin-rmispbk-eng.php 

to aggregate better, more inter-operable information faster. This means
that emergency responders to an endemic outbreak or a disaster situation
can respond faster with the correct supplies at the correct place
without the bureaucratic mess that we normally see.

With that perspective in mind.  Now, think about how important your job
is working on these specifications and the reference implementation of
them.

Including discussions from the workshop and discussions with others
outside of the INCT-MACC collaboration.  I want to give you some points
on where we are headed.  The exact roadmap for it is still in process
and I want you, each and everyone, to be involved:

1. It is confirmed that we will be converting an emergency cardiac
application to MLHIM specifications on top of OSHIP.  This application
was written by INCT.  It consists of an emergency room (cardiologist)
app and an Emergency Medical Technician (ambulance) app. This will
likely be the first approach to the PHISS project that we have already
begun.

2. Collaborative negotiations are still in process. But a major
University in Brazil is planning to collaborate with us on an ante-natal
care application that they are creating.  As this point it seems that it
consists of an application that can be used in an office and / or during
home care visits.  There is also a need for data aggregation and
analysis for municipalities to report case status to the state for
reimbursement.

3. It is confirmed that we will be in collaboration with Dr. Michael
(Mike) Bainbridge and his partners from the UK on the Database of
Medications and Devices (DM&D) and also on the Common User Interface
(CUI) standards. The DM&D is a standard drug database mandated for use
on the UK NHS Spine
http://www.connectingforhealth.nhs.uk/systemsandservices/spine/faqs In
case you are not aware.  The UK NHS is under going the world's largest
healthcare IT project to date.  Also Mike and his team will be working
with us on the MS/NHS-CUI standards.  Some of these are still
specifications others are UK Standards and some are on their way to ISO
standardization.  We are very fortunate to have Mike and his team since
they were instrumental in creating both the DM&D and the MS/NHS-CUI

4. It is confirmed that during this next school year (begins in
September in the US) the Software for Humanity (SoftHum) project will
begin working on MLHIM/OSHIP projects.  Probably the CDD. The specific
group is a computer science class from Western New England College.
Justin Dupree is the student technical lead and his supervisor, Heidi
Ellis are very excited about joining us. SoftHum is a US National
Science Foundation program in collaboration with Western New England
College, Drexel University and Trinity College.

5. There is a commercial company in Europe that is already deploying an
openEHR practice management solution and is now looking to add clinical
information systems.  They are interested in collaborating with us on
MLHIM.  Roger Erens is taking the lead on working with this in order to
bring the resources in to help. This is primarily a DSS on multi-level
data project.

6. There is another major University in Brazil that we are beginning
collaborative talks with around integration of disparate clinical
systems in order to normalize the data for interoperability. 

7. There is a US based data center company specializing in the business
side of healthcare that is now interested in collaborating with us on
creating a MLHIM based clinical stream of apps.

8. Collaboration is in the very early stages with a large telemedicine
network to help host our domain expert knowledge panels.

As you can see.  The demand is growing and we haven't really started
trying to market what we do.  Yes, open source groups have to us
marketing too. We currently have just enough committed people to take on
the projects that we have committed to do.  So a major negotiation is
bring on more granters or full-timers within some of the companies.  

In order to attract more developers from the open source world. I am
going to implement a strategy next week that has already been discussed
with some of the usual suspects. :-)  OSHIP has the right ideas.  There
must be 'something to show' people in order to attract the attention of
collaborators that have the financial means to keep us going through
grants etc.  

Therefore I have started negotiation with the openEHR Ruby team on
moving their project under the MLHIM/OSHIP banner.  They essentially
have the same ideas and things will be done in a Ruby way so that Ruby
developers are comfortable.  They will remain as project managers. This
will increase the developer pool for us all. I asked them to take a few
days to decide. It is already open source so you can imagine the outcome
no matter their decision.....

The current Java implementation is simply the underlying reference
model.  There is no application server, no persistence layer, etc. There
really isn't even a Java team thinking in that direction.  They all seem
(to me) to be creating those parts as commercial applications.  I intend
to change that.  I will fork the code and setup the jOSHIP project
(interim name) to create a Java platform.  The developers that come on
board can adopt a new name if they wish. 

We will move to a XML Technologies infrastructure.  This is for
knowledge modeling; replacing archetypes in ADL with Concept Constraint
Definitions (CCDs) expressed as XML Schemas and replace openEHR
Templates with Template Constraint Definitions (TCDs) also expressed as
XML Schemas.  The tooling is mostly off-the-shelf open source.  We will
use the Freemind mind-map tool for the experts to model the CCDs and
TCDs (Freemind output in XML converted to XML Schemas) and the
previously talked about Glade XML plugin for technologists that are
familiar with the MLHIM specifications to review for technical
correctness.  These XML Schemas then can be used in any language, the
tool for domain experts is easy to understand and use because they do
not have to know really anything about the reference model.  This will
encourage more to participate in expert panels either in person or
remotely. 

By using the Yahoo User Interface library. I expect us to be able to
create MS/NHS-CUI compatible widgets that are reusable across
implementations.  Giving us a clean, efficient, standards compliant and
consistent look and feel.

Tools for us to use on our artifacts, excluding software development,
have been chosen using the following guides.  They must be open source.
They must be cross platform.  They must produce an artifact in a file
format that does not prevent us from switching to another tool if
necessary.  

They are:

For documents of any kind: The Lyx Document Processor:
http://www.lyx.org

For graphics the exact tool is not specified but we should have an SVG
and/or GIMP file as a master.

For knowledge modeling we will use both a modified Freemind and Glade
with a new plugin. To produce XML Schemas.

If we need a desktop publishing application for any documents, posters,
etc.  They should be created using Scribus. http://www.scribus.net/ 

So everyone has plenty to do.  This always excites me and motivates my
creative mode. :-) There are other documents in the pipeline that will
drill down into more details on some of these issues as well as overall
governance of the projects.  

I hope that I have given each of you a little bit of the passion I have
for this set of projects.  While we probably do not have THE solution.
We do have a better solution and better approach than what has existed
over the past 45 years. We also have the Internet and a growing
population that has a clue about open source and open content.


Cheers,
Tim




-- 
***************************************************************
Timothy Cook, MSc
Project Lead - Multi-Level Healthcare Information Modeling
http://www.mlhim.org 

LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook 
Skype ID == timothy.cook
Academic.Edu Profile: http://uff.academia.edu/TimothyCook

You may get my Public GPG key from  popular keyservers or    
from this link http://timothywayne.cook.googlepages.com/home

Attachment: signature.asc
Description: This is a digitally signed message part