> ## Content Index
> Fetch the complete content index at: https://www.ostering.com/llms.txt
> Use this file to discover other available public pages before exploring further.
# Integration and Interoperability (IN)
- URL: https://www.ostering.com/taxonomies/hospital-and-medical-devices/cri-integration-and-interoperability/
- Published: 2026-11-05T21:00:00.000Z
- Updated: 2026-11-05T20:41:15.288Z
- Description: Integration and Interoperability: 13 threats in the Hospital and Medical Device Threat Taxonomy, each with a principle, design measures and mappings.
- Author: Brett Crawley
[Taxonomies](/taxonomies/) › [Hospitals and medical devices](/taxonomies/hospital-and-medical-devices/) › Integration and Interoperability
**The Hospital · CRI-IN · suit 10 of 17 · 13 entries**
HL7 v2, FHIR, DICOM, integration engines, device integration middleware and regional exchange.
**Scope:** HL7 v2 feeds, FHIR APIs, DICOM networking and PACS/VNA, integration engines, device integration middleware, regional and national exchange, apps on FHIR, message replay and injection, unauthenticated interfaces, mapping errors, interface engine as a single point, third-party apps scopes.
Entries are ranked Ace (most severe) to 2. In the taxonomy the ID is a stable reference, not a severity: rate each finding in your own system.
*Text version: every entry is written out below, with its card prompts and mappings. The same text is in the PDF and Excel downloads on the [overview page](/taxonomies/hospital-and-medical-devices/#downloads).*
## The threats
### CRI-IN-A Unauthenticated orders and results feeds
**† Wrong or delayed treatment**
**Threat.** Interfaces accept HL7 orders, results and admissions from any sender that can reach the port, with no check of who sent them. A forged potassium result or a cancelled allergy lands in the record looking genuine, and clinicians treat the patient on it.
**Principle.** Every interface accepts clinical messages only from authenticated senders over protected channels, and rejects everything else.
**Design measures:**
1. Wrap HL7 v2 MLLP feeds in mutually authenticated TLS, or carry them over an authenticated tunnel between named endpoints.
2. Allowlist sending applications and facilities per interface, and reject messages whose sender fields do not match the authenticated peer.
3. Alert on messages from unexpected sources, and route clinically significant result changes for human review.
**Card prompts:**
- Which senders can reach each interface port?
- How does an interface check who sent a message?
- What would a forged result look like when it reached the record?
**Mappings:** STRIDE S, T · CAPEC-151, CAPEC-148, CAPEC-594 · CWE-306, CWE-940, CWE-346 · ATT&CK T1565.002, T1557 · MDS2 NAUT, TXIG, IGAU · IEC 80001-1; IEC 81001-5-1
### CRI-IN-K Integration engine as master key
**† Wrong or delayed treatment**
**Threat.** The integration engine sees, transforms and routes every clinical message, and its routes can be edited by a handful of accounts. Whoever controls it can rewrite results, redirect orders or copy every message out, across every connected system at once.
**Principle.** The integration engine is treated as a safety-critical system: changes to routes and transforms are controlled, reviewed and detectable.
**Design measures:**
1. Put route and transform changes through change control with two-person approval and versioned, signed configuration.
2. Separate engine administration from ordinary IT accounts, with phishing-resistant MFA and a dedicated management network.
3. Reconcile message counts and checksums between sending and receiving systems so silent rewrites show up.
4. Keep a tested standby engine and a documented manual workaround for each critical feed.
**Card prompts:**
- Who can edit routes and transforms in the integration engine?
- How are engine changes reviewed and detected?
- What could someone controlling the engine change across systems?
**Mappings:** STRIDE T, I, D, E · LINDDUN DD · CAPEC-385, CAPEC-176 · CWE-732, CWE-1220 · ATT&CK T1565.002, T1119 · MDS2 AUTH, AUDT, IGAU · IEC 80001-1
### CRI-IN-Q Device data charted without integrity
**† Wrong or delayed treatment**
**Threat.** Device integration middleware writes vital signs, pump rates and ventilator settings into the record without proving which device produced them or that values were not changed in transit. Wrong values become the charted truth that drives early-warning scores and treatment decisions.
**Principle.** Device data entering the record carries proof of its source and integrity, and is validated before it is charted.
**Design measures:**
1. Authenticate each device to the middleware and sign or MAC observations end to end, not only per network hop.
2. Require clinician validation of device data before charting, with the device identifier shown alongside each value.
3. Range-check and rate-check incoming values against physiology and the device's own reported limits.
**Card prompts:**
- How does middleware prove which device produced a value?
- What validation happens before device data is charted?
- Which scores and decisions consume charted device data?
**Mappings:** STRIDE S, T, R · CAPEC-384, CAPEC-194 · CWE-924, CWE-353, CWE-940 · ATT&CK T1565.002 · EMB3D TID-406, TID-407 · MDS2 IGAU, NAUT, TXIG · IEC 80001-1; IEC TR 60601-4-5
### CRI-IN-J Open DICOM nodes
**† Wrong or delayed treatment**
**Threat.** Imaging systems accept DICOM store, query and retrieve requests from any node that knows an application title, which is usually guessable. Images can be pulled out in bulk, or new images inserted into a patient's study, including files that also carry executable code.
**Principle.** DICOM associations are authenticated and limited to known peers, and every received object is checked before it reaches a study.
**Design measures:**
1. Use DICOM TLS with certificates per node, and restrict associations to an allowlist of application titles and addresses.
2. Never expose PACS or modality DICOM ports to the internet; reach remote sites through authenticated gateways.
3. Scan received DICOM files for embedded executable content and quarantine objects arriving from unexpected sources.
**Card prompts:**
- Which nodes can query or store to the imaging systems?
- Is any DICOM peer authenticated beyond its application title?
- How are received objects checked before joining a study?
**Mappings:** STRIDE S, T, I · LINDDUN DD, I · CAPEC-151, CAPEC-636, CAPEC-157 · CWE-306, CWE-923, CWE-434 · ATT&CK T1190, T1565.001 · MDS2 NAUT, TXCF, MLDP · DICOM PS3.15; IEC 80001-1
### CRI-IN-10 Identity mismatched across interfaces
**† Wrong or delayed treatment**
**Threat.** Each system keys patients differently and interfaces map identifiers with brittle rules. A mapping error, or a deliberate edit to a demographic message, merges two people or files results under the wrong patient, so treatment follows someone else's data.
**Principle.** Patient identity is matched on multiple strong identifiers end to end, and every merge or mismatch is detected and reviewed.
**Design measures:**
1. Use an enterprise master patient index and match on at least two independent identifiers in every interface.
2. Hold and queue messages whose identifiers fail to match rather than guessing, and alert the owning team.
3. Log and review every patient merge and unmerge, with the ability to trace and reverse filed results.
**Card prompts:**
- Which identifiers do interfaces use to match a patient?
- Who reviews mismatches flagged between systems?
- How would results filed to the wrong patient be noticed?
**Mappings:** STRIDE T, R · LINDDUN L, I · CAPEC-153 · CWE-694, CWE-706 · ATT&CK T1565.002 · MDS2 IGAU, AUDT · IEC 80001-1
### CRI-IN-9 Over-broad scopes for FHIR apps
**Threat.** Third-party and patient-facing apps get FHIR access through broad scopes or long-lived tokens granted once. A compromised or careless app can read whole populations' records through a legitimate API, and nobody notices because the calls look normal.
**Principle.** API access is granted per purpose, minimal in scope and time, and monitored for unusual volume.
**Design measures:**
1. Grant the narrowest SMART scopes needed, prefer patient-level over system-level access, and expire refresh tokens.
2. Rate-limit and alert on bulk queries and access patterns outside an app's declared purpose.
3. Review registered apps regularly and revoke those without an owner or current agreement.
**Card prompts:**
- What scopes and token lifetimes do FHIR apps receive?
- Who approves a new app's access, and for what purpose?
- Would bulk reads through a legitimate API raise an alert?
**Mappings:** STRIDE I, E · LINDDUN DD, U, Nc · CAPEC-1, CAPEC-57 · CWE-1220, CWE-863, CWE-770 · ATT&CK T1213, T1567 · MDS2 AUTH, MPII, AUDT · ISO 27799
### CRI-IN-8 Replayed and duplicated messages
**† Wrong or delayed treatment**
**Threat.** Interfaces cannot tell a new message from a resent one. A replayed medication order, admission or transfer is acted on twice: a second dose dispensed, a bed reassigned, a discharge triggered.
**Principle.** Every clinical message is unique, ordered and processed once, and duplicates are caught before they act.
**Design measures:**
1. Enforce unique message control IDs with sequence checking and reject duplicates within a defined window.
2. Make order processing idempotent so a resent order updates rather than duplicates.
3. Timestamp and sign messages so stale replays outside their validity window are refused.
**Card prompts:**
- How does each interface recognise a duplicated message?
- Which repeated messages could cause harm if acted on twice?
- Where are message order and uniqueness enforced?
**Mappings:** STRIDE T, R · CAPEC-60, CAPEC-594 · CWE-294, CWE-924 · ATT&CK T1565.002 · EMB3D TID-221, TID-407 · MDS2 TXIG, IGAU
### CRI-IN-7 Feeds that fail silently
**† Wrong or delayed treatment**
**Threat.** When an interface stops, queues fill quietly and the receiving system simply shows nothing new. Critical results, allergy updates or admissions stop arriving, and clinicians take the silence for normal.
**Principle.** Every critical feed is monitored end to end, and staff are told when data stops flowing.
**Design measures:**
1. Monitor queue depth and message age per critical feed, with alerts to an owner who is on duty around the clock.
2. Send heartbeat messages and show a visible stale-data warning in receiving systems when they stop.
3. Define and rehearse what wards do when a feed is down, including phoning critical results.
**Card prompts:**
- How would anyone know a critical feed had stopped?
- Who is told when interface queues back up?
- What do clinicians see when no new data arrives?
**Mappings:** STRIDE D · CAPEC-603 · CWE-392, CWE-778 · ATT&CK T1489 · MDS2 DTBK, AUDT · IEC 80001-1
### CRI-IN-6 Exchange trusts every participant equally
**Threat.** Regional and national record exchanges give every connected organisation the same reach. One compromised clinic, vendor or pharmacy can query or push records about patients it has never treated.
**Principle.** Access through exchanges is tied to a demonstrated care relationship, and each participant's use is monitored.
**Design measures:**
1. Require a care-relationship or consent assertion per query and audit it against later activity.
2. Apply per-participant quotas and anomaly detection, and suspend participants quickly when misuse shows.
3. Sign pushed documents at source so receivers can check provenance before filing them.
**Card prompts:**
- What can one participant query through the exchange?
- Is access tied to a care relationship with the patient?
- Who monitors each organisation's use of the exchange?
**Mappings:** STRIDE S, I, E · LINDDUN DD, L, Nc · CAPEC-21, CAPEC-122 · CWE-863, CWE-346 · ATT&CK T1199, T1213 · MDS2 AUTH, AUDT, NAUT · ISO 27799
### CRI-IN-5 Malformed messages break the engine
**Threat.** Parsers in engines and receiving systems trust message structure. Oversized fields, unexpected segments or crafted XML and JSON crash interfaces, inject content downstream, or exhaust resources, stopping clinical data flows hospital-wide.
**Principle.** Every interface validates structure and content against a strict profile before processing.
**Design measures:**
1. Validate messages against conformance profiles and reject or quarantine anything outside them.
2. Disable external entity resolution and limit message size, nesting and field length in all parsers.
3. Fuzz test interfaces before go-live and after upgrades.
**Card prompts:**
- Does every interface validate messages against a strict profile?
- What happens to a malformed or oversized message?
- Could one bad message stop data flows hospital-wide?
**Mappings:** STRIDE T, D · CAPEC-28, CAPEC-221, CAPEC-153 · CWE-611, CWE-776, CWE-1284 · ATT&CK T1499 · MDS2 SAHD, IGAU · IEC 81001-5-1
### CRI-IN-4 Shared interface credentials and certificates
**Threat.** Interface accounts, keys and certificates are hard-coded, shared across feeds and vendors, and tracked nowhere. One leaked secret opens many interfaces, and an expiring certificate stops several feeds at once without warning.
**Principle.** Each interface has its own managed credentials, with known owners, rotation and expiry monitoring.
**Design measures:**
1. Issue a distinct credential or certificate per interface and peer, stored in a secrets manager rather than config files.
2. Track expiry dates centrally and alert well before any certificate lapses.
3. Rotate interface secrets on schedule and whenever a vendor engineer or integrator leaves.
**Card prompts:**
- Which interface credentials are shared across feeds or vendors?
- Who owns each certificate, and who watches its expiry?
- How many interfaces would one leaked secret open?
**Mappings:** STRIDE S, D · CAPEC-560 · CWE-798, CWE-298, CWE-522 · ATT&CK T1552.001, T1078 · MDS2 NAUT, SGUD
### CRI-IN-3 Test interfaces wired to production
**Threat.** Test and training systems are connected to live feeds for convenience. Test orders and dummy results flow into real records, or copies of real patient data sit in test systems with weaker controls.
**Principle.** Test and live environments are separated, and only synthetic or de-identified data crosses into test.
**Design measures:**
1. Block network routes between test and production interfaces, and use distinct identifiers that live systems reject.
2. Use synthetic or de-identified data in test, and approve any exception formally with an expiry date.
3. Mark test messages clearly and alert if one ever arrives in production.
**Card prompts:**
- Are any test or training systems connected to live feeds?
- Where could test orders reach a real patient's record?
- What real patient data sits in test environments?
**Mappings:** STRIDE T, I · LINDDUN DD, Nc · CAPEC-176 · CWE-1269 · MDS2 DIDT, SAHD · IEC 80001-1
### CRI-IN-2 Patient data in interface logs
**Threat.** Engines keep full messages in logs, error queues and debug traces for troubleshooting, often for years. Support staff, vendors and anyone with log access can read complete patient records outside the controls of the clinical system.
**Principle.** Interface logs keep only what troubleshooting needs, for as short a time as possible, under the same protection as the record.
**Design measures:**
1. Mask or truncate patient identifiers and clinical content in logs by default.
2. Encrypt error queues and set retention limits that purge resolved messages.
3. Restrict and audit access to logs, including vendor support access.
**Card prompts:**
- How much patient data do engine logs and error queues keep?
- Who can read interface logs, including vendors?
- How long are full messages retained for troubleshooting?
**Mappings:** STRIDE I · LINDDUN DD, U, Nc · CAPEC-497 · CWE-532, CWE-312 · ATT&CK T1005 · MDS2 MPII, STCF, AUDT · ISO 27799
## Seen in the wild
- **Open PACS servers, 2019** ([CRI-IN-J](/taxonomies/hospital-and-medical-devices/cri-integration-and-interoperability/#cri-in-j)). Greenbone found about 590 imaging archive (PACS) servers reachable on the internet without protection, exposing records of about 24 million patients and hundreds of millions of images; an update later counted over a billion images. Sources: [Help Net Security: Confidential data of 24.3 million patients discovered online](https://www.helpnetsecurity.com/2019/09/18/confidential-patient-data/); [HIPAA Journal: Exposed medical image total rises to 1.19 billion](https://www.hipaajournal.com/update-issued-on-unsecured-pacs-as-exposed-medical-image-total-rises-to-1-19-billion/).
- **DICOM files carrying malware, 2019** ([CRI-IN-J](/taxonomies/hospital-and-medical-devices/cri-integration-and-interoperability/#cri-in-j)). Cylera researchers showed that the DICOM file format allows an image file to also be a working Windows executable, so malware could hide inside medical images protected as patient data (CVE-2019-11687). Sources: [NVD: CVE-2019-11687](https://web.nvd.nist.gov/vuln/detail/CVE-2019-11687); [GovInfoSecurity: Researchers, malware can be hidden in medical images](https://www.govinfosecurity.com/researchers-malware-be-hidden-in-medical-images-a-12388).
## Mappings
Across the 13 entries, the STRIDE counts are Tampering 8, Information disclosure 6, Spoofing 5, Denial of service 4, Elevation of privilege 3, Repudiation 3 (an entry can carry more than one). 13 map to CAPEC 3.9, 13 to CWE 5.0, 12 to ATT&CK v20.0, 2 to MITRE EMB3D and 7 to LINDDUN. The MDS2 capabilities a buyer should check first are IGAU (6), AUDT (6), NAUT (5). 7 carry the amber † for wrong or delayed treatment. A blank means nothing fitted well; a loose tag would mislead.
---
← [Records and Patient Data](/taxonomies/hospital-and-medical-devices/cri-records-and-patient-data/) · [Hospitals and medical devices overview](/taxonomies/hospital-and-medical-devices/) · [Networks and Wireless](/taxonomies/hospital-and-medical-devices/cri-networks-and-wireless/) →
*© 2026 Jonathan Brett Crawley. Licensed under [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) with additional permissions: see the licence on the [hospitals and medical devices overview](/taxonomies/hospital-and-medical-devices/).*