Rhapsody recommends you use a naming convention that facilitates the implementation of configurations that are essentially self-documenting, and enables components to be labeled in a manner which is clear and indicative of purpose. This allows for the grouping of components and simplifies searches across components in Rhapsody applications, thereby streamlining the development and monitoring processes. 

Naming communication points and filters by including information such as their type and purpose is especially important when the components are viewed in the Management Console where they are not distinguishable by icon (unlike in Rhapsody IDE, which provides unique icons for every Rhapsody object and component type).

Furthermore, consistent naming simplifies maintenance by both internal and external personnel as it reduces the time needed to understand the purpose of a configuration.

The following recommendations provide a starting point for developing your own Rhapsody naming conventions:

General Considerations

Special Characters in Names

Components may require medium length strings of multiple tokens (including prefixes and suffixes) to indicate use and purpose as described below. Generally, it is recommended to separate these by either the space character or the underscore character. The underscore is suitable for shorter token sequences. For longer sequences, particularly when naming items that appear within the Route Editor canvas (such as communication points and filters), the use of the space character is recommended.

  • Use of the underscore in component names tends to stretch the component name horizontally and can make efficient use of layout in the Route Editor canvas difficult.
  • Use of underscores in filenames such as Message Definition and Mapper files has no impact on layout within Rhapsody IDE.
  • You cannot use the following characters: {}[]<>:; $\/?"|.

Long Names

  • Avoid component names which would wrap to more than three or four lines in the Route Editor canvas.
  • Avoid route names which are long, or nesting folders too deeply as this makes it difficult to see the entire component name without the need to scroll within the Rhapsody IDE Workspace.

Naming Format

Format: prefix_body_suffix

Element Description
prefix_

The prefix typically indicates the type of Rhapsody objects, particularly components (for example, tcp_ for TCP communication points). The Management Console uses the same icon for all filters and communication points, and does not indicate their component type in every instance.

The convention for component type prefixes should be outlined and discussed together with the users who are responsible for the day-to-day maintenance of the system. They may need to make alterations or additions to maintain a good naming standard.

  • CP. - communication point.
  • RT. - route.
  • WS. - web service.
body The body usually describes the function of the Rhapsody object.
_suffix The suffix provides supplementary information if required.

Lockers

Format: function

 

Examples:

  • Core
  • Complex Conductor Services
Element Description

function

Lockers are named based on the requirement for the locker (for example to segregate by the role of the interfaces within the locker, or the separation requirement such as a multi-agency tenancy which would have a folder per tenant).

  • <Cluster>
  • <Tenant>
  • <Folder type>

Folders

Format: ##_type

 

Examples:

  • webPAS
  • 01_Get National Identifiers
  • 02_Prepare MyHR Upload
Element Description

##_

An optional prefix that indicates the sequence number representing the different stages of processing.
type

Folders could be named according to one of the following conventions:

  • The primary source or destination systems they integrate with.
  • The primary function the routes perform.

Routes

Format: RT.##_body_state

Examples:

  • RT.01_Input ADT from PAS
  • RT.02_Transform to CMM
  • RT.03_EMPI SBR Update 
  • RT.01_ADT Validation_P
  • RT.01_EMPI SBR_OR
  • RT.03_PAS ADT to LIS_OUT
  • RT.03_Terminology_IN
Element Description

##_

An optional prefix that indicates the two-digit sequence ID of the route. When configurations break a complex processing sequence across several route stages, including the sequence ID in the route name may assist in understanding the processing flow.
function

For the body make it clear what the purpose of the component is.
_state

An optional suffix that indicates the state of route:

  • _P - processing.
  • _OR - orchestration.
  • _OUT - outbound.
  • _IN - inbound.

All direction specifications should be Rhapsody-centric; that is, inbound means Rhapsody is receiving the message while outbound means Rhapsody is sending the message.

Communication Points

Format: CP.type_function_mode

