Technical Committee Documentation Template

Template Usage Information:

·  Do not change the name/format of section titles

·  If necessary the sections may be repeated (note the numbers are manually entered so if you are repeating Section 3 Interaction Category then they should all be Section 3.

·  Do not change the font/format within each section

·  Replace RED text with appropriate content

If you have any special requests add them as editor notes at beginning of the appropriate section using “EDITOR NOTES” format,

Editor Notes: This is an example of a special request to the editors

·  If there is no content for a section, then enter the literal “NONE” under the section.

·  Green sections are informative only.

Construction of Identifiers (ID)

The sections that follow call for the inclusion of identifiers (ID) for many elements of the specification. Ultimately, the construction and allocation of these identifiers will be specified and managed by the Control-Query Committee. During the initial V3 development stages, however, each TC will generate its own set of identifiers and control them to assure uniqueness. The following is a set of rules for the opening six (6) characters of each identifier that will help provide some continuity across committees.

·  An identifier may have no more than 16 characters.

·  The opening four characters should be the committee identifier followed by an underscore. The committee identifiers are in vocabulary domain “HL7CommitteeIDsInRIM.” They include: C/Q – “C02_”, PA(FM) – “C03_”, OO – “C04_”, (PA)FM – “C06_”, Medical Records – “C09_”, Scheduling – “C10_”, and Patient Care – “C12_”

·  The fifth and sixth characters are based on the element being identified as below:

TC Documentation Template 8 March 19, 2001

Technical Committee Documentation Template

Item being identified / ID Characters5 & 6
Application_role / AR
Domain / DM
HMD / HD
Interaction / IN
Interaction Category / IC
Message Type / MT
MIM / MI
Item being identified / ID Characters5 & 6
Project / PJ
R-MIM / RM
Storyboard / ST
Storyboard example / SX
Trigger Event / TE
Use case / UC

TC Documentation Template 8 March 19, 2001

Technical Committee Documentation Template

·  The remaining ten characters can be assigned as desired by the committee. Thus a Trigger Event for PAFM might be “C03_TEA01” or “C03_TE_AdmitPt”:

Table of Contents

Template Usage Information: 1

Construction of Identifiers (ID) 1

Table of Contents 2

Section 1. PROJECT General Introduction 3

A. Identification 3

B. Scope 3

C. Dependencies / References 3

Section 2. DOMAIN General Introduction 4

A. Identification 4

B. Scope 4

C. Dependencies / References 4

D. Application Roles 4

Section 3. Interaction Category 6

A. Storyboards 6

B. Trigger Events 7

C. Message (Message Type) 7

D. Message Information Model (MIM) 8

Section 4. Interactions 9

Section 5. State Transition Model 10

A. State Transition Diagram 10

B. States 10

C. Transitions 10

Section 1. PROJECT General Introduction

A.  Identification

Project: / Insert the name of the project / ID

B.  Scope

R/O/C / Required
Formats Allowed: / Body Text
Body Number
Body Bullet
Table
Table Heading
·  Table Bullet List
2.  Table Number List

This section is required to define the scope covered by the project.

C.  Dependencies / References

ROC / Optional
Formats Allowed: / Body Text
Body Number
Body Bullet
Table
Table Heading
·  Table Bullet List
3.  Table Number List

This section should indicate any dependencies between the project in this document and any other projects or documents.

Section 2. DOMAIN General Introduction

A.  Identification

Domain: / Insert the name of the domain / ID
Parent Project: / The domain MUST be associated with a Project. Insert the Name and ID of the parent Project here. / ID

B.  Scope

ROC / Required
Formats Allowed: / Body Text
Body Number
Body Bullet
Table
Table Heading
·  Table Bullet List
4.  Table Number List

This section is required to define the scope of the domain.

C.  Dependencies / References

ROC / Optional
Formats Allowed: / Body Text
Body Number
Body Bullet
Table
Table Heading
·  Table Bullet List
5.  Table Number List

This section should indicate any dependencies between this domain and any other.

D.  Application Roles

“Application roles are abstractions that name roles that may be played by health-care information system components when sending or receiving HL7 messages. Thus they are a defined set of responsibilities with respect to interactions. The role may have responsibility to send or receive one or more interactions. The application role and its responsibilities may form the basis for establishing conformance specifications for a standard.”

Note that application roles are circularly defined with respect to interactions. Ultimately, an Application Role is defined in terms of its responsibilities for interactions. Nothing more. Nothing less. Although the MDF suggests formal stereotypes, these can be applied later. For now, identify Application Roles simply with:

1.  An assigned identifier (“C22_A25”)

2.  A name (“Person definer”)

3.  A brief description (“An application component that provides new instances (definitions) of persons in a registry.”)

Application Roles may be grouped into SETS or SUB-SETS

ROC / Required
Formats Allowed: / Table
Table Bullet List
Table Number List

This section contains a table only.

Repeat each table section for each Application Role identified.

Application Role: / Insert the name of the application role / ID
Description: / Insert a description of the application role.
Parent Set or Sub-Set / Insert the human readable identification of the application role parent set or sub-set if defined.
Application Role:
Description:
Parent Set or Sub-Set

Section 3. Interaction Category

An Interaction Category is an arbitrary collector. It can hold other Interaction Categories (to build a hierarchy) or it can hold storyboards, trigger events and interactions.

ROC / Required
Formats Allowed: / Table
Table Bullet List
Table Number List
Graphic
Interaction Category: / Insert the name of the interaction category / ID
Description: / Insert the description of the interaction category.
Parent Category or Domain: / The Interaction category MUST be associated with either a Domain or another Interaction Category.
Insert the name and identifier for the Parent here. / ID

A.  Storyboards

ROC / Optional – If this section is missing, the trigger event and interaction sections must clearly identify the story board to which they apply
Formats Allowed: / Table
Table Bullet List
Table Number List
Graphic

This section contains tables and diagram only.

Story Board: / Insert the name of the storyboard / ID
Purpose: / Insert here objective for this storyboard. This is the purpose for which the storyboard was created. It frequently describes the generic set of actions that the storyboard represents.

Insert the storyboard Diagram here. The storyboard diagram may be graphically depicted using either the Sequence/Ladder or Collaboration diagram. Note: one of these diagram formats is required.

Storyboard Examples:

A Storyboard example is a real-world example of the sequence of events captured in the Storyboard. Repeat the following table sections for each example identified (frequently there will only be a single example).

Example: / Insert the name of the example / ID
Narrative: / Insert the detailed narrative of the example.
Example:
Narrative:

B.  Trigger Events

ROC / Required
Formats Allowed: / Table
Table Bullet List
Table Number List

This section contains a table only.

Repeat the following table sections for each trigger event identified

A Trigger Event is an occurrence in the health care domain, or within the systems that support this domain, that causes information to be exchanged in the domain or between systems. Trigger events are initiators of Interactions. Trigger Events may be grouped into SETS and SUB-SETS

Trigger Event: / Insert the name of the trigger event / ID
Description: / Insert a description of the trigger event
Parent Set or Sub-Set: / Insert the human readable identification of the trigger event’s parent set or sub-set if defined.
Dependency of Note: / Document any dependencies such as states of classes or values of attributes or other trigger events upon which this trigger event is dependent.
Trigger Event:
Description:
Parent Set or Sub-Set:
Dependency of Note:

C.  Message (Message Type)

“A message type is part of an HMD. It defines the specific information transfer that occurs in an interaction to meet the requirements of use cases. It is a set of constraints applied to the message elements defined in the HMD. These are represented by a set of columns in the HMD.”

Ultimately, a message type is represented in the interaction solely by its identifier which points to a message type definition in an HMD. During early design stages (before the HMD has been constructed) you should provide a working definition with two elements:

1.  An assigned identifier (e.g. “C22_M08”)

2.  A description of the message contents (“The message must contain the core defining elements for the person being created, including, name, date of birth, gender, civil identifiers, and the identifier by which the sending application role ‘knows’ the person. The message should also identify the context in which the person was identified and identifiers used by other registries, if such identifiers are known and/or permitted.”) This description will provide a guide to the team seeking to define a formal information structure for this message.

ROC / Required
Formats Allowed: / Table
Table Bullet List
Table Number List
Graphic

This section contains a table and graphic only.

Repeat the following table sections for each message design identified

Message Identification: / LEAVE THIS FIELD BLANK / ID
Development Note: / Insert any notes or examples relevant to the development of the message. Note these will not be included in the final ballot.
Message Identification: / LEAVE THIS FIELD BLANK
Development Note:

D.  Message Information Model (MIM)

ROC / Required
Formats Allowed: / Table
Graphic

This section contains a table and graphic only.

MIM Identification: / Name / ID
Description: / Insert any notes or examples relevant to the development of the RMIM. This description may be included in the final ballot.

R-MIM Graphical Representation

The only purpose of this section is to document the VISIO R-MIM Block Diagram

Repeat this table and diagram for each R-MIM associated with the MIM.

R-MIM Identification: / LEAVE THIS FIELD BLANK / ID
Development Note: / Insert any notes or examples relevant to the development of the RMIM. Note these will not be included in the final ballot.

Insert the VISIO R-MIM BLOCK Diagram here

Section 4. Interactions

“An association between a specific message (information transfer), a particular trigger event that initiates or triggers the interaction, and the roles that send and receive the interaction. An interaction is a single, one-way transfer of information. Within itself, an interaction may not specify a return message. An interaction may, however, establish a responsibility for the receiver of its message, and this responsibility may require that the receiver initiate a particular trigger event/interaction subsequent to the receipt.”

Thus, an interaction is the unique combination of four mandatory elements and one optional element. These are:

1.  Trigger event

2.  A Sending Application Role

3.  A Receiving Application Role

4.  A Message that is sent in the Interaction and

5.  [Optionally] Receiver Responsibility, which is another interaction that the receiving Application Role must initiate (send) as a result of receiving the primary interaction.

ROC / Required
Formats Allowed: / Table
Table Bullet List
Table Number List

This section contains a table only.

Repeat the following table sections for each interaction identified

Interaction: / ID
Description: / Insert a description of the interaction
Parent Set or Sub-Set: / Insert parent Interaction if grouping has been implemented. / ID
Initiating Trigger Event: / Identify the initiating trigger event for this interaction
Note: must be defined in the Trigger Event table above / ID
Sending Application: / Identify the sending application for this interaction.
Note: must be defined in the Application Role table above / ID
Receiving Application: / Identify the receiving application for this interaction.
Note: must be defined in the Application Role table above / ID
Receiver Responsibility: / Interaction ID
Message Structure: / Identify the message structure for the interaction.
Note: must be defined in the Message Structure table above / ID
Interaction:
Description:
Initiating Trigger Event:
Sending Application:
Receiving Application:
Receiver Responsibility:
Message Structure:

Section 5. State Transition Model

ROC / Optional
Formats Allowed: / Table
Table Bullet List
Table Number List
Graphic

If a committee wishes to construct or add a state transition model for a class (Subject Class) in the RIM, the format of this section may be used to document these. The section contains a table and a diagram only.

A.  State Transition Diagram

Insert the state transition diagram

B.  States

Repeat this table for each state identified for the State Transition Model

State: / Enter the name of the state. Note: the name must be unique within the class.
Description: / Insert a description of the state
Predicate: / Thepredicate is a textual description of the condition or set of conditions that, when true about the attribute(s) and connections of the parent subject class, identifies that the subject class is in the declared state.
State:
Description:
Predicate:

C.  Transitions

Repeat this table for each state transition identified for the State Transition Model

State Transition: / Enter the name of the state transition / ID
Description: / Provide short, informative description of the state transition
Start State: / Insert the name state that is the starting point for the transition.
End State: / Insert the name of state where the transition terminates. (Note, this may be same as Start State.)
Causal Trigger Event: / If it is known, identify the trigger event that causes this transition by placing the name of the Trigger Event here, and its ID in the adjacent field. / ID

TC Documentation Template 8 March 19, 2001