I"m responding with a little more detail than normal, since I'm in an airplane on the way to D.C. with a little more time on my hands than I usually have.

At 10:58 PM 11/11/2000 -0800, Andrew po-jung Ho wrote:
Hi Dave,
  Excellent points!  Since federated systems are exactly what I am interested in implementing, I will do my best to address some of the issues below.
---
On Sat, 11 Nov 2000 22:49:49   David Forslund wrote:
>How does one create a federated system with Zope so that a medical record
>could be created
>from multiple repositories working together? 

Inter-node communications can go through CORBA / XML-RPC / SOAP / HTTP etc. This is not different from any other application server or system.

Great.  Then we need standards in this area consisting of well defined interfaces.   The functional
part of those standards is what CORBAmed (OMG) has been working on.  This requires "implementing" these standards.   Such implementations are already available for those who don't want to write their own. (cf.,
http://openmed.sourceforge.net).  I haven't seen a way to express those in Zope except through the
underlying Python layer.  There is an IDL binding for Python.    So this would mean a lower level
module for Zope which would handle the internode communcations. 


> Especially, if each does it a little differently?

Now, you know very well there is no magic bullet for this (except CORBA?).  The solution must include some type of metadata standard.  This has nothing to do with whether the implementation is done with Eiffel, Zope, C++, etc.

Exactly, but there has to be a standard for interoperability.  I know of no other standard for "functional" interoperability than the CORBAmed standards.  They presume a "meta"data standard from various sources.


>Zope seems to be a deployment platform but hardly a system development environment.

Not sure what you mean by that.  If I can *develop* an application using Zope, then I think it qualifies as a "development" environment.  It may not be the *preferred* development environment for all possible applications (for example- it is probably not suitable for developing the next version of Quake), but that does not say much.

How do you develop a CORBA application with Zope?  How do I deploy an application in Zope independent of the Web?   Particularly since an application may consist of a number of distributed components that must work together.   The communication channel between the components shouldn't have to rely only on the fragile web (http/https) environment.

>It should be possible to drop a GEHR kernel into Zope and have it provide services for it.

Do you mean like an ORB?

The ORB could be viewed as enabling the "dropping in" of a kernel such as GEHR.   This should be
done in a standard, component-based way.  


>If I have a Java application, how do I use Zope as an application server
>for that application?

Zope does not have a built-in JVM and thus does not run Java.  Thus, server-side Java is not supported.  However, it can serve Java Applets just fine.

Can I run JPython within Zope?  It sounds as though Zope doesn't support other languages at least directly.  Does it support CORBA?  Or is that done through Python?  Are there any CORBA-based Zope applications that have been written?   If not what is being done for interoperability?  We have already demonstrated cross-vendor interoperability with a number of CORBAmed standard applications.   And this is with essentially no configuration required.  (I.e., we don't have to have a separate agreement on paper as to how to interpret the data we see).


>How do I accommodate "legacy" systems with Zope?

Depends on what "dialect" your legacy system speaks.  If it speaks SQL, then a database adapter will work.

But not all SQL is the same.   What is the standard interface here?   How do I map one person's data model to another.  I know of essentially no legacy applications that use a standard data model.


>How do I discover where my medical records are with Zope?

Hopefully with a PIDS - perhaps like the one your AMIA paper describes. :-)

But how does Zope communicate with PIDS?   You actually need more than I described.  We are
working on the (Health/Heterogeneous) Information Locator Service to provide the additional functionality
required.   I don't have the space to elaborate on this here.


I am really looking forward to implementing it!!!

>Is my communication protocol forced to go through http with Zope?

No.  XML-RPC, HTTP, and FTP are supported natively.  I think there may be CORBA capabilities too.  It seems pretty easy to extend - I think it has great potential. 

It would be nice to see the CORBA capabilities.  FTP is hopeless as a system-to-system protocol and XML-RPC is  not a standard and also hopelessly inefficient.  And those protocols don't give much hope for interoperability since
they, by themselves, don't define standard functional interfaces.


>I don't see how one can write an application in DTML. 

Tim Cook's FreePM and my OIO are both examples of applications written in Zope.  FreePM uses ZClass and OIO uses 100% DTML.  You can download a copy of each from sourceforge and see for yourself.

