OnyxOS 5.7 Spring April 2024 Edition - April 17,2024

Back to Release Notes Summary

OnyxOS Updated to Release 5.7

OEM Team

US-Core Clinical (Version-2.1.0)

STU-5.0.1

  1. Clinical Preprocess

    a. Date Time update: Included all the columns which consists of dateTime type header when calling UDF from General repo. Client can send data in any column even in non-mandatory columns, therefore, adding all the dateTime columns helps to convert any column that client wishes to provide.

    b. Output function: Write to Output function which writes files to Landing location in S3 is called from General library and removed local function to every notebook.

    c. Increased version number to 2.1.0.0

  2. Clinical Main

    a. Performance improvements: ArchiveAndCleanOldFiles.py file is updated; update consists of a logic to delete the folders according to date partition.

    b. Cleaning: Removed extra ‘print’ calls from notebooks as a part of performance improvement.

PlanNet Provider Directory (Version-2.1.0.0)

STU-1.1.0

  1. PVD Preprocessing

    a. Logger fixes:

     i. Added additional fields for loggers to capture nulls on required fields on errorlog tables.
    

    b. Standardized the error log table names:

     i. Changed the error log table names to get it in sync with Common repo changes. Previously the error log table names included 'pvd’ as their substring, now it is changed to ‘providerdirectory’.
    

    c. Enabled all the references for all the profiles:

     i. Previously only required references were enabled to get the references from other profiles, for this version all the references are enabled to get the references.
    

    d. Increased version number to 2.1.0.0

  2. PVD Main

    a. Changed the filenames:

     i. Changed some file names that were commonly used in other IGs wheel file to avoid conflicts like FHIR_Upload_Functions, FHIR_Upsert_Functions, MainOrganization and MainPractitioner. 
     ii. Added ‘Pvd_’ prefix for all the above files.
    

    b. Unity catalog fix

     i. Added unity catalog for getDeltaTablePath function which gets the table names stored in S3.
    

    c. ContactPointAvailableTime fix:

     i. ContactPointAvailableTime was removed from few profiles. 
     ii. It is retained only in Organization profile.
    

    d. Performance improvements:

     i. ArchiveAndCleanOldFiles.py file is updated; update consists of a logic to delete the folders according to date partition, therefore, saves time to into each folder and match current date with file date. 
     ii. Removed extra ‘print’ calls from notebooks as a part of performance improvement.
    

DaVinci Drug Formulary (Version-2.1.0)

STU-2.1.0

  1. Formulary Preprocessing

    a. New Implementation: Created data cleaning and validation logic for five FHIR profiles as per Implementation Guide.

     i. FormularyDrug (MedicationKnowledge)
     ii. Formulary (InsurancePlan)
     iii. FormularyInsurancePlan (InsurancePlan)
     iv. FormularyItem (Basic)
     v. FormularyLocation (Location)
    

    b. Resource References: Added logic to resolve resource references to inter-resource linking.

    c. SourceFile Placeholder: Added logic to ingest DaVinci Drug Formulary data with exception of optional profiles like FormularyLocation for a fresh data ingestion run.

    d. Additional AWS features: Added cloudwatch logging to log exceptions and errors arising from the pipeline run in AWS Cloudwatch service which can be traced back later.

    e. Custom Unity catalog

     i. Added custom unity catalog onyxos_metastore for logging data
     ii.     Added unity catalog for getDeltaTablePath function which gets the table names stored in AWS S3 storages.
    

    f. EmptyFile Generator: Added logic for generating empty source files with column headers after a data ingestion run, in case of continuous/periodical data ingestion.

    g. Version update: Wheel Package Version number increased to 2.1.0.0

  2. Formulary Main

    a. Main Template changes: Created resource templates to map data from processed and validated client data to FHIR JSON which includes templates for five resources.

     i. FormularyDrug (MedicationKnowledge)
     ii. Formulary (InsurancePlan)
     iii. FormularyInsurancePlan (InsurancePlan)
     iv. FormularyItem (Basic)
     v. FormularyLocation (Location)
    

    b. Ingestion of FHIR JSONs to Firely Server

     i. Added integration to Firely server to ingest Formulary FHIR resources.
     ii. Resource validation and generation of OperationOutcome files for indicating successful ingestion or failures
    

    c. Version update: Wheel Package Version number increased to 2.1.0.0

CMS-0057 PAA Upgrades:

Carin-BB Claims (Version-2.2.0.0)

