Clarification on 170.315(b)(2) CIRI — ingestion of both source CCDs vs. existing patient chart data

56 views
Skip to first unread message

Rajkumar P

unread,
Jun 18, 2026, 7:21:11 AMJun 18
to Edge Test Tool (ETT)

Hello,

We are working toward 170.315(b)(2) Clinical Information Reconciliation and Incorporation (CIRI) for the inpatient setting, and have a question about how the two scenario CCDs are expected to be loaded into the System Under Test (SUT).

Using the R1.1 CCD test data, the instructions state:
  1. Provide the SUT with 170.315_b2_ciri__r11_sample1_v*.xml
  2. Then provide the SUT with 170.315_b2_ciri__r11_sample1_recon_v*.xml
  3. The two CCDs belong to the same patient, and the SUT must provide a mechanism to reconcile them.

Our application's reconciliation UI has a single document-import control. In our workflow:
  - The 'Current' clinical data (medications, problems, allergies) is loaded from the matched patient's existing record in our system.
  - The 'Imported' clinical data is parsed from the uploaded C-CDA XML.

Our question:

For this test, must BOTH the v1 CCD and the recon_v1 CCD be ingested as imported XML documents (i.e., the SUT parses both files), or is it acceptable for one CCD to be represented as the patient's existing/current chart data (already present in the system) and the other to be the imported document that is reconciled against it?

In other words, does the criterion require that both CCDs are read from incoming C-CDA files, or only that the SUT can reconcile two same-patient clinical information sets regardless of whether one side originates from the patient's existing record?

If both files must be ingested from XML, we will adjust our UI to accept two documents (or accept them sequentially into the same control). We want to confirm the intended interpretation before finalizing our reconciliation flow and submitting the generated C-CDA to the validator.

Thank you for any guidance.

Best regards,
Rajkumar.P 

Rajkumar P

unread,
Jun 18, 2026, 9:10:43 AMJun 18
to Edge Test Tool (ETT)
"So the flow is: upload only the recon XML into our app → reconcile against current DB → our app generates the new C-CDA → we upload that generated C-CDA to the validator site. Correct?

Vishnu Mulla

unread,
Jun 18, 2026, 12:30:34 PMJun 18
to Edge Test Tool (ETT)

Hello Rajkumar,

Thank you for the details. Before we answer, we want to make sure we understand the workflow you are trying to support.

Can you please clarify what you are trying to accomplish end-to-end in your system for this test?

For example, are you trying to:

  1. Use the first ONC test file to create or populate the patient’s current record in your system;
  2. Then use the reconciliation test file as the new incoming clinical document;
  3. Have your system compare the incoming document against the patient’s current record;
  4. Complete the reconciliation in your system; and
  5. Generate a final C-CDA output that you will submit to the validator?

Once we understand your intended end-to-end workflow, we can better respond to the specific question about whether the two files need to be uploaded together or can be handled sequentially.

Thank you,
SITE Support Team

Rajkumar P

unread,
Jun 18, 2026, 10:03:02 PMJun 18
to Vishnu Mulla, Edge Test Tool (ETT)
Yes, that is our intended workflow.

We already have the patient's current record stored in our system. We upload only the reconciliation test XML as the incoming document, perform reconciliation against the existing patient record in our database, generate a new reconciled C-CDA, and then upload that generated C-CDA to the validator.

Could you please confirm whether this workflow is correct for the ONC reconciliation test?


--
You received this message because you are subscribed to a topic in the Google Groups "Edge Test Tool (ETT)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/edge-test-tool/yB5RKwIeADE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to edge-test-too...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/edge-test-tool/f85b1d41-0841-441d-935c-dada2335ca2fn%40googlegroups.com.

Rajkumar P

unread,
Jun 18, 2026, 11:26:52 PMJun 18
to Edge Test Tool (ETT)
Subject: Re: Clarification on 170.315(b)(2) CIRI — ingestion of both source CCDs vs. existing patient chart data

Hello SITE Support Team,

Thank you for the response. Yes, the five-step workflow you described is exactly our intended end-to-end flow. To confirm how it works in our system:

1. The patient's current record is already registered in our database beforehand, populated from the v1 file (medications, allergies, and problems).

2. During the demonstration, the user uploads only the recon_v1 document through a single upload control in our UI.

3. Our system matches the uploaded document to the existing patient. Once the patient is confirmed, the current medications, allergies, and problems are loaded from our database for that patient.

4. The user reconciles the current data against the imported (recon) data — adding, merging, or removing medications, allergies, and problems as needed.

5. After reconciliation, our system generates the updated R2.1 C-CDA, which we then download and upload to the validator site.

So in our UI there is only one upload control (for the incoming recon document); the current record comes from our database rather than a second file upload.

Could you please confirm that this approach is acceptable for the test — i.e., the v1 baseline data is already incorporated into the patient's current record beforehand, and only the recon_v1 document is uploaded live during the demonstration?

Thank you again for your help.

Best regards,
Rajkumar P

Rajkumar P

unread,
Jun 19, 2026, 8:12:15 AMJun 19
to Edge Test Tool (ETT)
Hi,
I'm working on §170.315(b)(2) Clinical Information Reconciliation and Incorporation (CIRI) certification.
The test materials for both 170.315_b2_CIRI_Inp (Inpatient) and 170.315_b2_CIRI_Amb (Ambulatory) — including the first example PDF — use the same patient name and demographics.
Could you clarify the expected setup in the system under test:
1. Should this be a single patient record with two separate encounters (one Inpatient, one Ambulatory)?
2. Or should two separate patient records be created, even though they share the same name and demographics?
Our application treats the same name/DOB/SSN as one patient and attaches multiple encounters of different types, so we want to confirm this matches the intended test approach before submission.
Thanks,
Rajkumar
Reply all
Reply to author
Forward
0 new messages