Frequently asked questions

General     |     Emissary    |    FHIR/HL7     |     EHR


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 AppDynamics and how is it used with Emissary?

AppDynamics is an application performance management (APM) product. Sansoro Health has licensed AppDynamics, a Cisco company, and their Application Performance Monitoring product(s) to ensure your Emissary service is monitored for ultimate performance. Through the Sansoro Health licensed AppDynamics Application Performance Tool, performance of Emissary is constantly tracked and monitored.

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 any 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.

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.

Where do I go to get help on a specific Emissary question?

Explore the resources found in the Resource Center > Customer Resources for Tutorials, User Guides and API Workflow Guides .

For additional questions, please contact your Sansoro Health Representative or email us at: or call: (888) 988-5202.

What is Emissary POC?

The Emissary POC environment is cloud-hosted, connected to environments across multiple EHRs. In the future we also anticipate value as a test environment for existing customers who do not yet have a health system. Feature List includes:
• Cloud-hosted Emissary instance
• Available via Web UI or Postman
• Connect to multiple available EHR instances pre-populated with test data
• Authentication keys managed by customer, expiration date and available APIs

For additional questions, please contact your Sansoro Health Representative or email us at: or call: (888) 988-5202.


What is Emissary?

Emissary is a middleware application that enables data exchange between third-party applications and electronic health records (EHRs) through REST APIs. It provides a robust set of services that read from and write to the native EHR data repository through EHR vendor-supported software modules. Emissary standardizes EHR integrations through universal APIs and a unified data model. To connect to any supported EHR, a third-party developer codes once to the Emissary APIs.

What are the benefits of Emissary?

The Emissary approach drastically simplifies the integration of software with EHRs. Through Emissary, software connectivity to EHRs 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 EHR. The health system’s EHR platform typically contains all coding systems (e.g. LOINC®, SNOMED® or ICD). If the EHR 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 EHR data on demand.

How does Emissary reduce costs?

Emissary’s API plug-and-play solution delivers standardized, interchangeable APIs for seamless integration across health IT vendors and EHRs. Emissary eliminates traditional custom interface development and maintenance costs, and reduces EHR vendor interface fees.

How is Emissary able to write data back to the EHR system safely?

We safely re-purpose existing backend services that the native EHR applications utilize to write data to the EHR. For example, when we POST/Documents today, we essentially locate and use the same backend service that the EHR applications use to write a new document. In that way, we allow all of the business/validation logic currently built into the EHR 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 through datascripting.

Is Emissary HIPAA compliant?

Emissary does not store data and encrypts all data in transit using proven technology. In addition, if Emissary is hosted by Sansoro Health we are HIPAA compliant and HITRUST certified.

How does Emissary secure PHI?

Emissary is a platform of RESTful API calls that leverages industry standard encryption to ensure the data transfer is secured.

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.

Can Emissary embed customer user interfaces in the EHR?

Emissary supports improved workflows associated with embedding third-party web applications within the EHR 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 applications from the EHR 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 EHR end users?

Because Emissary provides real-time data and true integration, it has a significant positive impact on EHR 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.

Can Emissary be hosted in the cloud?

Yes, Emissary is cloud-hosted and only requires a Windows operating system with Internet Information Services (IIS) running on it.

What are the hosting options for Emissary?

There are three options for hosting Emissary:

1. Sansoro hosts:
– Sansoro hosts the Emissary server at its hosting provider.
– Sansoro works with HS to establish VPN to the HS or EHR vendor.
– Sansoro works with DHP to establish secure connectivity to the Emissary server.

2. Digital health partner (DHP) hosts:
– DHP hosts the Emissary server on-premise at their location or hosting provider.
– DHP works with HS to establish VPN to the HS or EHR vendor.
– DHP works with Sansoro to establish remote access to the Emissary server.

3. Health system (HS) hosts:
– HS hosts the Emissary server on-premise at their location or hosting provider.
– HS works with DHP to establish VPN to the HS.
– HS works with Sansoro to establish remote access to the Emissary server.

Is Emissary compatible with SMART on FHIR?

Emissary gives SMART application developers more options and greater flexibility for achieving EHR integration than FHIR resources. SMART applications can use the Emissary API endpoints, FHIR resources or a combination of both to achieve deep integration.

How long does it take to implement Emissary?

Implementing the Emissary solution at a health system typically requires about 10-15 total hours of task time by about 3-4 health system resources such as network administrator, security analyst, and a DBA/EHR analyst. See Resource Center > Customer Resources > Evaluating Emissary > Technical

What are the Emissary Installation Steps?

Emissary is a middleware application and has a two-part installation along with a connectivity component. Please contact your Sansoro Health Representative or email us at: or call: (888) 988-5202 for more information.

What are the minimum hardware and software prerequisites to install Emissary?

– Dual-Core 2.2 GHz CPU
– 8 GB RAM
– 50 GB Hard-drive (based on transactional logs archiving strategy)

– Recommend Windows Server 2012 R2 or higher (minimum of Windows Server 2008)
– IS 7.0 (or higher versions)
– .NET Framework 4.7
– ASP.NET (Windows Component)

How can I test an API?

There are multiple ways that testing can be performed to ensure that the Emissary calls are successfully connecting to and retrieving data. Two examples include:

1. API Runner available through the installed Emissary site.
2. Other API testing tools such as Postman.

Is Emissary backwards compatible?

Yes, in most cases. In the event a breaking change is being made, we will communicate it ahead of deployment. In addition, versioning at the API level will allow us to release breaking changes to our UDM, which will still support our existing versions.

1. API Runner available through the installed Emissary site.
2. Other API testing tools such as Postman.


How is Emissary different than traditional HL7 integration engines?

Emissary leverages the EHRs underlying core data services. These often are the same services that facilitate reading and writing of data for the EHR’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 EHR data.

Emissary offers third-party vendors and health systems a more elegant solution that gets them out of the business of making “copies” of EHR data that can never be real-time and are many times “out of sync.” Emissary does not store any EHR data, therefore, data security and privacy concerns are greatly reduced. Because Emissary provides direct connectivity to EHR systems through vendor-supported modules, third-party applications and their users benefit from the same real-time access as the native EHR 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 EHR vendors. Since each EHR vendor can and will implement specifications differently, FHIR resources are not consistent. This places the burden on third-party applications to code to each EHR’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 EHR system. In this way, third-party developers code to the Emissary specification once without worrying about having special code that must deal with EHR-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 EHR 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 EHR, Emissary will provide APIs to cover any and all use cases.

EHR vendors are implementing FHIR, so why would we need Emissary?

Yes, EHR vendors are working to develop and implement FHIR standards. However, just as with current HL7 standards, each EHR 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, EHR 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 EHR 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
  • 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 does Emissary keep up-to-date with EHR upgrades and service packs?

Emissary’s technical approach leverages the data models that support the user interface for each EHR solution. Major changes to those tried and true data structures would result in major revisions to workflows for the user. While not uncommon, major revisions are rare. Lastly, we always offer to test our APIs against a non-production instance prior to go-live to ensure core functionality is available.

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.