STU-2.0

  1. Claims Main

    a. Updated ArchiveAndCleanOldFiles.py for performance improvement. Update consists of a logic to delete the folders according to date partition.

    b. Wheel package version updated to 2.2.0.0

    c. New Implementation: Added Oral profile.

     i. Claims.supportinginfo: Added Orthodontics, missing tooth number, prothesis, array of additional body site (currently we support 5 additional body sites)
     ii. Claims.item.adjudication: Added benefit payment status and updated system URL accordingly.
     iii. Claims.item.productOrService.code  defaulted to not-applicable.
     iv. Claims.adjudication: This is new element, it consists of array of benefit payment status (currently we support 5 benefit status)
     v. Added Claims.item.bodysite.
     vi. Added Claims.item.subsite.
     vii. Claims.meta tag changed to ‘Oral’.
     viii. Claim.type changed to ‘Oral’.
    

    d. New Implementation: Added Vision Profile:

     i. Claims.item.productOrService.code  defaulted to not-applicable.
     ii. Claims.meta tag changed to ‘Vision.
     iii. Claim.type changed to ‘Vision’.
    
  2. Claims.adjudication: This is new element; it consists of array of benefit payment status (currently we support 5 benefit statusClaims Preprocess)

    a. ConditionalInitScript: Added Oral profile to create folders in S3 at the time of fist execution of workflow.

    b. Setup: Added Reference file generator pointer.

    c. Claims:

     i. Updated mandatory fields according to STU2.0 requirements.
     ii. Updated null check columns.
     iii. Wheel package version updated to 2.2.0.0
    

US-Core Clinical (Version-1.1.0)

STU-6.1.0

  1. Clinical Preprocessing

    a. New Implementation: Added/Modified existing column headers for enabling Clinical STU-6.1.0 functionalities. Update for resources include:

     i. AllergyIntolerance
     ii. CarePlan
     iii. CareTeam
     iv. Condition
     v. DiagnosticReport-Laboratory
     vi. Encounter
     vii. Goal
     viii. Immunization
     ix. Medication
     x. MedicationRequest
     xi. Observation-LaboratoryStatus
     xii. Observation-SmokingStatus
     xiii. Observation-VitalSigns
     xiv. Procedure
    

    b. Mandatory and Optional column validation: Updated mandatory column checks and error logging according to Clinical STU-6.1.0

    c. Date format UDF: Added UDF for handling date formats as defined by HL7 FHIR®. Handles all ISO-format dates and converts them to the required version

  2. Clinical Main

    a. Main Template changes: Changes to Clinical resource template structures to enable support for Clinical STU-6.1.0. Update for resources include:

     i. AllergyIntolerance
     ii. CarePlan
     iii. CareTeam
     iv. Condition
     v. DiagnosticReport-Laboratory
     vi. Encounter
     vii. Goal
     viii. Immunization
     ix. Medication
     x. MedicationRequest
     xi. Observation-LaboratoryStatus
     xii. Observation-SmokingStatus
     xiii. Observation-VitalSigns
     xiv. Procedure
    

    b. Resource Referencing Logic: Changes to resources’ FhirPrep logic for inter-resource linking using resource references to adapt to the upgraded version.

    c. Performance Improvements and Cleaning Old Archived Files: For performance improvements, ArchiveAndCleanOldFiles.py file is updated; update consists of a logic to delete the folders according to date partition, therefore, saves time to into each folder and match current date with file date. Removed extra ‘print’ calls from notebooks as a part of performance improvement.

DaVinci Drug Formulary (Version-1.1.0)

STU-2.0.1

  1. Formulary Preprocessing

    a. New Implementation: Created data cleaning and validation logic for five FHIR profiles as per Implementation Guide –

     i. FormularyDrug (MedicationKnowledge)
     ii. Formulary (InsurancePlan)
     iii. FormularyInsurancePlan (InsurancePlan)
     iv. FormularyItem (Basic)
     v. FormularyLocation (Location)
    

    b. Resource References: Added logic to resolve resource references to inter-resource linking.

    c. SourceFile Placeholder: Added logic to ingest DaVinci Drug Formulary data with exception of optional profiles like FormularyLocation for a fresh data ingestion run.

    d. Additional AWS features: Added cloudwatch logging to log exceptions and errors arising from the pipeline run in AWS Cloudwatch service which can be traced back later.

    e. Custom Unity catalog:

     i. Added custom unity catalog onyxos_metastore for logging data
     ii. Added unity catalog for getDeltaTablePath function which gets the table names stored in AWS S3 storages.
    

    f. EmptyFile Generator: Added logic for generating empty source files with column headers after a data ingestion run, in case of continuous/periodical data ingestion.

    g. Version update: Wheel Package Version number increased to 2.1.0.0

  2. Formulary Main

    a. Main Template changes: Created resource templates to map data from processed and validated client data to FHIR JSON. Which includes templates for five resources.

     i. FormularyDrug (MedicationKnowledge)
     ii. Formulary (InsurancePlan)
     iii. FormularyInsurancePlan (InsurancePlan)
     iv. FormularyItem (Basic)
     v. FormularyLocation (Location)
    

    b. Ingestion of FHIR JSONs to Firely Server

     i. Added integration to Firely server to ingest Formulary FHIR resources.
     ii. Resource validation and generation of OperationOutcome files for indicating successful ingestion or failures
    

    c. Version update: Wheel Package Version number increased to 2.1.0.0

