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 Oracle Health Insurance application and to keep the copies up-to-date.
Design Principles
The Oracle Health Insurance application requires procedures that may be maintained (mastered) outside of the Oracle Health Insurance application. Where this is the case, the Oracle Health Insurance application needs to store an up-to-date copy of these procedures. This copy in the Oracle Health Insurance application is maintained by external (not part of the Oracle Health Insurance application) interfaces using Procedure Integration Point messages. The external interfaces will initially load details of all required procedures from the 'master' systems into the Oracle Health Insurance 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 Oracle Health Insurance application with updated details and to add new procedures.
Procedure Matching
In order for the Oracle Health Insurance 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 Oracle Health Insurance 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 Oracle Health Insurance 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 Oracle Health Insurance 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 Oracle Health Insurance 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 Oracle Health Insurance 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 Oracle Health Insurance 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 Oracle Health Insurance 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).