HL7 PPP Messages: Patient Pathway — Problem-Oriented

HL7 PPP messages communicate problem-oriented care pathway updates — adding, revising, or deleting a structured care plan that is organised around the patient's active clinical problems. A PPP message is sent from the clinical system that owns the pathway to every downstream system that needs to reflect the patient's current trajectory through care, including the problems driving it, the goals tied to each problem, and the orders placed to achieve those goals. This page explains what a PPP message represents, the trigger events that carry it, every segment the message can contain and what each one holds, and how a PPP pathway relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What a PPP message represents

A PPP message — PPP stands for Patient Pathway, Problem-Oriented — communicates a change to a problem-oriented care pathway for a patient. The core of the message is the PTH segment, which carries the pathway identifier, a unique instance identifier, the datetime the pathway was established, and its current lifecycle status. A problem-oriented pathway is a clinical construct that organises care explicitly around the patient's problems: each problem on the pathway can have its own goals and orders, and the pathway as a whole provides the governance context that links those elements into a coherent plan of care. The PPP message propagates any change to that construct so that all participating systems remain synchronised.

The sender is the clinical system or care management application that owns the pathway — most often an EHR or a case management platform. The receivers are the systems that need a current view of the patient's problem-oriented care plan: clinical documentation, order management, care coordination tools, and quality reporting. Because the pathway is the governance record that links problems to goals and goals to orders, the PTH segment — not the individual problem or goal segments — is the authoritative anchor for the entire structure.

When a PPP message is sent

A PPP message is sent whenever a problem-oriented care pathway is added, updated, or deleted. A new admission to a chronic disease management pathway triggers a PPP^PC9. A clinical revision — changing the pathway lifecycle status, linking a new problem, adjusting a goal, or adding an order — triggers a PPP^PCA. Closing or retiring a pathway when the patient is discharged or the pathway is no longer applicable triggers a PPP^PCB.

Trigger events

The PPP message type carries three trigger events:

• PPP^PC9 — Add patient pathway (problem-oriented). Sent when a new problem-oriented pathway instance is established for the patient.
• PPP^PCA — Update patient pathway (problem-oriented). Sent when an existing pathway is revised in any respect — status change, new problem linkages, goal adjustments, order additions, or corrections.
• PPP^PCB — Delete patient pathway (problem-oriented). Sent when a pathway instance is removed or retired.

Receivers should route primarily on the trigger event in MSH-9: a PC9 creates a new record, a PCA updates an existing one keyed on the pathway instance identifier in PTH-3, and a PCB retires it. The action code in PTH-1 reinforces the trigger for downstream processors that inspect segment-level action codes.

Integration topology

The diagram shows the care management system emitting a pathway event through the integration engine to the systems that record and act on it.

{{diagram: care management / EHR → PPP message → integration engine → clinical documentation / order management / quality reporting / care coordination}}

Typical senders: EHR care management module, case management platform, care pathway authoring system.

Typical receivers: clinical documentation system, order management, quality and outcomes reporting, and care coordination tools.

Direction: unidirectional notification from the pathway owner to the systems that consume and display the patient's problem-oriented care plan.

Segments in a PPP message

The PPP_PC9 message opens with a required MSH and PID, then contains one or more repeating PATHWAY groups. Each PATHWAY group opens with the required PTH segment and may carry pathway-level notes, variances, and roles. Within the PATHWAY group, an optional repeating PROBLEM sub-group opens with PRB and may itself contain problem-level notes, variances, roles, an optional repeating GOAL sub-group, and an optional repeating ORDER sub-group. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.

[ ] = optional, { } = repeating

The PATHWAY group repeats so a single PPP message may carry updates to multiple pathways. Within each pathway the PROBLEM sub-group repeats once per linked problem, and within each problem the GOAL and ORDER sub-groups each repeat independently. The canonical segment pages carry the full field-by-field detail.

Sample PPP message

Note. Constructed for illustration. Patient identifiers, pathway identifiers, dates, and names are fictional.

MSH|^~&|CAREPLAN|MERCYGEN|EHR|MERCYGEN|20260604110000||PPP^PC9^PPP_PC9|MSG00053|P|2.5.1
PID|1||MR74312^^^MERCYGEN^MR||PATEL^RAJ^K||19581122|M
PTH|AD|CHF-PATHWAY^Congestive Heart Failure Pathway^L|PTH-2026-00902|20260604110000|AC^Active^HL70305
NTE|1||Pathway initiated following confirmed CHF exacerbation on admission.
ROL|1|AD|CP^Care Coordinator^HL70443|NGUYEN^LINDA^^^^RN
PRB|AD|20260604110000|84114007^Heart failure^SCT|PRB-2026-00902-01||20260604110000|AC^Active^HL70306
NTE|1||Systolic dysfunction confirmed on echocardiogram; LVEF 32%.
GOL|AD|20260604110000|GOAL-FLUID^Achieve euvolemia^L|GOAL-2026-00902-01||20260614|IP^In Progress^HL70480
NTE|1||Target: fluid balance neutral or negative within 72 hours; daily weights.
OBX|1|NM|29463-7^Body weight^LN||94|kg|||||F|||20260604110000
ORC|NW|ORD20260604-011^EHR|||CM
OBR|1|ORD20260604-011^EHR||55208-7^Heart failure management assessment^LN|||20260604110000

