USCDI v3 Insurance Script Requirements

[Matt Szczepankiewicz]

Hi all,

The USCDI v3 test data for Alice Newman and Rebecca Larson contains a few things that seem a little inaccurate:

In CDA-20764, HL7 agreed that the Source of Payment Typology codes should be the primary code for Coverage Type, rather than the translation, to align with FHIR. Fortunately, the previous binding here was only a SHOULD:

SHALL contain exactly one [1..1] code, which SHOULD be selected from ValueSet Health Insurance Type 2.16.840.1.113883.3.88.12.3221.5.2 DYNAMIC (CONF:1198-8903).

• This code SHALL contain at least one [1..*] translation, which SHOULD be selected from ValueSet Payer  2.16.840.1.114222.4.11.3591 (CONF:1198-32852).

Which makes it pretty easy for implementers to pre-apply this errata if they so choose. Therefore, it seems like it would be better for the test data to allow the code and translation in either order, in order to accommodate this errata putting them a little up in the air.

The second issue is with the Group Identifier and Payer Identifier elements:

The Companion Guide offers no specific guidance on what type of identifier should be used for the Group Identifier (merely that it needs to be "a unique identifier for the policy or program providing the coverage"), and for the Payer Identifier, it says:

"The root is a unique identifier to an openly available assigning authority, such as National Association of Insurance Commissioners (NAIC) (2.16.840.1.113883.6.300), and the extension identifiers the payer within that authority."

So the Companion Guide leaves a lot up to implementers to decide how to support these, and it's unlikely that different systems will all be guaranteed to support any one specific format, such as the one shown above (which uses an OID reserved for test data)--though in the case of payer identifiers, NAIC codes would likely be a better starting point since the Companion Guide does specifically cite them as an example. Can the test scripts be updated to clarify that point?

Cheers,

Matt

[Kim Poletti]

Hi - Thanks for reaching out. This has been logged for review and a member of the team will reach out in the near future.

[Matt Szczepankiewicz]

Hi there,

Have there been any updates on this? Just want to make sure it's sorted out before it creates any confusion for USCDI v3 certification.

Thanks,

Matt

[Kim Poletti]

Hi Matt,

Apologies for the delay in responding. We will have a response in the next day or two.

Thank you for your patience.

Kim

[br...@waveoneassociates.com]

Hi Matt!

Did https://jira.hl7.org/browse/CDA-20764 ever get considered by Structured Documents as a 'patch' to the companion guide?

[Matt Szczepankiewicz]

Hey Brett! It says SDWG voted on it in October, so it seems that way? Unless you mean something more specific.

[br...@waveoneassociates.com]

Hi, Matt!

HL7 approved for the 'new' release, but didn't approve a 'patch' -- but with with you on SD this morning, they approved! (https://jira.hl7.org/browse/CDA-20764).

This is green light for ONC/ETT team to adopt.

Best

Brett 

[Matt Szczepankiewicz]

Just to be clear, I think approving the patch for CDA-20764 definitely covers the first half of my original question, but how do we feel about the second? That is, the Companion Guide reads (to me) as saying that implementers can choose to identify groups and payers more or less however they think is best (with NAIC as a suggestion for payers). So seeing the test script require vendors to send a specific group and specific payer id with an OID reserved for test data feels worrisome to me; it seems more like any sort of id ought to work here as long as the ids are unique and so on.

What do you think about that bit?

- Matt

[br...@waveoneassociates.com]

Hi, Matt,

This is a test data decision -- I think suggesting NAIC is ok, but Dragon/ONC will have to chime in on flexibility with your test lab.

Best

Brett 

[nagesh.bashyam (Dragon)]

Matt, 

Thanks for the input.

For #1 : we will allow the use of either OID , will make the necessary updates in the March Release.

For #2 : We can update the test data to use the NAIC Root for the Payer Identifier.

               For the Group Identifier, if we allow the flexibility to use any ROOT value and stick to validating the extension, will that work ?

Thanks

Dragon

[Matt Szczepankiewicz]

Yes, that will work for us! Thanks for the update.

Cheers,

Matt

[Braeden Rai]

Pinging this, we uploaded our document with insurance data, and the message validator said that we did not send coverage type. That isn't true, it was just sent as a translation code, which the validator doesn't seem to be checking. Has issue 1 on this post been addressed/will it be addressed soon?

