EMR Integration

Many hospital clients will want to integrate data with m.Care. The integration involves not only sending data to m.Care but also extracting data to send back to the EMR. When we designed m.Care, we wanted to ensure that our customers could get the data in and out of the system as easy as possible.

We also knew that there were a wide variety of EMR systems in use in these hospitals and that integration had to be flexible to adapt to what each system was capable of doing.

EMRs are not the only system that might want to integrate with m.Care. In a corporate wellness campaign, it might be the case that data feeds are being received from an HR system. The mechanisms in m.Care make it easy to integrate with various different back end systems and they are not limited to EMRs.

Some EMR Wisdom

Understand a bit about EMRs and their history can help you understand more about how integration works within m.Care.

As electronic medical records systems came onboard, they were first and foremost designed for use within a hospital or clinical setting. m.Care is designed for use OUTSIDE of the walls of a hospital and clinic. As such, there are differences in the way these system think.

m.Care is designed to work with patients who have left the building and who may receive services from more than one hospital or clinic. It’s totally possible for a person to, say, go to their doctor for complaints about the flu and then the next moment, receive say, chiropractic services. The doctor and the chiropractor may be using instances of m.Care. m.Care is designed to handle multiple uses of it’s system and provides a way to unify data to the patient. In most EMR settings, there is no notion of this or if it does exist, it tends to be complicated and hard to ensure that “single patient” view.

EMR systems tend to connect together other clinical equipment and systems by using either HL7 or FHIR based protocols. The problem with these protocols in the case of m.Care is that they contain no historical data. HL7 is a “current transaction” type of mechanism whereby if you are listening at the appropriate time with your system, you capture transactions from the HL7 network, but if you are not there, then there is no way to get those “old transactions”

In m.Care, we WANT those old transactions. We want to see what appointments have been scheduled, what the current prescription list looks like, old lab results, etc. We use this “old” data to tell the story of the patient and what’s been going on with them historically with their health.

So, the big difference between m.Care and EMR based systems:

  1. EMRs are meant for in-clinic or in-hospital use… m.Care is for outside of the hospital
  2. EMRs communicate amongst connected systems with HL7… m.Care wants historical record as well as current

Most EMR system vendors get around this lack of historical data by providing hospitals with data warehousing tools that allow them to go back in time to look at the patient’s “old data”. In m.Care, because we want that old data, the data warehouse view tends to be the most important source of data for inbound integration.

Most EMR systems can be easily overwhelmed by at-home patient data. m.Care gathers huge amounts of biometric and non-biometric data. If placed directly into an EMR, it tends to overwhelm the EMR. EMRs then, in an m.Care world, tend to receive m.Care data in the form of a report rather than raw biometrics so that the clinical use of the EMR is not overwhelmed with the m.Care data.

How fast do you want it?

Now that you’ve got kind of a view of how the EMR and m.Care data differs, the next thing to understand is that with m.Care we know that the timing of receipt of data is sometimes critical and sometimes not so critical. As such, there are a couple of mechanisms in m.Care that can be used to import and export data. These mechanisms can be broken into two classes:

  1. Batch Files
  2. Real Time

If the data needs to move in bulk or needs to be received, say, nightly, then folks tend to use the m.Care batch file import process. The batch file processes allow for batch file processing upon receipt (for imports into m.Care) and for exports by way of a secured file transfer protocol.

If the data is needed soonest, then the folks tend to use the m.Care real time mechanism. There are several real time mechanisms supported in m.care

  1. API – m.Care has a programmatic, real-time, RESTful services API which can be used to extract data at any time from the live production environment.
  2. Pushed Notifications – The m.Care platform can push notifications to a waiting RESTful server if available at the client location. This is used in conjunction with the monitoring plans in m.Care. When a key event is discovered in m.Care by way of a monitoring plan alert, 3rd party systems can be notified through the push notifications delivery system in m.Care. Push notifications can be done directly to a client web server (this takes additional programming from the m.Care staff) or by way of Google’s PubSub queueing mechanism.

Client Needs

When you are working with a client, you will need to understand then what systems they wish to integrate, where we will get the data that is typically needed by m.Care, and how they want data returned. You will also need to know the frequency of data feeds so that you can recommend one of the above solutions (ie, realtime versus batch based data exchange).

Data We Like in m.Care

To effectively use m.Care, we need to know the patients/subjects to be enrolled in the monitoring plan. This is the most fundamental piece of information. We also need to know if those patient’s have a unique identifier associated with them and in the hospital world, the answer to that question is “Medical Record Number”.

There are other kinds of data we like to get as well. Commonly, the data we receive comes to us via secured FTP. A client extracts the data we want to receive and places it out on an SFTP site that we set up for the client. Upon receipt some m.Care program will run to import the data received based one the file contents.

Typical files we receive then include:

  1. Enrollment/demographics
  2. Appointments
  3. Medications
  4. Admissions and ER usage information
  5. Lab Results

Other clients may have other files, but the above are the ones we typically receive from a hospital.

Data Formats

Given the above list of typical data we like to receive in m.Care, we have develop various mechanisms for getting that data into m.Care. The kind of “standard” mechanism is for the client to push us file feeds to our SFTP site. In order for the client to do that, they have to know what the data format of each file should contain.

m.Care has dealt with a lot of different systems and as such, we have multiple data formats available for each of the above file types. Some hospitals may not have all the information we like to have in one file format, but they do in a different file format. Or, it may be the case that the hospital can only reasonable obtain the data of the above types in the formats they provide to the m.Care team. No matter what, the m.Care system is designed to allow that data to flow in. Sometimes, as in the case of a customer insisting on their own file format, additional programming is needed to accept the file.

Assuming you have determine what format the data will arrive in, m.Care requires that configuration work be done to select from and assign a file format to a client so that the system knows what files to expect and can know in advance what the file will contain. In m.Care then, there is a tool that maps a set of file formats to the department for both import and export so that we have the knowledge we need about how files will come across and what they will contain.

Import File Specifications

Here is some additional information on the file import mechanisms of m.Care. Please check with the m.Care tech team for the latest information.

Export File Specifications

Here is some additional information on exporting data

Real Time API

Click here to read more about the m.Care real time API.