Connecting Your Hospital to Smart Devices

Andrew Sauber / Software Engineer

At Stel, we observe patient care at a critical turning point. With many hospitals advancing to Stage 2 or even Stage 3 of the Meaningful Use objectives for EHR set out by the ONC, doctors and nurses will soon have a flurry of new signals at their disposal. What we as digital innovators and healthcare systems need to do is make these signals complete and useful.

The trend that we see is that all professional work will soon be supplemented by artificial intelligence — driven by data collection, filtering, modeling, and machine learning. Transportation and delivery workers are already enjoying the fruits of this labor: while you sit in traffic with your smartphone, couriers are re-routed in real-time by leveraging a firehose of vehicle position data. This is a magical experience, the kind that we must provide to our healthcare professionals to make our data efforts reap their full benefits. After all, improving patient outcomes to a never-before-seen standard is the goal that we share.

Improvement in care begins from day one.

The first activity that receives a huge boost in productivity from smart devices is collection tasks: the primary one being input/output charting. Fluid balance collection and recording is an especially time-consuming process for healthcare professionals, often resulting in boundless frustration due to unforeseen complications. The dissatisfaction with today's processes are exacerbated by the incomplete signal they provide, further diminishing their value. Automating this manual charting will alleviate this burden.

The next advancement is automated recommendations. Discharge time and medication dosage are early candidates for recommendations that can add value to I/O charting. By classifying a patient using all available data, we can provide suggestions to doctors and nurses to reduce readmissions and improve outcomes. The net result of these efforts is more time for nurses to do what they do best: take care of patients at a one-to-one level.

Stel is attacking this challenge from all angles. We have a set of data tools and a data strategy to help hospitals get connected to us as easily and quickly as possible. The components of this strategy are: models, connectivity, and interfaces.

Data Models

If you have an Electronic Health Records system, you have data models. These are the formal specifications of objects like Patients, Visits, Referrals, and Orders. The standards that have been most widely deployed by EHR providers are HL7v2, HL7v3, and FHIR, which are all maintained by the HL7 standards body.

Smart device providers will find great value in learning the data models that you use for the signal of interest, and how these models are formatted. For example, fluid balance data is often stored as an “Observation”, although it may be stored in your system as a “DeviceMetric”. There are two important attributes of each model that we need. The format, sometimes called a serialization format, of the data, and the fields that are available for each model. These fields are the (possibly nested) data attributes of each model, or relations to other models.

Here is an example of an Observation record for blood glucose levels in HL7v2, this format dates back to the first deployment of HL7 in 1981. The serialization format for HL7v2 is called “pipe and hat” because the fields are separated by pipe characters “|” and hat characters “^”, and each has a specified data type and storage size.

PID|||001677980||P.^van^de^Heuvel||19680219|M||||||||||929645156318|123456789|
PD1||||1234567890^LAST^FIRST^M^^^^^NPI|
OBR|1|341856649^HNAM_ORDERID|000002006326002362|648088^Basic Metabolic Panel|||20061122151600|||||||||1620^Hooker^Robert^L||||||20061122154733|||F|||||||||||20061122140000|
OBX|1|NM|GLU^Glucose Lvl|6.3|mmol/l||H|||F|||20061122154733|

Here's what that same type of Observation record looks like using the XML serialization format when using the FHIR XML namespace. HL7v3 also defines an XML namespace, and so has a very similar structure and appearance.

<Observation xmlns="http://hl7.org/fhir">
  <id value="f001"/>
  <status value="final"/>
  <code>
    <coding>
      <system value="http://loinc.org"/>
      <code value="15074-8"/>
      <display value="Glucose [Moles/volume] in Blood"/>
    </coding>
  </code>
  <subject>
    <reference value="Patient/f001"/>
    <display value="P. van de Heuvel"/>
  </subject>
  <effectivePeriod>
    <start value="2013-04-02T09:30:10+01:00"/>
    <end value="2013-04-05T09:30:10+01:00"/>
  </effectivePeriod>
  <issued value="2013-04-03T15:30:10+01:00"/>
  <performer>
    <reference value="Practitioner/f005"/>
    <display value="A. Langeveld"/>
  </performer>
  <valueQuantity>
    <value value="6.3"/>
    <unit value="mmol/l"/>
  </valueQuantity>
  <interpretation>
    <coding>
      <code value="H"/>
      <display value="Above high normal"/>
    </coding>
  </interpretation>
</Observation>

And finally, using the JSON serialization format, using the FHIR JSON Schema:

{
  "resourceType": "Observation",
  "id": "f001",
  "status": "final",
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "15074-8",
        "display": "Glucose [Moles/volume] in Blood"
      }
    ]
  },
  "subject": {
    "reference": "Patient/f001",
    "display": "P. van de Heuvel"
  },
  "effectivePeriod": {
    "start": "2013-04-02T09:30:10+01:00",
    "end": "2013-04-05T09:30:10+01:00"
  },
  "issued": "2013-04-03T15:30:10+01:00",
  "performer": [
    {
      "reference": "Practitioner/f005",
      "display": "A. Langeveld"
    }
  ],
  "valueQuantity": {
    "value": 6.3,
    "unit": "mmol/l",
  },
  "interpretation": {
    "coding": [
      {
        "code": "H",
        "display": "Above high normal"
      }
    ]
  }
}

Using an EHR that supports the most recent FHIR standard with the option for JSON serialization is ideal for data and device partners. This format is easy to parse using modern tools, is human readable, and has a well defined structure with a welcome quantity of useful fields — some of which can be used to refer to other important models.

