Smart Cards in Healthcare
Smart card deployments in healthcare: electronic health insurance cards, health professional cards, and patient identification.
Smart Cards in Healthcare
Healthcare smart cards store insurance eligibility, patient identifiers, emergency medical data, and clinician credentials — directly on the card or as cryptographic pointers to server-side records. The German eGK (elektronische Gesundheitskarte), the Belgian BeID, and US healthcare PIVPIVIdentityUS federal identity card standard.Click to view → cards represent mature deployments; emerging standards link smart cards to FHIR APIs for real-time data access.
Health Professional Cards (HPC)
Health Professional Cards authenticate clinicians to healthcare systems and authorise access to patient records. The European HPC framework (CEN EN 14890) defines:
| Application | Purpose |
|---|---|
| HPC Authentication Cert | Proves clinician identity to hospital IS |
| HPC Signature Cert | Qualified electronic signature on prescriptions |
| HPC Encryption Cert | Receive encrypted messages / patient data |
| Emergency Access Flag | Override normal access control in emergency |
The HPC uses a PIV-style slot architecture with RSARSACryptographyPublic-key algorithm for smart card signatures and key exchange.Click to view →-2048 or ECCECCCryptographyEfficient public-key cryptography using elliptic curves.Click to view → P-384
keys stored in the secure element. Signing a prescription
triggers a PKCS#11 C_Sign call mapped to:
APDU: 00 2A 9E 9A 30 <48-byte SHA-384 digest>
Resp: <signature bytes> 90 00
German eGK (Electronic Health Card)
The eGK is the most widely deployed health smart card globally, issued to all ~73 million statutory insured persons in Germany. The card architecture under gematik specification:
| Data Object | Storage | Access |
|---|---|---|
| KVNR (insurance number) | Chip, plaintext | Any reader |
| Personal data (name, DOB, address) | Chip, AESAESCryptographyNIST symmetric block cipher for smart card encryption.Click to view →-256 | Authenticated reader |
| Emergency data (blood type, allergies) | Chip, PIN-protected optionally | Emergency override |
| eAU (electronic sick note) | Server-side | Card + server mutual auth |
| ePA (electronic patient record) | Server-side | Card + PACE auth |
The eGK uses PACEPACEApplicationStrong ePassport authentication protocol.Click to view → (Password Authenticated Connection Establishment) for PIN entry — preventing eavesdropping on the PIN over the contact interface — and BAC-equivalent chip authentication for server-side record access.
ePA (Electronic Patient Record) Access Flow
Patient card (eGK) + card terminal
│
├── PACE PIN authentication
│
└── TLS mutual authentication to ePA server
│
└── gematik connector (in clinic)
│
└── FHIR R4 API (/Patient, /Observation, /MedicationRequest)
The ePA server stores FHIR-structured records. The eGK's ECC key pair authenticates the session; access tokens are issued per-card, per-session.
Insurance Card Standards
| Country | Card | Standard | Key Features |
|---|---|---|---|
| Germany | eGK | gematik / EN 14890 | PACE, ePA FHIR, eAU |
| Belgium | BeID | ISO 7816ISO 7816StandardPrimary standard for contact smart cards.Click to view → / BELPIC | National PKI, dual certificate |
| France | Carte Vitale 2 | SESAM-Vitale | Insurance eligibility, offline verification |
| Estonia | ID-ka / e-Health | DigiDoc / CDOC | Full PKI, e-prescription |
| Japan | My Number Card | JPKI | Insurance + national ID combined |
FHIR Integration
Modern health card deployments expose data via FHIR (HL7 FHIR R4/R5) rather than storing records directly on the chip. The smart card provides:
- Authentication: Card private key proves patient or clinician identity.
- Authorisation: Card-derived token carries consent flags for data categories.
- Audit trail: Every access is logged with the card's certificate serial number.
# Example: FHIR Patient record fetch with smart card auth
import requests
# Token obtained via card-based OAuth2 PKCE flow
headers = {"Authorization": f"Bearer {card_derived_token}"}
response = requests.get(
"https://fhir.example.de/fhir/Patient/12345",
headers=headers,
cert=("/path/to/client.crt", "/path/to/pkcs11-key.pem"),
)
Security and Privacy Considerations
- Minimal on-card storage: Store only what is needed offline; server-side FHIR minimises PII exposure if the card is lost.
- Selective disclosure: FHIR scopes (
patient/Observation.read) limit what each application sees — clinicians access clinical data; insurers access billing codes only. - Emergency access: Standardise emergency override procedures; require dual-key authorisation to prevent abuse.
- Revocation: Healthcare cards have a 5-year typical validity; maintain OCSP infrastructure sized for millions of simultaneous healthcare encounters.
Use the Card Identifier to identify unknown healthcare cards, and EAL Comparator to compare security certifications of different healthcare card platforms.
Frequently Asked Questions
Our guides cover a range of experience levels. Getting Started guides introduce smart card fundamentals. Security guides address Common Criteria certification and key management. Programming guides target developers working with APDU commands, JavaCard applets, and GlobalPlatform card management.