3 Dynamic links

Paraglide's dynamic link structure handles two sorts of links: those that maintain consistency between different elements of a case object; and those that import document data. Our fundamental approach is to try to unify the link framework, so that we can cope with change-sensitivity in a principled way. Therefore all links are viewed as associations that relate a source object to a destination object with respect to an aspect, or operation, via a link function:

 link = <source, destination, operation, link_function>

A link goes from a given source, or set of sources, to a given destination, or set of destinations. It applies a link function to transform the data from the source, and then performs some operation on the destination. For instance, a link could go from a lab system serving blood test documents to a local blood test results object, extracting all blood results from the document and transforming them into Java objects, before adding them to the blood test results collection.

3.1 Local and remote sources

There are two sorts of link source, document and value sources. Note that these sources are not simple documents or values but (remote) services or (local) objects that will provide new documents or values over the duration of the link.

A link's local source is an active value and, indeed, all potential local sources, the contents of the service store, have attributes that are active values. Links employ listeners to be notified about changes in a local source.

In the Paraglide system, information is transmitted between services as documents, i.e., structured text. A link's remote source requires a specification of which services to query for relevant document(s) and what to say to the service to get such documents. For instance, it may specify an SQL query to extract data from a database service. These documents may well contain information relevant to a number of local links. This information must be extracted from incoming documents in order to resolve the links dependent on that document.

3.2 Updates and smart pasting

Implicit value updates are straightforward; simply set the value, although with a collection destination we can reset the collection, add or delete one or more items to or from the collection. In the case of explicit updates, the link performs a notification operation based on the results of a summary function that specifies how to summarise the source document for the user . It also contains a set of sub-operations that specify what to do if the notification is accepted. Each of these sub-operations may itself extract some data from the source document.

The user interface implements an unusual paradigm for handling such notifications. Via visual cues in the interactors, the availability is signalled of unread information in the form of read-only documents. The user has the option to inspect the data by reading a document (for example, a Full Blood Count report), and may elect to close the document without copying any data into the anaesthetic assessment or "paste" the information into the assessment with a single button-press, causing the execution of the link's acceptance operations.

Although it may appear to place a small but unnecessary burden on the user, the paradigm gives the user control of data entry in a natural manner, since the task sequence, "browse documents; select and inspect a document; copy data" mirrors current practice in paper-based working. It also ensures that the user has always inspected and endorsed any information written into the assessment, a desirable situation with respect to clinical records, since the clinical user will have to take full responsibility for the content of the assessment.

3.3 Link specification

Because links depend on potentially variable relationships and because they must be created at run-time, we also include link specification as an explicit element in the architecture. A link specification object holds the information necessary to create a link of a specified type, defined in terms of the types of its arguments.

 linkspec = <source_type, destination_type, operation_type, function_type>

Link specifications are held by resource managers and used to instantiate links when called upon by objects in the service store or, indeed, as the outcome of a link operation.

To allow configurability, link specifications are written in XML. They can be stored in documents and transferred around a network. New links types can be added without the need for recoding. They can, in fact, even be added while the system is running, thus enabling dynamic reconfigurability. For instance, if a new document type were to be added in a hospital, an update could be broadcast to allow all Clinical Assistants to interpret it, without any need to disrupt the users of the system. We are currently using this approach to implement a dynamically reconfigurable audit system in which links specification are downloaded that, when instantiated , create a pathway for the deployment of an audit questionnaire and the transmission of its data back to the audit service.