SDA and CDA Transformation
This page tracks InterSystems SDA/CDA transformation evidence and the boundary between interoperability transformation and persistent clinical data modelling.
Definition
Summary Document Architecture (SDA) is an InterSystems patient-data format used inside InterSystems interoperability and healthcare-data products as a transformation intermediary. In this wiki, SDA should be read as an internal canonical or staging representation for mapping between healthcare formats, not as an NHS, DSIC, GP Connect, MESH, ITK3, FHIR, HL7, CDA, or PRSB compliance route by itself.
The strongest local definition is:
- SDA is an InterSystems patient-data format for transforming healthcare data from one format to another.
- A documented CDA-to-FHIR flow can transform CDA to SDA using XSLT, then transform SDA to FHIR using DTL.
- IRIS for Health CDA documentation separately describes XSL transformation libraries for converting CDA documents into SDA and SDA into CDA.
- InterSystems documentation warns not to build a persistent data model on SDA structures, so SDA should not be treated as the durable source of truth for a shared care record, GP system, or national-service interface.
Related InterSystems Transformation Routes
| Term or route | What it is in this wiki | InterSystems component relevance | Boundary |
|---|---|---|---|
| SDA | InterSystems intermediary patient-data format for transformation. | Used in documented CDA-to-SDA-to-FHIR and SDA-to-CDA transformation mechanics. | Not an external compliance standard, persistent target data model, or NHS national-service interface. |
| CDA / C-CDA | Clinical Document Architecture document standards used in document exchange and transformation contexts. | Health Connect documentation lists CDA/C-CDA support; IRIS for Health CDA documentation describes CDA-to-SDA and SDA-to-CDA transformations. | CDA support does not prove a local transfer-of-care, GP Connect, or customer document route. |
| FHIR | External interoperability standard and API/data-model family. | Health Connect, IRIS for Health, FHIR Server, and FHIR Services can support FHIR patterns. | FHIR capability does not prove UK Core, GP Connect, DSIC, customer onboarding, or Standards Directory conformance. |
| HL7 v2 / HL7 v3 | Healthcare messaging standards used in many integration routes. | Health Connect documentation lists HL7 v2/v3 support and built-in transformations between FHIR and HL7 v2. | HL7 support is integration capability, not evidence of a named NHS or customer interface. |
| DTL | InterSystems data transformation language used in documented transformation flows. | The CDA-to-FHIR example uses SDA-to-FHIR DTL after CDA-to-SDA XSLT. | DTL proves transformation mechanics only where product/version and mapping artefacts are supplied. |
| XSLT / XSL | XML transformation route used for CDA/SDA conversion. | Documentation describes CDA-to-SDA XSLT and IRIS for Health XSL libraries for CDA/SDA conversion. | XSL transformation libraries still need customer-specific mappings, tests, and clinical safety where deployed. |
IRIS / SDA / FHIR Landing
In the Executive Summary diagram, IRIS / SDA / FHIR is shorthand for an internal InterSystems transformation and healthcare-data platform route, not a single NHS compliance interface.
Use this split:
| Term | Best local page | Role in the Executive Summary architecture |
|---|---|---|
| IRIS for Health | InterSystems IRIS for Health | Healthcare data and application platform that can sit under or beside integration, FHIR, and application-development routes. |
| SDA | SDA and CDA Transformation | Internal InterSystems transformation/canonical-intermediary pattern where needed; not an external NHS national-service route. |
| FHIR | FHIR Services, InterSystems FHIR Server, and FHIR Packages and Profiles | External interoperability standard and repository/API route where the deployment proves the relevant profile, package, CapabilityStatement, and assurance scope. |
| Health Connect transformations | Health Connect | Mediation, routing, transformation, monitoring, and operational support for the actual source and target interfaces. |
Supported Positioning
InterSystems Health Connect documentation lists healthcare interoperability standards including FHIR, HL7 v2/v3, IHE XDS.b/XCA/PIX/PDQ/MHD, CDA/C-CDA, DICOM, and X12, and describes built-in transformations between FHIR and HL7 v2 or C-CDA.
SDA is documented as an InterSystems patient-data format used as an intermediary for transforming healthcare data from one format to another. For a CDA-to-FHIR flow, the documentation describes CDA-to-SDA XSLT transformation followed by SDA-to-FHIR DTL transformation.
Technical Shape
- Health Connect includes FHIR client and server components, a FHIR object model, and built-in transformations for translating between FHIR and other healthcare interchange standards.
- SDA is explicitly framed as an intermediary data format; the documentation warns not to build a persistent data model on SDA structures.
- InterSystems IRIS for Health CDA documentation describes a library of XSL transformations for converting CDA documents into SDA and SDA into CDA.
Evidence Status
Confidence is high for documented transformation mechanics and the SDA-as-intermediary boundary. This page does not prove a particular customer mapping, clinical-safety case, data-quality threshold, or local custom transform.
Related Pages
Follow-up Evidence
- Current transform library coverage, customization guidance, and test evidence.
- Customer-specific mapping artefacts, clinical-safety evidence, and data-quality validation.
- UK standards mapping where CDA/SDA/FHIR transformations support national or local interoperability.