FAQ

Not difficult. Here is what's involved.

Legal

• Subscription Agreement.
• Business Associate Agreement (for compliance with HIPAA or Canadian provincial health information protection laws).

Time commitment for deployment. Cortex Support will work with Enterprise staff to:

• set up secure communication channel between Enterprise and Cortex (1 day).
• establish and validate interoperability between enterprise systems and Cortex. This typically takes 1 day for simple cases (DICOM integration only) and ranges upward for more complex/custom requirements (HL7 integration, etc).

Procurement (optional)

• Storage Units provided by Enterprise, if Bring Your Own Storage (BYOS) option used.

Archiving package:

The retention period is configurable and depends on the business agreement in place between the Subscriber and Cortex. This is usually based on the Subscriber's jurisdictional requirements for retention of clinical data.

Sharing package:

Sharing of clinical content does not involve long term archiving of clinical data in the Cortex. Data is transferred to and kept in the Cortex solely to facilitate clinical case sharing. The maximum lifetime of a share is configurable and determines how long information associated with the share is kept in Cortex.

In the case of termination - by either Subscriber or Cortex - the clinical data archived in Cortex will be:

• Destroyed (deleted from Cortex), or
• Returned to the Subscriber and destroyed. If the storage units were provided by the Subscriber (BYOS - Bring Your Own Storage option), the unit(s) will be returned to the Subscriber asap. Otherwise, the Subscriber is expected to provide a temporary storage unit to facilitate the transfer of data from Cortex to the Subscriber. Following transfer, all Cortex copies of the transferred clinical data will be destroyed.

Clinical data in Cortex is archived in Healthcare IT-standard formats (e.g., DICOM Part 10, CDA/CCD documents, etc.) avoiding proprietary encodings, as they are not readily portable across vendors. All returned data will be in a standard format that can be easily uploaded to a third-party system.

Yes. After an encrypting agent (cloudLink or VPN) is installed on the workstation, the workstation becomes visible to Cortex. The user of the workstation can launch the Cortex Web Portal and preview exams for the patient of interest over the web. When a particular exam calls for advanced local viewing, the user can bring the exam of interest into their local workstation by selecting the exam from the Cortex Web Portal GUI.

Similar to the standalone workstation, the enterprise image viewer becomes visible to Cortex after a free encrypting agent (cloudLink) is installed to interface with the viewer's backend. Once the enterprise viewer becomes visible to Cortex, any exam stored in or shared via Cortex can be brought into the viewer for intranet-based distribution.

Chances are that the enterprise image viewer may also be natively supported by Cortex (running inside the Cortex infrastructure) without the need to transfer image data out of Cortex to the enterprise instance of the web viewer. Contact us to discuss your specific needs and preferences in this area.

Yes. Cortex can perform offsite backups to a variety of destinations (concurrently), including a client-owned AWS Glacier account. All that needs to be configured is the credentials for the AWS Glacier account and the destination vault name.

Cortex cloudLink uses TLS with mutual authentication (client certificates) to exchange enterprise data with Cortex. Communication between enterprise and Cortex systems is encrypted as well as protected by a digital certificate that is assigned to each enterprise during the initial setup. That (client) certificate must be included in all communications with Cortex. Other than the client certificate for mutual authentication, the following mechanisms are used to ensure secure communication:

• Protocol: TLS 1.2
• Key Exchange: DHE (Diffie-Hellman Ephemeral) and ECDHE (Elliptic Curve DHE) with RSA key equivalents of 2048 bits or more. Key exchange is signed with RSA
• Symmetric Cipher: AES256 or AES128 in GCM mode
• Hash Algorithm: SHA384 or SHA256

Yes. All communications with the Cortex - from both users and systems - are audited. The auditing approach is based on the peer-reviewed IHE ATNA Profile, an international standard. All events of interest (e.g., study transferred in/out, report viewed, portal logins, etc.) are recorded in the Audit Repository for complete traceability of who (which user/system) did what (transaction type) and from where (which IP address).

Both intrusion detection as well as automated intrusion prevention are performed. Cortex evaluates each request both in the context of the connecting user as well as in the context of the connecting system. Based on the results of this evaluation the request is allowed to be processed or not. For example, too many login attempts from a single IP address in a certain time period may result in automatic black-listing of the originating IP address.

Yes. All image and document data is AES256-encrypted before writing to storage. This is independent of any volume/device-level encryption that may be performed by the OS or storage unit. The encryption key used by Cortex is enterprise-specific. Therefore, content belonging to Enterprise A cannot be decrypted with Enterprise B's key.

All backups are encrypted as well, each using their enterprise-specific key.

Cortex keeps a checksum (SHA512) for each data blob it manages. Any change to that checksum, e.g., due to corruption of storage device, can be readily detected and corrected using a redundant copy of the affected blob (e.g., from another storage unit, or from offsite backup).

No. All patient browsing via Cortex Web Portal is zero footprint for Personal Health Information (PHI), meaning there is no residual patient data left on the connecting computer.

However, if data is transferred into another application (e.g., local PACS system, viewer from another vendor) then that application will naturally control the lifetime and treatment of PHI there.

In order for enterprise systems to send/receive data to/from Cortex, a secure communication channel must be established between the enterprise and Cortex. This can be done via VPN or via Cortex cloudLink.

Clinical and administrative data - including imaging exams, orders, reports, patient admissions and updates - can be passed to Cortex using the same communication protocols that are found within the enterprise, namely, DICOM and HL7. In order to send an imaging study, simply DICOM C-Store it to the Cortex DICOM Storage SCP endpoint - via the encrypting agent (cloudLink) or VPN. For retrieval, use the standard interfaces as well, e.g., DICOM C-Find, PIX, PDQ. In order to pass an imaging order, report or patient update, send the relevant HL7 messages to the Cortex HL7 endpoint.

Yes. Cortex has been designed from the ground up to keep track of issuers of Accession Numbers (coming from different RIS systems) and not to confuse those when two distinct RIS systems assign the same accession. With its built-in MPI, Cortex can do the same for patient identities (MRNs) coming from different HIS/EHR systems and possibly associated with the same person. Fully qualified MRNs (ID and issuer) as well as fully-qualified accession numbers are automatically embedded into DICOM and other data to avoid hazards and facilitate advanced use cases like import of external studies.

Cortex can help. With a built-in terminology conversion engine, Cortex can localize external imaging exams and reports coded in one vernacular (that of external enterprise) and present them in the vernacular of the local enterprise.

The Cortex DICOM Conformance Statement can be found here.

The Cortex HL7 Conformance Statement can be found here.