Exhibit_5__-_Technical_Specification_-_Premium_Interface.pdf
PDF 322 KB Posted
- Attached to
- Designated Provider/US Family Health Plan - Data Support Federal contract opportunity
- Solicitation number
- HT0011-13-R-0001
- Issued by
- Defense Health Agency
About this file
Exhibit 5 - Technical Specification - Premium Interface
View the file
Other files for this federal contract opportunity
Show all 18
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
DoD
Defense Manpower Data Center
Defense Enrollment Eligibility Reporting System/ Military Health System (DEERS/MHS)
Technical Specification for the
Premium Interface
Version 1.4 March 16, 2012
Technical Specification for the Premium Interface
DMDC iiVersion 1.4 – March 16, 2012
Document History
Document Version Date Change(s)
1.0 May 13, 2011 Initial Draft.
1.1 August 24, 2011 1. Updated HCDP_PREM_FREQ_CD with value ‘D’ for request to begin EFT or allotment (one month payment).
2. Added a note that HCDP_PREM_FREQ_CD with value ‘R’ includes a three month payment.
3. Fixed example in Section 12.2.5 where the dollar amount had three decimal places.
1.2 February 16, 2012 Added note in Section 8.3 explaining that if the PAID_PERD_END_DT occurs after the policy end date, or if the funds sent by the Contractor will move the PAID_PERD_END_DT more than two fiscal years into the future, DEERS will apply those funds as a credit to the policy (even if the credit amount is greater than one month’s premium).
Corrected the filename in the Premium Interface Sequence Diagram.
Formatted examples with $sign for credit amounts.
1.3 February 23, 2012
1.4 March 16, 2012 Added changes relevant to migrating medical Contractors from fee to premium model plans and proration logic.
DMDC iiiVersion 1.4 – March 16, 2012
Contents
1.0 DOCUMENT PURPOSE 1
2.0 REFERENCED DOCUMENTS 1
3.0 TECHNICAL PROCESS FLOW 1
4.0 SECURITY 3
5.0 COMMUNICATIONS 3
6.0 TECHNICAL REQUIREMENTS 3
7.0 IDENTIFICATION 4
8.0 TRANSACTION TYPES 5
8.1 PREMIUM PAYMENT TRANSACTIONS 5
8.1.1 PREMIUM PAYMENT BUSINESS RULES 6
8.2 ADJUSTMENT TRANSACTIONS 6
8.2.1 PREMIUM ADJUSTMENT BUSINESS RULES 76
8.3 CALCULATING THE PREMIUM PERIOD 7
8.3.1 BUSINESS RULES 7
8.4 PREMIUM RECALCULATIONS 9
8.5 DISENROLLMENT TRANSACTIONS 10
8.5.1 BUSINESS RULES 10
9.0 INPUTS 12
9.1 ENROLLMENT PREMIUM TRANSFER (BEPPT) VERSION 4 FOR PREMIUM PAYMENT,
ADJUSTMENT, AND DISENROLLMENT REQUESTS 12
10.0 OUTPUTS 14
10.1 ENROLLMENT PREMIUM PAYMENT ACKNOWLEDGEMENT (BEPPA) FOR PAYMENT,
ADJUSTMENT, AND DISENROLLMENT REQUESTS 14
11.0 PREMIUM TRANSACTION ERROR AND WARNING CODES 16
11.1 PLACEHOLDER ERROR AND WARNING CODES 19
12.0 INPUT AND OUTPUT EXAMPLES 20
12.1 BEPPT RECORDS 20
12.2 BEPPA RECORDS 20
13.0 EXAMPLE SCENARIOS 21
13.1 PAYMENTS 21
13.1.1 MONTHLY PAYMENT, NEW TRS FAMILY POLICY 21
13.1.2 MONTHLY PAYMENT, NEW TRS FAMILY POLICY WITH OVERPAYMENT 21
13.1.3 MONTHLY PAYMENT, EXISTING TRS FAMILY POLICY WITH OVERPAYMENT 22
13.1.4 MONTHLY PAYMENT, EXISTING TRS FAMILY POLICY WITH PRORATION DUE TO
POLICY ENDING MID-MONTH 23
13.1.5 MONTHLY PAYMENT, EXISTING TRS FAMILY POLICY WITH PRORATION DUE TO
POLICY BEGINNING MID-MONTH 23
DMDC ivVersion 1.4 – March 16, 2012
13.1.6 QUARTERLY PAYMENT, EXISTING FAMILY MEDICAL OR TDP POLICY WITH CREDIT ON
FILE 24
13.1.7 QUARTERLY PAYMENT, EXISTING FAMILY MEDICAL OR TDP POLICY WITH
CHANGING PREMIUM AMOUNTS AND OVERPAYMENT DUE TO EXISTING CREDIT 25
13.1.8 QUARTERLY PAYMENT FOR A FAMILY MEDICAL POLICY WITH A MID-MONTH
WAIVER 2625
13.1.9 QUARTERLY PAYMENT FOR A FAMILY MEDICALLY RETIRED POLICY 26
13.2 ADJUSTMENTS 27
13.2.1 BASIC ADJUSTMENT OF A MONTHLY PREMIUM FOR A TRS POLICY 27
13.2.2 ADJUST OUT ALL TRS PREMIUMS FOR A POLICY (ZERO-OUT PREMIUMS) 27
13.2.3 ADJUST OUT A MONTHLY TRS PREMIUM WITH AN OVER-ADJUSTMENT, EXISTING
CREDIT 28
13.2.4 ADJUST OUT A MONTHLY TRS PREMIUM WITH AN OVER-ADJUSTMENT PAST THE
POLICY BEGIN DATE 29
13.2.5 ADJUST OUT A PARTIAL-MONTH TRS PREMIUM FOR POLICY ENDING MID-MONTH
<<<< FIX – THE INITIAL STATE PPED SHOULD NOT EXCEED THE POLICY
END_DT 29
13.2.6 ADJUST OUT A QUARTERLY MEDICAL OR TDP PREMIUM WITH CHANGING PREMIUM
AMOUNTS 30
13.3 DISENROLLMENT 31
DMDC 1Version 1.4 – March 16, 2012
1.0 Document Purpose
The DMDC and the TRICARE Management Activity (TMA) have created a number of documents defining the roles and responsibilities of each organization. This document defines the specifications for processing Premium Payments and Disenrollments for Failure to Pay Premiums transactions. The intended audiences are Managed Care Support Contractors (MCSCs), Dental Contractors, and the Designated Providers (DPs), annotated throughout this document as “Contractors.” MCSCs and DPs have to use this new Premium Interface to post premiums payments effective 10/1/2012 and beyond. For payments prior to 10/1/2012, they can must use the existing Fee Interface.
2.0 Referenced Documents
This Technical Specification references and/or contains information from Chapter 3 of the TRICARE Systems Manual (TSM).
3.0 Technical Process Flow
Enrollment Premiums are paid monthly, quarterly, or annually. Contractors must send DEERS premium information separate from the enrollment using the Enrollment Premium Interface.
The Premium payment updates include new payments and payment adjustments. Contractors can resubmit enrollment Premiums rejected by DEERS.
1. All Enrollment Premium Payment Transfers (BEPPT) originate from the Contractors’ payment posting process, and DEERS retrieves them over a Virtual Private Network (VPN).
One or more times a day, a DEERS server will establish a secure SFTP session and retrieve files from a specified location on the Contractor’s server. The file naming convention is:
BEPPT.<HCDP_CNTC_CD>.YYYYMMDDhhmmss
The HCDP_CNTC_CD is a fixed value that DEERS assigns to the Contractor, and the timestamp marks the date and time that Contractor posts the file.
2. Upon retrieving the file, DEERS will process the transactions, create the Enrollment Premium Payment Acknowledgement (BEPPA) transaction for each transaction in the file, and create the acknowledgment file.
3. Once all of the BEPPT records are processed, DEERS will post the acknowledgement file containing the BEPPA records back to the Contractor using secure SFTP. The acknowledgment file will have the same HCDP_CNTC_CD and timestamp as the original file retrieved from the Contractor, but it will have a prefix of “BEPPA” instead of “BEPPT”.
Example: BEPPA.25.20030501123000
4. DEERS will change the extension on the original input file and the acknowledgment files on the Contractor’s server to “.ftc” to indicate that DEERS has processed these files.
Example: BEPPT.25.20030501123000.ftc
Note: To avoid duplicate premiums, DEERS will check the files processed at the same time to see if they are identical, and if so, one of the duplicates will be left for processing while
DMDC 2Version 1.4 – March 16, 2012 the others will have their extension changed on the Contractor’s server to “.dup” rather than the usual “.ftc”.
Premium Interface Network Diagram
Premium Interface Sequence Diagram
DMDC/DEERS
MCSC/DP A
Server
MCSC/DP B
Server
MCSC/DP C
Server
Internet
Internet
DMDC
Server
Internet
VPN
VPN
VPN
NIPRNet
NIPRNet
B2B Gateway
B2B Gateway
B2B Gateway
NIPRNet
MCSC/DP Server DEERS Computer
1) The Contractor creates the Fee Payment Transfers (BEPPT) input file.
2) DEERS retrieves the BEPPT input file from the Contractor’s server.
3) DEERS
processes the transactions and creates the Batch Enrollment Fee Payment Ac-knowledgement
(BEPPA)
transaction file.
4) DEERS returns the BEPPA records to the Contractor in an acknowledgement file. DEERS renames both the original input file and the acknowledgment files on the Contractor’s server to have the “.ftc” extension to indicate that these files have been processed.
5) The Contractor processes the acknowledgment file and determines if any transactions were rejected or produced a warning.
DMDC 3Version 1.4 – March 16, 2012
4.0 Security
The Contractor must send all Premium Information transactions using Secure File Transfer Protocol (SFTP) over the Military Health System (MHS) Business-to-Business (B2B) gateway secured by Virtual Private Network (VPN). The VPN will use encryption to provide a secure channel for data transmission. The MHS administers the B2B gateway and VPN, including components that are physically located at the Contractor’s site. The Contractor must upgrade and comply with changes to the standard MHS VPN solution. The Contractor must provide information required to support the B2B Gateway to MHS. The requirements for the B2B Gateway may change over time, and the Contractor must upgrade and comply accordingly.
The goal of TMA security administration is to minimize maintenance of user IDs and passwords across the network and to accommodate future security strategies through current procedures.
The Contractor must comply with current DoD and MHS security requirements, as well as future enhancements based on technological advances that include, but are not limited to, Machine-to- Machine certification and authentication, Public Key Infrastructure (PKI), and other encryption options.
5.0 Communications
DEERS will retrieve files containing BEPPT records from the Contractor’s server using SFTP over a VPN. Once the files are processed, DEERS will post the BEPPA files back to the Contractor using SFTP over the VPN.
6.0 Technical Requirements
The Contractor must provide files containing BEPPT records and make those files available to DEERS through a server that is on the MHS VPN. Each input file shall contain a maximum of 5,000 records. Batches larger than 5,000 records must be broken into multiple files.
At least every 15 minutes, DEERS will log in to the Contractor server computer using SFTP over the Military Health System (MHS) VPN and retrieve any unprocessed BEPPT files. Once DEERS has processed the files and posted the acknowledgment files back to the Contractor, the Contractor must process the acknowledgment file and determine if DEERS rejected any transactions or produced any warnings. For rejected transactions, the Contractor must examine the fields in the acknowledgement information segment of the record to determine the cause of the errors, correct these errors, and then post the corrected records in a file for DEERS to retrieve. The Contractor must send corrections to DEERS within three business days. For records that produced one or more warnings, the Contractor must examine the acknowledgment segment to determine the nature of the problem and submit a correction to DEERS if necessary.
DMDC 4Version 1.4 – March 16, 2012
7.0 Identification
The Enrollment Premium Payment Transfer input record contains the following fields that uniquely identify records in the database.
HCDP_SYS_ID – The EDI system identifier for a health care delivery program system.
Includes Contractors and MTFs.
HCDP_CNTC_CD – The code that indicates a Heath Care Delivery Program Contractor sending the transaction to DEERS.
DEERS_FAM_ID – The identifier that uniquely identifies a family for the purposes of DoD benefits.
DEERS_BNFRY_ID – The identifier that uniquely identifies a family member for whom DEERS credited the Catastrophic Cap for plans that require Catastrophic Cap. DEERS currently automatically applies the Premium to the correct beneficiary based on the individual enrollment. For family plans, DEERS will apply the Premium to the family’s Catastrophic Cap, which is held under the sponsor’s family contribution amount. For Disenrollment requests, the DEERS_BNFRY_ID field should be “00”, and DEERS will disenroll all family members except those with a fee waiver in effect on the disenrollment date.
HCDP_PLN_CVG_CD – The code that represents the plan coverage a family member or sponsor has within a health care delivery program type.
HCDP_PLCY_BGN_DT – The calendar date of the beginning date of the policy.
DMDC 5Version 1.4 – March 16, 2012
8.0 Transaction Types
8.1 Premium Payment Transactions
A Premium payment transaction is used to apply a new Premium payment to a policy on the DEERS database. A Premium payment record is identified with the HCDP_PREM_ACTN_CD = “A”. The fields that are used to identify a policy on DEERS are DEERS_FAM_ID, DEERS_BNFRY_ID, HCDP_PLN_CVG_CD, and HCDP_PLCY_BGN_DT. The fields that are used to describe the payment are HCDP_PREM_PMT_DT, HCDP_PREM_FREQ_CD, HCDP_PREM_PMT_TYP_CD, and HCDP_PREM_PMT_AM. For payment transactions, the HCDP_DSNRLMT_DT should be set to blank.
HCDP_PLCY_BGN_DT – The date that the policy began.
HCDP_PREM_PMT_DT – A date field that specifies the date on which the payment is applied.
HCDP_PREM_FREQ_CD – A one-character field that describes the intended payment plan. The HCDP_PREM_FREQ_CD is for informational purposes only and will not be used in the calculation of the period for which the policy is paid. The valid values are:
A – annual
D – request to begin EFT or allotment (one month payment).
Q – quarterly
M – monthly. Note that TRS, TRR, and TYA allow only a monthly payment option.
R – request to begin EFT or allotment (three month payment).
HCDP_PREM_PMT_TYP_CD – A one-character informational field that describes the payment method type. The valid values are:
A – allotment
C – check
D – credit card
E – electronic funds transfer
M – money order
O – other
Payments with HCDP_PREM_FREQ_CD of A and Q should have HCDP_PREM_PMT_TYP_CDs only of C, D, M, or O.
Payments with HCDP_PREM_FREQ_CD of M should have HCDP_PREM_PMT_TYP_CDs only of A, D, or E.
HCDP_PREM_PMT_AM – An eight-character field that contains the payment amount expressed in the format: “ $999.99”. Payment amounts must be positive values. The maximum amount in a single payment transaction is $9999.99.
DMDC 6Version 1.4 – March 16, 2012
When processing a payment record, DEERS validates that all required fields contain valid values and are in the correct format. If DEERS finds any errors, DEERS will reject the record and generate an output record with one or more descriptions of the errors. If DEERS validates the record successfully, then DEERS will attempt to retrieve the policy information specified by the fields in the record. If DEERS cannot find a corresponding policy, we will return an error. If we find the policy, then we will perform additional validation to ensure that the input record meets all business rules.
8.1.1 Premium Payment Business Rules
DEERS only applies payments to policies that require premiums. If a payment Premium transaction indicates a policy that does not collect premiums or a plan that is not supported using the Premium model, DEERS will reject the transaction and return an error.
DEERS will not allow a payment transaction to be applied to a canceled-retained policy and will reject the transaction and return an error.
For plans where catastrophic cap applies, DEERS checks to see if the catastrophic cap and deductible (CCD) totals of the family are unlocked for plans where the payment applies to Cat Cap. If another application has locked the CCD totals, DEERS will reject the payment and issue an error on the output record along with the CCD_LOCK_CNTC_CD that locked the record. When this occurs, the Contractor must resend the payment record later. If the CCD totals are unlocked, then DEERS applies the payment to the CCD totals for the fiscal year.
Premium payments cannot be zero (0). DEERS will reject zero dollar Premium adjustments and will return an error.
If the amount of the payment would cause the Premium Period to extend beyond the policy end date, DEERS will accept the transaction and return a warningthe remaining funds as a credit. (See 8.3, “Calculating the Premium Period” for more information.)
Request To Begin Allotments for TRICARE Dental Plans must have a premium amount to cover one (1) month’s premium.
Request To Begin Allotment for TRICARE Prime Medical Plans must have a premium amount to cover at least three (3) months’ premium.
Is there a special rule for beginning allotment for TRR/TRS/TYA plans?
8.2 Adjustment Transactions
Contractors use an adjustment transaction to modify the existing amount of money applied to a policy. An adjustment record is identified using the HCDP_PREM_ACTN_CD = “B”. DEERS uses the following fields to identify a policy: DEERS_FAM_ID, DEERS_BNFRY_ID, HCDP_PLN_CVG_CD, and HCDP_PLCY_BGN_DT. The fields used to describe the adjustment are the same as for a payment transaction: HCDP_PREM_PMT_DT and HCDP_PREM_PMT_AM. For payment transactions, set the HCDP_DSNRLMT_DT, HCDP_PREM_FREQ_CD, and HCDP_PREM_PMT_TYP_CD to blank.
DMDC 7Version 1.4 – March 16, 2012
8.2.1 Premium Adjustment Business Rules
Premium adjustments may be positive or negative, but cannot be zero (0). DEERS will reject zero dollar Premium adjustments and will return an error.
DEERS applies Premium adjustments only to policies that require premiums. If a Premium transaction indicates a policy that does not collect premiums or a plan that is not supported using the Premium model, DEERS will reject the transaction and will return an error.
Positive Premium adjustment transactions cannot be applied to a canceled-retained policy.
DEERS checks to see if the catastrophic cap and deductible (CCD) totals of the family are unlocked for plans that require posting Premiums to Cat Cap. If another application has locked the CCD totals, DEERS will reject the payment and issue an error on the output record along with the CCD_LOCK_CNTC_CD that locked the record. When this occurs, the Contractor must resend the payment record later. If the CCD totals are unlocked, then DEERS applies the payment to the CCD totals for the fiscal year.
A negative adjustment cannot be applied if it will cause the cumulative total payments and adjustments for the policy to be less than $0.
When processing an adjustment record, DEERS validates all required fields contain valid values and the correct format. If DEERS finds any errors, DEERS will reject the record and generate an output record with one or more descriptions of the errors. If DEERS validates the record successfully, then DEERS will attempt to retrieve the policy information specified by the fields in the record. If DEERS cannot find a corresponding policy, we will return an error. If we find the policy, then we will perform additional validation to ensure that the input record meets all business rules.
8.3 Calculating the Premium Period
When DEERS accepts a payment or adjustment transaction, DEERS will apply the payment or adjustment and determine the correct period for which the policy is paid. In addition, DEERS will determine whether there is additional money that cannot be applied to the policy by adjusting the paid period and apply the additional money as a credit on the policy. DEERS will return the Paid Period on the return file using the PAID_PERD_BGN_DT and PAID_PERD_END_DT. DEERS also returns any money left over that cannot be applied to the policy in the return file using the HCDP_PREM_CRDT_AM.
8.3.1 Business Rules
DEERS automatically applies any existing credit that is on file for the policy by adding the credit amount on file to the HCDP_PREM_PMT_AM before applying money to the policy.
DEERS automatically determines the amount to apply and how to apply funds based on the monthly cost of the policy and the latest Paid Period on file for the policy.
For Prime Medical plans that accept medical fee waivers, DEERS will automatically adjust the premium period based on applicable fee waivers or premium override conditions and payment tiers.
DMDC 8Version 1.4 – March 16, 2012
Applying Premium Amounts
Starting with the latest Paid Premium period on file, DEERS will apply money to the policy and create a new Paid Period and Credit amount based on the following rules:
Rule 1: For Payments and Positive Adjustments, DEERS will apply amounts that cover one
(1) month’s premium or greater to move the PAID_PERD_END_DT into the future. After the amount is applied, if there are remaining funds not enough to cover an entire month, DEERS will record the remaining funds as a credit on the policy.
Exceptions to Rule 1:
If the funds applied cause the PAID_PERD_END_DT to exceed the policy end date, DEERS will apply those funds as a credit to the policy (even if the credit amount is greater than one month’s premium).
If the funds sent by the Contractor will move the PAID_PERD_END_DT more than two fiscal years into the future, DEERS will apply those funds as a credit to the policy (even if the credit amount is greater than one month’s premium).
If there is a 100% fee waiver, DEERS will set the PAID_PERD_END_DT = Fee waiver end date or null if the fee waiver end date is indefinite. Any payments applied when there is 100% fee waiver in effect will be stored as a credit (even if the credit amount is greater than one month’s premium).
Rule 2: For Negative Adjustments, DEERS will subtract amounts that cover one (1) month’s premium or greater to move the PAID_PERD_END_DT backwards towards the start date of the policy. After the amount is applied, if the funds remaining are not enough to cover an entire month, DEERS will move the PAID_PERD_END_DT backwards an additional month and DEERS will record the remaining funds as a credit on the policy.
Rule 3: For plans that require money to apply to the Cat Cap for the family, DEERS will automatically determine which fiscal years the positive or negative amount to apply and adjust the Cat Cap appropriately. DEERS will also limit the amount of money applied to a fiscal year based on the current Cat Cap limit for the family. DEERS will not apply funds applied and stored as a credit on the policy to cat cap.
Rule 4: DEERS will calculate a new Premium Period and Credit Amount and return the new PAID_PERD_BGN_DT, PAID_PERD_END_DT, and HCDP_PREM_CRDT_AM on the return transaction.
Additional Rules
If a negative transaction would cause the PAID_PERD_END_DT to move backwards past the Policy Begin Date, DEERS will reject the transaction.
For TRR, TRS, and TYA plans, when a policy begins on a date other than the first day of the month or ends on a date other than the last day of the month, DEERS will prorate Premiums based on 1/30th of the monthly amount required and adjust the Paid Period End Date or Paid Period Begin Date to the middle of the month as appropriate for the policy.
Monthly/daily proration will be rounded down to the nearest penny.
Daily Proration logic examples:
Formatted: Not Highlight
Formatted: Not Highlight
Formatted: Not Highlight
DMDC 9Version 1.4 – March 16, 2012
1. If a TRS/TRR/TYA enrollment begins mid-month on Jan 28, premiums will be prorated for 34 days of January(Premium amount = 34/30 * Monthly premium)
2. If a TRS/TRR/TYA enrollment begins mid-month on Jan 31, premiums will be prorated for the 1 enrolled day of January(Premium amount = 1/30 * Monthly premium)
3. If a TRS/TRR/TYA enrollment begins mid-month on Jan 2, premiums will be prorated for the 30 enrolled day of January(Premium amount = 30/30 * Monthly premium)
4. If a TRS/TRR/TYA enrollment begins mid-month on Feb 28(of a leap year), premiums will be prorated for the 2 enrolled days of February(Premium amount = 2/30 * Monthly premium)
5. If a TRS/TRR/TYA enrollment begins mid-month on Feb 2(of a leap year), premiums will be prorated for the 28 enrolled days of February(Premium amount = 28/30 * Monthly premium)
6. If a TRS/TRR/TYA enrollment ends mid-month on Jan 28, premiums will be prorated for 28 days of January(Premium amount = 28/30 * Monthly premium)
7. If a TRS/TRR/TYA enrollment ends mid-month on Jan 30, premiums will be prorated for the 30 enrolled days of January(Premium amount = 30/30 * Monthly premium)
8.4 Premium Recalculations
Under most circumstances, DEERS will apply money and adjust the Premium period starting with the latest Premium record on file and by moving the Paid Period End Date forward or backward. However, there are some circumstances that require recalculation of the premium period from scratch based on the Policy Begin Date. If an event triggers a Premium recalculation, DEERS will automatically add all Premiums associated with the policy and create a new Premium record with a recalculated Premium Paid Period. The new Premium Paid Period and remaining credit will be returned on an unsolicited PNT for the affected policy. Please note that Premium Recalculations business rules are documented here for informational purposes only, Premium Interface transactions will not result in a Premium Recalculation.
The following events will result in a Premium Recalculation:
Initializing Premium data during transition of plans from Fee-Based Model to Premium Based Model
Adding, Removing, or Updating a Fee Waiver Entitlement for plans requiring fee waiver entitlements
Adjusting premiums based on retroactive changes to the amount required for a plan for a period of time
Converting Individual to Family policies
Converting Family to Individual policies
Changing Policy Begin Dates or End Dates
Merging or splitting policies
Adding, Removing, or Updating Premium Override data
Formatted: Not Highlight
DMDC 10Version 1.4 – March 16, 2012
Adding, Removing, or Updating Payment Tier data
Future Fiscal Year Credit Sweeps
Premium Rate changes
8.5 Disenrollment Transactions
The Contractor uses a disenrollment for failure to pay Premiums transaction to terminate a policy for failure to pay Premiums. A disenrollment for failure to pay Premiums transaction is identified with the HCDP_PREM_ACTN_CD = D. The fields that are used to identify the beneficiary to disenroll on DEERS are DEERS_FAM_ID, DEERS_BNFRY_ID, HCDP_PLN_CVG_CD, and HCDP_PLCY_BGN_DT. In order to disenroll for a failure to pay Premiums, DEERS checks to ensure that Premiums are delinquent, applicable cat cap amounts have not been met, and no applicable fee waivers exist for the beneficiaries enrolled in the policy. For Disenrollment transactions, the HCDP_PREM_PMT_DT, HCDP_PREM_FREQ_CD, and HCDP_PREM_PMT_AM are not applicable and should be set to blank.
To complete the disenrollment for failure to pay Premiums, the following values are required:
HCDP_PLCY_BGN_DT – The date that the policy began.
HCDP_DSNRLMNT_DT – A date field that specifies the disenrollment date.
EMC_LKOT_PERD_CD – Enrollment Management Contractor Lockout Period Code. The valid values for this field are:
N – Indicates that the beneficiary is not locked out after the disenrollment.
Y – Indicates that the beneficiary is locked out after the disenrollment.
8.5.1 Business Rules
DEERS applies disenrollments transactions for failure to pay Premiums to a policy. A disenrollment request for a failure to pay Premiums will result in a disenrollment attempt on each beneficiary in the policy.
The disenrollment date for failure to pay Premiums must be in the past, must match the date of the latest Paid Period End Date for the policy, and must be equal or greater than the day before the premium model effective date. (See 8.3, “Calculating the Premium Period” for more information.)
DEERS will cancel up to one future pending or non-pending enrollment or Primary Care Provider due to a transfer or PCM change. If there are more than one future transfers or PCM changes for a beneficiary after the disenrollment date, DEERS will not perform the disenrollment for that beneficiary and will return a warning.
For plans that require posting Premiums to cat cap, DEERS will not allow disenrollment for failure to pay Premiums for anyone in the family if the family’s cat cap contribution amount has been met for the fiscal year.
For plans that require posting Premiums to cat cap, DEERS will not allow disenrollment for failure to pay Premiums for an individual if the individual’s cat cap contribution amount has been met for the fiscal year.
DMDC 11Version 1.4 – March 16, 2012
For policies requiring fee waivers, DEERS will not allow disenrollment for a failure to pay fees for an Individual policy if it has an active fee waiver.
For policies requiring fee waivers, DEERS will not allow disenrollment for a failure to pay fees for a Family policy if it has an active fee waiver covering 100% of fees for the policy.
When all beneficiaries on a policy are disenrolled, DEERS will terminate the policy.
DEERS will not allow a disenrollment on an individual if the enrollment or primary care provider has a pending status as of the date of the disenrollment. However, up to one future pending enrollment will be canceled.
For non-Dental policies, DEERS will post a warning code when disenrollment for failure to pay Premiums is not performed on everyone in the family. (In this case, the policy is still open and the Contractor must research.) For Dental policies, DEERS will return an error and no Disenrollments will be performed unless everyone in the family can be disenrolled.
DEERS sends a Policy Notification upon a successful disenrollment for each individual.
DEERS sends the latest premium period begin date, premium period end date and credit amount on the acknowledgement layout on applying a disenrollment transaction successfully.
For non-Dental plans, if DEERS cannot disenrollthe disenrollment action would leave one individual in the family plan, DEERS will convert the policy from Family to Individual policy.
When a TRICARE Reserve Retired or TRICARE Reserve Select policy is terminated, DEERS will automatically terminate or cancel TRICARE Young Adult policies that are associated with the sponsor.
Disenrollment for Failure to Pay is not available for TRICARE Young Adult policies.
DMDC 12Version 1.4 – March 16, 2012
9.0 Inputs
The following table describes the record layout for Premium payment, adjustment, and disenrollment requests. A newline character (ASCII 0x0A) terminates each fixed-size transfer record. Nulls in the fields are not accepted. Use space characters instead.
9.1 Enrollment Premium Transfer (BEPPT) version 4 for Premium Payment, Adjustment, and Disenrollment Requests
Section/Attribute Name Size System Name Notes Payment &
Adjustment Usage Disenrollment
Usage* Header Information Application Identifier 4 APP_ID “0436” ** R R Transaction Type Code 1 TXN_TYP_CD “R” ** - Request transaction to DEERS R R
Application Version Identifier 2 APP_VRSN_ID “04” ** R R Transfer Effective Calendar Date 8 XFER_EFF_DT YYYYMMDD R R Transfer Effective Time 6 XFER_EFF_TM HHMMSS R R Transaction Return Status Code 1 TXN_RT_STAT_CD 0 Transaction Return Code 5 TXN_RT_CD “00000” Submission Identifier 8 SUBM_ID Blank Run Identifier 8 RUN_ID Blank Security Identifier 8 SCRTY_ID Blank Site Identifier 6 SITE_ID Numeric ** R R User Identifier 8 USER_ID Blank
Length Subtotal 65 System Information Health Care Delivery Program System Identifier 7 HCDP_SYS_ID Numeric R R Health Care Delivery Program Contractor Code 2 HCDP_CNTC_CD R R Message Control ID 32 MSG_CTRL_ID Blank
Length Subtotal 41 Subscriber Information DEERS Family Identifier 9 DEERS_FAM_ID R R DEERS Beneficiary Identifier 2 DEERS_BNFRY_ID R R
Length Subtotal 11 Premium Information
DMDC 13Version 1.4 – March 16, 2012
Healthcare Delivery Program Type Code 1 HCDP_TYP_CD "M" for Medical, "D" for Dental
R R
Health Care Delivery Program Plan Coverage Code
3 HCDP_PLN_CVG_CD R R
Health Care Delivery Program Policy Begin Date 8 HCDP_PLCY_BGN_DT YYYYMMDD R R Health Care Delivery Program Enrollment Premium Payment Calendar Date
8 HCDP_PREM_PMT_DT YYYYMMDD R R
Health Care Delivery Program Enrollment Premium Payment Frequency Code
1 HCDP_PREM_FREQ_CD Required only on Payment transactions.
S Blank
Health Care Delivery Program Enrollment Premium Type Code
1 HCDP_PREM_PMT_TYP_CD Required only on Payment transactions.
S Blank
Health Care Delivery Program Premium Amount to Apply
8 HCDP_PREM_PMT_AM $ / Decimal / - (e.g., $150.00, -$150.00, etc.) For payments, this value must be >= 0.
For adjustments, this value can be positive or negative, but cannot be $0.
R Blank
Enrollment Management Contractor Lockout Period Code
1 EMC_LKOT_PERD_CD Blank = for payments and adjustments
Blank R
Health Care Delivery Program Enrollment Premium Action Code
1 HCDP_PREM__ACTN_CD A = Payment B = Adjustment D = Disenrollment
R R
Requested Disenrollment Date 8 HCDP_DSNRLMT_DT YYYYMMDD Blank (Must be a space, do not truncate record)
R
Length Subtotal 40 Total 157
* R = Required field, S = Situational field ** DEERS assigns this value.
Formatted: Swedish (Sweden)
Formatted: Heading 1
DMDC 14Version 1.4 – March 16, 2012
9.210.0 Outputs
The following table describes the acknowledgement record layout for payment, adjustment, and disenrollment requests. A newline character (ASCII 0x0A) terminates each fixed-size transfer record. Nulls in the fields are not accepted. Use space characters instead.
9.310.1 Enrollment Premium Payment Acknowledgement (BEPPA) for Payment, Adjustment, and Disenrollment Requests
Section Name Attribute Name Size Column Name Notes Usage
Header Information Application Identifier 4 APP_ID “0436” R Transaction Type Code 1 TXN_TYP_CD A = Acknowledgment
E = Failure W = Warning
R
Application Version Identifier 2 APP_VRSN_ID “04” R Transfer Effective Calendar Date 8 XFER_EFF_DT From input record R Transfer Effective Time 6 XFER_EFF_TM From input record R Transaction Return Status Code 1 TXN_RT_STAT_CD “0” is returned for transactions that do not result in warnings or errors.
R
Transaction Return Code 5 TXN_RT_CD “00000” is returned for transactions that do not result in warnings or errors. A non-zero value indicates the individual error or family of errors.
R
Submission Identifier 8 SUBM_ID Run Identifier 8 RUN_ID Security Identifier 8 SCRTY_ID Site Identifier 6 SITE_ID User Identifier 8 USER_ID Length Subtotal 65 System Information Health Care Delivery Program System Identifier 7 HCDP_SYS_ID From input record S Health Care Delivery Program Contractor Code 2 HCDP_CNTC_CD From input record S
DMDC 15Version 1.4 – March 16, 2012
Message Control ID 32 MSG_CTRL_ID Catastrophic Cap/Deductible Lock Contractor
Code 2 CCD_LOCK_CNTC_CD The Contractor code for the Contractor who created the current CCD Lock record
S
Length Subtotal 43 Subscriber Information DEERS Family Identifier 9 DEERS_FAM_ID From input record S DEERS Beneficiary Identifier 2 DEERS_BNFRY_ID From input record Length Subtotal 11 Premium Information Premium Paid Period Begin Date 8 PAID_PERD_BGN_DT YYYYMMDD S Premium Paid Period End Date 8 PAID_PERD_END_DT YYYYMMDD S Premium Credit Amount 8 HCDP_PREM_CRDT_AM $ / Decimal / - (e.g., $0150.00) S
Acknowledgement Information
Premium Payment Change Transaction Response Code
1 FPMT_CHNG_TXN_RSPN_CD A = accepted, R = rejected
S
Length Subtotal 25 Error Code Information Transaction Error Code Quantity 3 TXN_ERR_CD_QY $NN repeats. The first two characters are “$0”. The third character indicates the number of errors or warnings (0–5).
S
Length Subtotal 3 Error Occurrence** Error Description 50 ERR_DESC A textual description of the error S
Return Status Code 1 RTN_ST_CD Return Status Code S Return Code 5 RTN_CD Return Code S Length Subtotal 56
Total Variable
* R = Required field, S = Situational field ** The Error Occurrence section is a repeating section that indicates any errors or warnings that are detected in the input record. This section consists of three fields. ERR_DESC is a text description of the error or warning. RTN_ST_CD is the return status code of the error or warning. RTN_CD is a numeric value that identifies the individual error or warning. Zero to five Error Occurrence sections may be present in a BEPPT transfer record. The total length for the output record would be between 147 (with no errors) and 427 (with five errors).
DMDC 16Version 1.4 – March 16, 2012
10.011.0 Premium Transaction Error and Warning Codes
The EFP application will attempt to parse the entire input record prior to processing the individual fields in the record. If the application is unable to parse a field in an input record successfully, it will return an error. Once a record has been parsed, the individual fields are validated. Each of the required fields is checked against valid field values and formats. Any errors found during validation will result in the record being rejected. The application will return up to five errors per input record. If a record is validated successfully, business rules are applied to the data before updating the database. As a result of applying the business rules, the record may be: 1) accepted without errors, 2) accepted with one or more warnings, or 3) rejected with an error.
Error/ Warning*
Return Code Message Contractor Action/Notes
W 560 Premium End Date is not within Policy Dates
The Premium amount was applied to the policy, however, the transaction resulted in a Paid Premium End Date that is after the policy end date.
W 565 Disenrollment Date must be the Latest Premium End Date
This warning indicates that the Disenrollment Date is not equal to the current Premium Period End Date for the policy.
W 508 Cannot disenroll 1 person, Medicare fee waiver
One individual in the family has an Individual Medicare Fee Waiver. The family plan may be converted to an individual plan. Does not apply to transactions for Dental policies, TRS, TRR, or TYA.
W 515 Wrong payment method for Q, A, or R Plan Type
If the Plan Type is Quarterly or Annual, then the payment method must be Check, Credit Card, Money Order, or Other. Does not apply to transactions for Dental policies, TRS, TRR, or TYA.
W 520 Not everyone in the family is disenrolled One or more family members were not disenrolled because they have multiple future transfers from the Disenrollment Date or a beneficiary has a pending primary care manager change. The family plan may be converted to an individual plan. Does not apply to transactions for Dental policies, TRS, TRR, or TYA.
E 1001 Invalid input record length Record length is not 157 characters.
E 1002 Error parsing header Error parsing header information.
E 1003 Error parsing system info Error parsing system information.
E 1004 Error parsing subscriber info Error parsing subscriber information.
E 1005 Error parsing Premium info Error parsing Premium information.
E 1110 Invalid APP_ID The application identifier is not “0436”.
E 1111 Invalid TXN_TYP_CD The Transaction Type Code is not “R”.
E 1112 Invalid APP_VRSN_ID The Application Version ID is not “04”.
E 1113 Missing XFER_EFF_DT The Transfer Effective Calendar Date is blank.
E 1114 Invalid XFER_EFF_DT The Transfer Effective Calendar Date format is not YYYYMMDD.
E 1115 Missing XFER_EFF_TM The Transfer Effective Calendar Time is blank.
E 1116 Invalid XFER_EFF_TM The Transfer Effective Calendar Time format is not HHMMSS.
DMDC 17Version 1.4 – March 16, 2012
Error/ Warning*
Return Code Message Contractor Action/Notes
E 1120 Missing HCDP_SYS_ID HCDP System Identifier is blank.
E 1121 Missing HCDP_CNTC_CD HCDP System Contractor Code is blank.
E 1125 Missing DEERS_FAM_ID The DEERS Family ID is blank.
E 1126 Missing DEERS_BNFRY_ID The DEERS Beneficiary ID is blank.
E 1130 Missing HCDP_PLN_CVG_CD HCDP Plan Coverage Code is blank.
E 1131 Invalid HCDP_PLN_CVG_CD HCDP Plan Coverage Code format is not 999.
E 1132 Missing HCDP_PLCY_BGN_DT HCDP Policy Begin Date is blank.
E 1133 Invalid HCDP_PLCY_BGN_DT HCDP Policy Begin Date format is not YYYYMMDD.
E 1134 Missing HCDP_PREM_PMT_DT The Premium Payment Date is blank.
E 1138 Missing HCDP_PREM_FREQ_CD The HCDP Premium Frequency Code is blank.
E 1139 Invalid HCDP_PREM_FREQ_CD The HCDP Premium Frequency Code is invalid. Please see business rules for proper
Plan Type Code.
E 1140 Missing HCDP_PREM_PMT_TYP_CD The HCDP Enrollment Premium Payment Type Code is blank.
E 1141 Invalid HCDP_PREM_PMT_TYP_CD The HCDP Enrollment Premium Payment Type Code is invalid. Please see business rules for Premium Payment Type Code.
E 1142 Missing HCDP_PREM_ACTN_CD The Premium Action Code is blank.
E 1144 Missing HCDP_PREM_PMT_AM The Premium Payment Amount is blank.
E 1145 Invalid HCDP_PREM_PMT_AM The Premium Payment Amount format is not +/-$999.99.
E 1148 Missing EMC_LKOT_PERD_CD TXN.EMCLKOT_PERD_CD is blank.
E 1149 Invalid EMC_LKOT_PERD_CD TXN.EMCLKOT_PERD_CD is not “Y” or “N”.
E 1150 SYS_ID/CNTC_CD mismatch The EDI HCDP identifier does not match the Contractor Code.
E 1151 No Premium required for plan The HCDP_TYP_CD is not a Premium paying plan.
E 1154 Family not in database The DEERS_FAM_ID provided does not exist in the DEERS database.
E 1155 No policy record found A policy could not be found using the information provided in the transfer record. Correct and resubmit.
E 1158 No enrollment found As of the Disenrollment Date, there were no enrollments found for the policy. All the family members were already terminated.
E 1161 No disenrollment, fees waived The family cannot be disenrolled because the family or policy has a current applicable fee waiver.
E 1180 CCD record locked Resubmit the record without any changes.
E 1187 No disenrollment, outside policy dates Disenrollment cannot be outside of the policy dates. If there are no Premiums paid on a policy and the policy is being canceled, then the Disenrollment Date should be one day prior to the Policy Begin Date.
E 1210 Invalid HCDP_PREM_ACTN_CD The Premium Action Code is invalid. Please see business rules for the Premium Action Code.
E 2105 Invalid HCDP_PREM_PMT_DT The Premium Payment Date format is not YYYYMMDD.
DMDC 18Version 1.4 – March 16, 2012
Error/ Warning*
Return Code Message Contractor Action/Notes
E 4305 Payment transaction cannot have a negative amount
Payment transaction cannot have a negative amount. Correct and Resubmit.
E 5315 Total Payments and Adjustments cannot be < 0
The total payments and adjustments applied to a policy cannot be less than zero (0)
E 5316 Incorrect Amount Request to begin Allotment
Request To begin Allotment requires correct premium amounts to be collected. Please see business rules.
E 7310 Cannot disenroll, terminated policy The family cannot be disenrolled because the family was already disenrolled for another reason.
E 7415 Disenrollment Date must be < SysDate Disenrollment for failure to pay Premiums cannot take place in the future.
E 7418 Could Not Disenroll Family Family could not be disenrolled due to a TRICARE Young Adult (TYA) policy, a TDP
Policy where one or more family members could not be disenrolled, or an unknown error occurred.
E 9020 Only Negative Adjustments Allowed When a policy is canceled-retained due to an eligibility change only negative adjustments transactions are allowed to be posted to the policy.
E 9030 Cannot Disenroll, Policy Soft Canceled Disenrollment due to failure to pay Premiums are not allowed for canceled-retained policies.
E 9040 Cannot Disenroll Family The policy cannot be disenrolled due to multiple future enrollments, a pending BWE transaction, or other enrollment error.
E 9050 Missing or invalid HCDP_TYP_CD The HCDP_TYP_CD is invalid or blank E 9060 Invalid or Missing HCDP_DSNRLMT_DT The transaction is a disenrollment transaction and the HCDP_DSNRLMT_DT is invalid or missing E 9070 Invalid Premium Amount The HCDP_PREM_PMT_AM is $0. The transaction is ineffective.
E 9080 DisenrollDate must be > MODL_EFF_DT Disenrollment date must be greater than premium model effective date.
* Error/Warning indicates whether DEERS accepted the transaction.
E = Error – DEERS rejected the transaction and did not post to the database. Errors must be corrected and the transacted resubmitted for processing.
W = Warning – DEERS accepted the transaction; however, the transaction needs to be reviewed for one or more reasons. Do not resubmit transaction.
DMDC 19Version 1.4 – March 16, 2012
10.111.1 Placeholder Error and Warning Codes
The following error and warning codes are placeholders that may be used in the future for new error and warning messages. Anytime a new error (return code 1000 or greater) is returned, the transaction was NOT posted to DEERS and must be corrected and resubmitted. Anytime a new warning (return code less than 1000) is returned, the transaction was posted to DEERS and does not have to be resubmitted; however, there was a warning related to the transaction. If DEERS adds a new error or warning using one of the placeholder codes, the error/warning message will indicate the nature of the error.
Error/ Warning*
Return Code Message Contractor Action/Notes
W 565 Placeholder Warning Placeholder Warning W 570 Placeholder Warning Placeholder Warning W 575 Placeholder Warning Placeholder Warning W 580 Placeholder Warning Placeholder Warning W 585 Placeholder Warning Placeholder Warning W 590 Placeholder Warning Placeholder Warning
E 9082 Placeholder Error Placeholder Error E 9084 Placeholder Error Placeholder Error E 9086 Placeholder Error Placeholder Error E 9088 Placeholder Error Placeholder Error E 9090 Placeholder Error Placeholder Error E 9092 Placeholder Error Placeholder Error E 9094 Placeholder Error Placeholder Error E 9096 Placeholder Error Placeholder Error E 9098 Placeholder Error Placeholder Error
* Error/Warning indicates whether DEERS accepted the transaction.
E = Error – DEERS rejected the transaction and did not post to the database. Errors must be corrected and the transacted resubmitted for processing.
W = Warning – DEERS accepted the transaction; however, the transaction needs to be reviewed for one or more reasons. Do not resubmit transaction.
DMDC 20Version 1.4 – March 16, 2012
11.012.0 Input and Output Examples
11.112.1 BEPPT Records
Payment 0436R0420100630033753000000 001000163 00389738400D20920080201201120101028MD $217.11NA
Adjustment 0436R0420101028033753000000 001000163 00202685700D20219981001201020101028MD $31.72NB
Disenrollment 0436R0420050630033753000000 001000163 00146717300D20620090201201020101028MD $000.00ND20100831
11.212.2 BEPPA Records
Accepted without any errors or warnings 0436A04200506300337530000000147419601478698 00000000000000001000163 001467173000000000000000000$0000.00A$00
Rejected with one error 0436E04200506300337534074150147419601478698 00000000000000001000163 006199133000000000000000000$0000.00R$01Disenrollment Date must be <= SysDate 407415
Rejected with multiple errors 0249E02200506300337534011000147417801478678 00000000000000001000163 000017772000000000000000000$0000.00R$01Invalid APP_ID 401110Invalid APP_VRSN_ID 401112Missing_HCDP_CNTC_CD 401121Missing HCDP_FPMT_THRU_DT 401136Missing HCDP_FPMT_TYP_CD 401140
Accepted with one warning 0436W02200305011201014005040000000000000000 0000000000000000020010202 046$0002.50A$01Account is Underpaid 400504
DMDC 21Version 1.4 – March 16, 2012
12.013.0 Example Scenarios
This section illustrates some sample scenarios. In each scenario, the table shows the values of the Premium information segment of the Premium payment record. We have omitted the fields in the other segments here for brevity. For Medical plans, the Premium Model effective date (10/1/2012) is not reflected in the below examples.
12.113.1 Payments
DEERS applies payments to policies using the identifying information in the input record. A payment transaction has an HCDP_PREM_ACTN_CD of “A” in the input record. For plans requiring Cat Cap, DEERS updates the Catastrophic Cap total for the correct fiscal years where the money is applied. For payments, DEERS restricts the HCDP_PREM_PMT_AM to be a positive value. The HCDP_PREM_FREQ_CD identifies the payment plan frequency (A=Annual, Q=Quarterly, M=Monthly).
12.1.113.1.1 Monthly Payment, New TRS Family Policy
A monthly payment is made on a new TRS policy that begins on 10/1/2010. The plan coverage code for the policy is 414, which requires a premium of $197.76 per month. The payment is made by check. The date of the payment is 9/1/2010.
Premium Payment Information
System Name Expected Value Notes HCDP_PLN_CVG_CD 414 The plan coverage code of the policy HCDP_PLCY_BGN_DT 20101001 The date the policy began HCDP_PREM_PMT_DT 20100901 The date of the transaction HCDP_PREM_FREQ_CD M An “M” indicates an Monthly payment plan HCDP_PREM_PMT_TYP_CD C A “C” indicates a payment made by check HCDP_PREM_PMT_AM $197.76 The payment amount HCDP_PREM_ACTN_CD A An “A” indicates a payment
Premium Return Information
System Name Expected Value Notes PAID_PERD_BGN_DT 20101001 Paid Period Begin Date PAID_PERD_END_DT 20101031 Paid Period End Date HCDP_PREM_CRDT_AM $0.00 Leftover Credit Amount FPMT_CHNG_TXN_RSPN_CD A An “A” indicates that the transaction was accepted
How it works: Since no premiums exist for the policy, DEERS will create the first premium record starting with the policy begin date of 10/1/2010. DEERs will use the monthly amount to determine that they are paid through the first month of the policy and return a paid period of 10/1/2010–10/31/2010. Since all of the Premiums are consumed to cover the month, DEERs will return a credit of $0.
12.1.213.1.2 Monthly Payment, New TRS Family Policy with Overpayment A monthly payment is made on a new TRS policy that begins on 1/1/2011. The plan coverage code for the policy is 414, which requires a premium of $197.76 per month. A Payment of $220 is made by check. The date of the payment is 1/1/2011.
DMDC 22Version 1.4 – March 16, 2012
Premium Payment Information
System Name Expected Value Notes HCDP_PLN_CVG_CD 414 The plan coverage code of the policy HCDP_PLCY_BGN_DT 20110101 The date the policy began HCDP_PREM_PMT_DT 20110101 The date of the transaction HCDP_PREM_FREQ_CD M An “M” indicates a Monthly payment plan HCDP_PREM_PMT_TYP_CD C A “C” indicates a payment made by check HCDP_PREM_PMT_AM $220.00 The payment amount HCDP_PREM_ACTN_CD A An “A” indicates a payment
Premium Return Information
System Name Expected Value Notes PAID_PERD_BGN_DT 20110101 Paid Period Begin Date PAID_PERD_END_DT 20110131 Paid Period End Date HCDP_PREM_CRDT_AM $22.24 Leftover Credit Amount FPMT_CHNG_TXN_RSPN_CD A An “A” indicates that the transaction was accepted
How it works: Since no premiums exist for the policy, DEERS will create the first premium record starting with the policy begin date of 1/1/2011. DEERs will use the monthly amount to determine that they are paid through the first month of the policy and return a paid period of 10/1/2010–10/31/2010. However, since the amount submitted is greater than one month premium and the policy does not end in the middle of January 2011, the remaining amount will be stored as a credit on the policy. When future payments are applied to the policy, the credit on file will be added into the transaction before the transaction is applied.
12.1.313.1.3 Monthly Payment, Existing TRS Family Policy with Overpayment
A monthly payment is made on an existing TRS policy that begins on 1/1/2010. The plan coverage code for the policy is 414, which requires a premium of $197.76 per month. A Payment of $230 is made by check. The date of the payment is 1/1/2011. The latest premium record has a Paid Period of 1/1/2010–1/31/2011 and a credit of $14.95.
Premium Payment Information
System Name Expected Value Notes…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .