IHE — integration profiles built on HL7, DICOM, FHIR

Quick summary

• IHE began in 1998 with involvement from RSNA and HIMSS; profiles are organized into domains such as IT Infrastructure, Radiology, Cardiology, PCC, QRPH, and PaLM.
• A profile commonly defines a use case, actors, transactions, options, groupings, and/or content modules; the exact requirements live in the selected Technical Framework version.
• XDS.b manages document sharing within an Affinity Domain and does not require one document-content format. MHD provides a FHIR R4 interface for a subset of document-sharing use cases and can act as an API in front of XDS/XCA.
• PIXm and PDQm are distinct: PIXm handles identifier cross-references, while PDQm supports demographic query or matching. They should not be collapsed into one API or a default requirement.
• IHE Worldwide did not list a Vietnam Deployment Committee at the review snapshot. ATNA, MHD, and other profiles are technical design inputs; legal compliance still requires a separate analysis of processing roles, data, and deployed controls.

1. What is IHE? History and organizational structure

IHE was founded in 1998 in the United States by two professional societies: RSNA (Radiological Society of North America) and HIMSS (Healthcare Information and Management Systems Society). The original goal was to fix the fact that PACS, RIS, and HIS systems could not talk to each other, even though they all claimed to use HL7 and DICOM — every vendor implemented the standards a little differently. IHE did not write a new standard; it described how existing standards should be combined so that every vendor would do the same thing.

Organizationally, IHE International is a member-driven non-profit. National chapters or deployment committees handle local adaptation and regional testing — IHE Europe, IHE USA, IHE Japan, IHE Korea, and IHE Asia-Oceania are active examples. On the public IHE Deployment Committees list reviewed in June 2026, Vietnam is not yet listed as an official committee.

Key outputs include Technical Frameworks and Profiles, test material, and cross-vendor evidence from Connectathons. A test result applies only to the actor, profile, option, and version exercised at that event; it does not prove that an entire product or a particular deployment is interoperable in every context.

2. A profile = use case + actors + transactions

An IHE profile commonly describes a use case, actors, and transactions; depending on the profile it can also define options, required groupings, content modules, and security considerations. Base standards still define the applicable data structures or protocols, while IHE constrains their use within the stated workflow.

Take the canonical example of XDS.b (Cross-Enterprise Document Sharing) — the most widely cited document-sharing profile:

Profile: XDS.b (Cross-Enterprise Document Sharing)
├── Actors:
│   ├── Document Source       (the facility producing the document, e.g. a provincial hospital)
│   ├── Document Repository   (stores the document binary)
│   ├── Document Registry     (the metadata index, where queries hit)
│   └── Document Consumer     (the facility/app reading the document, e.g. a commune health station)
├── Transactions:
│   ├── ITI-41: Provide and Register Document Set-b
│   ├── ITI-42: Register Document Set-b
│   ├── ITI-43: Retrieve Document Set-b
│   └── ITI-18: Registry Stored Query
└── Technology:
    ├── ebXML Registry metadata (ebRIM/ebRS)
    ├── SOAP 1.2 over HTTPS, MTOM/XOP for binary attachments
    └── Payload: CDA R2, PDF/A, DICOM images, plain text — whatever the Affinity Domain specifies

Note: XDS.b uses an ebXML Registry over SOAP 1.2, with MTOM/XOP for binary file transport. The payload may be CDA, PDF, an image, or any format defined by the Affinity Domain — CDA is one option among many, not a hard requirement. The "actors + transactions + technology" pattern repeats for every other profile.

3. The main IHE domains

IHE organizes profiles into domains by clinical or technical area. The table below lists the active domains together with representative profiles (the full catalog lives at profiles.ihe.net):

One naming caveat worth flagging: PaLM is the name of a domain, not a single profile — it merges what used to be the Laboratory and Anatomic Pathology domains. The legacy LAB-* identifiers still exist, but they are now transactions inside PaLM profiles such as LTW or LAW. Likewise, DSG (Document Digital Signature) lives in the ITI domain, not QRPH.

4. Ten profiles you should know

4.1 XDS / XDS.b — Cross-Enterprise Document Sharing

XDS.b supports registration, distribution, and access to documents across organizations in one or more Affinity Domains. A basic flow commonly includes Document Source, Repository, Registry, and Consumer actors with transactions such as ITI-41, ITI-42, ITI-43, and ITI-18; the profile defines additional actors, transactions, and groupings. Documents are handled as payloads, while Affinity Domain policy determines formats, identity, consent, and access control. The project corpus has no public evidence supporting a claim that a particular Vietnamese program deploys XDS.b.

4.2 PIX / PDQ — Patient Identity Cross-reference / Demographics Query

