[Gnumed-devel]

[sjtan]

Below was an email response to Horst's stuff:

This was an interesting read. Why can't the EHR be simpler? It looks
like Fowler's Observation pattern in Analysis Patterns, but has extra
stuff about versioning and subclassifying stuff into SOAP , but Fowler's
looks easier to implement. What happened to the UK Cosmos clinical
project? Has anyone seen an example of how it worked? 
Historically, Eiffel came before Java, and I've read the Object Oriented
Software Construction book by Eiffel's inventor : the main points I
remembered about it was Pre-conditions and post-conditions and the best
job in the world was pre-condition = False ( no responsibility) , and
the next best job in the world was post-condition = True ( never wrong,
so always responsible) ; it had some good stuff about the pointer
concept (as in c pointers) and object references being similiar , deep
copying objects ( because a shallow copy is just pointer duplication) ;
a little ditti about State change tables which comes out of computation
theory , and how to write an application as a state change table , or a
description of a finite state machine; a thing about invariants ,
although I'm not sure at what points in time within a black box
operation one is supposed to check the invariant, and how Eiffel was the
ants pants , and would have prevented an Ariane satellite rocket from
blowing up etc. if only the it had been written in Eiffel, because all
Eiffel classes have operation pre-conditions, post-conditions, and class
invariants , which prevent bugs from causing unpredictable operations
etc.  ( but if the main program and the backup program of the rocket had
both failed an invariant, the rocket would have just shutdown, and
fallen in the sea, instead of blowing up , ? to be fair, the argument
was that Eiffel was a strongly typed language, and insufficiently ranged
integer types wouldn't have been programmed in, as far as I remember) .
.. in short, there was a trend by some academic and financial
programming circles to push Eiffel as the solution for writing bug free
programs in the 90s , but because people had to pay ISE to get a copy of
Eiffel , it really didn't take hold.
( I also remember trying to use an Eiffel Bench tool, and it was pretty
kooky , e,g, put the pebble in the hole , meant some sort of
object-oriented operation . I think it was to something like throw the
pebble in the pond , grasshopper, and see how the waves caused by the
small pebble propogate across the whole pool ..  ) 

 

  

Comments from Thomas Beale in blue (TB)

TB: General comment. In general I support Horst's open source point of
view and requirements. However, there are a number of factual errors in
his review of the previous GPCG work, and a number of points I disagree
with.

Funding of the GEHR Archetype Editor: minimum specifications
The GEHR Archetype editor is an essential tool in the context of any
OpenEHR system. If implementation of such tool is to be funded with
public money, a number of minimum requirements regarding implementation
details have to be demanded.
These minimum requirements aim at ensuring
1.Reusability TB: in general re-usable software is desirable. But the
exact expectations of what might be re-usable here need to be described.
It is not necessarily reasonable to expect that a relatively small,
dedicated tool will generate many re-usable components. In fact (given
that we think we know how it should be designed) it is more likely to
incorporate other re-usable components, and the part written de novo is
unlikely to be particularly re-usable itself. I don't think
"reusability" is a useful a priori requirement of the editor. I would
feel that extensibility is the issue here;  the editor should be able to
be built upon or modified in future, however if the editor is part of
the process of generating standards then changes to the editor need to
be managed within some standards process.  This is not always an
absolute requirement – it depends on the primary purpose of the software
development process – there may be conflict between these requirements.
2.Portability (does this mean able to be used across different operating
system platforms
3.Long term value – is this value for money for the funders, or also
value for those using it
TB: these other two requirements would have to be defined as well - on
their own, these are not "requirements". What about other typical
requirements of reliability, quality, maintainability,
extensibility....????
of the generated software.
4.Functionality would have to get a look in surely – it has to do the
job and in a timely way

In the past, when such requirements were not specified explicitly, the
GEHR team has consistently failed to respect all of these three
essential requirements. I cant support having a statement like this here
unless it is well justified and the language is too strong -  as stated
above I doubt that Horst has given us a full list of requirements
against which something might be judged.  In any case it is easy in
retrospect to be wise.

TB: I'm not sure what purpose this comment serves. As noted above,
requirement 1 might not be reasonable in any circumstance. Requirements
2 and 3 are only reasonable if the effort is properly funded and if the
effort is not purely R&D. The current GEHR archetype editor is pure R&D,
and as such was a real experiment. Reasonable expectations of it are:
that it illustrate proof of concept 
that it be usable on a majority of user computers 
that it be free and publicly available 
It satisfied all of these, and, nearly 2 years after its creation,
continues to be used in presentations. It was written in VB because the
available resource - which the GPCG did not pay for - DSTC effectively
donated the time and resources by paying an honours student part-time to
do the work. I'll repeat that. THE DSTC WROTE THE GEHR ARCHETYPE EDITOR
FOR FREE, WITH NO GPCG FUNDING. The student in question is a talented
programmer in a number of languages, but the DSTC eventually judged that
VB was the best language given the student's knowledge of it, and the
ability to quickly build something that would run on Windows, which,
like it or hate it, almost everyone runs on at least one computer.
Realistically, if the GPCG had required a specific language, and there
was not a "free" resource available, they would have had to pay for it.
A first generation of software products was based around Microsoft's
proprietary single-platform COM model. A costly failure which - as
predicted by many - never worked.
TB: This is incorrect in a number of places. Firstly, the use of COM was
a requirement on the development of the GEHR kernel, not a choice by us.
In fact, with my background in open systems and Unix, I can personally
guarantee that no work would have been done with COM had we had a
choice. COM was required because the GPCG project definition included
integration with Locum, Medical Spectrum, and MIMSdata. Some or all of
these require COM for integration with their GUI. The GPCG allocated
money for personnel within these organisations to work on integration.
As it turned out, even with the available funds (admittedly not much -
order of 10k per company), they failed to do much work at all on the
project, citing lack of available resources.
Secondly, the trial was not a failure. The GEHR kernel worked, and even
worked through the COM interface to a test VB application designed to
mimic the required GP desktop tools. At the one demonstration we did for
representatives of the GPCG, the COM interface did not behave properly,
although we had tested it earlier. The back end worked perfectly. With a
bit more funding, the bugs could have been cleaned up. No-one asked for
this to be done.
A significant amount was learned from this project, much of it publicly
documented in the freely available public openEHR specifications
(currently estimated at at least $1m worth of free IP) - many of the
features of openEHR were influenced directly by what we learned on this
project. How a research project which achieved what this project
achieved could be called a failure is a mystery to me.
Lastly, it was not expensive by any stretch of the imagination. It was
budgeted at about 330k, of which less than 300k was spent. In the words
of a well known Australian IT indentity, 330k is the kind of amount
"just large enough to guarantee failure". In fact we didn't fail, but we
could not afford to employ people outside of the principals (TB & SH),
apart from one part time resource (Why? Because obtaining a quality
human resource for such a project means enticing them from their current
job, and offering them at least 12 months' work at a good rate. Internal
cost of a useful technical person is 80k/pa or more). Anyone who thinks
that less than 270k for the amount of software written in the project
(still publicly available, and being re-used in openEHR by the way) has
no idea of software engineering economics.
Another trial has been funded by the GPCG concerning proof-of-concept
components
(http://www.gehr.org/gpcg/Components/pilot_software_components.htm) -
once again, yet another non-portable proprietary Microsoft component
architecture was chosen (ActiveX).
By choosing ActiveX and COM, reusability was severely limited,
reasonable portability made impossible, and long term value put at risk
through vendor lock in. There was absolutely no need for such
artificially restrictive choices: the same goals could have easily been
achieved by selecting an open and portable component model.
TB: Again, these choices were due to availability of donated resource,
mainly by the DSTC. You get what you pay for. Whether reusability was
required or achieved has not been investigated to my knowledge - how was
this conclusion drawn?
By choosing non-standard and/or non-portable programming languages like
Visual Basic or Delphi or a proprietary Eiffel dialect along with
proprietary tool chains
TB: my personal choices are always high-quality, portable languages. The
languages which were actually used depended heavily on what software the
project was required to interface to, and the availability of human
resources in an environment of very limited funding.
and libraries the GEHR team created artificial difficulties in
recruiting experienced developers with the necessary clinical
background, and they missed out completely
TB: There is no problem getting hold of a VB developer! Delphi - no real
problem either. However, a priori, I would not normally choose either of
these languages for anything. Eiffel is a different category of
language. It is a specification language which produces software as well
(note: it is still the only tool on the market which can validate models
written in UML/OCL). From professional experience, I know that any
worthwhile OO programmer can learn Eiffel in a matter of weeks. There is
a large community of Eiffel users internationally, and in Australia,
including academic centres of excellence at Monash, UTS and U Canberra.
The Eiffel dialect we used was not proprietary - it was (and still is)
standards compliant. The Eiffel language now has an ECMA standard. There
is a GNU compiler for the same language which admittedly trails the
major commercial vendor whose tools we used. I am not trying to push
Eiffel here - simply to show that we did not make choices (where we had
them) without thinking.
And - it should be made clear that many of the software costs of
development using quality commercial tools were footed by Deep Thought
Informatics, including Eiffel licence, Configuration Management system,
quality documentation tools. None of the open source tools in any of
these areas was judged to be of high enough quality or was otherwise
problematic (e.g. would have cost too much to run in terms of extra
personnel to make up for missing features), at the relevant point in
time. (The well-known CVS tool is a case in point. The DSTC has run it
hard, using the latest freely available version & tools, and recently
found data errors - the death knell for any version control system).
Overall, the DSTC donated the largest amount of free resource. Flinders
University also donated. 
on valuable contributions from the free software community which they
alienated. These choices delay development and increase costs, while at
the same time
TB: I think this comment shows a failure to understand what the project
was about. It was not about "developing software" but doing research. If
it had been about building e.g. a quality, cheap, portable EHR system
for GPs to use, it would have been a different project (and would have
needed about $2m). R&D is not about using large numbers of people to
write little contributions to a software base, it is about having a core
team which has developed innovative ideas build a proof-of-concept of
the ideas. It should be recognised that the ideas in GEHR and now
openEHR are a qualitative improvement on existing software systems. It
is not a coincidence that the european standards boyd, CEN and the US
health standards body, HL7, have made significant changes in their
thiking and specifications due to GEHR and openEHR.
I support the open source community doing interesting work. But any R&D
project inevitably has a core team, core ideas, and core contributors.
Many of the programmers on the GEHR projects contributed significant
free time.
reducing the value of the end product for the target audience and the
"sponsor" - the tax payer.
TB: again, this misses the point. The point was not to build a piece of
production quality software, it was to do an important piece of
research. It achieved exactly what it was supposed to do.
To avoid further costly mistakes and in order to maximize benefit of
public funding, the following issues should be explicitly specified:
1.choice of license: a taxpayer funded project should benefit all
taxpayers. Only licenses granting public right of use (including right
to modify and extend, including right to reuse in commercial products in
a non-discriminatory way) are acceptable TB: the Mozilla public licence
was used in the GEHR work funded by the GPCG. This is probably the 2nd
or 3rd most common kind of officially recognised open source licence
after the GPL. This is a good licence because it does not alienate
commercial developers, and makes no difference to open source
developers. It maximises uptake. 
2.availability of source code: this is essential. There is no long term
benefit and no reusability in software of which source code is not
available. TB: all the source code of the GEHR project as been online
for two years, at Dr Sam Heard's expense I might add. 
3.choice of platforms: developed software has to run either directly
(virtual machine, interpreted code) or through simple recompilation on
all major computing platforms (as absolute minimum Windows, Mac OS/X and
Linux) 
4.choice of programming languages: only standardized programming
languages existing at least on all mentioned major computing platforms
should be allowed. Proprietary non-portable languages like Visual Basic
or Delphi must be specifically excluded from being used. 
5.choice of inter process communication architecture and protocols: only
platform and language independent architectures and protocols should be
allowed. Proprietary methods like COM and ActiveX must be explicitly
excluded from being used. 
6.user interface: must be cleanly separated from the rest of the program
logic to facilitate portability. Whenever graphical user interfaces are
contemplated, portable GUI toolkits must be used. 
7.choice of third party libraries, tools and applications: must meet all
requirements listed above 
TB: while I agree with these requirements for projects intended to
develop software for ongoing use (cf Research), we have to be careful
here. To say that the software be portable to e.g. Windows, Mac and
Linux is a desirable requirement. It can only be a realistic requirement
if there are funds to pay for the portability work and testing. The
Eiffel GEHR kernel would run on Windows, any flavour of unix, including
OS/X, given a modicum of recompilation work and probably a couple of
weeks. Funds were not available for this work, nor for obtaining the
necessary boxes for testing. Thus, these requirements are only
meaningful to the extent that theyare funded. As a matter of interest
the Eiffel GEHR kernel satisfies every one of these requirements.
The following examples for development tools to be used are
non-exclusive suggestions only. Any tool not listed in these suggestions
should be tested individually regarding compliance with the essential
specifications listed above.
Examples for usable programming languages:
1.All portable languages defined as standards with royalty free
implementations (C (ANSI strict), C++ (ANSI strict), Pascal (without
proprietary extensions like Delphi), Modula2, Modula3) 
2.All portable languages with royalty free implementations (Java, Eiffel
(with SmallEiffel as least common denominator for dialects), Python,
Perl, PHP, Tcl, Ruby, Guile, Scheme, Squeak) 
Examples for portable graphical user interface toolkits:
1.Swing (Java standard GUI library) 
2.QT (http://www.trolltech.no) 
3.wxWindows (http://wxwindows.org) 
4.Tk (http://www.scriptics.com) 
5.Web interface (HTML standard compliant) 
TB: Some of these, while free, have been found to be poor technically,
mainly Swing. Any software, whether free or not will eventually incur
some cost. Poor technical choices often incur high maintenance costs.
Examples for open and portable inter process communication (IPC) methods
1.XML-RPC (http://www.xmlrpc.org) 
2.SOAP (http://www.soapware.org/) 
3.CORBA (http://www.omg.org) 
4.Jabber (http://www.jabber.org) 
Examples for portable database backends 
It is important to use abstract database interfaces whenever possible:
such as JDBC (JAVA specific), ODBC (supported by most programming
languages), DB-API (Python specific).
1.PostgreSQL : Object-relational SQL compliant database server, ACID
compliant (http://www.postgresql.org) 
2.Interbase / Firebird : relational SQL compliant database server, ACID
compliant (http://www.ibphoenix.com/) 
3.SAP-DB : relational SQL compliant database server, ACID compliant
(http://www.sapdb.org) 
4.MySQL : relational SQL compliant database server (htp://www.mysql.com)
5.Metakit : embedded database system, ACID compliant
(http://www.sapdb.org) 
6.Berkeley-DB : embeddable database system, ACID compliant
(http://sleepycat.com/) 
7.Berkeley-XML-DB : XML database server
(http://www.merrells.com/john/dbxml/index.html) 
8.Apache-Xindice : native XML database server.
(http://xml.apache.org/#xindice) 
Suggestion for archetype editor implementation specifications:
1.License: any GPL compatible license as listed and explained at
http://www.gnu.org/licenses/license-list.html TB: GPL may be too narrow.
GPL alienates commercial vendors. 
2.Programming Language: Java or Python for best portability and
maintainability. The archetype editor is unlikely to have performance
issues with VM (virtual machine) languages, and will therefore not
require languages that are more difficult to port 
3.Graphical user interface: Swing if written in Java, else TkInter or
PyQT or wxPython (Python library bindings for Tk, QT and wxWindows) if
written in Python 
4.IPC: XML-RPC. The archetype editor is not likely to require
authentication or the better performance of CORBA; hence the ease of
implementation of XML-RPC appears preferable as compared to the more
expensive to implement CORBA. The archetype editor may be implemented
without IPC as standalone application. 
5.Third part libraries: unlikely to be needed for this purpose apart frm
a portable graphical user interface toolkit. If XML parsing is required,
the free Expat library (http://sourceforge.net/projects/expat/) or one
of it's countless language bindings would be strongly suggested. If
CORBA is chosen as IPC method, the free ORBIT library
(http://orbit-resource.sourceforge.net/) or omniORB
(http://www.uk.research.att.com/omniORB/omniORB.html) would be strongly
suggested. 
6.Should the archetype editor depend on database functionality, this
should be implemented by software complying with the essential
specifications. Database functionality can be implemented "embedded" or
through a client-server architecture. Isolating database access via a
simple middleware API is desirable, unless a small footprint embedded
database system is used. 
TB: While I don't particularly disagree with these suggestions, there is
no mention here of semantic fitness, or the quality or maintenance
characteristics of any of the technologies. We used Eiffel because it is
semantically far superior to Java for example. There is no reason why
Java cannot be used of course, it's jsut more difficult to write quality
software in it. I am simply using this example to show that quality must
also be a concern.

As a general comment, I support the GPCG use of funds to do trials of
various kinds, and hope it continues. While the projects I was involved
in were not well funded, they were presumably funded to the extent that
could be afforded at the time, and I appreciate the opportunity to have
been able to do some research in these circumstances. I think that the
current output of openEHR is a pretty solid proof that the GPCG money
was well spent.

My main recommendation for further GPCG funded projects is to understand
what the requirements are properly, and to especially understand the
costs. Regardless of whether open source is used, there are always costs
involved, whether for skilled people, testing, administration of support
tools or whatever.