[FOSS_health] my summary of discussion

[Lee Seldon]

This morning I finally gave up and decided to make a digest of the 
discussion. So I have pasted together what I find interesting pieces. I 
still need time to study this and follow up on many of the points.
A very very short summary:
  - FOSS should probably aim for 'functional' interoperability, but 
might have to start with a 'basic' one.
  - communications should be based on XML, not on HL7 v2.x.
  - using XML there already seem to be several (compatible?) 
initiatives. However, VistA and openMRS both use HL7 v2.x, obviously for 
reasons of interoperability with existing applications (including 
themselves).
  - middleware approaches (CORBAmed, gateways, hubs) have been 
successful, but seem to have gotten lost or lost favor like much other 
stuff (good and bad) in IT. Reviving one of them might be more effort 
than just letting it rest in peace.
  - the next step could be to agree on an existing XML-based standard, 
e.g. CCR, HL7 v3 CDA, HL7 v3 messages (of which there exists an 
extensive list), etc, or join an existing interoperability project, e.g. 
HSSP HDTF, ... (I am not familiar with these, but somebody certainly 
is). I can give my opinion of the CCR, HL7 v3, etc ones if desired.
Lee
DIGEST:
24/5/2007 Wayne Wilson - I work in one of the largest academic health 
systems in the US. For about 5 years ending just 5 years ago I worked to 
establish strategic IT directions in clinical care.
I had a very difficult time getting any open source software to be 1) 
accepted by the IT management and 2) gain the support of the academic 
doctors who were tapped to guide the professional IT shop.
  Why was this?
In the case of IT management, there were several 'buzz' concepts that I 
couldn't penetrate:
1) We are poor at developing software compared to proprietary software 
vendor. - now this was cognitive dissonance, since the most successful 
software ever was an in-house developed clinical web portal. I had set 
up the web services group, but was not in charge of it after it's 
creation, I did strategy not implementation. It was a miracle we managed 
to get a web developer group started at all! I remember sitting at one 
executive board meeting and presenting data that I had gathered from our 
commercially procured, competitive economic analysis with other top 
academic medical centers. That data consistently showed a better 
accepted system and better return on investment for in-house developed 
software. That should have caused questions to be raised to be raised 
about proprietary vendors. Yet, the Nursing representative, who had 
joint academic and clinical care duties, basically said right after my 
presentation something like this: "But we know we are no good at 
developing software, everything we do in house has failed". A bunch of 
nods at the table and my presentation was promptly forgotten.
2) A re-enforcing factor for the above sentiment - COTS. Commercial Off 
The Shelf software. It's was the latest word in effective IT management 
circles.
3) Finally, I discovered that one or more academic doctors had a long 
term relationship with one or more commercial software companies. This 
is technically not a conflict of interest, as long as your are not 
getting directly paid this year by them. But you are free to encourage 
attendance at love fests like HIMSS, while you hit the booths of your 
favorites and keep on the lookup for up and coming contenders.
4) Several in house developed software packages had been taken and 
continue to be taken commercial via start-ups, by either the 
professional staff or the academic health care staff. The University is 
pushing licensing of IP revenue to start to make up for the declining 
support from the public. WE are supposed to be a public institution, yet 
the public is now more or less a minority investor. Combine that with 
bubble effect of the wide publicity of all these kids making millions 
from startups.
So, what kind of effort could turn these concepts upside down? I think 
that COTS and startups have nearly run their course. Things are no 
better in IT than before those concepts were endorsed. That leaves long 
term relationships with commercial vendors and the reluctance of 
professional IT to get involved with FOSS where it counts, in clinical 
software. It's curious to note that infrastructure FOSS software in 
professional IT shops can easily come in. It lowers cost and does the 
job. No other comparisons and factors then count.

24/5/2007 Tom Jones - >That depends on what level of interoperability we 
are discussing.
 >Interoperability has several meanings. For instance, in Lumpkin, John 
et al "National Committee on Vital and Health Statistics report to the 
Secretary of the US Department of Health and Human Services on Uniform 
Data Standards for Patient Medical Record Information" July 6, 2000, p 
6, one can find the following:
 >"Interoperability refers to the ability of one computer system to 
exchange data with another computer system. There are three levels of 
interoperability.
 >'Basic' interoperability allows a message from one computer to be 
received by another but does not require the ability for the receiving 
computer to interpret the data.
 >'Functional' interoperability is an intermediate level that defines 
