This page introduces the users, use cases and resulting service requirements for a terminology server supporting postcoordination.
Users
Table 5.1.2-1 provides an overview of the key users who interact with an expression repository.
| User | Description |
|---|---|
Information Manager |
|
Clinical user |
|
Table 5.1.2-1: Overview of key users interacting with an expression repository.
Use Cases
This set of services will enable users interacting with an expression repository to perform required tasks.
Table 5.1.2-2 provides an overview of requirements for each group of users.
| User | Functional Requirement | Service Requirements |
|---|---|---|
Information Manager | Should be able to set up the expression repository when preparing for an implementation | Create expression repository |
| Should be able to retrieve details about the expression repository to enable referencing the content of this specific expression repository, e.g. for adding and updating content in the expression repository. | Get repository details | |
| Should be able to add expressions to the repository when these are created prior to the implementation within an EHR | Add expression | |
| Should be able to check if an expression constraint conforms to the concept model rules | Validate expression | |
| Should be able to check if expressions exists in the repository, e.g. as part of exploring if new expressions should be created | Lookup expression | |
| Should be able to view the details of each expression in the expression repository | Lookup expression | |
| Should be able to search for expressions using term search | Search for expression | |
| Should be able to retrieve expressions matching specific search criteria, e.g. as part of bulk edit features, expression reviews, etc. | Query expressions | |
| Should be able to update expressions in an expression repository to enable correction of errors or to support updates to a new substrate | Update expression | |
| Should be able to disable or inactivate expressions that are no longer recommended for use | Inactivate expression | |
Clinical user | Should be able to add expressions to the expression repository, e.g.when the EHR supports runtime creation of expressions using form-based data entry | Add expression |
| Should be able to see a term for an expression, e.g. when this is rendered as an option in a clinical user interface | Get display term | |
| Should be able to search for expressions using text-based search, e.g. when expressions are included in a value set bound to a search field | Search for expression | |
| Should be able to store expressions in the EHR data store | Add expression | |
| Should be able to share details about an expression, e.g. to support communication and exchange | Lookup expression | |
| Should be able to query expressions in the same way as pre-coordinated concepts to support tasks such as reporting, clinical data analysis and decision support | Query expressions |
Table 5.1.2-2: Overview of functional requirements for each user involving interactions with the expression repository.
Service Requirements
Create expression repository
Services should be available to support the creation of an expression repository, involving the creation of the structures required to hold the data of the expression repository, as described in 5.1.1 Expression Repository Requirements. These services are required to provide an 'empty' expression repository.
Get repository details
Services should be available for getting details about a generated expression repository. The details can be used when accessing content of this specific expression repository, e.g. when adding, updating or querying expressions.
Add expression
Services should be provided to support the addition of new expressions to the expression repository. These services should ensure that all data required to represent and process expressions are available.
Services for adding expressions will often include the services for validating the expression, transforming the expression and generating the necessary normal form.
Transform expression
Services should be provided to support transformation of the close-to-user form expression to a classifiable form which is required to generate the necessary normal form.
Considerations and approaches to transformation are described in 5.3 Implementation.
Validate expression
Services should be available to check if the close-to-user form of the expression is syntactically valid and conforms to the concept model rules, or any allowed rules for postcoordination.
Generate Necessary Normal form
Services should be provided to support the generation of the necessary normal form of the expression, which is a prerequisite for supporting expressions to be queried in the same way as pre-coordinated content.
Considerations and approaches to the generation of the necessary normal form are described in 5.3 Implementation.
Update expression
Services should be provided to support the updating of expressions while retaining full traceability of previous versions of the expression (similarly to the principles of updating precoordinated SNOMED CT content).
Inactivate expression
Services should be provided to support the indication that an expression is no longer recommended for use. Although inactivated, the expression should be retained in the repository and full traceability of previous versions (similarly to the principles of inactivating precoordinated SNOMED CT content).
Lookup expression
Services should be provided to support access to details about the individual expressions in the repository.
Search for expression
Services should be provided to support searches for expressions in the repository. Lexical searches should be supported based on the terms associated with the concepts included in the expression.
Get display term
Services should be provided to support a human-readable representation of the expression. This service is required to enable the display of expressions in user interfaces, or to support term searching.
Subsumption testing
Services should be provided to test the subsumption relationship between a pair of expressions given the semantics of subsumption
Query expressions
Services should be available to enable subsumption testing between expressions and enable the selective retrieval of postcoordinated expressions satisfying stated criteria. Query services should enable queries to be performed over the content of a specific expression repository plus the content of the versioned edition of SNOMED CT that the repository depends on.
Feedback
Overview
Content Tools
Apps