Interoperability Techniques in CrowdHEALTH project: The Terminology Service.

INTRODUCTION: Healthcare information systems' (HIS) lack of interoperability remains a challenge and a barrier for important health-related events detection. While relevant techniques are based on medical standards and technologies, these techniques do not follow a holistic approach. The creation of a set of tools that fulfils the needs of interoperability is needed. AIM: The aim of this paper is to present the terminology service envisioned while defining the initial design of the Interoperability solution proposed for the CrowdHEALTH project.
METHODS: In the CrowdHEALTH project, specific subcomponents responsible for providing the appropriate functionalities have been designed: The rule engine for the implementation of the business logic, the Structure Mapping Service which is responsible for creating and managing the knowledge related to the link that exists between information structures, or mappings between them and the Terminology Service for providing a set of operations on medical terminologies used for the coding of medical knowledge, which fill the information structures.
RESULTS: Therefore, it is possible to provide a series of functionalities about these information elements found within more complex structures expressed in a local code and translated into other standardized medical terminology. Towards this end, CrowdHEALTH presents the terminology service envisioned in the context of the initial design of the interoperability solution.
CONCLUSION: CrowdHEALTH project provides an infrastructure to convert the clinical information into meaningful data so that healthcare systems communicate effectively. This initial proposal will be further extended and tested during the project life circle.

INTRODUCTION

With the expansion of the available ICT services applications and sensors (1) have been developed to detect patient health conditions. Almost 275 million devices are available in the global market as mentioned by Gartner (2). Currently all these services operate independently, and the available data are heterogeneous. Therefore, limited value can be gained from data exploitation. Data is spread across different settings, it is often devicebased or stored in different systems. Due to the lack of technology interoperability and the large amounts of health-related data, it is common for certain health conditions or early indications of diseases not to be detected (3). Full semantic interoperability in healthcare systems seems a work in progress. IEEE (4) definition for interoperability is the “ability of a system or a product to work with other systems or products without special effort on the part of the customer”. In the healthcare sector, the challenge is how to achieve seamless communication between healthcare organizations, clinics, general practitioners and other stakeholders, in order to provide complete and accurate Electronic Health Records (EHR). Electronic Health records digitally store the data and provide the means for exchanging patient information to authorized people when required to monitor care (8), improve public health monitoring and conduct research (6, 11, 9, 10). Therefore, an EHR is best perceived as a collection of statements of healthcare professionals actions, interventions and observations (7) at a specific time and place, for a particular patient. Medication, side effects, allergies, observations and therapies can become available electronically to doctors but they are usually expressed in different formats (5). Clinical information is complex and requires a coordinated way to manage the data. Healthcare providers and research initiatives require EHR data to be restructured into a common format and standard terminologies, linked to other data sources (12). The transformation into a common format is currently achieved through the Health Level 7 (HL7) Fast Healthcare Interoperability Resources (FHIR) standard (13), which is widely accepted among different healthcare organizations to achieve interoperability (14). In CrowdHEALTH, datasets with structured and unstructured data coming from different Use Cases are processed. Within this context, there is a need to identify the entities and attributes from a proprietary source and translate them to a resource specification.

AIM

The aim of this paper is to present the terminology service envisioned while defining the initial design of the Interoperability solution proposed for the CrowdHEALTH project.

METHODS

The challenges of interoperability within the CrowdHEALTH project have been clustered in two main pillars, health information structures, and code systems or medical terminologies that allow the expression of medical facts. Therefore, specific subcomponents to support functionalities in order to meet the needs of each of these pillars have been designed. The Rule engine for the implementation of the business logic, the Structure Mapping Service for the creation and management of the knowledge related to the link that exists between information structures, or mappings between them and the terminology service providing a set of functions on medical terminologies used for the coding of medical knowledge, which fills the information structures. The Terminology Service provides a set of operations over terminologies which are defined using the specifications of HL7 FHIR. The local code used in a specific organization, regarding the patient diagnosis, is translated into other standardized medical terminologies, such as International Classification of Disease-10 (ICD-10) or Systematized Nomenclature of Medicine-Clinical Terms (SNOMED-CT). The terminology service has an interface layer that is intended to serve as the main interaction point with the rest of external services.

RESULTS

Terminology Service

The Terminology Service offers a set of operations on medical terminologies used for coding of medical knowledge, which fill the information structures. This way, it is possible to provide a series of functionalities (semantics) about these information elements found within more complex structures. One of the purposes provided by the Terminology Server will be the translations of local codes of an organization to the codes of other more standardized terminologies, for example SNOMED CT or ICD-10 (Figure 1).

Figure 1.

Data Converter design

The Terminology Service provides a defined set of operations over terminologies. The operations are defined using the specifications of HL7 FHIR, with the aim of fulfilling the needs of healthcare applications for the use of codes from available medical vocabularies that represent clinical knowledge. The Terminology Service operations are:

Value Set expansion;

Concept Lookup / Decomposition;

Value Set Validation;

Subsumption testing;

Batch Validation;

Translation;

Batch Translation;

Maintaining a Closure Table.

In order to provide these operations, it is necessary to load the terminologies used by organizations, create and store those translations required by use cases and finally performthe operations. For this purpose, the terminology service has the architecture illustrated in Figure 2:

Figure 2.

The terminology service architecture

The terminology service has an interface layer serving as the main interaction point with the rest of external services. In order to provide all the expected operations defined by HL7 FHIR standard, two internal subcomponents are needed as well as an external service provided by a common FHIR server. A controller is developed for each of these services used by the terminology service, whether being internal or external. The purpose of these controllers is to include methods used for the interaction with each of the sub-services, thus decoupling each of the interactions with different external/internal services. The Terminology Store manages and provides different medical vocabularies deployed by the Terminology Service. All the ontologies stored inside this service use a NoSQL graph-oriented database, in order to improve the execution of queries that require browsing the taxonomies which structure these terminologies. This subcomponent is the main element of interaction with the terminologies it stores, offering almost all operations on them. For highly expensive operations, another subcomponent is available which purpose is to improve the request processing times, in order to complete the operations in the usual and expected interaction times of a RESTful service. The Closure Table stores a transitive closure table, listing transitive subsumption relationships in a more rapid manner. The purpose of this subcomponent is to serve as cache for client results. Thus, the terminology service through the Terminology Store provides operations that are more resource-demanding, and the Closure table stores some of these operation results to be available after client requests. The FHIR Server is an external service of the Terminology Service subcomponent. This service is needed becausethe translation operation (that translates a medical idea from a code of a specific terminology to the code of another terminology) relies on the creation of a set of ConceptMap FHIR resources for a specific translations. Since specific requirements cannot be supported by a universal translation ofcodes, due to possible changes of the meaning of medical information, a set of specific translations must be created. This way, specific translations can be created to meet specific needs for the transformation of medical facts between terminologies in a controlled and supervgmailed manner. For example, a healthcare organization has an internal code of ‘ENDO’ for coding the endocrinology service, so a mapping between the code ‘ENDO’ and the SNOMED CT code ‘Endocrinology service | 700434000’ is created. Since the code ‘ENDO’ can be used in other organizations for codinga different concept, this translation should be specifically used within the given context of a use case,and avoid using universal translations without proper supervision As the FHIR ConceptMap resource proposes, these translations will be one-directional. All the translations from a source terminology target a destination terminology in a specific context. For example, the set of codes used within a secondary care facility to name the different services of the hospital (cardiology, rheumatology, oncology, etc), can be translated into the coded representation provided by SNOMED CT. A ConceptMap resource will be created where the source code will be each of the internal codes (local coding of the hospital), and the target will be the selected codes from the SNOMED CT terminology. These translations will be valid only for this specific context, and to translate from local terminology to SNOMED CT and not vice versa. Another ConceptMap needs to be created in order to provide translation from SNOMED CT to the internal hospital service coding that maps the SNOMED CT set of service codes to the destination set codes of the internal terminology in this given context. The purpose of the Error logging is to provide a normalized set of operation outcome description from the Terminology Service and to account for and store all the possible outcomes that are carried among the Terminology Service subcomponents, the Terminology Store, Closure Table and interactions with the FHIR Server. The Terminology Service intends to comply with the Application Programming Interface (API) specified by FHIR so the operations that this standard specifies will be summarized.

Value Set Expansion

A ValueSet is a set of codes from different terminologies or code systems defined by a set of rules. This operation returns a list with current codes that are included in the requested ValueSet. The formal definition of this operation is included in the operations for the FHIR resource ValueSet.

Required information for this operation:

The ValuetSet intended to be expanded. Provided by its URL on the RESTful interface, by its logical identifier or directly as a parameter;

Text filter (optional) to restrict codes that are returned;

Date and time (optional) at which the expansion should be evaluated;

Page (optional) to retrieve, breaking the expansion into a set of chunks;

Reference to an ExpansionProfile (optional) that supplies additional information about how to perform the expansion.

The result of the operation is a ValueSet resource with the current list of codes. In case of an error a resource OperationOutcome will be returned. The URL defined to carry out this operation will be as follows:

As an example, for requesting the expansion of a ValueSet already available the FHIR server, will be as follows:

Or if the ValueSet is specified by the client using JavaScript Object Notation (JSON):

The response:

Value Set Validation

ValueSet validation is the inverse operation for the ValueSet expansion, resolving if a given code is included in a specified ValueSet.

Required information for this operation:

