In our last healthcare post, Modernizing Healthcare Integration with Naftiko: From HL7 v2 to OpenEHR, we showed how a Naftiko Capability turns a pipe-delimited HL7 v2 ADT message into a structured OpenEHR composition. That kind of standard-to-standard translation is where most teams begin. It is also the easy part.
The harder, more valuable layer is what an industry initiative called IHE – Integrating the Healthcare Enterprise – has been doing for over twenty-five years: writing Integration Profiles that constrain the underlying standards into specific, testable, multi-vendor workflows. Profiles are how cross-organizational document sharing, patient-identity-cross-referencing, imaging workflows, and (increasingly) European Health Data Space exchanges actually work in production.
This post walks through how Naftiko Capabilities can be used at both layers. First, the translation patterns across HL7 v2, FHIR, DICOM, and OpenEHR. Then, the implementation patterns that let a capability deliver an actual IHE Integration Profile – as a Connectathon-testable actor, a cross-cutting substrate, or an AI-callable MCP tool that no other implementation in the market exposes.
Part 1: Translation Patterns Across the Healthcare Standards
A Naftiko Capability is a YAML file that declares what it consumes, what it produces, and what it exposes to AI agents and tools. The translation use cases line up cleanly with that shape:
- HL7 v2 to OpenEHR – Pipe-delimited ADT, ORM, ORU, RDE messages from a hospital integration engine, turned into structured OpenEHR compositions backed by clinically-authored archetypes. We covered this in detail in the previous post.
- HL7 v2 to FHIR – The same ADT events surfaced as FHIR Encounter, Patient, and Condition resources for modern application stacks.
- DICOM to FHIR ImagingStudy – DICOMweb QIDO-RS metadata translated into FHIR ImagingStudy resources for cross-system image references.
- OpenEHR to FHIR – Canonical OpenEHR compositions read out and projected as FHIR bundles for partners who only speak FHIR.
- FHIR to FHIR – Profile-to-profile transformations between US Core, IPS, EHDS-aligned, and payer profiles.
Each translation is a short capability following the consume-produce-expose pattern. Here is a compact HL7 v2 to FHIR sketch:
naftiko: "1.0.0-alpha1"
info:
label: HL7 v2 ADT^A01 Patient Admit to FHIR Encounter
description: >-
Reads HL7 v2 ADT^A01 messages from a hospital integration engine and
posts FHIR R4 Encounter, Patient, and Condition resources to a target
FHIR server. Useful for modernizing downstream consumers without
touching the upstream interface engine.
tags: [hl7v2, fhir, adt-a01, healthcare]
capability:
consumes:
- namespace: hl7-gateway
type: http
baseUri: "https://hl7-gateway.hospital.example/api/v1"
resources:
- name: adt-events
path: "/adt/events"
operations:
- name: get-admit-event
method: GET
- namespace: fhir-server
type: http
baseUri: "https://fhir.hospital.example/r4"
resources:
- name: encounters
path: "/Encounter"
operations:
- name: post-encounter
method: POST
exposes:
- type: mcp
port: 3020
namespace: hl7-fhir-tools
tools:
- name: transform-adt-a01-to-fhir
description: >-
Fetches an ADT^A01 message and posts the resulting FHIR R4
Encounter resource to the configured FHIR server.
inputParameters:
- name: messageId
type: string
required: true
steps:
- name: fetch-admit
type: call
call: hl7-gateway.get-admit-event
with:
messageId: hl7-fhir-tools.messageId
- name: post-encounter
type: call
call: fhir-server.post-encounter
Same pattern as the OpenEHR post: consume the legacy gateway, produce the modern resource, expose an MCP tool. Multiply across HL7 v2, FHIR, DICOM, and OpenEHR and you have a translation fleet that retains existing investment without locking the future.
This is genuinely useful work. It is also where most healthcare integration platforms stop.
Part 2: From Standards to Profiles
Translating standards moves data between formats. Profiles specify the workflows that data participates in. The distinction matters.
Take cross-enterprise document sharing. FHIR has a DocumentReference resource. HL7 v2 has MDM messages. DICOM has Structured Reports. None of them, on their own, tell you how Hospital A’s EMR shares a discharge summary with Hospital B’s primary care system across an organizational boundary. That is what an IHE Integration Profile does.
A profile defines:
- Actors – the system roles that participate, e.g., Document Source, Document Repository, Document Registry, Document Consumer.
- Transactions – the specific exchanges between those actors, grounded in a base standard (FHIR REST call, HL7 v2 message, DICOM operation).
- Content modules – which CDA template, which FHIR profile, which DICOM SOP class is required.
- Conformance options – mandatory versus optional behaviors that products declare at IHE Connectathons.
- Cross-cutting actors – ATNA (audit), CT (consistent time), XUA (cross-enterprise user assertion). Almost every IHE profile depends on these.
A Naftiko Capability is operation-shaped: one consumes operation, one exposes tool, one MCP entry. An IHE profile is workflow-shaped. The interesting design work is mapping one onto the other cleanly. Here is how.
Pattern 1: One Capability per IHE Actor
The default. Each actor in a profile becomes its own Naftiko Capability. For XDS.b cross-enterprise document sharing, that means a xds-document-source.naftiko.yml, a xds-document-repository.naftiko.yml, a xds-document-registry.naftiko.yml, and a xds-document-consumer.naftiko.yml. Each is independently deployable and Connectathon-claimable.
naftiko: "1.0.0-alpha1"
info:
label: IHE XDS Document Source
description: >-
IHE ITI Document Source actor (XDS.b). Submits a SubmissionSet of
clinical documents to a configured Document Repository in an XDS
Affinity Domain via transaction ITI-41. Emits an ATNA audit event
per ITI Technical Framework Volume 2 requirements.
ihe:
profile: XDS.b
actor: Document Source
transactions: [ITI-41]
tags: [ihe, xds, iti-41, healthcare]
capability:
consumes:
- namespace: repo
type: http
baseUri: "{{XDS_REPOSITORY_BASE_URI}}"
resources:
- name: provide-and-register
path: "/Repository/services/xdsrepositoryb"
operations:
- name: submit-document-set
method: POST
- namespace: audit
type: capability
ref: ihe-atna-audit-record-repository
exposes:
- type: mcp
port: 3030
namespace: xds-document-source
tools:
- name: submit-document-set
description: >-
Submit a SubmissionSet of clinical documents to the XDS
Affinity Domain Document Repository (transaction ITI-41).
inputParameters:
- name: patientId
type: string
required: true
description: "CX-formatted patient identifier with assigning authority OID"
- name: documents
type: array
required: true
- name: submissionSetMetadata
type: object
required: true
steps:
- name: submit
type: call
call: repo.submit-document-set
- name: audit
type: call
call: audit.record-event
Two things to notice. First, the info.ihe block carries the profile, actor, and transaction codes – structured metadata that a Connectathon test harness or registry can introspect. Second, the capability composes another Naftiko capability – the audit record repository – via the second consumes entry. That is Pattern 2.
Pattern 2: Cross-Cutting Capabilities for the IHE Substrate
ATNA, CT, and XUA are not workflow profiles. They are substrate. Build them once and depend on them everywhere.
naftiko: "1.0.0-alpha1"
info:
label: IHE ATNA Audit Record Repository
description: >-
IHE Audit Record Repository actor. Receives ATNA-conformant audit
events emitted by other IHE actor capabilities and persists them
for compliance and forensic review.
ihe:
profile: ATNA
actor: Audit Record Repository
transactions: [ITI-20]
tags: [ihe, atna, audit, security]
Every other IHE-profile-implementing capability adds audit to its consumes list. The fleet now has a single auditable trace of every cross-enterprise transaction, and conformance to ATNA’s audit requirements is composed in rather than re-implemented per profile.
The same pattern applies to a consistent-time.naftiko.yml for CT and an xua-assertion.naftiko.yml for cross-enterprise user identity.
Pattern 3: FHIR-Native Profiles Are the Cleanest Fit
The newer IHE profiles – the ones the European Health Data Space and US TEFCA initiatives are building on – are FHIR-based. Patient Identity Cross-Reference for Mobile (PIXm, transaction ITI-83) is a one-page capability:
naftiko: "1.0.0-alpha1"
info:
label: IHE PIXm Patient Identifier Cross-Reference Consumer
description: >-
Resolves a patient's identifiers across systems within an Affinity
Domain using IHE PIX-on-FHIR (ITI-83). Built on FHIR R4 Patient
$ihe-pix operation.
ihe:
profile: PIXm
actor: Patient Identifier Cross-Reference Consumer
transactions: [ITI-83]
tags: [ihe, pixm, fhir, iti-83]
capability:
consumes:
- namespace: pix
type: http
baseUri: "{{PIX_MANAGER_BASE_URI}}/fhir"
resources:
- name: patient-identifier-xref
path: "/Patient/$ihe-pix"
operations:
- name: cross-reference
method: GET
exposes:
- type: mcp
port: 3031
namespace: pixm-consumer
tools:
- name: cross-reference-patient-id
description: >-
Resolve a patient's identifiers across systems within an
Affinity Domain using IHE PIX-on-FHIR.
inputParameters:
- name: sourceIdentifier
type: string
required: true
description: "Token search param: system|value"
- name: targetSystem
type: string
call: pix.cross-reference
Because FHIR transactions are already RESTful, the consumes-exposes mapping is one-to-one. PIXm, PDQm, MHD, and IUA all collapse into capabilities of similar size. This is why the FHIR-based IHE profile track at the recent IHE-Europe Connectathon in Brussels is the fastest-growing one.
Pattern 4: Profile Bundle as a Workflow Tool
For consumers who do not want to wire up four actor capabilities, ship a meta-capability – xds-affinity-domain-workflow.naftiko.yml – that internally consumes the actor capabilities and exposes a single high-level tool: “share clinical document across affinity domain.” The underlying actors remain the unit of conformance. The bundle is sugar for AI agents that prefer one verb over five.
This is the most AI-friendly shape. An LLM agent can call share-clinical-document once and the capability orchestrates the IHE-conformant transactions underneath – including the audit emission and identity assertion that a hand-written agent would forget.
Pattern 5: Auto-Generating Capabilities from IHE Implementation Guides
This is the force-multiplier. IHE publishes its FHIR-based profiles as FHIR Implementation Guides – bundles of StructureDefinition, CapabilityStatement, and OperationDefinition resources. That is the same structured input a Naftiko capability YAML wants to consume.
A Naftiko skill could read an IHE FHIR IG, walk every Actor declared in its CapabilityStatement, and emit one capability YAML per actor with consumes, exposes, parameter schemas, and the info.ihe metadata block pre-populated. IHE has hundreds of profiles. This is the kind of artifact that one engineer can drive but that no one engineer can hand-write.
Pattern 6: Connectathon-Validated Capabilities
A Naftiko capability deployed via the fleet has a network surface. It implements transactions. It can be peer-tested at an IHE Connectathon – the multi-day events where vendors prove interoperability against each other in real time. The North America Connectathon Week is in Arlington, Virginia, in October 2026; the IHE-Europe Connectathon returns to Brussels in spring 2027.
A capability registered as a system-under-test in Gazelle, with its info.ihe metadata declaring the actor and transactions claimed, becomes Connectathon-eligible. Pass results post on connectathon-results.ihe.net – the same enterprise credibility signal that Epic, Cerner, and InterSystems lean on.
Pattern 7: AI Agents Calling IHE Profiles via MCP
This is the pattern that no other IHE actor implementation in the market offers. Every existing implementation – Epic, IBM, InterSystems, b·well, Forcare – exposes profile transactions over HL7 v2, SOAP, or FHIR. None of them expose those transactions as MCP tools.
Naftiko’s exposes: type: mcp block changes that. A profile-implementing capability automatically becomes an AI-callable tool. An LLM agent can:
- Cross-reference a patient identifier (PIXm, ITI-83) before calling a downstream FHIR API.
- Fetch a clinical document set (XDS-I or MHD) as context for a clinical reasoning task.
- Submit a structured audit event (ATNA, ITI-20) when an AI agent acts on a patient’s record.
That is the most concrete way to deliver on what the IHE community is increasingly saying out loud: leveraging standards in healthcare will make AI solutions better. Profiles are how standards become usable. Naftiko Capabilities are how profiles become AI-callable.
What This Means for European and US Healthcare Programs
These patterns map to the regulatory weather healthcare is operating in right now. The European Health Data Space (EHDS) regulation is in force, with mandatory cross-border patient summary and ePrescription exchange coming online in 2029, and medical images, lab results, and discharge reports following in 2031. Every EU EHR vendor has to certify. Every cross-border exchange needs a working profile implementation.
IHE-Europe runs the practical testing rails for that work, and IHE recently launched the PRISM accelerator – a program that takes a market need (the first cohort is EHDS), runs it through an accelerated profiling cycle, and produces a Connectathon-validated specification. The pattern is the same in the US, where the North America Connectathon anchors profile testing for TEFCA-aligned exchange.
A Naftiko Capability is not a replacement for this work. It is the AI-callable, governed, declaratively-versioned delivery vehicle for it.
Looking for Healthcare Design Partners
We are actively looking for healthcare design partners who want to modernize and integrate their existing patient data securely and confidently into AI workflows – and who care about doing it in a way that holds up against IHE profiles, EHDS certification, and cross-border exchange requirements.
The Naftiko Framework and the Capabilities specification are released under the Apache 2.0 license. If you are working with HL7 v2, FHIR, DICOM, OpenEHR, or any combination of these standards – and you want to explore how governed, AI-callable capabilities can carry that work forward into IHE-conformant integration profiles – we want to hear from you.
