Virtual Care team Network Architecture
Draft Version 2.2, 11 Feb 2011, Etienne Saliez, with help from
- This note summarize the architecture proposed by the project "Collaborative
Care Team in Open Source" of the ISfTeH, International Society
for Telemedicine & eHealth.
- A patient centric approach. Indeed the follow-up of any
patient may need any kind of care, maybe having multiple problems at
the same time.
- A very modular architecture intended to allow the integration
of existing medical softwares available in open source, as well to
allow distributed developements and maintenance at international level.
- A seamless approach, the ordinary user will just see an
ergonomic human interface and will not mind of the architecture behind
- Architecture based on 4 levels, (1) User's browser, (2)
Presentation, (3) Application Core Logic and many (4) Sevices,
connected by means of formal interfaces.
These components may but do not need to be in the same machine.
For example the IPATH service would usually be located thousends
kilometer away. The users interface is in priciple always in web
mode, regardless if the the other layers are located far away through
Internet, in the same building, or even a subset of the services in the
same laptop in case Internet would not at all be available.
( 1 ) User (red)
- Users need only a standard web browser, as Firefox, available
on all usual operating system platforms.
( 2 ) Web Presentation layer (yellow)
- A web server focusing on the presentation issues.
- Essentially the conversion of logical information into visual
pages intended for the users, usually in XHTML format.
- A kind of "front end":
- Communicating with the core layer through formal interfaces:
- Calling application transactions in the "core" as
- Receiving information back, to be displayed back to the
- The presentation layer is expected to be the object of the
most frequent requests for adaptations.
- Security dealing with encripted communications.
- Presentation issues in function of:
- The linguistic and cultural environment.
- The professional profile of the current user. Indeed
doctors and nurses require different presentations to be extracted from
the common patient database.
- Specialized presentation requirements related to situation
dealing with specific diseases as AIDS, tuberculose, malaria, cancer,
Remark: from an informatics point of view the goal is to avoid to make
each time completely new softaware projects from zero, for particular
professional profiles and deseases.
- Local preferences and existing procedures.
- The device type. Usually the browser of a standard
computer, but could also be
a mobile phone, a voice machine, as well the representation of a
in a given format, as for example a HL7 messages.
- Current experimental prototype:
- Essentially the conversion of
information coming back from the "core" layer, using a template system,
currently Chameleon templates, http://chameleon.repoze.org/
- Some elements of experimental prototype are already
available at http://vctdemo.gorfou.fr/
, although still very incomplete and containing errors. (user= "guest",
( 3 ) Core Logic layer (green)
- The generic application logic of basic common services as
required in most
situations of patient care.
- The core can be called by the front end.
- Management of generic functions as:
- User authentication, authorization profile, ...
- Patient identification;, "care team" management and "Role
Based Access Control".
- The management of "Patient Items" of any kinds:
- Support of a "Problem Oriented" approach, an important
factor intended to support education objectives. Indeed the local
user directly in contact with the patient should first formulate
explicitely his/her current vision of the problems, before asking a
second opinion to a remote expert.
- The main types of Patient-Items are here Observations,
Problems, Actions, and Contacts, each of these groups being
subsequently derived into many more specialzed classes.
- Multipath navigation trough related patient Items and
related medical knowledge. Semantic web technologie are
considered here, i.e. no more the limitations to strict hierarchical
- A provisional model is available at http://www.chos-wg.eu/Software/Modules-Overview.html
. First the "common generic requirements" and then the
"additional requirements" in function of particular situations.
- Call of external services:
- The core can call external "services" based on external
open source components, developed and maintained by external
- 2 options:
- Send requests and receive information to be managed, i.e.
showed in the prestation layer and stored in the patient data base.
- Possibility of temporary full delegation to an external
service, the user interface from the service provider being simply
tramitted in a frame of the front layer.
- Current experimental prototype:
- Written in Python, http://www.python.org/
, communication between the layers by means
of "XML-RPC" protocols, http://www.xmlrpc.com/
, a neutral approach allowing communication between modules written in
different programming language, as PHP, Java, etc...
- Every layer is accessible on a distinct network address,
front-end, core and external services, regardless if in the same
computer or somewhere else.
- The network philosophy is to avoid unnecessary
centralization. Most traffic is expected to be at regional level,
but when necessary regional servers will have the possibility of
exchange information with other servers in a larger international
( 4 ) Services layer (blue)
- Reuse of available medical software modules in open source.
- External services will receive requests from the core and
provide information. A few adaptations will be necessary in order
to accept theses
requests and provides responses in a technical neutral way, as XML-RPC.
- Formal interfaces agreements will allow to delegate
developements and maintenances of modules to groups based in other
- Some considered services:
- IPATH lab:
- If a patient need pathology, the coordinating "core" will
contain only a small link to the IPATH system and delegate this lab
business until a final report will become available.
- Current applications in the Philippines:
- Handling of administrative issues as declaration of
services, tarification, billing, book keeping, human resources, stock
- Could be processed by the comprehensive open source
, while only tables and parameters will need to be adapted.
- Remarks: a project also based on similar
principles of front-end web server and a back-end core processing.
- Additional services as could be required by disease
- Medical images processing:
- Could be provided by OsiriX, an advanced open source
package for radiology
processing, developed at the university of Geneva, http://www.osirix-viewer.com/
- Drug interaction database:
- Epidemiological packages: