Clarification on Test Data Sheets Required/Optional Data and CCDA Standards SHALL/SHOULD Conformance Statements

[Joe Herdliska]

Good afternoon. I’m looking for some clarification on the Required/Optional Test Data when compared to the SHALLs/SHOULDs conformance in the CCDA specifications.  Specifically, I’m trying to understand what is required in CCDA documents to be compliant with criteria such as 170.315(b)(1) when the CCDA standards and the Test Data sheets are not aligned on what is required.

Not having required Test Data in the CCDA document, as specified in the scenario files (e.g. 170.315_b1_toc_amb_svap_uscdiv3_sample1_v1.pdf), results in a CCDA validation error on the Edge Testing Tool for that criterion. This is seen, in my understanding, as non-compliance to the 170.315(b)(1) criteria.

There are some required data elements in the Test Data, required being indicated by the absence of [ ], where the CCDA standard lists that data as a SHOULD (specific examples in question for clarity are below). My understanding of the CCDA Conformance Statements is that a SHALL indicates a requirement and a SHOULD conformance statements indicate a best practice or recommendation, and not a requirement. Is the required Test Data, required being indicated by the absence of [ ], meant to supersede the CCDA standards conformance statements in such cases? Should the data in the Test Data be marked with the optional indicator of [ ] in these cases? I’m trying to understand what is required in CCDA documents to be compliant with criteria such as 170.315(b)(1) when the CCDA standards and the Test Data sheets are not aligned on what is required.

Thank you for your time and consideration, and any input or clarity you may be able to provide on this. It is greatly appreciated and thank you for all that you do in helping drive standardized interoperability.

 

Example data to help clarify the question and request for clarity.

Encounter Type Code

In 170.315_b1_toc_amb_svap_uscdiv3_sample1_v1.pdf, Encounter Type has CPT Code = 99202 as required, required being indicated by the absence of [ ]. However, in the CCDA standard, CONF:1198-8714 identifies the EncounterTypeCode Valueset  urn:oid:2.16.840.1.113883.3.88.12.80.32 as a SHOULD

SHALL contain exactly one [1..1] code, which SHOULD be selected from ValueSet EncounterTypeCode urn:oid:2.16.840.1.113883.3.88.12.80.32 DYNAMIC (CONF:1198-8714).

In this case, the CPT Code of 99202 is required in the Test Data but the CCDA standard conformance statement for the EncounterTypeCode Valueset containing CPT codes is a SHOULD. Additionally, USCDI v3 does not list an applicable vocabulary standard for the Encounter Type data element, such that CPT is not the required vocabulary/code per USCDI v3. Which rule is correct for compliance with 170.315(b)(1)?

Medication – Dispense Data

In 170.315_b1_toc_amb_svap_uscdiv3_sample1_v1.pdf, Medication Dispense Data has Repeat Number = 2 and Quantity = 6 as required, required being indicated by the absence of [ ]. However, in the CCDA standard, CONF:4537-7457 and CONF:4537-7458 identifies repeatNumber and quantity as a SHOULD.

SHOULD contain zero or one [0..1] repeatNumber (CONF:4537-7457).

SHOULD contain zero or one [0..1] quantity (CONF:4537-7458).

In this case, the repeatNumber and quantity are required in the Test Data but the CCDA standard conformance statement is a SHOULD. Which rule is correct for compliance with 170.315(b)(1)?

Thank you very much for any clarification or input you may have.

 

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

[Joe Herdliska]

Good morning, Kim.  Have you had any luck on getting clarification regarding the original post?  Thanks! Any input the team may have is appreciated.

[Joe Herdliska]

Good morning. Have you had a chance to look into this?  Please let me know if you need additional information for clarification. I appreciate any insights you may have on this to help ensure our products comply with what is required in the CCDA standards. Thank you very much.

[Amir Ahmed]

Good morning, any feedback on this?

[Kim Poletti]

Hello,

Our team is still looking into this and will respond when they have an answer.

Thank you,

Kim

[Michelle Knighton]

We have the same concerns. There are a few instances within the test data where the test data implies either a standard that is not specified by USCDIv3 (e.g. Care Team Member Role) or a required data element that is not in USCDIv3 and is labeled as SHOULD in the CCDA specifications (e.g. RepeatNumber and Quantity). It is critical that the test data accurately reflect only the minimum required for certification and not impose requirements where none exist.

Michelle

[Arslan Iqbal]

SITE/ETT team's internal reference is SITE-4484

[Michelle Knighton]

We are unable to access that internal reference. Can you please answer our questions directly within this chat?

Thank you,

Michelle

[Kim Poletti]

Hello Michelle,

This is just for SITE internal use. Your question will be answered here once the team has completed their investigation.

Thanks,

Kim

[Joe Herdliska]

