Release Notes for Oracle Health Insurance Product Definition Release 3.21.2.0.0

This document contains the release notes for Oracle Health Insurance Product Definition Release 3.21.2.0.0.

Version compatibility: Oracle Health Insurance Product Definition Release 3.21.2.x is only compatible with other Oracle Health Insurance applications release version 3.21.2.x unless explicitly stated otherwise.
In accordance with the OHI error correction policy (Document 1494031.1 on My Oracle Support), error correction support will be provided for this release and the previous two releases.

Enhancements

ID Summary Description Included in Patch

NXT-21417

PHI Audit logs must be written in the same transaction as PHI / PII access occurs

PHI logs were initially written to a local buffer file before being persisted in the database. For compliance it is required to persist PHI audit logs in the same transaction as PHI access occurs. If system property 'ohi.logging.target' is set to value 'database', OHI applications persist PHI access in the database as part of the HTTP API or ADF UI request in which PHI data was accessed. If the value for system property 'ohi.logging.target' is set to 'log', which is also the default if no value is specified, then PHI access continues to be logged using any configured Logback Appender for which the PHI filter is applied.

Upgrade Steps for Installation

To perform the upgrade, perform the following steps:

  1. Perform any pre-upgrade steps.

  2. Stop all the managed nodes running the .existing version of the application.

  3. Perform any pre-undeploy steps.

  4. Undeploy the existing version of the application.

  5. Back up the database.

  6. Perform any post-undeploy steps.

  7. Unpack the release bundle into a directory that we refer to as OHI_ROOT from now on.

  8. Change Installation Configuration: In <OHI_ROOT>/util/install, make a copy of ohi_install.cfg.template and name it ohi_install.cfg.

  9. Edit ohi_install.cfg to contain your specific database connection data and other configuration settings. The settings are explained in the file itself.

  10. Make sure NO connections are present to the database using the OHI_xxx_USER account (where xxx is the abbreviation of the application)

  11. Run the Upgrade script:

    1. Open a command window and browse to <OHI_ROOT>/util/install.

    2. Run the upgrade by executing ./ohi-update.sh .

  12. Make the required changes to the ohi properties file

  13. Perform any post-upgrade steps

  14. Start WebLogic application server

  15. Deploy the Application

  16. Perform any post-deploy steps

Additional Upgrade Steps for Installation

The following phases are defined:

  1. pre-upgrade: Application is still running

  2. pre-undeploy: Application is stopped, but not undeployed.

  3. post-undeploy: Application is undeployed. Database is backed up

  4. post-upgrade: Released upgrade script has run.

  5. post-deploy: New application is deployed and is up and running.

The OHI Logback Database Appender can no longer be configured for logType 'phi'. Remove any appender of class 'com.oracle.healthinsurance.loggingsupport.appender.impl.OhiAppender' for logType 'phi' from the Logback configuration. To continue persisting PHI access in the database, set system property 'ohi.logging.target' to value 'database'. Note that use of the appender of class 'com.oracle.healthinsurance.loggingsupport.appender.impl.OhiAppender' for logType 'application' or logType 'dylo' is unaffected.

During the post-undeploy phase run the following SQL statement as application owner and commit any changes:

update log_phi_events
set    event_doc =
       json_mergepatch(
         json_mergepatch(
           json_mergepatch(
             json_mergepatch(
               nvl(event_doc, '{}')
               , json_object('sourceapp' value nvl(json_value(event_doc, '$.sourceapp' returning varchar2(30 char)), 'proddef')))
             , json_object('sourceappversion' value nvl(json_value(event_doc, '$.sourceappversion' returning varchar2(60 char)), 'pre-3.21.1.0.0')))
           , json_object('instancename' value nvl(json_value(event_doc, '$.instancename' returning varchar2(100 char)), 'UNKNOWN_DURING_CONVERSION')))
         , '{ "arguments" : { "user" : "'||nvl(json_value(event_doc, '$.arguments.user'), 'UNKNOWN_DURING_CONVERSION') ||'" }}'
       )
where  virtual_application is null
or     virtual_application_version is null
or     virtual_instancename is null
or     virtual_username is null;

In this release a performance improvement was included for the views generator. For this to work the VIEWS_OWNER database user should be granted CREATE TABLE privilege (the user creates a few global temporary tables). During the post-undeploy phase run the following SQL statement as a dba user:

grant create table to ohi_proddef_views_owner;

If you used a different schema then the above default, adjust the command accordingly

Configuration Properties

Ref Action Subject Description

NXT-21417

Added

ohi.logging.target

Defines the target for logging PHI access. Possible values are 'database', for logging to the database, or 'log' for logging PHI access to the Logback appender configured for it. Default value is 'log'.

Web Services

Ref Action Subject Description

NXT-21417

Modified

logphievents API

The following attributes are removed: eventDoc; eventTimestamp; eventLevel; eventThread; contextItemId; contextItemType

Data Conversion

Ref Action Subject Description

NXT-21417

Modified

Log PHI Events

Newly added attributes are derived from event_doc

Dynamic Logic

This section intentionally left blank.

UI Changes

This section intentionally left blank.

Deprecated items (to be removed in future release)

This section intentionally left blank.

Breaking Changes

Ref Action Subject Description

NXT-21417

Modified

log_phi_events

Column event_doc is removed

Bug Fixes

BugDB SR Internal BP Summary

32525599

PRD-2499

Usage names with a reserved SQL work result in view generation failure.

Description:

A usage name like "level" (which is a SQL reserved word) results in a failure in the deprecated view generator for the table where this usage is used.

Resolution:

Usage name like "level" which are SQL reserved words no longer create failure in view generation.

32581693

PRD-2516

Create-form link shall not be available for baseviews, baseviewgeneration and baseviewcolumn resources

Description:

Before this release, create-form link is visible for baseviews, baseviewgeneration and baseviewcolumn resources. Also baseviewerrors is not listed as a resource.

Resolution:

Create-form links for baseviews, baseviewgeneration and baseviewcolumn resources are removed. Baseviewerrors resource is now listed as a resource.

Issues that were backported in previous Release / Patch

No backports.

Known Issues

BugDB SR Internal Summary

24716118

PRD-1586

Accessibility - Component is not labeled

Description:

Component is not labeled, either by specifying the label attribute, or by being referred to by the 'for' attribute of a panelLabelAndMessage or outputLabel

31060661

3-22654524781

PRD-2288

Moving products from Edit to Review, some stay in Edit with 'valid' status'

Description:

Moving products from Edit to Review, some stay in Edit with 'valid' status'.

31116281

PRD-2290

With clicking Next button dialog button not refreshed

Description:

In Popup dialogs, Next and previous button doesn’t work due to refresh issue.

32477670

PRD-2488

No base view generated for reference sheet lines

Description:

Reference sheet(line)s use a different storage structure (JSON) for the dynamic fields. The base view generator does not support that yet. So the reference sheet line columns can’t be queried using base views.

32560678

PRD-2508

Baseview generation sometimes might result in error: ORA-01461

Description:

Occasionally baseview generation results in error: ORA-01461. In the event that this happens, typically resubmitting the generation process resolves the problem.