FREQUENTLY ASKED QUESTIONS
Have a question beyond this FAQ?
What are APIs and how do they work?
APIs are sets of requirements that govern how one application can talk to another. APIs expose some of a program’s internal functions to the outside world in a limited fashion. That makes it possible for applications to share data and take actions on one another’s behalf without requiring developers to share all of their software’s code.
What is Emissary?
Emissary is a middleware application that helps electronic medical record (EMR) customers achieve third party software integration through real time RESTful APIs. It provides a robust set of services that read from and write to the native EMR data repository through EMR vendor-supported software modules. It standardizes EMR integrations through universal real-time APIs and a unified data model. Emissary also provides tools to assist with the monitoring and management of the environment, including advanced security and auditing features.
What are the benefits of Emissary?
The Emissary approach drastically simplifies the integration of software with EMRs. Through Emissary, software connectivity to EMRs happens in days, not months, without the need for painful one-off data-mapping exercises. With real-time data moving through web services, software applications exchange comprehensive clinical, financial, and administrative data with a health system’s core EMR. The health system’s EMR platform typically contains all coding systems (e.g. LOINC®, SNOMED® or ICD). If the EMR stores these code sets, Emissary exposes them, helping to normalize the related data. Using Emissary web services reduces or eliminates interface maintenance costs. Real-time data exchange reduces the need for replicating data in external databases. While data sourced from traditional HL7 feeds must be stored in the receiving system’s database, Emissary web services allow the requesting system to obtain EMR data on demand.
How are you different than other middleware integration products?
On the surface level, Emissary looks the same as other middleware integration productions, but where it shines is when you look under the hood. Other integration products leverage HL7 and require integration engines on both the hospital system them and within their own infrastructure. In order to populate their APIs they have built databases or data lakes which hold all of the systems highly secure data that has been collected to feed the APIs.
Emissary leverages the native EMR infrastructure in order to securely and quickly transfer the data. Emissary is a pass through which creates a unified data model that is EMR agnostic.
How is Emissary different than traditional HL7 integration engines?
Emissary leverages the EMRs underlying core data services. These often are the same services that facilitate reading and writing of data for the EMR’s own front-end applications, so the need for traditional triggering and batch processing of outbound interfaces is eliminated.
Because HL7 only accesses data when there's a defined data structure, third party vendors that rely on HL7 integration must populate a separate data repository. Other integration companies rely solely on HL7 and/or the vendor’s limited public APIs to feed and persist data in their own database – so their APIs are accessing a replicated data store that has only a limited subset of EMR data.
Emissary offers third party vendors and health systems a more elegant solution that gets them out of the business of making “copies” of EMR data that can never be real-time and are many times “out of sync.” Emissary does not store any EMR data, therefore data security and privacy concerns are greatly reduced. Because Emissary provides direct connectivity to EMR systems through vendor-supported modules, third party applications and their users benefit from the same real-time access as the native EMR applications.
How is Emissary different from FHIR?
HL7 has defined a set of specifications for web-based resources, which they call FHIR (Fast Healthcare Interoperability Resources), but the implementation of those FHIR specifications is still up to each of the EMR vendors. Since each EMR vendor can and will implement specifications differently, FHIR resources are not consistent. This places the burden on third party applications to code to each EMR's implementation, thus, reducing the value of a specification like FHIR. It defeats the overall purpose of publishing a specification if all source systems represent data differently depending on how they implement the specification. Emissary API endpoints are consistently implemented and represented regardless of the underlying EMR system. In this way, third party developers code to the Emissary specification once without having to worry about having special code that must deal with EMR-specific FHIR implementations.
We recognize that:
- Historically there has been inconsistent implementation of industry-adopted standards (e.g., HL7, X.12, CDA)
- Thus, EHR vendors will vary their approach to data they make available through FHIR.
- FHIR releases new updates infrequently, updating approximately every 18-24 months. Emissary releases updates every 2 weeks.
- FHIR only defines standards for activity data within the EHR. Emissary provides patent pending Discovery APIs, which gives access to EMR reference tables (i.e. build and configuration) for any third party applications.
Emissary offers a set of real-time APIs in a proprietary unified data model, with greater flexibility and stability. If the appropriate data is stored in the EMR, Emissary will provide APIs to cover any and all use cases.
EMR Vendors are implementing FHIR, so why would we need Emissary?
Yes, EMR vendors are working to develop and implement FHIR standards. However, just as with current HL7 standards, each EMR vendor likely will vary in their approach to implementing FHIR services, and to what extent they will support data services they want to make available through FHIR. Also, FHIR standards will need to evolve over some number of years before they are robust, and the EMR vendors will require time after FHIR specifications are announced to implement and test before making available for consumption. Emissary is proven and available today.
What about use cases where triggering and sending data to an external system is necessary?
The way we safely write data back to the EMR is that we re-purpose existing backend services that the native EMR applications utilize to write data to the EMR. For example, when we POST/Documents today, we essentially locate and use the same backend service that the EMR applications use to write a new document. In that way, we allow all of the business/validation logic currently built into the EMR service to take over and properly write new activity records. This is the same approach for any PUT or DELETE methods as well. As a rule, Emissary never actually does an INSERT or UPDATE to any table in the EMR.
How is Emissary able to write data back to the EMR system safely?
The way we safely write data back to the EMR is that we re-purpose existing backend services that the native EMR applications utilize to write data to the EMR. For example, our POST /Documents uses the same backend service that the EMR applications use to write a new document. In that way, we allow all of the business and validation logic currently built into the EMR service to take over and properly write and update activity records. This is the same approach for any POST, PUT, or DELETE methods as well. As a rule, Emissary never does an INSERT or UPDATE to any table in the EMR through database scripting.
WHich EMRs does Emissary currently support?
Emissary currently supports the following:
- Allscripts TouchWorks – v10 or higher code version
- athenahealth athenaClinicals – all versions
- Cerner Millennium – 2007.01 or higher code version
- Epic – 2014 or higher code version
- MEDITECH – Client Server 5.x and Client Server 6.x
How do you handle different versions of EMRs?
EMRs today have become very complicated and complex systems, with many supported internal applications. Although layouts and functionality may drastically change from version to version, the underlying data model has essentially stayed the same. Emissary leverages the same underlying data models so it is virtually immune to any breaking changes as it is not in the EMR’s best interest to change their data models on a frequent basis as those changes would break all of their current and legacy applications that they support. When EMRs do change versions, we perform a thorough test of our APIs to ensure there have been no breaking changes, and there rarely are.
Is there any data Emissary cannot read or write?
If data exists in the core EMR system, then Emissary can read any data. There are no limitations on reading data. Writing data back into the EMR is more delicate. There are a few workflows where Emissary will not write back to the EMR. For example, offering services that replace the EMR’s closed loop computerized provider order entry (CPOE) process is not something Emissary supports at this time. This is because the CPOE workflow is traditionally highly complex and involves a number of different data integration points, such as drug-to-drug interaction checking, drug-to-allergy interaction checking and other CPOE functions that makes it very difficult for a third party to replicate. We support as many interactions as we can while maintaining the integrity of the native EMR system functions.
Do you store the data?
Emissary is the only true RESTful API solution available in the market. We are a pass through for the data. The only data stored in our system is for audit purposes, such as which API was called, when were they called and by who.
Can Emissary embed customer user interfaces in the EMR?
Emissary supports improved workflows associated with embedding third party web applications within the EMR user interface. The combination of real-time data and embedding of web applications allows for sophisticated integration. Emissary tears down the wall, separating third party apps from the EMR window and moves external applications directly into the end-user’s workflow. Studies consistently show that tighter integration into workflow enhances usability, adoption and impact.
What is the practical impact of EMissary on EMR end users?
Because Emissary provides real-time data and true integration, it has a significant positive impact on EMR end users and, by extension, healthcare outcomes. End users can leverage connected apps that are embedded into their normal workflow and always have access to current data that is never out-of-sync. Emissary eliminates head turning, copy/paste and toggling from one system/screen to another. Seamless workflows provide a better user experience and more effective outcomes.
Is Emissary scalable to large, complex environments?
Emissary is specifically designed for the needs of large-scale organizations. It is built on Microsoft’s development stack. All transactions going through Emissary are stateless, enabling virtually unlimited load balancing. Emissary does not store data in a separate repository, therefore customers avoid the complexities of a massive database. Built in the Microsoft Azure cloud, Emissary is lightweight and runs on Windows Server 2008 R2 and above, within any virtualized environment.
How do you handle local customizations made in the EMR?
Our solution relies on the native core infrastructure of the EMR and is unaffected by most custom configurations. Since many in our team came from the health system world, we recognize how customized an EMR can be within any given hospital system so we created patent pending Discovery APIs that expose the local configurations of the health system. We are the only middleware company on the market that can unleash this area of the EMR to our customers.
Can Emissary be hosted in the cloud?
Yes, Emissary only requires a Windows operating system with Internet Information Services (IIS) running on it. Emissary was developed on Microsoft Azure, and is currently hosted with our partners, Clear Data, in Amazon web services (AWS).
What is SMART?
SMART represents the ability to launch a third party application within the EMR framework using OAuth2 while passing contextual data so the third party application can launch in patient and user context. The SMART platform is composed of open standards, open source tools for developers building apps and a publicly accessible app gallery. Applications built using SMART will typically require data integration with an EMR which is where the SMART on FHIR concept exists. FHIR, which are a set of API resources, is the data acquisition portion of third party integration while utilizing SMART for the application launch and authentication framework.
What is SMART on FHIR?
A SMART on a FHIR app runs within an ERM system that supports both SMART and FHIR, extending its functionality through the use of clinical and contextual data offered by API endpoints; in this case FHIR resources. Emissary is also a set of standard API endpoints so a third party could develop a SMART on Emissary application.
Is Emissary compatible with SMART on FHIR?
Emissary gives SMART application developers more options and greater flexibility for achieving EMR integration than FHIR resources. SMART applications can use the Emissary API endpoints, FHIR resources or a combination of both to achieve deep integration.