The Usage Context (in the PIM the applicableContext) is represented as an attribute of the ConceptDomainBinding class. applicableContext - a realm or context in which the particular binding applies. If not present, the binding applies in any context not stated in another binding.
In the SFM it is represented as a class entirely apart providing detailed information about the binding. If we have two different value sets belonging to the same Concept Domain but with different usage contexts, this cannot work. Moreover, in most implementation guides, the Concept Domains are not specified, indicting just the Usage Context as Concept Domains are something very specific to HL7 (they can be inferred), and the Usage Contexts are expressed as OIDs and not as URIs (enforcing the fact that we need the possibility to simultaneously define an entity via an URI and an OID)

Use Case:
The value set epSOSActiveIngredient 1.3.6.1.4.1.12559.11.10.1.3.1.42.24 consists of the whole ATC and it is the most important piece of information in the medication identification in epSOS. The same value set is being used in 3 different documents in 4 different sections with 4 different entries:

Prescription Item Entry 1.3.6.1.4.1.12559.11.10.1.3.1.3.2
Dispensed Medicine Entry
1.3.6.1.4.1.12559.11.10.1.3.1.3.3
Medication Item Entry
1.3.6.1.4.1.12559.11.10.1.3.1.3.4
Allergy & Intolerance Concern Entry
1.3.6.1.4.1.19376.1.5.3.1.4.5.3

Prescription Section
1.3.6.1.4.1.12559.11.10.1.3.1.2.1
Dispensation Section
1.3.6.1.4.1.12559.11.10.1.3.1.2.2
Medication Summary Section 1.3.6.1.4.1.12559.11.10.1.3.1.2.3
Allergies and Other Adverse Reactions Section
1.3.6.1.4.1.19376.1.5.3.1.3.13

In the follwing documents:
ePrescription
eDispensation
Patient Summary
Patient Summary

The corresponding Concept Domain is EntityCode and the subdomain is ActiveIngredientDrugEntityType for all four Usage Contexts; however they are entirely different. Logged: https://github.com/cts2/cts2-specification/issues/146

The PIM uses enumeration rather than having a code system of its own. This does not allow for new codes to be added easily (need another enumeration), a separate documentation is needed for the definition of what the enumerations mean, and translations are not possible. Two such examples are the enumeration Resource Type with 7 possible values such as CODE_SYSTEM, CODE_SYSTEM_VERSION, CONCEPT_DOMAIN, MAP, MAP_VERSION, VALUE_SET, VALUE_SET_DEFINITION and the enumeration CHANGE TYPE with the enumerations: CREATE, UPDATE, METADATA, DELETE, CLONE, IMPORT. It would good terminology practice for the international specifications of terminology server to use an internal code system rather than use enumerations. Logged: https://github.com/cts2/cts2-specification/issues/145

The 'resolve' functions in ResolvedValueSetResolution lack a readContext - this is an oversight and needs to be corrected.

Logged: https://github.com/cts2/cts2-specification/issues/126

Rename method 'getKnownCodeSystems' to 'getKnownCodeSystem'.

Rename method 'getKnownCodeSystemVersions' to 'getKnownCodeSystemVersion'.

Rename method 'getSupportedVersionTags' to 'getSupportedVersionTag'.

In method 'restrictToTargetExpression' change the type of param 'target' to EntityExpression

In method 'count' add parameter 'timeout'.

In method 'getAllSourceAndTargetEntities' change the type of param 'directory' to EntityDirectoryURI

In method 'restrict' change the type of param 'directory' to DirectoryURI

In method 'restrictToTargetLiteral' change the type of param 'target' to String

Logged: https://github.com/cts2/cts2-specification/issues/50