Procedure integration Point

This chapter describes the Procedure Integration Point messages and how they are used by external interfaces to initially load procedure data copies into the OHI application and to keep the copies up-to-date.

Design Principles

The OHI application requires procedures that may be maintained (mastered) outside of the OHI application. Where this is the case, the OHI application needs to store an up-to-date copy of these procedures. This copy in the OHI application is maintained by external (not part of the OHI application) interfaces using Procedure Integration Point messages. The external interfaces will initially load details of all required procedures from the 'master' systems into the OHI application through Procedure Integration Point message calls. Thereafter, they could monitor the 'master' system(s) for updates and new procedures and make message calls to provide the OHI application with updated details and to add new procedures.

Procedure Matching

In order for the OHI application to be able to recognize when an update to a procedure’s details is being sent (as opposed to the details of a new procedure ) and to know which procedure in the OHI application is to be updated, the procedure code and flex code definition is used. The combination of these attributes is a unique id from the source system that external interfaces will always include with each procedure’s details.

The OHI application stores the procedure code and flex code definition with its copy of each procedure . When the details of a procedure are received in a message, the OHI application will consider the details to be a new procedure if there is not already a procedure stored with the same combination of procedure code and flex code definition and it will consider the details to be an update to an existing procedure if there is one with the same code and flex code definition.

The combinations of procedure code and flex code definition are assumed to be unique across all procedures within the OHI application regardless of the source of the procedure .

Request

Each request message may contain the details of one procedure .The external interfaces will create request messages for the initial data load, in response to entry of new procedures and updates to previously sent procedures.

If a procedure’s end date is updated and the validity time period is shorter, then procedure group details referring to the procedure will get the same end date unless the detail has an end date before the procedure’s end date. The same accounts for combination check procedures. Procedure settings will not be updated automatically: the assumption is that the complete list is included..

The details of exactly what information needs to be in a given request message varies based on factors such as whether details have been sent before and the category of details that have been added or updated. For details on how values in the request messages are handled, refer to the concepts in the Integration Guide.

A given implementation of the OHI application could have dynamic fields added to the procedure setting entity that need to be interfaced. For details on how external interfaces can provide values for dynamic fields and dynamic records in request messages and how they are handled by the OHI application, refer to the Integration Guide.

Procedure

The system accepts the procedure request message in the following format:

<procedure
   flexCodeDefinitionCode=""
   code=""
   description=""
   startDate=""
   endDate=""
   displayAccessRestrictionCode=""
>
   <procedureSettingList>
      <procedureSetting
         ageFrom=""
         ageTo=""
         gender=""
         startDate=""
         endDate=""
     />
   </procedureSettingList>
</procedure>

Response Messages

Response messages are created by the OHI application in response to request messages received from external interfaces. Please refer to the 'Response Messages' section in the HTTP API Integration Points part of the Common Features book for more details.

Batches

Batch requests enable the handling of multiple requests in one go. Because the volume of data can become quite extensive, these are file based requests. Please refer to the 'File Based Import' section in the HTTP API Integration Points part of the Common Features book for more details.

Batch Messages

Procedure batch request messages have the following structure:

<procedures>
  <procedure/> -- refer to Procedure Request for details
</procedures>

Procedure batch response messages have the following structure:

<proceduresResponse>
  <resultMessages/>
</proceduresResponse>

The elementId attribute that is included as part of the result messages element (refer to the 'Activity Integration Point' section in the HTTP API Integration Points part of the Common Features book for more details) contains the code of the flex code definition, followed by a comma, space and code of the procedure for which the messages are raised.

Error Messages

The following error messages that are specific to the procedure interface may be returned in the response messages:

Code	Severity	Message
OHI-IP-PROC-002	Fatal	Flex code definition {code} is unknown
GEN-ACRE-001	Fatal	Access restriction code {code} is unknown. Request cannot be processed

In addition, functional business rule messages may be returned as well as the standard messages related to dynamic fields and dynamic records (refer to the 'Response Messages' section in the HTTP API Integration Points part of the Common Features book).