Issue 17181: AssociationQueryServices WSDL corrections
Issue 17318: CTS2: Possible issue with CTS2 URI
Issue 18469: CTS2: "entityType" description text incorrect - needs to be updated
Issue 18470: CTS2: referencedEntity in Value Set Definitions should include an optional description
Issue 18471: CTS2: "SourceAndNotation" should be made optional in resource version
Issue 18472: CTS2: "documentURI" attribute description in ResourceVersionDescription is incorrect
Issue 18473: CTS2: DocumentURI shouldn't be mandatory in ResourceVersionDescription
Issue 18474: CTS2: Extensible Directories - Allow directories to be extended
Issue 18475: CTS2: Include the signature for the CLONE operation in Change Set
Issue 18476: CTS2: No ROA link to value set resolution of current value set
Issue 18477: CTS2: "versiontag" has wrong type in MapVersion schema
Issue 18478: CTS2: Format and language resolution precedence not described for REST
Issue 18479: CTS2: Additional options needed for Entity Read Query
Issue 18480: CTS2: Redirect behavior isn't clear for uri reads
Issue 18481: CTS2: REST language signature "referencelanguage" needs to be more REST compliant
Issue 18482: CTS2: "readContext" missing on ResolvedValueSetResolution functions
Issue 18483: CTS2: Rest signatures missing for ValueSetDefinitionResolution "resolveAsCompleteSet" function
Issue 18484: CTS2: Documentation for value set resolution needs to be corrected.
Issue 18485: CTS2: ValueSetDefinition REST signatures need to include shortcuts for tags
Issue 18486: CTS2: Map Entry "MapFrom" and "MapTo" need optional description element
Issue 18487: CTS2: CodeSystemCatalogEntry xml schema missing "hasOntologyLanguage" and "includes" elements
Issue 18488: CTS2: Include a depth indicator for AssociationGraph
Issue 18489: CTS2: Make "associationID" optional
Issue 18490: AssociationDirectory needs "associationID"
Issue 18491: CTS2: URIAndEntityName XSD representation does not match UML
Issue 18492: CTS2: ConceptDomainCatalogQueryService (resolve) parameter "directory" type incorrect
Issue 18493: CTS2: CodeSystemCatalogQueryService (resolve and resolveAsList) parameter 'directory' type incorrect
Issue 18494: CTS2: Parents URI needed in EntityDescription
Issue 18517: Need an optional attribute to carry the OID in addition to the URI
Issue 18518: Using enumerations instead of using code systems
Issue 18519: Usage Context Binding Inappropriately Expressed
Issue 18530: CTS2: CTS2Exception doesn't match documentation
Issue 18531: CTS2: IteratableResolvedValueSet and ResolvedValueSet have inconsistent element names
Issue 18532: CTS2: URIAndEntityName references should all be changed to EntitySynopsis, allowing an optional description
Issue 18534: CTS2: Complete binding operation missing from specification
Issue 18541: CTS2: Filter PropertyReference documentation needs clarification
Issue 18542: CTS2: Cardinality of includesResolvedValueSet wrong on ResolvedValueSetHeader
Issue 18562: CTS2: MapTargetList and MapTargetListList need a 'Message' wrapper for REST calls
Issue 18563: CTS2: MapEntry Read and Resolution need WADL 'byURI' REST signatures
Issue 18564: CTS2: WADL Graph URLs need to change to better reflect AssociationDirectory as input
Issue 18610: CTS2: Resource content filtering for Query
Issue 18622: CTS2: AssociationDirectory needs the derivation
Issue 18624: CTS2: Association derivation should be optional and not have a default
Issue 18682: Type of maxtoreturn is string in the WADL definitions. It should be NaturalNumber (or equiv)
Issue 18689: CTS2: ValueSetDefinitionResolution 'resolve' method has incorrect return type
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
Appendix 10 of the OMG "Hitchhiker's Guide" (http://www.omg.org/cgi-bin/doc?hh) specifies a directory structure for organizing submission documents. While older specifications were organized as "spec.omg.org/...", the current direction is that the documents should be organized in "www.omg.org/spec//, where version would be "Beta2", "1.0" for the base spec and "yyyymmmm" for accompanying files. The OMG AB believes that this set of requirements would imply that the CTS2 URIs should change from "http://spec.omg.org/cts2/1.0/" to "http://www.omg.org/spec/cts2/1.0/". Logged: https://github.com/cts2/cts2-specification/issues/90
The current description of entityType in section 2.1.1.1 of the Entity Description Services (page 6) reads: entityType - the set of type(s) which the entityReference is an instance of. Because this is a terminology service, entityType must include one of owl:class, owl:individual, rdf:predicate, or skos:concept, although it may carry many other types as well. This is incorrect - it should read: "... must include one of owl:Class, owl:Individual, rdf:Property or skos:Concept" Note that this may potentially effect some implementations that have either transcribed the information literally or have used "rdf:predicate" instead of "ref:Property" Logged: https://github.com/cts2/cts2-specification/issues/142
AssociatedEntitiesReference.referencedEntity and SpecificEntityList.referencedEntity are currently of type URIAndEntityName. This does not provide any place to include a designation or description of the entity. The type should be changed to EntitySynopsis Logged: https://github.com/cts2/cts2-specification/issues/141
At the moment, SourceAndNotation is a required field. In many situations there is nothing of value that can be supplied here - it should be made optional. Logged: https://github.com/cts2/cts2-specification/issues/140
On page 39 of Core the description of the documentURI attribute in ResourceVersionDescription stops in mid sentence with a "100". Logged: https://github.com/cts2/cts2-specification/issues/139
The DocumentURI was intended to differentiate situations where there were potentially multiple sources of the same version of a resource (e.g. SNOMED CT 20120731 from RF1, RF2, RRF or Owl). This is the exception, rather than the rule, and the DocumentURI field should be made optional for clarity. Logged: https://github.com/cts2/cts2-specification/issues/138
The CTS2 specification describes the minimum (and, at the moment, only) content that can be in directories of various types. Implementers are discovering that they need to add information to this to meet special use cases (e.g. ChangeSetURI and ChangeSetNotes for a special value set authoring environment). We need a way to allow directories to be extended for service specific implementations. Logged: https://github.com/cts2/cts2-specification/issues/137
The change set includes a CLONE type, but we haven't specified a method for asking that a CLONE be performed. We would anticipate that the method signature would include: nameOrURI of the the versionable resource to be Cloned the new version identifier (optional - could be assigned by service or error if it doesn't) the new version URI (optional) the change set URI (we need to check the documentation to see whether there is anything else) Logged: https://github.com/cts2/cts2-specification/issues/135
While it is possible to construct a URL that requests the resolution of the CURRENT version of a value set, there is no href in the ValueSet schema that allows this query to be performed without knowing URL construction rules. There should be another optional link called "resolution" or something similar where a service can provide an href that allows direct access to the value set resolution. Logged: https://github.com/cts2/cts2-specification/issues/134
Line 60 in MapVersion.xsd has the wrong type for versiontag. Change: <xs:element name="versionTag" type="core:MapVersionReference" minOccurs="0" maxOccurs="unbounded"> to <xs:element name="versionTag" type="core:VersionTagName" minOccurs="0" maxOccurs="unbounded"> Change submitted to svn - cts2/spec/submission/OMGServerMap/mapversion/MapVersion.xsd - revision 7877 Logged: https://github.com/cts2/cts2-specification/issues/133
Both the format and language can be supplied as a url parameter or as part of the http header. The current specification doesn't address what to do if both are present. Recommendation is that the command line takes precedence over Accept and Accept-Language in the header. Logged: https://github.com/cts2/cts2-specification/issues/130
The entity and entitybyuri queries currently return an EntityReference that contains zero or more knownEntityDescriptions. They do this even if there is just one knownEntityDescription. This behavior is not what most clients desire
Would recommend the following:
(a) (re-)add the tag that was present in the LexGrid model that could be used to identify one of the coding systems as the "primary"
(b) State that the default behavior of entity and entitybyuri is to redirect to the only or (when present) tagged entry in the specific codesystem version. The id is that //entity/12345 will redirect to //codesystem/{c}/version/{v}/entity/12345 if it is the only describing code system version or its code system (version?) is listed as the primary
(c) add an additional parameter (fwd?) that, when false, says that redirection should not occur.
Logged: https://github.com/cts2/cts2-specification/issues/129
The REST specification doesn't specify what the service behavior should be on "byuri" type queries. Some implementations use a 303 to get to the base resource while others leave the URI as entered. Would propose that the specification say that it should always redirect. Logged: https://github.com/cts2/cts2-specification/issues/128
The current tag, "referencelanguage" is a bit unwieldy from the REST perspective. Would recommend adding a synonym, "lang" to address this issue. Logged: https://github.com/cts2/cts2-specification/issues/127
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 resolveAsCompleteSet function allows the client to ask for a ResolvedValueSet (vs. IterableResolvedValueSet). There is currently no way to do this in the REST functions. Would propose that we add a parameter to queryControl or update the possible values for maxToReturn so a client can indicate that they don't want an iterator, they want the whole thing. We will have to supply a new error message as well - something to the effect of "too much to return all at once" Logged: https://github.com/cts2/cts2-specification/issues/125
The documentation for //valueset/{valuesetid}/definition/{valuesetdefinitionid}/resolution found at http://informatics.mayo.edu/svn/trunk/cts2/spec/psm/rest/html/cts2.html#id1171374283352 makes no sense - we need to check the WADL in this area to see what is going on.
Logged: https://github.com/cts2/cts2-specification/issues/124
Currently there is no way to resolve a value set definition directly without knowing a specific version - it is first necessary to find the definition via query statements. The REST signatures should include:
//valueset/resolution[?tag={tag}], which will resolve CURRENT or tag directly. This has already been implemented in the SVS mat implementation.
Logged: https://github.com/cts2/cts2-specification/issues/123
The mapFrom and mapTo elements in Map Entry are currently of type URIAndEntityName, which doesn't allow an explanatory designation to be provided, meaning that it may be necessary to resolve the returned types against a code system. This type should be changed to EntitySynopsis. Changes have been submitted to CTS2 svn repository as change 7853 Logged: https://github.com/cts2/cts2-specification/issues/122
CodeSystemCatalogEntry.xsd is missing "hasOntologyLanguage" and "includes" elements. These were added to cts2/spec/submission/OMGServerMap/codesystem/CodeSystem.xsd in revision 7641 Logged: https://github.com/cts2/cts2-specification/issues/121
The association graph structure is considerably easier to use if has a dept indicator. While this could be computed, it is much easier to traverse if explicitly present. This change has been added to Association.xsd in cts2/spec/submission/OMGServerMap/association Still needs to be documented and added to the spec itself Logged: https://github.com/cts2/cts2-specification/issues/120
Generating associationID's when none exist just produces noise. The associationID parameter should made optional in the PIM where the service doesn't support AssociationRead. This needs to be changed in the schema AND the spec. Schema has been updated in revision 7752 in cts2/spec/submission/OMGServerMap/association/Association.xsd Logged: https://github.com/cts2/cts2-specification/issues/119
In cases where the associationID is supplied, it is the ID that gets you from the directory contents to the actual association. This change has been added to revision 7733 in cts2/spec/submission/OMGServerMap/association/Association.xsd on 10/4/2012 Logged: https://github.com/cts2/cts2-specification/issues/118
URIAndEntityName does not represent what is in the UML. The UML says that the only thing that is required is the uri – the name and href are optional. The Schema says that the namespace and name is required. Logged: https://github.com/cts2/cts2-specification/issues/98
Section 2.2.1.1 (Operation resolve), input parameter 'directory' is specified as type ConceptDomainDirectoryURI. Type should be 'ConceptDomainCatalogEntryDirectoryURI' Logged: https://github.com/cts2/cts2-specification/issues/97
Section 2.2.1.1 (Operation resolve), input parameter 'directory' is specified as type CodeSystemCatalogURI. Type should be 'CodeSystemCatalogEntryDirectoryURI' Section 2.2.1.2 (Operation resolveAsList), input parameter 'directory' is specified as type CodeSystemCatalogURI. Type should be 'CodeSystemCatalogEntryDirectoryURI' Logged: https://github.com/cts2/cts2-specification/issues/96
EntityDescription provides URI's for children, descendants and ancestors, but it only provides parents directly. While this is useful, it means that applications that are traversing graphs have to have two different mechanisms - one for the first three categories and a second for parents. We should add one more attribute, "parents" which allows parents to be accessed by URI as well. Logged: https://github.com/cts2/cts2-specification/issues/136
In the description of the Code System Catalog Entry the identification is done via the Code System name: “codeSystemName - the local identifier that uniquely identifies the code system within the context of the implementing service. Note that the about URI is the globally unique identifier”. The HL7 culture is used to manage messages and documents via OIDs which. An optional attribute: CodeSystemOID is needed. The issue here is not turning an OID into a URI but having the possibility to have SIMULTANEOUSLY the URI and OID present (an additional attribute aside from about). In all IHE domains we use OIDs to identify objects. There is no strong consensus and a mechanism of sharing URI so that complete interoperability can be achieved. In this transition context we need a means to assure this transition while assuring interoperability. https://github.com/cts2/cts2-specification/issues/144
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
CTS2Exception in the PIM consists of message and severity. The XML schema has an extra element that makes no sense - ExceptionType. This appears to be an artifact that was accidentally left in the UML model, but is never used in the spec itself. This should be removed from both places - the UML and the exception schema Logged: https://github.com/cts2/cts2-specification/issues/148
ResolvedValueSet has 'member' elements while IteratableResolvedValueSet has 'entry' elements. Recommend moving all elements to 'entry' as that is the pattern for everything else. Logged: https://github.com/cts2/cts2-specification/issues/147
Issues #141 (http://www.omg.org/issues/cts2-rtf#Issue18470) and #122 (http://www.omg.org/issues/cts2-rtf#Issue18486) add an optional description to valueSetEntry, mapFrom and mapTo. It appears that, with the exception of EntityType and ResourceType, the remainder of the URIAndEntityName references should all be changed to EntitySynopsis, allowing an optional description. Would propose removing EntitySynopsis completely from the model and moving its description property to URIAndEntityName. Logged: https://github.com/cts2/cts2-specification/issues/143
There is no method with a signature: f(conceptDomain, context[0..*], codeSystemVersion[0..*], tag[0..1]) --> ResolvedValueSet (In that there is no way to say "Give me the resolved value set for this concept domain in this context") https://github.com/cts2/cts2-specification/issues/149
The PropertyReference class in Filter, and corresponding elements in the query signatures doesn't specify exactly how one should create a referenceTarget for references of type Attribute. As an example, how would one go about specifying the uri attribute in the source component of a sourceAndRole element? The behavior is underspecified if the reference not to a leaf (e.g. "sourceAndRole") Recommend it should specify match anything except href. If it is going to require URIAndEntityName (vs. 'or'), we need to clearly state what URI is used in the CTS2 spec. Otherwise we need to change the signature to allow just a name (preferred). Logged: https://github.com/cts2/cts2-specification/issues/151
The UML model in figure 4.4 of the ValueSet document lists the cardinality of includesResolvedValueSet as [0..1]. It should be [0..*]. https://github.com/cts2/cts2-specification/issues/150
In the schema: http://www.omg.org/spec/cts2/201206/mapversion/MapEntryServices.xsd, the types 'MapTargetList' and 'MapTargetListList' need corresponding Message elements, such as 'MapTargetListMsg' and 'MapTargetListListMsg.' The WADL would need to be updated accordingly to represent the new return types. Logged: https://github.com/cts2/cts2-specification/issues/154
In the WADL, two MapEntry URLS were omitted:
map/{map}/version/{version}/entrybyuri?uri=...
map/{map}/version/{version}/entrybyuri/resolution?uri=.
Logged: https://github.com/cts2/cts2-specification/issues/153
Currently, to get an association graph in REST, the graph is retrieved by: /codesystem/cs/version/1.0/graph It would be more correct to be like: /codesystem/cs/version/1.0/associations/graph to take into account the 'graph' taking in the association directory as an input. Right now, the 'graph' resource is used in place of the 'associations' resource, but this makes it very hard to do queries such as: /codesystem/cs/version/1.0/entity/C12345/children/graph Logged: https://github.com/cts2/cts2-specification/issues/152
In each Query Service, it would be helpful for the user to be able to select certain attributes of the resource to be included (or excluded). For instance, a user may only be interested in the Definitions, or a given named property. Right now, for the Query Service, the user is limited to either 1) the directory entry, or 2) the list representation, which is the entire resource. It would be helpful to have the option of something in between. Logged: https://github.com/cts2/cts2-specification/issues/155
The derivation attribute (INFERRED/ASSERTED) needs to be visible in an association directory, as it helps consumers understand the abstract structure. Logged: https://github.com/cts2/cts2-specification/issues/156
The specification states that derivation can be ASSERTED, INFERRED or omitted, meaning that the derivation is unknown. The UML diagram shows it as required, which is wrong. The XML Schema shows it with a default of ASSERTED, which also needs to be removed. Logged: https://github.com/cts2/cts2-specification/issues/157
Type of maxtoreturn is string in the WADL definitions. It should be NaturalNumber (or equiv) Logged: https://github.com/cts2/cts2-specification/issues/158
ValueSetDefinitionResolution 'resolve' method has incorrect return type. It should be IterableResolvedValueSet. 6.1.1.1 Operation: resolve Resolve the value set definition against the supplied code system versions and/or version tags. .... Return Type: ResolvedValueSetDirectory should be: 6.1.1.1 Operation: resolve Resolve the value set definition against the supplied code system versions and/or version tags. .... Return Type: IterableResolvedValueSet Logged: https://github.com/cts2/cts2-specification/issues/159