Overview
The 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.
Use case 1 - Creating and storing IPS data by a non-affiliate organization
The IPS is a summary document, and it can be created manually by a clinician that applies his criteria to describe the most clinically important items in the patient's history, it can be automatically derived from existing electronic clinical documents, or it can be a mix of these two approaches.
Manual data entry
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 in the IPS Terminology constraining the scope to the "procedures" hierarchy, avoiding some administrative concepts, as described in the IPS terminology binding for the procedure value set. The recommended way to implement a UI like this is to access the IPS Terminology from a terminology server and to constrain the scope of the search by applying an ECL that matches with the value set conclusion and exclusion criteria.
In an implementation like the one described, the following ECL:
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| )
Mapping from existing content
When the content of the IPS is being generated from existing, coded, electronic documents, one implementation option is to map existing information to the IPS Terminology. The implementers can create maps from local terminologies or classifications to the IPS Terminology and covert the codes in real-time when creating IPS documents.
Use case 2 - Sending and/or receiving IPS data by non-affiliate users
The ultimate use case for the IPS is to exchange clinical information between systems, and the goal of the IPS Terminology is to provide a common language, free of use, that can be applied worldwide.
Sending 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 interoperable with any other user worldwide, as the IPS Terminology represents the basic common denominator that any user can have for a SNOMED implementation, removing any barriers of membership and cost.
When the IPS is created by affiliate users, they have access to the whole breadth of the terminology, allowing them to represent a wider range of clinical meanings. These users can also have implementations that expand the representation possibilities by applying post-coordination or maintaining local extensions. When 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.
Use case 3 - Using IPS Terminology data for analytics
SNOMED CT enables advanced possibilities for data analytics, the hierarchies and concept definitions support the selection of concepts based on meaning. Data analytics can be applied to population surveillance, quality metrics, clinical decision support, or research.
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 ECL language is possible to create queries for each for the IPS document fields to identify candidate patients.
The problems list field of the IPS Document 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:
Diabetic patients |
---|
Any cardiovascular diseases |
---|
Sending these ECL queries to a terminology server API will 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 co-occurrence of these diseases and identify the candidates.
Feedback