DSTU2 Ballot Source
This page is part of the FHIR Specification (v0.5.0: DSTU 2 Ballot 2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions 
. Page versions: R5 R4B R4 R3 R2
This resource has 3 operations associated with it. For more information about operations, including how they are invoked, see Operations.
Translate a code from one value set to another, based on the existing value set and concept maps resources, and/or other additional knowledge available to the server.
One (and only one) of the in parameters (code, coding, codeableConcept) must be provided, to identify the code that is to be translated.
The outcome is an operationOutcome with hints, warnings, or errors, or the translated code in an extension
Formal Definition (as a OperationDefinition).
URL: [base]/ConceptMap/$translate
URL: [base]/ConceptMap/[id]/$translate
| In Parameters: | ||||
| Name | Cardinality | Type | StructureDefinition | Documentation |
| code | 0..1 | code | The code that is to be translated. If a code is provided, a system must be provided | |
| system | 0..1 | uri | The system for the code that is to be translated | |
| version | 0..1 | string | The version of the system, if one was provided in the source data | |
| valueSet | 0..1 | uri | Identifies the value set used when the concept (system/code pair) was chosen. May be a logical id, or an absolute or relative location | |
| coding | 0..1 | Coding | A coding to translate | |
| codeableConcept | 0..1 | CodeableConcept | A full codeableConcept to validate. The server can translate any of the coding values as it chooses | |
| target | 1..1 | uri | Identifies the value set in which a translation is sought. May be a logical id, or an absolute or relative location | |
| Out Parameters: | ||||
| Name | Cardinality | Type | StructureDefinition | Documentation |
| result | 1..1 | boolean | True if the concept could be translated | |
| message | 0..1 | string | Error details, if result = false. If this is provided when result = true, the message carries hints and wanrings | |
| equivalence | 0..1 | code | A code indicating the equivalence of the translation, using values from [ConceptMapEquivalence]{concept-equivalence.html} | |
| outcome | 0..1 | Coding | The translation outcome | |
Translate a set of concepts from one value set to another, based on the existing value set and concept maps resources, and/or other additional knowledge available to the server
Formal Definition (as a OperationDefinition).
URL: [base]/ConceptMap/$batch
| In Parameters: | |||||
| Name | Cardinality | Type | StructureDefinition | Documentation | |
| item | 0..* | An item to be translated | |||
| concept | 1..1 | CodeableConcept | A codeable concept to be translated. If the source is a coding, or a code/system pair, wrap it in a CodeableConcept | ||
| target | 1..* | uri | Identifies the value set in which a translation is sought. May be a logical id, or an absolute or relative location. If more than one is provided, multiple translations are requested for the concept | ||
| map | 0..1 | Reference(ConceptMap) | A specific concept map to use for the translation. If none is provided, the server chooses which concept map to use | ||
| Out Parameters: | |||||
| Name | Cardinality | Type | StructureDefinition | Documentation | |
| item | 0..* | The outcome of validating an item. There must be an entry for every item in the same order | |||
| result | 1..1 | boolean | True if the concept could be translated | ||
| message | 0..1 | string | Error details, if result = false. If this is provided when result = true, the message carries hints and wanrings | ||
| equivalence | 0..1 | code | A code indicating the equivalence of the translation, using values from [ConceptMapEquivalence]{concept-equivalence.html}. TODO: what about multiple translations? | ||
| outcome | 0..1 | CodeableConcept | The translation outcome - a CodeableConcept to allow for multiple translations | ||
This operation provides support for ongoing maintenance of a client-side closure table based on server-side terminological logic. For details of how this is used, see Maintaining a Closure Table
Formal Definition (as a OperationDefinition).
URL: [base]/$closure
| In Parameters: | ||||
| Name | Cardinality | Type | StructureDefinition | Documentation |
| name | 1..1 | string | The name that defines the particular context for the subsumption based closure table | |
| concept | 0..* | Coding | Concepts to add to the closure table | |
| version | 0..1 | id | A request to resynchronise - request to send all new entries since the nominated version was sent by the server | |
| Out Parameters: | ||||
| Name | Cardinality | Type | StructureDefinition | Documentation |
| return | 1..1 | ConceptMap | A list of new entries (code / system --> code/system) that the client should add to its closure table. The only kind of entry mapping equivalences that can be returned are equal, narrower, wider, and unmatched Note: as this the only out parameter, it is a resource, and it has the name 'return', the result of this operation is returned directly as a resource | |
© HL7.org 2011+. FHIR DSTU (v0.5.0-5149) generated on Fri, Apr 3, 2015 14:30+1100.
Links: What's a DSTU? |
Version History |
Specification Map |
Compare to DSTU1 |
|
Propose a change