Implant Record Standards — Research Note | CareFirst Vision Compendium / CareFirst 愿景纲要

Research input for the export engine (Engineering Action Plan item 2) and the implant identity dataset (item 3). This note surveys how dental implant records are stored today and what structured formats exist for representing them.

This note deliberately makes no recommendation.

Confidence is marked inline where a claim rests on secondary sources rather than the primary standard text.

There is no universal, commonly agreed structured format for a dental implant record.

The imaging half of the problem is solved and has been for decades — DICOM, with IHE profiles governing how it is packaged for portable interchange. The clinical-record half is not. What exists instead is a set of partially overlapping pieces:

a device identity standard (UDI, backed by the FDA's GUDID database) that is mandated and real, but identifies a device model, not the specific unit in a specific patient;
a medical interoperability standard (FHIR, specifically the US Core Implantable Device profile) that has a well-defined shape for "this patient has this implanted device," but says nothing dental-specific;
a dental terminology and data-model family from the ADA (SNODENT, Standards 1000/1084/1111) that is comprehensive on paper and thinly implemented in practice;
a patient-facing document convention (the EU implant card) that defines a minimum data set — but whose applicability to dental implants specifically is contested and probably exempt;
an assortment of commercial "implant passport" products, each with its own private schema.

Nobody has assembled these into a single portable implant record. That gap is the thing the Engineering Action Plan calls "the quiet moat" — this research supports that framing.

The scale of the underlying problem is documented in the literature: one survey identified 87 implant manufacturers across 21 countries producing 231 distinct implant designs, and identifying an implant body radiographically when records are unavailable is described as "a considerable problem due to increased patient mobility and to the large number of implant systems with different designs."

Worth separating from the standards question, because the gap between them is large.

In practice management systems. Implant details are captured as free-text or lightly structured fields attached to a tooth in the clinical chart. The observed field sets across systems (Carestream/Sensei, CareStack, Dentrix, Open Dental) are close to what CareFirst already models: manufacturer, brand, reference number, lot number, size, plus dates for consultation, extraction, placement, bone graft, healing collar, and restoration. Open Dental marks an implanted tooth on the perio chart with an i suffix (e.g. 17i). Dentrix records referred procedures in the chart so the placing event is visible to the restoring dentist.

Two observations matter for export design:

These are per-vendor field sets, not a shared schema. Nothing exchanges between them in structured form.
The fields captured are close enough to CareFirst's implants table that a manifest modeled on our own schema would be intelligible to anyone working in these systems — the vocabulary is shared even where the format is not.

Outside the PMS. The physical implant package carries a peel-off sticker with manufacturer, reference, lot, and often the UDI barcode. That sticker is routinely pasted into a paper chart or scanned to PDF. Surgical reports and lab work orders are PDFs or paper. CBCT lives in the imaging system as DICOM, usually separate from the chart. This is the fragmentation the export engine is meant to resolve.

A note on the lot/serial gap. GUDID contains only the Device Identifier (DI) — the model-level identifier. Production Identifiers (lot, batch, serial, expiry, manufacture date) are not submitted to or stored in GUDID; they exist only on the physical label. So the specific unit placed in a specific patient is recoverable only from the sticker or from whoever transcribed it. Any export that carries lot/serial is carrying data that cannot be re-derived from any public database — an argument for treating those fields as high-value and checksum-protected.

What it is. The Unique Device Identification system. Every UDI is a DI (identifies the model) plus optional PIs (lot, serial, expiry, manufacture date). GUDID is FDA's catalog of DI records; AccessGUDID is the public search and bulk-download front end, updated every business day.

What a dental implant record contains. Records are classified by GMDN term (e.g. "Screw endosteal dental implant, two-piece", "Dental implant abutment", "Dental implant analog"), FDA product code, an implantable flag, brand and company name, version/model, and device size attributes including outer diameter and length in millimetres — which maps directly onto CareFirst's diameter_mm and length_mm.

Regulatory weight. Substantial and increasing. USCDI v6 expanded the UDI data element from implantable-only to all medical devices, on FDA's argument that exchangeable UDI supports safety-event reporting, recall management, and post-market surveillance. ONC certification criterion 170.315(a)(14) requires certified EHRs to record UDIs and maintain a patient implantable-device list.

Limitations. UDI adoption was phased in by device risk class over several years, so GUDID holds records for only a fraction of devices currently in use — this is stated plainly by AccessGUDID itself. Older implants, and implants placed outside the US, will frequently have no GUDID record at all. For a patient whose implant was placed in 2009, or in Qingdao, UDI may simply not exist. AccessGUDID search also caps results at 10,000, which matters for bulk ingestion (item 3) but not for export.

Relevance to the manifest. UDI is the strongest available identifier, and CareFirst already has a udi column. It is not a record format — it identifies the device and nothing about the patient, the placement, or the treatment.

What it is. The HL7 FHIR Device resource constrained by US Core for patient-linked implantable devices. This is the format US health systems use when they exchange "what is implanted in this patient."

Shape.

Element	Cardinality	Notes
`Device.type`	1..1	Device kind; extensible binding to FHIR Device Types
`Device.patient`	1..1	Reference to US Core Patient
`Device.udiCarrier`	0..1 must-support	Container
`Device.udiCarrier.deviceIdentifier`	1..1 when present	The DI
`Device.udiCarrier.carrierHRF`	0..1	Human-readable barcode form (HRF only; AIDC not required)
`Device.status`	required binding	FHIRDeviceStatus
`Device.lotNumber` / `serialNumber` / `distinctIdentifier`	0..1 must-support
`Device.manufactureDate` / `expirationDate`	0..1 must-support
`Device.manufacturer` / `Device.model`	0..1 must-support	Explicitly provided for historical devices lacking a UDI

That last row is notable: the profile anticipates exactly CareFirst's situation, where manufacturer and model are known but UDI is not.

Adoption. Genuinely high in US medical systems, effectively zero in general dental practice. A receiving dentist will not consume FHIR; a receiving hospital or health system might.

Limitations. Device alone carries no placement context — tooth number, placing provider, surgical detail, prosthetic components. Representing a full implant case means composing Device with Procedure, DocumentReference, Patient, and probably Observation, which is a substantially larger modeling exercise than emitting a single resource. Tooth-level positioning has no clean US Core representation and would need SNODENT or SNOMED CT coding.

What it is. HL7 FHIR Implementation Guide: Dental Data Exchange, Release 1 (US Realm), FHIR R4. Developed with the ADA and CareQuest. Built on ANS/ADA Specification No. 1084, Reference Core Data Set for Communication among Dental and other Health Information Systems (2019).

Scope. Bidirectional exchange between a medical and a dental provider, or between dental providers. The exchanged artifact is a document bundle — a C-CDA-on-FHIR Referral Note or Consultation Note — plus ServiceRequest, Patient, and associated clinical information.

Relevance. This is the closest thing to an official dental interoperability standard, and it is the right lineage to be aware of. But it is scoped to referrals and consultations, not to a longitudinal device record. It answers "how do I send a dental colleague a referral," not "how do I represent this patient's implant inventory." A CareFirst export is closer to the second question.

Relevant members:

ANSI/ADA 1000 — Standard Clinical Data Architecture for the Structure and Content of an Electronic Health Record; a logical data model for dental EHR interoperability.
ANSI/ADA 1084 — Reference Core Data Set for Communication among Dental and other Health Information Systems; the substrate of the FHIR Dental Data Exchange IG.
ANSI/ADA 1111 (ODIN) — data modeling for dental system informatics, expanding the 1084 Reference Core Data Model.
ANSI/ADA 2000.6 (SNODENT) — Systematized Nomenclature of Dentistry; the dental controlled vocabulary, recognized in ONC's Interoperability Standards Advisory.
ANSI/ADA 1114 — requirements for effective use of DICOM in dentistry.
ANSI/ADA 1039 / 1040 — clinical conceptual data model; dental extension to the Continuity of Care Record.

Assessment. Comprehensive on paper, weak in the field. The ADA itself acknowledges the gap: a June 2025 ADA News piece reports that integrating electronic dental records into research systems remains complicated, and in March 2026 the ADA publicly called for improved interoperability standards for dental imaging specifically — an admission that even the DICOM-adjacent part is not settled in dentistry. The academic literature describes proprietary formats and inconsistent standards as "one of the central barriers to integrated workflows in digital dental implantology."

Practical consequence: adopting an ADA standard buys legitimacy and a defensible lineage, but essentially no immediate interoperability, because few counterparties implement them.

What it is. Regulation (EU) 2017/745 Article 18 obliges manufacturers to supply an implant card with implantable devices. Required content: device name, model, serial number, lot number, UDI-DI and UDI-PI, manufacturer name and address, plus warnings and precautions, expected lifetime, and necessary follow-up. It must be human-readable and written so a lay person understands it. Guidance is MDCG 2019-8 v2.

The dental catch. Article 18(3) exempts "sutures, staples, dental fillings, dental braces, tooth crowns, screws, wedges, plates, wires, pins, clips and connectors." Industry reading — reflected in a Team-NB position paper on dental implants — is that the dental implant fixture qualifies as a screw and the abutment as a connector, placing both outside the implant-card requirement.

Confidence: moderate. The exemption list is verbatim from the regulation and is solid. The dental-specific interpretation comes from secondary summaries of the Team-NB position paper; the PDF itself could not be parsed during this research and should be read directly before anyone relies on the conclusion. If the interpretation holds, the EU implant card is not a mandate CareFirst can point to for dental implants.

Residual value. Even if legally inapplicable, Article 18 is a regulator-designed, lay-readable minimum data set for "what a patient should be told about their implant," which is very close to the human-readable half of a CareFirst export. It is usable as a template without being usable as a compliance claim.

Settled. CBCT is DICOM. For portable interchange, the relevant profile is IHE Portable Data for Imaging (PDI), which constrains DICOM more tightly for compatibility on removable media.

PDI's structural requirements, if the export were to conform:

a DICOMDIR file at the root referencing every DICOM file on the media;
ISO 9660 Level 1 file-system compliance;
file and folder names referenced by DICOMDIR limited to 8 characters, uppercase letters, digits, and underscore, no extension;
optionally a second entry point, INDEX.HTM, for human/browser access.

A supplement extends PDI beyond CD to DVD and USB.

Assessment. PDI is the only genuinely mature "portable archive of clinical data" convention in this whole survey, and its two-entry-point design (DICOMDIR for machines, INDEX.HTM for humans) is a directly transferable idea. Its filename constraints are archaic and were designed for optical media. Conforming fully would mean 8-character uppercase filenames throughout the archive — a real usability cost. Borrowing the structure without claiming conformance is an available middle path.

Also relevant: whether CareFirst's stored CBCT uploads are DICOM series or already-zipped archives determines how much work a DICOMDIR would be. Current schema accepts "CBCT as DICOM/ZIP," so this is not uniform today.

Not a format, but the closest regulatory analogue to what the export engine does, and instructive.

Certified EHRs must support single-patient EHI export covering all EHI in the designated record set (as defined at 45 CFR 164.501). Its format requirements are notably permissive:

the export must be electronic and in a computable format;
no specific standard format is mandated;
the export must include an up-to-date, publicly accessible hyperlink documenting the export's format, obtainable without preconditions;
the user must be able to trigger export at any time without developer assistance.

The regulator's own answer to "what format should a full patient record export use" was: any computable one, as long as you publish the schema. That is a meaningful data point for the bespoke-vs-standard question, and the "publish your format documentation at a stable URL" requirement is a concrete, cheap practice worth adopting regardless of which format wins.

Several products already occupy the "implant passport" concept: implantpassport.app (digital implant record system with access management, marketed as permanent, portable, secure), id2dental.com (portal framed around preserving implant identity across providers, patients, time, and geography), plus manufacturer-issued cards and various clinic-issued paper passports.

None publishes an open schema, so none constitutes a standard. Flagging this because the Engineering Action Plan states that "no competitor discovered so far appears to have it" — that claim is about the structured dataset (item 3) and may still hold, but the passport concept itself is occupied territory and worth a closer competitive look before it is repeated externally.

Option	Standards weight	Dental fit	Adoption by likely recipients	Cost to emit	Covers full case?
UDI / GUDID	High (FDA-mandated)	Identifier only	Universal as an identifier	Trivial — already modeled	No
FHIR US Core Implantable Device	High	Generic, not dental	High in health systems, ~zero with dentists	Low for `Device` alone	No — needs composition
FHIR Dental Data Exchange IG	Medium (HL7/ADA)	Dental, but referral-scoped	Very low	High	No — wrong shape
ADA 1000 / 1084 / 1111 / SNODENT	Medium (ANSI)	Strong on paper	Very low	High	Partially
EU MDR implant card	High, but likely exempt for dental	Designed for implants	N/A as a format	Low	No — device only
DICOM + IHE PDI	High	Imaging only	Universal for imaging	Medium (`DICOMDIR`)	Imaging only
Bespoke versioned JSON	None	Exact	N/A — self-describing	Low	Yes

Reading across the table: no single row covers a complete implant case. Any complete export is a composition — the practical question is which pieces to compose and how much conformance to claim.

Listed as questions, not answers.

Who is the actual consumer? A dentist opening a folder, a health system ingesting FHIR, and a future CareFirst instance re-importing are three different design targets with different winners in the table above. The Action Plan's "done when" names a dentist with a DICOM viewer — which points away from FHIR — while the Qingdao path arguably points toward machine ingestion.
Does the export claim conformance, or just compatibility? Claiming IHE PDI conformance imposes 8.3-style uppercase filenames. Claiming US Core conformance imposes profile validation. Emitting a DICOMDIR and a FHIR-shaped JSON without claiming conformance costs far less and delivers most of the practical benefit — at the price of not being able to say "standards-conformant" in a pilot conversation.
How much does UDI absence undermine a UDI-anchored design? Given GUDID covers only a fraction of devices in use, and Qingdao-placed implants likely have no GUDID record, a manifest that treats UDI as the primary key will have a lot of null primary keys.
Is the CBCT stored as a DICOM series or a ZIP? Determines whether a DICOMDIR index is feasible without unpacking and re-reading every uploaded archive.
Should the format documentation be published at a stable URL? Cheap, follows the ONC EHI Export precedent, and is a credibility asset in pilot and BAA conversations regardless of which format is chosen.
Does the human-readable half exist? Every mature option here pairs machine data with a human entry point — PDI's INDEX.HTM, the EU implant card's lay-readable requirement. CareFirst has no PDF or HTML rendering capability today, and the Action Plan's "human-readable" bar implies one is needed.

Dental interoperability, general

UDI / GUDID

US regulatory

FHIR

ADA standards

EU MDR

DICOM / IHE

Field practice and problem scale

Commercial prior art

Implant Record Standards — Research Note

Overview

1. The headline finding

2. How implant records are actually stored today

3. Candidate structures

3.1 UDI / GUDID (FDA)

3.2 FHIR — US Core Implantable Device profile

3.3 FHIR — Dental Data Exchange IG

3.4 ADA standards family

3.5 EU MDR Article 18 implant card

3.6 DICOM and IHE PDI — the imaging half

3.7 ONC EHI Export (170.315(b)(10)) — a precedent worth knowing

3.8 Commercial prior art

4. Comparison

5. Open questions this research surfaces

Sources