The PTH (Pathway) segment carries information about a clinical pathway that is associated with a patient's plan of care. A pathway is a predefined sequence of clinical activities, goals, and problems intended to guide care for a particular condition, and the PTH segment records which pathway has been applied to a patient, the specific instance of that pathway, when it was established, and where it sits in its life cycle. PTH appears alongside the goal (GOL) and problem (PRB) segments inside the patient pathway messages, allowing a sending system to attach goals and problems to the pathway that governs them.
Purpose
The PTH segment exists to identify and track a clinical pathway instance for a patient. It answers four questions: what is being done to the pathway (the action code in PTH-1), which catalog pathway is referenced (PTH-2), which unique occurrence of that pathway applies to this patient (PTH-3), and when the pathway began (PTH-4). The optional life cycle fields then describe the pathway's current status and when that status last changed. Because the pathway acts as an organizing container, the goals and problems that follow it in a message are understood to belong to the pathway instance named here.
Used in
PTH is used in PPP — Patient Pathway (Problem-Oriented) messages. In these messages PTH establishes the pathway context, and the goal and problem segments that follow describe the clinical detail managed under that pathway. The segment is sent whenever a pathway is added, updated, deleted, or its life cycle status changes for a patient.
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (PTH) for sequence, name, data type, and repetition. Length is not published in the javadocs (—); Required and Table # are filled from the HL7 v2.5.1 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| PTH-1 | Action Code | id | — | R | — | HL70287 | Add, update, delete, or change action on the pathway |
| PTH-2 | Pathway ID | ce | — | R | — | — | Coded identifier of the referenced catalog pathway |
| PTH-3 | Pathway Instance ID | ei | — | R | — | — | Unique identifier for this patient's pathway occurrence |
| PTH-4 | Pathway Established Date/Time | ts | — | R | — | — | Date and time the pathway was established |
| PTH-5 | Pathway Life Cycle Status | ce | — | O | — | — | Current life cycle status of the pathway instance |
| PTH-6 | Change Pathway Life Cycle Status Date/Time | ts | — | O | — | — | Date and time the life cycle status last changed |
Most-used fields
PTH-1 (Action Code) is mandatory and drives processing on the receiving side; it tells the engine whether the pathway is being added, updated, deleted, or having its status changed. PTH-2 (Pathway ID) identifies the catalog pathway and is what links the instance back to the organization's pathway definitions. PTH-3 (Pathway Instance ID) is the durable key for the specific occurrence and is essential for correlating later updates to the same pathway. PTH-4 (Pathway Established Date/Time) anchors the pathway in time. The two life cycle fields, PTH-5 and PTH-6, are used by systems that actively manage pathway state transitions.
Version differences (2.3 to 2.8.2)
The PTH segment was introduced with the patient care messages and has remained remarkably stable across versions. The six-field structure — action code, pathway ID, pathway instance ID, established date/time, life cycle status, and change date/time — is consistent from the earlier 2.3.x patient care chapter through 2.5.1 and onward into the 2.7 and 2.8.x releases. The principal evolution across versions is in the underlying data types rather than the field layout: the time-stamp fields PTH-4 and PTH-6 are carried as TS in 2.5.1, while later releases formalize the DTM data type for date/time values. Table bindings and the coded element structure for PTH-2 and PTH-5 are likewise unchanged in substance. Integrators moving between versions should verify date/time formatting expectations rather than worry about added or removed fields.
Common mistakes
A frequent error is omitting or guessing PTH-1, the action code; receivers depend on it to decide whether to create or update a pathway, and an unrecognized value typically causes the message to be rejected. Another mistake is reusing or regenerating the PTH-3 pathway instance ID on updates — the instance ID must remain constant for the life of the pathway so that updates correlate to the original instance. Integrators sometimes populate PTH-5 (life cycle status) without sending PTH-6 (the change date/time), leaving the status change untimestamped. Confusing the catalog Pathway ID (PTH-2) with the per-patient Pathway Instance ID (PTH-3) is also common: PTH-2 names the template, PTH-3 names this patient's run of it. Finally, sending PTH without the surrounding goal and problem groups it is meant to organize produces a structurally valid but clinically empty message.
Examples
Minimal valid segment:
PTH|AD|DIAB-PATH^Diabetes Management^L|PI-88231^^VORRO|20260610103000
Fully-populated segment:
PTH|UP|CHF-PATH^Congestive Heart Failure Pathway^L|PI-99014^^VORRO&1.2.840.114398.1.1&ISO|20260601080000|ACTIVE^Active^HL70316|20260610111500
Annotated breakdown:
PTH|UP|CHF-PATH^Congestive Heart Failure Pathway^L|PI-99014^^VORRO&1.2.840.114398.1.1&ISO|20260601080000|ACTIVE^Active^HL70316|20260610111500
| | | | | |
| | | | | └─ PTH-6 Change Life Cycle Status Date/Time
| | | | └─ PTH-5 Pathway Life Cycle Status
| | | └─ PTH-4 Pathway Established Date/Time
| | └─ PTH-3 Pathway Instance ID
| └─ PTH-2 Pathway ID
└─ PTH-1 Action Code (UP = update)
In-context excerpt — a PPP message adding a pathway with a goal:
MSH|^~&|CAREMGR|VORRO CLINIC|PATHEHR|VORRO HOSP|20260610103000||PPP^PCB^PPP_PCB|MSG00231|P|2.5.1
PID|1||MRN77310^^^VORRO^MR||Tanaka^Hiroshi^^^^^L||19580412|M
PTH|AD|DIAB-PATH^Diabetes Management^L|PI-88231^^VORRO|20260610103000|ACTIVE^Active^HL70316|20260610103000
GOL|AD|20260610103000|GL-50021^^VORRO|HBA1C^HbA1c below 7 percent^L
In-context excerpt — a PPP message updating a pathway's life cycle status with an associated problem:
MSH|^~&|CAREMGR|VORRO CLINIC|PATHEHR|VORRO HOSP|20260610111500||PPP^PCC^PPP_PCC|MSG00232|P|2.5.1
PID|1||MRN77310^^^VORRO^MR||Tanaka^Hiroshi^^^^^L||19580412|M
PTH|UP|DIAB-PATH^Diabetes Management^L|PI-88231^^VORRO|20260601080000|COMPLETED^Completed^HL70316|20260610111500
PRB|UP|20260610111500|E11.9^Type 2 diabetes mellitus^I10|PB-30188^^VORRO
FHIR mapping
No segment-level ConceptMap is published in the v2-to-FHIR IG for PTH. Conceptually, a pathway instance recorded in PTH aligns with a FHIR CarePlan (conceptual) resource: the pathway acts as the organizing plan of care, with PTH-3 corresponding to the CarePlan identifier, PTH-4 to its period start, and PTH-5 to its status. The goals and problems carried alongside PTH in the message map to CarePlan.goal and CarePlan.addresses references rather than to fields within PTH itself.
Engine considerations
When parsing PTH, treat PTH-1 as a controlling field and route the message according to its value before processing the rest of the segment. Persist PTH-3 as the correlation key so that subsequent update and delete actions can be matched to the existing pathway instance rather than creating duplicates. Validate that PTH-2 resolves to a known catalog pathway and reject or quarantine messages that reference unknown pathways. Because PTH-4 and PTH-6 are time stamps, normalize their precision and time-zone handling on ingest to avoid drift when comparing established and status-change times. When producing PTH, ensure the four required fields are always present and that the pathway segment precedes the goal and problem groups it organizes.
How Vorro parses and produces PTH
Vorro parses PTH by mapping each field to a normalized internal pathway record: PTH-1 becomes an action that drives upsert or delete logic, PTH-2 is resolved against the configured pathway catalog, and PTH-3 is stored as the stable instance key used for correlation across the patient's message history. The two time stamps are parsed into normalized date/time values, and PTH-5 is mapped to an internal life cycle status enumeration with PTH-6 retained as the effective change time. On the outbound side, Vorro produces PTH from the same internal model, emitting the required action code, pathway ID, instance ID, and established date/time on every message and adding the life cycle fields when status tracking is enabled. The segment is always sequenced ahead of the GOL and PRB groups it governs so downstream systems receive the pathway context first.