PIX supports cross-referencing patient identifiers across identifier domains; PDQ supports demographic queries through transactions defined by its profile. These are patterns that may be assessed for an MPI or HIE, but Circular 13/2025/TT-BYT does not itself prescribe PIX, PDQ, or a “national MPI” architecture. A Vietnamese design must define each identifier authority, match/merge rules, access control, and false-match handling.

4.3 ATNA — Audit Trail and Node Authentication

ATNA defines actors and transactions related to node/application security and an Audit Record Repository. Grouping requirements must be read in each profile; XDS.b, for example, specifies required ATNA groupings for its actors. ATNA may support part of an audit architecture, but it does not prove compliance with Law 91/2025/QH15 or Decree 356/2025/NĐ-CP. Event scope, retention, log access, and processing responsibility still require separate decisions.

4.4 BPPC — Basic Patient Privacy Consents

BPPC records that a patient has agreed to an Affinity Domain privacy policy in a document-sharing environment. BPPC and FHIR Consent have different models, transactions, and conformance boundaries; they are not direct replacement versions of one another. A Vietnamese use case should start from the lawful basis and applicable duties, then select the profile and representation that fit.

4.5 MHD — Mobile access to Health Documents

MHD defines FHIR interfaces for publishing, finding, and retrieving documents, with emphasis on clients that use a simpler or resource-constrained stack. It profiles DocumentReference, List, Bundle, and Binary; Folder and SubmissionSet are represented by List profiles, not separate FHIR Resource types. At the 18 July 2026 snapshot, IHE exposes MHD 4.2.5-comment as a Publication Ballot based on FHIR R4, so an implementation must pin the exact package and status. MHD supports a subset of XDS use cases and may act as an API to XDS/XCA, but it does not reproduce all XDS scalability, security, or functionality.

4.6 SWF / SWF.b — Scheduled Workflow (Radiology)

SWF/SWF.b defines actors and transactions for ordering, scheduling, performing, and storing diagnostic-imaging work. A product that supports DICOM Modality Worklist or C-STORE does not automatically support every SWF actor and option; inspect its IHE Integration Statement, DICOM Conformance Statement, and the configuration actually deployed at the site.

4.7 XCA / XCA-I — Cross-Community Access

XCA defines actors and transactions for querying and retrieving documents across community boundaries; XCA-I applies the cross-community problem to imaging information. This is a distributed federation pattern, but data location, access control, and any claim about data sovereignty still depend on deployment architecture and policy.

4.8 PIXm / PDQm — FHIR-native Patient Identity

PIXm and PDQm both use FHIR R4 but define different contracts. PIXm 3.1.0 publishes ITI-83 for identifier cross-reference queries and ITI-104 for patient-identity feeds; PDQm 3.2.0 publishes ITI-78 for demographic query and ITI-119 for patient match. Select either or both according to the actors and use case. VN Core Patient supplies Vietnamese data constraints; it does not create PIXm/PDQm capability by itself.

4.9 IPS — International Patient Summary

International Patient Summary is a family of standards and guides for a minimal health summary, independent of any one national system. A reference should name the exact artifact, such as ISO 27269 or a specific HL7 FHIR IPS IG version. IPS may be used for a gap analysis of a Vietnamese summary use case, but Decision 1332/QĐ-BYT does not thereby mandate IPS or establish compatibility with VNeID.

4.10 PaLM domain — Pathology and Laboratory Medicine

PaLM is not a single profile but a domain, formed by merging the older Laboratory and Anatomic Pathology domains. The flagship profiles in PaLM are LTW (Laboratory Testing Workflow), LAW (Laboratory Analytical Workflow), LDA (Laboratory Device Automation), LPOCT (Laboratory Point-of-Care Testing), LCSD (Laboratory Code Set Distribution), LBL (Laboratory Barcode Labeling), and XD-LAB (Sharing Laboratory Reports cross-enterprise). The legacy LAB-* transactions still exist, but they are now folded into these profiles.

5. IHE and FHIR — the relationship and the shift

IHE publishes several FHIR R4-based profiles, including MHD, PIXm, PDQm, mXDE, and QEDm. Each defines its own actor and transaction contract and may inherit selected concepts from earlier profiles. This is not a mandatory replacement roadmap, and it does not show that every IHE deployment is moving to FHIR.

A deployment may use MHD as an API in front of XDS/XCA, use it in a stand-alone push solution, or select another profile according to its requirements. Combining profiles still requires explicit mappings for metadata, identity, security, and error behavior; no gateway label automatically guarantees semantically correct exchange between architectures.

A quick comparison of XDS.b and MHD:

6. Connectathon — interoperability under fire

Connectathons are cross-vendor testing events scheduled by IHE regions under their current event programs. Systems are tested against the profiles, actors, and options registered for the event; results should be checked in the Connectathon Results service. The IHE Product Registry primarily hosts vendor-authored Integration Statements, so the two evidence types should not be conflated.

