PL 012.pdf
PDF 263 KB Posted
- Attached to
- BABYNET INTEGRATED CASE MGMT SYSTEM State and local contract opportunity
- Solicitation number
- 5400024726
- Issued by
- Richland County, South Carolina
About this file
This is a technical requirements document for the BABYNET Integrated Case Management System replacement project for South Carolina's Department of Health and Human Services (SCDHHS). The document, specifically PL 012, details data field mapping requirements for ingesting 834 enrollment transaction data from the current system into the replacement system. The project involves establishing protocols for Third Party Liability (TPL) insurance information management, recipient record creation and updates, and integration workflows through South Carolina's MES Core Integration Hub. Key functional requirements include matching carrier codes and policy numbers against system tables, handling new referrals, re-referrals, and insurance updates, automatically ingesting and processing monthly updates to carrier code tables, and generating reports for TPL lapse dates thirty days in advance to inform Babynet operations teams about required payor source updates on active Individualized Family Service Plans.
The document establishes detailed ingest logic scenarios for recipient data management, including protocols for Medicaid ID matching, creation of new records, retention of existing information when no updates are provided, and handling of PCAT (Provider Category) information prioritized by most recent date. TPL information must be retained during re-referrals when carrier codes and policy numbers match existing records, archived and replaced when insurance updates occur, and flagged as "Unknown" when carrier codes do not match system tables until the next scheduled system table update. The document addresses field-level requirements including greying out TPL fields in the Financial Support Screen and requires that the replacement system ingest all insurance occurrences rather than only primary insurance, with provisions for system synchronization between SCDHHS and the replacement system prior to go-live implementation.
View the file
Other files for this state and local contract opportunity
| File | Type | Posted |
|---|---|---|
| PL 016.pdf | ||
| ATTM 001.pdf | ||
| Amendment 2 24726.pdf | ||
| Amendment 1.pdf | ||
| ATTM 008.xlsx | XLSX spreadsheet | |
| ATTM 007.docx | DOCX document | |
| PL 015.pdf | ||
| Award Extension 24726.pdf | ||
| ATTM 010.pdf | ||
| PL 010.pdf | ||
| ATTM 015 Disc Control.docx | DOCX document | |
| ATTM 003.pdf | ||
| ATTM 009.pdf | ||
| ATTM 005.pdf | ||
| PL 011.pdf | ||
| ATTM 013.xlsx | XLSX spreadsheet | |
| ATTM 014.pdf | ||
| ATTM 002.pdf | ||
| PL 013.pdf | ||
| ATTM 007 Q & A.pdf | ||
| PL 017.pdf | ||
| PL 014.pdf | ||
| BabyNet RFP.pdf | ||
| Award Posting Notice.pdf | ||
| ATTM 011.docx | DOCX document | |
| ATTM 006.pdf | ||
| ATTM 012.pdf | ||
| ATTM 004.pdf |
Show all 28
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
PL 012 Data Field Mapping from 834
Notes:
• Use South Carolina’s MES Core Integration Hub, refer to PL 002 TRA INTEGRATION HUB for details.
• Follow agency standards for transmitting child referral data between the solution and SCDHHS systems using the MES Core Integration Hub.
• 834 currently does not send private insurance name. Private insurance name is a required field in 837P during Claims submission. The assumption here is SCDHHS would do a data extract of TPL information from their system so that Replacement System can have the latest TPL table to have both systems (SCDHHS and Replacement System) in sync.
• Ingest all OHI into their system
• Automatically ingest and process updates to the system table using a regularly delivered file
(current standard is monthly) of all possible carrier code and carrier description information.
Chadwick K. Knight, PhD Insert detailed referral requirements that were previously written into this section
Stephanie Donald Ingest requirements-Anant
Michael Brotherton @Anant Pai - Contractornant Pai - Contractor imported TPL requirements from 6-16 document
Michael Brotherton @Anant Pai - Contractor Please review one last time and remove any unnecessary formating
Michael Brotherton @Anant Pai - Contractor
Anant Pai - Contractor Made the change. Also not calling out what "all fields mean" .I do have a supplemental document containing these fields that I can share with Daniel.
Michael Brotherton @Samuel Fields @Anant Pai - Contractor update this and PL 012. Stephanie bulleting workflow and cross referencing onbase to add anything missing. Member Management Requirements Section and Referral Workflow Requirements
Michael Brotherton @Samuel Fields @Anant Pai - Contractor
• Ensure that the Carrier code/Policy Number on 834 matches Carrier code/Policy Number on system Table.
o In case of new referral-If carrier code sent on the 834 matches the carrier code and policy number on the insurance table then ingest all TPL information into the (Replacement System TPL screen). We can define all TPL fields only when we know the fields present in Replacement System today.
o In case of re-referral-If there is existing TPL information for the recipient (and the carrier code/policy number matches), then the system retains the Existing TPL information.
o In case of Insurance gets updated in MMIS-If the Carrier code/Policy number are different (but matches the table), then archive the existing TPL information and add the new policy on the financial support screen.
• Carrier code on the 834 does not match the carrier code on system table.
o Ingest all TPL information sent on the 834. The unknown insurance name must be flagged on the report. If carrier code codes do not match the table, then default the TPL name to “Unknown” until the next system table update, at which time the TPL record must display the correct insurance name information automatically.
• No TPL information sent on the 834.
• If no TPL information is sent on the 834 but the recipient has existing TPL information on the financial support screen, then retain the existing TPL information.
• Lapse date payor source impact.
o A report or notification needs to be generated which will inform the Babynet operations team about the TPL lapse date which will result in a payor source update on the active IFSP (administrative review).
o Report to be generated thirty (30) days before the lapse date. Service coordinator to have an option to download a report where the TPL information will be sorted based on lapse date.
• Greying out the TPL fields in Financial Support Screen. Will include the entire field after referring the screen.
o Fields Include-
Insurance Company Policy Number Carrier Code Insurance Effective Date (Start and End)
Recipient Ingest requirements-
a. Medicaid ID match- update the existing member record with updates or new information present on the 834.
b. Medicaid ID not match- create a new record with all the information present on the 834.
c. No information does not mean override the existing information with blanks (do not update existing information).
d. Keep in mind that currently if MMIS does not have social security numbers, zeros are sent on the Flat file to MES (000-00-0000). MES would truncate this information.
e. Based on the import logic, the current system takes in the latest PCAT information. SCDHHS has five (5) occurrences of PCAT info that SCDHHS sends on the 834 and the topmost PCAT on the 834 information is considered to be latest. PCAT information is sent on descending order based on the most recent dated PCAT on top.
Scenarios-
a. Recipient existing currently with a Medicaid ID. Send an 834 with a matching Medicaid ID.
Expected result- no duplicate records will be created for the recipient using the current matching logic.
Michael Brotherton @Anant Pai - Contractor can this question be answered and reformatted for the RFP?
Anant Pai - Contractor Ideally these will be part of ingest requirements, but yes i have added a comment for Stephanie and Sam to weigh in
Anant Pai - Contractor @Samuel Fields ....is this scenario possible in the new system? Are there any reasons why new TPL info will be a mismatch between MMIS and new system. I am assuming before going live with a new system, there will be TPL sync activity to carry over all relevant TPL data from MMIS and if TPL info cannot be manually entered to the new system then the mismatch shouldn't happen?
Samuel Fields and @Anant Pai - Contractor revised. Please read and make sure my intent is clear (added a new bullet two up). Stephanie, we need to remove the focus in this section on "Primary" since we expect them to ingest "all" insurances, correct? If so, Anant, please revise.
Stephanie Donald @Anant Pai - Contractor this makes sense to me. This section has "BRIDGES" throughout. Shouldn't we take that out and make it more general or replace the word "BRIDGES" with "current system?"
Samuel Fields Agree, we should change anything in the entire RFP (where it makes sense, which I think is everywhere) that says BRIDGES to "current system". @Anant Pai - Contractor can you take care of that?
Anant Pai - Contractor @Stephanie Donald @Michael Brotherton ...have removed bridges from the verbiage.
Rebecca Lopez What does this mean?
Michael Brotherton @Anant Pai - Contractor
Anant Pai - Contractor Should be a new bullet point. So every TPL policy has a lapse/end date. As soon as TPL lapses then we expect the system to generated a report for operations team, for them to update the IFSP accordingly.
Michael Brotherton @Anant Pai - Contractor TPL Ingest Requirements Imported from 6-16 Document. Anant and Sam should check. There is a second document dated 5-25 Bridges Ingest Logic that is contains additional information and may need to be reconciled into one document to replace these bulleted items.
Rebecca Lopez Several "should" in this section, make sure it should not be "must."
b. Recipient existing currently with a Medicaid ID. Send an 834 with a new Medicaid ID for the same recipient keeping all other information intact.
Expected result – a new record with a new ID must be created.
c. Multiple recipients exist in the current system with the same Medicaid ID and recipient with the same Medicaid ID is sent on the 834.
Expected result – update both the records with the same Medicaid ID with the new information sent on the 834.
d. Based on the import logic, the current system shall take in the latest PCAT information. SCDHHS has five (5) occurrences of PCAT information that SCDHHS sends on the 834 and the topmost PCAT on the 834 information is considered to be the latest. PCAT Information is sent on descending order based on the most recent dated PCAT on top.
Re-referral matching Rules-
• Medicaid ID on 834 matches with the Medicaid ID
• Child is inactive
• 834 RSP Start Date > Referral Date
• 834 RSP Start Date > Exit Date
e. A new line of BNET RSP is sent over on the 834 (new dates) for a recipient without an exit date for the recipient.
Expected result - the existing referral date will not be updated with new line of BNET RSP date.
f. A new line of BNET RSP is sent over on the 834 (new dates) for a recipient who is inactive but 834 RSP StartDdate is < than Referral Date.
Expected result - the existing referral date will not be updated with new line of BNET RSP date.
g. A new line of BNET RSP sent over on the 834 (new dates) for a recipient who is inactive in Bridges but 834 RSP Start Date is > than Referral Date and < than the Exit Date.
Expected result - the existing Referral Date will not be updated with new line of BNET RSP date.
h. A new line of BNET RSP sent over on the 834 (new dates) for a recipient who is inactive but 834 RSP Start Date is > than Referral Date and > than the Exit Date.
Expected result - the existing Referral Date will be updated with new line of BNET RSP date.
Rebecca Lopez Is this RSP Start Date?
Michael Brotherton @Anant Pai - Contractor
Anant Pai - Contractor That is correct.
File details come from the government source that posted it. Updated .