Issue 17181: AssociationQueryServices WSDL corrections
Issue 18482: CTS2: "readContext" missing on ResolvedValueSetResolution functions
Issue 18518: Using enumerations instead of using code systems
Issue 18519: Usage Context Binding Inappropriately Expressed
Issue 17181: AssociationQueryServices WSDL corrections (cts2-rtf)
Click here for this issue's archive.
Source: Mayo Clinic (Mr. Craig Stancl, stancl.craig(at)mayo.edu)
Nature: Uncategorized Issue
Severity:
Summary:
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
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
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
This crosses into the boundary of a UML model and the CTS2 API. CTS2 makes three different uses of value sets: 1) Concept domains with application specific value sets. The "status" property of CodeSystemVersionCatalogEntry is an example of this, where the specific status values depeend on the particular work flow model for the contained terminology. 2) Concept domains with recommended but not mandated value sets. The CodeSystemCatalogEntry calls for ontologyDomain, ontologyType, designedForOntologyTask, etc. While not mandated in the standard, each of these domains has a recommended value set - in this case, a set drawn from the Ontology Meta Vocabulary (OMV) 3) Concept domains with mandated value sets. While the specification isn't as obvious about this as it should be, the intent is that the language and format fields in the OpaqueData element should be drawn from value sets constructed from the IETF/ISO language and mime codes 4) Concept domains that are coupled with the CTS2 model itself. Examples of this include the "describedResourceType" and "entrySate" properties of ResourceDescription, where "describedResourceType" identifies the particular type of resource (CodeSystemVersionCatalogEntry, ConceptDomain, MapCatalogEntry, etc.). The first three cases could and, ideally, should be represented by ConceptDomain-ConceptDomainBinding-ValueSet entries in a CTS2 service. As an example, the CTS2 concept domain, "ontologyDomain" could be bound to an OntologyDomain value set derived from the OMV. The fourth case, however, would not lend a lot to the specification, for two reasons. The first reason is that not all of the model elements even appear in a given PIM. The "describedResourceType" element, in particular, is not actually represented in XML Schema, as the XML Element name itself determines which type of resource is represented. The second reason is a CTS2 service or client would have no idea what do do an "entryState" or "describedResourceType" that wasn't already part of the spec. The semantics of ACTIVE and INACTIVE are clearly defined, but what would a client do if it received a status of "PROPOSED" as an entry state? Similarly, adding a new "describedResourceType" would be the equivalent of adding a new model element that is not described in the specification. The behavior of a client (or server) in this case would be undefined. This does not prevent the specification from being extended using UML, however. One could import the CTS2 Core specification and extend or replace the existing enumerations to represent new or additional model types. We had actually considered separating the change set model from the rest of the specification because there is nothing in there that is terminology specific. We decided against it, however, as it fell outside of the scope of the CTS2 RFP. In summary, while we definitely need to deploy a CTS2 service that serves the concept domains and value sets that are used by the CTS2 specification itself, we see little to be gained by restructuring the existing CTS2 specification to represent UML model enumerations as CTS2 value sets. Note, however, that there is work underway to define a CTS2 / UML profile that will be able to bridge some of these issues by formally defining the relationship between UML Property Types, Enumeration and Enumeration Literal with CTS2 Concept Domain, Value Set, and Resolved Value Set and URIAndEntityName. It is proposed we address this issue again in a future revision task force. Disposition: Deferred
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