FHIR:V1.0 FHIR Profiling Guidelines STU3: verschil tussen versies
| Regel 27: | Regel 27: | ||
==Associating functional definition to StructureDefinition== | ==Associating functional definition to StructureDefinition== | ||
| − | |||
| − | |||
Any StructureDefinition that profiles a Resource does so because there is some kind of logical definition ''dictating'' how. These functional definitions are known as Clinical Building Blocks, Health Information models or in Dutch ''Zorginformatiebouwstenen'' or ZIB's. Profiles SHALL have a traceable relationship with their functional counterpart(s). | Any StructureDefinition that profiles a Resource does so because there is some kind of logical definition ''dictating'' how. These functional definitions are known as Clinical Building Blocks, Health Information models or in Dutch ''Zorginformatiebouwstenen'' or ZIB's. Profiles SHALL have a traceable relationship with their functional counterpart(s). | ||
| Regel 44: | Regel 42: | ||
# In our own profiles we can make sure we populate this Element/@id and associate the functional concept on id / id basis. We found that DAF Profiles populate these ids as well. | # In our own profiles we can make sure we populate this Element/@id and associate the functional concept on id / id basis. We found that DAF Profiles populate these ids as well. | ||
#* Example: <element id="Patient:DAF-Patient.extension:race">...</element> | #* Example: <element id="Patient:DAF-Patient.extension:race">...</element> | ||
| − | # In profiles we reference from third parties that do not have this Element/@id populated we need less precise method. | + | # In profiles we reference from third parties that do not have this Element/@id populated we need less precise method. We will deal with that when we need to |
[[Category:FHIR]] | [[Category:FHIR]] | ||
Versie van 30 jun 2016 08:50
Introduction
FHIR requires profiling. To do profiling in a comparable way we need conventions. This page lays out these conventions.
Canonical URL
Any conformance resource needs a canonical URL. This preferably leads somewhere but does not have to be processable. For Nictiz profiles we SHALL use the following structure:
http://[domain]/fhir/[ConformanceResource]/[project]-[name]-[semver.major]
Where:
- [domain] is "nictiz.nl"
- [ConformanceResource] is usually "StructureDefinition" or "ValueSet"
- [project] is preferably the same as its matching ART-DECOR project prefix
- [name] is the name that best depicts the purpose of the Conformance Resource
- [semver.major] is the version of the Conformance Resources. Of the 3 parts in a semantical version a.k.a. semver can contain we SHALL only use the major version
This convention aligns with international initiatives such as DAF and QiCore and has been confirmed/advised by Grahame Grieve
Versioning
Breaking changes constitute a new conformance resource with a new canonical URL. A breaking change is any change that breaks conformance of instances by adding new required contents, removing previously required contents, making previously required contents optional, changing the terminology bindings contents in a incompatible way like removing codes or changing code systems.
Minor changes like adding additional textual guidance, extending value sets without changing semantics are reflected in the StructureDefinition.version, ValueSet.version, OperationDefinition.version etc. The *.version therefor SHALL consist of major.minor version where major matches that of the canonical URL.
Patches are most difficult of all. Patches are most of time also a breaking change. As per the rule of breaking changes this would constitute a new conformance resources and canonical URL. If context allows it, and that really depends on whether there is known group of stakeholders and their implementation status, you might agree on implementing the patch as a (well documented) minor version.
Associating functional definition to StructureDefinition
Any StructureDefinition that profiles a Resource does so because there is some kind of logical definition dictating how. These functional definitions are known as Clinical Building Blocks, Health Information models or in Dutch Zorginformatiebouwstenen or ZIB's. Profiles SHALL have a traceable relationship with their functional counterpart(s).
The FHIR specification contains several solutions for this problem, ConceptMap (>=STU1), StructureMap (>=STU3), ElementDefinition.mapping. Neither of these solutions are mature and cover our use case.
- ConceptMap: works best for value sets and codes
- StructureMap: overcomplicated and unclear how to apply and whether or not this has a future
- ElementDefinition.mapping: is a free text mapping inside the profile. This means we cannot add mappings to profiles from third parties with updating their resource
Proposed way forward:
- The functional definition live in ART-DECOR and every concept in this functional definition has a versioned id
- The technical FHIR profile elements we want to map to have an optional @id attribute, but according to Tracker#9843 it is a required item for profiles (StructureDefinition)
- In our own profiles we can make sure we populate this Element/@id and associate the functional concept on id / id basis. We found that DAF Profiles populate these ids as well.
- Example: <element id="Patient:DAF-Patient.extension:race">...</element>
- In profiles we reference from third parties that do not have this Element/@id populated we need less precise method. We will deal with that when we need to