HL7 CER Certificate Detail
HL7 field reference CER 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 |
|---|---|---|---|---|---|
| CER.1 | Set ID - CER | Yes | No | SI | |
| CER.2 | Serial Number | No | No | ST | |
| CER.3 | Version | No | No | ST | |
| CER.4 | Granting Authority | No | No | XON | |
| CER.5 | Issuing Authority | No | No | XCN | |
| CER.6 | Signature of Issuing Authority | No | No | ED | |
| CER.7 | Granting Country | No | No | ID | 0399 |
| CER.8 | Granting State/Province | No | No | CWE | 0347 |
| CER.9 | Granting County/Parish | No | No | CWE | 0289 |
| CER.10 | Certificate Type | No | No | CWE | |
| CER.11 | Certificate Domain | No | No | CWE | |
| CER.12 | Subject ID | No | No | ID | |
| CER.13 | Subject Name | Yes | No | ST | |
| CER.14 | Subject Directory Attribute Extension (Health Professional Data) | No | Yes | CWE | |
| CER.15 | Subject Public Key Info | No | No | CWE | |
| CER.16 | Authority Key Identifier | No | No | CWE | |
| CER.17 | Basic Constraint | No | No | ID | 0136 |
| CER.18 | CRL Distribution Point | No | Yes | CWE | |
| CER.19 | Jurisdiction Country | No | No | ID | 0399 |
| CER.20 | Jurisdiction State/Province | No | No | CWE | 0347 |
| CER.21 | Jurisdiction County/Parish | No | No | CWE | 0289 |
| CER.22 | Jurisdiction Breadth | No | Yes | CWE | 0547 |
| CER.23 | Granting Date | No | No | TS | |
| CER.24 | Issuing Date | No | No | TS | |
| CER.25 | Activation Date | No | No | TS | |
| CER.26 | Inactivation Date | No | No | TS | |
| CER.27 | Expiration Date | No | No | TS | |
| CER.28 | Renewal Date | No | No | TS | |
| CER.29 | Revocation Date | No | No | TS | |
| CER.30 | Revocation Reason Code | No | No | CE | |
| CER.31 | Certificate Status | No | No | CWE | 0536 |
CER describes a certificate, license, credential, or similar authority record used in staff, provider, or master-file workflows.
The standard describes CER this way: The CER segment adds detailed information regarding the formal authorizations to provide a service (e.g. licenses, certificates) held by the health professional identified by the STF segment.
Master-file segments update reference data rather than describing a single patient event. They define locations, staff, providers, test catalogs, charge items, inventory items, languages, certificates, and other shared records.
Because many downstream messages depend on this data, small changes here can have large effects. Use stable identifiers, effective dates, action codes, and clear ownership rules instead of treating a master-file feed like a loose spreadsheet export.
The v2.5.1 structures show CER in MFN_M02 - Master file - staff practitioner, PMU_B01 - Add personnel record, PMU_B07 - Grant Certificate/Permission, and PMU_B08 - Revoke Certificate/Permission, and 1 other message structure. 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.
CER-1 is the sequence number for this CER segment within its repeating group. It keeps multiple CER lines in order; it is not the business identifier for the master-file record.
CER-2 identifies the Serial Number for this master-file record. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
CER-3 helps identify the product, software, device, or equipment involved. It is particularly useful when support needs to trace behaviour back to a specific build, lot, instrument, or manufacturer.
CER-4 carries Granting Authority for this master-file record. 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.
CER-5 carries Issuing Authority for this master-file record. 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.
CER-6 carries Signature of Issuing Authority for this master-file record. 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.
CER-7 is used for reconciliation. The receiver may compare it with the segments, batches, messages, rows, or items actually received, so do not populate it from a stale estimate.
The generated panel links this to HL7 table 0399; many real interfaces narrow that list further, so follow the receiver's implementation guide.
CER-8 tells the receiver the state of this master-file record. 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 0347 or the narrower table in the local profile.
CER-9 is used for reconciliation. The receiver may compare it with the segments, batches, messages, rows, or items actually received, so do not populate it from a stale estimate.
The generated panel links this to HL7 table 0289; many real interfaces narrow that list further, so follow the receiver's implementation guide.
CER-10 qualifies the master-file record rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
CER-11 carries Certificate Domain for this master-file record. 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.
CER-12 identifies the Subject ID for this master-file record. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
CER-13 identifies a person, provider, staff member, or contact involved in this master-file record. Use the structured name or provider datatype instead of flattening everything into display text.
CER-14 carries Subject Directory Attribute Extension (Health Professional Data) for this master-file record. 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.
CER-15 carries Subject Public Key Info for this master-file record. 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.
CER-16 identifies the Authority Key Identifier for this master-file record. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
CER-17 carries Basic Constraint for this master-file record. 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 0136; many real interfaces narrow that list further, so follow the receiver's implementation guide.
CER-18 carries CRL Distribution Point for this master-file record. 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.
CER-19 is used for reconciliation. The receiver may compare it with the segments, batches, messages, rows, or items actually received, so do not populate it from a stale estimate.
The generated panel links this to HL7 table 0399; many real interfaces narrow that list further, so follow the receiver's implementation guide.
CER-20 tells the receiver the state of this master-file record. 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 0347 or the narrower table in the local profile.
CER-21 is used for reconciliation. The receiver may compare it with the segments, batches, messages, rows, or items actually received, so do not populate it from a stale estimate.
The generated panel links this to HL7 table 0289; many real interfaces narrow that list further, so follow the receiver's implementation guide.
CER-22 carries Jurisdiction Breadth for this master-file record. 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 0547; many real interfaces narrow that list further, so follow the receiver's implementation guide.
CER-23 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.
CER-24 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.
CER-25 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.
CER-26 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.
CER-27 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.
CER-28 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.
CER-29 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.
CER-30 identifies the Revocation Reason Code for this master-file record. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
CER-31 tells the receiver the state of this master-file record. 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 0536 or the narrower table in the local profile.
Related links
- MFI - Master File Identification
- MFE - Master File Entry
- MFA - Master File Acknowledgment
- LOC - Location Identification
- STF - Staff Identification
- PRA - Practitioner Detail
- OM1 - General Segment
- CDM - Charge Description Master
- MFN_M02 - Master file - staff practitioner
- PMU_B01 - Add personnel record