Frequently asked questions
What are APIs and how do they work?
How are you different than other middleware 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 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 EHR infrastructure in order to securely and quickly transfer the data. Emissary is a pass through which creates a unified data model that is EHR agnostic.
Do you store the data?
What is SMART?
SMART represents the ability to launch a third-party application within the EHR 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 EHR 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 Emissary?
What are the benefits of Emissary?
How is Emissary able to write data back to the EMR system safely?
Is there any data Emissary cannot read or write?
Can Emissary embed customer user interfaces in the EMR?
What is the practical impact of Emissary on EMR end users?
Is Emissary scalable to large, complex environments?
Can Emissary be hosted in the cloud?
Is Emissary compatible with SMART on FHIR?
How is Emissary different than traditional HL7 integration engines?
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 worrying 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 the years before they are robust. Additionally, 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 is SMART on FHIR?
A SMART on a FHIR application runs within an EMR 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.
Which EHRs 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 EHRs?
EHRs 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 EHR’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 EHRs do change versions, we perform a thorough test of our APIs to ensure there have been no breaking changes, and there rarely are.
How do you handle local customizations made in the EHR?
Our solution relies on the native core infrastructure of the EHR and is unaffected by most custom configurations. Since many in our team came from the health system world, we recognize how customized an EHR 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 EHR to our customers.