the structure, or format, of messages (hence the term message format 
standards). Functional interoperability defines the syntax of the 
message. It ensures that messages between computers can be interpreted 
at the level of data fields. For example, when one computer has a 
structured data field for Ear Exam, that computer should be able to pass 
data from that structured data field on to another computer and have it 
appropriately stored in a comparably structured field for Ear Exam in 
the receiving computer. Neither system has understanding, however, of 
the meaning of the data within the fields.
 >'Semantic' interoperability provides common interpretability, i.e., 
information in the fields within the message can be used in an 
intelligent manner. At the highest level, semantic interoperability 
takes advantage of both the structuring of the message and the 
codification of the data so that the receiving computer can interpret 
the data."
 >Up through version 2 of the HL7 messaging standard, each enterprise 
created its own information model. Within the "pipes and bars" (or 
within the XML standard used by versions 2.4 - 2.n), the representation 
of the content of each HL7 message was left up to the enterprise (and to 
the vendors servicing that enterprise's system needs). While each 
enterprise was able to maintain a degree of interoperability within its 
boundaries, once an enterprise had to communicate outside of its 
boundaries, effective communication faltered because the "optionality" 
inherent in these older versions of HL7 prevented systems from 
exchanging the meaning of the message content. This shortcoming was 
highlighted in an NCVHS report to HHS Secretary Shalala in 2000.
 >"Today, these standards have a high degree of optionality in order to 
accommodate the variability of workflow and availability of information 
in different care settings. This optionality creates the need for costly 
and time-consuming customization when implementing message format 
standards. In addition, vendors and providers have developed their own 
implementation guides that differ from the standards. Finally, there is 
little or no conformance testing of message format standards.
 >Non-standard implementations result in the need for costly and 
time-consuming customization to allow information systems to seamlessly 
exchange data with one another. These customized solutions contribute to 
high cost of systems."
 >When enterprises merge for business or regulatory reasons, the need 
for more robust standards for interoperability becomes more acute. In 
these merged entities, simple graphic display of numerical laboratory 
results becomes a nightmare, and automated decision support a virtual 
impossibility. The situation is just as intolerable for the continuing 
consolidation of commercial hospital groups as it is for the evolution 
of government-mandated regional healthcare networks.
 >As the HL7 messaging standards gained wider use (the majority of 
automated clinical systems take advantage of one or more of the older 
versions of HL7), recognition of the need to more fully specify and 
normalize the content of HL7 messages led to the development of the HL7 
Reference Information Model (RIM), an integral part of HL7 version 3 
(the messaging structure in this version continues the XML standard 
established with HL7 2.4). In an early white paper, a committee within 
the HL7 organization proposed a model for the actual content of an HL7 
message. They believed "that the proposed model will pave the way to new 
messaging opportunities, including quality management, outcome 
assessment, decision support, cost control, and authenticated, accurate, 
electronic medical record communication". As work on the RIM progressed, 
one can see that its authors' collective ambition was to represent the 
world of clinical care in a formal >logic that would allow engineers to 
write code and build clinical >information systems that would more 
accurately represent that world. Such >systems could facilitate more 
effective electronic communication among clinicians, and they could also 
cross enterprise boundaries and therefore be truly "patient centric".
 >The bottom line, in my view, is that HL7 v2.X sets the bar too low – 
at functional, rather than semantic, interoperability. HL7 v.3 (which 
includes the RIM) would be a better level.

24/5/2007 Klaus Veil - The problem has been with " just agree on the 
terminology (elements)." - this has been in an international agreement 
process for ~20 years and HL7 SNOMED, LOINC, etc have been the result. 
Having been involved in healthcare standards development since ~1987, I 
can only say how very hard it is to develop globally agreed consensus 
standards...
HL7 V2.x comes in a compact delimited version ("vertical bars") or in a 
XML version (It is actually not a XML wrapper, but true XML).
V3 is very complex and requires extensive knowledge of the HL7 model 
("RIM") and is quite resource intensive (both implementation and 
run-time) to implement. Fortunately, there are a number of initiatives 
underway to simplify its use.
For those who recently joined this list, here is an HL7 Intro:
www.HL7.com.au/FAQ.htm
For those looking for HL7 tools and resources, go to:
www.HL7.org.au/HL7-Tools.htm
There is also a RSS feed at www.HL7.org.au/HL7-Tools-RSS.xml

24/5/2007 Boh Heong Yap - agreed, with Lee, we should go with the later 
XML based stds. to 'future proof' the stuff we do. Also as Lee pointed 
out, most languages, certainly Java and Python has strong support for 
XML handling.
Also as a suggestion, why don't we pick just ONE aspect of 
interoperability to work on; and the OBVIOUS one would be EHR/patient 
records' (or a subset of?), say the demographic details - then expand 
that to encompass diagnosis and prescription (which I understand may 
encompass other encoding standards (ICD, SNOMED etc...)
Also as a methodology and to spread the knowledge/work around, (for e.g. 
I can hack code and handle complex data-structures, but have next to 
zero knowledge of HL7 et-al, whereas others have the HL7 knowhow) can 
someone with the knowhow specify/extract the encoding (representation of 
EHR, Electornic Health Records, in XML) so that other hackers can then 
work at building the 'black-boxes' the do the translation. Perhaps this 
is best illustrated by a simple diagram:

1.                                                         5.
+--------+    2.                                4.         +----------+
| app.1  |    +------+     3.                  +-------+   | app.2    |
|OpenMRS |<-->|black |    +---------------+    |black  |<->|VistA     |
+--------+    | box  |<-->| HL7/XML rep.  |<-->| box   |   |          |
               +------+    |  of EHR       |    +-------+   +----------+
                           +---------------+

When one app needs to talk to another app. to transfer EHR, its done 
thru the intermediary of the HL7 representation of a EHR, which might be 
a bunch of XML tagged data, show as 3. in the diagram.
OpenMRS may have its own internal representation, and so does VistA. 
What is needed are the 2 'black-boxes' represented by 2. & 4. above. 
What these are, is code that can read/write from their internal 
representation to the HL7 representation.
Once 3. is specified (among OSHCA devlopers) any other app. that needs 
to trnsfer EHR would just need to build its own 'black-box'. e.g SAHANA 
would build a 'SAHANA black-box' to join the party...
And if written well, the 'black-boxes' can be done as libraries for 
specific languages (say a Java, PHP, Python vesions...) to that it can 
be reused by other apps.

24/5/2007 Tim Churches - I think that is a rather good summary of the 
problems with HL7 v2.x. I would add that the HL7 specifications do not 
really address the issue of what receiving information systems are 
supposed to with the the messages which they are sent. For example, if a 
pathology laboratory discovers a life threatening abnormal result, say a 
very low serum potassium level, then it can send an HL7 result message 
to the requesting doctor's system, and it can even flag in that message 
that the result is abnormal and urgent and life-threatening, but HL7 
provides no mechanism for directly requesting that the other system 
bring this result to the attention of a relevant human being (probably a 
doctor or nurse), nor does HL7 provide any help with communicating back 
that the requested action was done, or was not done as the case may be. 
In other words, HL7 v2.x defines (rather loosely in most cases) how data 
or information should be formatted and to a lesser or non-existent 
extent how data should be semantically represented, but is completely 
silent about what should be done with that data by the receiving 
computer system: actions are all implicit and have to be worked out on a 
case-by-case basis. What is actually needed is a mechanism for receiving 
systems to advertise what actions they are able or willing to perform, 
and a mechanism to explicitly request one or more of those actions when 
sending data to that system. In order words, a remote procedure calling 
system. CORBA and CORBAmed had all this a decade or more ago, but HL7 
won out over CORBAmed for various reasons. Thus, apart from solving all 
the problems with the optionality of the HL7 v2.x specifications and the 
many semantic encoding issues which HL7 v2.x does not address, there is 
also the problem of negotiating what receiving systems are supposed to 
do with the HL7 messages which they receive, and that ends up being 
implicit and again worked out on a case-by-case basis.
Now, none of these issues mean that one should not use HL7 v2.x, just 
that one needs to be aware that the decision to use HL7 v2.x is only a 
very partial solution to the interoperability problem, and that in 
almost all cases, a lot more work will be needed to either define 
additional (usually national, regional or local) standards and protocols 
layered on top of HL7 v2.x for specific purposes (eg path lab results 
reporting), or a lot of case-by-case, point-to-point negotiation and 
pre-processing and post-processing of HL7 messages will be needed in 
order to achieve useful levels of interoperability.
That's why I opined at the OSHCA conference that the decision to use HL7 
v2.x in any interoperability circumstance should be a considered one, 
not an automatic one, and that HL7 is not a panacea, and in some cases 
it may be better to use a simpler, more light-weight mechanisms to 
exchange data between health applications.
Perhaps openEHR and/or HL7 v3.x will solve these problems, but as 
various people have said, practical implementations of these are still 
some way off and we need to get on with life (and death) in the meantime.
The other point regarding HL7 is that its whole interoperability model 
is based on the assumption that health care applications are black boxes 
and that their internal data models and data representations can't be 
examined, modified or augmented - hence the need for a single 
comprehensive standard (which is supposed to be HL7). Of course, that 
model is valid for almost all closed-source software, but it is not true 
of open-source health software. When considering interoperability of 
open-source information systems, other models are possible. Underlying 
databases and data stores can often be accessed directly, it may be 
possible to actually embed one open-source application in another, or 
special-purpose data interchange modules can be written. For example, 
say I want SAHANA to exchange data with NetEpi. The traditional approach 
is to look at the HL7 specifications, work out which message types and 
message segments are most appropriate, and for the developers of each of 
the applications to add the ability to emit and consume HL7 messages 
which are compliant with the relevant aspects and parts of the HL7 
specification. Of course, the actually data items collected by SAHANA 
and NetEpi are quite volatile and dynamic (that is, the data which needs 
to be exchanged will change as a disaster or a disease outbreak develops 
and unfolds), and HL7 v2.x does not handle changing data requirements 
very nicely at all. But alternative approaches are possible. For 
example, as a NetEpi developer, I can download all the SAHANA source 
code, set up an instance of it, and write a plug-in module or code patch 
for SAHANA which will produce data in exactly the form that NetEpi 
requires - without all the overhead of pouring through 700 pages of HL7 
v2.x specifications, then having to augment those specifications in any 
case, write up those augmented specifications, send them tot he SAHAN 
people and try to get them to implement them. Or I can write a NetEpi 
extension to directly access the underlying SAHANA database. Or both 
SAHANA and NetEpi can agree to use XML-RPC or some other simple 
mechanism to interchange data and to remotely cause specific actions to 
occur in each others' systems.
Of course, the objection will be raised that it will take more resources 
to define and create such special-purpose interfaces than it would to 
use a "standard" HL7 interface. The problem is, as has been discussed, 
that HL7 v2.x is an insufficient standard in so many respects, and thus 
it may, in many circumstances, be harder and more resource intensive, 
even in the long-term, to use it than to ignore it. Also, health 
applications and information systems themselves are in a constant state 
of development and change (particularly open-source applications), and 
so ongoing maintenance of any interoperability mechanism, whether it 
involves HL7 or not, will be needed in any case. Finally, open-source 
health information systems, particularly those deployed in developing 
and transitional countries and those deployed in community settings as 
opposed to hospitals and large clinics, should not allow themselves to 
be dictated to by a "standard" which is primarily designed to help run 
large hospitals in rich countries. After all, there is not exactly a lot 
of evidence from rich countries that have adopted HL7 v2.x widely that 
it is a better solution than other approaches. There are so many stories 
of systems which are supposedly "HL7" compliant failing to interoperate 
properly, or only being able to interoperate after a lot of case-by-case 
and point-to-point effort and money is expended. Open-source health 
systems should only use what has been demonstrated to work well, and 
should feel free to explore alternatives to HL7. Remember, what matters 
is that patient care and public health is improved, not that systems are 
compliant with arbitrary information standards developed in rich 
countries to run their well-resourced hospitals. Let's not put the cart 
before the horse.

25/5/2007 Christian Heller - You may also want to have a look at CYBOL, 
an XML-based format described here (DTD, XSD, EBNF):
http://cybop.berlios.de/cybol/index.html

It has just four tags and four attributes and is very flexible, yet able 
to hold meta information (the third level :-) . I just copy the DTD here:

<!ELEMENT model (part*)>
<!ELEMENT part (property*)>
<!ELEMENT property (constraint*)>
<!ELEMENT constraint EMPTY>

<!ATTLIST part
  name CDATA #REQUIRED
  channel CDATA #REQUIRED
  abstraction CDATA #REQUIRED
  model CDATA #REQUIRED>

<!ATTLIST property
  name CDATA #REQUIRED
  channel CDATA #REQUIRED
  abstraction CDATA #REQUIRED
  model CDATA #REQUIRED>

<!ATTLIST constraint
  name CDATA #REQUIRED
  channel CDATA #REQUIRED
  abstraction CDATA #REQUIRED
  model CDATA #REQUIRED>

Here are some example models:
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/cybop/examples/helloworld/greeting.cybol?rev=1.2&content-type=text/vnd.viewcvs-markup
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/cybop/examples/helloworld/startup.cybol?rev=1.10&content-type=text/vnd.viewcvs-markup

Note, that "state models" (the first link being part of a textual user 
interface) and "logic models" (the second link representing the startup 
algorithm) are represented in the same way, as opposed to traditional 
programming languages having a different syntax for structures/ classes 
and methods/ functions/ procedures.

25/5/2007 David Forslund - Christian Heller wrote:
Interoperability - Message standards
Some people seem to be interested in pursuing this. I have had more 
thoughts since my original proposal.
I do not have time to commit to the project, but would like to give my 
opinion, if possible. I vote for your proposal to stick with XML.
Also, I do not recommend using HL7 RIM3 since it is a complex domain 
model to be used in application frameworks for building standalone 
application systems, but not suitable for data interchange. HL7 CDA 
might be a better solution.
The interoperability of FOSS should be in concert with non-FOSS systems, 
too, which is why standard bodies for interoperability exist. Having 
interoperability between FOSS systems is valuable, but likely to go very 
far unless they interoperate with non-FOSS systems.
OpenEHR is very complex and not mature in my eyes (my opinion). HDTF 
(CORBAmed) is o.k. and might be faster than an XML-based approach, but 
brings with some overhead, needs IDL interfaces, an ORB process
All of these capabilities come with standard Java, and CORBA solutions 
are perhaps 10 fold (or more) faster than XML approaches. (The use of 
the DOM standard adds enormously the the XML bloat, but this can be 
eliminated). Most of the data movement in the HDTF standards is 
completely compatible with XML. In our OpenEMed software we use XML 
extensively and it works well with those standards.
running etc. and not many programmers know about CORBA any longer.
This is probably the biggest barrier even though, IMHO, it is much 
simpler than Web Services because objects are handled more clearly and 
it was designed with interoperability from the beginning, while Web 
Services is not. Doing things in XML does little for interoperability 
unless one has some common semantics. CORBA doesn't guarantee 
interoperability. Standard interfaces are what are required. The FOSS 
folks need to connect up with the HSSP efforts so that one doesn't have 
to reinvent the wheel.
I wonder what happened to HXP, in which OSCAR was involved? In my 
opinion, this is the way to go. Start simple and get some data exchanged 
via XML, as prototype solution. Then think closely about the XML format 
and refine it.

26/5/2007 William Lauesen - It was interesting to hear about IHE 
"Integrating the Healthcare Enterprise" ( http://www.ihe.net/ ) and the 
HIMSS Interoperability Showcase ( 
http://www.interoperabilityshowcase.org/ ) in the US. There were some 
talks about IHE in their booth at the adjoining exhibition (but there 
was no Interoperability Showcase in Singapore). Perhaps if OSHCA could 
demonstrate interoperability of some FOSS products at one of their big 
showcases it would be a good opportunity to showcase FOSS and its 
advantages to a wider audience.

28/5/2007 Adrian Midgley - I think if several groups are trying to 
connect _in the same time period_ then a lingua franca or even hub and 
spoke arrangement is more likely to arise and is clearly better.
http://www.defoam.net/writing/4xn.gif
Given that, new arrivals coming one at a time should find it is cheaper 
to join that, particularly if the lower layers of protocols and 
components are FLOSS rather than proprietary, or at least are published 
and gratuit to use.
However if two orgs need to swap info, they are likely to see a 
bilateral special purpose link as cheaper, and they are right. So later 
you end up with http://www.defoam.net/writing/4x2.gif

28/5/2007 David Forslund - Check out http://healthcare.omg.org and 
http://OpenEMed.org. OpenEMed.org implements most of the OMG HDTF 
specifications from the late 90s and early 2000's all in open source. 
These are service-oriented specifications specifically designed for 
interoperability and demonstrated to work. The OMG HDTF is working as a 
joint effort with HL7 to update these specifications to current popular 
technologies and to increase their capabilities. You can read more about 
this work at http://hssp.wikispaces.org. It is an open process and, in 
my opinion, should be participated in by those in the FOSS community 
that are interested in interoperability. Participating in this process 
would ensure that open source solutions would be able to interoperate 
with commercial products, this increasing their penetration into the 
broad healthcare market. For many on this list, they've heard this from 
me before. There are some participants in the HSSP effort from the open 
source community, but there should be more and it provides some 
interesting targets for demonstrating true interoperability.

29/5/2007 Tim C - >> I believe the "intellectually pleasing" approach 
was accomplished almost a decade ago (or more) but no one seems to 
understand it or care, which is too bad. "emitting messages" is a fairly 
archaic and "assembly language" approach to the problem which keeps 
software engineers busy but does little to "solve" the problem. 
Distributed services and standards for them have been around a long 
time, and people are just starting to understand their value and power. 
I think they actually simplify the problem considerably, but I appear to 
be a minority. There I think I see the value of HDTF. OpenEMed is an 
impressive project and I am glad that its source is open.
 > However, changing Interface Definition Language (IDL) interfaces and 
having to compile them into "Stubs" as soon as new domain knowledge 
requirements appear (or the standard changes) also keeps developers 
busy. May be less frequently.
That was also my initial reaction to CORBA and the HDTF specs. I think 
it reflects the mindset of those who believe that compile-time binding 
in programming languages is the only sensible way to work (think C, C++, 
Java). However, to others who have adopted the mindset of dynamic 
programming languages (Python, Perl, Ruby, Lua etc), this seems 
unecessarily cumbersome and like a straightjacket. That dichotomy is 
also reflected in approaches to Web services, between the WS-* mindset 
(as promoted by Microsoft and other large IT companies) and the much 
looser coupling approach of REST, as used mainly be Web start-ups - for 
an introduction to the ideas behind REST, see 
http://www.xfront.com/REST-Web-Services.html
I know such loose coupling horrifies Dave and many others, but for a lot 
of sub-domains, it seems to work rather well. Most of the "Web 2.0" 
sites use a RESTful approach, as do all the Web "mash-ups" that are 
appearing. Is it useful or sufficient for health applications? That's an 
open question, but I urge open-source developers to think outside the 
square of HL7 and even outside the box of CORBA, HDTF and WS-* services 
and explore RESTful approaches to interoperability, and teh use of Web 
"microformats" like RSS, ATOM and FOAF, and the use of asynchronous HTTP 
calls via AJAX machinery in Web (or GUI) apps. They may get you a lot 
further far more quickly. OK, without much standardisation, but my 
position is that standardisation should derive from practice, not v-v, 
and that in many settings it is better to start experimenting and using 
non-standardised interoperability than it is to get bogged down with 
having to implement things like the CORBA/HDTF specs, or the nascent 
HSSP specs (which are not complete, I note) using HL7 v3.x and WS-* for 
web services. Groan! If you live and work in the richest country in the 
world which has a health care system that eats 13 or 14% of its huge 
GDP, then those approaches might be justifiable, but if you live and 
work in less well-off places, then simpler, more lightweight, 
faster-to-implement but less standardised approaches might be a better 
idea in the first instance. Then start to develop appropriate standards 
for local and regional use on the back of those initial implementations. 
Leapfrog the mess of of developed-world health IT, don't replicate it. 
Or at least chose very careful which parts you chose to emulate.
You should look at the IDL (not because it is IDL, but because of how it 
captures this in a way that changes are needed only infrequently). This 
is a characteristic of any interoperable solution. One needs to use 
standards that only change infrequently.
I'm not sure about that. Certainly in public health applications that is 
not true, nor in a lot of medical research. But I am less and less sure 
that it is true in clinical medicine as well. openEHR may be the answer 
to this issue of dynamism, but that remains to be proven in practice, 
and there are still missing technical parts to the openEHR jigsaw as 
well as many questions about the ecology of openEHR archetype and 
template definitions.
This is needed for any interoperable solution, in my opinion. I see 
nothing special other than providing a way of expressing 
interoperability in a language independent way. Certainly this can be 
done with XML and Web Services which, I'm sure will be the result of the 
HSSP work. My major "complaint" about web services so far, is that 
little concern about interoperability has been considered. Just because 
you have a web service and I have a web service, doesn't mean we can 
interoperate.
True, although the RESTful approach typically involves the minimal 
transformation necessary for a specific purpose. That works when the 
specific purpose is somewhat constrained. If the aim is to be able to 
have complete interoperability between one comprehensive clinical 
application and another, then a more structured approach as embodied by 
CORBA/HDTF/HL7v3 etc is better. However, I suspect that many real-life 
(as opposed to thought-experiment) interoperability requirements between 
applications are a lot more limited than that.

30/5/2007 David Forslund - I agree. The original GCPR project between 
the VA, DOD and IHS actually involved the identical software at all the 
sites, but configured differently at each site and were totally 
non-interoperable as a result, even though much of it was open source 
(VistA). The HDTF solution chosen dealt specifically to deal with this 
problem and it helped in the solution. HL7 had been used but HL7, 
itself, doesn't mean systems are interoperable. Low level database 
replication is likely to be a poor interoperability platform in my 
experience. If one has total control of all the sites, one might get 
away with it. Otherwise, forget it. Mapping XML structures between sites 
should work well in this situation, once one knows how to do the 
appropriate transforms.
Dave
Tim C wrote:
The other type of interoperability which hasn't really been mentioned is 
the interoperability between the same software application which is 
deployed in multiple sites. I suspect that in developing and 
transitional countries, it is that form of interoperability which is the 
most pressing problem. Using complex mappings to and from HL7 for such 
purposes may not make a lot of sense when data structures and semantic 
representations which are native to the application can be shared around 
far more easily and directly. For example, database replication between 
different instances of the same software application can be a very 
effective and effort-effective means of achieving quite extensive 
interoperability. Sure it is limited to a single type of software, but 
often that is all that is needed. But with open source, you can 
mix-and-match. For example, if, say, NetEpi implements database-level 
replication between sites which are running netEpi, then one way for a 
SAHANA site to interface to many NetEpi sites would be for the SAHANA 
site to set up a NetEpi node, have data replicated to it, and then read 
the required data items directly from their local copy of the NetEpi 
database. Or vice-versa (NetEpi reads directly from a local replicated 
SAHANA database). This is possible because a) open-source applications 
don't hide their internal details like almost all closed-source 
applications do and b) the marginal cost of setting up an instance of, 
say, SAHANA or NetEpi is very low - no additional license fees, they can 
both run on the same hardware and operating system etc.. No message 
passing at all, except at the application-specific low-level of the 
database replication. OK, privacy and other concerns may mitigate 
against that approach everywhere, but it should still be considered in 
many situations.

30/5/2007 David Forslund - Wayne Wilson wrote:
On May 28, 2007, at 5:21 PM, Tim C wrote:
Most of the "Web 2.0" sites use a RESTful approach, as do all the Web 
"mash-ups" that are appearing. Is it useful or sufficient for health 
applications? That's an open question, but I urge open-source developers 
to think outside the square of HL7 and even outside the box of CORBA, 
HDTF and WS-* services and explore RESTful approaches to 
interoperability, and teh use of Web "microformats" like RSS, ATOM and 
FOAF, and the use of asynchronous HTTP calls via AJAX machinery in Web 
(or GUI) apps.
Ok, from my some 5 year old perspective, the WEB 2.0 and Identity 2.0 
(soon to be followed by 3.0 no doubt :) ) are 'where the most 
development in Internet based computing' is taking place. It definitely 
challenges established and standards body approaches to things. My final 
words to the OMG HDTF, low these many years ago, was to that they had to 
find a way to start using then emerging (and by induction, any future 
emerging) approaches such as XML, and follow the old Internet model of 
starting simple and getting more complex only as needed. You can easily 
see the this difference by comparing two Internet standards, SMTP 
(Simple Mail Transport Protocol) and body of PKI work published by IETF.
We did include XML concepts into COAS and it actually supports a full 
super set of XML. I demonstrated this last year with simple handling of 
the ASTM CCR model without any changes in my backend COAS server. This 
totally unknown data model at the time of the COAS specification design 
was rather easily handled by the COAS model because of its flexible 
design and interface. We could easily run the COAS model over HTTP if we 
wanted, but I've never seen any good reason to do so.
Dave
  Uptake of SMTP is near universal now, despite such 'extensions' into 
complexity as MIME while uptake of PKI is still starting and stumbling. 
While there are always really good engineers and programmers who can 
take the most complex of standards and use them, my generalization (thus 
not always true, but mostly true) is that adoption of a standard is 
inversely proportional to it's complexity.
Even then, a simple core communications protocol which is general and 
can implement specific application protocols on top of it, has been 
difficult for people to use. One of the Internet's more experienced and 
seminal protocol engineers, Marshall Rose (SNMP and POP among many 
others), created just such an abstraction called BEEP. www.beepcore.org 
<http://www.beepcore.org>.
So far, the most significant work built using BEEP has been Apple's 
Xgrid technology.
What I have observed is that people take the fastest and easy route, and 
for some years now that has been various application protocols built on 
top of HTTP, including SOAP.
For a brief overview of the various components that are being used to 
build a web services architecture see here: 
http://en.wikipedia.org/wiki/Web_Services_Protocol_Stack

30/5/2007 Klaus Veil - UK parliamentary briefing document on ICT 
assistance to developing countries
http://www.parliament.uk/documents/upload/postpn261.pdf
As a reference for those who might be involved with that, and with UK 
agencies.

30/5/2007 KS Bhaskar - There was a successful proof of concept showing 
data from both CHCS (DoD version) and VistA (VA version) integrated in 
the same browser screen using Esi Objects to wrap both flavors of the 
same application so that they looked like an integrated system. I 
actually saw a demonstration of this a few years ago.
However, even though the technical feasibility was demonstrated, I 
understand that the rollout was not funded because it was not the 
officially blessed way to integrate information.
Others may have better insight into it, but perhaps too much management 
can ruin any worthwhile project, as the saying goes... [Yes, I confess 
to being a manager!]
David Forslund wrote, On 05/29/2007 06:19 PM:
I agree. The original GCPR project between the VA, DOD and IHS actually 
involved the identical software at all the sites, but configured 
differently at each site and were totally non-interoperable as a result, 
even though much of it was open source (VistA). The HDTF solution chosen 
dealt specifically to deal with this problem and it helped in the 
solution. HL7 had been used but HL7, itself, doesn't mean systems are 
interoperable. Low level database replication is likely to be a poor 
interoperability platform in my experience. If one has total control of 
all the sites, one might get away with it. Otherwise, forget it. Mapping 
XML structures between sites should work well in this situation, once 
one knows how to do the appropriate transforms.

1/6/2007 Tom Jones - If your focus is on a single enterprise and you 
believe that there is no other open source alternative, then you will be 
willing to spend time working with VistA. This is particularly true if 
your organization has access to MUMPS programmers and you have limited 
ambition to develop web-based applications that can be used by a range 
of existing devices. VistA has been and will continue to be a 
highly-regarded 20th century solution.
If your focus is on community integration across a lot of organizations 
and you want to take advantage of Java, of the WEB for multi-device 
deployment (including hand-helds), of the opportunity to evolve a PHR 
(which is beginning to be an important application in many geographies), 
of a hosted implementation so that local users need only have access to 
a browser, and of relational data base technology, then you might want 
to look at something like Tolven (www.tolven.org)
Presumably Tom's comments relate to VistA, which is the subject of the 
article.
 > * Home grown information model
What is wrong with that if the information model is 
highly-fit-for-purpose? The idea that one information model can serve 
all purposes is a pipe dream.
 > * Reasonable use of standard vocabulary, but no deployment of 
archetypes/ templates
Do you mean openEHR archetypes/templates? An interesting but as yet 
completely unproven and unevaluated approach. It is absurd to suggest 
that a system must be based on openEHR (or HL7 v3.x) archetypes and 
templates in order for that system to have any utility or worth.
 > * Semantic interoperability is sufficiently limited that, for 
example, allergy information cannot be exchanged with the DOD
That is an implementation/configuration/deployment issue - something to 
be avoided in future deployments, but not a fundamental problem of VistA 
itself. Or at least, no more fundamental a problem than exists in every 
single other available, proven, fielded health information system. > * 
Application development framework is cumbersome
Compared to what? And at least it is free and open-source. There are so 
many "non-cumbersome" development technologies which are blind alleys or 
mechanisms for complete lock-in with vendors. But sure, MUMPS is 30 year 
old technology. But then my car is full of 100 year old technology and I 
still drive it, and my bicycle is closely based on 150 year old 
technology but it still works really well.
 > * No personal health record functionality
Is that a showstopper for hospitals or clinics? Very, very few 
proprietary systems sold here in Oz offer operational personal health 
record interfaces either. There are several bolt-on or third-party 
personal health record systems, all of which have problems interfacing 
with clinical systems to some degree.
... Sort of.... VistA has MyHealtheVet for a personal health record.... 
and it's just a matter of time before it too becomes available and 
integrated with WorldVistA EHR.... there is also the option of 
integrating MyOSCAR. (JDM)
 > * Most organizations that have deployed clinical information > 
systems on MUMPS have had to turn to one of the relational > data bases 
to develop data mining and/or data ware-housing > capabilities.
Most organisations of appreciable size who have deployed clinical 
information systems based on third-normal-form relational structures 
have had to turn to dimensional data base structures to develop data 
mining and/or data warehousing capabilities. Both MUMPS and relational 
systems with large amounts of data both need to move data into a data 
warehouse which is optimised for reporting and analysis queries. That's 
life, and it is good practice. And there is no reason why you can't host 
your reporting and analysis data warehouse in PostgreSQL or MySQL 
(license costs $0) running on the same Linux server that hosts your GT.M 
database for VistA. MUMPS and GT.M is sufficiently efficient to leave 
plenty of horsepower for PostgreSQL or MySQL for the data warehouse even 
on a modest dual processor machine.
So I don't buy your objections to VistA, Tom. But I'd be interested to 
hear about alternatives (open-source, of course). Tim Churches

1/6/2007 Dr HM Goh - the URL: http://forum.apami.org

01/06/07, David Forslund <forslund at mail.com> wrote:
It was this full integration that was the goal of the original GCPR 
project some 7+ years ago. It was well along in a phased development 
cycle, when the DoD pulled out. The VA continued in a limited way which 
I think was the basis of this demonstration referred to here. Wrapping 
them on the screen isn't sufficient. EsiObjects could do much more than 
this, in my opinion.

3/6/2007 David Forslund - I agree. I don't think there is such a thing 
as "spontaneous semantic interoperability". The major effort of the GCPR 
was to provide semantic interoperability between essentially identical 
systems (VA, DoD, IHS) that had different semantics. They were 
developing a metadata repository that would do the mapping so that each 
site could see the "foreign" data in their on semantic view. Just 
running the same system at multiple locations is no guarantee of 
semantic interoperability. Interoperability takes deliberate effort, but 
with the right representations of the data and the processes involved, 
the effort can be made "easier". I think it requires more than data 
translation, but process translation, too.