What is the Healthjump Agent?
When we connect to on-premise EHR / PM systems, Healthjump requires the installation of the Healthjump agent. The agent allows Healthjump to safely and securely connect, extract, and transfer data to the Healthjump data lake.
We won’t be delving too deeply into the finer details of the TLS handshake as it’s a very complicated, technical process. In the most simple terms, it’s a series of messages exchanged between the Healthjump agent and Healthjump wherein the server’s public key and SSL certificate are authenticated, culminating in creating a session key, which is what encrypts the connection between the client and the server. Combined, the total array of security protocols utilized between Healthjump and the agent host is the Cipher suites.
Cipher suites dictate how the entire process plays out. The agent running on the EHR server or application server sends the Healthjump server a list of the cipher suites it supports, and the server will choose a mutually supported cipher suite that it deems most secure. Depending on the version of TLS being used, this may happen before the handshake or in the very first step.
Example Cipher Suite:
To understand how our security protocols play out during Healthjump agent activity, let's walk through what the Healthjump agent is doing when it's time to transmit data back to the Healthjump server.
At the installation time, you or your Healthjump Installation engineer would have requested and set a nightly extraction time. This time the agent will begin to pull the data each day. The Healthjump Agent will wait for this time each day before extracting data from the source EMR/PM. It does this by polling via API calls to the Healthjump Cloud servers and waiting for a response that tells the agent the time has come to run the extraction logic.
- Key Exchange: When polling the Healthjump server, the agent initiates the handshake by sending a "hello" message to the server. The message will include which TLS version the client supports, the cipher suites supported, and a string of random bytes known as the "client random." In reply to the client hello message, the server sends a message containing the server's SSL certificate, the server's chosen cipher suite, and the "server random," another random string of bytes generated by the server. The SSL certificates are valid for 13 months, and are renewed 60 days before expiration.
Note: Healthjump utilizes AWS load balancers that support a wide range of Cipher Suites to ensure connection compatibility. That being said, we also refuse connections to outdated or insecure cipher suites that could put the data at risk. For this reason, Healthjump advocates against installing the agent on personal laptops and workstations which do not undergo the same regular security and os updates that a standard EHR or Application server would.
Once the agent and Healthjump have agreed upon a secured and mutually supported cipher suite, the Healthjump servers will respond to the agent API polling at the designated time by sending prebuilt SQL scripts specifically written to extract the Healthjump data model from the source EHR database. Once the extraction jobs are received by the EHR database server, the scripts are executed by the server hosting the agent. The results of the executed scripts are temporarily stored in the application directory.
- Authentication: When the connection handshake is agreed upon, the Healthjump Server will send the agent its SSL certificate. The agent checks to make sure the certificate is "authentic". This is an extremely important step. To truly have a secure connection, you can’t just encrypt your data, you also need to know it’s being sent to the right website/organization. SSL/TLS certificates provide that authentication.
Once a data file has been extracted from the source database, the file is sent via the encrypted connection to the Healthjump data lake for processing.
- Cipher: Healthjump Servers leverage various Bulk Data Encryption algorithms to ensure Data being transferred between the client and server securely. AES_128_GCM represents it in the example above. To see the full range of supported suites, click here.
Healthjump utilizes Amazon Simple Cloud Storage (S3). Data contained within the Healthjump S3 deployment are encrypted via AES256 utilizing Amazon S3-Managed Keys (SSE-S3). Once all of the data has been received for the evening, the agent returns to a "long-polling" state and awaits commands to extract data again.
- MAC: The Hashing Algorithms are fixed-sized blocks representing data of arbitrary size. They are used to verify the integrity of the data being transmitted. When the message is created, a hash of the original message is generated using the agreed-upon algorithm (i.e., MD5, SHA, SHA256, SHA384, SHA512). The receiver uses that hash to ensure that the data is the same as when the sender sent it.
Healthjump is dedicated to the security of the data we have been entrusted to manage, from transmission to storage. We regularly update our load balancers and servers to ensure we are supporting the latest available cipher suites and utilize the latest encryption algorithms supported by AWS S3.
Furthermore, maintenance of our existing supported cipher suites is an important function of certificate lifecycle management to ensure that our certificates are up-to-date with industry best practices.