Connexion v26 adds purpose-built devices for converting between HL7 v2, FHIR and C-CDA, validating FHIR and C-CDA, and sending FHIR to a REST server. The conversions are compiled C# mappings rather than templates, so they need no template catalog and run quickly; each converter has optional custom code hooks for site-specific changes.

Converts HL7 v2 messages to a FHIR Bundle with Connexion's compiled HL7 v2-to-FHIR mappings. The mappings reproduce the Microsoft FHIR Converter HL7 v2 templates and are checked against Microsoft's expected output, with corrections where Microsoft writes invalid FHIR.

• Mapping selection. There is one mapping per message structure, and several message types share one (ADT^A01, ADT^A04 and ADT^A08 all use ADT_A01). The device takes the structure from MSH-9.3, or looks it up from MSH-9.1 and MSH-9.2 in HL7's message structure table. Built-in Mappings lists what each message type converts as.

• Message type rules are for exceptions: a rule converts a message type as another structure, for example ADT-Z01 as ADT-A01. Rules are checked when the device starts.

• Failures. A message the device cannot convert (no rule and no built-in mapping, an empty MSH-9, or one a mapping cannot convert) fails and goes to the error queue; HL7 is never passed on unconverted. To leave some message types unconverted, filter them out before the device.

• FHIR version. R4 by default, or R5, produced from the R4 output with HL7's official R4-to-R5 StructureMaps.

• Time zones. HL7 times without an offset are read in the configured source time zone (the server's by default).

• Custom code (optional): BeforeConvertAsync changes the HL7 message before conversion, ConvertAsync can produce the Bundle itself (for example for a message type with no mapping), and AfterConvertAsync changes the Bundle.

• Parallel processing. Converts the messages of a batch on several threads (2 by default, set in the device header); the batch keeps its order.

The output is a FHIR message that later FHIR devices use without parsing it again. The device does not validate what it writes: put a FHIR Validator Device after it. HL7 Transform devices can still run upstream to normalize local fields, apply map tables or reshape Z-segments.

• FHIR to HL7v2 Device converts a FHIR R4 or R5 Bundle (JSON or XML) to ADT^A01, ADT^A04, ADT^A08 or ORU^R01, the reverse of the HL7v2 to FHIR mappings. The message type comes from the Bundle's MessageHeader or is fixed in the settings; the HL7 version written is configurable (2.5.1 by default).

• CCDA to FHIR Device converts a C-CDA Release 2.1 or 4.0.0 document to a FHIR R4 or R5 batch Bundle (JSON or XML), following HL7 C-CDA on FHIR: the header and the main clinical sections' entries.

• FHIR to CCDA Device converts a FHIR R4 or R5 Bundle to a C-CDA Continuity of Care Document (4.0.0 by default, or Release 2.1), following HL7 C-CDA on FHIR.

• HL7v2 to CCDA Device does HL7v2 to FHIR and FHIR to CCDA in one device, for channels that need no FHIR of their own.

Every converter fails a message it cannot convert rather than passing it on, and has optional before and after custom code hooks.

Validates FHIR R4 or R5 resources and Bundles and records the results. Three modes, chosen per device:

• Local (default): Firely's validator inside Connexion, against FHIR packages shipped with Connexion (for R4: core, terminology, extensions and US Core 6.1.0) plus a site's own packages from a folder. Offline unless a terminology server is configured.

• Remote: the $validate operation of a FHIR server, using the FHIR Sender's connection and authentication settings.

• Rules only: no profile validation; only the device's rules run.

Validates C-CDA documents against the CDA R2 schema (with HL7's SDTC extensions) and HL7's C-CDA schematron for Release 2.1 or 4.0.0, chosen per device or read from the document. The schematron's warnings phase (SHOULD rules) is optional.

Both validators share their results, reporting and rules with the HL7 Validation Device:

• Rules. A rules grid adds site-specific checks to the standard validation: each row has a condition (an expression, a map-table lookup or a custom code function) and a validation that writes a finding at the elements its path selects.

• Findings and failure. Findings are written as events on the message; errors, and optionally warnings, can fail the message. Ignored rules drop findings a site accepts. The message itself is not changed.

• Results and reporting. Results are stored in a local database, a shared PostgreSQL or SQL Server database, or MongoDB, and the Reporting tab shows a results grid and aggregate reports; a finding opens at its place in the message.

• Parallel processing, as for the converters (2 by default).

The FHIR Sender transmits FHIR JSON to a FHIR REST endpoint with the application/fhir+json media type. It accepts FHIR JSON, the converters' FHIR messages and Firely Resource objects.

• Operations: post a Bundle to the base URL, create (POST /{resourceType}), update (PUT /{resourceType}/{id}), conditional update with a configured search expression, or automatic selection: Bundles are posted, resources without an id are created, and resources with an id are updated.

• Connection: anonymous, Basic, bearer-token or Integrated Windows authentication, with proxy, TLS certificate pinning and mutual TLS.

• Responses can stay in processing history only, be retained for diagnostics, or replace the message. Optional HTTP tracing helps troubleshooting; request and response bodies may contain PHI and should only be captured under appropriate operational controls.

• The sender does not validate: put a FHIR Validator Device before it.

The HL7v2 to FHIR and FHIR to HL7v2 devices are built on the Connexion.Fhir.Mapping library (FhirMappingEngine, with R4-to-R5 conversion), and the C-CDA devices on Connexion.Cda.Fhir. Developers can use Connexion.Fhir.Mapping directly for custom HL7 v2-to-FHIR mappings in their own devices or custom code.

• Razor Transformation

• Plugin Developers: What You Need to Know for v26 (parallel processing)