The SPD (Specialty Description) data type was introduced in HL7 v2.4 to carry the four facts a downstream system needs about a practitioner's clinical specialty: the specialty name, the board that grants certification, whether the practitioner is board-certified or merely board-eligible, and the date certification was issued. SPD appears in the PRA (Practitioner Detail) segment's specialty field and in the STF (Staff Identification) segment's specialty field. A single practitioner often carries multiple SPDs — one per specialty — and each is self-contained.
Purpose
Healthcare directories, credentialing systems, and referral platforms all need a structured answer to "what is this physician certified in, by whom, and since when?" Free-text specialty strings ("Internal Medicine, Board Certified, 2018") cannot be queried, filtered, or trusted; they conflate the credential with the issuing body and lose the eligibility-vs-certified distinction that determines whether a practitioner can sign certain orders or bill at certain codes. SPD splits these into four discrete components so a credentialing receiver can validate the board (ABIM, ABS, ABFM, etc.), enforce the C/E semantics, and compute time-in-specialty from the certification date.
Components
Source: HAPI HL7v2 v2.8.1 javadoc (SPD).
| Comp | Name | Sub-type | Length | Required | Description |
|---|---|---|---|---|---|
| SPD.1 | Specialty Name | st | — | O | Free-text specialty name (e.g. Internal Medicine). |
| SPD.2 | Governing Board | st | — | O | Board that certifies the specialty (e.g. ABIM American Board of Internal Medicine). |
| SPD.3 | Eligible or Certified | id | 1 | O | HL7 table 0337: C certified, E eligible. |
| SPD.4 | Date of Certification | dt | 8 | O | Date the certification was granted (YYYYMMDD). |
Most-used components
- SPD.1 Specialty Name — the human-readable label receivers display.
- SPD.2 Governing Board — the credentialing source-of-truth; without it, the specialty is unverifiable.
- SPD.3 Eligible or Certified — drives privilege and billing eligibility downstream.
Where it's used
- PRA-5 Specialty (the canonical home — repeats per specialty).
- STF-10 Specialty in staff/practitioner master messages.
- Credentialing Z-segments in payer enrolment feeds that mirror PRA/STF content.
- Outbound provider-directory exports that derive specialty + board + certified-flag from SPD before serialising to NPPES-aligned formats.
- ROL segment extensions in some site-local profiles that attach specialty to a role assignment.
Version differences
- HL7 v2.4 — SPD introduced with the four-component layout (specialty, board, eligible/certified, date).
- HL7 v2.5 through v2.8 — no structural changes; HL7 table 0337 (C/E) binding stabilised.
- HL7 v2.8.1 — HAPI javadoc confirms the four-component definition unchanged.
- HL7 v2.8.2 — no structural changes; table refreshes only.
Common mistakes
- Encoding the board into the specialty name (
Internal Medicine (ABIM)) and leaving SPD.2 empty — receivers that parse SPD.2 for credentialing pipelines lose the board entirely. - Using
Y/Nin SPD.3 instead ofC/E— HL7 table 0337 is C/E only; Y/N is a different binding and fails downstream credentialing validation. - Omitting SPD.4 when SPD.3 =
C— a certified practitioner without a certification date cannot be re-credentialed on the standard cycle; receivers either reject or flag for manual lookup. - Putting time-of-day in SPD.4 — SPD.4 is DT (YYYYMMDD), not DTM; an 8-character date with a 6-character time concatenated mis-parses on most engines.
- Treating multiple specialties as a single SPD with comma-separated names — receivers expect repeating SPDs at the field level, not packed sub-components.
Examples
Minimal value — Internal Medicine, board-certified by ABIM in June 2018:
Internal Medicine^ABIM^C^20180615
Eligible (not yet certified) — Internal Medicine, board-eligible:
Internal Medicine^ABIM^E
In context — PRA-5 with two specialties:
PRA||||||Internal Medicine^ABIM^C^20180615~Cardiovascular Disease^ABIM^C^20220901|
Common pitfall — Y/N instead of C/E:
Internal Medicine^ABIM^Y^20180615 <- WRONG; HL70337 is C/E
Internal Medicine^ABIM^C^20180615 <- CORRECT
FHIR mapping
The v2-to-FHIR Implementation Guide does not publish a per-datatype ConceptMap for SPD. The content splits across two FHIR resources: PractitionerRole.specialty for the specialty itself, and Practitioner.qualification for the credentialing facts (board, certified/eligible, date).
| SPD component | FHIR target |
|---|---|
| SPD.1 Specialty Name | PractitionerRole.specialty.coding.display (and, where coded, .code) |
| SPD.2 Governing Board | Practitioner.qualification.issuer.display |
| SPD.3 Eligible or Certified | Practitioner.qualification.code qualifier (often modelled as an extension carrying the HL70337 code) |
| SPD.4 Date of Certification | Practitioner.qualification.period.start |
Specialty taxonomies (NUCC, SNOMED CT) are typically applied on the FHIR side after lookup from SPD.1; SPD itself does not carry the coding system.
Engine considerations
- C/E enforcement: SPD.3 must validate against HL70337; engines that accept lowercase
c/eor synonyms (Y/N,CERTIFIED/ELIGIBLE) propagate dirty credentialing data. - Date precision: SPD.4 is DT, not DTM — engines must reject 12- or 14-character values rather than truncating silently.
- Board normalisation: SPD.2 is ST and accepts any string; engines that integrate with credentialing systems should normalise to a canonical board catalogue (ABMS member boards) with a synonym table.
- Repeating specialties: PRA-5 and STF-10 expect repeating SPDs with
~; engines must not collapse to first occurrence and must preserve order. - Eligible without date: when SPD.3 =
E, SPD.4 may legitimately be empty (no certification date yet); engines should not synthesise one.
How Vorro parses and produces SPD
On inbound, Vorro parses each SPD as a Specialty value object with name: String, board: Optional<String>, status: Enum(CERTIFIED, ELIGIBLE), and certifiedOn: Optional<LocalDate>. SPD.3 is validated against HL70337 and normalised to the enum; values outside C/E route to a curation queue. The board string is normalised against a configurable ABMS catalogue, with the original string preserved as provenance.
On outbound, Vorro emits SPDs in canonical order with explicit C/E in SPD.3 and a DT-precision SPD.4 (YYYYMMDD only — never with a time component). Multiple specialties for the same practitioner are emitted as repeating SPDs in PRA-5 or STF-10 with ~ separators, ordered by certification date descending for receiver-side diff stability. When the source record carries an eligible-only status, Vorro emits E with an empty SPD.4 rather than fabricating a placeholder date.
