3.6.0

[jkiddo]

This pull request primarily standardizes the way code systems and display texts are represented in example data, improves code system references, updates practitioner qualification periods, and introduces a sample organization instance. Additionally, it removes an unused extension definition. The most important changes are grouped below:

Standardization of Code System and Display Texts in Examples:

• Removed display texts from SNOMED, LOINC, and other code system references in example instances across multiple files (e.g., DkCoreBasicParameter.fsh, DkCoreCondition.fsh, DkCoreMinimalDocumentReference.fsh, DkCoreObservation.fsh, DkCoreServiceRequest.fsh), ensuring only codes are used for clarity and consistency. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19]

Improvements to Code System References:

• Updated regional subdivision code references from the Danish code system to the ISO 3166-2 standard in both patient and organization examples, and updated the identifier system for regional codes accordingly. [1] [2]
• Corrected NPU code system references in blood pressure examples to use the correct code system and code format.

Practitioner Qualification Enhancements:

• Added qualification period start and end dates to practitioner examples, and included missing identifier and code information for practitioners, improving the completeness of qualification data. [1] [2] [3]

Organization Example and Invariant Update:

• Added a new example instance for a Danish organization with a CVR identifier, and updated the invariant expression to accept CVR as a valid identifier system.

Other Notable Changes:

• Removed the unused DkCoreDocumentReferenceVersionIDExtension extension definition to clean up the codebase.
• Updated the SNOMED CT version in practitioner role specialty references to a future version for consistency. [1] [2]

[Kirstinerosenbeck]

I do not agree with the changes made in "Standardization of Code System and Display Texts in Examples". They have also not been a topic of discussion in the FHIR SIG. Consistent display texts improve human readability, clarity and helps validate that coded concepts remain understandable across systems. FHIR's own examples consistently pair codes with displays to support reliable interpretation and safer data exchange.
Note that the display should not be present in profiles (which we have implemented consistently). This design choice have the effect that all displays accepted in the code system, is also accepted at instance level.

[Kirstinerosenbeck]

The updated SNOMED CT version in practitioner role is correct, but I do not understand the reasoning behind it.

[Kirstinerosenbeck]

@jkiddo I cannot find the place where I am supposed to do a formal review. However, with the three comments left here I have concluded it. I looked up ISO 3166-2, but I could not find enough hierarchical information to suggest an rule-based ValueSet. I suggest we keep it the way it is suggested here.

[jkiddo]

I do not agree with the changes made in "Standardization of Code System and Display Texts in Examples". They have also not been a topic of discussion in the FHIR SIG. Consistent display texts improve human readability, clarity and helps validate that coded concepts remain understandable across systems. FHIR's own examples consistently pair codes with displays to support reliable interpretation and safer data exchange. Note that the display should not be present in profiles (which we have implemented consistently). This design choice have the effect that all displays accepted in the code system, is also accepted at instance level.

Display text are context dependent and should be resolved by the respective terminology server. Keeping them there makes it potentially ambigous, context dependent and leaves the impression that those text will be part of the on-the-wire format, which in most cases, they will not.

[jkiddo]

@jkiddo I cannot find the place where I am supposed to do a formal review. However, with the three comments left here I have concluded it. I looked up ISO 3166-2, but I could not find enough hierarchical information to suggest an rule-based ValueSet. I suggest we keep it the way it is suggested here.

The entire PR is for review

[jonigkeit]

@Kirstinerosenbeck regarding you comment

I looked up ISO 3166-2, but I could not find enough hierarchical information to suggest an rule-based ValueSet. I suggest we keep it the way it is suggested here.

I'd like to clarify a few points regarding the hierarchical structure: ISO 3166-2 is the standard for country subdivisions and represents the first administrative division level after ISO 3166-1 (country codes). The hierarchical information in ISO 3166-2 is well-defined and structured, there is a subdivision per ISO 3166-1 element. I cannot understand why there is a need for rule-based ValueSet for danish regional codes, when there is an official codesystem ISO 3166-2 DK (urn:iso:std:iso:3166#DK) that contains exactly all danish regional codes and nothing more.

Additionally, there's a practical benefit to adopting the ISO 3166-2 replacement: the updated standard addresses a known issue in the previous custom CodeSystem http://hl7.dk/fhir/core/CodeSystem/dk-core-regional-subdivision-codes, which retained the "Region" prefix in the English designations. The Danish Government specifically requested the prefix be removed. This correction was documented in the ISO 3166-2 newsletter (reference: https://www.iso.org/files/live/sites/isoorg/files/archive/pdf/en/iso_3166-2_newsletter_ii-3_2011-12-13.pdf), making the new version more accurate for Danish use cases.

Given these considerations, I believe the approach suggested here aligns well with both international standards and local regulatory requirements.

[jacand]

@Kirstinerosenbeck

Consistent display texts improve human readability, clarity and helps validate that coded concepts remain understandable across systems. FHIR's own examples consistently pair codes with displays to support reliable interpretation and safer data exchange.

It is my understanding that these changes will have no visible effect on the IG presented to readers, since the IG Publisher will pull the display strings from the terminology server instead when we do not fill in the display value.

[jacand]

Looks good overall. I left one comment about an OID which we may have to check up on...

[jacand]

I am curious about the 2.16.840.1.113883.2.24.1.1 OID. I did not know that we had defined any OIDs in HL7-DK (The prefix 2.16.840.1.113883.2.24 is HL7-DK). Where are they maintained/listed? I assume that it has been put here as a placeholder for CVR (?) so shouldn't we remove it now?

[jkiddo]

We can remove it ... or replace it with 1.3.198 -> https://oid-base.com/cgi-bin/display?oid=1.3.198&a=display

[jacand]

Assuming 2.16.840.1.113883.2.24.1.1 really means "CVR", I would vote for removing it (replacing it with the URL) - alternatively deprecating the OID now and removing it in the next version if some systems are already using it..