Omni-Payer™ Server

• Extended the content for the library of SourceCodeMaps.
• Updates for the latest HLI-provided SourceCodeSets and SourceCodeMaps.
• Enhancement of db.upgrade to respect database column length increases.
• Expanded the implementation of the Outbound CCD for the following additional section:
  • Medication
• SQL Server support for Relational On-Ramp FASTPATH/DIFFERENTIAL.
• Several bug fixes to improve processing and deployment.

• Fixed several bugs in the CCD Outbound process.
• Extended the content for the library of SourceCodeMaps, including an NDC to RXNorm translation for producing PQRS metrics.
• Fixed several bugs with Relational On-Ramp process.
• Updates for latest HLI-provided SourceCodeSets and SourceCodeMaps.
• Separation of PharmacyPrescriptionOrderEvent into the following subjects:
  • PharmacyPrescriptionOrderEvent
  • PharmacyDispenseEvent
  • MedicationAdministerEvent
  • VaccinationAdministerEvent
• Separated FamilyHistory as a distinct subject from DiagnosisEvent.
• Created a new channel and IDS subject to process ADT event messages.
  • Created Omni ADT Canonical XML message to support nine HL7 ADT message types (A01, A02, A03, A04, A05, A08, A11, A12, and A13).
  • Created ADTEvent IDS subject for processing ADT event messages.
  • Created ADT channel to process Omni ADT Canonical XML messages.
• Created ProviderPractice and PracticeFacility as mastered subjects to replace the use of Organization for more explicitly depicting the PracticeFacility relationship to the ProviderPractice and the Provider.
• Updated the ProviderPracticeSpecialty to show the relationship of the Provider to the ProviderPractice and PracticeFacility.
• Addressed a bug in sourceCode processing that was created when changing from a merge policy to a replace policy, and back again for a given subject.
• Implemented several configuration properties for optimizing the processing of large incremental loads.
• Several additional bug fixes to improve processing and deployment.

• Added the following fields to the ADTEvent IDS:
  • PatientClass
  • EncounterClass
  • VisitPriority
  • VisitStatus
  • VisitStatusEffectiveDate
  • VisitPublicity
  • VisitProtection
  • AdmitSource
  • AmbulatoryStatus
  • ModeofArrival
  • PatientCondition
  • LevelofCare
• Renamed the following fields in the ADTEvent IDS to retain a consistent naming convention for fields defined as SourceCodes:
  • AdmitReason
  • DischargeDisposition
• Updated channel for mapping the additional fields from ADTCanonical to ADTEvent.
• Improved performance in SourceCodeMap loads.
• Fix for SourceCodeMap duplicate error (IRN: 170112061).
• Removal of remediation tickets being generated for each transaction that uses an invalid SourceCode.

1. Create a back up of the existing source_code_relation table.
2. Install Omni-Payer 1.6.1.5 and run the following:

   omni db.upgrade

3. Run the SQL that follows, which replaces all records in the source_code_relation table with ones with differently formulated id columns.
4. Install any Source Code Map updates (packaged with 1.6.1.5 or later type 2 updates). See the IDS zip file for model changes.

CREATE TABLE source_code_relation_temp
(
  id character varying(255) NOT NULL,
  source_code_map_name character varying(50),
  source_code_map_id character varying(255),
  linked_map_id character varying(255),
  base_code character varying(255),
  related_code character varying(255),
  related_group character varying(255),
  preference_order integer,
  description character varying(255),
  start_date timestamp without time zone,
  end_date timestamp without time zone,
  transaction_id character varying(255),
  version bigint,
  source_name character varying(255) NOT NULL,
  source_instance_id character varying(255) NOT NULL,
  source_instance_id_name character varying(255),
  status character varying(255),
  status_reason character varying(255),
  source_status_code character varying(255),
  source_created_date timestamp without time zone,
  source_created_by character varying(50),
  source_modified_date timestamp without time zone,
  source_modified_by character varying(255),
  omni_created_date timestamp without time zone,
  omni_modified_date timestamp without time zone,
  CONSTRAINT pk_source_code_relation_temp PRIMARY KEY (id)
)


INSERT INTO source_code_relation_temp(
            id, source_code_map_name, source_code_map_id, linked_map_id, base_code, related_code, 
            related_group, preference_order, description, start_date, end_date, 
            transaction_id, version, source_name, source_instance_id, source_instance_id_name, 
            status, status_reason, source_status_code, source_created_date, 
            source_created_by, source_modified_date, source_modified_by, 
            omni_created_date, omni_modified_date)

       (SELECT 
       
       CONCAT('SourceCodeRelation:',source_name,':',source_code_map_name,'|',
       substring(base_code,12),':',
       substring(related_code,12),':',
       related_group,':',
       to_char(start_date,'YYYYMMDD'),':',
       preference_order
       ),
       

 source_code_map_name, source_code_map_id, source_code_map_id, base_code, related_code, 
       related_group, preference_order, description, start_date, end_date, 
       transaction_id, version, source_name,
       CONCAT(source_code_map_name,'|',
       substring(base_code,12),':',
       substring(related_code,12),':',
       related_group,':',
       to_char(start_date,'YYYYMMDD'),':',
       preference_order
       ), 
       source_instance_id_name, 
       status, status_reason, source_status_code, source_created_date, 
       source_created_by, source_modified_date, source_modified_by, 
       omni_created_date, omni_modified_date
       
  FROM source_code_relation);

