Hyperdrive
Changes for Integrations
Existing products integrating with Epic Hyperspace via COM-based APIs will need to be updated to work with Hyperdrive. Web applications hosted within, or launched from, Hyperspace may require changes to work with Hyperdrive. HL7, Web Services, DICOM, XML file drop, SMART on FHIR, and outgoing command line integrations will not require changes.If your integration is a website, the Prepare Web Content for Hyperdrive document summarizes changes that may be necessary to make your integration Hyperdrive-ready. This reference can help you evaluate if changes are needed for your application.
The details of our new API specifications can be found in the sections below. As you evaluate these APIs keep in mind that integrations developed for Hyperdrive may not work with the current Hyperspace client. Your application should support integration with both clients, or be side-by-side compatible with your current application, on the same workstation or server until all customers have transitioned off of Hyperspace.
Testing Integrations in Hyperdrive
We have developed testing harnesses to help you validate that your integration is successful with Hyperdrive:- The Hyperdrive Client Test Harness allows you to ensure your development is compatible with Hyperdrive.
- Supported workflows currently include: E-Signature, Login, Voice Recognition, Scan Acquisition, Scan Viewing, Scan Signature Deficiencies, FHIRcast, XML, and web content integration workflows.
- Functionality of this harness will be updated as we release additional features and enhancements.
- When Hyperdrive is used as a published application, Slingshot can make some integrations available on the endpoint device. Further detail can be found in the test harness documentation.
- The Hyperdrive Web Developer Test Harness allows you to validate that your website renders and functions correctly when hosted inside of Hyperdrive before it enters production. It allows you to see how a site will present either in an iframe or in a Hyperdrive embedded window.
- The client testing harness can also be accessed via Hyperspace for Mac. When using Hyperspace for Mac, keep in mind that most client integrations will only work on a Windows OS. Testing integrations via Hyperspace for Mac should be focused on URL launches for SMART on FHIR, HTTP GET, and SAML. If your integration requires more bespoke client integration technology that is supported by the test harness, you should test using Hyperdrive on a Windows workstation or VM. When installing Hyperspace for Mac, you will be prompted to configure a Hyperspace Web URL to connect to the fhir.epic sandbox.
- URL: https://fhir.epic.com/HSWeb_uscdi
Timelines
Most organizations transitioned their users to Hyperdrive in 2022 and 2023, though a few may not have completed this transition until later. During the transition, most organizations will have some users using Hyperspace and others using Hyperdrive, and both clients will be installed on the same workstations.
Tapestry Document Linker DMS Integration
read the spec
Desktop Generic Authentication
read the spec
Subspace Communication Framework
read the spec
Subspace User Session Management
read the spec
Other Subspace APIs
read the spec
E-Signature
read the spec
Scan Acquisition
read the spec
Scan Viewing
read the spec
XML Context Synchronization
read the spec
Speech Recognition
read the spec
FHIRcast
read the spec
Credit Card and Bank Account Integration
Subspace Encoder
read the spec
Web Services Encoder
read the spec
Kiosk Generic Authentication
read the spec
OpenID Connect
read the spec
Speech Recognition for Embedded Applications
read the spec
FHIRcast Content Sharing in Subspace
read the spec
FHIRcast Content Sharing enables external applications to share clinical information and measurements with Epic through a Subspace integration. This API describes how Subspace implements that content sharing using the Subspace Communication Framework.
mTLS Client Recognition for Enterprise Browsers
read the spec
Epic’s Hyperspace Web (HSWeb) platform uses mutual Transport Layer Security (mTLS) as a mechanism for recognizing that a browser connection originates from a known, trusted source. When a browser presents a valid client certificate during the TLS handshake, Epic treats the session as recognized rather than anonymous. If the certificate’s Subject Common Name (CN) also matches a configured Logical Workstation (LWS) record, Epic associates the session with that workstation, unlocking workflows that depend on workstation identity.
Enterprise Browser Printing
read the spec
Healthcare workflows frequently require printing to specific devices, trays, and formats, including thermal label printers, wristband printers, and high-volume document printers. The standard web printing surface (window.print()) is insufficient for these needs because it lacks silent printing, tray selection, raw data passthrough, and programmatic printer enumeration.