I've downloaded OIO and Zope, but still don't see how to write an application in DTML yet.  Writing applications in a  "markup" language seems a little strange to me.  It seem more like a configuration and display problem being solved than an application.   Writing directly to SQL from Zope (or anything else, for that matter)  and publishing web pages is not a good architectural approach to writing distributed applications. (cf. Chapter I in "Managing Healthcare Information Systems with Web-Enabled Technologies", ed. Lauren Eder, Idea Group Publishing, 2000,
"The Impact of the Global, Extensible Electronic Health Record", David W. Forslund, Los Alamos National Laboratory; David G. Kilman, Theragraphics, Inc.).   Presentation should be totally separate from the data storage mechanisms.  Basically a multitiered architecture is required.     How does Zope support a multitiered architecture with standard interfaces in the middle tier?   


>Especially one that
>might
>need to communicate cooperatively with a number of other heterogeneous
>applications to create a medical record for a patient.

I think the keyword here is "heterogeneous".  Currently, OIO exports
metadata in XML format.  This means compatible systems are defined by
their ability to use that metadata.  Data interchange is easy among
compatible systems since metadata is transportable.  This is really no different from any other data interchange schemes.  Two systems that wish to communicate must have at least one shared metadata format.  It could be TCP/IP, CORBA, ASCII, OIO-forms, etc.

But standards for metadata are critical here so that we can easily interpret them.  But more than data standards are required.  Functional standards are required so that one can understand the semantics of the request.  This could be done with XML (e.g., in SOAP), but it isn't needed, since much work on creating standard functions has already been done complete with a robust transport protocol.  And this can easily be translated into XML as needed.


>I believe we are past the days of building new standalone applications, but
>need
>to build to a specification that allows one to do collaborative
>healthcare. 

I agree 100%.  That is why I chose to use Zope and hope to work with you and OpenEMed to interchange metadata and data.

And use standard functionality, I hope.


>The Gnutella or Napster models are closer to what is needed for healthcare. 

Can't agree with you more.  I think your PIDS design is basically a peer-to-peer system.  Are you going to the O'Reilley P2P conference? 

PIDS (especially in its federated mode) is a peer-to-peer system.  There is nothing new about peer-to-peer systems.   P2P may be a little new to a world with a web view (which started mostly as a read-only publishing environment).   I don't see any need to go to the O'Reilley P2P conference.   P2P is what CORBAmed has been doing for years (as well as other parts of the OMG).

The GEHR model also takes mobile patients into consideration.

>People move around and get treated in many places.   They all shouldn't have to be running the identical software for them to interoperate.  They need standard
>interfaces to be implemented.

Right.  I hope OpenEMed/OIO will contribute to providing that standard interface.

Some of it is already defined.  PIDS/TQS/COAS/CIAS/RAD are already standards.   There is more work to be done and I would like to see the openhealth community actively contributing to it, perhaps by demonstrating interoperability and additional new interfaces that may be needed.   Which of the above interfaces are available in OIO?  We have had a PIDS server on the internet for 2 1/2 years for any one to connect to. 


>I need to understand the object-model in
>Zope, since
>it appears not to be particularly object oriented (It does use SQL, which
>isn't particularly
>object oriented, for example).

The SQL is used to link to external data sources only.  Internally, Zope is composed of objects with inheritance (called acquisition for some reason), properties, methods. :-)  The entire code tree is a big object.

OK.   Is there a mapping of Zope to CORBA IDL?   Can I design my application UML and deploy automatically to Zope?  

Thanks for the opportunity to discuss these important issues.

Andrew
---
Andrew P. Ho, M.D.
OIO: Open Infrastructure for Outcomes
www.TxOutcome.Org
Assistant Clinical Professor
Department of Psychiatry, Harbor-UCLA Medical Center
University of California, Los Angeles


Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

David W. Forslund                               [EMAIL PROTECTED]    
Computer and Computational Sciences             http://www.acl.lanl.gov/~dwf
Los Alamos National Laboratory          Los Alamos, NM 87545            
505-665-1907                                    FAX: 505-665-4939

Reply via email to