NEWFree ROI Calculators — quantify what prior auth and siloed data are costing your organization.Prior Auth ROI Siloed Data ROI
HL7 v2Segment10 min read

HL7 CER Segment: Certificate Detail

CER carries the formal credential and certificate details for a person — typically a health professional described by an STF (Staff Identification) segment in a master-file message. It records what license or certificate the person holds, who granted it, where it is valid, and its lifecycle dates (granted, activated, expired, revoked). CER was introduced in HL7 v2.6 and is most often seen in personnel master-file messages that distribute provider directories between systems. It is an optional, low-frequency segment: many interfaces never send it, and receivers built before v2.6 will not recognize it.

Note: CER is a v2.6+ segment. This page keeps version: "2.5.1" in the frontmatter for consistency with the rest of the segment library, but CER does not exist in 2.5.1 — see Version differences.

Purpose

CER adds detailed information about the authorizations a health professional holds — licenses, board certifications, and similar credentials. Where STF identifies the person and PRA describes their practitioner role, CER describes a single certificate: its serial number, granting and issuing authority, the geography in which it is valid, and the dates that govern its validity. One CER segment represents one certificate; a person with several credentials is described with several CER segments.

Used in

CER appears in master-file and personnel messages that carry practitioner credentials — most notably the staff/practitioner master file MFN/M02. In those messages CER follows the STF (and any PRA) segments for the person it describes. It is not used in patient-centric ADT or ORU traffic. See the messages index for the broader message catalog.

Field-by-field reference

Source: the HL7 v2.6+/2.8 standard CER definition (HL7 Europe refactored reference, cross-checked against the Caristix v2.8 definition). CER was not present before v2.6, so there is no v2.5.1 row to cite. R = required, O = optional, C = conditional. Repeat = field may repeat. Lengths are not reproduced here. Table numbers are shown only where well established; otherwise .

Confidence note: this field list reflects the v2.6+ standard and is lower-confidence than segments with a published v2-to-FHIR ConceptMap. Field count and exact data types vary slightly across v2.6, v2.7.1, and v2.8 — verify against your target version before building a strict parser.

SeqNameData TypeLengthReqRepeatTable #Description
CER-1Set ID - CERSIRSequence number; 1 for the first CER, 2 for the second, etc.
CER-2Serial NumberSTONumber/characters identifying the certificate within its issuer's scope.
CER-3VersionSTOVersion of the certificate.
CER-4Granting AuthorityXONOOrganization that granted the certificate.
CER-5Issuing AuthorityXCNOPerson/authority that issued the certificate.
CER-6SignatureEDOEncapsulated digital signature data.
CER-7Granting CountryIDOHL70399Country that granted the certificate (ISO 3166).
CER-8Granting State/ProvinceCWEOHL70347State/province that granted the certificate.
CER-9Granting County/ParishCWEOCounty/parish that granted the certificate.
CER-10Certificate TypeCWEOType of certificate (e.g. license, board certification).
CER-11Certificate DomainCWEODomain/specialty the certificate covers.
CER-12Subject IDEICIdentifier of the certificate subject.
CER-13Subject NameSTRName of the certificate subject.
CER-14Subject Directory Attribute ExtensionCWEOYAdditional directory attributes for the subject.
CER-15Subject Public Key InfoCWEOPublic key information for the subject.
CER-16Authority Key IdentifierCWEOIdentifier of the authority's key.
CER-17Basic ConstraintIDOBasic constraint flag.
CER-18CRL Distribution PointCWEOYCertificate revocation list distribution point.
CER-19Jurisdiction CountryIDOHL70399Country of the jurisdiction in which the certificate applies.
CER-20Jurisdiction State/ProvinceCWEOHL70347State/province of the jurisdiction.
CER-21Jurisdiction County/ParishCWEOCounty/parish of the jurisdiction.
CER-22Jurisdiction BreadthCWEOYBreadth/scope of the jurisdiction.
CER-23Granting DateDTMODate the certificate was granted.
CER-24Issuing DateDTMODate the certificate was issued.
CER-25Activation DateDTMODate the certificate became active.
CER-26Inactivation DateDTMODate the certificate became inactive.
CER-27Expiration DateDTMODate the certificate expires.
CER-28Renewal DateDTMODate the certificate was renewed.
CER-29Revocation DateDTMODate the certificate was revoked.
CER-30Revocation Reason CodeCWEOReason the certificate was revoked.
CER-31Certificate Status CodeCWEOCurrent status of the certificate (e.g. active, revoked, provisional).