truncate source_code_relation; 

INSERT INTO source_code_relation(
            id, source_code_map_name, source_code_map_id, linked_map_id, base_code, related_code, 
            related_group, preference_order, description, start_date, end_date, 
            transaction_id, version, source_name, source_instance_id, source_instance_id_name, 
            status, status_reason, source_status_code, source_created_date, 
            source_created_by, source_modified_date, source_modified_by, 
            omni_created_date, omni_modified_date)

       (SELECT 

       id, source_code_map_name, source_code_map_id, linked_map_id, base_code, related_code, 
            related_group, preference_order, description, start_date, end_date, 
            transaction_id, version, source_name, source_instance_id, source_instance_id_name, 
            status, status_reason, source_status_code, source_created_date, 
            source_created_by, source_modified_date, source_modified_by, 
            omni_created_date, omni_modified_date

        FROM source_code_relation_temp);

The key processes business processes for tracking Medications and Vaccinations are as follows:

• Order
• Dispense
• Administration
  • Medication Administration
  • Vaccination Administration

Each of these processes was tracked previously in the various groups contained within the PharmacyPrescriptionOrderEvent. The movement to more explicit subjects helps to simplify the integration and consumption processes. The model changes being introduced in this release to support the more explicit subjects are based on the FHIR/HL7 V3 model, which suggests the use of the MedicationOrder, MedicationDispense, MedicationAdministration, and Immunization resources. The changes are summarized in the following table:

In prior implementations, Diagnoses tied to FamilyHistory were distinguished from other diagnoses related to the patient's care, using the CCDCategoryCode of 10157-6 in a DiagnosisEvent. The movement of these diagnoses to a more explicit subject helps to simplify the integration and consumption processes. The model changes being introduced in this release to support this explicit subject is based on the FHIR/HL7-V3 model, which suggests the use of the FamilyMemberHistory resource.

The FHIR/HL7-V3 model suggests the use of the Organization and Practitioner model for communicating information about the relationship between Providers, their Practice(s), and the Facilities at which they perform services. The more general Organization model allows for the designation of Addresses, but was not as robust for storing additional metadata required for analytics, such as links to the Facility and Organizational hierarchies.

Therefore, the ProviderPractice and PracticeFacility subjects are being introduced to help simplify the integration, mastering, and consumption processes. In addition, the Provider model has been amended to account for these new objects in the ProviderPracticeSpecialty. The changes are summarized in the following table.

With this release, Omni-Payer supports processing of patient admit, discharge, and transfer transactions sent by hospital facilities and/or HIEs via the Omni ADT canonical XML message. The canonical supports the mapping of different ADT event types and different formats, such as HL7 version 2.3.x and version 2.5.x. An ADT Channel will consume the ADT Canonical and generate Member and ADTEvent IDS. The ADTEvent subject will be used to run reports for member inpatient visits. For more information and details, see the following process flow.

1. The date filter for clinical events in the CCD Outbound process must be provided in the following format:

   yyyyMMdd

2. Allergies events will not be filtered by date recorded. All patient allergies will be reported in the patient's CCD.

iWay Omni products use EclipseLink (http://www.eclipse.org/eclipselink) for Java persistence services. EclipseLink has many settings that may be useful for site-specific customizations or tuning.

As of Omni-Payer™ Version 1.6.1, these settings may be specified for use by Omni by adding property files to the following directory:

iway7/config/OmniGenServer/resource

There is a separate property file for each of the three persistence units managed by Omni. These properties are listed and described in the following table.

An example would be the following property file:

iway7/config/OmniGenServer/resource/omni-payer.properties

This file contains:

eclipselink.session.customizer.JPQLParseCacheMaxSize=300
eclipselink.jdbc.batch-writing.size=1500
eclipselink.logging.level=FINE

The full list of EclipseLink properties can be found on the following website:

http://www.eclipse.org/eclipselink/documentation/2.4/jpa/extensions/persistenceproperties_ref.htm#CACDCCEG2

For settings to be applied and take effect, you must restart of the server. Tuning guidelines are being planned for a future release. Customer Support may also request certain setting changes in order to diagnose a particular issue.

Information Builders has partnered with Wolters Kluwer, formerly known as Health Life International (HLI), to provide content set updates for industry standard codes, such as SNOMED-CT, ICD-9, and ICD-10, among others. On a release-by-release basis, Information Builders updates its library with the latest content updates from HLI and transforms them for use in the SourceCodeSet and SourceCode subjects.

Due to volume considerations, these codesets are not loaded into the system by default. All current SourceCodeSets are now delivered in the following directory of the deployment package:

/ OmniGenServer/iway7/config/OmniGenServer/resource/OID

The operations administrator is given the flexibility to determine which content sets are applicable to the current customer implementation. Once the appropriate files are chosen, they may be scheduled for loading through the file listener at the appropriate time during the incremental load process.