2        Navigation Tabs  

2.1        Navigation Tab behaviour

When the mouse is over a tab the font colour changes and a screen tip appears.

When you are viewing a page after clicking on a tab the font changes colour to indicate which page you have selected.

When navigating though multiple tab levels the font colour changes and the different tab background colour gives an indication of where you started from.

In the example above the trail is Message Definitions -> Care & Support Planning Assessments -> TMS Implementation.

2.2        Navigation Tab Levels

The navigation tabs within the specification are at 3 levels, the following section describes the level 1 tabs. The purpose of the artefacts relevant to each tabbed page is described later.

2.2.1        Level 1 Navigation Tabs

1. Overview - This takes you to the overview page which gives an overview of the domain
2. Messages definitions - This takes you to the definitions of the messages and maybe further divided into sub tabs for some of the larger messaging domains.
3. Generic - This page details artefacts that are generic in nature, this means they are used across many specifications and usually are related to common functionality.
4. References - This page provides details of artefacts which are used for reference and analysis.
5. Glossary - This provides a explanation of terms and acronyms used with the specification.

2.2.2        Level 2 Navigation Tabs for the Message Definitions Page

Level 2 navigation tabs for message definition navigation tab.

The navigation tabs in this section will be one of two formats.

In most domain message specifications the level 2 navigation tabs detail the implementation specific information.

Level 2

1. TMS Implementation - This page details the information needed when using TMS as the transport layer for implementing the message flows.
2. ITK Implementation - This page details the information needed when using the ITK distribution envelope over various transport layers when implementing the message flows. This can be web services, DTS or other layers.
3. Configuration Profiles - This page gives information about versioning of configurable items.

Level 3 - Not used

On large message domains where the messages are divided into phases (HSCI for example) the level 2 navigation tabs sub divide the domains into phases and the standard level 2 navigation tabs which detail the implementation specific information are moved to level 3.

Level 2

The navigation tabs here are used to sub-divide the domain message phases , with each phase having a separate set of level 3 navigation tabs

Level 3

1. TMS Implementation - This page details the information needed when using TMS as the transport layer for implementing the message flows.
2. ITK Implementation - This page details the information needed when using the ITK distribution envelope over various transport layers when implementing the message flows. This can be web services , DTS or other layers.
3. Configuration Profiles - This page gives information about versioning of configurable items.

2.2.3        Level 2 Navigation Tabs for the Generic Page

1. Generic CDA - This page details the information about generic CDA artefacts.
2. Data Types Specification - This page details the various data types used by the messages.
3. Nullification - This page details the generic nullification process (withdrawal) of CDA documents.
4. TMS Infrastructure - This page details the wrappers used when the messaging is implemented over TMS.
5. TMS infrastructure CMETs - This page details model fragments (CMETs) used in the TMS infrastructure models.

2.2.4        Level 2 Navigation Tabs for the References Page

1. Domain - This page details the reference files available for analysis etc for the domain.
2. Nullification - This page details the reference files available for analysis etc for nullification.
3. TMS Infrastructure - This page details the reference files available for analysis etc for Infrastructure.

3        Explanation of purpose of each page

The typical DMS consists of 28 main pages nested as below:

3.1    Overview Page

This page gives a brief description of the purpose and aims of the message flows for the domain.

3.2    Change History Page

This page gives details of all the changes that have been made to the specification.

3.3    Message Definitions Page

This page details the message(s) that are used by this domain, below is a typical message table.

1. Message name.
2. Message identifier.
3. Link to the R-MIM (message model).
4. Link to the tabular view (which is the message model documentation).
5. Link to the message XML schema used for validation of message instances. The actual format / use of this schema will vary dependant on whether the message is CDA (2 levels of validation) or Non CDA (single level of validation). The Interaction table will provide more detail in this area.
6. Link to the list of templates used by this message (where templates are utilised in the message).
7. Link to the list of reference templates used by this message (where templates are utilised in the message).
8. A link to the MIF (XML representation of the message).

3.4    TMS Implementation Page

This page details information about implementing the domain over TMS, a typical page is explained below:

3.4.1 Application Role table

The first section details the application roles, this is detail about the role a particular system plays in the information flows.

1. The application role name - a description of the type of role, in this example this is the system where the information came from (the sending system).
2. The application role identifier - a unique identifier of the role.
3. A list of interactions that the role should support.
4. These icons link to the interaction stated on the left.
5. The cell at the bottom is used to indicate whether there is any additional behaviour required. 

3.4.2        Application Role Rule Table

The application role rule table details rules the system which is playing the application role should obey, a typical rule is shown below:

3.4.3        Trigger Events

The second section details trigger events - this is something that triggers an exchange of information, a typical trigger event is explained below:

1. Trigger event name.
2. Trigger event identifier - a unique identifier of the trigger event.
3. Details of the trigger event.

3.4.4        Interaction Diagrams

The interaction diagram gives a simple visual overview of how the application roles exchange information with each other, a typical diagram is shown below:

1. The first application role - in this example this is the sending system.
2. The second application role - in this example the receiving system.
3. A description of the type of information flow.
4. The interaction involved -  arrow gives direction of information flow, in this example information (a contact assessment) flows from left to right , from sending (originating) system to receiving system.
5. The interaction involved -  arrow gives direction of information flow, in this example information (an acknowledgement) flows from right to left, from receiving system to (originating) system. It should be noted that both systems actually send and receive interactions. Most application roles are named based on the business information flow direction and things such as acknowledgements are not class as business information but as system responses.

