Overview

The main use cases for the IPS Terminology are:

1. Create and store IPS data within a non-Affiliate organization
2. Send IPS data to/from non-Affiliate users
3. Perform simple data analytics

In this section, we describe each of these IPS Terminology use cases.

Use case 1 - Create and store IPS data within a non-affiliate organization

The IPS is a summary document that can be created by a clinician to describe the most clinically important items in the patient's history. It can also be automatically derived from existing electronic clinical documents. Or it can use a mix of these two approaches.

Creating IPS data

When a clinical user is directly entering information into an IPS document, the software user interface will provide a structured data entry form to add content, allowing the user to search and select concepts from the IPS Terminology when appropriate.

For example, in the "Procedures" section of an IPS document, the data entry software should allow the clinician to search for concepts in the IPS Terminology, which are constrained to the  hierarchy, excluding some administrative concepts (as described in the IPS terminology binding for the procedure value set). The recommended way to implement a user interface (UI)  like this is to access the IPS Terminology from a terminology server and to constrain the scope of the search using an ECL query that matches with the value set inclusion and exclusion criteria.

For example, as explained in section e of the 3. Using a Terminology Server page, the following ECL 

((< 71388002 |Procedure (procedure)|)
   MINUS (< 14734007 |Administrative procedure (procedure)|
       OR < 308335008 |Patient encounter procedure (procedure)|))

can be used in a FHIR API request to create a data entry form with a text search and autocomplete feature like this one:

When the content of the IPS is auto-generated from an existing electronic document, it may be possible to map the existing codes to the IPS Terminology. To do this, implementers should create maps from the existing code systems to the IPS Terminology and use these to convert the codes from the existing documents into IPS Terminology codes to use in the IPS document (in real-time).

Storing FHIR IPS Data

The codes and terms included in the IPS Terminology can be used to populate FHIR resources, as defined in the IPS implementation guide. The example below shows a CodeableConcept data element (i.e., "Code") populated with a code from the IPS Terminology as a fragment of the FHIR Procedure resource.

Use case 2 - Send IPS data to/from non-affiliate users

A key use case for the IPS is to exchange clinical information between systems. The goal of the IPS Terminology, in this use case, is to provide a free, common language for the interoperable sharing of this data worldwide.

Receiving IPS data

Coded IPS data received by non-affiliates can be displayed to users and stored in local systems using the original codes and terms received from the sending system. In some cases, the receiving system may also choose to map these codes to local terminologies used by the receiving system.

When a SNOMED CT code is received by a non-affiliate, the receiving system may use its terminology server to check whether or not the code is in the IPS Terminology. Any SNOMED CT code received by a non-affiliate system that is included in the IPS Terminology may subsequently be used for simple data analytics or property lookup (see use case 3). However, if the sending system is using a full SNOMED CT edition, then the SNOMED CT codes sent in the IPS document may fall outside the scope of the IPS Terminology. If this is the case, then the receiving system may only store, display and/or resend the code and term that is received. Alternatively, the receiving organization may obtain a SNOMED CT license for the full SNOMED CT Edition. For more information, please contact info@snomed.org. 

If an affiliate sending system requires a non-affiliate receiving system to be able to perform some simple analytics operation or lookup on the data, then the sending system may decide to supplement each CodeableConcept with the original code's proximal ancestor(s) that are contained in the IPS Terminology. For example, using the following ECL query:

(>|X| AND ^ 816080008 |International Patient Summary|) MINUS (> (> |X| AND ^ 816080008 |International Patient Summary|))

it is possible to find the closest supertypes of a concept (X) that are included in the IPS Terminology. Please note that this ECL can only be performed by an affiliate with a license to use a SNOMED CT edition that contains the concept |X| and its associated relationships.

Sending IPS data

Once the IPS document is created and coded with IPS Terminology codes, the document is ready to share. By coding using the IPS Terminology, this data becomes interoperable with any other user worldwide. The IPS Terminology includes all concepts that are common and free to use in any SNOMED CT implementation, thus removing any barriers of membership and cost.

When an IPS document is created by an affiliate user, they have access to the entire breadth of the terminology, allowing them to represent a broader range of clinical meanings. These affiliate users can also expand their implementations by representing new clinical meanings with post-coordination or a local extension. As explained in the previous section, an affiliate user may also decide to supplement each CodeableConcept with the original code's proximal ancestors belonging to the IPS Terminology for maximum interoperability. These proximal ancestors should be sent in addition to the original code recorded by the clinician to avoid losing part of the original meaning.

Use case 3 - Perform simple data analytics

SNOMED CT enables advanced data analytics over coded data, using the hierarchies and concept definitions to support the selection of concepts based on their meaning. SNOMED CT queries can assist in a range of use cases, including population surveillance, quality metrics, clinical decision support, clinical research, or simple searching.

For example, a research use case may have the following requirements:

Using the IPS Terminology and the ECL language, it is possible to create queries that can be used to match codes in an IPS document, to identify a candidate set of patients.

The 'code' data element in the Problem List resource can be used to find each patient's diagnosis. By checking if each Problem.code value, in the IPS document, is a member of the following ECL result sets, it is possible to identify patients that match the clinical trial's inclusion criteria.

<< 73211009 |Diabetes mellitus (disorder)|

<< 49601007 |Disorder of cardiovascular system (disorder)|

These ECL queries can be passed to a terminology server API to obtain the list of diagnoses that are relevant for the clinical trial. The IPS documents are then checked for the co-occurrence of these diseases to identify the trial candidates.