Aiidera FHIR-definitioner
0.1.0 - ci-build

Aiidera FHIR-definitioner - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Home

Official URL: https://fhir.aiidera.se/ImplementationGuide/aiidera.fhir Version: 0.1.0
Draft as of 2026-08-09 Computable Name: AiideraFHIR

Aiideras FHIR-definitioner

Den här Implementation Guiden publicerar Aiideras egna conformance-resurser under den permanenta namnrymden https://fhir.aiidera.se/.

Namnrymden är artefakternas identitet, inte en adress till en tjänst. Den publika resolveringen får implementeras hur som helst bakom adressen — statisk hosting, container, reverse proxy — men en canonical får aldrig bero på deploymentväg eller aktuell hostingstruktur. Ingen FHIR-server behövs för att lösa upp dem.

En canonical som publicerats här ändras aldrig och återanvänds aldrig för en semantiskt annan artefakt. En publicerad version skrivs aldrig över; nya versioner läggs till. Åtagandet är långlivat, eftersom en canonical kan stå i en signerad journalhandling som ska gå att läsa i decennier.

Vad som finns här

Den signerade journalhandlingens permanenta kärna, och dokumentet den bär:

  • AiideraJournalDocument — den kliniska journalhandlingen som document-Bundle. Det som serialiseras, signeras och lagras.
  • AiideraJournalComposition — handlingens innehållsförteckning, härledd ur composition-eu-core.
  • AiideraSigneradHandlingBinary — originalet, de exakta bytes som signerades.
  • AiideraSigneradHandlingDocumentReference — katalogposten som pekar ut originalet. Inte signerad.
  • AiideraSigneradHandlingProvenance — signeringen. Target är originalet och ingenting annat.
  • artifact-digest — Aiideras algoritmexplicita digest över originalpayloaden. Inte en standardextension.

Vad som medvetet inte finns här

Profiler för resurser där ingen Aiidera-specifik regel är beslutad. Ett namn i profilregistret är inte i sig skäl att publicera en StructureDefinition — en profil skapas först när minst en beslutad constraint, bindning, invariant eller interoperabilitetsregel behöver uttryckas ovanpå vald basprofil.

Skälet är att varje publicerad canonical är ett förvaltningsåtagande i decennier, och att en tom profil som senare fylls är antingen en ny canonical eller ett brutet åtagande.