HL7 PPG Messages: Patient Pathway — Problem-Oriented

HL7 PPG messages communicate goal-oriented care pathway updates — adding, revising, or deleting a patient pathway together with the problems, goals, and orders that belong to it. A PPG message is sent from the clinical system that owns the care plan to every downstream system that needs to track the patient's trajectory through care. This page explains what a PPG message represents, the trigger events that carry it, every segment the message can contain and what each one holds, and how a PPG pathway relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What a PPG message represents

A PPG message — PPG stands for Patient Pathway, Problem-Oriented — communicates a change to a structured 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 pathway is a clinical construct that links a set of related problems, goals, and orders into a coherent plan of care; the PPG message propagates any change to that construct so that all participating systems stay synchronized.

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 care plan: clinical documentation, order management, quality reporting, and coordination tools. 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 PPG message is sent

A PPG message is sent whenever a care pathway is added, updated, or deleted. A new admission to a stroke care pathway triggers a PPG^PC6. A clinical revision — changing the pathway lifecycle status, linking a new problem, or adjusting a goal — triggers a PPG^PC7. Closing or retiring a pathway when the patient is discharged or the pathway is no longer applicable triggers a PPG^PC8.

Trigger events

The PPG message type carries three trigger events:

• PPG^PC6 — Add patient pathway (problem-oriented). Sent when a new pathway instance is established for the patient.
• PPG^PC7 — Update patient pathway (problem-oriented). Sent when an existing pathway is revised in any respect — status change, new linkages, or corrections.
• PPG^PC8 — 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 PC6 creates a new record, a PC7 updates an existing one keyed on the pathway instance identifier in PTH-3, and a PC8 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 → PPG 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 care plan.

Segments in a PPG message

The PPG_PC6 message is organised around a mandatory PATHWAY group that opens with PTH and may contain pathway-level notes, variances, and roles, followed by an optional repeating PROBLEM sub-group. Each problem may itself contain observations, goals, and orders. 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 PPG 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 PPG message

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

MSH|^~&|CAREPLAN|MERCYGEN|EHR|MERCYGEN|20260604083000||PPG^PC6^PPG_PC6|MSG00047|P|2.5.1
PID|1||MR98201^^^MERCYGEN^MR||SMITH^LAURA^E||19670314|F
PTH|AD|STROKE-PATHWAY^Acute Stroke Care Pathway^L|PTH-2026-00841|20260604083000|AC^Active^HL70305
NTE|1||Pathway initiated on admission to neurology unit.
ROL|1|AD|CP^Care Coordinator^HL70443|JOHNSON^MARY^^^^RN
PRB|AD|20260604083000|230690007^Cerebrovascular accident^SCT|PRB-2026-00841-01||20260604083000|AC^Active^HL70306
NTE|1||Ischemic stroke confirmed by CT.
GOL|AD|20260604083000|GOAL-MOBILITY^Restore independent mobility^L|GOAL-2026-00841-01||20260604|IP^In Progress^HL70480
NTE|1||Target: ambulation without assistance within 14 days.
OBX|1|NM|59408-5^Oxygen saturation^LN||97|%|95-100||||F|||20260604083000
ORC|NW|ORD20260604-001^EHR|||CM
OBR|1|ORD20260604-001^EHR||71552-6^Stroke rehabilitation assessment^LN|||20260604083000

What this sample shows

The PPG^PC6 in MSH-9 marks a new pathway being added. PID carries the medical record number MR98201. The PTH segment establishes the pathway: action code AD in PTH-1 confirms this is an add, the coded pathway identity STROKE-PATHWAY in PTH-2 names the protocol, instance identifier PTH-2026-00841 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 ischemic stroke problem to the pathway. A GOL captures the mobility restoration goal within that problem, annotated with a target. An OBX records oxygen saturation as a problem-level observation, and an order group (ORC/OBR) attaches a stroke rehabilitation assessment order to the problem.

Working with PPG messages

Key on the pathway instance identifier, not the pathway type

The pathway type in PTH-2 identifies the care protocol — stroke care, hip replacement, sepsis bundle — 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 stroke pathway 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 PPG^PC7 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 PPG^PC8 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. PPG^PC7 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. Confirm a partner's supported depth against their interface specification rather than assuming the base standard.

FHIR equivalent

A patient pathway corresponds to the FHIR CarePlan resource, with problems mapping to Condition resources, goals to Goal resources, and linked orders to ServiceRequest or MedicationRequest 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 PPG_PC6, PPG_PC7, or PPG_PC8 and no ConceptMap for the PTH pathway segment. A FHIR CarePlan produced from a PPG message is therefore mapped manually, taking the pathway identifier, status, and established datetime from PTH, deriving contained Condition and Goal resources from PRB and GOL respectively, and representing linked orders as 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 PPG messages

Vorro ingests the PPG 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, goals, and orders as Condition, Goal, and ServiceRequest resources nested within it.

Related messages

• PPR — the patient problem message that communicates standalone problem additions, updates, and deletions outside the pathway context.
• PPP — the patient pathway message for pathway-problem-oriented 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 PPG_PC6/PC7/PC8
• HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for PTH
• HL7 Messaging Standard Version 2.5.1 product brief