Package oracle.hsgbu.ets.base

Contains base classes common to all components of ETS.

See: Description

Interface Summary

Interface	Description
AttributableETSComponent	Parent interface of the ETSComponent objects that have attributes.
CandidateLocaleMap	Represents a proposed mapping from requested/given Locale to a Locale for a Coding Scheme Version.
Classification	Represents a container of Concept objects.
ClassificationDeclaration	Represents a declaration in a classification.
CodingScheme	Represents a healthcare terminology, such as ICD-9, LOINC, or SNOMED.
CodingSchemeVersion	Represents a single version or release of a CodingScheme object, such as SNOMED-CT July 2004.
Concept	Represents a single idea within a terminology version.
ConceptContainer	Defines a read-only interface for ETS objects that mimic containers of concepts.
ConceptDescription	Represents a single description for a Concept and may be associated with UsageContext.
ConceptList	Represents a list of Concept objects.
ConceptListMember	Represents a Concept member belonging to a ConceptList.
ETSAdministrationService	Provides methods to create, retire, modify, and remove objects from the ETS repository.
ETSAttribute	Defines a generic name/value pair attribute that can be assigned to AttributableETSComponent objects.
ETSComponent	Abstract parent for all objects stored in the ETS repository.
ETSService	Provides a starting point for terminology services.
HierarchicalConcept	Defines common methods for terminologies that have a tree-like structure for concepts.
LocalConceptDescription	Represents a locally-specified description for a concept.
LocaleMap	Represents a mapping from a requested/given Locale for a Coding Scheme Version.
ReassignableETSComponent	Represents an ETSComponent that can have attributes and be reassigned to another ETSComponent.
Relationship	Represents a relationship between two concepts in a CodingSchemeVersion.
RetirableETSComponent	Represents an ETSComponent that can have attributes, can retire from the ETS repository, and can have its status changed to retired in the ETS repository.
TerminologyConceptDescription	Represents a terminology vendor-specified description for a Concept.
UsageContext	Provides a context in which a concept is to be described or defined.

Package oracle.hsgbu.ets.base Description

Contains base classes common to all components of ETS.

These classes provide the foundation for all of the terminology-specific functionality.

Some key interfaces are:

CodingScheme

A coding scheme represents a body of terminology data, which may be versioned over time. SNOMED-CT, ICD-10, and LOINC are examples of common coding schemes. Creation and manipulation of Coding Schemes are performed using ETSAdministrationService and ETSService.

Concept

A concept is a single representation of an idea within a coding scheme version. A concept is required to have a code defined by the terminology vendor or maintainer, referred to as the concept code. The concept code must be unique within a coding scheme version. Concepts are also required to be associated with at least one description.

Classification

A container used to group Concept objects that belong to a particular category of meaning. Example, antibiotics or pulmonary diseases. The concepts may be from one or more terminologies. Classifications may be arranged hierarchically.

ETSAdministrationService

Provides services such as create, update, and remove Object in the ETS repository. Some of the services provided by this interface are:

• Creating Coding Scheme.
• Creating concept list.
• Getting all versions of Coding Scheme.
• Retiring concept list.

ETSService

Provides services that interact with terminologies stored in ETS. Some of the services provided by this interface are:

• Getting concept list.
• Finding concepts.

Locale Handling

ETS multiple language support (MLS) is based on the mapping provided for the given/requested Locale to the mapped Language Code. The requested/given Locale will be valid if and only if it conforms with ISO standards. The country code of the Locale must be as per ISO 3166 specification(i.e 2-letter country codes defined in ISO 3166) and the language code of the Locale must be as per ISO 639 specification (i.e 2-letter language codes defined in ISO 639). The variant part of a Locale is not supported in ETS.

ETS global wild cards for language code(i.e XX) and country code (i.e XX) are also allowed for Locale. System will consider these wild cards as a substitution for any

Language Code

Language code will be obtained by concatenating the language code(in upper case) of the Locale with country code of the Locale(in upper case).

The search for the description for the given ISO Locale in the request for a particular version will occurs in following preference ordering

1)Search for the description for the exact mapping for Language Code for the given Locale language code and country code.

2)Search for the description for the exact mapping for Language Code for the given Locale language code and country code wild card (i.e XX)

3)Search for the description for the exact mapping for Language Code for the language code wild card (i.e XX) and country code wild card (i.e XX)

Base language is the constructed using the profile options values ETS MLS Language Code and ETS MLS Country Code.

The method getLanguageLocale() on the SessionContext returns the Locale preference of the currently logged-in user.

Non-MLS APIs

MLS-specific behavior only applies to ETS methods that deal with ConceptDescription objects, or to methods that retrieve a Concept object and also prefetch its associated descriptions.

Some of these methods have been overloaded so that a Locale parameter can be specified. Those that do not accept a Locale will automatically default to using the base language. An exception to this rule applies to the APIs that retrieve ConceptDescription objects by their ETS ID; in this case the description will always be retrieved, no matter which Locale it is in. Another exception applies to the APIs that search descriptions according to a text pattern. These APIs do not filter results according to a specific Locale.

Note: It is possible for Non-MLS APIs to return descriptions in a language other than the base language under one condition: If the base language is mapped to another Language Code for a terminology version. See the Language Mappings section below for information on language mappings.

Language Mappings

Language mappings are used to specify how the requested/given Locale correspond to the languages that a terminology version provides. They are also used as a way of not having to provide concept descriptions in every language for a given terminology. For example, a terminology may provide descriptions in one language only, here mappings will allow descriptions to be looked up in all other languages without having to update the terminology to add descriptions in these languages.

Note: Language mappings do not imply that descriptions are automatically translated. When requesting descriptions in a language that is mapped to Language Code, the description text will be identical regardless of which language is requested.

The impact of language mappings on the APIs that retrive ConceptDescription objects is that a description may be returned that will have a Locale other than the requested Locale.

Service Crosstalk

Service crosstalk may occur if two instances of an ETSService or related service objects (admistration service, authoring service) are used interchangably. In this situation it is possible for one of the ETSService objects to use the connection information of another ETSService object. This may have auditing consequences as the connection information is associated with the session of the currently logged in user. As a result only a single instance of each of these objects should be used per thread. Sharing instances between threads or using multiple instances in the same thread is strongly discouraged.

This occurs only if objects retrieved from one instance of a service object are passed to another instance of a service object. Some of the APIs on the service objects require one of the ETS component objects (CodingScheme, ConceptList, etc) to be passed in as a parameter.

Component objects are aware of the user's session from which they were retrieved and passing an object instance into an instance of a service object will cause the component object's session to be used (and not the session that the service is asssociated with).

For example, the following code will demonstrate this erroneous behaviour:

  // Get an ETS service for Bob
  ServiceLocator sl1 = ServiceLocator.getInstance();
  sl1.login("bob", "bob");
  ETTSService etsBob = sl1.getETSService();

  // Get and ETS service for Mary
  ServiceLocator sl2 = ServiceLocator.getInstance();
  sl2.login("mary", "mary");
  ETSService etsMary = sl2.getETSService();

  // Get the SNOMED coding scheme and all of it's versions
  CodingScheme cs = etsBob.getCodingScheme("SNOMED-CT");
  CodingSchemeVersion[] cvs = etsMary.getAdministrationServiceInstance().getAllVersionsForScheme(cs);

This example causes the CodingScheme and all of the CodingSchemeVersion objects to be retrieved as the user 'bob'. Even though the coding scheme versions are requested on the service belonging to Mary, they are requested with a CodingScheme object that belongs to Bob, which will force Mary's ETS service to use Bob's session.