HL7 PRR messages return the answer to a problem query — the set of patient problem-list records that match a query a requesting system sent. A PRR message is the response half of a query/response pair: a system asks for a patient's problems, and the system that holds the problem list replies with a PRR carrying the matching records, each one a problem with its action code, identity, and lifecycle status. This page explains what a PRR message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how a PRR response relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What a PRR message represents
A PRR message — PRR stands for Patient Problem Response — communicates the result of a problem query back to the system that issued it. The core of the message is the PRB segment, which carries the detail for a single problem on the patient's problem list: the action being reported in PRB-1, the date and time of that action in PRB-2, the coded problem identifier in PRB-3, the problem instance identifier in PRB-4, and the problem's lifecycle status in PRB-14. Each problem returned is one PRB and its surrounding clinical detail.
The PRR is built on a query/response envelope. It does not stand alone — it answers an inbound query, and so it carries an acknowledgement of that query alongside the data. The sender is the system that owns the problem list (an EHR or a clinical repository), and the receiver is whichever system asked. Because the message is a response, the MSA and QAK segments — which report whether the query succeeded, found nothing, or errored — are as load-bearing as the PRB data itself: a receiver reads the acknowledgement first to learn whether any problems were returned at all.
When a PRR message is sent
A PRR message is sent in direct response to a patient problem query. The requesting system issues a query for a patient's problems, and the system holding the problem list answers with a single PRR that echoes the query definition and carries every matching problem record. One query yields one response; the response may contain no problems (a not-found result), one, or many, grouped by patient.
Trigger event
The PRR message type carries a single trigger event:
PRR^PC5– Patient problem response.
Because PRR has one trigger event, the receiver's handling turns on the query acknowledgement in QAK and the problem detail in PRB — the response status, the query tag, and the returned problems — rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the requesting system issuing a problem query and the problem-list owner answering with a PRR through the integration engine.
{{diagram: requesting system → problem query → integration engine → problem-list owner (EHR / clinical repository) → PRR response → requesting system}}
Typical senders: EHR problem-list module, clinical data repository, problem registry.
Typical receivers: the application that issued the query — a clinical decision-support system, a care-coordination platform, or a reporting tool.
Direction: the response leg of a synchronous query/response exchange, returning to the system that issued the original problem query.
Segments in a PRR message
The PRR_PC5 message opens with the acknowledgement and query-echo segments, then carries one or more PATIENT groups, each beginning with PID. Within a patient, one or more PROBLEM groups each open with PRB and may carry nested PATHWAY, ORDER, OBSERVATION, and GOAL groups. 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 PRR message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (PRR^PC5), 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 Acknowledgement. Acknowledges the original query message. MSA-1 carries the acknowledgement code and MSA-2 echoes the control id of the query being answered, tying the response to the request. Required. |
[{ERR}] | Error. Detail on any error encountered processing the query — error code and location. Optional and repeating; present when the acknowledgement reports a problem. |
QAK | Query Acknowledgement. Reports the outcome of the query: the query response status in QAK-2 (OK data found, NF no data found, AE application error, AR application reject) and the query tag in QAK-1 that correlates the response with the request. Required — a receiver reads QAK-2 first to learn whether any problems follow. |
QRD | Query Definition. Echoes the original query definition back to the requester — the query date/time, the quantity limited request, and the who/what subject filter that selected the patient and problems. Required. |
[QRF] | Query Filter. The additional filter criteria the original query applied, echoed back. Optional; present when the query carried filter parameters. |
PID | Patient Identification. Opens each patient group and identifies the patient whose problems follow — the identifier list in PID-3, the name in PID-5. Required, and the patient group repeats so one response can carry problems for more than one patient. |
[{NTE}] | Notes and Comments. Notes that apply to the patient as a whole, following PID. Optional and repeating. |
[{VAR}] | Variance. Records a variance associated with the patient. Optional and repeating. |
PRB | Problem Details. The core of the message and the segment that opens each problem group. It records the problem as the problem list holds it: the action code in PRB-1 (add, update, delete, link, unlink, unchanged), the action date/time in PRB-2, the coded problem identifier in PRB-3, the problem instance identifier in PRB-4 that uniquely keys this problem on the list, and the problem lifecycle status in PRB-14 (for example active or resolved). Required, and the problem group repeats once per problem returned. |
[{NTE}] | Notes and Comments. Notes relative to the problem, following the PRB. Optional and repeating. |
[{VAR}] | Variance. A variance associated with the problem. Optional and repeating. |
[{ROL}] | Role. The people in a role relative to the problem — for example the provider who recorded or owns it. Optional and repeating. |
[{PTH}] | Pathway. Opens the optional PATHWAY group: the clinical pathway or protocol the problem is being managed under. Optional and repeating; each PTH may carry its own [{VAR}] variance segments. |
[{ORC}] | Common Order. Opens the optional ORDER group: an order placed in connection with the problem. Optional and repeating; each ORC may be followed by an optional OBR order detail and its own [{NTE}] notes and [{VAR}] variances. |
[{OBX}] | Observation/Result. Opens the optional OBSERVATION group: an observation tied to the problem, such as a severity score. Optional and repeating; each OBX may carry its own [{NTE}] notes. |
[{GOL}] | Goal Detail. Opens the optional GOAL group: a care goal set for the problem. Optional and repeating; each GOL may carry its own [{NTE}] notes and [{VAR}] variances. |
[ ] = optional, { } = repeating
The patient group from PID onward repeats, and within each patient the problem group from PRB onward repeats, so a single PRR message can return many problems across one or more patients. The canonical segment pages carry the full field-by-field detail.
Sample PRR message
Note. Constructed for illustration. Patient identifiers, problem codes, dates, and names are fictional.
MSH|^~&|EHR|MERCYGEN|CDS|MERCYGEN|202006150900||PRR^PC5^PRR_PC5|MSG00021|P|2.5.1
MSA|AA|QRY00017
QAK|Q00017|OK|PC5
QRD|202006150900|R|I|Q00017|||10^RD|MR12345^^^MERCYGEN^MR|PRB|||
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
PRB|AD|202006120800|44054006^Diabetes mellitus type 2^SCT|PRB1001|||202006120800||A
PRB|AD|202005031000|38341003^Hypertensive disorder^SCT|PRB1002|||202005031000||A
What this sample shows
The PRR^PC5 in MSH-9 marks a patient problem response. MSA acknowledges the original query with AA and echoes its control id QRY00017. QAK reports query tag Q00017 with status OK — data was found — so problem records follow. QRD echoes the query definition that selected patient MR12345 and the PRB record type. PID opens the patient group for MR12345. The two PRB segments return two active problems: type 2 diabetes mellitus (PRB-3, instance PRB1001 in PRB-4) and a hypertensive disorder (instance PRB1002), each added (AD in PRB-1) with its action date/time and an active lifecycle status (A) in PRB-14.
Working with PRR messages
Read the acknowledgement before the data
A PRR is a response, so read QAK and MSA before parsing problems. QAK-2 tells you whether the query found data (OK), found none (NF), or failed (AE / AR); a NF response is valid and carries no PRB groups, so do not treat an empty problem list as an error. Correlate the response with the original request through the query tag in QAK-1 and the echoed control id in MSA-2.
Key problems by instance id, not by code
The problem instance identifier in PRB-4 uniquely keys a problem on the list; the coded problem in PRB-3 does not. Two distinct problems can share a diagnosis code, and one problem can be updated over time while keeping its instance id. Match incoming problems on PRB-4 so that an update lands on the right record rather than creating a duplicate.
Apply the action code
PRB-1 carries the action this record reports — add, update, delete, link, unlink, or unchanged. A PRR returned from a query is typically a snapshot of current problems, but the action code still governs how each PRB is applied; honour it rather than blindly inserting every problem as new.
Read the lifecycle status
PRB-14 records whether a problem is active, resolved, or otherwise in its lifecycle. Surface this rather than discarding it — a resolved problem returned in the response is part of the history and should not be displayed as a current active problem.
Vendor variance. The nested PATHWAY, ORDER, OBSERVATION, and GOAL groups under each problem are all optional, so some systems return only the bare
PRBrecords while others attach goals, orders, and observations to every problem. Confirm a partner's field and group usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A patient problem response corresponds, conceptually, to a FHIR Bundle of type searchset containing one Condition resource per returned problem, 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 PRR_PC5 and no ConceptMap for the PRB problem-detail segment. A FHIR representation produced from a PRR message is therefore mapped manually: each PRB becomes a Condition, taking the coded problem from PRB-3 into Condition.code, the instance identifier from PRB-4 into Condition.identifier, and the lifecycle status from PRB-14 into Condition.clinicalStatus, with the whole set gathered into a searchset Bundle that answers the original query.
Common pitfalls
Pitfall. Parsing problems before checking
QAK-2. ANF(no data found) response is a valid answer with noPRBgroups; treating the absence of problems as a parse error or an outage masks a legitimate empty result.
Pitfall. Matching problems on the diagnosis code in
PRB-3instead of the instance id inPRB-4. Two problems can share a code, so keying on the code merges distinct problems or misapplies an update.
Pitfall. Displaying every returned
PRBas an active problem. Ignoring the lifecycle status inPRB-14surfaces resolved or historical problems as current, distorting the problem list.
How Vorro handles PRR messages
Vorro receives the PRR response over MLLP or another transport, reads the query acknowledgement in QAK and MSA to correlate the response with the original query and confirm whether data was returned, and routes each problem to every subscribed destination in the format that system expects. Vorro keys each problem on the instance identifier in PRB, applies the action code, carries the lifecycle status through, and, where a FHIR destination is configured, maps each problem to a Condition resource gathered into a searchset Bundle — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- PPR — the patient problem message that reports problem updates, which a PRR query response returns against.
- PPG — the patient pathway (goal-oriented) message in the patient-care problem family.
- PPP — the patient pathway (problem-oriented) message in the patient-care problem family.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for PRR_PC5
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for PRB
- HL7 Messaging Standard Version 2.5.1 product brief
