CDA and XML comparison utility
Compare two clinical XML documents structurally, match CDA sections and entries semantically, and review header, narrative, attribute, value, and internal reference changes without uploading the content.
Structured comparison
This tool compares parsed XML structure and applies practical CDA-aware matching. It is not a CDA, schema, template, terminology, or implementation-guide conformance validator.
Both documents stay in your browser and are not saved by this tool.
Separate paths with commas, semicolons, or new lines. Asterisks act as wildcards. Paths are matched against the structured result paths shown below.
CDA sections
Sections are matched by code, then template IDs, then title when semantic section matching is enabled.
Internal references
Changes to CDA narrative references and their local ID resolution state are shown separately.
| Status | Path | Original | Updated |
|---|
| Status | Scope | Path | Original | Updated |
|---|
Compare two documents to generate a report.
FAQ
No. The tool parses both XML documents, compares elements, attributes, and direct text values, and uses CDA-aware semantic keys for sections and structured entries when possible.
With semantic section matching enabled, the tool prefers section code and code system, then template IDs, then title. Reordering the same sections should not create false removed and added section results.
The tool looks for statement identifiers first and coded statement keys second for common entry types such as observations, substance administrations, procedures, acts, organizers, encounters, and supplies. It falls back to order when stable unique keys are unavailable.
They ignore the direct ClinicalDocument document ID and effectiveTime, plus author or authenticator time elements. Encounter effectiveTime and other IDs remain significant unless you explicitly ignore their paths.
No. It performs structured comparison and practical CDA-aware matching only. It does not validate schemas, templates, terminology, or jurisdiction-specific implementation guides.
No. Use synthetic or appropriately de-identified test data only.
Practical guide
CDA documents often contain generated IDs, timestamps, reordered XML, and formatted narrative alongside clinically important changes. The comparison tool helps expose structured differences while keeping the document's section and entry context visible.
Worked example
Document A: ClinicalDocument/effectiveTime/@value = 20260720093000+1000
Document B: ClinicalDocument/effectiveTime/@value = 20260720101500+1000
Document A: observation/effectiveTime/@value = 20260719080000+1000
Document B: observation/effectiveTime/@value = 20260720080000+1000The document timestamp may simply indicate regeneration or a new document version. The observation timestamp changes the represented clinical event and may require clinical or mapping review. Paths, surrounding section context, and document-version fields help determine which difference is important.
Avoiding false positives
Equivalent sections or entries may be emitted in a different order. Random UUIDs, document IDs, timestamps, or software-specific namespace prefixes can also create large diffs that obscure the actual regression.
For repeatable tests, use stable synthetic identifiers and timestamps where possible. Compare section codes, template IDs, business identifiers, and clinical values before treating positional movement as a defect.
Authorship and review
Maintained and technically reviewed by Health Data Tools, drawing on more than 15 years of healthcare integration experience across HL7, FHIR, CDA, APIs, PKI, and clinical integration systems.
Technically reviewed:
Official references
These references support the technical context. Local implementation guides, vendor profiles, and receiving-system rules still take precedence for a specific interface.