The ValuetSet with which to be validated. Provided by its URL on the RESTful interface, by its logical identifier or directly as parameter;

The code value. String, a Coding data type or a CodeableConcept data type;

Date and time (optional) at which the expansion should be evaluated.

The result of the operation will be true/false indicating if the code/concept is valid for the given ValueSet. In case of error a resource OperationOutcome will be returned. The URL defined to carry out this operation will be as follows:

The following example is a request whether or not the SNOMED CT code 6142004 is included in the ValueSet:

Or if both the ValueSet and the code is specified by the client using JSON:

The response:

Batch Validation

A batch process is defined to perform the ValueSet validation operation with the aim of providing a better scalable interface. Thus, a set of validation operation requests can be incorporated into a single request and result in a single pack with correspondent results. The entire required validation request will be packed in a FHIR resource Bundle and will be POST into the URL previously provided, as follows:

The response:

Concept Lookup / Decomposition

For the retrieval of information regarding a specific code from a given system, the following information is required:

The code value. String or a Coding data type;

Id or URL (optional) of the system (terminology) where the concept is being looked up;

Date (optional) at which the result should be returned;

Properties (optional) that are intended to be returned.

The result of the operation will be a set with the following information:

Label or display of the code;

Name of the system;

Version of the code system used;

Definition of the code;

Designation for the code, like an alphanumeric code for its representation;

Designation in language (‘EN’ for english, ‘SLO’ for Slovenian, etc);

Parent codes for the code (if defined in a hierarchy);

Child codes of the code (if defined in a hierarchy).

Or in case of error a resource OperationOutcome will be returned.

The URL defined to carry out this operation will be as follows:

As an example, for requesting the lookup of the SNOMED CT code “6142004”, will be as follows: GET [base]/CodeSystem/$lookup?code=6142004 .Or if the code is specified by the client using XML of the data type Coding:

The response:

Subsumption testing

Semantic inclusion between codes allows the identification of a possible kinship relationship between two given concepts, i.e. the meaning of a concept is broader than the other one, so it is semantically included in the broader one.

Required information for this operation:

The code ‘A’ and ‘B’ value. Strings or Coding data type;

The system that the codes belong to;

The version (optional) of the code system.

The result of the operation will be one of the following options:

Equivalent. Concept A is equivalent to B, and vice versa;

Subsume. Concept A subsumes B;

Subsumed-by. Concept B subsumes A;

Not-subsumed. Concept A and B are not related by any subsumption relationship.

Or in case of error a resource OperationOutcome will be returned. The URL defined to carry out this operation will be as follows:

As an example, for requesting the subsumption of the SNOMED CT concept with the “6142004” “Influenza” and the concept “55604004” “Avian influenza”, will be as follows: GET[base]/CodeSystem/$subsumes?system=http://snomed.info/sct&codeA=6142004&codeB=55604004 . Or if the code is specified by the client using XML of the data type Coding:

The response:

Translations

The availability and use of different code systems create the need of an operation of translation between them when possible. This operation addresses this issue by providing the code, system and the ConceptMap (statement of relationship from one set of concepts to other concepts) to use as mapping table, or the source and destination context (source and destination ValueSet) where the translation needs to be performed.

Required information for this operation:

The code value. String or Coding or CodeableConcept data type;

The system that the code belongs to;

ConceptMap (optional) to use for the translation;

ValueSet for source (optional). Provided by URL on the RESTful interface, by logical identifier or directly as parameter;

ValueSets for destination (optional). Provided by URL on the RESTful interface, by logical identifier or directly as parameter.

The result of the operation will be Coding data type with the code translated. In case of error a resource OperationOutcome will be returned. The URL defined to carry out this operation will be as follows:

As an example, for requesting the translation of the SNOMED CT concept with the code “20735004” “Syphilitic aortitis (disorder)” to ICD-10-CM, will be as follows:

Since no source ValueSet is provided, it is assumed that the whole code system SNOMED CT replaces the source ValueSet. In this case the translation is performed between two general contexts since both, source and destination, are whole code systems with no specific context.

The response:

Batch translations

In order to provide a better scalable interface, and identical to Batch ValueSet Validation, a batch process is specified to carry out the Translation operation. The entire required validation request will be packed in a FHIR resource Bundle that will be POST into the URL previously provided, as follows:

The response:

The response:

CONCLUSIONS

In this paper the initial design of the terminology service was presented. In order to transform (15) the hospital-centric paradigm to patient-centric view (16), full semantic interoperability must be achieved. To this end, the CrowdHEALTH project provides an infrastructure to convert the clinical information into meaningful data so that healthcare systems communicate effectively, facilitating the medical and nursing (17) healthcare personnel to reach efficient clinical decisions (18, 19). This initial proposal will be further extended and tested during the project life circle.