Diagnosis Integration Point

This chapter describes the Diagnosis Integration Point messages and how they are used by external interfaces to initially load diagnosis data copies into Oracle Health Insurance and to keep the copies up-to-date.

Design Principles

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

Diagnosis Matching

In order for Oracle Health Insurance to be able to recognize when an update to a diagnosis’s details is being sent (as opposed to the details of a new diagnosis) and to know which diagnosis in Oracle Health Insurance is to be updated, the diagnosis 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 diagnosis’s details.

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

The combinations of diagnosis code and flex code definition are assumed to be unique across all diagnoses within Oracle Health Insurance regardless of the source of the diagnosis.

Request

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

If a diagnosis’s end date is updated and the validity time period is shorter, then diagnosis group details referring to the diagnosis will get the same end date unless the detail has an end date before the diagnosis’s end date. Diagnosis 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 Developer Guide.

A given implementation of Oracle Health Insurance could have dynamic fields and records added to the diagnosis as well as diagnosis 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 Oracle Health Insurance, refer to the Developer Guide.

Diagnosis

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

<diagnosis
   flexCodeDefinitionCode=""
   code=""
   description=""
   startDate=""
   endDate=""
   displayAccessRestrictionCode=""
>
   <diagnosisSettingList>
      <diagnosisSetting
         startDate=""
         endDate=""
     />
   </diagnosisSettingList>
</diagnosis>

Response Messages

Response messages are created by Oracle Health Insurance 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

Diagnosis batch request messages have the following structure:

<diagnoses>
  <diagnosis/> -- refer to Diagnosis Request for details
</diagnoses>

Diagnosis batch response messages have the following structure:

<diagnosesResponse>
  <resultMessages/>
</diagnosesResponse>

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 the code of the diagnosis for which the messages are raised.

Error Messages

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

Code	Severity	Message
OHI-IP-DIAG-003	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).