Executive Summary

British Telecom (BT) Approach to NHS NPfIT Semantic Processing

1. Transaction Messaging Service (TMS)

TMS uses XML Accelerators to interpret the ebXML and HL7 message wrappers. TMS does not interrogate the payloads.

Values are retrieved from the wrappers using Xpath queries that generally rely on consistent paths and consistent XML Element Names.

1. Whether the application uses fixed and default values (those values are indicated as mandatory attributes with fixed value in MIM 2.3)?

TMS does not used fixed or default values.

2. Whether during the message processing the schema corresponding to the incoming message is used for any reasons?

HL7 schema are not used (although messages are validated against ebXML schema

3. Whether during the message processing fixed values are searched for e. g. by xPath in the incoming message?

Fixed values are not searched.

2. e-Transmission of Prescriptions (ETP)

1. Whether the application uses fixed and default values (those values are indicated as mandatory attributes with fixed value in MIM 2.3)?

ETP does not use fixed or default values.

2. Whether during the message processing the schema corresponding to the incoming message is used for any reasons?

HL7 schema are not used.

3. Whether during the message processing fixed values are searched for e. g. by xPath in the incoming message?

Fixed values are not searched.

3. Personal Demographic Service (PDS) / ACF

PDS/ACF adapters use XSLT transforms to create Value Objects for communication to PDS and ACF.

1. Whether the application uses fixed and default values (those values are indicated as mandatory attributes with fixed value in MIM 2.3)?

As for PDS and ACF, there are certain nullflavours that are checked for disability codes in Update messages(think this is MIM 2.3 specific). For responses, too, PDS and ACF Adaptors explicitly put in the default or fixed values in the response messages.

2. Whether during the message processing the schema corresponding to the incoming message is used for any reasons?

No the schema is not used.

3. Whether during the message processing fixed values are searched for e. g. by xPath in the incoming message?

For PDS messages certain nullflavours are checked for disability codes in update messages (think this is MIM 2.3 specific). There are also certain attributes used like use="L" or use="A" in Person name for PDS messages. Again these are not default or fixed value but attribute values.

4. Personal Spine Information Service (PSIS) & Clinical Service Application (CSA)

CSA uses HL7 message wrappers. PSIS & CSA do interrogate the payloads.

Values are retrieved from the wrappers & the payloads using XSLT and Xpath queries that generally rely on consistent paths. Where possible, PSIS and CSA avoid relying on inconsistent XML Element Names.

1. Whether the application uses fixed and default values (those values are indicated as mandatory attributes with fixed value in the MIM)

PSIS & CSA do use fixed or default values.

2. Whether during the message processing the schema corresponding to the incoming message is used for any reasons

PSIS and CSA do not use HL7 schemas (It is assumed the sender is responsible for sending valid messages.) (HL7 schemas are used to validate test data.)

3. Whether during the message processing fixed values are searched for e. g. by xPath in the incoming message

Fixed values are searched by xPath. CSA and PSIS search incoming messages for fixed values.

5. CSW Record aggregation using existing clinical data – A. Wrightson

This example draws on a real proof-of-concept project undertaken by CSW in 2004. It shows in particular real examples of people working "in the XML layer", and also taking measures to overcome practical problems with existing v3 XML. I believe that this example brings out issues and ways of working that are relevant to the adoptability of a new ITS for relatively local integration, for example within a group of related organizations, or within a medium-sized geographic region (remembering that organization of healthcare varies a lot internationally).

The overall shape of the problem is shown in the accompanying diagram -

The task is to integrate clinical information from existing systems to provide a single integrated electronic patient record. Note this is a record repository not a clinical "EHR system". CDA structured documents were selected as the common target data format for this integration; a key feature for this purpose was that CDA accommodates a range of structured-ness of data within a uniform framework, including: 1) uniformly structured patient and provenance information 2) clinical content in human-readable form as a valuable working minimum for record reuse by humans across healthcare organizations 3) clinical content in a structured, coded form for reuse by computers, to the maximum extent permitted by the existing data

Three geographically distributed sites participated, using existing clinical applications of varying age and capability. From these applications, clinical information was extracted in whatever form was possible, as CSV or ad-hoc well-formed XML. (The data was made unidentifiable with respect to real patients, but kept real in other respects.)

Sites 1 and 2 sent their extracted data via a message broker that converted the ad-hoc extracted formats into corresponding target record formats. At site 3, a local expert developed software for direct data conversion into the target record formats.

There were several distinct clinical domains represented, with records for each domain coming in from more than one site. For each clinical domain, a CDA-conformant XML structure was defined (by an XML expert and a clinical analyst working together) in the central project team; express (and necessary) aims of this work included 1) shielding the rest of the project team from the full complexity of HL7v3 and CDA, by providing moderately complex XML structures (and clinical guidance) well within their existing skills; 2) making the XML schema (the fully compiled schema, not just the schema document) for each XML document type sufficiently small and simple that the message broker's native mapping tool (and our message broker expert) could set up the data conversions required in the broker node.

The CDA-conformance of the simplified XML was tested to high confidence using example messages, however the level of confidence achieved was only possible because the XML was pretty simple. Tooling support to do such simplification on the CDA model rather than as a knife-and-fork job on a complex set of schema docs would have been welcome; such a tool would have had to be able to generate simplified schemas too, using the "just as much schema as I need" principle of reusing schema components.

The fact that all the various records aggregated in the repository were CDA documents was used to provide examples of cross-patient and cross-site reporting and analysis. I understand that the partial and varying presence of fully structured coded records was intended to be accommodated by using analysis methods and presentation of data adapted to this situation - however I cannot comment in detail on that as I'm not an expert in such analysis.

3.