All posts

IHE profiles in the Jam platform — what they mean in practice

AJ
AJ FHIR Platform
25 March 2026 · 11 min read
11 min read
IHE ATNA PDQm PIXm MHD mCSD SMART BALP Standards

Why IHE profiles matter

IHE (Integrating the Healthcare Enterprise) profiles define exactly how two systems should exchange a specific type of clinical data. They eliminate ambiguity in standards like FHIR and HL7v2 by specifying which fields are required, what vocabularies must be used, and what the expected response looks like.

When a vendor claims “FHIR R4 support,” that tells you almost nothing about interoperability. When they claim “ITI-78 PDQm conformant,” you know exactly what patient query request/response looks like and can write a conformance test in an afternoon.

The profiles JamBridge implements

ITI-20 — Audit Trail and Node Authentication (ATNA)

Every transaction in JamBridge generates an ATNA AuditEvent. The event is written asynchronously via RFC 5425 TLS syslog to syslog-ng, and as a BALP FHIR AuditEvent to HAPI FHIR. ATNA is the foundation of HIPAA §164.312 and GDPR Art. 30 compliance — without it, you cannot prove who accessed what data and when.

ITI-78 — Patient Demographics Query (PDQm)

JamMPI exposes an ITI-78 conformant Patient search endpoint. Any FHIR client can query for patients by name, date of birth, or identifier using standard FHIR search parameters. The response includes golden record references via Patient.link.

ITI-83 — Patient Identifier Cross-Referencing (PIXm)

JamMPI’s Patient/$match operation is ITI-119 conformant (the newer profile). For systems that expect the older ITI-83 $ihe-pix operation, JamMPI also supports it — returning all known identifiers for a golden patient across all connected facilities.

ITI-90 — Mobile Care Services Discovery (mCSD)

JamFR exposes an ITI-90 conformant Organization search endpoint. JamBridge calls this on every message to resolve facility codes. Auto-provisioning creates a new Organization resource when JamBridge receives a message from an unknown MSH-4 facility code.

ITI-65/66/67/68 — Mobile Health Documents (MHD)

JamSHR implements the full MHD transaction set: Provide Document Bundle (ITI-65), Update Document Metadata (ITI-66), Find Document References (ITI-67), and Retrieve Document (ITI-68). Clinical documents generated by JamBridge — discharge summaries from MDM messages — are stored and discoverable via MHD.

BALP — Basic Audit Log Patterns

BALP is the FHIR-native successor to ATNA syslog. Every transaction generates a structured AuditEvent resource in HAPI FHIR that can be queried by patient, actor, time window, or event type. Useful for patient-facing consent dashboards that show a patient exactly who has accessed their data.

Filed under Standards  |  IHE ATNA PDQm PIXm MHD mCSD SMART BALP Standards
Next Migrating from OpenHIM to JamBridge — a practical 8-week plan