Page History
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:
- Create and store IPS data within a non-Affiliate organization
- Send IPS data to/from non-Affiliate users
- Perform simple data analytics
In this section, we describe each of these IPS Terminology use cases.
Anchor | ||||
---|---|---|---|---|
|
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 | ||
---|---|---|
|
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.
Anchor | ||||
---|---|---|---|---|
|
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 | ||||
---|---|---|---|---|
| ||||
(>|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 | ||||
---|---|---|---|---|
|
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 |
|
---|
...
Any cardiovascular diseases |
|
---|
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.