HL7 PTR messages return care-pathway records organized around problems — the response a clinical system sends back when it is queried for a patient's problem-oriented pathways. A PTR message answers a problem-oriented pathway query, carrying the pathway records that match the query along with the goals, orders, and observations attached to each problem on the pathway. This page explains what a PTR message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how a PTR response relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What a PTR message represents
A PTR message — PTR stands for Patient Pathway, Problem-Oriented, Response — communicates the result of a problem-oriented pathway query. The core of the message is the PTH segment, which carries the pathway data for a single care pathway: the action being reported in PTH-1, the coded pathway identifier in PTH-2, the pathway instance id in PTH-3, the date and time the pathway was established in PTH-4, and the pathway lifecycle status in PTH-5. The PTH is the container the response returns — each pathway groups together the problems being managed on it.
PTR is a query-response message: it travels back to the system that asked for the data, not as an unsolicited notification. The sender is the system that holds the pathway records — typically a clinical or care-management application — and the receiver is the application that issued the query. Because PTR is the response half of a request/response pair, its MSA and QAK segments form the acknowledgement: they tell the requester whether the query succeeded and what data, if any, the response carries.
When a PTR message is sent
A PTR message is sent in reply to a problem-oriented pathway query — it is never unsolicited. The querying system asks for the pathways associated with a patient or a problem, and the responding system returns the matching pathway records, each with its problems, goals, orders, and observations, inside a single PTR message.
Trigger event
The PTR message type carries a single trigger event:
PTR^PCF– Patient pathway (problem-oriented) response.
Because PTR has one trigger event, the receiver's handling turns on the contents of QAK and the returned PTH pathways — the query response status and the pathway records themselves — rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the requesting system issuing a pathway query and the responding system returning the matching pathways through the integration engine.
{{diagram: querying system → pathway query → integration engine → care-management system → PTR response → querying system}}
Typical senders: clinical or care-management application, problem-list/pathway repository, EHR module that holds care pathways.
Typical receivers: the application that issued the query — a clinical workstation, care-coordination tool, or reporting system.
Direction: solicited response returned to the system that issued the problem-oriented pathway query.
Segments in a PTR message
The PTR_PCF message opens with a query-response envelope — MSH, MSA, an optional ERR, QAK, QRD, and an optional QRF — followed by one or more PATIENT groups. Each patient group opens with PID and contains one or more PATHWAY groups, each opening with PTH and containing a PROBLEM subgroup of PRB records with their GOAL and ORDER detail. 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.
| Segment | Description |
|---|---|
MSH | Message Header. Opens every PTR message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (PTR^PCF), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 and deduplicate on MSH-10. |
MSA | Message Acknowledgment. Acknowledges the query that prompted the response. MSA-1 carries the acknowledgment code and MSA-2 echoes the control id of the original query, so the requester can match the response to its request. Required. |
[{ERR}] | Error. Reports any error encountered while processing the query — error location, code, and severity. Optional and repeating; present only when the query did not complete cleanly. |
QAK | Query Acknowledgment. Reports the query response status — QAK-2 indicates whether data was found, no data was found, or the query failed — and echoes the query tag. Required, and read together with MSA to decide whether the response carries usable pathway data. |
QRD | Query Definition. Echoes the original query parameters — the query date/time, what was requested, and the subject filter — so the response is self-describing. Required. |
[QRF] | Query Filter. Carries the additional filter criteria applied to the query, when the request narrowed the result set beyond the base QRD. Optional. |
PID | Patient Identification. Opens each PATIENT group and identifies the patient the pathways belong to — the identifier list in PID-3, the name in PID-5. Required, and the patient group repeats once per patient in the response. |
[{NTE}] | Notes and Comments. Patient-level notes that apply across the patient's pathways. Optional and repeating. |
PTH | Pathway. Opens each PATHWAY group and is the container the response returns. It records the pathway as it stands: the action code in PTH-1, the coded pathway identifier in PTH-2, the pathway instance id in PTH-3, the date and time the pathway was established in PTH-4, and the pathway lifecycle status in PTH-5. Required, and the pathway group repeats once per pathway. |
[{NTE}] | Notes and Comments. Notes relative to the pathway, following the PTH. Optional and repeating. |
[{VAR}] | Variance. Records a deviation from the expected pathway — what varied and when. Optional and repeating. |
[{ROL}] | Role. The people and their roles on the pathway — the responsible provider or care-team member. Optional and repeating. |
[{PRB}] | Problem Detail. Opens each PROBLEM subgroup and carries a problem being managed on the pathway — the problem id, onset, and status. Optional and repeating; each problem brings its own goals, orders, and observations. |
[{NTE}] | Notes and Comments. Notes relative to the problem, following the PRB. Optional and repeating. |
[{VAR}] | Variance. A deviation recorded against the problem. Optional and repeating. |
[{ROL}] | Role. The people and roles attached to the problem. Optional and repeating. |
[{GOL}] | Goal Detail. Opens each GOAL subgroup and carries a goal set against the problem — the goal id, target, and status. Optional and repeating; each goal can carry its own notes, variances, roles, and observations. |
[{NTE}] | Notes and Comments. Notes relative to the goal. Optional and repeating. |
[{VAR}] | Variance. A deviation recorded against the goal. Optional and repeating. |
[{ROL}] | Role. The people and roles attached to the goal. Optional and repeating. |
[{OBX}] | Observation/Result. Observations recorded against the goal — measurements that track progress toward it — each optionally followed by its own NTE. Optional and repeating. |
[{ORC}] | Common Order. Opens each ORDER subgroup under the problem and ties an order to the problem being managed. Optional and repeating; each order can carry its detail, notes, variances, and observations. |
[OBR] | Observation Request. The order detail for the ORC — what was ordered against the problem. Optional. |
[{NTE}] | Notes and Comments. Notes relative to the order. Optional and repeating. |
[{VAR}] | Variance. A deviation recorded against the order. Optional and repeating. |
[{OBX}] | Observation/Result. Observations tied to the order, each optionally followed by its own NTE. Optional and repeating. |
[{OBX}] | Observation/Result. Problem-level observations recorded directly against the PRB rather than a goal or order, each optionally followed by its own NTE. Optional and repeating. |
[ ] = optional, { } = repeating
The PATIENT group repeats once per patient and the PATHWAY group within it repeats once per pathway, so a single PTR message can return several pathways — each with its problems, goals, orders, and observations — for one or more patients. The canonical segment pages carry the full field-by-field detail.
Sample PTR message
Note. Constructed for illustration. Patient identifiers, pathway ids, dates, and names are fictional.
MSH|^~&|CAREMGR|MERCYGEN|EHR|MERCYGEN|202006040900||PTR^PCF^PTR_PCF|MSG00021|P|2.5.1
MSA|AA|QRY00017
QAK|Q017|OK
QRD|202006040900|R|I|Q017|||10^RD|MR12345^^^MERCYGEN^MR|PTH|||
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
PTH|AD|DM2CP^Diabetes Type 2 Care Pathway^L|PW7788|202005010800|active
PRB|AD|202005010800|E1142^Type 2 diabetes with diabetic polyneuropathy^I10|PR3344||||202005010800
GOL|AD|202005010800|HBA1C7^HbA1c below 7 percent^L|GL5566||||active
OBX|1|NM|4548-4^Hemoglobin A1c^LN||7.8|%|<7.0|H|||F
ORC|RE|ORD901^EHR|FIL901^CAREMGR
OBR|1|ORD901^EHR|FIL901^CAREMGR|4548-4^Hemoglobin A1c^LN
What this sample shows
The PTR^PCF in MSH-9 marks a problem-oriented pathway response. MSA returns AA and echoes the query control id QRY00017, and QAK reports OK for query tag Q017 — together confirming the query succeeded and data was found. QRD echoes the query that asked for pathways (PTH) for medical record MR12345. PID identifies the patient, and PTH returns the pathway: the Diabetes Type 2 Care Pathway (PTH-2), instance PW7788 (PTH-3), established 2020-05-01 (PTH-4), with lifecycle status active (PTH-5). The PRB carries the managed problem, the GOL sets the HbA1c goal, the OBX reports the current HbA1c of 7.8% flagged high, and the ORC/OBR carry the order placed against the problem.
Working with PTR messages
Read the response status before the data
Check MSA and QAK before parsing any pathway. MSA-1 says whether the query was accepted and QAK-2 says whether data was found — a clean acknowledgment with a no-data status means the patient has no matching pathways, not that the message failed. Branch on the query response status rather than assuming a PTH is always present.
Walk the nesting in order
A PTR response nests deeply: PATIENT contains PATHWAY, PATHWAY contains PROBLEM, and each problem can carry goals, orders, and observations. Parse by following the group boundaries — a new PID opens a new patient, a new PTH opens a new pathway, and a new PRB opens a new problem — rather than treating the segments as a flat list, so an OBX is attributed to the goal, order, or problem it actually belongs to.
Match the response to the query
MSA-2 echoes the control id of the original query and QAK-1 echoes the query tag, so use them to correlate the response with the request that is still open on the querying side. Treat a response whose echoed identifiers do not match an outstanding query as unsolicited and handle it accordingly.
Pathway lifecycle status
PTH-5 records the pathway's lifecycle status — whether it is active, on hold, or completed. Surface this alongside the pathway rather than assuming every returned pathway is current, since a problem-oriented query can return historical pathways as well as the one in force.
Vendor variance. The PROBLEM subgroup's goals, orders, and observations are all optional, so some systems return a fully populated pathway with goals and tracking observations while others return only the
PTHandPRBskeleton. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A problem-oriented care pathway corresponds conceptually to the FHIR CarePlan resource, so a PTR response maps to a Bundle of CarePlan resources — one per returned pathway — with the patient as a Patient resource and, for a messaging exchange, a MessageHeader at the head of the Bundle.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for PTR_PCF and no ConceptMap for the PTH pathway segment. A FHIR Bundle of CarePlan resources produced from a PTR message is therefore mapped manually, taking the pathway identifier, established date, and lifecycle status from PTH, the managed conditions from each PRB, and the goals and orders from the GOL and ORC detail beneath them.
Common pitfalls
Pitfall. Parsing the pathway before checking the query response status. A clean
MSA/QAKwith a no-data status carries noPTHat all; reading for a pathway first treats an empty but successful response as a parse failure.
Pitfall. Flattening the nested groups. Attributing every
OBXto the pathway instead of the goal, order, or problem it sits under loses the structure that makes the response meaningful.
Pitfall. Assuming a fixed date-time precision. Some senders stamp
PTH-4asYYYYMMDDand others as a full timestamp with an offset; do not assume a timezone — normalize on ingest.
How Vorro handles PTR messages
Vorro receives the PTR response over MLLP or another transport, correlates it to the open query through the echoed control id in MSA and the query tag in QAK, and routes the returned pathways to every subscribed destination in the format that system expects. Vorro reads the pathway identifier, established date, and lifecycle status from PTH, walks the nested PROBLEM, GOAL, and ORDER groups to keep each goal and observation attributed to the right problem, and, where a FHIR destination is configured, maps each pathway to a CarePlan resource within a Bundle — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- PPP — the problem-oriented pathway update/unsolicited message that conveys pathway changes.
- PPG — the patient pathway (goal-oriented) message that organizes care around goals rather than problems.
- PRR — the patient problem response that returns problem records to a problem query.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for PTR_PCF
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for PTH
- HL7 Messaging Standard Version 2.5.1 product brief
