Skip to main content

Domains

All Domains
Card Domain
Assumptions
Card domain uses Fiserv Optis as its card issuer
Internal Job Functions
Monetary, Non Monetary, New Card, Tokenization, Card Generation, Reconciliation, Reporting, ISO Swipes
External Job Functions and APIs
Monetary, Non Monetary, Files Mon and Non mon from Fiserv, ISO Swipes
Inter Domain Dependencies
None
Tactical Approach
United Portal can be integrated with the APIs of Card Domain via any other Business Domain
Strategic Approach
Migration of Card Data residing in various systems to Card Domain
Outstanding/Probing Questions
Would other applications directly call card domain or will be interreac via Account domains
What is not covered or not a part of this domain
Ledger balance will not be covered as part of this domain. Eg card balances would not be maintained in card domain
Will be covered as a future domain enhancement
Migrations should be estimated separately
stacked card needs to be built
OFSP APIs
Decision Quest integration /Account portability
Master Card Migration
Card Deletions
Out of scope
Viewing cards by account, since card domain does not contain account information.
Payment card claim information will not be available in card domain eg.
claim #
claim service date
claim approved amount
Claim not approved amount
Claim receipt date
Claim notes
claim status
service provided for
merchant, provider
claim information
account paid for
PIN contact number
HSID Validated etc is not available
Dispute process is not available in notional today, card ops handle it outside procedurally.
Person Domain
Assumptions
Only Source of truth for Person Data
Internal Job Functions
iMDM integration both ways, APIs for person, OCI infrastructure, Oracle database
External Job Functions and APIs
APIs for Person
Inter Domain Dependencies
Dependency on lift and shift of Faro DB to OCI
Tactical Approach
Load person data from faro database
Strategic Approach
via FINS
Outstanding/Probing Questions
Faro DB / New DB
What is not covered or not a part of this domain
Client, Employment and Account information would not be part of this domain
Client Domain
Internal Job Functions
External Job Functions and APIs
Inter Domain Dependencies
Tactical Approach for Unified Portal Delivery
Strategic Approach
Outstanding/Probing Questions
Are the existing file specs going to change ?
-For example - Census and Enrollment, Contributions.
Which back end process is going to be responsible for file processing/pre-file processing steps?
- OptumBank or Optum Financial or FINS
ClientDomain needs to retain existing employer ID for OptumBank?
-If client domain creates its own identifier can OptumBank/OptumFinancial work with the new identifier, provided a lookupService exists for translation?
-If not who is responsible for translation in API calls and File Processing calls?
What is the front end for Client Domain?
Connected Admin or BIS?
Does Client need to support existing legacy cyc employers?
Employers served through cycportal, cyc batches, cyc core?
What are the allowed configurations for an employer? distributor? Sponsor?
Assuming configurations vary for notional/non-notional - can business/someone provide the requirements for configurations?
What is not covered or not a part of this domain
TBD
Notional Domain
Assumptions
Notional domain is a platform that supports the notional capabilities. We would be exposing APIs using existing CYC (Optum Financial) DB
APIs to be developed only for CYC notional only accounts, non notional should have been migrated to FTPS, CAMS is out of scope.
Internal Job Functions
Existing Optum Financial Batch Processing
External Job Functions and APIs
Account Holder Search
Dependents
Reimbursements
Contact Updates
Claims Service
Member Service
Transactions
Direct Deposits
Debit Cards
Payee Services
PlanYear Totals
Documents And Letters
Inter Domain Dependencies
Person
Fins
Cards
Client
Bank
Tactical Approach
Build APIs on top of CYC existing database schema
Strategic Approach
Long term, each individual component should be broken down into individual schema
Ideal world, separate database with a complete redesign of the schema
Outstanding/Probing Questions
Would the batch processes need to move out to respective other domains
If the answer to above question is yes, what are all those batches and domains
Would the notional API's need to accomodate changes to integrate with any other domains
How does a client/person domain get integrated with notional
Would the notional API's be exposed through FARO
Do we consider CAMS or that is going to get migrated to CYC
Would the notional API's need to accomodate changes to integrate with any other domains
Required Timelines for each API delivery?
How to account and solution for differences between Optum Bank and Optum Financial data/functionality?
What is not covered or not a part of this domain
TBD
Bank Domain
Internal Job Functions
External Job Functions and APIs
Inter Domain Dependencies
Tactical Approach
Strategic Approach
Outstanding/Probing Questions
What is not covered or not a part of this domain
TBD
FINS Domain
WHY IS THIS DOMAIN/CAPABILITY IMPORTANT
Establish a centralized system for all file processing across Optum Financial
Standardize the data exchange format for manual setup and batch processing.
File data availability near real time to the downstream applications
Assumptions
Fins will process employer sent sftp file for enrollment,contributions,census file
Fins will perform basic file level validations
Fins will pass data to FTPS for processing
FINS will only interface with Bank domain for Fiserv processing in future
FINS will not interface with BIS or EAP(as BIS,EAP are going to retired )
PRISM FINS will not be rated for PCI data as the expectation is card files will not be sent thru FINS
FINS will add public SFTP server to allow for ECG to deliver files over the public internet to Prism FINS tenancy
Internal Job Functions
EDI processor for enrollment , contribution and census files for Optum Financial Batch Processing
Data validation, unification and staging
External Job Functions and APIs
Receiving data files from external systems (census, enrollment, contribution)
Providing insight into data processing progress and statistics
Inter Domain Dependencies
MFM as a UI for internal teams
Client Domain (Future State)
Person Domain (Future State) - employee census/demographic data
HRC - manual upload thru UI (assumption is only HSA files)
Notional Domain - enrollments and contributions related to Notional accounts
Bank Domain - enrollments and contributions related to HSA accounts
Tactical Approach
FINS Phase 1
Establish the infrastructure for FINS
Support only two types of files : Enrollments & Contributions
Pass the original files to FTPS
FINS Phase 2
Assumption : Person domain is available
Send Enrollments to Person domain
Add Person ID/FARO ID and send enrollment to CYC/ FTPS
Define the FINS unified json format (fujf)
Setup Validation rules & error format
Port over the MFM capabilities to FINS-OCI
Setup eventing to send enrollment/contribution data events
Fins will not have any interaction with customer portal but does have integrations in HRC w/ MFM data and we will continue to push out visibility to client/parters via this channel.
Strategic Approach
Leverage oracle cloud infrastructure to build an infinitely scalable file intake process. FINS will break down files into JSON data and store into a nosql backend. In the future, FINS will use streaming or events to notify domains of incoming data. FINS can fall back to rest endpoints or files if required.
Outstanding/Probing Questions
What is the timeline for availability of FARO/Person domain for FINS to use?
When will APIs be available from Person Domain for creating a new person and return a FARO/Person ID as part of the API response?
Do banking and notational domain have to update their process to accept a file with FARO ID? Answer: FARO ID will be appended to the enrollment file
Is FTPS going to build capabilities around sending responses for file processed /record level stats?
Does FINS need to expose an API to show file processed response on HRC? MFM already has integrations to HRC for file level stats.
For client files for HA migrations, we should ask our groups to use native file formats and bind to our internal identifiers. Today the current CDEX solution has limitations and is not scalable for large clients.
How will data for HA migrations know how to route to back end notional or bank domains for processing?
Waiting on a network design that supports a public SFTP server with proper security and segmentation.
Unified standard file format should be decided upon – How do we achieve this?
Does FINS accept the CYC format or the FTPS format? Answer: FTPS format
What is not covered or not a part of this domain
Processing of employer setup files
Claims files Processing
Direct Deposit File Processing
Replacement of EAP - The details for HRC - manual upload thru UI