Exhibit_2_-_Technical_Specification_-Claims.pdf

DoD

Defense Manpower Data Center

Defense Enrollment Eligibility Reporting System/ Military Health System (DEERS/MHS)

Technical Specification for

Claims Coverage Eligibility

Version 2.7 March 24, 2011

Deleted: 6

Deleted: April 21

Deleted: August 2, 2010

Technical Specification for Claims Coverage Eligibility

DMDC iiVersion 2.7 – March 24, 2011

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 (Inquiry Period), modified wording for clarity.

In Section 7.1.4 (Lock Indicator), added Contractor Code to the info Contractors to send when placing a Lock on CCD Totals. Also removed two inapplicable bullets under the lock functionality.

In Section 6.0 (Communications), updated to add a sub-section for HTTP communication. Also rearranged Section

6.0 to incorporate the HTTP communication sub-section.

In Section 8.2, added a note about newborns and verification.

In Section 8.3, updated the description of Mailing Address information.

2.1.1 March 25, 2009 In Section 6.1.1 (Initialization), removed the “preamble” – item #s 5, 6, 7, 8.

In Section 10.1 (Inquiry Transfer Record Layout), added APP_VRSN_ID as “07”.

In Section 10.1, added value “2” to the

INQ_HCDP_TYP_CD.

2.2 April 6, 2009 In Section 8.2, added the description of EOC block.

In Section 10.0 (Appendix A), changed APP_VRSN_ID from “07” to “09”.

In Section 10.2 (HCC for Claims Response TR Layout), added EOC information and EOC information occurrence.

2.3 October 27, 2009 In Section 10.2 and 10.3, reworded Transfer Section Quantity (XFER_SECT_QY) fields and added minimums and maximums for clarity.

In Section 10.2, corrected the system name of

CCD_LOCK_RT_CD.

In Section 8.6.2, corrected the reference for Error Codes to Section 9.0.

In Section 8, added clarification on CC&D locking.

In Section 8, added more clarification on NDAA 1637.

In Section 8, added descriptions for Episode of Care ID & Description.

In Section 8, clarified OHI, OGP, PCM & NPI acronyms.

In Section 8, clarified Soft Match condition & response.

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

Deleted: March 24, 2011

DMDC iiiVersion 2.7 – March 24, 2011

In Section 8.1, clarified the IDs returned.

In Section 8.3, added full names of acronyms.

In Section 8.3, corrected the displaying of CCD totals when locked.

In Section 8.3, clarified PCM NPI.

In Section 9, changed title to reflect that the section documents more than just errors.

In Section 9, changed introduction wording to better introduce response code table.

In Section 9, resorted response table so that like transaction types were together and sorted by ascending return codes.

In Section 9, clarified P 00010 CC&D locked response.

In Section 9, clarified P 00310 Soft Match response.

In Section 9, added W 00200 as a separate entry in response table rather than in description of other responses.

In Section 10, clarified Transfer Section Quantity (XFER_SECT_QY) field descriptions.

In Section 9, removed unnecessary error codes E 00410 and E 00116.

In Section 5.0, added a paragraph describing the maximum number of connections a Contractor can have with DMDC systems.

In Section 6.1.2, clarified TCP reads.

2.4 November 20, 2009 In section 8.3, added that only current family members will be returned on family inquires.

2.5 March 12, 2010 In Section 7.1.3, changed inquiry date to allow up to 6 years in the past.

Updated Section 7.1.1 and added Section 7.1.1.1 in support of beneficiaries with ONE name.

2.6 April 21, 2010 Added Section 6.1.5, Response Time and Performance.

2.7 March 24, 2011 Updated Section 7.1.2 to add a subsection for DBN in support of the “SSN Reduction Initiative” related changes.

Deleted: August 2, 2010

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC ivVersion 2.7 – March 24, 2011

Contents

1.0 DOCUMENT PURPOSE 1

2.0 REFERENCED DOCUMENTS 1

3.0 HEALTH CARE COVERAGE FOR CLAIMS OVERVIEW 1

4.0 TECHNICAL OVERVIEW 2

5.0 NETWORK SECURITY AND ENCRYPTION 2

6.0 COMMUNICATIONS 4

6.1 TCP/IP COMMUNICATION 4

6.2 HTTP COMMUNICATION 7

7.0 INPUT 9

7.1 INFORMATION REQUIRED FOR A HEALTH CARE COVERAGE INQUIRY FOR CLAIMS 9

8.0 OUTPUT 13

8.1 PERSON IDENTIFICATION INFORMATION RETURNED IN THE HEALTH CARE COVERAGE

INQUIRY FOR CLAIMS 13

8.2 DATA RETURNED IN A COVERAGE INQUIRY THAT REPEATS FOR EVERY COVERAGE PLAN 14

8.3 DATA RETURNED IN A COVERAGE INQUIRY INDEPENDENTLY FROM THE COVERAGE PLAN

INFORMATION 15

8.4 HEALTH CARE COVERAGE COPAYMENT FACTOR 16

8.5 SPECIAL ENTITLEMENTS 16

8.6 RESPONSES TO A HEALTH CARE COVERAGE INQUIRY FOR CLAIMS 17

9.0 RESPONSE CODES 20

10.0 APPENDICES: TRANSFER RECORD LAYOUTS 22

10.1 APPENDIX A: INQUIRY TRANSFER RECORD LAYOUT 22

10.2 APPENDIX B: HEALTH CARE COVERAGE FOR CLAIMS RESPONSE TRANSFER RECORD

LAYOUT 26

10.3 APPENDIX C: PARTIAL MATCH RECORD LAYOUT 37

10.4 APPENDIX D: INQUIRY ERROR / WARNING RECORD LAYOUT 40

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 1 Version 2.7 – March 24, 2011

1.0 Document Purpose

This document defines the Claims Eligibility 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), and the TRICARE Dual Eligible Fiscal Intermediary Contractor (TDEFIC).

2.0 Referenced Documents

This Technical Specification references and/or contains information from the following documents:

• TRICARE Systems Manual (Business Rules are in Chapter 3.) – The document is online at the TRICARE web site: http://www.tricare.osd.mil/tricaremanuals/ts02.htm.

• Technical Specification for the Catastrophic Cap and Deductible Database

3.0 Health Care Coverage for Claims Overview

DEERS is the system of record for eligibility and enrollment information. The Contractor will query DEERS to determine eligibility and/or enrollment status for a given period (up to 6 years in the past from the current date or 180 days in the future) in the process of claims adjudication.

DEERS serves as the database of record for:

• Person Identification

• Eligibility

• Enrollment and PCM information

• Year-to-date totals for Catastrophic Cap and Deductible (CC&D) amounts

• Point of Service (POS) deductible amounts

• Other Government Programs (OGP) The Contractor must not override this data with information from other sources.

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 2 Version 2.7 – March 24, 2011

4.0 Technical Overview

DEERS is the system of record for eligibility and enrollment information. The Contractor will send health care coverage inquiries to DEERS via the DEERS Health Care Coverage Inquiry for Claims. DEERS will return the DEERS Health Care Coverage for Claims Response to the Contractor to acknowledge the inquiry 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 Health Care Coverage Inquiry transaction and sends it to DEERS over the Virtual Private Network as described in Section 5.0.

2. DEERS pulls data according to the request or rejects the transaction upon receiving the transaction.

3. DEERS creates the Health Care Coverage for Claims Response transaction, the Partial Match Response, or an error / warning response based on the processing result.

4. DEERS will return the Health Care Coverage for Claims Response transaction to the Contractor with the return status of “0” if there is no error and the person is found.

5. DEERS will return the Partial Match response if there is no error, but we find either multiple families or multiple persons for the information provided (ambiguous match), or we find the sponsor but the specific family member cannot be found.

6. DEERS will return the header section and the Message Identification information of the Health Care Coverage Inquiry transaction response to the Contractor if there is an error caused by either no person can be found (return status 1) or the inquiry itself has errors.

DMDC will add the return code in the header section of the message.

7. DEERS processes all Health Care Coverage transactions in real time.

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.

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 3 Version 2.7 – March 24, 2011

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 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.

Coverage Inquiry

Contractor

VPN VPN

DEERS

Database

DISN

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 4 Version 2.7 – March 24, 2011

6.0 Communications

6.1 TCP/IP Communication

The Contractor will operate a server that initiates and accepts TCP/IP socket connections on a fixed port number. The Contractor will provide DEERS with the IP address and port number for the server. The MHS will provide the Contractor with a list of IP addresses to connect to. For Contractor’s data transferred over the VPN, the server running on the Contractor’s system must accept connections from those IP addresses specified by MHS. The Contractor will split transactions over multiple IP addresses as specified by MHS. This is a synchronous interface in that the Contractor sends an inquiry on one thread and waits for the response for that inquiry.

The purpose of the following information is to provide an outline for the TCP/IP application level protocol used to communicate with the DEERS server programs.

At the implementation level, there are many options available to the programmer. DMDC does not intend for this information to define a specific programming style nor limit options for the programmer. It is very important to note that this outline provides the lowest level communication action and does not address such things as multiplexing with multiple connections, failover, lost connection recovery, and other system level design components.

TCP/IP communication is divided into four components: initialization, application data sending and receiving, termination, and error handling.

6.1.1 Initialization

DEERS defines initialization as the series of steps beginning with no connection and ending with the DEERS server prepared to accept application data. The steps are:

1. Invoke the TCP/IP interface to obtain a socket.

2. Perform the computation for the select bit mask.

3. Invoke the TCP/IP interface to obtain a connection.

4. Invoke the TCP/IP interface to turn off the Nagel algorithm via the set socket options. This step is not required, but it has the potential to reduce TCP/IP response time. This action may also increase traffic on the network so the Contractor must give care to this action.

5. At this point, a connection to the DEERS server is established and the server is ready to accept application data. This ends the initialization phase of the communications with

DEERS.

6.1.2 Application Data Sending and Receiving

Application data sending and receiving is the process of sending the application request to the DEERS server and receiving a response. In the following steps, the term program refers to the client program that sends the requests to DEERS and receives the response. The steps include:

1. Invoking the TCP/IP interface to write the application data message or transaction to the DEERS server. A six-byte field containing the length of the data message must precede the application data message. In other words, the outbound message must contain:

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 5 Version 2.7 – March 24, 2011

• Six bytes containing the length of the data message

• n bytes of data message The Contractor must check the return from the write operation to ensure the message is complete. DMDC recommends the write operation be in a loop controlled by the number of bytes the write operation writes and the actual number of bytes written.

While it is possible to write the first six bytes of length and then issue writes for the data message, this action will result in a slight increase in response time due the time required for TCP/IP to acknowledge the six-byte message.

2. Invoking the TCP/IP interface for a Read Select operation so that the program can detect when there is data available for reading. The Read Select operation will either indicate data is available for reading or a time out. The error handling section discusses time out actions.

3. Invoking the TCP/IP interface to read the data from the socket. This read must be for six bytes. The Contractor must check the first byte for an asterisk (“*”). If an asterisk exists, then read the three additional bytes to obtain the total length of the record. In other words, the lengths appear as follows:

• If the first six bytes are all numeric, i.e., no asterisk in first byte, then read for the length in the first six bytes, or

• If the first byte of the six bytes contain an asterisk, then read for an additional three bytes.

Then form the length by combining bytes two through six of the first read and the three bytes from the second read. This action gives the 8 byte length of the message to be read.

Once the length of the response message is determined, then the program must read the message for the determined length.

Control the TCP/IP Read with a loop to ensure the read of all bytes with a Read Select between each Read operation.

It is very important to take into account the number of bytes returned and the area in the program where the inbound message or record is stored. The program must overlay storage and ensure the correct alignment of the segments of the message in storage.

4. At this point, a message has been delivered to the DEERS server and a response message received or an error detected. The next actions depend on the type of connection assumed by the program and the connection assumed by the DEERS server.

6.1.3 Termination

DMDC defines termination as the series of steps to end the connection to the DEERS server. It is very important for the client program to work in concert with the DEERS server with respect to the type of connection established and used by the client. In DEERS, the connection can be continuous socket or non-continuous socket. A continuous socket mode of operation assumes that the client will continue to send and receive messages using the connection established in the initialization of the connection. This means that the DEERS server will not terminate the connection when we return a message and the client can continue to send and receive messages without establishing a new connection for each message. This is the preferred option for maximum performance and where the client is capable of sending and receiving multiple messages on the same connection.

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 6 Version 2.7 – March 24, 2011

The non-continuous connection means that the DEERS server will close the connection after sending the outbound message. Any subsequent messages will require the client to establish a new connection. In this mode, the client program must also close the connection to the DEERS server.

It is important to note that the client can operate in either mode with respect to closing the connection and establishing a new connection for every message. However, the DEERS server cannot switch modes of operation for a specific TCP/IP address and port. This means that the client program must be aware of the operation of the DEERS server if the client program desires to operate in a continuous socket mode.

The steps terminating the connection include:

1. Invoke the TCP/IP interface to shutdown the socket. Depending on the computing environment, shut down the socket for messages in both directions.

2. Invoke the TCP/IP interface to close the socket.

6.1.4 Error Handling

We define error handling as the series of steps to deal with any errors that might occur during the operation of the communications with the DEERS server. It is beyond the scope of this document to define all error conditions and the actions to take by the client in the event of an error. Client application designers must consider the actions taken and assumed in the event of an error. For example, if the read for the response times out on the select, the application designer must consider such things as the impact of no response as the client program will have no immediate knowledge of the success or failure of the transaction. Presentation of errors to the end user of the client application, retrying of the transaction, and failure of the DEERS server are a few examples of the design elements that the client application designer must consider. The following sections present guidelines and only guidelines for client application programming.

1. Check every interaction with the TCP/IP interface for success or failure. Check the return code from the interface and the TCP/IP error number after each invocation of the interface.

The only exception to this might be the shutdown and close actions.

2. You may consider time outs from the Read Select operation as errors. You must carefully consider the time out values based on expected transaction response time from the DEERS server.

3. The following table presents some error conditions and their implications. It is important to note that this table is NOT all-inclusive nor does it represent all possible situations where errors can occur. It is the application designer and programmer’s responsibility to detect the error, determine the cause of the error, and determine the actions to take.

Error Likely Cause TCP/IP Write failure The connection to the DEERS server has failed/dropped, the DEERS server has failed, or the connection was not established.

TCP/IP Read Select Time Out The DEERS server failed to respond during the Read Select time value. ***NOTE*** Extreme care must be taken in this event because the DEERS server may respond after the time-out value and the client application must be aware of this possibility.

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 7 Version 2.7 – March 24, 2011

During Initialization, READY message not received but Read did not fail.

The DEERS server configuration does not match the client configuration or the DEERS server did not recognize the preamble data. If USER ID and PASSWORD are required, this may indicate a security system rejection of the USER ID or PASSWORD.

Programming considerations:

1. As with any communications programming, the client program must be able to deal with such things as broken connections, timeouts, and other errors that can occur with the communications mechanisms.

2. Such things as timeout values, IP addresses and ports should be easily configurable so that the client application can adapt to changes without significant maintenance work. This applies to the test and production environments.

All communications with the DEERS environment must be request followed by a response. In other words, the client application sends a request to DEERS and must wait for a response or timeout. There is no option of request, request, and then response.

6.1.5 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.

6.2 HTTP Communication

6.2.1 Introduction

DMDC is implementing HyperText Transfer Protocol (HTTP) as the communication protocol to exchange messages. The Contractor will be required to transition to the new protocol on the request from DMDC. This section provides a description of how the Contractor will

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 8Version 2.7 – March 24, 2011 communicate with DEERS using HTTP, the network application protocol by which 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, the Contractor must accomplish the following to communicate with

DEERS:

• Connect to the DMDC Web server by 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 for 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). Adjust the number of connections needed during performance tuning based on the expected volume of transactions from the particular client site. The Contractor and DEERS will jointly develop performance tuning data and guidelines during the Contractor testing phase of the project.

6.2.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>

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.

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 9Version 2.7 – March 24, 2011

7.0 Input

The DEERS Health Care Coverage Inquiry for Claims supports business events associated with health care coverage and CC&D data for processing medical claims. The Contractor may use this inquiry for general customer service requests or for eligibility, referrals, and authorizations.

There are multiple options for inquiring about coverage information while including CC&D information. These various inquiry options allow the inquirer to receive coverage information and CC&D totals for the family. A coverage inquiry and lock of the CC&D accumulations is necessary prior to updating the CCDD on DEERS.

Contractors can resubmit claim inquiries rejected by DEERS.

7.1 Information Required for a Health Care Coverage Inquiry

for Claims

The information needed to perform this type of coverage inquiry includes:

• Person identification information

• Person or family transaction type

• Begin and end dates for the inquiry period (Note: The begin date may not be greater than six years in the past from the current date, and the end date may not be greater than 180 days in the future)

• The Catastrophic Cap & Deductible (CCD) Lock information See the Appendices in this document and the TSM Chapter 3, for specific business rules.

7.1.1 Person vs. Family Inquiry Required Data Attributes

The following table indicates the valid inquiry types and the data required for each.

Persons to return What information is available from the claim? Values to set Usage*

Return only a single sponsor/family member

(PNF_TXN_TYP_CD = P)

Sponsor information is provided

(INQ_PN_TYP_CD = S)

Inquiry Sponsor Info Section

SPN_INQ_PN_ID

SPN_INQ_PN_ID_TYP_CD

SPN_PN_LST_NM

SPN_PN_1ST_NM

SPN_PN_BRTH_DT

Inquiry Person Info Section†

INQ_PN_ID

INQ_PN_ID_TYP_CD

and/or

PN_LST_NM

PN_1ST_NM

PN_BRTH_DT

R

O O

S

NA

S

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 10Version 2.7 – March 24, 2011

Persons to return What information is available from the claim? Values to set Usage*

Return only a single person single sponsor/family member

(PNF_TXN_TYP_CD = P)

No sponsor information is provided‡

(INQ_PN_TYP_CD = P)

Inquiry Sponsor Info Section

Inquiry Person Info Section

INQ_PN_ID

INQ_PN_ID_TYP_CD

PN_LST_NM

PN_1ST_NM

PN_ BRTH_DT

O O O

Return the whole family

(PNF_TXN_TYP_CD = F)

Sponsor information provided

(INQ_PN_TYP_CD = S)

Inquiry Sponsor Info Section

SPN_INQ_PN_ID

SPN_INQ_PN_ID_TYP_CD

SPN_ PN_LST_NM

SPN_PN_1ST_NM

SPN_PN_ BRTH_DT

Inquiry Person Info Section

O

* R = Required field, O = Optional field, S = Situational field

† The Inquiry Person information section on a family member inquiry must either have the INQ_PN_ID and INQ_PN_ID_TYP_CD or if none is available then at least a PN_1ST_NM and PN_BRTH_DT. For beneficiaries with ONE name (refer to Section 7.1.1.1), providing only the PN_BRTH_DT will be acceptable when the INQ_PN_ID and INQ_PN_ID_TYP_CD are not available.

‡ The time required for this type of inquiry to DEERS is significantly longer than for a family member inquiry using a sponsor and the Contractor should infrequently use this inquiry only when NO sponsor PN_ID information is on the claim.

The HICN (H) is only valid in the Person inquiry section, not in the sponsor section and only on Person pulls. (Leave the sponsor section blank.)

7.1.1.1 Beneficiaries with ONE Name

For beneficiaries with only ONE name, the name is stored in DEERS as a Last Name, and the First Name is left blank. If only a PN_BRTH_DT is provided as a Person Identifier in the Inquiry Person information section, the match in DEERS will be based on the PN_BRTH_DT and a blank First Name.

7.1.2 Person Identification

Access a beneficiary’s information with the coverage inquiry using the identification information from the claim. DEERS performs the identification of the individual and returns the system identifiers (DEERS ID and Patient ID). Use the DEERS IDs for subsequent communications on this claim.

The inquiry person identification information to be sent is discussed below. The purpose of the Inquiry Person Identifier Type Code is to identify the type of data in the Inquiry Person Identifier. For example, if the content is a Social Security Number (SSN), then the Inquiry Person Identifier Type Code is an “S”. Every person on DEERS, whether sponsor or family member, has a Person Identifier and a Person Id Type Code. If no SSN or ITIN (individual Tax ID Number) is available then DEERS assigns a unique number.

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 11Version 2.7 – March 24, 2011

• DEERS assigns Temporary IDs, called TINs, (Person Id Type Code = “D”) to family members who have not yet provided an SSN.

• DEERS assigns Foreign IDs, called FINs, (Person Id Type Code “F”) to our foreign population who may never get an SSN (foreign military).

• DEERS assigns Service Personnel IDs (Person Id Type Code “P”) to deceased sponsor’s survivors. This ID is from a period before the SSN became the service ID.

The purpose of the Person Id Type Code on DEERS is to insure uniqueness of IDs. Currently the SSN does not collide with the number ranges of the TIN or the FIN or the Personnel ID.

However, the Social Security Administration makes no guarantees they will not move into the TIN/FIN number range in the future (see below). The ITIN from the IRS already collides with FINs.

The assigned Person Id Type Code (“D”, “F”, “P”) and the ITIN (“I”) is on the ID card.

However, the Person Id Type Code does not yet appear on the current claims form. Until it does, there are several ways to deal with this key value in the coverage inquiry:

For sponsors: (only “S”, “F”, “P”, and “I” are valid types)

• Most sponsors can be defaulted to “S” (if it is really a “P” type of ID it will still match if “S” is used)

• For any foreign national or foreign military activity check the first digit and if the first digit is a “9” (SSNs do not currently start with 9), then

• Use the “F” and if it matches then use the coverage data

• If the “F” does not match then change to “I”

• If the “I” does not match then deny claim

For family members: (only “S”, “F”, “I” and “D” are valid types) this is not so much of a problem as claims supply first name and birth date within the sponsor Person Id to find the family member. Even if the Contractor sends the Person Id, as long as the first name and date of birth are sent, there can still be a match even if the Contractor sends the Person Id Type Code with a wrong value. In addition, any data returned from DEERS inquiries or from enrollment notices will have these ID type codes along with the each person ID. These can be stored with the enrollment or used to get an exact match on the next inquiry if returned a multiple or an ambiguous match (in the form of a Partial match response).

However, if provided the Person Id on a family member then default the Person Id Type Code as follows

• If the ID starts with an 8 then make the PN_ID_TYP_CD = “D”

• If the first digit is a 9 (SSNs do not currently start with 9) then

• Use the “F” and if it matches then use the coverage data

• If the “F” does not match then change to “I”

• If not match then pull the whole family

• Otherwise default to an “S”

Deleted: April 21, 2010

DMDC 12Version 2.7 – March 24, 2011

In addition to the nine position IDs described above, the Contractor may consider using one more inquiry ID for coverage inquiries. For Medicare eligible persons where DEERS has communicated information back and forth with the Medicare system (CMS), there is a HICN (“H”) that is 11 positions. This is the unique value used by the Medicare system for beneficiaries.

This ID is only valid to use in the Person inquiry section for an inquiry of either a sponsor or family member.

7.1.2.1 DoD Benefit Number (DBN)

In support of the SSN Reduction Initiative, DMDC will enable the use of a new person identifier, a DoD Benefit Number (DBN), to inquire individuals’ eligibility for DoD Benefits. Once fully implemented, DBN is expected to replace SSN as a person identifier for DoD Benefit eligibility;

until then and in the meantime, DBN will be supported in addition to the person identifiers currently used and documented in Section 7.1.2.

• DBN is the external name for the existing DEERS Identifier (DEERS ID). DEERS ID is an 11-digit number created by DEERS for each family. The first 9 digits (aka DEERS Family Identifier) identify the family, and the last 2 digits (aka DEERS Beneficiary Identifier) identify the beneficiary.

• DBN will only be printed on the Cards of individuals with DoD Benefits; therefore, DBN provides a visible distinction between Cards that convey benefit and those that do not.

• DBN does not change over time.

7.1.2.1.1 Using DBN as Person Identifier

The Person Id Type Code (PN_ID_TYP_CD) for DBN is “B”.

• For Sponsors: The last 2 digits of the DBN are “00”.

• For dependents: The last 2 digits of the DBN are a value that ranges from “01” to “99”.

On the eligibility Inquiry (please refer to Appendix A), DBN should be used as follows:

• The Inquiry Person Identifier Type Code (INQ_PN_ID_TYP_CD) and/or the Sponsor Inquiry Person Identifier Type Code (SPN_INQ_PN_ID_TYP_CD) must be set to “B”.

• An 11-digit number must be provided as DBN.

• If the DEERS Family ID (first 9 digits) is less than 9 digits in length, it must be padded with zeros on the left, right justified. For example, a value of “123567” should be provided as “000123567”.

• If the DEERS Beneficiary ID (last 2 digits) is less than 2 digits in length, it must be padded with a zero on the left, right justified. For example, a value of “0” should be provided as “00”, and “1” should be provided as “01”.

DBN is a full-key in DEERS, so if used correctly, there should be no soft or partial matches in the Response.

Using DBN as Person Identifier on the Inquiry will have no impact on the data returned in the Response. In other words, the Response will not change.

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 13Version 2.7 – March 24, 2011

7.1.3 Inquiry Period

In addition to identifying the correct person or family, the inquiry must supply the inquiry period. The inquiry period may either be a single day or span multiple days.

Populate the inquiryPeriodBeginDate with a date up to 6 years in the past from the current date, and 180 days in the future from the current date. Populate the inquiryPeriodEndDate with a date that is greater than or equal to the inquiryPeriodBeginDate. The inquiryPeriodEndDate may be no greater than 180 days in the future. For example, if today’s date is January 1, 2009, you may inquire within a range of January 1, 2003 through June 30, 2009.

The Contractor’s system must edit the inquiry dates to be within the allowable range.

7.1.4 CC&D Lock Indicator

To ensure that the Catastrophic Cap and Deductible (CC&D) amounts do not change while the contractor is adjudicating a claim, DEERS provides a mechanism to lock the CC&D records associated with that claim. While locked, other contractors will not be able to update those CC&D amounts. The inquiry must indicate whether to place a lock on the CC&D information.

Use the lock inquiry 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 as well as the Contractor code. DEERS refers to this as the CC&D Detail ID. DEERS uses this identifier for locking and validation when receiving CC&D updates.

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 that initiated the lock is able to update totals, and the detail identifier used for locking must match the detail identifier used for updating.

The maximum period a Contractor can lock 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.

8.0 Output

8.1 Person Identification Information Returned in the Health

Care Coverage Inquiry for Claims The two primary identifiers used for subsequent system-to-system communication (i.e., electronic data interchange) are return on the response. These IDs, the DEERS ID and the Patient ID (also known as the EDI_PN), provide accuracy in further activity for the claim by the Contractor and DEERS.

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 14Version 2.7 – March 24, 2011

DEERS Identifier – DEERS returns for each person on the coverage response and consists of two parts:

• DEERS Family Identifier - a nine-digit number assigned by DEERS to be unique to each family

• DEERS Beneficiary Identifier - a two-digit number uniquely assigned to each member of the family. Unlike the Legacy DDS, this field has no inherent relationship meaning other than that the sponsor is always 00 The Contractor can view this number as a Health Care Coverage policy insurance number given by the DOD to all benefits eligible families. A person on DEERS may have more than one of these over time based on their changing family associations (e.g., child moving between sponsors in a joint service marriage, child becomes sponsor in own right). In the enrollment database on DEERS all information about enrollments and claims are stored under this number for each beneficiary.

• Family policies and CC&D totals are under the DEERS Family ID

• Enrollments, eligibility and individual totals are stored under the combination of the DEERS

Family ID and DEERS Beneficiary ID This identifier is to be used to trade enrollment information and to inquire and send CC&D totals once coverage has been determined. The Contractor can store this ID with the enrollment information to trade information such as fees, PCM assignments, and enrollment changes with DEERS. In addition, once obtained on a claims inquiry, use it on all further inquiries and updates for that claim. However, this identifier should not be used on any subsequent claims for that beneficiary, since it is based on the service period, it may no longer apply.

Patient Identifier - A ten-digit number uniquely assigned to each person. The Contractor can use it to store and transmit clinical information about a person as a patient. The Contractor can store and communicate clinic information to/from the MTFs and the Clinical Data Repository (CDR).

In addition, it would be most valuable for the Contractor to store in claims history for comparing current treatments to those on previous claims where the DEERS_ID may have been different due to family association changes over time.

8.2 Data Returned in a Coverage Inquiry That Repeats For

Every Coverage Plan

In response to a Health Care Coverage Inquiry for Claims, DEERS returns the specified coverage information in effect for the inquiry period. The following list shows the information DEERS returns for each coverage plan in effect during the inquiry period:

• Coverage plan information (assigned or enrolled)

• Coverage plan begin and end dates for inquiry period

• Sponsor branch of service and sponsor member category

• Family member relationship to the sponsor during coverage period

• Co-payment Factor (for all assigned and enrolled plans) and Special Co-payment factors applicable only to Extended Care Health Option (ECHO) programs

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 15Version 2.7 – March 24, 2011

DEERS creates a new Health Care Coverage Information section on the response with the associated dates (coverage plan begin and end) if the value of any of the following attributes changes during the inquiry period:

• Health Care Delivery Plan Coverage code

• Health Care Coverage Co-payment Factor code

• Health Care Coverage Special Co-payment Factor code (ECHO only)

• Health Care Coverage Service Branch Classification code

• Health Care Coverage Member Category code

• Health Care Coverage Member Relationship code

Note: For newborns returned in the response to a eligibility inquiry, a coverage code of “999” will be returned by DEERS up to 365 days after the Date of Birth, until the newborn is verified by a Verifying Officer (VO).

DEERS creates another new segment in this section if coverage of episode of care is applicable for the associated dates (coverage plan begin and end). NDAA 2008, Section 1637 provides for coverage of specific injuries incurred on Active Duty that are discovered in a sponsor’s Transitional Assistance Management Program (TAMP) period. The coverage is limited to 180 days, and may extend beyond the TAMP. It includes the following attributes:

• Episode of Care Code – Unique identifier for this episode of care

• Episode of Care Description Text – Description of the nature of the injury

8.3 Data Returned in a Coverage Inquiry Independently from

the Coverage Plan Information

The DEERS coverage response could include Primary Care Manager (PCM), Other Health Insurance (OHI), and Other Government Programs (OGP) information, Catastrophic Cap and Deductible (CC&D) totals (if requested), and lock information (if locked) independently from the health care coverage information.

• Sponsor Personnel Information: DEERS will return all current personnel segments, including dual eligible segments. The Contractor will use this data to update any enrollment information or to provide current contact reference information as required but should not necessarily be used for claim adjudication, as it represents current information only, not always information applicable at the time of the claims. For that information use information provided in the Health Care Coverage section itself and use Health Care Coverage Member Category Code (HCC_MBR_CAT_CD) and Health Care Coverage Service Code

(HCC_SVC_CD).

• Family Member Association information: Current family members (those with a person association end date after 1998 or do not have a person association end date) will be returned.

This is also for contact or enrollment maintenance. For relationships valid during the claims period, use the Health Care Coverage Member Relationship Code (HCC_MBR_REL_CD) in the Health Care Coverage section.

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 16Version 2.7 – March 24, 2011

• Mailing Address information: DEERS will return the mailing address in the eligibility response, if both the mailing address and residence address are present. If there is no mailing address, then DEERS will return the residence address in the response.

• Primary Care Manager (PCM) information: DEERS returns PCM information for some enrolled coverage plans. This information includes the Defense Medical Information System (DMIS) National Provider Identifier (NPI). This DMIS ID will always be a NPI Type 2 ID (Institutional Provider).

• Other Health Insurance (OHI): DEERS returns limited OHI information for the purpose of Coordination of Benefits (COB).

• Other Government Programs (OGP): DEERS provides complete OGP information in the response. OGPs include CHAMPVA and Medicare.

• CC&D totals: DEERS provides both family and individual CC&D totals in the coverage response. The DEERS response shows year-to-date CC&D totals as requested. Based on the inquiry dates requested, DEERS determines the appropriate year and returns the greater of the fiscal or enrollment year totals for the respective periods. If there are no CC&D totals accumulated for the inquiry period requested, DEERS would show a zero value.

IF the Contractor requests to lock CC&D totals:

• DEERS will lock the CC&D totals for the requesting Contractor and return CC&D totals if a Contractor does not hold a lock on the family.

• If a Contractor holds a lock on the family, DEERS will return CC&D totals, as well as the lock information indicating the Contractor who has locked the totals.

• If the inquiry period spans more than one year, the CC&D totals will repeat multiple times. For example, if the inquiry dates were September 1, 2008 through September 25, 2009, there would be two sets of CC&D totals, one for 2008 and one for 2009.

8.4 Health Care Coverage Copayment Factor

DEERS determines the Health Care Coverage Copayment Factor Code and returns it on a claims inquiry. The Contractor will use this factor code to determine the actual copayment for the claim.

Examples of copayment factors are:

• Pay Grade Corporal/Sergeant or Petty Officer Third Class and below rate

• Pay Grade Sergeant/Staff Sergeant or Petty Officer Second Class and above rate

• Retiree and Surviving family members of deceased active duty sponsors rate

• Foreign Military rate

8.5 Special Entitlements

The Special Entitlement Code—and dates, if applicable—provide information to support legislative initiatives. Examples are:

• Special entitlement for participation in Operation Joint Endeavor

• Special entitlement for participation in Operation Noble Eagle

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 17Version 2.7 – March 24, 2011

Effective dates will also be included in the response from DEERS. A person may have multiple special entitlements.

8.6 Responses to a Health Care Coverage Inquiry for Claims

DEERS may send one of three response transfer formats to a Health Care Coverage Inquiry for Claims.

IF no errors occur in processing, then the Transaction Type Codes (TXN_TYP_CD) in the response will include:

• Health Care Coverage (TXN_TYP_CD = “P”) if the beneficiary is found (see Section 10.2 for format)

• Partial Match (TXN_TYPE_CD = “F”) if the beneficiary or sponsor is either not found or ambiguously found (see Section 10.3 for format)

IF an error occurs:

• Inquiry Transfer Handling Error (TXN_TYPE_CD = “E”) if an error occurs in initial transfer handling of the input transfer record or parsing (see Section 10.4 for format). In this case, DEERS returns only the 65-byte header. DEERS does not return the Message Control Id section.

• System Error (TXN_TYPE_CD = “S”) if an error occurs in the DEERS system (e.g., database down) (see Section 10.4 for format). In this case, DEERS returns the 65-byte header along with the Message Control Id section.

• Application Warning or Error (TXN_TYPE_CD = “W”) if an error was detected in the Claims Health Care Coverage application (e.g., inquiry content incorrect, person not found etc.,) (see Section 10.4 for format). In this case, DEERS returns the 65-byte header along with the Message Control Id section.

For System and Application Errors, the overall format of the error transfer is the same and described in Section 10.4. The format includes both the header section and the message identification section. The Inquiry Transfer Handling Error transfer is the same format except the Message Identification Section is missing and DEERS returns only the header section.

8.6.1 Responses when no Errors or Warnings are Encountered

Based on Inquiry Person Type Code of “S” (individual family member inquiry with Sponsor and family member information provided)

Condition Response Contractor Action

1. Multiple sponsors matched Partial match transfer with multiple families

TXN_TYP_CD = “F”

Return Status 0 and Return Code 00000 in header section

Select correct sponsor, re-query DEERS using the selected sponsor’s SPN_PN_ID and

SPN_PN_ID_TYP_CD,

SPN_PN_LST_NM and SPN_PN_BRTH_DT and at least the PN_ID, PN_ID_TYP_CD of the family member selected.

Deleted: Version 2.6

Deleted: Version 2.7

Deleted: April 21, 2010

DMDC 18Version 2.7 – March 24, 2011

Condition Response Contractor Action

2. Sponsor found, family member not found Partial match transfer with one family

TXN_TYP_CD = “F”

Return Status 0 and Return Code 00000 in header section

Select correct family member, re-query DEERS using both the returned sponsor’s and family members PN_ID and

PN_ID_TYP_CD.

3. Sponsor found, multiple family members matched

Partial match transfer with one family

TXN_TYP_CD = “F”

Return Status 0 and Return Code 00000 in header section

Select correct family member, re-query DEERS using the originally sent sponsor data but now add PN_ID and PN_ID_TYP_CD returned to the new inquiry

4. Sponsor found, family member found

Health care coverage transfer

TXN_TYP_CD = “P”

Return Status 0 and Return Code 00000 in header section

Adjudicate claim based on response.

5. Family Member…