[FOSS_health] Re: [os-wg] [LinuxMedNews] Re: PatientOS v0.21 Scheduling II released

[Greg Caulton]

Hi Larry,

You have words of wisdom!  Let me clarify my involvement and position
in all of this.

>
> probably a seasoned developer even if he is new to open source healthcare applications
>

There are many more seasoned than I of course.  This is my second open
source app, having learnt many lessons from the first.  I am not new
to commercial healthcare information systems having worked on Cerner
for most of my 13 years.   My current day job is managing development
of internal clinical applications for my hospital.

I am new to open source healthcare applications and that is why I
(naively) had no clue that my posting progress on my development of
PatientOS, an open source (GPL v3) healthcare information system on
forums, mailing lists and LinuxMedNews would generate adverse
reactions from some people.  I guess I can compare it to joining a new
organization where you don't know the culture but after a year or so
(I have only been online since Oct) you can blend in or at least not
stick out as not playing by the rules.

As another wise person said on foss_health in this context, "I don't
blame any of you if you wish to recede into the background...", I feel
that way right now - stick my head in the sand ignore the storm around
me.  But against my own advice I am responding again (the follies of
youth), though if I get flamed again I will retreat.


>
>   If we (OS-WG) could create an environment or mechanism for *every* existing open source EHR developer to collaborate and create one data model that each was comfortable using,
>

That is a fantastic idea.  I have always believed that with any
complex information system the battle is won or lost with the data
model.  Too complex and your code will suffer, too simple and you
cannot be flexible enough.


>
> we could have a working engine (like Apache) upon which we could vary user interfaces, decision support and so forth
>

Absolutely - there is no reason one cannot have a web client and a
rich client.  Decision support can be built using open source rules
engines.


>
> Perhaps out of individualism or simply because it can be hard to find useful components, we reinvent what has already been done. If each developer would start from a standard
>

Ahh, well you see the reason (right or wrong) I reinvented was that I
looked at the goals of

a) minimize the amount of code written
b) minimize the complexity of the code written
c) maximize automation of routine code written

I did search high and low for components to do this, and my search was
very successful for many, many
(http://www.patientos.org/patientos/acknowledgements.html) components
and libraries but just not healthcare specific code *for the core
system*.  I did find and do use Mirth as an HL7 Engine, I do plan to
integrate Indivo as a patient portal, and I will use later other
specialty systems e.g. PACS

To achieve a and b) I found Hibernate awesome to minimize writing
complex SQL and yet still manage hierarchal database relationships.
JBoss provides middleware, queuing, synchronization, messaging, a
rules engine and much more.

Also for a) I do not code a single user interface - it is all driven
from the database and so no mistakes and forces a strong MVC
architecture.

To achieve c) I generate all of the data objects, object relationships
and reference codes as source code - effectively ruling out DTO
mapping errors and errors referencing all of the reference content
(settings, units of measure, types of status etc).

So all of this coupled with code focused on < 12 lines/method,
facades, interfaces, soa, factories, mediator and builder patterns has
made me extremely productive and I can build new functionality in a
fraction of the time of other projects I have worked on (I guest that
sounds arrogant - not meant to be).

With any architecture that attempts to achieve flexibility,
maintainability, scalability, reusability there is a price to pay -
mine is performance - rather than raw SQL serving up web pages, I have
a lot of object generation.  I offset this by smart caching but it is
yet to be proven that we can scale PatientOS to thousands of users.
Next year I will test this - once I have functionality enough to do a
valid test.

So while I completely agree with not reinventing the wheel - I think I
have at least an oval.  I have not seen an example of a project which
has done all I describe.

*And I not saying it will succeed but I would like to try*

>
> Apache-like model which encouraged developers to add new modules to the existing core
>

So while you probably cannot gather it from my website, this is
exactly what I hope to achieve.  While I will admit to being an
optimist, I am not so foolish as to believe that I could build an
entire system, however productive one can be.  My goal is purely to
build enough to attract other developers and open source companies to
take up PatientOS. Today I have a 2 developers and one (albeit) small
company that are doing just that as we work towards our first install,
replacing McKessons product
(http://www.patientos.org/phpBB3/viewtopic.php?f=9&t=40).  Small
beginnings I know, but I have to start *somewhere* and again - it has
only been a few months!

As we build functionality we are purposefully building plugins so that
you not only use the system tools to design your own applications, but
also write your own Java to radically alter the workflow of the
application, whether on the front end or in the backend processing.
As an example if you look at this user interface:

http://www.patientos.org/forum_temp/scheduling.png

The goal is you can completely alter the display.  For this version I
am working on (which is hopefully going live in a limited scheduling
capacity on the 10th) you can code against this interface and replace
the default code (i.e. implement ICalendarViewPlug by adding and
referencing a class that does something like this:
http://patientos.svn.sourceforge.net/viewvc/*checkout*/patientos/trunk/src/com/patientis/pluginclient/scheduling/CalendarViewStandard.java)

One of the biggest challenges is organizing the software development
lifecycle, to achieve a degree of design control and quality without
bogging down the entire process.  When you add that I have integrated
with a single source of reference codes and a database driven
environment there are several challenges.

*Until* I get the developer environment (on Linux) such that a
developer can synch a subversion environment - and immediately be
productive, I know it will be challenging to attract developers.  Once
I have the process nailed I plan to release PatientOS is a number of
languages and hopefully broading the interest to developers world
wide.

A large part of the system (form, menus, toolbars, dialogs etc) is not
built with raw code - rather built with GUI interfaces so I hope to
attract a broader audience to help build the system and while I do
have a few interested clinicians from our hospital - it is the chicken
before the egg in that I need to build more functionality for them or
anyone else to be productive.

Regardless of the challenges, anything is possible and while a
non-technical open source HIS seems out of reach, if Linux and Vista
can do it, so can we.  Certainly I am not giving up for at least 30
years :-)

Having said all this I am still all for giving and helping, and less
interested in controlling the project than making it successful,  In
fact it was upon Tim's recommendation that I joined OpenEHR in an
effort to make PatientOS compatible with other systems.

*All I ask* is to be able to post on LinuxMedNews and elsewhere my
progress - I am not saying I have succeeded (yet lol).

Oh and don't force me to write PHP (that's a joke!)

Greg

http://www.patientos.org



On 12/1/07, Larry Ozeran <lozeran at clinicalinformatics.com> wrote:
> Hi all,
>
> As an attempt to remind everyone we are all on the same side, I will enter the fray fully aware I may be bruised in the process.
>
> First, here is my take on the interaction. I know Tim. He is a longstanding developer and supporter of open source in healthcare. He speaks from personal experience. I do not know Greg, but I hear his passion and excitement. I am not a Java programmer, but I can follow his code examples easily, so I am going to conclude that he is probably a seasoned developer even if he is new to open source healthcare applications. If you can objectively strip out any emotional connotations associated with certain phrases, it seems to me that Tim is trying to help Greg benefit from his experience and guide Greg to the most beneficial uses of his time. How do we harness the enthusiasm that Greg brings to his project and move open source EHRs forward as a group? I think that was what Tim was trying to do in a more private conversation.
>
> Second, I think that Tim and Greg and I and probably most of you on this list would like to see greater adoption of open source projects in the healthcare industry. In my mind, the big question is how do we do that? Partly, we have to stop fighting (or appear to be fighting) and collaborate more effectively. All of us are smart and creative. It is natural for us to think our idea is the best and just hasn't been done before. Unfortunately, it is too common that a project will start with great enthusiasm and as progress slows, the project succumbs to frustration.
>
> This incident gives us an opportunity to discuss that bigger question. Here are my suggestions:
> If we (OS-WG) could create an environment or mechanism for *every* existing open source EHR developer to collaborate and create one data model that each was comfortable using, we could have a working engine (like Apache) upon which we could vary user interfaces, decision support and so forth. The beauty of open source is that if you don't like what is available you can make it your own. The danger of open source is that that freedom does not require us to modularize and build on what has been done already. Perhaps out of individualism or simply because it can be hard to find useful components, we reinvent what has already been done. If each developer would start from a standard and move forward rather than create their own from scratch, we would be much father ahead. Even better if we actually had an Apache-like model which encouraged developers to add new modules to the existing core.
>
> I don't think it is possible to create that data model today, but I would be happy to be proved wrong. Our next best option is to have a general agreement favoring modularity. If each developer would modularize their data model, user interface and other components then each could be reused by the next Greg if it met Greg's needs. It would be possible to use Greg's malleable user interface on OEMRs data model using Tim's order entry and Fred's billing. It would be similar to using a specific Linux core, with an Ubuntu distribution and KDE presentation layer. If our OS-WG were able to catalog existing modules, perhaps it would be easier to find modules that have already been made rather than spend large amounts of time developing anew. If each open source project indicated in its instances (its web site and on sourceforge) that our catalog existed, it might help to direct potential developers to start with what exists, or possibly encourage them to bring their ideas and talents to an existing project. If we had difficulty encouraging AMIA to support an online instance of this catalog, we are fortunate to have Ignacio as our chair. Not putting words in his mouth, but if it were the will of the group, I suspect he would be willing to host this catalog on LinuxMedNews.
>
> I've got my asbestos on. Flame away! :-)
>
> Regards,
>
> Larry
>
> On 11/29/2007 at 2:43 PM Greg Caulton sent:
>
> >Tim,
> >
> >If you were defending my project then perhaps I misjudged your email,
> >perhaps I am getting a little defensive (nothing personal) but when
> >you imply that my developing anything other than a web interface is
> >pointless, that I am repeating the mistakes of the past - I
> >*completely* disagree.
> >
> >I will attach what I believe is the merits of PatientOS utliization of
> >a rich client, software design patterns, HCI concepts, the best open
> >source software components - Java, JBoss, Hibernate, Swing, JGoodies,
> >Mirth etc.
> >
> >thanks
> >
> >Greg
> >
> >http://www.patientos.org
>
>
>
>