What this sample shows

The PPP^PC9 in MSH-9 marks a new problem-oriented pathway being added. PID carries the medical record number MR74312. The PTH segment establishes the pathway: action code AD in PTH-1 confirms this is an add, the coded pathway identity CHF-PATHWAY in PTH-2 names the protocol, instance identifier PTH-2026-00902 in PTH-3 uniquely keys this patient's pathway, PTH-4 stamps the establishment datetime, and PTH-5 records the lifecycle status as active. The NTE provides a pathway-level annotation, and the ROL assigns a care coordinator. Within the PROBLEM sub-group, PRB links an active heart failure problem to the pathway. A GOL captures the euvolemia goal within that problem, annotated with a target timeline and monitoring instruction. An OBX records current body weight as a goal-level observation, and an order group (ORC/OBR) attaches a heart failure management assessment order to the problem.

Working with PPP messages

Key on the pathway instance identifier, not the pathway type

The pathway type in PTH-2 identifies the care protocol — heart failure management, COPD care, diabetes pathway — while PTH-3 is the unique instance identifier that distinguishes this patient's specific instantiation of that pathway. Use PTH-3 as the primary key when storing or updating pathway records. Two patients on the same pathway type each have distinct PTH-3 values; matching on the type code alone will conflate them.

Honour the action code and trigger event together

PTH-1 carries an action code (AD, UP, DE) that mirrors the message trigger event. For a PPP^PCA update, confirm that the pathway instance in PTH-3 already exists before applying the update — an update received without a prior add indicates a missed or out-of-order message. For a PPP^PCB delete, retire rather than hard-delete the record so that historical audit trails remain intact.

Rebuild the hierarchy from the nesting order

The segment sequence is the hierarchy: PTH → PRB → GOL / OBX / ORC-OBR. A new PRB segment begins a new problem, and all GOL, OBX, and ORC segments that follow it belong to that problem until the next PRB or PTH resets the context. Parsers that flatten the message without tracking segment position will lose the linkage between problems, goals, and orders.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key. PPP^PCA update messages are replayed after transport outages; applying the same update twice should leave the pathway record unchanged. Treat the combination of PTH-3 (pathway instance id) and PTH-4 (established datetime) together with the message trigger as the natural business key for change detection.

Vendor variance. The depth of the pathway hierarchy varies considerably across implementations. Some senders populate only PTH and PRB, omitting goals and orders entirely; others send a fully nested structure with observations at every level. Confirm a partner's supported depth against their interface specification rather than assuming the base standard.

FHIR equivalent

A problem-oriented patient pathway corresponds to the FHIR CarePlan resource, with problems mapping to Condition resources and goals to Goal resources. The patient is represented as a Patient resource, and a messaging exchange wraps the Bundle in a MessageHeader.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for PPP_PC9, PPP_PCA, or PPP_PCB and no ConceptMap for the PTH pathway segment. A FHIR CarePlan produced from a PPP message is therefore mapped manually, taking the pathway identifier, status, and established datetime from PTH, deriving contained Condition resources from PRB, and representing linked goals as Goal resources within the CarePlan. The problem-oriented structure — where goals and orders belong explicitly to problems rather than to the pathway as a whole — must be preserved through the addresses reference on each Goal and through activity references within the CarePlan.

Common pitfalls

Pitfall. Keying on the pathway type code instead of the pathway instance identifier. PTH-2 identifies the care protocol and will repeat across many patients; PTH-3 is the unique instance key. Matching updates and deletes on PTH-2 alone will corrupt every patient on the same pathway type.

Pitfall. Losing problem-goal-order linkage by flattening the segment stream. The hierarchy is implicit in segment order. A parser that treats all GOL segments as belonging to the same problem, regardless of which PRB preceded them, will misassign goals and produce a structurally incorrect care plan.

Pitfall. Ignoring PTH-5, the lifecycle status. A pathway with status inactive or on hold carries different clinical implications than an active pathway; discarding the status and treating all received pathways as active will misrepresent the patient's care state.

How Vorro handles PPP messages

Vorro ingests the PPP feed over MLLP or another transport, deduplicates on MSH-10, and routes each pathway event to every subscribed destination in the format that system expects — clinical documentation, care coordination, and quality reporting. Vorro reads the pathway instance identifier and lifecycle status from PTH, reconstructs the problem-goal-order hierarchy from the segment sequence, and links each problem and goal back to the governing pathway through the instance identifier in PTH-3. Where a FHIR destination is configured, Vorro maps the pathway to a CarePlan resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message — and represents problems and goals as Condition and Goal resources nested within it, preserving the problem-oriented linkages that distinguish PPP from a flat care plan.

Related messages

• PPR — the patient problem message that communicates standalone problem additions, updates, and deletions outside the pathway context.
• PPG — the patient pathway goal message for goal-oriented pathway communication in the complementary pathway variant.
• PGL — the patient goal message that communicates goal additions, updates, and deletions independent of a pathway.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms no message map for PPP_PC9/PCA/PCB
• HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for PTH
• HL7 Messaging Standard Version 2.5.1 product brief