HL7 PPR_PC1 (Patient Problem Message) | Integration Soup HL7 Reference Guide

HL7 PPR_PC1 Patient Problem Message

The patient-care message for adding a problem and its care-plan context.

HL7 message structure PPR_PC1 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

Segment	Name	Required	Repeatable
MSH	Message Header	Yes	No
SFT	Software Segment	No	Yes
PID	Patient Identification	Yes	No
PPR_PC1.PATIENT_VISIT	Patient Visit group	No	No
PV1	Patient Visit	Yes	No
PV2	Patient Visit - Additional Information	No	No
PPR_PC1.PROBLEM	Problem group	Yes	Yes
PRB	Problem Details	Yes	No
NTE	Notes and Comments	No	Yes
VAR	Variance	No	Yes
PPR_PC1.PROBLEM_ROLE	Problem Role group	No	Yes
ROL	Role	Yes	No
VAR	Variance	No	Yes
PPR_PC1.PATHWAY	Pathway group	No	Yes
PTH	Pathway	Yes	No
VAR	Variance	No	Yes
PPR_PC1.PROBLEM_OBSERVATION	Problem Observation group	No	Yes
OBX	Observation/Result	Yes	No
NTE	Notes and Comments	No	Yes
PPR_PC1.GOAL	Goal group	No	Yes
GOL	Goal Detail	Yes	No
NTE	Notes and Comments	No	Yes
VAR	Variance	No	Yes
PPR_PC1.GOAL_ROLE	Goal Role group	No	Yes
ROL	Role	Yes	No
VAR	Variance	No	Yes
PPR_PC1.GOAL_OBSERVATION	Goal Observation group	No	Yes
OBX	Observation/Result	Yes	No
NTE	Notes and Comments	No	Yes
PPR_PC1.ORDER	Order group	No	Yes
ORC	Common Order	Yes	No
PPR_PC1.ORDER_DETAIL	Order Detail group	No	No
PPR_PC1.OBR_SUPPGRP	Obr Suppgrp group	Yes	No
NTE	Notes and Comments	No	Yes
VAR	Variance	No	Yes
PPR_PC1.ORDER_OBSERVATION	Order Observation group	No	Yes
OBX	Observation/Result	Yes	No
NTE	Notes and Comments	No	Yes
VAR	Variance	No	Yes

PPR_PC1 sends patient problem information from one system to another. You see it in patient-care integrations where a point-of-care, care planning, clinical repository, or specialty system needs to tell a downstream system, "this problem is now part of this patient's record."

The message can carry a simple problem-list entry, but the structure also lets the sender attach roles, pathway context, observations, goals, and orders. That makes it more like a care-plan update than a lightweight diagnosis feed.

A small PPR PC1 example

MSH|^~\&|CAREPLAN|CITYHOSP|REPOSITORY|CITYHOSP|20260723141000||PPR^PC1^PPR_PC1|PPR00001|P|2.5.1 PID|1||123456^^^CITYHOSP^MR||Rivera^Maya^^^^^L||19750519|F PV1|1|O|CLINIC^2^A^CITYHOSP||||12345^Nguyen^Anita PRB|AD|20260723140500|HTN^Hypertension^L|PRB-20260723-001|EOC-771|1|20260723090000|||CHRONIC^Chronic^L ROL|1|AD|PP^Primary provider^HL70443|12345^Nguyen^Anita OBX|1|ST|PROBLEMNOTE^Problem note^L||Home BP readings remain above target.||||||F GOL|AD|20260723140500|BPCONTROL^Blood pressure controlled^L|GOL-20260723-001|EOC-771|1|20260723140500|20260823000000

What workflow it represents

A source system has added a clinical problem and wants another application to store, display, route, or reconcile it. The receiver might update a longitudinal problem list, seed a care plan, notify a care-management queue, or link the problem to an open episode of care.

Do not treat PPR_PC1 as a generic diagnosis message. A diagnosis can appear in several HL7 workflows; this one is specifically about the patient-care problem record and the surrounding care-plan material.

How to read the structure

The header is the usual MSH, optional SFT, required PID, and optional visit context through PV1 and PV2.

The required repeating PROBLEM group starts with PRB. PRB carries the action code, action date/time, problem identifier, problem instance identifier, episode, priority, established date, classification, status, onset, sensitivity, and similar problem-list detail.

Inside each problem, optional NTE, VAR, and ROL add comments, variances, and responsible roles. Optional PTH ties the problem to a pathway. Optional OBX, GOL, and ORC groups let the sender include supporting observations, linked goals, and orders.

Implementation traps

The action code matters. A receiving system should distinguish add, update, correction, and delete-style actions instead of blindly overwriting the problem list.

Preserve the PRB problem instance ID. It is the durable handle that lets later patient-care messages update the same problem without relying on display text or local code descriptions.

Be clear about scope. If the receiver only supports PRB-level problem details, reject or safely ignore unsupported goal, order, pathway, and observation groups by profile, not by accident.

Reference notes

HL7 v2 patient-care material describes the PPR patient problem message as a way to send problems between applications, commonly from point-of-care systems to repositories. In v2.5.1 the structure centers on required PID and repeating PRB-led PROBLEM groups with optional pathway, observation, goal, role, variance, and order context.