Most-used fields

In practice the credential-directory use case relies on a small subset. CER-1 Set ID distinguishes multiple certificates for the same person. CER-10 Certificate Type and CER-11 Certificate Domain say what the credential is and what it covers. CER-4 Granting Authority and CER-5 Issuing Authority say who stands behind it. CER-7/8/9 (Granting Country, State/Province, County/Parish) capture where it was granted, and CER-27 Expiration Date plus CER-31 Certificate Status Code drive whether the credential is currently honored. The cryptographic fields (CER-6, CER-15, CER-16, CER-17, CER-18) are rarely populated in everyday provider-directory feeds.

Version differences (2.3 to 2.8.2)

  • 2.3 / 2.4 / 2.5 / 2.5.1: CER does not exist. Practitioner credentials, where exchanged at all, were carried in other structures.
  • 2.6: CER (Certificate Detail) introduced as part of the personnel/master-file material, designed to extend the STF/PRA practitioner description with certificate detail.
  • 2.7 / 2.7.1: field set stabilized; data-type refinements applied to several fields in line with the v2.7 data-type cleanup.
  • 2.8 / 2.8.2: definition as reflected in the field table above. Field details (data types, conditionality) can differ slightly from 2.6 — confirm against your target version.

Because CER is v2.6+, a receiver negotiated at v2.5.1 or earlier will not recognize the segment and will typically ignore or reject it.

Common mistakes

  • Sending CER to a receiver that negotiated a pre-2.6 version, which does not know the segment.
  • Confusing CER-4 Granting Authority (XON, an organization) with CER-5 Issuing Authority (XCN, a person).
  • Assuming one CER per person; a practitioner with multiple credentials needs one CER per certificate, each with its own CER-1 Set ID.
  • Treating expired or revoked credentials as valid by ignoring CER-27 Expiration Date and CER-31 Certificate Status Code.
  • Reusing the same Set ID across CER segments for the same person, which breaks set ordering.

Examples

Minimal CER (required fields only — Set ID and Subject Name):

CER|1|||||||||||||DOE^JANE

Fully-populated CER (license credential with granting geography and lifecycle dates):

CER|1|LIC-558231|1.0|State Medical Board^^^^^^^^MO-BOM^XX^^^MOBOM|99887766^Smith^Robert^^^Dr^^^MOBOM^L^^^DN|^application^pdf^Base64^...|USA|MO^Missouri^HL70347||MD^Physician License^L|INTERNAL_MED^Internal Medicine^L||LIC-558231|DOE^JANE|||||||USA|MO^Missouri^HL70347|||20180601|20180601|20180601||20280531|||| ACTIVE^Active^L

Annotated breakdown of the minimal example:

CER                 ← segment ID
1                   ← CER-1  Set ID - CER
                    ← CER-2..12 empty (serial, version, authorities, signature, geography, type, domain, subject id)
DOE^JANE            ← CER-13 Subject Name

In-context inside an MFN^M02 staff/practitioner master file (STF then PRA then CER):

