IHE — integration profiles built on HL7, DICOM, FHIR

Quick summary

• IHE is a consortium founded in 1998 by RSNA and HIMSS. It now publishes more than 150 profiles organized into domains (ITI, PCC, QRPH, Radiology, Cardiology, PaLM, and more).
• Each profile describes a use case, a list of actors, the transactions exchanged between actors, and a choice of underlying technology (HL7, DICOM, FHIR, SOAP, HTTPS).
• The most common profiles are: XDS.b (HL7 v3-based document sharing), MHD (the FHIR-native successor to XDS), PIX/PDQ, ATNA (audit), BPPC (consent), SWF (radiology workflow), and IPS (patient summary).
• MHD is its own FHIR profile — not a "second implementation" of XDS — and is the recommended choice for greenfield projects.
• Vietnam does not yet have an IHE Affiliate; a few projects already use XDS/MHD patterns implicitly. ATNA is a natural fit for the audit-log obligations under Law 91/2025/QH15 and Decree 356/2025/NĐ-CP.

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 known as IHE Affiliates handle local adaptation and regional testing — IHE Europe, IHE USA, IHE Japan, and IHE Asia-Oceania are the most active. As of April 2026, Vietnam does not yet have an official IHE Affiliate.

IHE produces three core deliverables. First, the Technical Framework — a detailed technical document for each domain, published free of charge at profiles.ihe.net. Second, the profiles themselves — the units that describe specific use cases, with more than 150 published to date. Third, the Connectathon — an annual testing event where vendors prove that their systems actually interoperate.

2. A profile = use case + actors + transactions

Every IHE profile has the same four parts: a use case description, a list of actors (roles), a list of transactions (the exchanges between actors), and a choice of underlying technology. This approach is different from how HL7 writes a resource specification: HL7 describes "what the data looks like," whereas IHE describes "who sends what to whom in which scenario."

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 is the profile for sharing documents across organizations (an Affinity Domain) — the most canonical, most cited profile in national HIE programs. Four actors (Source, Repository, Registry, Consumer) exchange transactions ITI-41, ITI-42, ITI-43, and ITI-18. Underneath, it runs ebXML Registry metadata over SOAP 1.2, with MTOM/XOP for binary attachments. In Vietnam the XDS pattern shows up implicitly in cross-facility referral and discharge projects.

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

PIX solves the problem that one patient ends up with several different identifiers across facilities (a national ID card (CCCD) at the country level, an MRN at every hospital, a BHYT (social health insurance) card number from BHXH (Vietnam Social Security)). The PIX Manager maintains the cross-reference between identifiers. PDQ lets clients query demographic information (name, date of birth, sex, address) over HL7 v2. In Vietnam, PIX/PDQm is the foundation for building a national Patient Master Index keyed on the personal identification number, in line with Circular 13/2025/TT-BYT (Ministry of Health, EMR).

4.3 ATNA — Audit Trail and Node Authentication

ATNA is IHE's shared security and audit profile. It defines the behavior of the Secure Node, Secure Application, and Audit Record Repository actors. Many profiles handling sensitive data require or recommend grouping with ATNA — not every IHE actor must implement it, but it depends on the profile and the security requirements of the Affinity Domain. For Vietnam, ATNA is the natural way to satisfy the audit-log requirements of Law 91/2025/QH15 (Personal Data Protection Law) and Decree 356/2025/NĐ-CP.

4.4 BPPC — Basic Patient Privacy Consents

BPPC describes how a patient signs consent for an Affinity Domain's privacy policy and how other actors verify that consent before accessing documents. BPPC is the conceptual ancestor of the FHIR Consent resource. As Vietnam rolls out the Personal Data Protection Law from January 1, 2026, BPPC is a useful reference pattern when designing a consent management layer — though new projects should look at the more modern FHIR Consent resource first.

4.5 MHD — Mobile access to Health Documents

MHD is the FHIR-based document-sharing profile, created to fix XDS.b's poor fit with mobile and web clients (SOAP is too heavyweight). MHD is not a "second implementation" of XDS — it is its own profile, with its own specification, currently at MHD v4.x on FHIR R4. MHD uses DocumentReference, List, Folder, and SubmissionSet together with Bundle/Binary to represent a document set; DocumentManifest is no longer used in current MHD versions. MHD still aligns with the IHE Document Sharing model, so it can sit next to an existing XDS Affinity Domain via gateway actors. Recommendation: greenfield projects in Vietnam should prefer MHD over XDS.b.

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

SWF describes the diagnostic-imaging workflow: the HIS issues ADT and order messages (HL7 v2) → the RIS schedules and produces the Modality Worklist (DICOM MWL) → the modality pulls the worklist, performs the study, and sends images (DICOM C-STORE) → PACS stores them → the radiologist reads and writes the report. SWF has been supported out of the box for years by international PACS/RIS vendors (Carestream, Fujifilm, GE, Siemens), so it is usually already present in Vietnamese hospitals running first-party PACS.

4.7 XCA / XCA-I — Cross-Community Access

When several XDS Affinity Domains need to interoperate (for example, a Hanoi HIE querying a Ho Chi Minh City HIE), XCA is the gateway profile between communities. XCA-I is the variant for DICOM imaging. This is a federated pattern rather than a centralized one — each region keeps custody of its own data while still allowing lookups when needed.

4.8 PIXm / PDQm — FHIR-native Patient Identity

PIXm and PDQm are the FHIR variants of PIX and PDQ, using a RESTful API instead of HL7 v2 messaging. They expose the $ihe-pix operation on the Patient resource and standard search parameters for demographic queries. They are the recommended choice for any new Patient Master Index in Vietnam that integrates with VN Core FHIR.

4.9 IPS — International Patient Summary

IPS defines the minimum patient-summary dataset for emergency care during international travel: allergies, current medications, problems, immunizations, and the most recent lab results. IPS is a joint product of IHE, HL7 (the FHIR IPS Implementation Guide), CEN, and ISO (standard ISO 27269). It is also a key reference frame for designing Vietnam's personal health record (PHR) on VNeID — Vietnam's national digital identification app — under Decision 1332/QĐ-BYT.

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 is steadily moving toward FHIR as the underlying technology for new profiles: MHD replaces XDS.b for document sharing, PIXm/PDQm replaces PIX/PDQ for identity, mXDE/QEDm offer RESTful data query, and IPS uses FHIR resources directly. These are their own profiles — not "REST versions of the old profiles" — and they have their own Technical Frameworks.

During the transition, most affinity domains run two generations side by side: legacy systems keep XDS.b/PIX/PDQ over SOAP, while new systems use MHD/PIXm/PDQm over REST. IHE provides gateway profiles (for example, the MHD-to-XDS bridge) so data can flow between the two generations. In the long run, most new affinity domains will choose only the FHIR-based profiles.

A quick comparison of XDS.b and MHD:

6. Connectathon — interoperability under fire

The Connectathon is IHE's annual testing event, held in three regions: North America (Cleveland), Europe (rotating between EU countries), and Asia-Oceania (Tokyo, Seoul, Singapore). Vendors bring their systems and run cross-vendor tests against the profiles and actors they have registered. Each test pair is supervised by an IHE test manager; passing results are published in the Product Registry.

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.

For Vietnam, vendors can join the Asia-Pacific Connectathon if they want to build international credentials. Participation runs in the low thousands of US dollars per profile, well within reach of larger vendors.

7. The Vietnamese context and recommendations

Status as of April 2026: Vietnam does not yet have an IHE Affiliate. Provincial HIE programs and the EMR rollout under Circular 13/2025/TT-BYT are taking shape, but no official document yet references IHE profiles. A handful of special-class hospitals have first-party PACS systems with built-in IHE Radiology compliance (SWF, IRWF, REM). A few cross-facility document-sharing pilots are using the XDS/MHD pattern implicitly — they do not claim IHE compliance, but the architecture matches.

Recommendations for 2026 and beyond:

• MHD for any new document-sharing deployment — do not stand up new XDS.b unless integrating with installed legacy systems.
• PIXm/PDQm combined with the VN Core Patient profile for a national Patient Master Index, anchored on the 12-digit personal identification number (CCCD).
• ATNA as the default audit-log framework for any healthcare system handling sensitive data — a clean fit for Law 91/2025 and Decree 356/2025.
• SWF.b for every new HIS-RIS-PACS integration; for hospitals with older PACS, check the vendor's IHE Integration Statement.
• IPS as a reference frame when designing the personal health record on VNeID — note that IPS today is only a reference model; the official VNeID API specification still has to be published by the Ministry of Health and the Ministry of Public Security.
• Consider participating in the Asia-Pacific Connectathon so Vietnamese vendors can earn international credentials and build hands-on interoperability testing experience.

As OmiGroup builds the VN Core FHIR Implementation Guide, we are aligning the clinical profiles (Patient, Encounter, DocumentReference, Composition) so they are directly compatible with MHD, PIXm, and IPS. That way, when the community and regulators eventually pick IHE profiles as the benchmark, adoption will not require starting over.

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?

In the EU and the United States, IHE compliance is a common requirement in hospital and health-network RFPs. In Vietnam, no legal document yet mandates IHE compliance, but provincial HIE programs frequently reference IHE as best practice.

Does IHE replace HL7 or DICOM?

No. IHE uses HL7 and DICOM as building blocks; it does not replace them. An XDS.b profile still uses HL7 v3 and CDA underneath; SWF still uses HL7 v2 and DICOM. IHE solves the question of "how to combine these standards in a specific use case."

Is the Connectathon ever held in Vietnam?

Not as of April 2026. Vietnamese vendors can attend the Asia-Pacific Connectathon, which rotates between Japan, South Korea, and Singapore.

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