A hospital's clinical data moves between machines far more than between people, yet the identities those machines use (device certificates, DICOM node entries, interface engine logins, SFTP keys and FHIR client keys) are usually tracked in five different places or not at all. Biomedical engineering knows the devices, the integration team knows the channels, the EHR team knows the API clients and identity teams often see none of it. This guide covers one task: building and running a single machine identity inventory across connected medical devices, HL7 v2 and FHIR interfaces and the integration engines between them, and using it to drive ownership, rotation and revocation. Protocol hardening is covered in the HL7 v2 and Clinical Interface Engine Security Guide, device security programmes in the Medical Device Security Guide and clinician access in the Healthcare Identity Security Guide. It is written for healthcare security, identity, integration and clinical engineering leads.
Source note: HIPAA, HL7 FHIR, SMART, IHE and DICOM requirements below are summarised from the eCFR and standards pages listed in the references, as checked in November 2026. Confirm against the official text before relying on it.
Key takeaways
- HIPAA already counts software as an accessor. The 164.312(a)(1) access control standard covers persons and software programs granted access rights, and 164.312(d) requires verifying any person or entity seeking access to ePHI.
- One inventory, three populations. Devices, interfaces and engines share identities and dependencies; tracking them separately hides the credential that links them.
- The integration engine is the hub. It holds credentials to most clinical systems, so its connector inventory is the fastest route to finding the rest.
- FHIR backend clients should hold keys, not passwords. SMART Backend Services uses signed JWT client assertions, a hosted JWKS URL for rotation and access tokens of five minutes or less.
- Clinical safety sets the pace. Rotate and revoke through change control with clinical owners, because a broken results interface is a patient safety event.
What counts as a machine identity in a hospital
| Population | Identity | Credential or identifier | Usually owned by |
|---|---|---|---|
| Medical devices | Device service and maintenance accounts | Local passwords, often vendor managed | Clinical engineering and the manufacturer |
| Medical devices | Device network identity | 802.1X certificate, MAC address, TLS client certificate | Network team |
| Imaging | DICOM nodes (modalities, PACS, workstations) | Application entity configuration plus TLS certificates where DICOM TLS is used | Imaging informatics |
| HL7 v2 interfaces | Sending and receiving systems | Network endpoint, MLLP port, TLS certificate or VPN where used | Integration team |
| Integration engine | Connector accounts | Database logins, SFTP keys, API credentials, web service passwords | Integration team |
| FHIR APIs | Backend service clients | Client ID with registered public keys (JWKS), system/ scopes | EHR and API platform team |
| FHIR APIs | Partner and app clients | OAuth client registrations, client secrets, mutual TLS certificates | EHR team and third-party risk |
| Audit and security | Secure nodes and audit repositories | X.509 certificates for node authentication (IHE ATNA) | Security and integration |
Some of these are identifiers rather than secrets. A DICOM application entity title or an HL7 sending facility field names a system but proves nothing about it; record them because they are how clinical systems recognise each other, and pair each with whatever actually authenticates the connection, such as a TLS certificate, a VPN or a network control.
Why the three populations must share one inventory
A single clinical workflow crosses all three. A laboratory analyser sends results through middleware, over an HL7 v2 interface, into the engine, which writes to the EHR database with a connector login, while a FHIR backend client pulls the same results into a population health platform. Revoke the wrong credential and results stop; miss one and a decommissioned system keeps a path to ePHI. Inventories split by team cannot answer the questions that matter in an incident or a decommission:
- Blast radius: if this engine's credential store leaks, which databases, partners and APIs are exposed?
- Dependency: if we rotate this database login, which channels and which clinical services fail?
- Decommission: when this modality or partner goes, which certificates, keys and accounts must be revoked?
- Vendor exit: which identities does this manufacturer or integrator know or control?
Discovery sources
| Source | What it yields | Notes |
|---|---|---|
| Integration engine channel and connector configuration | Every destination, its credential type and the account used | Exports and configuration maps can contain cleartext credentials: handle exports as secrets |
| Medical device inventory and manufacturer disclosures (MDS2) | Device accounts, authentication capabilities, remote service connections | Ask for the MDS2 form at procurement and file it against the asset |
| PACS and modality configuration | DICOM node list, TLS use, which nodes may query and retrieve | Unknown nodes accepted by default are a finding in themselves |
| EHR and FHIR authorisation server client registry | Backend and app clients, scopes, key registration method, owner contact | Compare against contracts to find clients with no current agreement |
| Directory and database account listings | Service accounts used by interfaces and devices, password age, last use | Match each to a connector or device, flag orphans |
| Certificate authority and network access control records | Device and node certificates, 802.1X identities, expiry | Expiry dates feed the renewal calendar |
| Network flow monitoring | Which systems actually exchange HL7, DICOM and FHIR traffic | Confirms consumers and finds undocumented interfaces |
| Vendor remote access tooling | Accounts manufacturers and integrators use to service devices and engines | Tie each to a contract and a sponsor |
The inventory record
Use one record per identity, linked to assets, connections and contracts. Keep it in the CMDB or identity governance tool the organisation already trusts; the schema matters more than the product.
- Identity: name, type (account, key, certificate, client registration, node entry) and where the secret is stored.
- Bound to: the device, application or engine instance using it, and the system it authenticates to.
- Clinical service: the workflow that depends on it (results, orders, imaging, medication) and its clinical owner.
- Technical owner and vendor: who can change it, and whether a manufacturer or integrator also knows it.
- Privilege: what it can do on the target, such as insert results, read all patients or system/*.read.
- Lifecycle: created, last rotated, last used, expiry, next review, contract end date.
- Data: whether ePHI flows, and whether it leaves the organisation (business associate relationship).
Interface engines and HL7 v2 connectors
Start the inventory here: the engine's channel list enumerates most clinical connections in one place. The live interface guide covers protocol hardening; for inventory purposes, focus on four checks per connector.
- Unique credential: one account per connector and destination, so revoking one partner does not break five channels.
- Least privilege: the account can do only what the channel needs on the target, typically insert or read on specific tables or endpoints.
- Secret location: credentials referenced from a vault or the engine's protected store, not typed into channel definitions that end up in exports and source control. ATT&CK records credentials harvested from configuration files as Credentials In Files (T1552.001).
- Owner and expiry: each connector identity linked to an interface request, a clinical owner and, for external partners, a business associate agreement. See the HIPAA Business Associate Agreements Guide.
FHIR clients and APIs
FHIR R4's own security page states that FHIR is not a security protocol and relies on security defined elsewhere: OAuth and SMART on FHIR for authorising clients, OpenID Connect for users, and mutual TLS, API keys or signed JWTs for business-sensitive exchanges, all over TLS 1.2 or higher. For system-to-system access, SMART App Launch 2.2.0 defines Backend Services.
| SMART Backend Services element | Requirement (SMART App Launch 2.2.0) | Inventory and governance action |
|---|---|---|
| Grant | OAuth 2.0 client credentials, confidential client only | Record each backend client and its owning system |
| Client authentication | Signed JWT assertion (RFC 7523); clients support RS384 and ES384 | No shared client secrets for backend services |
| Key registration | Hosted JWKS URL strongly preferred; static JWKS strongly discouraged | Record the method; plan migration of static registrations |
| Assertion lifetime | exp no more than five minutes ahead; jti checked for replay | Confirm the authorisation server enforces both |
| Access token | expires_in should not exceed 300 seconds; refresh tokens should not be issued | Alert on clients holding long-lived tokens |
| Scopes | system/ scopes, granted only as pre-authorised | Review scopes against purpose; flag broad wildcards |
A hosted JWKS URL lets a client rotate keys by changing what the URL serves; for static registration, which it strongly discourages, the specification notes that including both the current and successor keys helps. Token theft is recorded in ATT&CK as Steal Application Access Token (T1528). See the SMART on FHIR Security Guide and the API Key Management Guide.
Medical devices and imaging nodes
- Device accounts: record service and maintenance accounts from the MDS2 and commissioning documents, mark which can be changed by the hospital and which only by the manufacturer, and change those you control at installation.
- Network identity: where devices support 802.1X with certificates, record certificate subject, issuer and expiry against the asset; where they do not, record the compensating network control.
- DICOM nodes: DICOM supports TLS for DIMSE and HTTPS for DICOMweb but, in its own words, facilitates encryption rather than mandating it. Record for each node whether TLS is in use, and treat the node list as an access control list that needs an owner. See the DICOM and PACS Security Guide.
- Node authentication: IHE ATNA requires machine-to-machine connections that may expose private information to authenticate with TLS and X.509 certificates (Authenticate Node, ITI-19), and allows a local chain of trust rather than public browser roots. Its certificates belong in the inventory and the renewal calendar.
- Vendor knowledge: flag every identity a manufacturer can use remotely, and require named, logged access for it. See the Device and IoT Identity Guide.
Running it: rollout, rotation and revocation
The rollout sequence below is NHI Mgmt Group's recommended approach.
- Set governance: a joint group of integration, clinical engineering, EHR, identity and clinical safety leads, with authority to approve credential changes.
- Seed from the engine: export the connector list (as a protected file), create an identity record per connector and resolve each target account.
- Add FHIR clients and DICOM nodes from the authorisation server registry and PACS configuration.
- Add devices from the medical device inventory and MDS2 forms, starting with network-connected devices that exchange ePHI.
- Reconcile: compare against directory and database accounts and network flows; every unmatched account is an orphan to investigate, every unmatched flow an undocumented interface.
- Prioritise: external-facing and partner identities, shared credentials, high-privilege database logins and anything a vendor knows.
- Rotate through change control: test in the engine's test environment, schedule with the clinical owner, keep the old credential valid during a short overlap where the target allows, and keep downtime procedures ready to fall back on.
- Revoke on events: decommission, contract end, vendor staff change and suspected exposure each trigger revocation from the inventory record.
Decision guidance
The approaches below are NHI Mgmt Group recommendations.
| Situation | Approach |
|---|---|
| Large health system with an identity governance tool | Model machine identities in the IGA tool with owners and certification campaigns |
| Community hospital or small practice | A controlled register in the CMDB or a spreadsheet with restricted access, reviewed quarterly; prioritise the engine and external partners. See the Cyber Security for Dental and GP Practices Guide |
| Credential the hospital cannot change (manufacturer controlled) | Record, segment, monitor its use and raise it with the manufacturer at contract review |
| Partner still using a shared secret for FHIR backend access | Agree a dated migration to signed JWT assertions with a hosted JWKS |
Detection and measurement
HIPAA 164.312(b) requires mechanisms to record and examine activity in systems containing ePHI. For machine identities, log and alert on: a connector account authenticating from a host other than the engine, interactive logons by interface or device service accounts, new FHIR client registrations and scope changes, token requests from unknown clients, DICOM associations from nodes not in the inventory, and use of vendor service accounts outside agreed windows. FHIR AuditEvent and IHE ATNA audit records give a structured trail for API and node activity. Misuse of these accounts appears in ATT&CK as Valid Accounts (T1078).
- Coverage: percentage of engine connectors, FHIR clients, DICOM nodes and networked devices with an identity record and named owner.
- Orphans: service accounts and client registrations with no matching connector, device or contract (target zero).
- Shared credentials: credentials used by more than one connector or device (should fall to zero).
- Credential age: median age of connector passwords and keys; share of FHIR backend clients on hosted JWKS.
- Revocation lag: days from decommission or contract end to revocation of every linked identity.
- Certificate expiries: device, node and interface certificates expiring in the next 60 days without a scheduled renewal.
Framework mapping
| Control objective | HIPAA Security Rule | NIST SP 800-53 r5 | NIST CSF 2.0 |
|---|---|---|---|
| Inventory of devices, software and services | 164.308(a)(1) risk analysis inputs | CM-8 | ID.AM-01, ID.AM-02 |
| Access limited to authorised software programs | 164.312(a)(1) | AC-2, AC-6 | PR.AA-05 |
| Unique identification | 164.312(a)(2)(i) | IA-9 | PR.AA-01 |
| Entity and device authentication | 164.312(d) | IA-3, IA-5, SC-17 | PR.AA-03 |
| Transmission protection | 164.312(e)(1) | SC-8 | PR.DS-02 |
| Audit of machine activity | 164.312(b) | AU-2, AU-6 | DE.CM-03 |
Common failure patterns
- Inventories split by team: biomedical, integration and EHR registers that never meet, so nobody can answer what a single leaked credential exposes.
- One database login for every channel: rotation becomes a hospital-wide outage risk, so it never happens.
- Credentials in channel exports: exports shared with vendors or committed to repositories carrying cleartext connector passwords.
- Partner clients outliving contracts: FHIR client registrations and SFTP keys still active years after the relationship ended.
- Node lists without owners: PACS accepting associations from any configured node, including retired modalities whose addresses were reused.
- Vendor-known credentials never changed: device and engine accounts the integrator set at go-live, unchanged after their staff moved on.
Practitioner checklist
- Create one machine identity inventory covering devices, DICOM nodes, HL7 and FHIR interfaces and integration engine connectors.
- Seed it from the engine's connector list, then add FHIR client registrations, PACS nodes and MDS2-documented device accounts.
- Record for every identity its clinical service, clinical and technical owner, vendor knowledge, privilege and lifecycle dates.
- Give every connector its own least-privilege credential, stored outside channel definitions.
- Require signed JWT client authentication with hosted JWKS for FHIR backend clients and tokens of five minutes or less.
- Record TLS and certificate status for DICOM and HL7 connections, and put every certificate in a renewal calendar.
- Reconcile against directory, database and network flow data each quarter and resolve orphans.
- Rotate through clinical change control with tested rollback and downtime procedures.
- Trigger revocation from decommission, contract end and vendor staff changes.
- Report the six metrics above to the joint governance group.
Standards and references
- eCFR: 45 CFR 164.312 Technical safeguards
- HL7 International: SMART App Launch, Backend Services
- HL7 International: SMART App Launch, Client Authentication: Asymmetric (public key)
- HL7 International: FHIR R4 Security
- IHE: ITI Technical Framework, Audit Trail and Node Authentication (ATNA)
- DICOM Standards Committee: DICOM Security
Related NHI Mgmt Group resources: HL7 v2 and Clinical Interface Engine Security Guide · Healthcare Identity Security Guide · Medical Device Security Guide · Service Account Security Guide