MSH|^~&|HR_SYS|HOSP_A|DIRECTORY|HOSP_B|20260609120000||MFN^M02^MFN_M02|MSG00042|P|2.6
MFI|PRA^Practitioner Master File^HL70175|||UPD|20260609120000|AL
MFE|MAD|||99887766^^^MOBOM^DN|CWE
STF|99887766^^^MOBOM^DN|99887766|DOE^JANE^A||P|F|19750214|A
PRA|99887766^^^MOBOM^DN||MD^Doctor of Medicine^L||INTERNAL_MED^Internal Medicine^L
CER|1|LIC-558231|1.0|State Medical Board^^^^^^^^MO-BOM^XX^^^MOBOM||||MO^Missouri^HL70347||MD^Physician License^L|INTERNAL_MED^Internal Medicine^L||DOE^JANE|||||||||||20180601||20180601||20280531||||ACTIVE^Active^L

In-context showing two credentials for the same practitioner (two CER segments, distinct Set IDs):

STF|24681357^^^ABMS^DN|24681357|RAO^PRIYA^^||P|F|19820710|A
PRA|24681357^^^ABMS^DN||MD^Doctor of Medicine^L||CARDIOLOGY^Cardiology^L
CER|1|LIC-771204|1.0|State Medical Board^^^^^^^^TX-MB^XX^^^TXMB||||TX^Texas^HL70347||MD^Physician License^L|CARDIOLOGY^Cardiology^L||RAO^PRIYA|||||||||||20160901||20160901||20260831||||ACTIVE^Active^L
CER|2|BC-330915|2.0|Am Board of Internal Medicine^^^^^^^^ABIM^XX^^^ABIM||||US^United States^HL70399||BC^Board Certification^L|CARDIOLOGY^Cardiology^L||RAO^PRIYA|||||||||||20170301||20170301||20270228||||ACTIVE^Active^L

FHIR mapping

No segment-level ConceptMap is published in the v2-to-FHIR IG for CER. The IG provides datatype and segment maps for many practitioner-related structures (for example XCN to Practitioner and the PRT/ROL practitioner segment maps), but CER is not among the published segment maps. There is therefore no official mapping table to reproduce here.

Conceptually, CER credential data corresponds to Practitioner.qualification in FHIR: Practitioner.qualification.code aligns with CER-10/CER-11 (certificate type and domain), Practitioner.qualification.issuer with CER-4/CER-5 (granting/issuing authority), and Practitioner.qualification.period with the CER lifecycle dates (CER-25 activation through CER-27 expiration). Treat this as guidance for hand-built transforms rather than an official mapping — confirm against the IG before relying on it.

Engine considerations

  • Version gating: only emit CER when the negotiated version is 2.6 or later. Suppress it for older receivers rather than risk a reject.
  • Cardinality: CER repeats per person. Group all CER segments under the correct STF/PRA so credentials attach to the right practitioner.
  • Set ID hygiene: assign CER-1 sequentially within each person; do not reset or collide across the person's credential set.
  • Lifecycle filtering: when downstream consumers want only valid credentials, filter on CER-31 status and CER-27 expiration rather than passing every historical certificate.
  • Unknown-segment handling: receivers that predate v2.6 may pass CER through as an unrecognized segment; confirm behavior before sending.

How Vorro parses and produces CER

On the inbound side, Vorro associates each CER with the preceding STF/PRA context so credentials stay bound to the right practitioner, and it reads CER-31 status and CER-27 expiration to flag stale or revoked credentials during directory loads. On the outbound side, Vorro assigns sequential CER-1 Set IDs per person, only emits CER on channels negotiated at v2.6 or later, and maps internal credential records to CER-10/CER-11 type and domain with the granting authority in CER-4. Because no IG segment map exists, Vorro's FHIR transform for credentials is a configured Practitioner.qualification mapping rather than a generated one.

  • STF — the staff identification segment CER attaches to.
  • PRA — the practitioner detail segment that sits between STF and CER.
  • MFN messages — the master-file messages that carry CER with practitioner credentials.

Sources

← Back to HL7 v2 Guide

Ready to Integrate This Into Your Workflow?

Talk to a Vorro expert about implementing HL7 v2 in your specific environment.

Browse HL7 v2 Guides
HL7 CER Segment: Certificate Detail | Vorro Academy | Vorro