1.2                         Components and Artefacts

The messages in this manual are defined and documented using the following components and artefacts:

·        Storyboards

·        Application Roles

·        Trigger Events

·        Interaction Diagrams

·        Interactions

·        Message Types

·        Refined Message Information Models (RMIMs)

·        Tabular Views

·        Schemas

·        Example Messages

Each of these and their role in the manual is described below.

1.2.1                    Storyboards

These are used to describe a healthcare scenario that results in one or more of the documented messages being sent.  Storyboards are intended as an aid to understanding how the messages interact with ‘real-life’ situations, but are not intended to be representative of how healthcare is delivered in all organisations that use the messages or provide an exhaustive set of circumstances in which a message may be sent.

Where applicable, hyperlinks are provided to interactions that may result from the activities described in the storyboard.

1.2.2                    Application Roles

Application Roles are used by within HL7 v3 as a basic unit for conformance.  A role is defined by a set of sender and receiver responsibilities that must all be met by an application that claims conformance to that role.  These responsibilities are limited to the way in which the application handles messages and do not explicitly specify how an application processes or stores the data contained within a message.

Links are provided (via the  icon) to those interaction in which the role acts as sender and/or receiver.

[Note: the precise nature of conformance and conformance testing within HL7 v3 is the subject of ongoing discussion].

1.2.3                    Trigger Events

A trigger event is the condition that initiates a messaging interaction.  The ‘event’ is usually a point in time (often characterised by an information state change), rather than a process -  for example ‘Completion of an Admission’ and not ‘Recording an Admission’.  The specified trigger events shall be the only events that trigger the interactions (and related messages) in this manual.

A link (via the  icon) is available to a list of interactions by trigger event.

1.2.4                    Interaction Diagrams

These diagrams illustrate the interactions that may occur between a pair of application roles.  No sequence is implied by the order in which interactions appear on the diagrams and although some of the interactions may be related (eg. request/response pairs) this is not always the case.

Hyperlinks to the Application Roles and Interactions are provided.

1.2.5                    Interactions

Interaction definitions specify the links between a number of other components and artefacts that support the sending of an actual communication.  These are:

·        The Sending and Receiving Application Roles that must support the interaction

·        The Trigger Event that initiates the interaction

·        The Transmission Wrapper, Control Act Wrapper and (where applicable) Message Type that together make up the communication

·        Where the Receiving Application role has specific messaging responsibilities, these are also listed

Interaction Specifications are a normative component of this manual.

Hyperlinks are provided to the artefacts referenced by the interaction definition.  A link (via the  icon) is also provided to the Interaction Schema, to which all wrapped messages for the interaction shall conform.

1.2.6                    Message Types

Each message type is defined within the ‘Message Definitions’ section of each domain.  The specification of each message type comprises the RMIM diagram (via the  icon), Tabular View documentation (), Schema () and Examples ().

1.2.7                    RMIMs

An RMIM provides a diagrammatic view of the model that underpins a message.  RMIMs are refinements of the abstract HL7 v3 RIM produced using the HL7 v3 toolset.  A full explanation of the models is not appropriate here and those requiring a more detailed understanding of the modelling approach are advised to read ‘HL7 Messaging Components’ in the ‘HL7 v3 Guide’ section of the HL7 v3 Ballot Pack.

Classes within an RMIM diagram provide a hyperlink to the relevant section of the Tabular View.

1.2.8                    Tabular Views

This documentation provides additional details about the various classes and attribute that are contained within a message model.  The tabular view comprises two columns:

·        The left column lists all of the classes, attributes, associations etc. that appear in the message

·        The right column provides additional information about the use of these components, such as options for populating an attribute, XML fragment examples etc.  This text is provided for guidance only and if there are any discrepancies with Datatypes, Vocabulary or schemas, then these other components should take precedence.

From within the tabular view, entries in the left column provide hyperlinks to the Datatypes section for more details of the valid formatting of attributes and the Vocabulary section for information about valid values for coded attributes.

1.2.9                    Schemas

The schemas referenced from the message type definitions represent the structure of the ‘payload’ component of a message (just a communication without its wrappers).  In general, these schemas are automatically generated from the message designs by an HL7 tool, although occasionally minor manual changes may have been made.  While these schemas are not strictly normative, it is a requirement that the payload of all messages validate successfully against the appropriate schema in the manual.

All schemas are available as .xsd files in the ‘Schemas’ folder within the manual file structure.

1.2.10               Example Messages

Example messages are provided to show how a message could be populated with data.  The flexibility within many of the message designs, HL7 v3 datatype definitions and the variability of clinical scenarios mean that is impossible to accommodate all possible options.  Where practical, multiple examples are provided, but even these cannot show all possible combinations.

Examples are provided for illustrative purposes only and have had no clinical validation.  Where they are not compliant with other parts of the manual, these other parts of the manual should take precedence.