Search



Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Overview

The main use cases for the IPS Terminology can be described as part of the cycle of clinical information, including recording IPS data, sharing IPS data, and analyzing IPS data.

...

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.

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

The IPS is a summary document , and it that can be created manually by a clinician that applies his criteria to describe the most clinically important items in the patient's history, it . It can also be automatically derived from existing electronic clinical documents, or . Or it can be 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 new entries concepts in the IPS Terminology constraining the scope to the "procedures" hierarchy, avoiding , which are constrained to the 

Concept
t71388002 |Procedure|
 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 (UIlike this is to access the IPS Terminology from a terminology server and to constrain the scope of the search by applying using an ECL query that matches with the value set conclusion inclusion and exclusion criteria.In an implementation like the one described

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

Scg expression
((< 71388002 |Procedure (procedure)|)
   MINUS (< 14734007 |Administrative procedure (procedure)|
       OR < 59524001 |Blood bank procedure (procedure)|
       OR < 389067005 |Community health procedure (procedure)|
       OR < 442006003 |Determination of information related to transfusion (procedure)|
       OR < 225288009 |Environmental care procedure (procedure)|
       OR < 308335008 |Patient encounter procedure (procedure)|
       OR < 710135002 |Promotion (procedure)|
       OR < 389084004 |Staff related procedure (procedure)|))
   AND (^816080008 |International Patient Summary|)

can be used in a FHIR API request Can be used as a parameter for the terminology server API to create a data entry form with a text search and autocomplete feature like this one:

...

When the content of the IPS is being auto-generated from an existing , coded, electronic documents, one implementation option is document, it may be possible to map the existing information codes to the IPS Terminology. The implementers can To do this, implementers should create maps from local terminologies or classifications the existing code systems to the IPS Terminology and covert the codes in real-time when creating IPS documents.

...

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.

Image Added

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

The ultimate A key use case for the IPS is to exchange clinical information between systems, and the . The goal of the IPS Terminology, in this use case, is to provide a free, common language , free of use, that can be applied worldwide.

...

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:

Scg expression
Bordersolid
ShowFormatblock
(>|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 be shared, including codes and descriptions, as specified in the IPS document documentation. This data will be share. By coding using the IPS Terminology, this data becomes interoperable with any other user worldwide, as the . The IPS Terminology represents the basic common denominator that any user can have for a SNOMED implementation, includes all concepts that are common and free to use in any SNOMED CT implementation, thus removing any barriers of membership and cost.

When the an IPS document is created by an affiliate usersuser, they have access to the whole entire breadth of the terminology, allowing them to represent a wider broader range of clinical meanings. These affiliate users can also have implementations that expand the representation possibilities by applying expand their implementations by representing new clinical meanings with post-coordination or maintaining a local extensions. When extension. As explained in the previous section, an affiliate user wants to share an IPS Document with a non-affiliate user, it's possible for the affiliate user to create a version of the IPS that only use codes included in the IPS Terminology. This can be achieved by applying a Common Proximal Ancestor technique, this a mechanism that uses an ECL to start from a code that is not present in the IPS Terminology, and looks for the closes ancestor in the hierarchy of the complete SNOMED CT edition that is part of the IPS Terminology. This has the consequence of losing part of the original meaning but obtains a more general meaning that can still be understood and organized in the hierarchies of IPS Terminology users.

Receiving data

Data received in IPS documents can be displayed to the users and imported into local systems, with the code and description. Data can be mapped to local terminologies to match data recorded locally in clinical systems.

Agreements and interoperability frameworks will define the exact scope of SNOMED in the IPS documents. Non-affiliate users are expected to receive only IPS Terminology codes, if unknown codes are received, it may mean that these are SNOMED CT codes outside of the IPS Terminology and the user generating the IPS document needs to apply the Common Proximal Ancestor technique to ensure that only IPS Terminology codes are shared.

...

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.

Anchor
usecase3
usecase3
Use case 3 - Perform simple data analytics

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

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

"Identify all the diabetic patients , with a history of any cardiovascular disease , for inclusion in a clinical trial for a new antilipemic drug"

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

The problems list field of the IPS Document 'code' data element in the Problem List resource can be used to identify the diagnosis, this ECL will identify all the IPS Terminology codes that match with the clinical trial inclusion criteria for diagnosis: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.

Diabetic patients


Scg expression
<< 73211009 |Diabetes mellitus (disorder)|


...

Any cardiovascular diseases


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


Sending these These ECL queries can be passed to a terminology server API will to obtain the list of codes that represent inclusion criteria for the study, then a process will check all the IPS documents stored in the system to select the ones that have a diagnoses that are relevant for the clinical trial. The IPS documents are then checked for the co-occurrence of these diseases and to identify the trial candidates.