Thanks,

Braeden

[Braeden Rai]

Checking in again, are there any updates on when this fix will make it to the validator?

[Braeden Rai]

Hi again, do you have any updates on when the validator will be updated?

Thanks,

Braeden

[Braeden Rai]

Hi,

After the most recent release of the ETT, we started seeing the error pasted below for Ambulatory Sample Patient 1, Alice Newman.

 In the attached document, we should be sending coverage type the way Matt and Dragon mentioned above, where either OID could be sent as the primary code and the other as the translation. Should this still be the case? We didn't see this error when we checked our documents a few weeks ago, and it seems to have reappeared.

Also, it's possible this error may occur on other patients, but the validator currently isn't working so I wasn't able to check.

Error - 

1.      The scenario requires data related to patient's coverage policy for type PR , but the submitted C-CDA does not contain the Policy Activity entry data.

[Braeden Rai]

Hi, are there any updates on this?

[Braeden Rai]

Hi,

We are still seeing this error, which was fixed for a time before reappearing back in the validator. Can you confirm if this is a validator bug or an issue with our documents?

[Braeden Rai]

Hi, checking in again on this, can you let us know if this is being investigates?

[Kim Poletti]

Hello,

Yes, this is in the queue to be resolved. We will update you once it is fixed.

Thank you,

Kim

[sridevi Brijesh]

Similarly the Relationship to Subscriber valueset mentioned for FHIR and CCDA are different too. Can we correct this and follow one valueset for Relationship to subscriber for both FHIR and CCDA.

FHIR subscriber-relationship :  Valueset-subscriber-relationship - FHIR v4.0.1

CCDA CoverageRoleType : Value Set Authority Center

FHIR subscriber-relationship

CCDA CoverageRoleType

[Miles Williams]

Hello, are there any updates for this issue?

[Braeden Rai]

Hi, are there any updates on if this will be addressed?

[Michelle Knighton]

We have the same question. Do we know when an answer will be provided?

[Braeden Rai]

Hi, do you have any updates on when the fix for this will be released?

[NGO Solutions]

Subject: Recommendation on Aligning CCDA Insurance Type with ANSI Claim Standards and Recommendation on how to workaround test data conflict

Hello,

I believe this thread is the most appropriate context for the following observation, but I’m happy to start a new discussion if preferred.

The C-CDA value set for Insurance Type (2.16.840.1.113883.3.88.12.3221.5.2) appears to conflate two distinct ANSI standards:

1. ANSI X12 837 – SBR05 (Insurance Type Code): Required only when Medicare is Secondary (e.g., value “12” = Medicare Secondary Working Aged Beneficiary or Spouse with Employer Group Health Plan).

2. ANSI X12 837 – SBR09 (Claim Filing Indicator Code): Required on all claims (e.g., value “MB” = Medicare, “MC” = Medicaid, “12” = PPO).

These two fields have overlapping values with incompatible semantic intent. For example, “12” represents a specific Medicare secondary condition in SBR05 but a PPO in SBR09.

Due to this semantic conflict, I recommend HL7 revise the C-CDA Insurance Type guidance to align strictly with the Claim Filing Indicator (SBR09), which is the more widely adopted and consistently implemented value set in health information exchange and billing workflows.

Additionally, for implementers preparing for ONC SVAP 170.315(b)(1) certification:

• The test data currently expects a specific code from the mixed HL7-defined set (e.g., "PR" for Preferred Provider Organization).

• The IG only binds this value set with a SHOULD strength (CONF:1198-8903), allowing implementers discretion.

• Given that, I recommend vendors coordinate with their ATL to substitute values from the ANSI Claim Filing Indicator set (e.g., using “12” for PPO), even though these may currently trigger validator errors.

This approach aligns with ONC’s SVAP test data policy, which explicitly permits data modification in collaboration with ATLs under defined procedures.

If others in the group have concerns with this interpretation or a different perspective, I welcome feedback. I’m also happy to join a call to further clarify or collaborate on solutions.

Best regards,
Justin Berg

Open image-20250519-180559.png

[NGO Solutions]

Subject: Recommendation on Aligning C-CDA Coverage Role Type with ANSI Subscriber Relationship Codes and Proposed Test Data Coordination

