Cybersecurity Instructions for Use
Overview
AdvaView is a stateless web application delivered as a web-based medical image viewer running within a standard desktop browser. It interfaces with several external systems including an authentication provider, a medical image archive, an external worklist, a viewer configuration service, a static file server, crash reporting software, and a user telemetry service.
The system integrator is responsible for configuring, deploying, and maintaining the infrastructure in which AdvaView operates. The cybersecurity responsibilities described in this section are delegated to the system integrator unless otherwise stated.
Network Ports and Interfaces
The end user interacts with AdvaView via a web browser over a port and domain configured by the system integrator.
| Interface | Protocol | Description | Authentication | Access Control | Direction | Endpoint |
|---|---|---|---|---|---|---|
| Viewer Configuration REST API | HTTPS REST API | Stores and retrieves user settings and hanging protocols | Cookie-based session tokens (access + refresh) | Per-provider and per-mode settings scoped to authenticated user | Bidirectional | Configured by system integrator |
| Medical Image Archive REST API | HTTPS REST API (DICOMweb) | Retrieves DICOM study metadata and pixel data | JWT/JWE launch token exchanged for cookie-based session tokens via Exchange Token | Study-level access scoped by launch token; user context returned at token exchange | Incoming | Configured by system integrator |
| Authentication Provider REST API | HTTPS REST API | Verifies user identities and issues tokens for AdvaView to authenticate and access image archives | User credentials (username/password) | N/A — this is the authentication boundary itself | Bidirectional | Configured by system integrator |
| External Worklist REST API | HTTPS REST API | Retrieves external DICOM worklist entries | JWT/JWE launch token obtained from the Medical Image Archive | Study access scoped by launch token | Incoming | Configured by system integrator |
| Static File Server | HTTPS | Serves all static files required to load AdvaView | None (public static assets) | N/A | Outgoing | Configured by system integrator |
| Crash Reporting REST API | HTTPS REST API | Captures application failures and supports timely fault diagnosis and resolution | API key | Scoped to AdvaView | Outgoing | Configured by system integrator |
| User Telemetry REST API | HTTPS REST API | Records user interactions and workflow events for analytics, usability assessment, and operational monitoring | API key | Scoped to AdvaView | Outgoing | Configured by system integrator |
Release Artifact Integrity Verification
Before deploying any release of AdvaView, the deploying party must verify the integrity of the release artifact to ensure it has not been tampered with or corrupted during distribution.
Verification procedure:
- Obtain the zip archive and associated SHA-256 checksum from the manufacturer's official distribution channel.
- Compute the SHA-256 checksum of the downloaded artifact using an appropriate tool for your operating system:
# Linux / macOS
sha256sum <artifact-filename>
# Windows (PowerShell)
Get-FileHash <artifact-filename> -Algorithm SHA256
- Compare the computed checksum against the manufacturer-provided value character by character.
- Do not proceed with deployment if the checksums do not match exactly. Contact the manufacturer to obtain a verified copy.
Deploying an artifact whose integrity has not been verified may introduce unauthorized code into a clinical environment and poses a patient safety risk.
Encryption in Transit
The system integrator shall ensure that all network communication between AdvaView and integrated services uses HTTPS. Unencrypted HTTP connections shall not be permitted in a production deployment. Valid, trusted TLS certificates shall be installed and maintained for all endpoints, and certificate validation shall not be bypassed in any configuration.
Minimum transport security configuration
AdvaView is a browser-hosted application and terminates no TLS connections of its own. The transport security of a deployment is determined entirely by the infrastructure the system integrator operates. The system integrator shall configure every endpoint that AdvaView connects to, and every endpoint from which AdvaView is served, to meet the following minimum requirements:
| Setting | Requirement |
|---|---|
| Minimum protocol version | TLS 1.2 |
| Preferred protocol version | TLS 1.3, negotiated wherever the client supports it |
| Prohibited protocol versions | SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 |
| Permitted cipher suites | Authenticated encryption (AEAD) suites only: ECDHE key exchange with AES-GCM or ChaCha20-Poly1305 |
| Prohibited cipher suites | Any suite using CBC-mode encryption, SHA-1 as MAC, RC4, 3DES, or NULL, anonymous or export-grade cryptography |
| Cipher suite preference | Server-side preference ordering shall be enabled, so that suite selection is not left to the client |
| Certificates | Valid and trusted for all endpoints; certificate validation shall not be bypassed in any configuration |
| Session cookie attributes | Session cookies shall be issued with Secure and HttpOnly set, and with a SameSite policy appropriate to the deployment topology |
A configuration conforming to these requirements admits the following cipher suites:
| Protocol | Cipher suite | Key exchange | Signature | Bulk cipher | Hash |
|---|---|---|---|---|---|
| TLS 1.3 | TLS_AES_256_GCM_SHA384 | ECDHE | from certificate | AES-256-GCM | SHA-384 |
| TLS 1.3 | TLS_AES_128_GCM_SHA256 | ECDHE | from certificate | AES-128-GCM | SHA-256 |
| TLS 1.3 | TLS_CHACHA20_POLY1305_SHA256 | ECDHE | from certificate | ChaCha20-Poly1305 | SHA-256 |
| TLS 1.2 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | ECDHE | RSA | AES-256-GCM | SHA-384 |
| TLS 1.2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | ECDHE | RSA | AES-128-GCM | SHA-256 |
| TLS 1.2 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | ECDHE | RSA | ChaCha20-Poly1305 | SHA-256 |
| TLS 1.2 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | ECDHE | ECDSA | AES-256-GCM | SHA-384 |
| TLS 1.2 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | ECDHE | ECDSA | AES-128-GCM | SHA-256 |
AdvaView is launched with a one-time launch token, which is exchanged at the backend for HttpOnly session cookies. All subsequent traffic — configuration, audit and DICOM image data — is authenticated by those cookies; the viewer stores no credential in browser storage and holds no long-lived secret. The exchange and refresh mechanisms are described in the AdvaView Interface Specification.
Because the session cookie is transmitted on every request, the system integrator shall ensure that session cookies are issued with the Secure and HttpOnly attributes set, so that they are never transmitted over an unencrypted connection or exposed to page scripts, and shall configure a SameSite policy appropriate to the deployment topology.
Mutual TLS is not required by AdvaView and is not used as an authentication factor. A system integrator may deploy mutual TLS at the infrastructure layer; doing so does not affect AdvaView's behaviour.
The manufacturer does not control the network environment in which AdvaView is deployed. Failure to enforce HTTPS, or use of a protocol version or cipher suite outside those specified above, may expose patient data and authentication credentials to interception or modification in transit.
The configuration above sets TLS 1.2 as the current minimum and TLS 1.3 as preferred. AdvaHealth is committing to require TLS 1.3 exclusively — removing TLS 1.2 support — for AdvaView deployments by March 31, 2027.
Data Confidentiality
AdvaView displays and processes protected health information (PHI), including DICOM medical images and patient data retrieved from integrated systems.
The system integrator shall establish and maintain controls to protect the confidentiality of patient data, including:
- Encryption in transit — enforce HTTPS for all data exchanges as described above
- Encryption at rest — ensure patient data stored within integrated systems is encrypted at rest using current industry-standard algorithms
- Access control — restrict access to AdvaView and integrated backend systems to authorised users only, enforcing role-based access and ensuring authentication tokens are properly scoped and validated
- Audit logging — maintain logs of user access and interactions with patient data in accordance with applicable regulatory requirements, and protect or eliminate any PHI that may appear in logs
- Data minimisation — limit exposure of PHI to only those components and personnel that require it for clinical or operational purposes
- Secure decommissioning — ensure patient data is securely erased from all systems when no longer required or when systems are decommissioned
Service Availability
AdvaView's availability depends on the continued operation of several integrated external services.
The system integrator shall implement controls to maintain availability, including:
- Deploying backend services with appropriate redundancy and failover mechanisms
- Implementing monitoring for all integrated services with alerting to detect and respond to disruptions promptly
- Deploying network controls to protect the application and its interfaces from availability attacks, including denial-of-service mitigations
- Applying security patches to all system components in a timely manner
- Maintaining verified backups of critical system data and configurations, and periodically testing recovery procedures
- Communicating planned maintenance windows to clinical stakeholders in advance
Loss of availability of AdvaView in a clinical environment may impact the ability of clinicians to access diagnostic images. The system integrator is responsible for ensuring that availability controls are appropriate for the clinical use context and risk profile of the deployment.
Anomaly and Security Event Detection
AdvaView provides interfaces that facilitate logging. Anomaly and security event detection are the responsibility of the system integrator, who is responsible for providing hosting and appropriate log monitoring endpoints. The system integrator shall implement monitoring of logs and configure alerting for anomalous or suspicious activity.
Backup and Restore
AdvaView is a stateless application and does not contain any data or configuration to back up. Backup and restore responsibilities apply exclusively to the integrated external systems maintained by the system integrator.
Secure Configuration of the Shipped Device
AdvaView's internal configuration is secure by default. The system integrator is responsible for hosting AdvaView and connecting it to external services in a secure manner, in accordance with the requirements described in this section.
Supporting Infrastructure Requirements
The following infrastructure controls are the responsibility of the system integrator:
- Protect data in transit using HTTPS
- Protect data at rest
- Provide denial-of-service mitigations
- Protect or eliminate PHI in logs
- Monitor logs for anomalous activity
- Maintain a stable network connection to support clinical use
End user hardware and software requirements:
- Any modern desktop browser
- Minimum screen resolution 1080p
- Stable network connection (low latency and at least 10 Mbps)
End-of-Support
AdvaView is distributed to partners for integration. The duration of support is defined in the partner agreement and may vary between partners. Unsupported versions must not be used in clinical environments as they may contain unresolved vulnerabilities.
Coordinated Vulnerability Disclosure
If a vulnerability is discovered in AdvaView that presents uncontrolled risk, partners will be notified within 30 days of the manufacturer becoming aware of it. Patches will be released within 60 days.
If AdvaView is involved in a cybersecurity incident, or if a vulnerability is discovered by a partner, report the event to the manufacturer.
Software Bill of Materials (SBOM)
An SBOM for AdvaView is available in CycloneDX 1.6 format upon request. To request a copy, contact the manufacturer.
Summary of System Integrator Responsibilities
| Responsibility | Topic |
|---|---|
| Verify SHA-256 checksum of release artifact before deployment | Release Artifact Integrity |
| Configure and enforce HTTPS on all network interfaces | Encryption in Transit |
| Maintain valid TLS certificates for all endpoints | Encryption in Transit |
| Encrypt patient data at rest in integrated systems | Data Confidentiality |
| Enforce role-based access control and token validation | Data Confidentiality |
| Maintain audit logs of user access to patient data | Data Confidentiality |
| Protect or eliminate PHI in logs | Data Confidentiality |
| Deploy redundant infrastructure to ensure availability | Service Availability |
| Monitor services and respond to disruptions | Service Availability |
| Implement denial-of-service protections | Service Availability |
| Maintain backup and recovery procedures for integrated systems | Service Availability |
| Monitor logs for anomalous and security-relevant events | Anomaly Detection |
| Report cybersecurity incidents and discovered vulnerabilities to the manufacturer | Vulnerability Disclosure |