Note : the interaction flows (the arrows) have no order or conformance. This means that interactions flow does not start at the top and go in the order downwards. Also the inclusion of an interaction does not mandate it.

The interaction table details:

1. Interaction name.
2. Interaction identifier.
3. Icon that links to the interaction schema - this is an XML file which validates the message and its TMS wrapper instance.
4. Description of the interaction.
5. Sender responsibilities - what the sender should do before they send the information, in this case they must make sure the information carried in the message payload is valid against the two artefacts stated ( see item 7 & 8 below).
6. Trigger- what action triggers these sending responsibilities.
7. The conformance format - in this case the message must be a valid POCD_MT010001UK01 message , i.e. a valid Contact Assessment when tested using the conformance rules for this message - the blue text links to the artefacts associated with this validation.
8. The validation that the on the wire message must conform to - Note this is a CDA message and has two levels of validation. What this means is that the message must be a valid message when tested by whatever means is mandated.- the blue text links to the artefacts associated with this validation.
9. Receiver responsibilities - what the receiver must do when they receive the message.
10. What they must do when they receive the message - in this example send back an acknowledgement - the blue text links to the acknowledgement artefacts.
11. The trigger for these responsibilities  - in this example when they receive the contact assessment.
12. The artefacts used for transmission - in this case the TMS wrappers.
13. These are the artefacts used to wrap the payload information to allow transmission - in this example these are the TMS wrappers and this artefacts are linked by the blue text.

3.4.6        Message Examples Table

1. The message type the example(s) are for.
2. The business scenario that the example is based on.
3. An example payload (message).
4. An example of the payload (message) with its transmission wrapper in the format that is used "on the wire" i.e. with its TMS wrapper.
5. A conformance testable version of the payload (in the case of CDA payloads the "on the wire" format is transformed into a conformance format for more rigorous testing).
6. The payload rendered into a human readable form - this only applies to CDA documents.

3.5    ITK Implementation Page

This page details information about implementing the domain over ITK, a typical page is explained below:

Note: implementation over ITK refers to a payload wrapped in the ITK distribution envelope and not by any one transmission method.

3.5.1 Application Role table

The first section details the application roles, these are details about the role a particular system plays in the information flows.

1. The application role name - a description of the type of role, in this example this is the system where the information came from (the sending system).

2. The application role identifier - a unique identifier of the role.

3. A list of interactions that the role should support.

4. These icons link to the interaction stated on the left.

5. The cell at the bottom is used to indicate whether there is any additional behaviour required. 

3.5.2        Application Role Rule Table

The application role rule table details rules the system which is playing the application role should obey, a typical rule is listed below:

3.5.3        Trigger Events

The second section details trigger events - this is something that triggers an exchange of information, a typical trigger event is explained below:

1. Trigger event name.

2. Trigger event identifier - a unique identifier of the trigger event.

3. Details of the trigger event.

3.5.4        Interaction Diagrams

Note interaction diagrams are not currently supplied for ITK implementation

3.5.5        Interaction Tables

The interaction table details:

1. Interaction name.

2. Interaction identifier.

3. Note ITK does not use interaction schemas compared to TMS and so there is no icon.

4. Description of the interaction.

5. Sender responsibilities - what the sender should do before they send the information, in this case they must make sure the information carried in the message payload is valid against the two artefacts stated ( see item 7 & 8 below).

6. Trigger- what action triggers these sending responsibilities.

7. The conformance format - in this case the message must be a valid POCD_MT010001UK01 message , i.e. a valid Contact Assessment when tested using the conformance rules for this message - the blue text links to the artefacts associated with this validation.

8. The validation that the on the wire message must conform to - Note this is a CDA message and has two levels of validation. What this means is that the message must be a valid message when tested by whatever means is mandated.- the blue text links to the artefacts associated with this validation.

9. Receiver responsibilities - what the receiver must do when they receive the message.

10. What they must do when they receive the message - in this example send back an ITK business acknowledgement - details of these business acknowledgements are available from the core ITK specification.

11. The trigger for these responsibilities  - in this example when they receive the contact assessment.

12. The artefacts used for transmission - in this case the ITK wrappers.

13. These artefacts are used to wrap the payload information to allow transmission - in this example these are the Distribution Envelope (distributionEnvelope-v2-0) and the ITK Service (SendCDADocument-v2-0). These artefacts are linked by the blue text.

3.5.6        Message Examples Table

1. The message type the example(s) are for.

2. The business scenario that the example is based on.

3. An example payload (message).

4. An example of the payload (message) with its transmission wrapper in the format that is used "on the wire" , i.e. with its ITK wrapper.

5. A conformance testable version of the payload (in the case of CDA payloads the "on the wire" format is transform into a conformance format for more rigorous testing).

6. The payload rendered into a human readable form - this only applies to CDA documents.

3.6    Configuration Profiles Page

The configuration profiles are a list of configurable items in the message, this means things that are able to change and therefore need some form of configuration management. These profiles currently only contain vocabularies and templates.