HL7 PGL messages communicate care-plan goal updates — the record that a clinical goal has been added, revised, or removed for a patient. A PGL message is sent from the system that manages care plans to the systems that record and act on goal changes. This page explains what a PGL message represents, the trigger events that carry it, every segment the message can contain and what each one holds, and how a PGL goal relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What a PGL message represents
A PGL message — PGL stands for Patient Goal — communicates that a care-plan goal has been created, updated, or deleted for a patient. The core of the message is the GOL segment, which carries the goal data: the action being taken, the datetime of that action, the goal type and instance identifiers, the lifecycle status, and the target datetime by which the goal is expected to be achieved. The GOL is the authoritative record of the goal state at the time the message is sent, not a complete audit trail of every prior change.
The sender is the care-plan management system or the clinical application that records goals, and the receivers are the systems that need to reflect the goal — most often the EHR's care-plan module, case-management tools, and any downstream analytics or care-coordination platforms. PGL sits alongside the problem-list (PPR) and pathway (PPG) messages in the HL7 v2 patient care family. Where a PPR message records a clinical problem the patient has and a PPG message records a structured care pathway, a PGL message records an explicit, measurable goal the care team is working toward — such as a target blood-pressure value, a rehabilitation milestone, or a patient-education objective.
When a PGL message is sent
A PGL message is sent whenever a goal's lifecycle changes: when it is first set, when the goal, its target, or its status is revised, or when the goal is removed from the care plan. Each message carries one or more GOAL groups, so a single transmission can update several goals simultaneously. The action code in GOL-1 distinguishes the operation on each goal, so a single PGL message can add one goal, update a second, and delete a third in a single exchange.
Trigger events
The PGL message type carries three trigger events, one for each lifecycle operation:
PGL^PC6— Add patient goal. Sent when a new goal is created on the care plan.PGL^PC7— Update patient goal. Sent when an existing goal is revised — its target, status, or any associated data changes.PGL^PC8— Delete patient goal. Sent when a goal is removed from the care plan.
Because all three trigger events share the same PGL message structure, receivers route on the trigger code in MSH-9 and confirm the per-goal action in GOL-1 before processing.
Integration topology
The diagram shows the care-plan system emitting a goal lifecycle event through the integration engine to the systems that record and act on it.
{{diagram: care-plan system → PGL message → integration engine → EHR care-plan module / case management / care coordination / analytics}}
Typical senders: care-plan management system, EHR clinical documentation module, case-management platform.
Typical receivers: EHR care-plan module, case-management tools, care-coordination platform, and clinical analytics.
Direction: unidirectional notification from the care-plan source to the systems that record, display, and act on goal changes.
Segments in a PGL message
The PGL_PC6 message opens with MSH and PID, then contains one or more repeating GOAL groups. Each GOAL group opens with GOL and may include notes, variance, role, problem, observation, and order sub-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 PGL message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (PGL^PC6, PGL^PC7, or PGL^PC8), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 and deduplicate on MSH-10. |
PID | Patient Identification. Identifies the patient the goal belongs to — the identifier list in PID-3, the name in PID-5. Required in every PGL message. |
GOL | Goal Detail. The core of the GOAL group and the authoritative record of the goal. GOL-1 carries the action code — AD (add), UP (update), DE (delete), or CO (correct). GOL-2 is the action datetime. GOL-3 carries the goal ID as a coded element identifying the type of goal. GOL-4 is the goal instance ID, uniquely identifying this specific goal for this patient. GOL-5 carries the episode of care ID linking the goal to its encounter or episode. GOL-10 is the goal lifecycle status (e.g., proposed, active, achieved, abandoned). GOL-12 is the goal target datetime — the date by which the goal is expected to be reached. Required; the GOAL group repeats once per goal. |
[{NTE}] | Notes and Comments. Clinical notes relative to the goal, following GOL. Optional and repeating. |
[{VAR}] | Variance. Records deviations from the expected care plan, with a variance code and an originating organisation. Optional and repeating. |
[{ROL}] | Role. Identifies care-team members associated with the goal and the role each plays (e.g., goal owner, responsible clinician). Optional and repeating. |
[{PRB}] | Problem Detail. Opens the optional PROBLEM sub-group. Links a clinical problem that this goal addresses back to its source on the problem list. Repeating — a goal may address more than one problem. Optional. |
[{NTE}] | Notes and Comments. Notes relative to the linked problem. Optional and repeating; appear within the PROBLEM sub-group. |
[{VAR}] | Variance. Variance records for the linked problem. Optional and repeating; appear within the PROBLEM sub-group. |
[{ROL}] | Role. Care-team roles associated with the linked problem. Optional and repeating; appear within the PROBLEM sub-group. |
[{OBX}] | Observation/Result. Goal-related observations within the PROBLEM sub-group — for example, the observation value that prompted adding the goal. Optional and repeating. |
[{NTE}] | Notes and Comments. Notes relative to the observation in the PROBLEM sub-group. Optional and repeating. |
[{OBX}] | Observation/Result. Goal-level observations outside the PROBLEM sub-group — quantitative targets, assessment scores, or other goal-related measurements. Optional and repeating. |
[{NTE}] | Notes and Comments. Notes relative to the goal-level observation. Optional and repeating. |
ORC | Common Order. Opens the optional ORDER sub-group. Links an order placed to help achieve the goal — a referral, a lab order, or a therapy order — to the goal itself. Optional; the ORDER group repeats once per linked order. |
OBR | Observation Request. The observation request for the linked order — the service being ordered to support goal achievement. Required when the ORDER group is present. |
[{NTE}] | Notes and Comments. Notes relative to the linked order. Optional and repeating; appear within the ORDER sub-group. |
[{VAR}] | Variance. Variance records for the linked order. Optional and repeating; appear within the ORDER sub-group. |
[{OBX}] | Observation/Result. Results or observations associated with the linked order, carrying findings relevant to goal progress. Optional and repeating; appear within the ORDER sub-group. |
[{NTE}] | Notes and Comments. Notes relative to the order-level observation. Optional and repeating; appear within the ORDER sub-group. |
[ ] = optional, { } = repeating
The GOAL group from GOL through the ORDER sub-group repeats once per goal, so a single PGL message can carry updates to several goals in one transmission. The canonical segment pages carry the full field-by-field detail.
Sample PGL message
Note. Constructed for illustration. Patient identifiers, goal identifiers, dates, and names are fictional.
MSH|^~&|CAREPLAN|MERCYGEN|EHR|MERCYGEN|20260601083000||PGL^PC6^PGL_PC6|MSG00047|P|2.5.1
PID|1||MR98765^^^MERCYGEN^MR||SMITH^MARY^A||19650315|F
GOL|AD|20260601083000|00001^Reduce systolic blood pressure to <130 mmHg^L|GOAL-2026-0042|EP-20260515|||||active^Active^L|20260901
NTE|1||Goal set following hypertension review on 2026-06-01.
ROL|1|AD|GOWN^Goal Owner^HL70443|PROV01^CHEN^ALICE^^^^MD
OBX|1|NM|55284-4^Blood pressure systolic^LN||158|mm[Hg]|<130||||F|||20260601
NTE|1||Baseline systolic recorded at goal creation.
What this sample shows
The PGL^PC6 in MSH-9 marks the addition of a new patient goal. PID carries the medical record number MR98765. The GOL segment records the goal: action code AD in GOL-1 confirms this is a new goal; GOL-2 gives the action datetime; GOL-3 carries the coded goal type (reduce systolic blood pressure to below 130 mmHg); GOL-4 is the unique goal instance ID GOAL-2026-0042; GOL-5 links the goal to episode EP-20260515; GOL-10 sets the lifecycle status to active; and GOL-12 sets the target date to 1 September 2026. The NTE following GOL adds a clinical note. The ROL identifies the goal owner. The OBX carries the baseline systolic reading of 158 mmHg that prompted the goal, with its own NTE.
Working with PGL messages
Use GOL-1 action code and the trigger event together
Receivers should confirm the per-goal action code in GOL-1 (AD, UP, DE, CO) in addition to the trigger event in MSH-9. The trigger event signals the primary intent of the message, but a single PGL message may carry goals with differing action codes. Process each GOAL group according to its own GOL-1 rather than applying the trigger event uniformly to all goals in the message.
Idempotency and deduplication
Use MSH-10, the message control id, as the deduplication key, and treat the goal instance ID in GOL-4 together with the action datetime in GOL-2 as the natural business key for a goal change. Care-plan feeds are replayed after outages, and treating a repeated control id as a duplicate prevents a replayed add from creating a second goal record or a replayed delete from removing a goal that has since been reinstated.
Track goal lifecycle through GOL-10
GOL-10 carries the lifecycle status of the goal at the time the message is sent. A sequence of PGL messages for a single goal instance — identified by GOL-4 — should show an evolving status from proposed through active to achieved or abandoned. Sequence by the action datetime in GOL-2 rather than arrival order, so a delayed update does not roll back a more recent status change.
Preserve the target datetime
GOL-12 carries the date by which the goal is expected to be reached. Surface this on the care plan rather than discarding it — the target datetime is the measurable commitment that distinguishes a goal from a general intent, and it is used by care-coordination tools to flag overdue or at-risk goals.
Vendor variance. The PROBLEM, OBSERVATION, and ORDER sub-groups are all optional, and their presence varies widely by sender. Some care-plan systems send only
GOLwith no sub-groups; others always attach linked problems viaPRBor baseline observations viaOBX. Confirm a partner's field and sub-group usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A patient goal corresponds to the FHIR Goal 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 PGL_PC6 and no ConceptMap for the GOL segment — the patient-care message family (PGL, PPR, PPG) is not covered by the current IG. A FHIR Goal produced from a PGL message is therefore mapped manually, taking the goal code, lifecycle status, target date, and subject reference from GOL, and deriving linked Condition resources from any PRB segments present.
Common pitfalls
Pitfall. Routing on the trigger event alone and ignoring
GOL-1. A single PGL message can carry goals with different action codes; applying the message-level trigger uniformly can result in adding a goal that was meant to be deleted, or vice versa.
Pitfall. Discarding the goal instance ID in
GOL-4. WithoutGOL-4as the stable identifier for a goal, update and delete messages cannot be matched to the correct existing goal record; duplicate or orphaned goal entries result.
Pitfall. Assuming the PROBLEM sub-group is always present. Not all senders populate
PRB, even when the goal was created in response to a specific problem. Build implementations that handle aGOL-only GOAL group without expecting a linked problem segment.
How Vorro handles PGL messages
Vorro ingests the PGL feed over MLLP or another transport, deduplicates on MSH-10, and routes each goal update to every subscribed destination in the format that system expects — the EHR care-plan module, case management, and care-coordination platforms. Vorro reads the action code, goal identifier, lifecycle status, and target datetime from GOL, links each goal to any associated problems through PRB and to any supporting orders through ORC and OBR, and, where a FHIR destination is configured, maps the goal to a FHIR Goal resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- PPR — the patient problem message that records clinical problems a PGL goal may be created to address.
- PPG — the patient pathway message that provides the structured care pathway within which goals are set.
- ADT — the admit/discharge/transfer message that establishes the patient encounter or episode referenced in
GOL-5.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for PGL_PC6
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for GOL
- HL7 Messaging Standard Version 2.5.1 product brief