One thing is often misunderstood: passing the Connectathon is not the same as being "certified compliant". IHE is explicit that the Connectathon provides baseline evidence of interoperability — it is not an independent product certification. Final responsibility rests with the vendor through the self-declared IHE Integration Statement. Conversely, not having a pass does not automatically mean "non-compliant" either — it just means there is no public test evidence.

A Vietnamese implementation team can evaluate a Connectathon once its actor, profile, option, test partners, and pass criteria are defined. Event results still need site testing with the deployment's own policies, terminology, volumes, and security controls.

7. The Vietnamese context and recommendations

Snapshot on 18 July 2026: IHE Worldwide lists 17 countries with national deployment committees and does not list Vietnam. The VN Core legal corpus likewise contains no Vietnamese instrument mandating a specific IHE profile. XDS.b, MHD, PIXm, PDQm, ATNA, or SWF should therefore enter architecture or procurement only where their actors and transactions match the use case. Evidence should identify the Technical Framework version, Integration Statement, any Connectathon result, relevant conformance statements, and site test scope.

Select profiles by use case:

• Assess MHD for FHIR R4 publish/query/retrieve APIs; assess XDS.b where the full XDS actor, transaction, and policy model is required.
• Assess PIXm for identifier cross-reference and PDQm for demographic query/match. Do not make the personal identification number the only key where legacy data or people without that identifier remain in scope.
• Assess ATNA against required groupings and the threat model; map IHE events, FHIR AuditEvent, infrastructure logs, and legal duties separately.
• Assess SWF/SWF.b at actor/option level and compare it with each product's DICOM Conformance Statement.
• Use IPS as one comparison source for a patient-summary use case when appropriate; do not infer a VNeID API or dataset from IPS without an official contract.
• Join a Connectathon only when test scope and evidence goals are clear; a result is neither a legal credential nor whole-product certification.

VN Core may be compared with IHE R4 packages for a defined use case, but a shared FHIR R4 base does not create direct compatibility. Any alignment claim must identify package dependencies, canonicals, profile mappings, terminology, CapabilityStatements, and representative tests.

8. Frequently asked questions

Is IHE free?

Yes. The full Technical Framework and every profile are published free of charge at profiles.ihe.net. IHE membership fees only apply to organizations that want to vote on technical decisions or register for the Connectathon.

Do I have to be IHE compliant to sell healthcare software?

Procurement requirements vary by buyer and market. The project corpus contains no Vietnamese legal instrument mandating IHE conformance. If an RFP says “IHE compliant,” it should name the profile, actor, option, version, Integration Statement, and test criteria instead of relying on a generic label.

Does IHE replace HL7 or DICOM?

No. IHE constrains how base standards are used within a profile. XDS.b uses ebXML/Web Services for metadata and treats document content as payload under Affinity Domain policy; a content profile may specify CDA, PDF, or another format. SWF/SWF.b uses the HL7/DICOM transactions stated in the selected Technical Framework version.

Is the Connectathon ever held in Vietnam?

Not in the public evidence reviewed in June 2026. Vietnamese implementation teams can attend Asia-Pacific Connectathon events or other regional IHE testing programs when they have a defined test scope.

What is the difference between an IHE Profile and a FHIR Implementation Guide?

Both are guidance documents that explain how to apply standards to a specific use case. A FHIR IG sits inside the FHIR ecosystem (resources, profiles, ValueSets) and is governed by HL7. An IHE Profile is broader — it can use HL7 v2, v3, CDA, FHIR, DICOM, or SOAP — and is governed by IHE. In practice, the newer IHE profiles (MHD, PIXm) are now published as FHIR IGs to take advantage of the FHIR tooling.

9. References and further reading

References

• IHE International — homepage and history: ihe.net/about_ihe
• IHE Profile Catalog (every profile by domain): profiles.ihe.net
• IHE ITI Technical Framework Volume 2 — XDS.b transaction ITI-41: profiles.ihe.net/ITI/TF/Volume2/ITI-41
• IHE MHD Implementation Guide (FHIR R4): profiles.ihe.net/ITI/MHD
• IHE PaLM domain: profiles.ihe.net/PaLM
• IHE PCC domain: profiles.ihe.net/PCC
• IHE QRPH domain: profiles.ihe.net/QRPH
• IHE General Introduction — Connectathon disclaimer (Appendix F): profiles.ihe.net/GeneralIntro/ch-F
• HL7 International Patient Summary (FHIR IG): hl7.org/fhir/uv/ips
• Law 91/2025/QH15 — Personal Data Protection Law (effective 01/01/2026)
• Decree 356/2025/NĐ-CP — implementing the Personal Data Protection Law (effective 01/01/2026)
• Circular 13/2025/TT-BYT — electronic medical records (effective 21/07/2025)
• Decision 1332/QĐ-BYT — personal health record on VNeID

Read next on hl7.org.vn