Domains
All Domains
Card Domain
Baseball Card
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
Baseball Card
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
Baseball Card
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
Baseball Card
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
Baseball Card
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
Baseball Card
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