Brontekst bekijken van FHIR:Vprepub-1.0 FHIR Profiling Guidelines STU3

==Introduction==

[http://hl7.org/fhir FHIR] requires [http://hl7.org/fhir/profiling.html profiling]. To do profiling in a comparable way we need conventions. This page lays out these conventions. 

The created profiles are generally based on the [https://zibs.nl/wiki/HCIM_Mainpage| Health and Care Information models (HCIM)] defined by the program ‘Registratie aan de bron’ (Data capture at the point of Care) for the Netherlands. In the Netherlands, these models are more commonly known by the name zorginformatiebouwstenen or ZIB's. In this text, we make use of the HCIM abbreviation. The section [https://informatiestandaarden.nictiz.nl/wiki/FHIR_Profiling_Guidelines#Associating_functional_definition_to_StructureDefinition Associating functional definition to StructureDefinition] provides more information regarding these information models.

==Canonical URL==

Any conformance resource needs a canonical URL. This preferably leads somewhere but does not have to be processable. Canonical URL's are about the ''identity'' of artifacts, not necessarily about retrieval location. URIs for the latter (for artifacts living in ART-DECOR) are described in [https://www.art-decor.org/mediawiki/index.php?title=FHIR_URIs ART-DECOR FHIR_URIs].  

For Nictiz profiles we SHALL use the following structure:

*For [http://zibs.nl HCIM] related profiles (this should be the majority of profiles):<br/>http://<nowiki>[</nowiki>domain<nowiki>]</nowiki>/fhir/StructureDefinition/zib-<nowiki>[</nowiki>English hcim name<nowiki>]</nowiki>
*For extensions pertaining to 1 HCIM:<br/>http://<nowiki>[</nowiki>domain<nowiki>]</nowiki>/fhir/StructureDefinition/zib-<nowiki>[</nowiki>English hcim name<nowiki>]</nowiki>-<nowiki>[</nowiki>English hcim concept name<nowiki>]</nowiki>
*For extensions pertaining to multiple HCIM:<br/>http://<nowiki>[</nowiki>domain<nowiki>]</nowiki>/fhir/StructureDefinition/<nowiki>[</nowiki>purpose<nowiki>]</nowiki>
*For other profiles:<br/>http://<nowiki>[</nowiki>domain<nowiki>]</nowiki>/fhir/StructureDefinition/<nowiki>[</nowiki>project<nowiki>]</nowiki>-<nowiki>[</nowiki>name<nowiki>]</nowiki>
*For value sets related to HCIMs:<br/><nowiki>http://decor.nictiz.nl/fhir/ValueSet/[value set OID]--[effective date as yyyymmddhhmmss]</nowiki>

Where:
* <nowiki>[</nowiki>domain<nowiki>]</nowiki> is "nictiz.nl"
* <nowiki>[</nowiki>project<nowiki>]</nowiki> is preferably the same as its matching [http://decor.nictiz.nl/art-decor/ ART-DECOR] project prefix

This convention aligns with international initiatives such as DAF and QiCore and has been confirmed/advised by Grahame Grieve.

==Versioning intro==

The HL7® FHIR® specification specifies a lot of things related to versions. This text aims to stay aligned with the latest insights. Readers should first get acquainted with the core FHIR specification before reading here: http://hl7.org/fhir/versions.html

===Versions of the profiles===

Versions of the profiles may occur for any of the following reasons:

*New releases of the underlying HCIMs are normally followed by an update to the representing profiles
*Identified issues in existing profiles may require an update
*HL7® FHIR® updates may lead to an update of the profiles. We do ''not'' automatically follow every FHIR version as it is released

Version updates first and foremost affects the <code>version</code> element found in all conformance resources (profiles, value sets, extensions, search parameter, operation definition etc.). The update normally does not affect the canonical URI of the conformance resource. Conformance resources create a web of interrelated artifacts. Any resource that references another resource, e.g. Patient referencing Practitioner for the general practitioner, normally does so without a version indicator (uri|version). This means that any reference points dynamically to 'the latest version' of the artifact. If you were to build a consistent set of versions you would need to add the version to any reference in the set of conformance resources and update the full set after any updating any particular part.

Around the advent of FHIR R4, the follow up of STU3, there will be a new versioning layer that allows packaging of profiles into a consistent set without affecting the profiles itself. The packaging mechanism will be tested in May 2018, and should greatly simplify specification and implementation of versions.

[[Bestand:Profiles-versioned-or-packaged.png|800px|Profiles with versioned references vs Packaged versions of profiles]]

===Versions in instances===

To understand how instances of resources are interpreted by a receiving server we should look at two things:

*The indicator for the profile that the sender added to the instance (if any). This indicator would be in the <code>Resource.meta.profile</code> element and may include a version, e.g.<br/><nowiki><profile value="http://fhir.nl/fhir/StructureDefinition/nl-core-patient"/></nowiki>
*The profile (versions) that the server defaults to in the absence of a profile indicator in the instance

If the server does not support the profile (version) as indicated in the instance it may do any of the following things. See also the [http://hl7.org/fhir/versions.html#f-compat relevant section] in the FHIR specification.

#Try to support the instance based on what it can support. This may lead to ignoring any element it doesn't know, except for modifierElements. If modifier elements are encountered, the instance should be rejected
#Reject the instance

Note: as specified in the core FHIR specification, the server SHALL use its CapabilityStatement to indicate its behavior around unsupported elements (ignore or reject)

==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 and Care Information Models or in Dutch ''Zorginformatiebouwstenen'' or zibs. Profiles SHALL have a traceable relationship with their functional counterpart(s).

The FHIR specification contains several solutions for this problem, [http://hl7.org/fhir/conceptmap.html ConceptMap] (>=STU1), [http://hl7-fhir.github.io/structuredefinition.html StructureMap] (>=STU3), [http://hl7.org/fhir/elementdefinition-definitions.html 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 without updating their resource.

===Current implementation===

We use the mapping elements in profiles to map functional elements to resource elements. When slicing, the mapping is made on the ''content'' of the slice, not the slice itself (see also [[#Placing-Info]]).

Functional elements are referenced based on their mnemonic id in the HCIM, e.g. NL-CM:9.6.19936. The mapping shall resolve to the English page on zibs.nl:

    <mapping>
        <identity value="hcim-medicationagreement-v1.0-2017EN" />
        <uri value="https://zibs.nl/wiki/MedicationAgreement-v1.0(2017EN)" />
        <name value="HCIM MedicationAgreement-v1.0(2017EN)" />
    </mapping>

....

    <element id="MedicationRequest.extension:usageDuration">
        <path value="MedicationRequest.extension" />
        <mapping>
            <identity value="hcim-medicationagreement-v1.0-2017EN" />
            <map value="NL-CM:9.6.19936" />
        </mapping>
    </element>

===Proposed way forward===

# The functional definitions ''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 [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=9843 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>
#* Example: <element id="2.16.840.1.113883.3.1937.99.62.3.2.3--20110128000000">
# In profiles we reference from third parties that do not have this Element/@id populated we need a less precise method. We will deal with that when we need to.

==Practical guidelines==

===File names===
* For profiles: ''<<the final part of the canonical URI>>''.xml
* For valuesets: ''<<Valueset.name>>''-''<<Valueset.id>>''.xml

===Profile meta data===
* URL: see above
* Resource ID: final part of the canonical URI
* Name: final part of the canonical URI (without hyphens, capitalized)
* Description:
** A(n) ''<<enter resource type>>'' resource as defined by the Dutch Health and Care Information models (Dutch: Zorginformatiebouwsteen or ZIB) ''<<Zorginformatiebouwsteen name>>'' ''<<version>>'' ''<<release>>''
** Followed by the 'Concept' section from the HCIM 
* Version: ''as applicable to the profile, not the HCIM it refers to''
* Date: n/a
* Lifecycle status: ''as applicable'' (normally draft or active)
* Experimental: normally '''false''' or null
* Title: final part of the canonical URI (without hyphens, with 'zib' replaced by 'HCIM')
* Purpose:
** 'Purpose' section from HCIM
** If needed: a discussion of where this profile fits in the workflow and why this resource was chosen (separated using a header in Markdown)
* Copyright: CC0
* Publisher: ''Nictiz''
* Contact information: n/a
* Use context: n/a
* Keywords: n/a
* Mappings: ''uri to the version of the HCIM specification'' (see [[#Associating_functional_definition_to_StructureDefinition]])<br/>&lt;mapping><br/>&#160;&#160;&#160;&#160;&lt;identity value="hcim-contactperson-v3.1-2017EN"/><br/>&#160;&#160;&#160;&#160;&lt;uri value="https://zibs.nl/wiki/ContactPerson-v3.1(2017EN)"/><br/>&#160;&#160;&#160;&#160;&lt;name value="HCIM ContactPerson-v3.1(2017EN)"/><br/>&lt;/mapping>
* Identifiers: n/a
* Meta data: ''tbd''
* Implicit rules (URI): n/a
* Language: n/a (most content is en-US from the core, some is nl-NL from the HCIMs)
* Kind: n/a (auto handled by Forge)
* Type: n/a (auto handled by Forge based on selection at creation time)
* Abstract: '''false'''
* Base definition: n/a (auto handled by Forge based on selection at creation time)
* FHIR version: n/a (auto handled by Forge based on selection at creation time) - initially 3.0.1 STU3

===Mapping DefinitionCodes===

Sometimes a FHIR element is equivalent to the HCIM concept (like a comment and a ''Resource.comment'' element), but if not, a code (usually SNOMED or LOINC) needs to be added to the FHIR profile to provide the proper definition. This is for example the case in Observation, where the root concept of the observation is unknown unless it is defined by the ''.code'' element, and where every ''.component'' needs to be defined by an individual ''.code'' element. Usually, the concepts for these elements are provided by the HCIMs (as DefinitionCode).

We map these DefinitionCodes from the HCIM onto the profile in an extendable way. If possible, we use a required slice for the DefinitionCode. In practice this will look like:
{| class="wikitable"
|-
! COLSPAN="4"| FHIR path                                !! Remark !! Cardinality
|-
| .code ||         ||                       ||          || || 1..1
|-
|       || .coding ||                       ||          || sliced on ''value/code'' || 1..*
|-
|       ||         || ''slice for concept'' ||          || named after the concept name || 1..1
|-
|       ||         ||                       || .system  || code system from HCIM as ''fixedValue'' || 1..1
|-
|       ||         ||                       || .code    || code from HCIM as ''fixedValue'' || 1..1
|-
|       ||         ||                       || .display || display value defined in the code system as ''defaultValue'' || 0..1
|}

====Don't use nested slicing====
In some cases, slicing in this way would mean to add slices within slices (e.a. Observation.component). This doesn't work too well in FHIR - for example, neither the Java nor the .Net validator can't handle this (at the moment) - so we don't use this mechanism. As an alternative we can use a slicing disciminator based on pattern/code, and on each slice.code we can add a ''patternCodeableConcept'' with the required system and value. This has the same effect; at least that coding is required, but others may be added.

===Binding HCIM defined ValueSets===
* the ValueSet can be obtained in FHIR 3.0 format from ART-DECOR (see [[#File_names]] for file naming conventions)
* the reference URL can be obtained from the ''<<ValueSet.url>>'' element in this file
* we use binding strength "''[http://build.fhir.org/valueset-binding-strength.html extensible]''".
* the ''<<binding.description>>'' value is set to ''<<ValueSet.name>>''

===Binding of HCIM BasicElements to profiles===
The [https://zibs.nl/wiki/BasicElements-v1.0(2017EN) BasicElements] were made explicit in HCIM Release 2017 and have been declared applicable to [https://zibs.nl/wiki/BasicElements-v1.0(2015EN) 2015] and [https://zibs.nl/wiki/BasicElements-v1.0(2016EN) 2016] in the zibs.nl wiki. 

Initially the profiles did not dedicate much attention to the BsasicElements as there was no clarity around how to interpret them. That clarity has [https://zibs.nl/wiki/BasicElements-v1.0(2017EN)#Concept since been added] but there is still room for interpretation:

{{NoteBox|All HCIM's implicitly contain a number of basic elements. These are usually not included in the information models of the individual building blocks, but are supposed to be present.
These are concepts that are of a more technical nature, often have little or no clinical relevance, but are necessary for the sake of clarity and readability of the information. In those cases where these elements are of clinical significance, they will usually be explicit in the information models. An example of this is an AGB number as an identification number for a health professional.}}

For some elements it's clear, e.g. the IdentificationNumber will always go to .identifier, and for other elements it is not, e.g. InformationSource. What would be the InformationSource for the resource Patient? When would a ContactPerson be a Subject in the current profiles, instance had of a Patient?)

The table outlines which mappings are clear and which are yet to be determined. As of the Spring release 2019 of MedMij, all BasicElement mappings have applied for as far as possible:

{| class="wikitable"
!BasicElement!![http://hl7.org/fhir/STU3/w5.html Profiel element]!!Remark
|-
|NL-CM:0.0.1 HCIMRoot||-||not possible
|-
|NL-CM:0.0.6 IdentificationNumber ||.identifier||Overlaps sometimes with existing mapping such as HealthProfessionalIdentificationNumber or PatientIdentificationNumber. Unclear what to do with sub parts of an HCIM such as LabroatoryTest and Specimen. Presumably best to map to Observation.identifier and Specimen.identifier
|-
|NL-CM:0.0.2 InformationSource||.asserter||Mapped only when clinically relevant, e.g. AllergyIntolerance.asserter, Condition.asserter. What HCIM is this really applicable to?
|-
|NL-CM:0.0.3 PatientAsInformationSource::Patient||Patient||
|-
|NL-CM:0.0.4 HealthProfessional||Practitioner <nowiki>|</nowiki> PractitionerRole||
|-
|NL-CM:0.0.5 RelatedPersonAsInformationSource::ContactPerson||RelatedPerson|| 
|-
|NL-CM:0.0.7 Author||.author <nowiki>|</nowiki> .performer||FHIR resources do not all have RelatedPerson in its choice list, or even Patient. Example is [http://hl7.org/fhir/STU3/diagnosticreport.html DiagnosticReport]. Is it clinically relevant and/or reasonable to assume a Patient and/or RelatedPerson as possible author?|
|-
|NL-CM:0.0.8 PatientAsAuthor::Patient||Patient||
|-
|NL-CM:0.0.9 HealthProfessionalAsAuthor::HealthProfessional||Practitioner <nowiki>|</nowiki> PractitionerRole||
|-
|NL-CM:0.0.10 RelatedPersonAsAuthor::ContactPerson||RelatedPerson||
|-
|NL-CM:0.0.11 Subject||.subject <nowiki>|</nowiki> .patient||A RelatedPerson is never a Subject of care except possibly for a family anamnesis. Is it clinically relevant and/or reasonable to assume RelatedPerson as possible subject regardless?
|-
|NL-CM:0.0.12 Patient||Patient||
|-
|NL-CM:0.0.13 RelatedPersonAsSubject::ContactPerson||RelatedPerson ||
|-
|NL-CM:0.0.14 DateTime||.effective <nowiki>|</nowiki> .onset||Is this clinically relevant time to be assumed only on clinical HCIMs? So not on e.g. Patient, Practitioner, Organization?
|}

===Miscellaneous===
* We only profile elements, cardinalities and bindings that require profiling. We leave other elements, cardinalities and bindings as-is (see [[#Open_vs._Closed_Modeling]])
* For elements that map to Health and Care Information Models (HCIM):
** We copy the name from the HCIM element into the profile element.short (in elements that refer to other zibs, the name is built up like ''<<ElementName::ReferenceZibName>>'', but we only use the part before the double colons)
** The HCIM concept description is placed in the profile element.definition
** The HCIM Dutch concept name is placed in the profile element.alias
** {{anchor|Placing-Info}}''Note: as a rule of thumb, we place this info 'as close as possible' to the elements that actually represent the data. For example: when slicing, the texts are placed on the slice content, not the slice itself. Similarly, in concept containers like Observation.component, this info is placed on the .valueXXX elements. This is also true for [[#Associating_functional_definition_to_StructureDefinition | the HCIM mappings]].''
* Slices get an UpperCamelCased name based on the HCIM element name.
* New elements defined through extensions get a lowerCamelCased name based on the HCIM element name.
* When adding invariants we use "hcim-[hcim-name]-[number]"  as a key. Example: hcim-alert-1
* [https://docs.google.com/document/d/1ClF3XpIrE2FiIDG7K7VD3pPjOPx3T950Sfi1Ip8ORcU/edit#heading=h.641auhfi9fvs FHIR URI Strategy] (draft document with potentially good info)
* For FHIR base resource elements with datatype ''code'' and binding ''required'' it may be that the HCIM has other/additional codes to specialize the FHIR codes. To conform to FHIR and the HCIM we will use the FHIR required element and binding and specify the mapping. We will use 1 extension to cover this use case.
** Extension URI [http://nictiz.nl/fhir/StructureDefinition/code-specification http://nictiz.nl/fhir/StructureDefinition/code-specification]
** The extension is of datatype CodeableConcept which also support text as a fallback
** The extension receives its ValueSet binding in the context of the profile element and does not have a binding internally
** The extension is only required to be present when the extension actually holds a specialization, e.g. CRITH + fatal. It is optional when the mapping is ''equal''
** The mapping shall be documented in a ConceptMap
** Example AllergyIntolerance.criticality

{| class="wikitable"
! FHIR !! HCIM
|-
| CRITL || low
|-
| CRITL || medium
|-
| CRITH || high
|-
| CRITH || fatal
|-
| CRITU || -
|-
|}

==Open vs. Closed Modeling==

{| class="wikitable"
|-
! ×
! Open
! Closed
|-
! Pros
| - Forward compatibility

- Modelers don't have to think about what you shouldn't support, only what must be supported  

- Implementers can fit more data, even if it's not in specified explicitly bu the profile
|| - Implementers, don't have to support all elements that maybe, someday could be used, according to the model
- Model becomes more specific

- Model becomes smaller and more straightforward

- More implementer feedback, about elements they want to support, but currently can't

|-
! Cons
| 
- Implementers, have to support all optional elements that maybe, someday could be used, according to the model
- Model becomes more vague, 

- Model becomes larger and less straightforward about what should actually be supported, and what can optionally be supported

- Less implementer feedback: elements they want to send can be easier 'hacked' in a not yet explicitly specified element. Model won't be improved.

 || 

- More versions of models, after more elements have to be supported

- No forward compatibility, only backwards

- Implementers have to wait for a new version of the model, if they want to support elements, that are currently not in scope.
|}

We have chosen for "open" modeling for the HCIMs, since they are very general and not meant for one specific use case. Excluding unspecified elements here is not an option, since we expect derived profiles for more specific use cases that may need those elements.

==Cardinality/conformance mapping table==

Cardinality applies to the number of occurrences that an element MAY/SHOULD/SHALL have. Minimum cardinality is integer 0. Maximum cardinality is "n" or "*" (exact character depends on tooling). If the minimum cardinality is higher than 0, then an element has to be present. 

Conformance applies to what a system MAY/SHOULD/SHALL support. When data for an element is missing, e.g. because it is not applicable, then the element may be absent, but when conformance MustSupport is active, then a conformant application SHALL support it. Contrary to V3, there is no concept of NullFlavor in FHIR, so whenever an element is 1..1 in FHIR, there is no escape through NullFlavor: a value SHALL be present. 

Reference: [http://hl7.org/fhir/elementdefinition-definitions.html#ElementDefinition.mustSupport ElementDefinition.mustSupport]

This poses a need for a mapping table from cardinality/conformance in HCIMs versus that in profiles.

{| class="wikitable"
|-
! ART-DECOR / HCIM
! FHIR
|-
| 0..1 || 0..1
|-
| 0..1 C || 0..1
|-
| 0..1 R || 0..1 mustSupport='true'
|-
| 0..* || 0..*
|-
| 0..* C || 0..*
|-
| 0..* R || 0..* mustSupport='true'
|-
| 1..1 || <span style="color: red;">'''0'''</span>..1
|-
| 1..1 C || <span style="color: red;">'''0'''</span>..1
|-
| 1..1 R || <span style="color: red;">'''0'''</span>..1 mustSupport='true'
|-
| 1..1 M || 1..1 mustSupport='true'
|-
| 1..* || <span style="color: red;">'''0'''</span>..*
|-
| 1..* C || <span style="color: red;">'''0'''</span>..*
|-
| 1..* R || <span style="color: red;">'''0'''</span>..* mustSupport='true'
|-
| 1..* M || 1..* mustSupport='true'
|}

==Constraining references==
HCIMs might have have connections to other HCIMs. Example: a MedicationAgreement might have a [https://decor.nictiz.nl/art-decor/decor-datasets--mp-?id=2.16.840.1.113883.2.4.3.11.60.20.77.1.3&effectiveDate=2016-06-01T00%3A00%3A00&conceptId=2.16.840.1.113883.2.4.3.11.60.20.77.2.3.19835&conceptEffectiveDate=2015-11-24T08%3A40%3A47&language=nl-NL Prescriber] relationship defined using a HealthProfessional which is mapped to a FHIR MedicationRequest.requester as Reference(Practitioner). The [http://hl7.org/fhir/STU3/medicationrequest.html FHIR MedicationRequest] however, defines more types: Reference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device). The closed world model would mandate that the profile only marks Practitioner for use. The open world model would mandate that the profile describes that for a HealthProfessional you need the Practitioner without omitting the other choices.

For general purpose profiles, suitable for further constraining we use open world profiling meaning that we do not constrain the choices of references into just the types that the HCIM requires. We only constrain the generic resource reference to the generic profile(s) for that resource. For Practitioner this would be the nl-core-practitioner. If deemed relevant a second layer of derived profile(s) could be created to tailor the generic profile for a specific use case using closed world modeling.

==Data type mapping table==

DECOR defines a set of data types. In most cases, the mapping to FHIR is straightforward, though there are a number of cases which are not as clear-cut. When defining extensions, or specifying the datatype of an Observation or Questionnaire.item in FHIR, a mapping to the relevant FHIR datatype needs to be done. The table below shows a mapping for datatypes in HCIMs versus those in profiles.

{| class="wikitable"
|-
! HCIM
! ART-DECOR
! FHIR 
! Remarks
|-
| INT || count || [https://www.hl7.org/fhir/STU3/datatypes.html#Count Count] or integer || Count in FHIR is derived from Quantity, this is appropriate for observations, such a a count of red blood cells in a specimen. Count in FHIR is a Quantity with system="http://unitsofmeasure.org" and code="1" (for units). If this is not appropriate, use integer.
|-
| BL || boolean || boolean || 
|-
| ED || blob || base64Binary || 
|-
| CD || code || CodeableConcept or coding or code || In general, CodeableConcept will be the right choice. See [http://hl7.org/fhir/terminologies.html Using Codes in Resources] for details. 
|-
| ANY || complex || BackboneElement || 'complex' is data which is not further defined in DECOR, and thus cannot be translated. 
|- 
| - || currency || Money || Does not have a HCIM counterpart currenty. Theoretically this could be MO
|- 
| - || date || date || Does not have a HCIM counterpart currently. Closest counterpart could be TS
|- 
| TS || datetime || dateTime || 
|-
| - || decimal || decimal || Does not have a HCIM counterpart currently. Theoeratically this could be REAL
|- 
| - || duration || Duration || Does not have a HCIM counterpart currently. Closest counterpart could be PQ
|-
| II || identifier || Identifier || 
|-
| CO || ordinal || CodeableConcept or coding or code || See [http://hl7.org/fhir/terminologies.html Using Codes in Resources] for details.
|-
| ST || string || string || 
|-
| - || ratio || Ratio || Does not have a HCIM counterpart currently. Closest counterpart could be RTO
|-
| - || text || string || Does not have a HCIM counterpart currently.
|-
| PQ || quantity || Quantity || 
|}

==Translating DECOR to FHIR==
Status: proposal

Quite often we will populate FHIR artifacts from DECOR artifacts. In such cases, FHIR identification must be derived from DECOR identification. 

DECOR uses the attributes id and effectiveDate to identify concepts, datasets, transactions, valueSets and templates. The artifacts with the same id but different effectiveDates are subsequent versions of the same artifact (though artifacts can also get a new id for a new version, such as when a new dataset is derived from an older one). 

In FHIR, every resource can have an id, which is the "logical id" of the resource. This id never changes once assigned, like DECOR id and effectiveDate. Resources usually have an URL too, which also identifies the resource, but should be resolvable. The URL can contain the id.

The following ART-DECOR artifacts map to FHIR artifacts:

{| class="wikitable"
|-
! DECOR artifact !! FHIR artifact || FHIR identifier system || Notes
|-
| concept || DataElement || http://art-decor.org/ns/oids/de || DataElement is a wrapper around a FHIR element (based on ElementDefinition). A FHIR element is not serializable independently, but is wrapped in a StructureDefinition or DataElement.
|-
| dataset<br/>transaction || Logical Model || http://art-decor.org/ns/oids/sd || A Logical Model is a StructureDefinition without base resource. FHIR uses this to capture user requirements.
|-
| valueSet || ValueSet || http://art-decor.org/ns/oids/vs ||
|}

The following FHIR attributes are constructed in the following way, when generated from ART-DECOR. Non-digits are stripped from the timestamp in @effectiveDate because they violate the FHIR rules for id.

{| class="wikitable"
|-
! FHIR artifact !! derivation from DECOR
|-
| FHIR id || @id + '--' + @effectiveDate
|-
| FHIR identifier system || See above
|-
| FHIR identifier value ||  @id
|-
| FHIR version || @effectiveDate
|-
| FHIR status || See below
|}

Status is translated from DECOR to FHIR:

{| class="wikitable"
|-
! DECOR status !! FHIR status
|-
| new || draft
|-
| draft || draft
|-
| pending || draft
|-
| active || active
|-
| review || draft
|-
| cancelled || retired
|-
| rejected || retired
|-
| deprecated || retired
|+ default is 'draft'
|}


[[Category:FHIR]]