HL7 PPR messages communicate patient problem-list updates — the record that a clinical problem has been added, modified, or deleted for a patient. A PPR message carries the full context of a problem entry: the coded problem identity, its onset and lifecycle status, related goals, observations, and orders. This page explains what a PPR message represents, the three trigger events that carry it, every segment the message can contain and what each one holds, and how a PPR problem-list entry relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What a PPR message represents
A PPR message — PPR stands for Patient Problem — communicates a change to a patient's problem list. The core of the message is the PRB segment, which carries the problem details for a single clinical entry: the coded problem identifier, the onset date and time, the problem's current lifecycle status, its priority, and the action being performed on it. The PRB is not a complete clinical narrative — it records the structured fact of a problem and its current state, not the full clinical reasoning behind it.
The sender is the clinical system maintaining the problem list — typically an EHR or care management platform — and the receivers are the systems that need an up-to-date view of the patient's active conditions: care coordination platforms, clinical decision support engines, billing and coding systems, and downstream reporting stores. PPR sits within the clinical trial, care plan, and problem management domain of HL7 v2, alongside the related PPG (patient pathway goal) and PPP (patient pathway problem) messages.
When a PPR message is sent
A PPR message is sent whenever the problem list is modified. A single clinical encounter may produce a sequence of PPR messages — adding a new problem, then updating its status as evaluation progresses, and eventually resolving or deleting it. Each message carries an action code in PRB-1 that tells the receiver what to do with the entry, so the full lifecycle of a problem can be reconstructed from the message stream.
Trigger events
The PPR message type carries three trigger events, one for each lifecycle action on a problem:
PPR^PC1— Add patient problem. Sent when a new problem is placed on the problem list.PPR^PC2— Update patient problem. Sent when an existing problem is modified — its status, priority, onset date, or any other attribute changes.PPR^PC3— Delete patient problem. Sent when a problem is removed from the problem list entirely.
The trigger event in MSH-9 tells the receiver which operation to apply. An AD (add) action code in PRB-1 paired with PC1 creates a new entry; a UP (update) code paired with PC2 modifies an existing one; a DE (delete) code paired with PC3 removes it. Receivers must honour both signals together — do not rely solely on PRB-1 action code or solely on the trigger event.
Integration topology
The diagram shows the EHR or care management system emitting a problem-list event through the integration engine to the systems that record and act on it.
{{diagram: EHR / care management system → PPR message → integration engine → care coordination platform / clinical decision support / billing / reporting}}
Typical senders: EHR problem-list module, care management platform, clinical documentation system.
Typical receivers: care coordination platform, clinical decision support engine, billing and coding system, downstream reporting store, and any system maintaining a patient's longitudinal problem summary.
Direction: unidirectional notification from the problem-list source to the systems that consume and act on it.
Segments in a PPR message
The PPR message is organised into a fixed header followed by one or more PROBLEM groups. Each PROBLEM group opens with the required PRB problem details segment and may contain a rich set of optional sub-groups: pathway data, clinical observations, goals, and related 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.
| Segment | Description |
|---|---|
MSH | Message Header. Opens every PPR message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (PPR^PC1, PPR^PC2, or PPR^PC3), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 to determine whether to add, update, or delete the problem, and deduplicate on MSH-10. |
PID | Patient Identification. Identifies the patient whose problem list is being updated — the identifier list in PID-3, the name in PID-5, and the date of birth in PID-7. Required in every PPR message; a problem-list update is meaningless without patient identity. |
PRB | Problem Details. The heart of the PROBLEM group and the only required clinical segment in it. It carries the action code in PRB-1 (add, update, or delete), the event date and time in PRB-2, the coded problem identifier in PRB-3 (the clinical term, such as a SNOMED CT or ICD code), the unique problem instance identifier in PRB-4, the episode of care identifier in PRB-5, and the problem lifecycle status in PRB-14 (active, resolved, inactive, and so on). Additional fields carry onset date, expected resolution date, certainty, probability, and priority. The PROBLEM group repeats once per problem, so a single PPR message can carry multiple problem entries. |
[{NTE}] | Notes and Comments. Free-text annotations associated with the problem, following the PRB. Optional and repeating; used for clinical narrative that supplements the coded problem identity. |
[{VAR}] | Variance. Records a variance from an expected pathway or protocol at the problem level — the source of the variance, the reason, and a coded classification. Optional and repeating. |
[{ROL}] | Role. Identifies the clinicians who have a defined role in relation to this problem — the responsible provider, the consultant, or the verifying practitioner. Optional and repeating; one ROL per role type. |
[{PTH [{VAR}]}] | PATHWAY sub-group. An optional, repeating pathway block opened by the PTH pathway segment, which links the problem to a clinical pathway or protocol. Each pathway block may carry its own [{VAR}] variance records. |
[{OBX [{NTE}]}] | OBSERVATION sub-group. Clinical observations related to the problem — vital signs, laboratory values, assessments, or any structured finding captured as an OBX. Optional and repeating; each OBX may be followed by its own [{NTE}] comment segments. |
[{GOL [{NTE}] [{VAR}] [{ROL}] [{OBX [{NTE}]}]}] | GOAL sub-group. An optional, repeating goal block opened by the GOL goal segment, which links a care goal to the problem. Each goal block may carry its own notes ([{NTE}]), variances ([{VAR}]), roles ([{ROL}]), and observations ([{OBX [{NTE}]}]). |
[{ORC OBR [{NTE}] [{VAR}] [{OBX [{NTE}]}]}] | ORDER sub-group. An optional, repeating order block opened by ORC (common order) and OBR (observation request), linking orders — diagnostic tests, referrals, or procedures — to the problem. Each order block may carry notes ([{NTE}]), variances ([{VAR}]), and observations ([{OBX [{NTE}]}]). |
[ ] = optional, { } = repeating
The PROBLEM group from PRB through the ORDER sub-group repeats once per problem, so a single PPR message can carry several problem-list entries simultaneously. The canonical segment pages carry the full field-by-field detail.
Sample PPR message
Note. Constructed for illustration. Patient identifiers, problem codes, dates, and names are fictional.
MSH|^~&|EHR|MERCYGEN|CCDPLATFORM|MERCYGEN|20260604093000||PPR^PC1^PPR_PC1|MSG00041|P|2.5.1
PID|1||MR98765^^^MERCYGEN^MR||SMITH^CAROL^A||19720315|F
PRB|AD|20260604093000|44054006^Diabetes mellitus type 2^SNM|PRB-INST-001|EP-2026-001|||||||||||55561003^Active^SNM
NTE|1||Newly diagnosed; initiating dietary counselling and pharmacotherapy.
OBX|1|NM|59261-8^HbA1c [Mass/volume] in Blood^LN||8.4|%|<5.7||||F|||20260601
NTE|1||Confirmed on repeat testing.
What this sample shows
The PPR^PC1 in MSH-9 marks a new problem being added. PID carries the medical record number MR98765. The PRB segment carries the action code AD in PRB-1 (add), the event timestamp in PRB-2, the SNOMED CT code for type 2 diabetes mellitus in PRB-3, the unique problem instance identifier PRB-INST-001 in PRB-4, the episode of care identifier EP-2026-001 in PRB-5, and the lifecycle status Active in PRB-14. The NTE provides a clinical annotation at the problem level. The OBX within the OBSERVATION sub-group carries a supporting HbA1c result, and its own NTE annotates that finding.
Working with PPR messages
Use PRB-1 action code and MSH-9 trigger together
PRB-1 carries the action code (AD add, UP update, DE delete) and MSH-9 carries the trigger event (PC1, PC2, PC3). Both must be consistent and both must drive downstream processing. A receiver that routes only on MSH-9 and ignores PRB-1 will mishandle messages where a single PPR carries a mix of add and update actions in repeated PROBLEM groups.
Idempotency and deduplication
Use MSH-10, the message control id, as the deduplication key, and treat the problem instance identifier in PRB-4 together with the action code in PRB-1 and the event timestamp in PRB-2 as the natural business key for a problem-list operation. Problem feeds are replayed after outages, and treating a repeated control id as a duplicate prevents a replayed add from creating a duplicate problem entry.
Track problem lifecycle through PRB-14
PRB-14 carries the problem lifecycle status — active, resolved, inactive, or another value from the local or standard vocabulary. This field changes across the life of a problem: a PC2 update message that moves PRB-14 from active to resolved is the authoritative signal that the problem is closed. Systems that ignore PRB-14 and rely only on the trigger event will fail to propagate resolutions.
Handle the repeating PROBLEM group
A single PPR message may carry multiple PROBLEM groups — each opened by its own PRB. Process each group independently, matching on PRB-4 (problem instance ID) rather than on message sequence position, so that a reordered or replayed message does not corrupt the problem list.
Vendor variance. The GOAL, ORDER, and OBSERVATION sub-groups within each PROBLEM are optional, and many senders populate only
PRBandNTE. Confirm a partner's field and sub-group usage against their interface specification rather than assuming the full sub-group structure is present.
FHIR equivalent
A patient problem corresponds to the FHIR Condition resource, with the patient as a Patient resource and, for a messaging exchange, a MessageHeader at the head of a Bundle.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for PPR_PC1, PPR_PC2, or PPR_PC3 and no ConceptMap for the PRB problem details segment. A FHIR Condition produced from a PPR message is therefore mapped manually, taking the coded problem identity from PRB-3, the lifecycle status from PRB-14, the onset date from the relevant PRB field, and the clinical status and verification status from local conventions. The problem instance identifier in PRB-4 serves as the source identifier on the Condition resource.
Common pitfalls
Pitfall. Routing on the trigger event alone and ignoring the action code in
PRB-1. A PPR message with aPC2trigger and aDEaction code inPRB-1is a delete embedded within an update exchange — processing it as a plain update leaves a deleted problem active in the receiving system.
Pitfall. Failing to match updates and deletes to an existing problem instance. Receivers that cannot match on
PRB-4(the problem instance ID) create duplicate entries on every PC2 update rather than modifying the existing record.
Pitfall. Ignoring
PRB-14lifecycle status changes. An update message that changes the lifecycle status from active to resolved is the formal closure signal; discarding that field leaves resolved problems incorrectly flagged as active.
Pitfall. Assuming a flat message structure. PPR messages may carry nested GOAL and ORDER sub-groups inside each PROBLEM group. Parsers that do not handle the full segment grammar will silently drop goal and order linkage data.
How Vorro handles PPR messages
Vorro ingests the PPR feed over MLLP or another transport, deduplicates on MSH-10, and routes each problem-list operation to every subscribed destination in the format that system expects — care coordination platforms, clinical decision support engines, and reporting stores. Vorro reads the problem action and lifecycle from PRB fields PRB-1, PRB-3, PRB-4, and PRB-14, applies add, update, and delete operations correctly against the problem instance identifier, and, where a FHIR destination is configured, maps each problem entry to a Condition resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- PPG — the patient pathway goal message that communicates goal-list updates alongside or independently of problem entries.
- PPP — the patient pathway problem message, which links problems explicitly to a clinical pathway.
- ADT — the admission, discharge, and transfer message that triggers encounter context within which problems are often recorded.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for PPR_PC1, PPR_PC2, or PPR_PC3
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for PRB
- HL7 Messaging Standard Version 2.5.1 product brief
