HL7 PRC Pricing
HL7 field reference PRC 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 |
|---|---|---|---|---|---|
| PRC.1 | Primary Key Value - PRC | Yes | No | CE | 0132 |
| PRC.2 | Facility ID - PRC | No | Yes | CE | 0464 |
| PRC.3 | Department | No | Yes | CE | 0184 |
| PRC.4 | Valid Patient Classes | No | Yes | IS | 0004 |
| PRC.5 | Price | No | Yes | CP | |
| PRC.6 | Formula | No | Yes | ST | |
| PRC.7 | Minimum Quantity | No | No | NM | |
| PRC.8 | Maximum Quantity | No | No | NM | |
| PRC.9 | Minimum Price | No | No | MO | |
| PRC.10 | Maximum Price | No | No | MO | |
| PRC.11 | Effective Start Date | No | No | TS | |
| PRC.12 | Effective End Date | No | No | TS | |
| PRC.13 | Price Override Flag | No | No | IS | 0268 |
| PRC.14 | Billing Category | No | Yes | CE | 0293 |
| PRC.15 | Chargeable Flag | No | No | ID | 0136 |
| PRC.16 | Active/Inactive Flag | No | No | ID | 0183 |
| PRC.17 | Cost | No | No | MO | |
| PRC.18 | Charge On Indicator | No | No | IS | 0269 |
PRC carries pricing rules for a charge, product, or service master item.
The standard describes PRC this way: The PRC segment contains the pricing information for the preceding CDM segment's chargeable item. It contains the fields which, for the same chargeable item, might vary depending upon facility or department or patient type. The preceding CDM segment contains the fields which, for one chargeable item, remain the same across facilities, departments, and patient types.
Billing segments are where clinical activity starts turning into charge, reimbursement, and account data. They can look administrative, but a bad code or account reference can cause real downstream cleanup.
Treat charge codes, revenue codes, grouping values, effective dates, and account identifiers as controlled data. Free-text labels are useful for humans, but receivers usually post, price, or group from the coded values.
The v2.5.1 structures show PRC in MFN_M04 - Master files charge description and MFR_M04 - Master files charge description. 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.
PRC-1 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
The generated panel links this to HL7 table 0132; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PRC-2 identifies the Facility ID - PRC for this billing 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.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.
PRC-3 places the billing workflow in an organization, facility, department, room, bed, or location group. Keep physical location, owning department, and receiving facility separate when the datatype allows it.
The generated panel links this to HL7 table 0184; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PRC-4 qualifies the billing workflow rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
Use the agreed value set, starting from HL7 table 0004. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
PRC-5 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
PRC-6 carries Formula for this billing 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.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
PRC-7 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
PRC-8 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
PRC-9 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
PRC-10 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
PRC-11 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.
For effective and end dates, make the boundary rule explicit. Receivers need to know whether the value is inclusive, exclusive, planned, actual, or merely informational.
PRC-12 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.
For effective and end dates, make the boundary rule explicit. Receivers need to know whether the value is inclusive, exclusive, planned, actual, or merely informational.
PRC-13 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
The generated panel links this to HL7 table 0268; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PRC-14 qualifies the billing workflow rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
Use the agreed value set, starting from HL7 table 0293. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
PRC-15 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
The generated panel links this to HL7 table 0136; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PRC-16 carries Active/Inactive Flag for this billing 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.
The generated panel links this to HL7 table 0183; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PRC-17 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
PRC-18 tells the receiver the state of this billing workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0269 or the narrower table in the local profile.
Related links
- FT1 - Financial Transaction
- DG1 - Diagnosis
- DRG - Diagnosis Related Group
- PR1 - Procedures
- PV1 - Patient Visit
- IN1 - Insurance
- IN2 - Insurance Additional Information
- IN3 - Insurance Additional Information, Certification
- MFN_M04 - Master files charge description
- MFR_M04 - Master files charge description