CDA and XML utility
Format and inspect clinical XML, explore a namespace-aware tree, summarise common CDA header details, browse sections, and check internal narrative references without uploading the document.
Formatter and viewer
The tool checks XML syntax and provides practical CDA-aware inspection. It is not a certified CDA, schema, template, terminology, or implementation-guide validator.
The document stays in your browser and is not saved by this tool.
A collapsible XML tree will appear here.
Formatted XML will appear here.
Namespace details will appear here.
Structural inspection notes will appear here.
FAQ
No. It validates XML syntax and performs practical CDA-aware structural inspection. It does not validate the complete CDA model, XSD schemas, template constraints, terminology bindings, or jurisdiction-specific implementation guides.
The tree keeps qualified element and attribute names where prefixes exist, and the Namespaces tab shows prefixes and namespace URIs discovered in the document.
The tool looks for common ClinicalDocument header structures such as template IDs, document identity and code, record target, author, custodian, legal authenticator, encompassing encounter, structured body, and sections.
The tool flags literal double-escaped entity text such as ' in the raw XML because it can indicate that entity text was escaped twice. The note is a debugging aid, not a conformance verdict.
No. Use synthetic or appropriately de-identified test data only.
Practical guide
A CDA document combines a header, coded sections, machine-readable entries, and human-readable narrative. The viewer helps move between those layers so that an integration problem can be located in the document structure rather than treated as one large XML string.
Worked example
<section>
<code code="10164-2" codeSystem="2.16.840.1.113883.6.1"/>
<title>History of Present Illness</title>
<text>Patient reports increasing shortness of breath.</text>
</section>The narrative may be perfectly readable, but an implementation can still fail if the section code, template ID, null flavour, required entry, or code-system identifier is missing or incorrect. Conversely, a coded entry can be present while the narrative shown to clinicians omits the important result.
Review both representations. CDA conformance and clinical usability depend on the relationship between the XML structure and the rendered document, not merely on whether the XML parser accepts the file.
Troubleshooting
#result-1 must match an ID in the document.This viewer performs practical structural checks but is not a full CDA schema, Schematron, terminology, template, or national conformance validator. It also cannot determine whether the clinical narrative is complete, accurate, or safe.
Use it to understand and troubleshoot the document, then validate against the exact implementation guide and test environment.
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.