Page History
Scrollbar | ||
---|---|---|
|
Page info | ||||
---|---|---|---|---|
|
The authoring core provides the ability to create and manage change sets and properties – aspects that are common to all authoring services.
The LexEVS API and the LexGrid model have been designed to provide capabilities to make changes to the terminology elements such as code system or value sets.
However, the current LexGrid architecture and model is based on the premise that the information being provided is valid and consistent and is not designed to support partially formed artifacts such as concepts without associated codes and associations that have a source but no target.
The LexEVS authoring task assumes that there is an external authoring tool that persists partially formed content and performs the necessary validation and reasoning tasks prior to the content being incrementally loaded into the LexEVS services.
We see this as being a necessary separation, as the potential combination of editors, reasoners, terminology models, other terminology management tooling is almost limitless, and each of these will have its own requirements when it comes to completeness and validity.
Tip | ||
---|---|---|
| ||
Before the changed terminology content is sent to LexEVS Authoring API to process, the client application should make sure that the contents are valid.
|
The intent of the change requests is as follows:
- NEW - to create a new versionable element
- MODIFY - to change the attributes of an existing versionable element
- VERSIONABLE - to change (or schedule a change of) the status of a versionable element within the context of the containing service.
- REMOVE - to remove a versionable element from the service. (Note that VERSIONABLE Retire should be used if the element and its history should remain.)
- DEPENDENT - no changes are to be made to the named element itself, but a versionable element whose identity is dependent upon this element is to undergo a change.
Additional information is available at: LexEVS Authoring
Scrollbar | ||
---|---|---|
|
- Resource Description ? a changeable element that is a collection of assertions about an external IRI. In the CTS2 specification, resource descriptions describe resources of type:
Code system – an abstraction of a code system such as the Gene Ontology, the Dublin Core Metadata Terms or SNOMED CT. - Code system version – a specific version or release of an abstract code systems, drawn from a specific source, such as the "OBO rendering Gene Ontology Version that was released on May 13, 2010 at 14:00 Pacific time",
the "RDF rendering of 2008/01/14 release of the Dublin Core Metadata Terms" and the "OWL rendering of the 2010AA SNOMED CT release as interpreted by Kent Spackman's table to OWL conversion utility".
- Abstract value set – an abstract value set, such as “The Wound History Value Set”.
- Value set definition ? the "Definition of the Wound History value set drawn from the Initial Load VADS 3.0".
- Value set resolution rules --a set of rules for representing a value set in a specific context, such as “the English rendering of The Wound History Value Set for data input”.
- Value set resolution rule version – a specific version of a set of value set resolution rules.
- Concept domain – the name of a conceptual domain that can be associated with one or more sets of value meanings depending on the use and context, such as “the HL7 ObservationType concept domain.
- Concept domain binding rules – a collection of rules for assigning a concept domain with a specific value set – such a “binding rules for the HL7 ObservationType as defined in Version:
V 02?30 (12/3/2009) of the HL7 Reference Information Model (RIM)”.
...