Examples:

  • CP.tcp_PAS_I
  • CP.email_Abnormal_O
  • CP.ws_Register Doc_IO
  • CP.ws_Terminology_OI
  • CP.email_Ascribe_E
  • CP.dir_Reportable_BI
Element Description
CP.type_

A prefix that identifies the type of communication point, for example:

  • CP.db_ - Database communication point.
  • CP.dir_ - DIrectory communication point.
  • CP.email_ - Email Client communication point.
  • CP.tcp_ - a TCP communication point.
  • CP.ws_ - a web services communication point.
function

A body that describes the system and its purpose, for example: tcp_PAS_ADT.
_mode

A suffix that identifies the flow of messages (correlates with a communication point's mode):

  • _I - In.
  • _O - Out.
  • _IO - In->Out.
  • _OI - Out->In.
  • _BI - Bi-directional.
  • _E - Error out.

Filters

Format: type_function_route

Example:

  • js_Process CDA Referral
Element Description
type_

A prefix identifies the type of filter, for example:

  • js_ - JavaScript filter.
  • nop_ - No-operation filter.
  • map_ - Mapper filter.
function A body that describes the function of the filter.
_route

An optional suffix used for No-operation filters used as bookends to connect routes:

  • _FROM_precedingRoute - the input No-operation filter with their preceding route names.
  • _TO_nextRoute - the output No-operation filter with the name of the next route.

For example:

  • nop_TO_RT PAS to G2
  • nop_TO_RT PAS to G2

Filter Tests

Filter tests and test messages that are used during filter testing should be saved with a meaningful name and a concise description of the test. This enables users carrying out peer review to use saved test messages for the review and testing of specific use cases.

Examples:

Name Description
Patient ID Found When the Patient ID Property is extracted and set from the database
Patient ID Not Found When the Patient ID Property is not set from the database

Conditional / JavaScript Connectors

Format: condition

Examples:

  • is Referral Message
  • is Required Msg Type
  • is Error Condition ADT Only
Element Description
condition 

Conditional connectors should be named succinctly to indicate their purpose. For unnamed conditional connectors, their actual condition is displayed in truncated form on the connection.

Message Definitions

Mapping Definition Files

Format: source_to_target.mdf

Example:

  • Cerner_ADT_HL7v23_to_CareFusion_ADT_HL7v22.mdf
Element Description

source

 A prefix that indicates the source and source format being mapped from.
target A suffix that indicates the target and target format being mapped to.

EDI Definitions

Format: system_HL7Version_messageTypes.s3d

Examples:

  • ACTPAS_PatientMerge_HL72.3.1_ADT040.s3d
  • Cerner_HL7v23_ADT.s3d
Element Description
system_

A prefix that indicates the source or target system.

 
HL7Version A body that indications the HL7 version the definition defines.
_messageTypes A suffix that indicates the message types the definition defines.

Message Properties

Format: valueType

Examples:

  • sourceFacilityCode
  • patientRegDB_patientID
Element Description
valueType Solution properties and Transient properties (only relevant to the set of route stages that populate and use the property) should be named appropriately to indicate the value it stores. In some cases, properties populated during route processing may require a prefix to aid in identifying their purpose and the solution that delivered them. This is especially true of properties that are populated by a publishing route and passed to any subscribers who require them for downstream processing (typically these properties should be managed within the configuration documentation to support easy identification and use by new subscribers).

Rhapsody Variables

Format: externalSystem_componentType_function

Examples:

  • ACTPAS_WS_UserID
  • SMT_OutputDocType
  • CDR_DB_Password
  • RIS_TCP_Port
Element Description
externalSystem_

An optional prefix that indicates the external system the variable is related to.

componentType

An optional body which indicates the communication point or filter type that the Rhapsody variable is being used to configure, for example:

  • TCP - TCP.
  • DB - database.
  • WS - web service.
_function A suffix that indicates what the variable is used as a substitute for (for example a component's configuration property).