3.7.0

[tmsMedcom]

See issue #214 for a description of the review.

[tmsMedcom]

Overordnet synes jeg, at dokumentationen er god og fyldestgørende. Jeg har sammenholdt profileringen med HL7 EU's og kommenteret de steder vi bør vende. Balancen mellem DK og EU behov er fin.
QA-report: https://build.fhir.org/ig/hl7dk/dk-core/branches/3.7.0/qa.html#_scratch_repo_fsh-generated_resources_ValueSet-dk-core-NPUBasicObservation

[jkiddo]

Review: branch 3.7.0 vs. HL7 Europe DiagnosticReport-eu-lab

The branch adds DkCoreDiagnosticReport (profile + 2 examples), a KliniskBiokemiHBY Organization example, and a cvr NamingSystem. The profile draws intentionally on the HL7 Europe lab profile (see intro.md
and valueSet descriptions). The two profiles are siblings — both derive from base DiagnosticReport — so "conflict" here means places where a DK‑valid instance would fail EU‑lab validation, or where
semantics drift.

Aligned — no conflict

• code 1..1, subject 1..1, subject reference types, status required binding (inherited).
• performer/resultsInterpreter/encounter/result use DK sub‑profiles of the types EU allows (DkCorePractitioner IS‑A Practitioner, etc.), so they remain assignment‑compatible.
• category open slicing with studyType + specialty mirrors EU; adding a third slice (danishSpecialty) is permitted by EU's open slicing.

Real conflicts / gaps (flag if dual EU conformance is intended)

1. basedOn reference types — DkCoreDiagnosticReport.fsh:28. DK allows CarePlan | ImmunizationRecommendation | MedicationRequest | NutritionOrder | DkCorePersonServiceRequest. EU allows only
   Reference(ServiceRequest). A DK instance with basedOn=CarePlan will not validate against EU‑lab.
2. Missing DiagnosticReportCompositionR5 extension. EU requires this extension at 1..1 (MS). DK does not mention it, so DK‑valid instances have no extension and will fail EU validation. Not a conflict for
   purely DK use, but a gap for any lab report expected to travel cross‑border.
3. imagingStudy prohibited in EU (0..0), unconstrained in DK. DK inherits 0..*. Instances populating this element will fail EU validation.
4. category[studyType] / category[specialty] bindings — DkCoreDiagnosticReport.fsh:15-18. DK binds to local valuesets (LoincLabStudyTypes, dk-core-SCTLaboratorySpecialities). Intent is alignment
   ("consistent with European use in EHDS", "the set of accepted specialities in Europe"). Both bindings are required on each side, so unless every code in the DK valuesets is a member of the corresponding
   EU valuesets, an instance cannot satisfy both at once. Worth confirming 1:1 code overlap against the current EU lab value sets (the EU specialty set has historically included codes like 708184003,
   18727-8‑family LOINC codes, etc.).
5. Slicing discriminator differs. DK uses discriminator.type = #value, path = "$this"; EU uses pattern. Both are open, so the extra DK slice is fine, but tooling may resolve slices differently — worth
   verifying in the build.

Scope drift (intentional, but document it)

• code binding is extensible to dk-core-LoincDiagnosticDocumentTypes which includes non‑lab codes (11506-3 Progress note, 53576-5 Personal health monitoring report). EU's binding is only preferred, so
  this is not an EU validation error, but the two profiles cover different scopes. The intro text already calls this out.
• ElseHomeNursingMeasurements example (non‑lab progress note) is out of scope for EU‑lab. Fine for DK.

Minor things spotted in the diff (not EU‑related)

• input/pagecontent/StructureDefinition-dk-core-diagnostic-report-intro.md:45 — typo: "cades" → "codes".
• input/fsh/DkCoreOrganization.fsh:168-170 — KliniskBiokemiHBY carries a SOR identifier (275871000016006, system urn:oid:1.2.208.176.1.1) but no name, no CVR/KOMBIT identifier. Worth checking it satisfies
  the dk-core-organization-mandatory-identifier invariant (SOR qualifies, so likely fine) — but a name would improve the example.
• input/fsh/instances.fsh:58 — cvr NamingSystem sets uniqueId.value = "urn:oid:1.3.184" on a uniqueId whose type = #oid; the convention is to store the bare OID (1.3.184) for type=#oid and the urn form
  only for type=#uri. Check whether the IG Publisher flags this.

Recommendation

If dual EU‑lab conformance is a goal for Danish laboratory reports, consider either (a) a derived profile DkCoreLaboratoryReport that layers EU constraints (Composition extension, basedOn to
ServiceRequest, imagingStudy 0..0, EU study/specialty value sets) on top of the general DkCoreDiagnosticReport, or (b) explicit guidance in the intro stating DK‑core is deliberately broader than EU‑lab
and listing the extra steps needed for EU conformance. Option (a) keeps both profiles validating simultaneously, which is what "no conflict" really means in FHIR.

[jkiddo]

AI suggest to either add a derived DkCoreLaboratoryReport profile for dual EU conformance or document the scope gap in the intro.

[tmsMedcom]

1. Skriftlig opsamling på at hvis basedOn indeholder andet en CarePlan, vil den ikke validere i EU-LAB
2. vi har fulgt op at DiagnosticReportCompositionR5 ikke er en del af Xt-EHR tabeller i sin nyeste version.
3. tilføjes sammen med pkt. 1.
4. dette er beskrevet, der gøres ikke yderligere
5. Det bør ikke have indflydelse på validering.

Typo tilrettes

Det er et bevidst valg, at DkCoreDiagnosticReport har et bredere scope en EU-lab DiagnosticReport.

@Kirstinerosenbeck implementerer ændringerne

[tmsMedcom]

@shejgaardkri vil du godkende dette PR?

[tmsMedcom]

@Kirstinerosenbeck og @jkiddo kan denne udgives?

[jkiddo]

Jeg kigger på det