Whether your health signal in question is modeled as an Observation, DeviceMetric, Procedure, or MedicationOrder, the format in which it's transferred and the fields available present a unique set of advantages and disadvantages that are of interest to device and service providers. At Stel, we have experience working with the formats presented here and more.

Connectivity

Once you have identified the models and serialization format relevant to the device at hand, the next step is getting it connected to your EHR. Smart device providers that make use of deep analytics, like Stel, read the raw data stream from any deployed devices. We then use the well-established techniques of statistical and deep learning to surface insights that make use of the entire data set. To make this happen, a data pipeline is used like the one shown below. To illustrate, let's use the example of monitoring a patient's weight in an inpatient setting. Weight data is first sent from the scale to the cloud, processed using statistical and machine learning, and then raw data and insights are sent back to your EHR.

The connection in this pipeline that requires some coordination between you and the device is the one between the device's analytics cloud and your EHR. To ensure secrecy, authentication, authorization, and anonymity (if desired) two main methods are used.

The first, which has been used by EHR service providers for many years, is a VPN tunnel into your hospital datacenter or the cloud-based virtual network of your EHR provider (if you subscribe to your EHR on a SaaS model). This method puts one or more machines of the device's cloud onto the private IP space of your EHR network. If a VPN tunnel is used, the device provider will need to know the connection protocol used by your EHR. This might be MLLP (used only with HL7v2) or HTTPS. In addition, the device provider will need to know the VPN protocol used by your healthcare system, this might be PPTP, IPSec, or OpenVPN.

Here's what a VPN tunnel looks like at a high level.
 


The tunnel might be from the device provider to your EHR's SaaS, which is another cloud-hosted application. The connection between the EHR provider and your hospital might be a VPN or it might simply be per-session HTTPS connections.

 

Whenever the tunnel is active, secrecy has been established and authentication has taken place. To enable authorization, permissions will need to be set for the user or service-id that allow the chosen models and fields to be accessed. The setup for these permissions vary from EHR to EHR system. Some have created “app-stores” for third-party providers that allow you to grant access to specific models and establish the network-level interface.

Anonymity, if required, needs to take place at a policy level. A data agreement should be established between the healthcare system and the device company, that would disallow reading or storing any Personally Identifiable Information (PII). The device cloud would use numeric or otherwise randomly assigned Patient IDs, already in use by most EHRs, to associate data with specific patients. These security considerations are illustrated below.

The second means of connecting a device cloud to an EHR is via an HTTPS API. The most common structure for an HTTPS interface is called REST, which stands for Representational State Transfer. In its most commonly-used form, HTTPS itself only provides secrecy, so you must provide your own means of authentication. Luckily, most EHR providers also act as OAuth providers, which means their cloud-based system can provide temporary authentication tokens for the device cloud in an automated fashion.

Once this authentication has taken place, HTTPS connections have the same security properties as a temporary VPN tunnel. Therefore, authorization and anonymity again need to be enforced using application-specific policies, such as the user-permissions system provided by your EHR.

Interfaces

A tool that we've built at Stel for rapid EHR integration and development is a unified developer interface for all of these systems. This is a JavaScript and Python module, which wraps the HL7v2 MLLP, FHIR REST, and other EHR interface specifications.

Here is an example of the Python API connecting to Allscript's Sunrise EHR, and reading the history of heart rate observations for a patient.

Python 2.7.10 (default, Jul 30 2016, 18:31:42)
IPython 5.1.0 -- An enhanced Interactive Python.

In [1]: import stelemr
In [2]: sc = stelemr.sunrise.SunriseConnection()
In [3]: sc.login_user()

In [4]: patientid = '5300200'
   ...: visitid = '5800270'
   ...: fromdt = '3/4/2014 02:03'
   ...: todt = '12/30/2016 00:00'
   ...:
   ...: result = sc.request('GetObservations',
   ...:                     patientid=patientid,
   ...:                     param1=visitid,
   ...:                     param2=fromdt,
   ...:                     param3=todt,
   ...:                     param4=stelemr.LOINC['heart_rate'])
   ...:
   ...: result_obj = result.json()
   ...: ob_lists = sc.obs_to_lists(result_obj)
   ...:
   ...: print ob_lists['18708-8'] == [
   ...:     (u'3/6/2014 4:52:00 PM',      u'56'),
   ...:     (u'3/6/2014 5:52:00 PM',      u'55'),
   ...:     (u'11/11/2015 10:18:00 PM',   u'91'),
   ...:     (u'9/24/2016 7:27:00 PM',     u'68'),
   ...:     (u'10/3/2016 5:17:00 PM',     u'87')
   ...: ]
   ...:
True

One advantage of this interface is its clarity and consistency for our team. Security is always enforced, using encrypted-at-rest configuration files. Performance enhancements are also employed such as persistent connections to the EHR and request buffering.

From your perspective as a healthcare system, the key thing to remember in terms of interface is to facilitate your developers in any way possible. Example data, a test connection, and read-only access to the production system are extremely helpful. The sooner the device cloud is able to send and receive data with the EHR, the faster the integration will take place. Challenges will arise if the application is developed purely from a model and connectivity specification.

Go Live

Once these three aspects of integration have been effectively tested and deployed, the benefits of a new smart device can be harvested to its full potential.

Accurate and consistent patient signals begin to appear automatically in your EHR, leading to better human intuition. This intuition is augmented by statistical insights and deep learning, enabling the near-future ubiquity of AI assisted medicine. Stel is excited to be a part of this transformation.

If you would like to speak with me about integrating Stel at your healthcare system or have any questions about smart devices or EHR integration, please send us an email at: sid@stel.life or carlos@stel.life.

Andrew SauberComment