Terminologies Recipe

Overview

Terminology is a fundamental concept within Healthcare IT and within HL7 FHIR.  interopiO™ provides an HL7 FHIR Terminology server as part of interopiO's CDR that implements HL7 FHIR Terminology Module.

Features

In this recipe, we describe enabling HL7 FHIR Terminology Services for use by your app or service.  This includes these common use cases (as described by HL7 FHIR Terminology Module:

• Create or reference a code system
• Create or reference a value set
• Record data using pre-coordinated codes
• Record data using post-coordinated expressions
• Record data using multiple local or standard code systems (translations)
• Expand a value set
• Validate a code
• Look up a display term for a code
• Translate a code from one value set to another
• Maintain a client-side transitive closure table  on subsumption relationships
• Test subsumption between concepts
• For a set of property/concept pairs, return the set of concepts for the requested properties
• Map data between different terminologies
• Declare the capabilities of a terminology service

To accomplish this capability, we explore the following implementation models:

• App or service queries the EHR native terminology using the FHIR REST API
• App or service queries commercial, third-party (vended), or your own custom terminology server
• App or service queries an interopiO global terminology server
• App or service queries your own interopiO terminology server

Benefits

By following this recipe, your app or service will be able to:

• Use the same terminologies that are used within the target EHR system
• Use the same terminologies that are used within your organization
• Use the industry-standard terminologies that are shared among interopiO clients
• Provision your own terminology server for your app- or service-specific  use cases

Requirements

Required

• Your application maintains an interopiO subscription
• Your application uses the HL7 FHIR SMART App Launch flow including app launch and backend service
• Your application uses the HL7 FHIR API for interacting with terminology servers

Recipe

Terminology Server Use Cases

For this recipe, let's consider four types of terminology servers and discuss how your app could utilize those servers using interopiO.

1. EHR-Native Terminology
2. Third Party Vendor- or Custom-Terminology Server
3. Your own interopiO CDR as a Terminology Server
4. interopiO Global Terminology Server

EHR-Native Terminology   In this model, the EHR supports the FHIR APIs for terminology.  Your app can query these APIs using your interopiO Gateway.	Third Party Vendor- or Custom-Terminology Server In this model, you already have a terminology server, either one you've purchased or one you've built.
Your own interopiO CDR as a Terminology Server In this model, you would like a terminology server that allows you to load your terminologies including LOINC, SNOMED, and others including those you create for your own use.	interopiO Global Terminology Server   In this model, you would like a terminology server with the typical industry terminologies (LOINC, SNOMED) and don't need to include other terminologies.

 

Terminology Integration Scenarios

Terminology services can be integrated at many different levels of an application stack or message flow.  We will consider the following:

1. An application wants to interact with the terminologies in use at the EHR system (for example, look up a code while creating an allergy for the patient)
2. An application wants to interact with its own terminology (for example, a corporate terminology server) using a standards-based method
3. An application wants to interact with a terminology server that is already loaded with the industry standard terminologies (LOINC, SNOMED CT)
4. An application wants to the systems processing queries and data to interact with a terminology server of the app's choosing

interopiO Gateway and Data Adapter Pattern

Before continuing with the terminology recipe, let's review the interopiO Gateway and Data Adapter pattern.  This pattern enables apps or services to access data sources using standards like HL7 FHIR R4.

 

As shown above, the app or service sends a request to the interopiO Gateway using the HL7 FHIR API and FHIR Resource model.  This allows the app or service to be decoupled from the underlying datasource (or terminology server in this recipe).

The interopiO Gateway receives the app's request as a FHIR API request and enforces authorization of the app (client).  The interopiO Gateway then sends the request to the corresponding interopiO Data Adapter.  

The interopiO Data Adapter receives the FHIR API request and fulfills it.  We provide data adapters for out-of-the-box use cases such as connecting an interopiO R4 Gateway to an EHR R4 FHIR API (that is largely pass-through) and data adapters for custom use cases such as connecting an interopiO R4 Gateway to a vendor's proprietary web services.  In addition, you can create external data adapters. 

 

Connecting to a Terminology Server using an interopiO Data Adapter

From the Terminology Integration Scenarios above, we can now see these integrations can be accomplished.

1. An application wants to interact with the terminologies in use at the EHR system

This flow is supported natively with no additional steps required.  An application can send a request to the EHR's terminology services using the interopiO Gateway.  This support may be seen on your interopiO Data Adapter Supported Operations screen as shown in this Epic R4 example:

 

2. An application wants to interact with its own terminology using a standards-based method

This flow introduces the vendor's terminology server and provides standards-based access to that server to the app using the interopiO Data Adapter pattern.  This pattern is critical to allow the app to be developed to the FHIR API standard for terminologies and leveraged to support the next two use cases.

The app is aware of both gateways (the gateway to the EHR is the ISS provided during the app launch and the gateway to the terminology server is known before hand by the app).  The app makes separate calls to each gateway using the access token for that gateway.

If it isn't important for the app to be aware of the separate terminology service, but instead, route calls to that service, we remove the gateway to the terminology service and route the terminology calls in the gateway to the EHR instead to the Vendor Terminology Server.

Finally, if the data adapter to the EHR needs to connect to the separate terminology server (for example, to process value-set expansion operations or look up vendor codes), the data adapter to the EHR may become a custom data adapter, integrating with the data adapter to the terminology server allowing additional flexibility as requests are processed.  

 

3. An application wants to interact with a terminology server that is already loaded with the industry standard terminologies (LOINC, SNOMED CT)

This flow utilizes a terminology server that interopiO provides as a read-only, globally shared server.  This server is loaded with LOINC and SNOMED CT terminologies.  Contact us for the details of using this server.

 

4. An application wants to the systems processing queries and data to interact with a terminology server of the app's choosing

This flow supports all of the integration options flow #2 but instead of an external vendor terminology server, the app uses an interopiO CDR that fully supports the HL7 FHIR Terminology Module specification.  The customer would use the terminology APIs to load code systems into the CDR.  The app would use the Gateway's terminology APIs to retrieve those terminologies from the CDR.

 

Contact Us

The terminology space is complex.  We would love to discuss your particular use case to help determine a plan and implementation of your terminology within interopiO.