5 Questions about the GALEN Terminology Server

5.1 What is the GALEN Terminology Server?
5.2 Is it CORBA-compliant?
5.3 Is it XML-compliant?
5.4 How many servers might I need for a hospital?
5.5 Why do I need a GALEN Terminology Server?
5.6 Where can I buy one?
5.7 Won’t I become dependent on that software vendor?
5.8 I'm interested in GALEN, but don't want the hassle of buying a GALEN Terminology Server. Can I manage without one?

5 Questions about the GALEN Terminology Server

5.1 What is the GALEN Terminology Server?

The GALEN Terminology Server is a software device which implements the GRAIL language, and stores and manipulates the GALEN Common Reference Model (which is itself written in GRAIL). The GALEN Terminology Server is used in two ways: it makes it possible to build and maintain the model, and it delivers services to clinical applications.

Different implementations of the GALEN Terminology Server have been produced through the GALEN Programme, and are now available through software vendors associated with Open GALEN. One of the roles of Open GALEN is to maintain a specification of the GALEN Terminology Server. Open source compliance testing suites will exist by which the products of software vendors may be assessed. The major part of the GALEN specification is concerned with the definition and behaviour of the GRAIL language, and with describing the kinds of services that must be available to client applications; vendors are free to extend the services provided by their implementation, and to choose how to deliver those services (e.g. using one or more industry-standard software component technologies).

Standard services provided by the GALEN Terminology Server include:

Concept identification. E.g. do you know about the "leg"? (this is represented informally as the kind of question a client application may make of the server)

Concept management and specialisation. E.g. what is known about the leg? What bones does it contain? if they are broken, how might they be clinically described? This might lead to information suitable to generate a data-entry form enabling a clinician to enter details of a fractured femur

Language: what is a French language phrase for the combination of a severe fracture of the neck of the left femur?

Concept reference: what is an identifier for this concept that could be stored in an electronic patient record, or transmitted to other clinical systems?

Coding: what is the closest ICD code for this concept?

Extrinsic: is there any relevant literature known about this condition?

5.2 Is it CORBA-compliant?

Or COM/ActiveX (insert your favourite object component technology here)-compliant…

The GALEN Terminology Server architecture fits very comfortably with the notion of client-server computing, and commercial implementations now use standard object component technologies to deliver their services. (Early implementations of GALEN Terminology Server pre-dated the widespread emergence of easily usable component technologies, and relied on socket or DDE connections to communicate).

5.3 Is it XML-compliant?

The emergence of XML as a widely-available, customisable interchange standard provides another industry-standard part of the overall architecture in which the GALEN Terminology Server sits. We expect that commercial implementations will provide output in XML-format for easy transmission and interchange.

As with the answer to the previous question, the emergence of industry standard component and interchange technologies allows the GALEN Terminology Server implementors to concentrate on their core competencies, whilst integrating more easily with client applications and other existing infrastructures.

5.4 How many servers might I need for a hospital?

In the early stages of the GALEN Programme, it was anticipated that the GALEN Terminology Server would be a large, networked resource, shared between multiple running applications. Whilst this is still a valid scenario, currently available implementations have often provided a unique instantiation of server for each application: this is possible as the server footprint is very low, and advantages accrue for having closely coupled applications and servers.

It is up to the specific installation environment, pattern of use, etc., to determine the optimal arrangements.

5.5 Why do I need a GALEN Terminology Server?

If you are a hospital or health service manager

Information should be better and more complete. It will be much easier to derive management information from patient-based data collected at the point of care, and easier to transform that information so that it fits the management point of view.

Applications will be more open and work together more smoothly. As the GALEN Technology becomes more pervasive, it should be much easier to ‘mix and match’ applications from different vendors. Ultimately, information systems should be more cost effective.

If you are a clinician

Clinical applications should be more clinical and work more naturally. They should be easier to use, provide more detailed clinical information, and link together better. They should be more flexible and ‘less computer-like’ in the way they handle language. There should be little or no need for manual ‘coding’.

You should never see the GALEN Terminology Servers themselves; they will be behind applications. The greatest possible success for the server is that you never notice it — things just work the way you expect them to.

If you are developing coding systems or nomenclatures

The GALEN Terminology Servers and their related tools make it easier to develop, cross reference, and restructure classifications and nomenclatures. They make it possible to automate important parts of the process, and as the system grows, they allow users to tap into a growing body of pre-structured models plus the tools to re-organise those models from many different alternative points of view.

If you are developing clinical applications

Applications should be easier to develop, maintain and integrate because:

Operations involving terminology can be delegated outside of individual applications; separating applications from the models which support them is a prime, and highly successful, result of the GALEN Programme.

Development will be based on re-usable concept models which will, increasingly be available from pre-existing repositories.

Systems will be more open. Communication with other applications using the shared structures should be easier and more complete. It will be easier to incorporate modules developed elsewhere.

Many of the tasks of updating the system as new developments appear should be easier, because much of this work will be done by those maintaining the GALEN Common Reference Model.

It will be much easier to tailor systems to the local requirements and local languages. The potential market should therefore be larger.

5.6 Where can I buy one?

From a software vendor associated with Open GALEN. Contact them ( help@opengalen.org ) for details of current vendors.

5.7 Won’t I become dependent on that software vendor?

As with any technology that you use, if it becomes an integral, and critical, part of your business, you will become dependent on the supplier of that technology. However, there is some good news.

Firstly, there is more than one source for the technology; Open GALEN publishes a specification, which is open for re-implementation, and there are already two separate commercial versions available for use. Furthermore, the technology is becoming more widely understood and used in other industries, so we expect that the availability of the software technology will only increase. It is true that there is a single source for the GALEN Common Reference Model itself, but this is to maintain the industry-wide advantages to be gained from use of a common model. Open GALEN exists as an independent body to ensure the model’s continued development and maintenance.

Secondly, there is no need for a ‘big-bang’ approach to using the GALEN technology. As described in the answer to the next question, there are ways of taking advantage of GALEN Technology without becoming dependent on particular pieces of software that you do not control.

Open GALEN is willing and ready to work with you to investigate and demonstrate, using small experiments or workshops, how your business could take advantage of GALEN Technology.

5.8 I’m interested in GALEN, but don’t want the hassle of buying a GALEN Terminology Server. Can I manage without one?

Yes and no. No, in that to take full advantage of the GALEN Technology, you will require access to the GALEN Common Reference Model via a GALEN Terminology Server, which will allow you to use dynamic functionality such as re-organisation, automatic classification, etc.

However, you don’t always have to use a server: we can make some of the information stored in the model available as a static data-set, in comparable forms to the way existing coding and classification schemes are normally delivered. In that case, you will be taking advantage of the GALEN Technology in that the static data-set will be more maintainable, coherent, complete, and, because it has been automatically derived from the underlying GALEN Common Reference Model, it can be easily configured for your specific requirements.

Making the impossible very difficult, ©OpenGALEN.org, All rights reserved