HL7 PRB Problem Details
HL7 field reference PRB fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| PRB.1 | Action Code | Yes | No | ID | 0287 |
| PRB.2 | Action Date/Time | Yes | No | TS | |
| PRB.3 | Problem ID | Yes | No | CE | |
| PRB.4 | Problem Instance ID | Yes | No | EI | |
| PRB.5 | Episode of Care ID | No | No | EI | |
| PRB.6 | Problem List Priority | No | No | NM | |
| PRB.7 | Problem Established Date/Time | No | No | TS | |
| PRB.8 | Anticipated Problem Resolution Date/Time | No | No | TS | |
| PRB.9 | Actual Problem Resolution Date/Time | No | No | TS | |
| PRB.10 | Problem Classification | No | No | CE | |
| PRB.11 | Problem Management Discipline | No | Yes | CE | |
| PRB.12 | Problem Persistence | No | No | CE | |
| PRB.13 | Problem Confirmation Status | No | No | CE | |
| PRB.14 | Problem Life Cycle Status | No | No | CE | |
| PRB.15 | Problem Life Cycle Status Date/Time | No | No | TS | |
| PRB.16 | Problem Date of Onset | No | No | TS | |
| PRB.17 | Problem Onset Text | No | No | ST | |
| PRB.18 | Problem Ranking | No | No | CE | |
| PRB.19 | Certainty of Problem | No | No | CE | |
| PRB.20 | Probability of Problem (0-1) | No | No | NM | |
| PRB.21 | Individual Awareness of Problem | No | No | CE | |
| PRB.22 | Problem Prognosis | No | No | CE | |
| PRB.23 | Individual Awareness of Prognosis | No | No | CE | |
| PRB.24 | Family/Significant Other Awareness of Problem/Prognosis | No | No | ST | |
| PRB.25 | Security/Sensitivity | No | No | CE |
PRB records a patient problem in a problem-oriented or care-plan message.
The standard describes PRB this way: The problem detail segment contains the data necessary to add, update, correct, and delete the problems of a given individual.
These segments describe clinical goals, problems, roles, referrals, requisitions, incidents, variances, and resource groupings that sit around the core patient/order/result traffic.
They are most useful when responsibilities, dates, identifiers, and status values are kept explicit. Otherwise they become narrative fragments that are hard to act on.
The v2.5.1 structures show PRB in PEX_P07 - PEX - Unsolicited initial individual product experience report, PGL_PC6 - PGL - PC/ goal add, PPG_PCG - Oriented) add, and PPP_PCB - Oriented) add, and 5 other message structures. That tells you where it can appear, but the implementation guide still decides which optional fields are meaningful.
For practical interface work, read the generated field panel for datatype, required, repeatable, and table details, then use the notes below to decide what the field should mean in the receiving workflow.
PRB-1 says what action is being taken for this segment or record: add, update, delete, cancel, clear, or another profile-defined operation. It needs to agree with the message trigger and the previous state.
The generated panel links this to HL7 table 0287; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PRB-2 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PRB-3 identifies the Problem ID for this care-plan or referral workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
PRB-4 identifies the Problem Instance ID for this care-plan or referral workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
PRB-5 identifies the Episode of Care ID for this care-plan or referral workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
PRB-6 qualifies the care-plan or referral workflow rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
PRB-7 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PRB-8 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PRB-9 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PRB-10 qualifies the care-plan or referral workflow rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
PRB-11 is clinical or administrative context for the care-plan or referral workflow. Use the coded value, lifecycle status, and timing fields together so a receiver can decide whether it is new, changed, resolved, cancelled, or historical.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
PRB-12 is clinical or administrative context for the care-plan or referral workflow. Use the coded value, lifecycle status, and timing fields together so a receiver can decide whether it is new, changed, resolved, cancelled, or historical.
PRB-13 tells the receiver the state of this care-plan or referral workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
PRB-14 tells the receiver the state of this care-plan or referral workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
PRB-15 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PRB-16 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PRB-17 is human-readable context. Keep it useful for display and troubleshooting, but do not hide required workflow logic here unless the implementation guide explicitly says the receiver parses it.
PRB-18 is clinical or administrative context for the care-plan or referral workflow. Use the coded value, lifecycle status, and timing fields together so a receiver can decide whether it is new, changed, resolved, cancelled, or historical.
PRB-19 is clinical or administrative context for the care-plan or referral workflow. Use the coded value, lifecycle status, and timing fields together so a receiver can decide whether it is new, changed, resolved, cancelled, or historical.
PRB-20 is clinical or administrative context for the care-plan or referral workflow. Use the coded value, lifecycle status, and timing fields together so a receiver can decide whether it is new, changed, resolved, cancelled, or historical.
PRB-21 is clinical or administrative context for the care-plan or referral workflow. Use the coded value, lifecycle status, and timing fields together so a receiver can decide whether it is new, changed, resolved, cancelled, or historical.
PRB-22 is clinical or administrative context for the care-plan or referral workflow. Use the coded value, lifecycle status, and timing fields together so a receiver can decide whether it is new, changed, resolved, cancelled, or historical.
PRB-23 carries Individual Awareness of Prognosis for this care-plan or referral workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
PRB-24 is clinical or administrative context for the care-plan or referral workflow. Use the coded value, lifecycle status, and timing fields together so a receiver can decide whether it is new, changed, resolved, cancelled, or historical.
PRB-25 is rarely the right place for modern authentication. If a legacy profile uses it, document the exact value and rotation rule; otherwise keep security in the transport, certificates, network controls, or authenticated service layer.