Good morning. I'm following up to see if there are any updates regarding this issue.  Do you happen to have a timeline for when guidance may be available? It remains unclear if we need to align with the test data (which, at times, require additional/different data than the conformance statements specify in the CCDA IG/CG), or if the test data will be updated. We appreciate any guidance or insight you may be able to provide.  Thank you for all you do.

[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

[nagesh.bashyam (Dragon)]

Hello

Yes, whenever the test data does not have a [], it is meant to supercede the C-CDA requirement. This is primarily to support USCDI requirements. In case you disagree on any specific data element that should not be superceded, by the test data, please craete a thread/ticket with the list of datalements and we can examine them on a case by case basis.

[Donkiss Boss]

Licensed Pharmaceuticals And Psychedelics Online Store
Buy the best Pharmaceuticals And Psychedelics products in our website with safe and guaranteed shipping and delivery Worldwide
Check out our website below if interested in our products.
https://shorturl.at/BvDVf
https://shorturl.at/ITBJW
https://shorturl.at/wCGS4
https://shorturl.at/RnP0b
https://shorturl.at/GTr8Q

[Michelle Knighton]

Dragon, here are the specific examples from Alice Newman's data:

Care Team Member Role - no standard specified in USCDIv3, SNOMED is listed as a MAY in CCDA, but a standard is listed in the test data

RepeatNumber (for Dispense Data) - Not in USCDIv3, listed as SHOULD in CCDA, but appears as required in the test data

Quantity (for Dispense Data) - Not in USCDIv3, listed as SHOULD in CCDA, but appears as required in the test data

Can you speak to these examples?

Thanks,

Michelle

[Brett Marquard]

Hi,

What terminology standard are you using or Care Member Role?

For Dispense Data the CDA RepeatNumber + Quantity are used to meet requirement of USCDI Fill Status. HL7 did it's best to communicate theses mappings in the 6.2.10 Medication table, and text underneath (6.2.10.4).

[nagesh.bashyam (Dragon)]

Thanks Brett.

Encounter Type is a data element in USCDIv3, hence it is required and it is associated with the Terminology requirements as part of US Core 6.1.0 with an extensible binding. 

The CCDA test data is trying to keep it in sync and hence we are enforcing the type as mandatory with terminology that is mapped already in US Core.

https://hl7.org/fhir/us/core/STU6.1/ValueSet-us-core-encounter-type.html 

For Fill Status, like Brett said we need to have the repeat number and the quantity.

For Care Team Member Role - it is required by USCDIv3 and we are using the binding from US Core to be in-snyc, again it is an extensible binding. 

https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1099.30/expansion 

Hopefully, this explains the data elements that are part of the thread. If there are any other ones, please open a new thread.

Thanks

Dragon 

[Michelle Knighton]

That is all perfectly reasonable, but unfortunately it is enforcing US Core/FHIR requirements onto CCDA requirements. In certification, if an EHR developer is only certifying to CCDA criteria, they would have no need to implement US Core/FHIR standards. Additionally, each criterion is tested individually, so even if an EHR developer were testing criterion b1 TOC for CCDA and g10 Standardized API for US Core/FHIR, they are not required to implement US Core/FHIR when testing b1. Currently, they would fail b1 certification because they have not bound their CCDA to US Core/FHIR requirements, which is not appropriate. How is this being addressed?

Thanks,

Michelle

[kylem...@gmail.com]

I'm not 100% sure Dragon's connection back US Core which is a FHIR requirement, but I would add that the CCDA Companion Guide (§ 170.205(a)(6)) is an equal standard along with the main HL7 CCDA IG (§ 170.205(a)(4)) for 315.b.1 compliance, and it does profile how USCDI is implemented in the CCDA for interoperability purposes. Because of that, it makes some requirements that are not in the CCDA IG. For at least RepeatNumber and Quantity, they are called out in the Companion Guide which would make them required for certification.  

I would also add that think we need to be careful with allowances around "SHOULD" or at least make them a case-by-case decision. The point of the certification program is to drive interoperability, and to do that, we need to be aligned. HL7 facilitator's guide states a SHOULD is a best practice where there may be valid reasons to ignore the item, but "the full implications must be understood and carefully weighed before choosing a different course." So it is not optional (that is a MAY) but instead, it is something the HL7 authors generally expect to be done in most situations. To me, it is reasonable for a developer to present why they can't implement a "SHOULD" that is being validated in the tool, but I can also understand if ONC (via test tool implementors or ATL/ACBs) don't accept that because of the "full implications" of the decision within the broader community.  

Kyle

[Nagesh Bashyam]

Thank you Kyle for this post re-iterating the required data elements vs SHOULD vs optionality.

 

--
You received this message because you are subscribed to the Google Groups "Edge Test Tool (ETT)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to edge-test-too...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/edge-test-tool/a27e19e3-2e0c-4757-8305-2709201490f6n%40googlegroups.com.