Hello,

Following up on recent discussions around Insurance Type semantics, I would like to raise a parallel consideration concerning the Coverage Role Type value set (OID: 2.16.840.1.113883.1.11.18877), used within the participantRole of the Coverage Activity in C-CDA documents.

This HL7-defined value set currently includes HL7 RoleCode descendants such as SELF, FAMDEP, SPON, STUD, FSTUD, and HANDIC, and is used to convey the relationship of the covered party to the subscriber.

However, these codes do not directly align with the X12 Subscriber Relationship Codes used in ANSI 837 transactions, nor with the simplified relationship codes employed in FHIR Coverage (e.g., self, spouse, child, other). This divergence can introduce mapping friction for vendors supporting both clinical and billing use cases, especially when aiming for consistency across C-CDA, FHIR, and EDI standards.

The C-CDA Companion Guide (June 2023, Table 404, page 718) confirms that this value set is bound with a SHOULD conformance (CONF:1198-16078), allowing some discretion:

"This code SHOULD contain zero or one [0..1] @code, which SHOULD be selected from ValueSet Coverage Role Type Value Set urn:oid:2.16.840.1.113883.1.11.18877 (CONF:1198-16078)."

Recommendation 

To support alignment with FHIR and ANSI standards, and to streamline semantic interoperability, I recommend that implementers coordinate with their ACB to substitute values from the ANSI Subscriber Relationship value set, using clear mappings (e.g., self, spouse, child, other) where applicable.

This approach is consistent with ONC’s SVAP test data modification policy and leverages the SHOULD-strength binding to avoid false positives in validator tools, provided ATLs document and approve the test data deviations.

This alignment will reduce cross-paradigm inconsistency and prepare systems for more coherent C-CDA to FHIR transitions.

As always, I welcome feedback from others in the group and am available to collaborate on a harmonized strategy moving forward.

Note: The recommendation seems to be in alignment with https://jira.hl7.org/browse/CDA-20757, which references us to > https://confluence.hl7.org/spaces/SD/pages/134942708/Health+Insurance+Information

Which appears to be last updated in October 2022

• Relationship to Subsriber
  • Will work to CREATE a CDA VALUE SET that Matches US Core - https://hl7.org/fhir/valueset-subscriber-relationship.html
    • In Trifolia -
      • How do we directly reuse a FHIR value set?
      • Do we manually recreate in Trifolia? <GD: Brett Marquard  Manually create and put link in the value set text area and as link in the "description" field above the binding constraint/>
      • If we manually create in Trifolia, what is process for getting into VSAC?

-- DO NOT USE --> Coverage Role Type Value Set 2.16.840.1.113883.1.11.18877 
US Core is USING: http://hl7.org/fhir/R4/valueset-subscriber-relationship.html

Best regards,
Justin Berg

[br...@waveoneassociates.com]

Hi,

These coverage issues have been tricky!!

HL7 discussed and approved this tracker for Coverage Type: https://jira.hl7.org/browse/CDA-20764

On the relationship piece, I am a little surprised C-CDA isn't sharing with US Core. If you have access to HL7 JIRA, please log a tracker: CREATE a CDA VALUE SET that Matches US Core - https://hl7.org/fhir/valueset-subscriber-relationship.html

If you don't, I can for you.

Best

Brett 

[Miles Williams]

Hello, pinging again on the validator fix question. 

[Miles Williams]

Pinging again, any updates on the validator fix?

[Arslan Iqbal]

For our SITE/ETT team's internal reference only: SITE-3848

-SITE/ETT team

[Miles Williams]

Any update to this fix?

[Arslan Iqbal]

We're continuing to work on this and will share an update as soon as possible. Thanks for your patience.

-SITE/ETT team

[Miles Williams]

Thanks, any update yet?

[Miles Williams]

Pinging, any update?

[Miles Williams]

Hello, any update on this one?

[Miles Williams]

We have reviewed the 7/29 update, thanks for making these changes! 

One clarifying question on the Payer Identifier root: Does this mean that  2.16.840.1.113883.6.300 is enforced as a root? Our understanding of the specs was that that root is an option, but it's 'openly available': 

We're thinking the scripts should clarify the open-ended nature of the payer identifier root, like the comment for group identifier now does.