Exhibit_4_-_Technical_Specification_-_CCDD.pdf
PDF 214 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 4 - Technical Specification - CCDD
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
Catastrophic Cap and Deductible Database (CCDD)
Version 2.4 November 3, 2010
Deleted: 3
Deleted: April 21
Technical Specification for the Catastrophic Cap and Deductible Database
DMDC Version 2.4 – November 3, 2010 ii
Document History
Document Version Date Change(s)
2.0 July 18, 2008 Final draft (T3)
2.1 October 14, 2008 In section 7.1.3, added Contractor Code to the info
Contractors to send when placing a Lock on CCD Totals.
In sections 7.2, replaced “N” with “blank” for the Newborn Addition Indicator Code to be set to when querying DEERS to check if a request to add a newborn is posted.
In sections 9.2, removed return codes 10021, 10022, 10023 and added them to the table in section 9.3.
Section 6.0 (Communications) updated to remove TCP/IP communication related information and replaced with HTTP related communication.
2.1.1 March 25, 2009 Updated section 6.1.2 to replace upper case “MSG” with lower case “msg”.
2.2 October 27, 2009 In Section 9.2, removed instructions to use “override code” when trying to re-add a newborn.
In Sections 10.2 and 10.3, reworded Transfer Section Quantity (XFER_SECT_QY) fields and added minimums and maximums for clarity.
In Section 10.4, added “0” to app_id “0274”.
In Section 10.1 and every other section in the TR layout, reworded Notes column for run_id.
In Sections 9.1 and 9.2 deleted mutually inclusive error codes and spelled out their descriptions.
In Section 10.1, replaced “can be blank for newborns” with “if blank returns family totals only”.
In Section 10.1 updated the app_id to the current version of “07”.
In Section 10.4, replaced “can be blank for newborns” with “must provide deers_bnfry_id, “00” for newborns” and made “R” (required) rather than “S” (situational).
In Section 9, added Response code introduction.
In Sections 9.1 and 9.2, removed Error codes 410 and 116, because they cannot be set in this interaction.
In Sections 9.1 and 9.2, clarified contractor responses for error codes 100, 102, and 408.
In Sections 9.1 and 9.2, added new Error 330 Invalid Lock Indicator.
In section 5.0, added a paragraph describing the maximum
Deleted: Version 2.3
Deleted: Version 2.4
Deleted: April 21, 2010
Deleted: November 3, 2010
DMDC Version 2.4 – November 3, 2010 iii number of connections a Contractor can have with DMDC systems.
2.3 April 21, 2010 In Section 7.1.2 and 7.2.6, changed inquiry date range to support inquires up to six years in the past.
In Section 7.1.2 and 7.2.6, clarified fiscal years in inquiry periods.
Added Section 6.1.6, Response Time and Performance.
2.4 November 3, 2010 Updated the expected values for SUBM_ID/RUN_ID in the CCD Totals Inquiry TRs and in the CCD Update TRs.
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 iv
Contents
1.0 DOCUMENT PURPOSE 1
2.0 REFERENCED DOCUMENTS 1
3.0 CATASTROPHIC CAP AND DEDUCTIBLE OVERVIEW 1
4.0 TECHNICAL OVERVIEW 1
5.0 NETWORK SECURITY AND ENCRYPTION 2
6.0 COMMUNICATIONS 3
6.1 HTTP COMMUNICATION 3
7.0 INPUTS 6
7.1 CC&D TOTALS INQUIRY 6
7.2 CC&D UPDATE 7
8.0 OUTPUTS 10
8.1 INFORMATION RETURNED IN THE CC&D TOTALS INQUIRY 10
8.2 INFORMATION RETURNED FOR A CC&D UPDATE INQUIRY 11
9.0 RETURN CODES 12
9.1 CC&D TOTALS RETURN CODES 12
9.2 CC&D UPDATE RETURN STATUS AND RETURN CODES BY TRANSACTION TYPE 13
9.3 CC&D ERROR CODES 15
10.0 APPENDICES: TRANSFER RECORD LAYOUTS 16
10.1 APPENDIX A: CC&D TOTALS INQUIRY TRANSFER RECORD LAYOUT 16
10.2 APPENDIX B: CC&D TOTALS RESPONSE TRANSFER RECORD LAYOUT 18
10.3 APPENDIX C: CC&D TOTALS INQUIRY ERROR/WARNING RECORD LAYOUT 21
10.4 APPENDIX D: CC&D UPDATE TRANSFER RECORD LAYOUT 22
10.5 APPENDIX E: CC&D UPDATE RESPONSE TRANSFER RECORD LAYOUT 25
10.6 APPENDIX F: CC&D UPDATE ERROR RESPONSE TRANSFER RECORD LAYOUT 27
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 1
1.0 Document Purpose
This document defines the Catastrophic Cap and Deductible Database (CCDD) portion of the Defense Enrollment Eligibility Reporting System (DEERS) for T3 contractors. The intended audiences for this document are Managed Care Support Contractors (MCSCs), the Pharmacy Benefit Manager (PBM), the Designated Provider Data Integrator Contractor, and the TRICARE Dual Eligible Fiscal Intermediary Contract (TDEFIC).
2.0 Referenced Documents
This Technical Specification references and/or contains information from the TRICARE Systems Manual (TSM). (Business Rules are in Chapter 3.) The TSM is online at the TRICARE web site:
http://www.tricare.osd.mil/tricaremanuals/ts02.htm.
3.0 Catastrophic Cap and Deductible Overview
DEERS is the system of record for eligibility and enrollment information. As such, in the process of claims adjudication, the contractors query DEERS to determine eligibility and/or enrollment status for a given period of time. DEERS serves as the database of record for:
• Year to date totals for Catastrophic Cap and Deductible (CC&D) amounts
• Point of Service (POS) deductible amounts The contractor must not override this data with information from other sources.
4.0 Technical Overview
DEERS is the database of record for Catastrophic Cap and Deductible as well as Point of Service information. The contractor will send CC&D inquiries or updates to DEERS via the DEERS Catastrophic Cap and Deductible Totals Inquiry and Catastrophic Cap and Deductible Update respectively. In response, DEERS will send the DEERS Catastrophic Cap and Deductible Totals Response and Catastrophic Cap and Deductible Update Response to the contractor to acknowledge the inquiry or update and to indicate success or failure of the transaction.
The following provides a high-level sequence of events for a given transaction:
1. The contractor system creates the inquiry/update transaction and sends it to DMDC/DEERS over the Virtual Private Network as described in Section 5.0.
2. Upon receiving the transaction, DEERS pulls data according to the request (inquiry), updates DEERS (update), or rejects the transaction.
3. Based on the processing result, DMDC/DEERS creates the appropriate response transaction.
4. If there is no error and the transaction is successful, the response transaction will be returned to the contractor with the return code set to 00000.
5. If there is an error, DMDC/DEERS will return the header section and the message identification information section of the response to the contractor (see Section 10.3 for layouts).
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 2
The entire transaction (the contractor sending the request to DEERS, DEERS processing the request, and DEERS sending the response) is performed in real time for inquiries.
5.0 Network Security and Encryption
The Contractor must send all Health Care Coverage Inquiry transactions 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’s system shall have a means to adjust and control the number of connections to DMDC systems. The means to adjust the number of connections shall have the capability of implementing any changes within one business day and not require re-programming to make the change. DMDC and the Contractor shall agree on the maximum number of connections based on the operating environment, system load, and performance requirements. In all environments, the Contractor’s system shall never exceed the maximum number connections agreed to for the environment. In this context, the number of connections is defined as the number of logical interactions between the Contractor’s system and DMDC systems. In TCP/IP terms, a connection is defined as a connection in the “ESTABLISHED” status from the DMDC system perspective.
For other types of connections, the Contractor and DMDC will agree on the precise definition of a connection and how the connection is determined.
The Contractor must provide information as 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.
Catastrophic Cap and Deductible Data Transfer
Contractor
VPN VPN
DEERS
Database
DISN
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 3
6.0 Communications
6.1 HTTP Communication
6.1.1 Introduction
DMDC uses HyperText Transfer Protocol (HTTP) as the communication protocol to exchange messages. This section provides a description of how Contractors will communicate with DEERS using HTTP, the network application protocol by which such communication will occur.
DMDC will make available a Web server that will act as an intermediary between the client system and the DEERS Web Interface.
At a fundamental level, Contractors must accomplish the following to communicate with
DEERS:
• Connect to the DMDC Web server using the basic constructs of TCP/IP sockets.
• Package the Transfer Record message in an HTTP formatted request.
• Send the HTTP request to the Web server.
• Receive an HTTP response containing the response.
This is not the only method by which the HTTP connection/request/response interaction could occur. Some programming languages provide more abstracted methods of using HTTP. For example, Java has several HTTP-related classes (such as the HttpUrlConnection class) that could be used instead of the Socket class; if such a method is available, then it would be prudent to explore the possibility of utilizing it.
The client system is NOT required to implement its own Web server.
DEERS expects each client system to have two or more processes or threads communicating with DEERS at the same time, via the HTTP protocol described above. The client system may be required to open more connections to DEERS (via the Web server). The number of connections needed should be adjusted during performance tuning and based on the expected volume of transactions from the particular client site. The Contractor and and DEERS will jointly develop performance tuning data and guidelines during the contractor-testing phase of the project.
6.1.2 HTTP and the Post Request
HTTP is the application protocol that forms the backbone of the World Wide Web. HTTP has a number of request methods, headers, and codes. The “POST” request best suites the communication needs of both DMDC and Contractor systems by allowing a client to send large amounts of data to a Web server within the body of the request.
The following is a generic POST format example:
POST <URL> HTTP/1.1
Host: <hostname> Content-Type: <mime-type> Content-Length: <length>
<body>
DMDC Version 2.4 – November 3, 2010 4
The client system will utilize the HTTP POST request to send TR messages to DEERS. To execute the POST request, the client system will first open a TCP/IP socket connection to the DMDC Web server. The client system will then prefix the Transfer Record message with the appropriate POST method headers, an example of which follows:
POST URL Provided by DMDC Host: DMDC Web Server Host Content-Type: application/x-www-form-urlencoded Content-Length: Provided by DMDC msg= CCD TR Message
Notes:
• The URL will be provided by DMDC.
• The blank line between the content-length and the body of the message is required.
• The length referred to in “Content-length” includes the TR message, the parameter name
(“msg”), and the “=” sign.
• This is ASCII text in which a CRLF is present after each header line. There are two CRLFs located after the Content-Length that generate a blank line between the header and the body of the request.
• The TR message itself is one long string. CRLFs are NOT IMPLIED after each line within the TR message.
6.1.3 How Contractors Will Communicate with DEERS
The DMDC Web server will receive the above POST request and route it to a Java servlet that runs on a DMDC application server. The Java servlet then extracts the TR message from the body of the HTTP POST request and processes the request. The servlet then packages the response into HTTP format and sends it back to the client system. After having sent the POST request through the socket connection that was created with the DMDC Web server, the Contractor system will begin reading from that same socket connection. Given that the POST request was formatted similarly to the above example, the Contractor will receive the following type of response from the DEERS Web server across the socket connection:
HTTP/1.1 200 OK
Date: Fri, 05 Sep 2008 18:26:54 GMT Server: Oraclexxx Containers for J2EE Content-Type: text/html
<body - the CCD TR response>
6.1.4 HTTP and State
It should be noted that HTTP is a stateless protocol in which each request/response is executed independently. The connection to the Web server is opened, the request is sent, the response is received, and the connection is closed. State is not maintained between POSTs.
6.1.5 HTTP Status (Error) Codes
When the CCD Java HTTP servlet responds back to the Contractor client, the response will contain HTTP headers as well as the body of the response. For example:
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 5
HTTP/1.1 200 OK
Date: Fri, 05 Sep 2008 18:26:54 GMT Server: Oraclexxx Containers for J2EE Content-Type: text/html
<body - the CCD TR response>
The first line of the HTTP headers will contain the HTTP version number, a numeric status code, and a text message associated with the status code. The status code indicates whether or not problems were encountered during the transaction.
The following are the HTTP status codes that the Contractor may expect to encounter in responses returned from the CCD Java HTTP servlets:
Status Code Status Text Explanation 200 OK Request was successful.
400 Bad Request A parameter was missing from the body of the HTTP request sent to the servlet.
500 Internal Server Error Either a problem exists within the web / application server or there is a communications problem in the network.
503 Service Unavailable The CCD Servlet was not able to send a response due to unavailability of service.
6.1.6 Response Time and Performance
The DMDC systems are optimized to provide the most efficient response times to the client systems. Specifically, the DMDC Systems provide a response time of 3.0 seconds or less for 99.5% of all input transactions given that the client’s stated transaction volume does not increase more than 25% of the baseline estimate.
The response time percentage is computed on a monthly basis, and a report is provided to the client and the client’s agency summarizing the performance of the DMDC systems. The computation is performed by taking the number of transactions that had a measured response time of 3.0 seconds or less and dividing this count by the total number of transactions processed during the month and multiplying the result by 100 to get the percentage.
This response time is measured from the time the DMDC system receives the transaction until the time the response is presented to the communications network. This time does not include network latency time nor any other factors outside the control of DMDC. DMDC measures and monitors transaction response time and associated transaction volume on a daily basis to ensure this response time is maintained. It is important to note that DMDC does not provide average response time service levels because in an interactive system, average may not convey physical reality in an interactive environment.
Should the client’s transaction volume increase more than 25%, then the response time for transactions will be on a best efforts basis until sufficient resources can be brought in to support the additional workload or other actions take place to support the additional workload.
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 6
7.0 Inputs
7.1 CC&D Totals Inquiry
The CC&D Totals Inquiry is used to obtain CC&D balances for the requested inquiry period.
The CC&D totals returned will be the greater of the enrollment year or fiscal year totals. The contractor will inquire and lock CC&D totals before updating DEERS CC&D amounts. (See Sections 10.1 and 10.2 for transfer record layout details for CC&D Totals Inquiry and CC&D Totals Response.)
The following sections describe the information a contractor must provide to perform this type of coverage inquiry:
• Person/Family DEERS ID
• Inquiry period
• CC&D Lock indicator
7.1.1 Person Identification
The contractor will use the DEERS ID, returned by DEERS on the claims inquiry, for this inquiry. Either the sponsor’s or family member’s DEERS ID is used for the totals inquiry. Even though only one person’s DEERS ID is used, both individual and family totals will be returned in the response.
In the case of a Newborn where the contractor wishes to do only a family totals inquiry BEFORE they do the CC&D update and add of the newborn, leave the DEERS_BNFRY_ID blank and only the family totals and lock information will be returned.
7.1.2 CC&D Totals Inquiry Period
The inquiry period used for the CC&D Totals Inquiry may be a single fiscal year or a fiscal year range. The inquiry range cannot exceed 6 fiscal years (5 fiscal years in the past + current fiscal year). For example, if the current fiscal year is 2009, you may inquire within a range of 2004– 2009.
7.1.3 CC&D Lock Indicator
The inquiry must indicate whether or not to place a lock on the CC&D information. The lock inquiry is used to perform the inquiry for claims processing when the intention is to send updates to the DEERS Catastrophic Cap and Deductible Database (CCDD).
When the contractor indicates that they would like to place a lock, the contractor will provide a claim identifier or adjustment identifier and the Contractor code. DEERS refers to this as the CC&D Detail ID. This identifier is used for locking, and DEERS validates it when CC&D updates are sent.
DEERS supports the following lock functionality:
• Lock – The contractor inquiring is attempting to place a lock that will lock out all contractors other than the contractor organization that placed the lock. Only the contractor organization
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 7 that initiated the lock is able to update totals, and the detail identifier used for locking must match the detail identifier used for updating.
• Totals – The contractor inquiring is requesting CC&D totals only.
• Both Lock & Totals – The contractor inquiring is attempting to place a lock and requesting
CC&D totals to be returned.
If the contractor is requesting CC&D totals to be locked.
• If the CC&D totals are not currently locked, DEERS will lock the CC&D totals for the requesting contractor and return CC&D totals.
• If the CC&D totals are currently locked, DEERS will not return CC&D totals, but will return lock information indicating the contractor who has locked the totals.
Else, if no lock is requested the totals will always be returned.
The maximum period a Contractor can lock CC&D records for a family is 48 hours. If the Contractor needs more than 48 hours to adjudicate the claim, they may extend the lock for 48 hours from the time DEERS accepts the lock extension. Only the same locking Contractor that placed the lock may extend the lock, and only if the CC&D detail update identifier matches the identifier used to initially lock the record.
Note: DEERS locks all family members’ CC&D records when the Contractor places a lock on a family.
7.2 CC&D Update
CC&D amounts can be updated for the previous 6 fiscal years (5 fiscal years in the past + current fiscal year). Each transaction should only include updates for one claim. CC&D amounts for multiple claims should be sent in separate transactions. The CC&D update amounts cannot be more than $3000 or less than -$3000 for Cat Cap; not greater than $150.00 or less than -$150.00 for Deductible; and not greater than $300.00 or less than -$300.00 for Point of Service (POS).
The Contractor’s system must edit the amounts to be within the allowable range. In the split claim situation, multiple transactions must be sent for the same claim. For example, if a claim spans years and is split, updates for 2006 and 2007 must be sent in two transactions using the claim extension identifier (explained below) to distinguish the two updates from one another.
CC&D information is applied for an individual, and then accumulated for all members of the family to calculate the family totals. Beneficiaries that have eligibility under more than one sponsor (thus have more than one DEERS Family Identifier) may accumulate CC&D amounts under each sponsor; however, those amounts are only accumulated across DEERS Family Identifiers at the individual level. Only totals under each respective DEERS Family Identifier become part of each family’s totals.
CC&D amounts for a newborn are posted to DEERS by using the CC&D update transaction and setting the Newborn Addition Indicator Code to “Y”. The “Y” code indicates that a newborn is to be added. If DEERS returns and error code on a newborn add that the person is already on the database, then the contractor should query to determine if this is the same person. IF so, then use the returned information to apply the CC&D.
Newborn information within the transfer record is populated as well as the CC&D amounts.
After the newborn has been added to DEERS, the CC&D update will be posted to the database
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 8
(provided that the family record is not locked). In the event that the CC&D update was unable to be posted, it is the contractor’s responsibility to query DEERS to verify that the newborn has been created. The contractor is then to resend the CC&D update transaction, setting the Newborn Addition Indicator Code to blank.
CC&D updates should be posted to DEERS even if the limit has been met.
Contractors can resubmit CC&D updates rejected by DEERS.
The following sections describe the data contractors must provide to update CC&D amounts:
• DEERS ID: This identifies the beneficiary for whom the update is applied.
• Catastrophic cap, deductible, and/or point of service dollar amount
• Identifier for the claim or adjustment
• Claim extension identifier
• Lock information (remove or do not remove lock).
• Dates provided for the catastrophic cap and/or deductible update.
(See Sections 10.4 and 10.5 for transfer record layout details for CC&D Update Inquiry and CC&D Update Response.)
7.2.1 Person Identification
The contractor must use the DEERS ID, returned by DEERS on the Health Care Coverage inquiry for this update. Either the sponsor’s or family member’s DEERS ID is used for the totals inquiry. Even though only one person’s DEERS ID is used, both individual and family totals will be returned in the response.
7.2.2 Catastrophic Cap, Deductible, and/or Point of Service Dollar Amount The contractor sends DEERS the CC&D amount for the beneficiary. DEERS knows to which family the beneficiary belongs and rolls up the totals for the correct family using the DEERS ID.
7.2.3 Claim Identifier
The contractor sends a claim identifier for each claim or adjustment.
Note: If there is a discrepancy between the identifier used for locking and the identifier used for updating, DEERS does not allow the update.
7.2.4 Claim Extension Identifier
When a claim spans fiscal years, the claim extension (CCD_SPLT_CLM_ID) is used to identify a split claim. These claims should have the same claim identifier with a different claim extension identifier. Splitting the claim is the responsibility of the claims processor, who splits the claim, adds the claim extension, and sends this information to DEERS. The claim extension should be defaulted to “000” except in the case of a split claim. In the case of a split claim, “001” should be used for the first fiscal year to which the claim applies, “002” for the next fiscal year, and so on.
7.2.5 CC&D Lock Indicator
The inquiry must indicate whether or not to unlock or extend the current lock on the family.
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 9
7.2.6 CC&D Dates
The dates may include the date(s) of service for the claim (both begin and end date) or the fiscal year, as appropriate. These dates are necessary for accumulating the CC&D totals for the correct period and HCDP.
• For fiscal year updates, the contractor will send DEERS the fiscal year for which the CC&D applies.
• For updates associated with a claim, the period of service for the claim should be sent to DEERS, so that the information can be referenced with CC&D details.
• CC&D update dates can be a range of up to 6 fiscal years (5 fiscal years in the past + current fiscal year).
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 10
8.0 Outputs
8.1 Information Returned in the CC&D Totals Inquiry
For successful responses, DEERS sends a CC&D Totals response (as shown in Section 10.2) showing year-to-date CC&D totals for each year inquired. Both individual and family totals are displayed, showing CC&D balances separately. If there are no CC&D totals accumulated for the inquiry period requested, DEERS will show a zero value.
DEERS may send one of several response transfers to a CC&D Totals Coverage Inquiry.
If no errors occur in processing:
• CC&D Totals Response (TXN_TYPE_CD = “Y”). See Section 10.2 for format. This transfer will show year-to-date the greater of either the fiscal or enrollment year CC&D totals for each year inquired. Both individual and family totals are displayed, showing CC&D balances separately. If there are no CC&D totals accumulated for the inquiry period requested, DEERS will show a zero value.
If an error occurs:
• Inquiry Transfer Handling Error (TXN_TYPE_CD = “E”) if an error occurs in initial transfer handling or parsing (see Section 10.3 for format)
• System Error (TXN_TYPE_CD = “S”) if an error occurs in the DEERS system (e.g., DEERS_ID not found, database down) (see Section 10.3 for format)
• Application Warning or Error (TXN_TYPE_CD = “W”) if an error was detected in the Health Care Coverage application (e.g., inquiry content incorrect, locking error) (see Section
10.3 for format)
Note that for System and Application Errors, the overall format of the error transfer is the same and is described in Section 10.3. It includes only the header and the Message Identification Section. The Inquiry Transfer Handling Error (E) is also described in Section 10.3, but it includes only the header without the Message Identification Section.
8.1.1 Data Returned in a CC&D Totals Inquiry based on Lock
If the contractor is requesting CC&D totals to be locked:
• If the CC&D totals are not currently locked, DEERS will lock the CC&D totals for the requesting contractor and return CC&D totals.
• If the CC&D totals are currently locked, DEERS will not return CC&D totals, but will return lock information indicating the contractor who has locked the totals.
If the contractor is not requesting CC&D totals to be locked:
• If the CC&D totals are currently locked, DEERS will return the CC&D totals and the lock information indicating the contractor who has locked the totals.
• If the CC&D totals are not currently locked, DEERS will return CC&D totals.
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 11
8.1.2 Data Returned in a CC&D Totals Response That Repeats for Every Fiscal Year
If the inquiry period spans fiscal years, the CC&D totals would repeat multiple times. For example, if the inquiry period is September 1, 2006 through October 25, 2007, there would be two sets of CC&D totals, one for 2006 and one for 2007.
8.2 Information Returned for a CC&D Update Inquiry
DEERS may send one of several response transfers to a CC&D Update.
If no errors occur in processing:
• CC&D Update Response (TXN_TYPE_CD = “A”) see Section 10.5 for format. This transfer is returned only if the update is successfully applied (return status code 0 and return code 00000 in the header).
If an error occurs:
• Inquiry Transfer Handling Error (TXN_TYPE_CD = “E”) if an error occurs in initial transfer handling or parsing (see Section 10.6 for format)
• System Error (TXN_TYPE_CD = “S”) if an error occurs in the DEERS system (e.g., DEERS_ID not found, database down) (see Section 10.6 for format)
• CC&D Update Warning / Error (TXN_TYPE_CD = “W”) if an error was detected in the Update application (e.g., locking error, newborn added but CC& D not applied) (see Section
10.5 for format)
Note that for System Errors (“S”) the overall format of the error transfer includes only the header and the Message Identification Section. The Inquiry Transfer Handling Error (“E”) is also described in Section 10.6, but it only includes the header without the Message Identification Section.
Note also that the CC&D Update Response (“A”) and the CC&D Update Warning / Error Response (“W”) are the same format described in Section 10.5. The Update Warning /Error Response may contain Error Codes in the Error Information Section and may not contain all the return information in the other sections. The content of the Update and Warning Error Response will depend on the Return Status Code and Return Code as described in Section 9.0.
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 12
9.0 Return Codes
DEERS uses a combination of Transaction Type Codes (TXN_TYP_CD), Transaction Return Status Codes (TX_RT_STAT_CD), and Transaction Return Codes (TX_RT_CD) to identify responses and describe error / warning conditions, if any. The Transaction Type Codes are defined as follows:
• Y – CCD Totals Response
• A – CCD Update Response
• W – Warning
• E – Error
• S – System Error
9.1 CC&D Totals Return Codes
The following return values are currently defined:
TXN
TYP
CD
TX RT
STAT
CD
TX RT
CD Description Contractor Response Y 0 00000 Successful totals response Y 0 00010 Totals not sent due to application of lock with totals already locked Check Lock section for contractor locking totals.
Y Any other codes
All codes
Report error with transaction type code, transaction return status code, and transaction return code to DEERS.
E 1 00100 Error reading input text Check input text format, fix and re-send.
E 1 00102 Invalid transaction type Check transaction type, fix and re-send.
E 1 00408 Incompatible TR versions of KB and application
Check TR version, fix and re-send.
E Any other codes
All codes
Report error with transaction type code, transaction return status code, and transaction return code to DEERS.
S All codes
All codes
Report error with transaction type code, transaction return status code, and transaction return code to DEERS.
W 4 00330 Invalid Lock Indicator Check Lock Indicator, fix and resubmit.
W All codes
Any other codes
Report error with transaction type code, transaction return status code, and transaction return code to DEERS.
DMDC Version 2.4 – November 3, 2010 13
9.2 CC&D Update Return Status and Return Codes by
Transaction Type
The following return values are currently defined:
TXN
TYP
CD
TX RT
STAT
CD
TX RT
CD Description Contractor Response A 0 00000 Successful update A Any other codes
All codes
Report error with transaction type code, transaction return status code, and transaction return code to DEERS.
E 1 00100 Error reading input text Check input text, format, fix and re-send.
E 1 00102 Invalid transaction type Check transaction type, fix and re-send.
E 1 00408 Incompatible TR versions of KB and application
Check TR version, fix and resend.
E Any other codes
All Codes
Report error with transaction type code, transaction return status code, and transaction return code to DEERS.
S All codes
All codes
Report error with transaction type code, transaction return status code, and transaction return code to DEERS.
W 4 00100 New Born Added, but no valid lock found All transfer sections should have data:
DEERS_BNFRY_ID is returned to use when lock can be applied.
Check Lock section and error codes in Error Information Section for details (see Section
9.3 for codes in 20000 series).
W 4 00330 Invalid Lock Indicator Check Lock Indicator, fix and resubmit.
W 4 00403 Attempt to re-add an existing New Born Only Header, Message ID information, and DEERS ID will be populated.
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 14
TXN
TYP
CD
TX RT
STAT
CD
TX RT
CD Description Contractor Response W 4 10000 Invalid data in transfer Sections on transfer that will be blank:
DEERS_ID, Person Identification Information, and Lock Return Sections with data:
Header, Message Identification and Error Information
Check error codes in Error Information Section for error details (see Section 9.3 for codes in 10000 series).
W 4 20000 Lock removal error All sections should have data
Check Lock section and error codes in Error Information Section for details (see Section
9.3 for codes in 20000 series).
W Any other codes
All codes
Only Header and Message information sections will have data.
Report error with transaction type code, transaction return status code, and transaction return code to DEERS.
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 15
9.3 CC&D Error Codes
These are the Error Codes in the Error Section that are referred to in Section 9.2 and will be set for some Return Codes as indicated.
Error Code Error Description Contractor Action/Notes 20001 Can't unlock a record that isn't currently locked Correct lock indicator and resend transaction
20002 Can't extend a record that isn't currently locked
Correct lock indicator and resend transaction
20003 Locked by a different contractor Resend transaction after successfully applying the lock
20004 CCD Update ID didn't match locked record
Correct field and resend transaction
20005 CCD Upd. ID,CNTC CD didn't match lock record
Correct field and resend transaction
10001 Invalid DEERS_BNFRY_ID Correct field and resend transaction 10002 Invalid NWBRN_ADDN_IND_CD Correct field and resend transaction 10003 Invalid PN_LST_NM Correct field and resend transaction 10004 Invalid PN_1ST_NM Correct field and resend transaction 10005 Invalid PN_BRTH_DT Correct field and resend transaction 10006 Invalid PN_SEX_CD Correct field and resend transaction 10007 Invalid CCD_LOCK_IND_CD Correct field and resend transaction 10008 Invalid CCD_DTL_UPD_IND_CD Correct field and resend transaction 10009 Invalid CCD_DTL_UPD_ID Correct field and resend transaction 10010 Invalid CCD_SPLT_CLM_ID Correct field and resend transaction 10011 Invalid HCDP_CNTC_CD Correct field and resend transaction 10012 Invalid CCD_DTL_TYP_CD Correct field and resend transaction 10013 Invalid CCD_DTL_TOT_APLD_CD Correct field and resend transaction 10014 Invalid HCDP_FY_ID Correct field and resend transaction 10015 Invalid CLM_SVC_PERD_BGN_DT Correct field and resend transaction 10016 Invalid CLM_SVC_PERD_END_DT Correct field and resend transaction 10017 Invalid FY_CCD_DTL_DT Correct field and resend transaction 10018 Invalid FY_DDCT_PMT_AM Correct field and resend transaction 10019 Invalid FY_POS_DDCT_PMT_AM Correct field and resend transaction 10020 Invalid FY_CCAP_PMT_AM Correct field and resend transaction 10021 Cat Cap Amount is out of range. Correct the amount and resend transaction 10022 Deductible Payment Amount is out of range.
Correct the amount and resend transaction
10023 Point of Service Deductible Payment Amount is out of range.
Correct the amount and resend transaction
DMDC Version 2.4 – November 3, 2010 16
10.0 Appendices: Transfer Record Layouts
Note: Character-defined attributes are left justified and space filled; numerical-defined attributes are right justified and zero filled. All characters are standard ASCII characters. A newline character (ASCII 0x0A) terminates each fixed-size transfer record sent. All times listed are Eastern Standard. Negative monies contain the negative sign in byte 1 and are zero filled (left to right) as necessary.
10.1 Appendix A: CC&D Totals Inquiry Transfer Record Layout
Section Name Level No. Attribute Name Size System Name Notes Usage* Header 1 Message Header 1.1 1 Application Identifier 4 APP_ID “0251” R 2 Transaction Type Code 1 TXN_TYP_CD “T” - Totals Inquiry R 3 Application Version
Identifier
2 APP_VRSN_ID “07” R
4 Transaction Online Calendar Date
8 TXN_ONL_DT Format “YYYYMMDD”. R
5 Transaction Online Time 6 TXN_ONL_TM Format “HHMMSS”. R 6 Transaction Return Status
Code
1 TXN_RT_STAT_CD “0” R
7 Transaction Return Code 5 TXN_RT_CD “00000” R 8 Submission Identifier 8 SUBM_ID 0 R 9 Run Identifier 8 RUN_ID 0 R 10 Security Identifier 8 SCRTY_ID Blank 11 Site Identifier 6 SITE_ID Static value to be provided by DMDC.
R
12 User Identifier 8 USER_ID 0 (Always “0” for Host-to- Host communication)
R
Length Subtotal 65 Message Identification Information
1.2 1 HCDP System Identifier 7 HCDP_SYS_ID Contractor populates and sends to DEERS, and DEERS returns as is.
(Can be used as trans-action ID by Contractor.)
O
Deleted: Static value to be provided by DMDC.
Deleted: Static value to be provided by DMDC.
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 17
2 Message Control Identifier 32 MSG_CTRL_ID Contractor populates and sends to DEERS, and DEERS returns as is.
(Can be used as trans-action ID by Contractor.)
O
Length Subtotal 39 DEERS ID 2 1 DEERS Family Identifier 9 DEERS_FAM_ID R 2 DEERS Beneficiary
Identifier 2 DEERS_BNFRY_ID If blank, returns family totals only.
S
Length Subtotal 11 Catastrophic Cap and Deductible Inquiry Dates
3 1 Inquiry Fiscal Year Catastrophic Cap and Deductible Begin Year Identifier
4 INQ_FY_CCD_BGN_ID Format “YYYY”. R
2 Inquiry Fiscal Year Catastrophic Cap and Deductible End Year Identifier
4 INQ_FY_CCD_END_ID Format “YYYY” Required when inquiring on multiple years.
S
Length Subtotal 8 Catastrophic Cap and Deductible Totals and Lock Inquiry Information
4 1 Catastrophic Cap and Deductible Lock Indicator Code
1 CCD_LOCK_IND_CD Required field.
N - No lock requested L - Lock requested E - Extend lock U - Unlock
R
2 Catastrophic Cap and Deductible Detail Update Identifier
17 CCD_DTL_UPD_ID Required if lock indicator code = L, E, U.
S
3 Catastrophic Cap and Deductible Lock Contractor Code
2 CCD_LOCK_CNTC_CD Required if lock indicator code = L, E, U.
S
Length Subtotal 20 Length Total 143
* R = Required field, O = Optional field, S = Situational field
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 18
10.2 Appendix B: CC&D Totals Response Transfer Record Layout
Section Name Level No. Attribute Name Size System Name Notes Header 1 Message Header 1.1 1 Application Identifier 4 APP_ID Returns same value set in inquiry header.
2 Transaction Type Code 1 TXN_TYP_CD “Y” - Totals Response 3 Application Version
Identifier 2 APP_VRSN_ID Returns same value set in inquiry header.
4 Transaction Online
Calendar Date 8 TXN_ONL_DT Format “YYYYMMDD”.
5 Transaction Online Time 6 TXN_ONL_TM Format “HHMMSS”.
6 Transaction Return Status
Code 1 TXN_RT_STAT_CD Set by application.
7 Transaction Return Code 5 TXN_RT_CD Set by application.
8 Submission Identifier 8 SUBM_ID Returns same value set in inquiry header.
9 Run Identifier 8 RUN_ID Returns same value set in update header.
10 Security Identifier 8 SCRTY_ID Blank 11 Site Identifier 6 SITE_ID Returns same value set in inquiry header.
12 User Identifier 8 USER_ID Returns same value set in inquiry header.
Length Subtotal 65 Message Identification Information
1.2 1 HCDP System Identifier 7 HCDP_SYS_ID Returns same value set in inquiry header.
2 Message Control Identifier 32 MSG_CTRL_ID Returns same value set in inquiry header.
Length Subtotal 39 DEERS ID 2 1 DEERS Family Identifier 9 DEERS_FAM_ID 2 DEERS Beneficiary
Identifier
2 DEERS_BNFRY_ID
Length Subtotal 11
Deleted: Static value to be provided by DMDC.
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 19
Catastrophic Cap and Deductible Accumulation Information
3 1 Transfer Section Quantity 3 XFER_SECT_QY The following occurrence section is repeatable. This value indicates the repetitions.
Format “$nn”, where nn is the number of fiscal years, based on inquiry dates. Minimum of 00, maximum of 99.
Length Subtotal 3 Catastrophic Cap and Deductible Accumulation Information Occurrence
3.1 1 Health Care Delivery Plan Fiscal Year Identifier
4 HCDP_FY_ID Format “YYYY”.
2 Family Fiscal Year Deductible Cumulative Amount
11 FAM_FY_DDCT_AM Zeros shown if DEERS shows no amounts.
3 Family Fiscal Year Point of Service Deductible Cumulative Amount
11 FAM_FY_POS_DDCT_AM Zeros shown if DEERS shows no amounts.
4 Family Fiscal Year Catastrophic Cap Cumulative Amount
11 FAM_FY_CCAP_AM Zeros shown if DEERS shows no amounts.
Length Subtotal 37 Catastrophic Cap and Deductible Accumulation Information
4 1 Transfer Section Quantity 3 XFER_SECT_QY The following occurrence section is repeatable. This value indicates the repetitions.
Format “$nn”, where nn is the number of fiscal years, based on inquiry dates. Minimum of 00, maximum of 99.
Length Subtotal 3 Catastrophic Cap and Deductible Accumulation Information Occurrence
4.1 1 Health Care Delivery Plan Fiscal Year Identifier
4 HCDP_FY_ID Format “YYYY”.
2 Individual Fiscal Year Deductible Payment Amount
11 INV_FY_DDCT_PMT_AM Zeros shown if DEERS shows no amounts.
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 20
3 Individual Fiscal Year Point of Service Deductible Payment Amount
11 INV_FY_POS_DDCT_PMT_AM Zeros shown if DEERS shows no amounts.
4 Individual Fiscal Year Catastrophic Cap Payment Amount
11 INV_FY_CCAP_PMT_AM Zeros shown if DEERS shows no amounts.
Length Subtotal 37 Catastrophic Cap and Deductible Totals Lock Information
5 1 Catastrophic Cap and Deductible Lock Return Code
1 CCD_LOCK_RT_CD Always returned.
2 Catastrophic Cap and Deductible Lock Contractor Code
2 CCD_LOCK_CNTC_CD Only populated if lock is currently in place.
3 Catastrophic Cap and Deductible Detail Update Identifier
17 CCD_DTL_UPD_ID Only populated if lock is currently in place.
4 Catastrophic Cap and Deductible Lock Calendar Date
8 CCD_LOCK_DT Only populated if lock is currently in place. Format is “YYYYMMDD”.
5 Catastrophic Cap and Deductible Lock Time
6 CCD_LOCK_TM Only populated if the lock is placed.
Format is “HHMMSS”.
Length Subtotal 34 Length Total Variable
DMDC Version 2.4 – November 3, 2010 21
10.3 Appendix C: CC&D Totals Inquiry Error/Warning Record Layout
Section Name Level No. Attribute Name Size System Name Notes Header 1 Message Header 1.1 1 Application Identifier 4 APP_ID Returns same value set in inquiry header.
2 Transaction Type Code 1 TXN_TYP_CD “E” - inquiry handling error
(header only) “S” - System Error (header and message control) “W” - Application error/warning (header and message control)
3 Application Version Identifier
2 APP_VRSN_ID Returns same value set in inquiry header.
4 Transaction Online Calendar Date
8 TXN_ONL_DT Format “YYYYMMDD”.
5 Transaction Online Time 6 TXN_ONL_TM Format “HHMMSS”.
6 Transaction Return
Status Code 1 TXN_RT_STAT_CD Set by application.
7 Transaction Return Code 5 TXN_RT_CD Set by application.
8 Submission Identifier 8 SUBM_ID Returns same value set in inquiry header.
9 Run Identifier 8 RUN_ID Returns same value set in update header.
10 Security Identifier 8 SCRTY_ID Blank 11 Site Identifier 6 SITE_ID Returns same value set in update header.
12 User Identifier 8 USER_ID Returns same value set in update header.
Length Subtotal 65
Message Identification Information
1.2 1 HCDP System Identifier 7 HCDP_SYS_ID Not included when TXN_TYP_CD is “E”.
2 Message Control Identifier
32 MSG_CTRL_ID Not included when TXN_TYP_CD is “E”.
Length Subtotal 39
Deleted: Static value to be provided by DMDC.
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 22
10.4 Appendix D: CC&D Update Transfer Record Layout
Section Name Level No. Attribute Name Size System Name Notes Usage* Message Header 1 1 Application Identifier 4 APP_ID “0274” R 2 Transaction Type Code 1 TXN_TYP_CD “U” - Update Inquiry R 3 Application Version
Identifier
2 APP_VRSN_ID “01” R
4 Transaction Online Calendar Date
8 TXN_ONL_DT Format “YYYYMMDD”. R
5 Transaction Online Time 6 TXN_ONL_TM Format “HHMMSS”. R 6 Transaction Return Status
Code
1 TXN_RT_STAT_CD “0” R
7 Transaction Return Code 5 TXN_RT_CD “00000” R 8 Submission Identifier 8 SUBM_ID 0 R 9 Run Identifier 8 RUN_ID 0 R 10 Security Identifier 8 SCRTY_ID Blank 11 Site Identifier 6 SITE_ID Static value and will be provided by DMDC.
R
12 User Identifier 8 USER_ID 0 (Always “0” for Host-to- Host communication)
R
Length Subtotal 65 Message Identification Information
1.2 1 HCDP System Identifier 7 HCDP_SYS_ID Contractor populates and sends to DEERS and DEERS returns as is (can be used as transaction ID by Contractor.
O
2 Message Control Identifier 32 MSG_CTRL_ID Contractor populates and sends to DEERS and DEERS returns as is (can be used as transaction ID by Contractor.
O
Length Subtotal 39 DEERS ID 2 1 DEERS Family Identifier 9 DEERS_FAM_ID Must provide the DEERS
Family ID, even for newborns.
R
Deleted: Set to 0.
Deleted: Static value and will be provided by DMDC.
Deleted: Static value to be provided by DMDC.
Deleted: “blank”
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 23
2 DEERS Beneficiary Identifier
2 DEERS_BNFRY_ID Must provide the DEERS BNFRY_ID. For newborns, enter “00”.
R
Length Subtotal 11 Newborn Addition Indicator Code
3 1 Newborn Addition Indicator Code
1 NWBRN_ADDN_IND_CD “Y” or “blank”. S
Length Subtotal 1 Newborn Information for Newborn Adds
4 1 Person Last Name 26 PN_LST_NM If newborn is “Y”. S
2 Person First Name 20 PN_1ST_NM If newborn is “Y”. S 3 Person Middle Name 20 PN_MID_NM O 4 Person Cadency Name 4 PN_CDNCY_NM O 5 Person Birth Calendar
Date 8 PN_BRTH_DT If newborn is “Y”. S
6 Person Sex Code 1 PN_SEX_CD If newborn is “Y”.
M - Male F - Female Z - Unknown
S
Length Subtotal 79 Update Indicators 5 1 Catastrophic Cap and
Deductible Lock Indicator Code
1 CCD_LOCK_IND_CD U - remove lock E - extend lock
R
2 Catastrophic Cap and Deductible Detail Update Indicator Code
1 CCD_DTL_UPD_IND_CD Y - detail included N - detail not included
R
Length Subtotal 2 Catastrophic Cap and Deductible Detail Identification Information
6 1 Catastrophic Cap and Deductible Detail Update Identifier
17 CCD_DTL_UPD_ID R
2 Catastrophic Cap and Deductible Detail Split Claim Identifier
3 CCD_SPLT_CLM_ID O
3 Health Care Delivery Program Contract Code
2 HCDP_CNTC_CD R
4 Catastrophic Cap and Deductible Detail Type Code
1 CCD_DTL_TYP_CD C - Claim D - Claim Adjustment S - Special Adjustment
R
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 24
5 Catastrophic Cap and Deductible Detail Totals Applied Type Code
1 CCD_DTL_TOT_APLD_CD Required.
B - Both
R
Length Subtotal 24 Catastrophic Cap and Deductible Claim Period Information
7 1 Health Care Delivery Program Fiscal Year Identifier
4 HCDP_FY_ID Format = “YYYY”. R
2 Claim Service Period Begin Calendar Date
8 CLM_SVC_PERD_BGN_DT Format = “YYYYMMDD”. R
3 Claim Service Period End Calendar Date
8 CLM_SVC_PERD_END_DT Format = “YYYYMMDD”. R
Length Subtotal 20 Catastrophic Cap and Deductible Update Information
8 1 Fiscal Year Catastrophic Cap and Deductible Detail Calendar Date
8 FY_CCD_DTL_DT Transaction Date Format
= “YYYYMMDD”.
R
2 Fiscal Year Deductible Payment Amount
11 FY_DDCT_PMT_AM R
3 Fiscal Year Point of Service Deductible Payment Amount
11 FY_POS_DDCT_PMT_AM R
4 Fiscal Year Catastrophic Cap Payment Amount
11 FY_CCAP_PMT_AM R
Length Subtotal 41 Length Total 282
* R = Required field, O = Optional field, S = Situational field
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 25
10.5 Appendix E: CC&D Update Response Transfer Record Layout
Section Name Level No. Attribute Name Size System Name Notes Message Header 1 1 Application Identifier 4 APP_ID Returns same value set in inquiry header.
2 Transaction Type Code 1 TXN_TYP_CD “A” - Update Response
“W” - Error/Warning response 3 Application Version
Identifier 2 APP_VRSN_ID Returns same value set in inquiry header.
4 Transaction Online
Calendar Date 8 TXN_ONL_DT Format “YYYYMMDD”.
5 Transaction Online Time 6 TXN_ONL_TM Format “HHMMSS”.
6 Transaction Return Status
Code 1 TXN_RT_STAT_CD Set by application.
7 Transaction Return Code 5 TXN_RT_CD Set by application.
8 Submission Identifier 8 SUBM_ID Returns same value set in update header.
9 Run Identifier 8 RUN_ID Returns same value set in update header.
10 Security Identifier 8 SCRTY_ID Blank 11 Site Identifier 6 SITE_ID Returns same value set in update header.
12 User Identifier 8 USER_ID Returns same value set in update header.
Length Subtotal 65 Message Identification Information
1.3.1 1 HCDP System Identifier 7 HCDP_SYS_ID Returns same value set in update header.
2 Message Control Identifier 32 MSG_CTRL_ID Returns same value set in update header.
Length Subtotal 39 DEERS ID 2 1 DEERS Family Identifier 9 DEERS_FAM_ID Always populated, regardless if for existing person or newborn add.
2 DEERS Beneficiary
Identifier 2 DEERS_BNFRY_ID Always populated, regardless if for existing person or newborn add.
Length Subtotal 11 Patient Identification 3 1 Patient Identifier 10 PTNT_ID Only populated for newborn adds.
Deleted: Static value to be provided by DMDC.
Deleted: Version 2.3
Deleted: Version 2.4
DMDC Version 2.4 – November 3, 2010 26
Length Subtotal 10 Person Identification Information
4 1 Person Identifier 9 PN_ID Only populated for newborn adds.
2 Person Identifier Type Code
1 PN_ID_TYP_CD Only populated for newborn adds.
Length Subtotal 10 Lock Return Information 5 1 Catastrophic Cap and
Deductible lock Return Code
1 CCD_LOCK_RT_CD E - Lock extend successful U - Unlock successful I - Invalid…
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 .