General Repo (SAFHIR-DATAINGESTION-UTILS)

  1. Common (for all IG):

    a. Added a write to output function to commonfunctions file.

    b. Updated UDF in commonfunctions file to accommodate date columns with empty values or ignore the columns if not present in the file.

    c. Wheel package version increased to 2.1.0.0 from previous implementation.

  2. Provider Directory:

    a. Changed the log table name in reporting dashboard which included PVD as a prefix to ‘Provider Directory’

    b. Added PVDFhirPrep() function which gets the references from reference tables.

  3. Formulary:

    a. Error log count now calculates error records with null identifiers and other errors (400 validation, mandatory columns missing, etc.) as total number of error records for Formulary in Reporting Dashboard

Client Apps Team

Provider Access API

In response to the CMS Interoperability and Patient Access final rule (CMS-0057), the Provider Access API establishes a secure, standardized way for healthcare providers to electronically retrieve their patients’ health information directly from health plans (payers). This eliminates the need for manual data entry and faxing requests, streamlining workflows and reducing administrative burden for providers.

Key features of of Provider Access API includes:

  1. Member Attribution: The Provider Access API leverages claims data to automate the creation of member attribution lists. This ensures providers have access to the most up-to-date information on their assigned patients, reducing administrative burden and improving care coordination.

  2. $Data Export of US Clinical, Claims and Supporting resources: Provider Access API utilizes HL7 bulk data standards to export clinical and claims data without financial information at patient and group level.

  3. OnyxProvider: WebApp utilizing Provider Access API’s to provide a user friendly UI for healthcare practitioners to access their patient information

OnyxIDM

A cutting-edge Identity Management Solution, designed to streamline access control and enhance security across any digital ecosystem. OnyxIDM seamlessly integrates with OAuth 2.0 protocol, providing a robust and flexible authentication and authorization framework.

With OnyxIDM, users can securely authenticate and authorize access to resources with ease, whether it’s within an organization’s network or across third-party applications and services. OAuth 2.0 support ensures standardized and secure access delegation, allowing users to grant limited access to their resources without compromising sensitive information.

Key features of OnyxIDM include:

  1. Single Sign-On (SSO): Simplify user access with SSO capabilities, enabling seamless authentication across multiple applications and services.

  2. Centralized Access Control: Gain granular control over user access rights and permissions from a centralized dashboard, ensuring compliance and minimizing security risks.

  3. Enhanced Security: Leverage OAuth 2.0’s robust security mechanisms to safeguard against unauthorized access and protect sensitive data.

  4. Customizable User Experience: Tailor the authentication process to align with any brand identity and user preferences, providing a seamless and intuitive experience.

Electronic Prior Authorization LITE (Coverage Requirements Discovery)

A Prior authorization process that’s digitally enhanced to automatically allow the payers to decide based on the request from the providers.

The CDS Hooks specification describes the RESTful APIs and interactions using JSON over HTTPS to integrate Clinical Decision Support (CDS) between CDS Clients (typically Electronic Health Record Systems (EHRs) or other health information systems) and CDS Services.

Key features of ePA-CRD Lite includes:

  1. Registration: CDS(Clinical Decision Support) services register with the CDS Hooks endpoint in the EHR system. This involves providing metadata about the service, including its capabilities and supported hooks

  2. Hook Triggering: When a clinician’s workflow triggers a registered hook, the CDS Hooks engine sends a request to the registered CDS service associated with that hook. The types of hooks supported are: Order Sign, Order Select, Appointment book, Encounter Start and Patient View

  3. Hook rules implementation with Clinical Quality Language (CQL): Clinical Quality Language (CQL) is a high-level, domain-specific language focused on clinical quality and targeted at measure and decision support artifact authors. Currently within the CRD lite, CQL is used to define Hook Rules. These Hook Rules written in CQL are obtained based on Medical Policy Guidelines

  4. Card Retrieval: The CDS service processes the request and generates one or more cards with relevant decision support information. These cards are then sent back to the EHR via the CDS Hooks endpoint

  5. Display: The EHR displays the received cards within the clinician’s workflow, presenting the decision support information at the right time and in the right context

PAA Team

Formulary

  1. Formulary Preprocess (V4.3)

    a. Created Formulary STU-2.0 data pipelines for InsurancePlanLocation and PayerInsurancePlan.

    b. Implemented a unified logic for merging multiple files across all resources.

  2. Formulary Main (V4.3)

    a. Added a logic to facilitate the uploading of report files to client-specific destinations.

    b. Integrated new templates for InsurancePlanLocation and PayerInsurancePlan resource and updated the templates for Basic, MedicationKnowledge, InsurancePlan, List (V1.1), MedicationKnowledge (V1.1).

    c. Implemented fhirprep logic for InsurancePlanLocation and PayerInsurancePlan, updated the code snippet to seamlessly process CSV or JSON files in FC&Upload&Upsert.

    d. Updated sql script to add the reference tables and error log tables for InsurancePlanLocation and PayerInsurancePlan Resources.

    e. Integrated new tasks into our workflow to provide comprehensive support for the InsurancePlanLocation and PayerInsurancePlan Resources.

PVD

  1. PVD Preprocess (V4.2)

    a. The logic for merging multiple files has been implemented, and a mechanism for creating empty files has been added.

    b. A new notebook was added to get the spark session for all the preprocessing notebooks.

  2. PVD Main (V3.5)

    a. Import library fix for the new wheel package name for all the main notebooks.

    b. Updated the template for all the profiles with regards to new mappings and references.

    c. Updated the folder structure name for all the required notebooks. Added logic for deleting the FHIR PAAS Records from the Server based on the meta tag.

    d. Unique row count fix for Fhir-prep, FHIR_Prep_Transform and preprocAuditErrorLogging, also added preprocessing file check before going for upload and upsert.

    e. Added error logging logic to track the count in FHIR Converter.

    f. Updated the methods in commonfunctions, SQLHelper and FhirPrepTransformations.

    g. Workflow got updated with latest data flow. All the parallel tasks have been removed.

  3. PVD Main (V3.6)

    a. References issue fix for all profiles in FhirPrepTrans, and the FhirPrepTransformations notebook.

    b. Upgraded the templates for Practitioner, HealthcareService, Organization, and InsurancePlan resources.

    c. Archiving source file fix for all the profiles in cleanArchivedFiles, and the ArchiveFilesRemoveLogFiles notebook.

    d. SQL script got updated to alter the table.

Claims

  1. Claims Preprocess (V4.3)

    a. Upgrade to the headers used for duplicate check and mandatory check.

    b. Added new logic to create the empty source file and added merge logic in Copy_ADLS_to_DBFS_rename.

    c. The new Cross Walk Load notebook was introduced to load the given crosswalk file into the azure sql table and delta table. Trigger command got added into the CopySourceFiles notbook for the same.

    d. Removed GlobalSparkSession and handled empty string more efficiently in all the preprocessed Notebook.

    e. Identifier update for Claims, Coverages, Patient and MemberMeta using processedXwalk to compare and change the identifier value to those preprocess only where we had patient identifier change.

  2. Claims Preprocess (V4.3.1)

    a. Turned off archival for source files.

  3. Claims Preprocess (V4.5)

    a. Latest Upgraded version of preprocessing to handle all the claims profile.

  4. Claims Main (V4.3.1)

    a. Code Enhancement for Deleting Old Archived Files from DBFS.

  5. Claims Main (V4.4)

    a. Added new FHIR elements for all the profiles.

    b. Updated/Modified SQL queries as per the requirement for all the profiles.

    c. Two new custom code files generated as per HL7 and code changes made to load them to database.

    d. New logic added to create empty process_note parquet file if it is not already available into DBFS.

    e. Upgraded nuke functionality with the deployment of the new job workflow JWF_KILL_RESOURCE.json to our Azure Data Brick environment. Linked Reference Load with workflow.

    f. Two new database tables originalXwalk and processedXwalk got introduced.

  6. Claims Main (V4.5)

    a. Added new FHIR elements for Patient and Practitioner profiles.

Clinical

  1. Clinical Preprocess (V4.5)

    a. Turned off archival for source files.

  2. Clinical Main

    a. No change

Back to Release Notes Summary

[]: