HL7 DPS Segment: Diagnosis and Procedure Code

The DPS (Diagnosis and Procedure Code) segment identifies diagnosis and procedure code combinations that impact coverage requirements or approval status in healthcare payer master files. When used in a master file notification message with MFI-1 set to MLCP (Medical Limited Coverage Process), DPS identifies codes in limited coverage; when MFI-1 is set to MACP (Medical Approved Coverage Process), DPS identifies codes that are approved. DPS carries effective date ranges and limitation types to express when coverage applies and any restrictions on the approval.

DPS is a detail segment introduced in HL7 v2.9 to support healthcare payers' ability to communicate coverage decisions, prior authorization lists, and procedure approval matrices to healthcare providers and billing systems. It forms part of the master file infrastructure alongside MFI (Master File Identification), MCP (Master File Coverage Policy), and other policy-related segments.

Purpose

The purpose of DPS is to express which diagnosis and procedure code combinations are approved, limited, or denied for coverage under a payer's medical policy. A single diagnosis code (DPS-1) may be paired with zero, one, or many procedure codes (DPS-2, which repeats), allowing payers to communicate nuanced policies such as "diagnosis X is approved only when combined with procedure Y," or "diagnosis X is approved with procedures Y and Z but not W." DPS also carries effective and expiration dates (DPS-3 and DPS-4) so that coverage policies can be time-bounded and retired, and DPS-5 (Type of Limitation) allows payers to specify the nature of any restriction (e.g., quantity limits, age restrictions, prior authorization required).

Because DPS is a detail segment, it supplements the master file header (MFI) and policy header (MCP) introduced earlier in the message. A payer system sends one or more DPS segments per diagnosis code under a given coverage policy, and downstream billing and clinical systems use these segments to look up whether a diagnosis-procedure combination is covered before submitting a claim.

Used in

DPS is a coverage-detail segment used in master file notification messages, primarily the MFN message with medical coverage policy trigger events. Within those messages, DPS repeats one or more times per diagnosis code that is subject to the coverage policy defined in the MFI and MCP headers. The message's MFI-1 field determines the semantics: when MLCP, DPS segments define limited coverage; when MACP, they define approved coverage. The payer and service provider identities established in MFI and MFE control whose coverage policy is being conveyed.

Field-by-field reference

Source: NIST HL7 v2.9 segment definition (https://usnistgov.github.io/v2plusDemo/segment-definition/DPS.html) for sequence, name, data type, cardinality, and vocabulary. Length is not published in the source (—); Required and Table # are filled from the HL7 v2.9 standard.

Seq	Name	Data Type	Length	Req	Repeat	Table #	Description
DPS-1	Diagnosis Code - MCP	cwe	—	R	—	0051	Diagnosis code assigned to this coverage policy; either identifier or text is required
DPS-2	Procedure Code	cwe	—	R	Y	0941	Procedure code(s) associated with this diagnosis; repeats for multiple procedures (CPT4, ASTM, ICD9, etc.)
DPS-3	Effective Date/Time	dtm	—	O	—	—	Date and time when this coverage policy becomes effective
DPS-4	Expiration Date/Time	dtm	—	O	—	—	Date and time when this coverage policy expires
DPS-5	Type of Limitation	cne	—	O	—	0940	Code indicating any limitation on the coverage (e.g., quantity limit, age restriction, prior auth required)

Most-used fields

DPS-1 (Diagnosis Code) is mandatory and identifies the clinical condition or diagnosis that the coverage policy applies to. DPS-2 (Procedure Code) is also mandatory but repeats, allowing a single diagnosis to be paired with multiple procedures; it is the second most-used field because payers commonly communicate "approved diagnosis-procedure pairs." DPS-3 and DPS-4 (Effective and Expiration Date/Time) are frequently populated to manage the temporal validity of coverage policies, especially when policies change seasonally or when prior policies are superseded. DPS-5 (Type of Limitation) is used when the coverage is not unrestricted approval — for example, to indicate prior authorization is required, or to specify quantity limits per year.

Version differences (v2.9 introduction)

The DPS segment was introduced in HL7 v2.9 as part of the expansion of master file infrastructure to support modern payer coverage communication. Prior HL7 versions (v2.5.1 through v2.8.2) did not include a dedicated segment for diagnosis-procedure coverage pairs; coverage policies were either absent from the HL7 standard or expressed via custom Z-segments. The DPS segment structure in v2.9 is stable as of the 2021-Jan release and remains the current definition.

Common mistakes

A frequent error is omitting DPS-2 (Procedure Code) or populating it with only a single procedure when multiple procedures are covered under the diagnosis; DPS-2 repeats specifically to allow multiple procedures. Another mistake is failing to populate DPS-3 and DPS-4 when policies are time-bounded; without expiration dates, receivers may apply an outdated policy indefinitely. Teams also confuse DPS-1 (diagnosis) with other diagnosis fields and place procedure codes in DPS-1 instead of DPS-2, breaking the intended diagnosis-first, procedures-second structure. Implementers sometimes omit DPS-5 (Type of Limitation) when coverage is conditional on prior authorization or quantity limits, forcing downstream systems to guess the restriction. Finally, a common oversight is not validating that DPS-1 and DPS-2 codes belong to the coding systems specified in the MCP segment, leading to mismatches between the policy header and the detail segment.

Examples

Minimal DPS (diagnosis with single approved procedure):

DPS|428.0^Congestive heart failure^ICD9|99213^Office visit - established patient^CPT4

Fully-populated DPS with multiple procedures, effective dates, and limitation:

DPS|428.0^Congestive heart failure^ICD9|99213^Office visit^CPT4~99214^Office visit - extended^CPT4~99215^Office visit - complex^CPT4|20260101140000|20261231235959|PA^Prior Authorization Required^0940

Annotated breakdown:

DPS|428.0^Congestive heart failure^ICD9|99213^Office visit^CPT4~99214^Office visit - extended^CPT4|20260101140000|20261231235959|PA^Prior Authorization Required^0940
    |                                   |                      |                                 |                  |                           |
    |                                   |                      |                                 |                  |                           +--> DPS-5 Type of Limitation (CNE)
    |                                   |                      |                                 |                  +--------------------------> DPS-4 Expiration Date/Time (DTM)
    |                                   |                      |                                 +-----------------------------------> DPS-3 Effective Date/Time (DTM)
    |                                   |                      +-----------------------------------> DPS-2 Procedure Code (CWE) — repeats
    +--------------------------------------------------------> DPS-1 Diagnosis Code (CWE)

In-context excerpt 1 — DPS in an MFN master file notification for medical approved coverage process (MACP):

MSH|^~&|PAYER|PAYER-MAIN|PROVIDER|CLINIC|20260701143000||MFN^M11^MFN_M11|MSG00151|P|2.9
MFI|MACP^Medical Approved Coverage Process^HL70175|||UPD|20260701143000
MFE|MAD|||POL-2026-CARDIO-001
MCP|POL-2026-CARDIO-001|ANTHEM|CARDIOLOGY POLICY 2026||||||||20260101|20261231
DPS|I10^I50.9^Unspecified systolic or diastolic heart failure^ICD10|99213^Office visit low complexity^CPT4~99214^Office visit moderate complexity^CPT4~99215^Office visit high complexity^CPT4|20260101|20261231|
DPS|I10^I50.1^Left ventricular systolic dysfunction^ICD10|93000^Electrocardiogram^CPT4~93005^ECG tracing^CPT4|20260101|20261231|PA^Prior Auth for interventional procedures^0940

In-context excerpt 2 — DPS in an MFN for medical limited coverage process (MLCP):

MSH|^~&|PAYER|PAYER-MAIN|PROVIDER|CLINIC|20260701150000||MFN^M11^MFN_M11|MSG00152|P|2.9
MFI|MLCP^Medical Limited Coverage Process^HL70175|||UPD|20260701150000
MFE|MAD|||POL-2026-LIMITED-001
MCP|POL-2026-LIMITED-001|BLUECROSS|LIMITED COVERAGE POLICY 2026||||||||20260101|20261231
DPS|I10^R07.9^Chest pain, unspecified^ICD10|99213^Office visit established^CPT4|20260101|20261231|QL^Quantity Limit - 4 visits per year^0940
DPS|I10^M79.3^Panniculitis, unspecified^ICD10|97110^Therapeutic exercises^CPT4|20260101|20261231|

FHIR mapping

There is no segment-level ConceptMap published in the v2-to-FHIR Implementation Guide for DPS, so the target is "Not mapped at the segment level." Conceptually, DPS maps to the FHIR Coverage resource: DPS-1 (Diagnosis Code) and DPS-2 (Procedure Code) align with Coverage.class, Coverage.extension (coverage conditions), or Coverage.item elements; DPS-3 and DPS-4 (Effective and Expiration Date/Time) map to Coverage.period; and DPS-5 (Type of Limitation) informs Coverage.extension for specific limitations. Because no normalized mapping is standardized, any DPS-to-Coverage transform must be defined locally and verified per interface.

Engine considerations

DPS is a repeating detail segment within a master file notification, so an interface engine must group all DPS occurrences under the policy header (MCP) established in the message. Engines should validate that DPS-1 is always present and contains a valid diagnosis code; DPS-2 (Procedure Code) is also required and repeats, so engines must handle the repetition delimiter (~) correctly to separate multiple procedures. The CWE data type in DPS-1 and DPS-2 requires component parsing to extract identifier, text, and coding system; engines should normalize coding system values against the HL7 tables 0051 (Diagnosis Code) and 0941 (Procedure Code) to ensure consistency. Date-based fields DPS-3 and DPS-4 use the DTM type and may be partial dates (e.g., just year-month); engines should handle partial timestamp granularity gracefully. The CNE type in DPS-5 requires vocabulary lookup against table 0940 (Limitation Type Codes) to interpret the limitation semantically.

How Vorro parses and produces DPS

When Vorro parses DPS, each occurrence is decomposed into a normalized coverage rule record linked to the master file policy established in the preceding MFI and MCP segments. DPS-1 (Diagnosis Code) is parsed into its CWE components so that diagnosis identifier, text, and coding system are stored separately. DPS-2 (Procedure Code) is expanded into an array of CWE components, one per procedure, so that each diagnosis-procedure pair is represented explicitly. Date fields DPS-3 and DPS-4 are parsed into discrete timestamps for policy period queries and temporal validity checking.

When Vorro produces DPS, it emits one segment per diagnosis code on the source coverage policy, validates that both DPS-1 and DPS-2 are present, and handles DPS-2 repetition (using the ~ component delimiter) to emit all approved or limited procedures. Diagnosis and procedure codes are reassembled into CWE format with proper component delimiters and coding system identifiers. Effective and expiration dates are formatted as complete DTM timestamps, and limitation type is reassembled into CNE format with coding system.

Sources

← Back to HL7 v2 Guide