This wiki has undergone a migration to Confluence found Here
Difference between revisions of "ConceptMap FHIR Resource Proposal"
Jump to navigation
Jump to search
| Line 21: | Line 21: | ||
* Vocabulary | * Vocabulary | ||
| + | * MnM | ||
==FHIR Resource Development Project Insight ID== | ==FHIR Resource Development Project Insight ID== | ||
| Line 28: | Line 29: | ||
==Scope of coverage== | ==Scope of coverage== | ||
| − | This resource expresses a mapping from one | + | This resource expresses a mapping from one set of concepts to another. One key case is where the concepts are represented in a value set |
Each mapping has the following qualities: | Each mapping has the following qualities: | ||
* a unidirectional mapping | * a unidirectional mapping | ||
* from a concept in one system to a concept in another | * from a concept in one system to a concept in another | ||
| − | * the mapping is only claimed to be valid in the context of the source and target value set | + | * the mapping is only claimed to be valid in the context of the source and target value set (if supplied) |
| − | * supports mapping between any code system as defined by the value set resource (and by extension, the core principles) | + | * value sets: supports mapping between any code system as defined by the value set resource (and by extension, the core principles) |
| − | * This will be used to capture and share mappings between code systems | + | * This will be used to capture and share mappings between code systems, and between element definitions in models |
| − | * scope is not constrained by subject, discipline, environment, or locale | + | * scope of this resource is not constrained by subject, discipline, environment, or locale |
==RIM scope== | ==RIM scope== | ||
| Line 44: | Line 45: | ||
This resource: | This resource: | ||
| − | * Represents a well understood, "important" concept in the business of healthcare: mapping between code systems | + | * Represents a well understood, "important" concept in the business of healthcare: mapping between code systems or models |
| − | * Represents a concept expected to be tracked with distinct, reliable, unique ids: maps | + | * Represents a concept expected to be tracked with distinct, reliable, unique ids: maps are important and expensive assets to be tracked and shared |
* Reasonable for the resource to be independently created, queried and maintained: yes - maps get created and curated | * Reasonable for the resource to be independently created, queried and maintained: yes - maps get created and curated | ||
* Declared interest in need for standardization of data exchange: yes - there is need both exchange maps and also to use maps in service of exchange | * Declared interest in need for standardization of data exchange: yes - there is need both exchange maps and also to use maps in service of exchange | ||
* Resource is expected to contain an appropriate number of "core" (non-extension): current design has 19 elements | * Resource is expected to contain an appropriate number of "core" (non-extension): current design has 19 elements | ||
| − | * Have the characteristics of high cohesion & low coupling: this is a focused infrastructure resource with a clearly | + | * Have the characteristics of high cohesion & low coupling: this is a focused infrastructure resource with a clearly defined boundary |
| − | |||
==Expected implementations== | ==Expected implementations== | ||
| Line 69: | Line 69: | ||
* IHTSDO Mapping format | * IHTSDO Mapping format | ||
* ISO/AWI TR 12300 | * ISO/AWI TR 12300 | ||
| + | * ISO 11179 | ||
==Example Scenarios== | ==Example Scenarios== | ||
| Line 85: | Line 86: | ||
* in it's existing form, it wasn't proposed for the DSTU, and therefore would be post DSTU | * in it's existing form, it wasn't proposed for the DSTU, and therefore would be post DSTU | ||
* However the tools need it to exist to meet DSTU comments around code mappings needing to be provided | * However the tools need it to exist to meet DSTU comments around code mappings needing to be provided | ||
| − | * | + | * was published as informative with the DSTU (with disclaimer explaining the status), should now become a full resource |
==gForge Users== | ==gForge Users== | ||
Grahame | Grahame | ||
Revision as of 18:07, 17 May 2014
This page documents a Pending FHIR Resource Proposal
Contents
- 1 ConceptMap
- 1.1 Owning committee name
- 1.2 Contributing or Reviewing Work Groups
- 1.3 FHIR Resource Development Project Insight ID
- 1.4 Scope of coverage
- 1.5 RIM scope
- 1.6 Resource appropriateness
- 1.7 Expected implementations
- 1.8 Content sources
- 1.9 Example Scenarios
- 1.10 Resource Relationships
- 1.11 Timelines
- 1.12 gForge Users
ConceptMap
Owning committee name
FHIR Project Team
Contributing or Reviewing Work Groups
- Vocabulary
- MnM
FHIR Resource Development Project Insight ID
Whichever one FHIR works under
Scope of coverage
This resource expresses a mapping from one set of concepts to another. One key case is where the concepts are represented in a value set Each mapping has the following qualities:
- a unidirectional mapping
- from a concept in one system to a concept in another
- the mapping is only claimed to be valid in the context of the source and target value set (if supplied)
- value sets: supports mapping between any code system as defined by the value set resource (and by extension, the core principles)
- This will be used to capture and share mappings between code systems, and between element definitions in models
- scope of this resource is not constrained by subject, discipline, environment, or locale
RIM scope
Out of scope for the RIM - this is in the MIF space.
Resource appropriateness
This resource:
- Represents a well understood, "important" concept in the business of healthcare: mapping between code systems or models
- Represents a concept expected to be tracked with distinct, reliable, unique ids: maps are important and expensive assets to be tracked and shared
- Reasonable for the resource to be independently created, queried and maintained: yes - maps get created and curated
- Declared interest in need for standardization of data exchange: yes - there is need both exchange maps and also to use maps in service of exchange
- Resource is expected to contain an appropriate number of "core" (non-extension): current design has 19 elements
- Have the characteristics of high cohesion & low coupling: this is a focused infrastructure resource with a clearly defined boundary
Expected implementations
- this is already implemented by the tools to express FHIR mappings to v2 and v3, and will be used by the run-time tool to assist with validation and operational mappings
- this will be used underneath implementations of the questionnaire resource to capture mappings of data elements and their contents between systems
- this would be taken up by any FHIR based implementation of vocabulary related services
- profile editors will need to express code mappings on a regular basis
see http://hl7.org/implement/standards/fhir/conceptmap.htm
Content sources
- Internal tooling requirements
- MIF
- CTS 2
- Core Principles
- IHTSDO Mapping format
- ISO/AWI TR 12300
- ISO 11179
Example Scenarios
- mappings from FHIR to v2 and v3
- mappings from a local code set to a LOINC code set
Resource Relationships
- this resource references ValueSet.
- No direct plans for other resources to reference it yet, but it may impact in future planning for the Profile resource
Timelines
- This resource already exists in an operational non-reviewed form
- in it's existing form, it wasn't proposed for the DSTU, and therefore would be post DSTU
- However the tools need it to exist to meet DSTU comments around code mappings needing to be provided
- was published as informative with the DSTU (with disclaimer explaining the status), should now become a full resource
gForge Users
Grahame
