Smart Cards in Healthcare

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 PIV 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:

The HPC uses a PIV-style slot architecture with RSA-2048 or ECC 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:

The eGK uses PACE (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

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:

1. Authentication: Card private key proves patient or clinician identity.
2. Authorisation: Card-derived token carries consent flags for data categories.
3. 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.