Kvalitetssystem
Kvalitetssystemintegrasjoner kobler pasientrelaterte avvik i Aidn med kommunens etablerte avviksprosess. Når et pasientavvik signeres i Aidn, sender Aidn en strukturert og dataminimert JSON-melding til kvalitetssystemet. Kvalitetssystemet behandler saken videre og sender én eller flere statusoppdateringer tilbake til Aidn.
Dette bruksområdet er inspirert av FHIR-konsepter, men integrasjons-API-et bruker et eget JSON-format. API-beskrivelsen ligger derfor her, ikke i FHIR API-referansen.
Scenario
Kommunen bruker Aidn som elektronisk pasientjournal og et separat kvalitetssystem for avviksbehandling. Ansatte registrerer pasientrelaterte avvik i Aidn. Når avviket signeres, overfører Aidn det umiddelbart til kvalitetssystemet slik at kommunen kan behandle saken videre i eksisterende QMS-arbeidsflyt.
Aidn lagrer koblingen til saken i kvalitetssystemet og viser siste status som kvalitetssystemet har sendt tilbake.
Påkrevd oppsett
| Konfigurasjon | Eier | Beskrivelse |
|---|---|---|
| OAuth-klient | Kommune eller Aidn-administrator | Klient konfigurert for QMS-leverandør og miljø. Se Kommuneoppsett. |
| Klientens privatnøkkel | Leverandør | Privatnøkkel som hører til den registrerte offentlige nøkkelen. Leverandøren kan generere nøkkelparet selv, eller administrasjonsportalen kan generere det under klientoppsettet. Lagres sikkert. |
| Scope | Kommune eller Aidn-administrator | Klienten trenger adverseevent.write for å sende statusoppdateringer til Aidn. |
| Avdelingsoversikt | Kommune | Kommunen må gi QMS-leverandøren en liste over avdelingsnavn og Aidn avdelings-ID-er for avdelingene som skal bruke QMS-integrasjonen. |
| Mottaksendepunkt i kvalitetssystemet | Leverandør | HTTPS-endepunkt hvor Aidn kan POST-e signerte avvik. Autentisering for kall fra Aidn til kvalitetssystemet avtales under oppstart. |
| Integrasjon aktivert for kommunen | Kommune eller Aidn-administrator | QMS-integrasjonen må aktiveres før forespørsler tillates for kommunen. |
Kommunen kan velge om integrasjonen skal være aktiv. Hvis kommunen krever det, kan trafikken også begrenses til Helsenettet.
Avdelingsoppsett
Før integrasjonen aktiveres må kommunen gi avdelingsoversikten til QMS-leverandøren. Oversikten må inneholde avdelingsnavn og Aidn avdelings-ID for hver avdeling som skal bruke QMS-integrasjonen, og leverandøren bruker den når QMS-oppsettet konfigureres.
QMS-leverandøren bruker avdelings-ID-ene og navnene til å rute, klassifisere eller vise avvik i tråd med kommunens avtalte oppsett.
Dataflyt
sequenceDiagram
participant User as Aidn-bruker
participant Aidn as Aidn
participant IdP as Aidn identity provider
participant QMS as QMS-leverandør
User->>QMS: Gi avdelingsnavn og Aidn avdelings-ID-er
QMS->>QMS: Konfigurer avdelinger for kommunen
User->>Aidn: Aktiver integrasjon for kommunen
User->>Aidn: Registrer og signer pasientavvik
Aidn->>QMS: POST avvik som JSON
QMS-->>Aidn: Teknisk kvittering
QMS->>QMS: Behandle sak i QMS-arbeidsflyt
QMS->>IdP: Be om access token med private_key_jwt
IdP-->>QMS: Access token med godkjente scopes
QMS->>Aidn: PUT statusoppdatering som JSON
Aidn-->>QMS: Teknisk kvittering
Aidn->>Aidn: Vis siste QMS-status i avviksbildet
Overføringen fra Aidn til kvalitetssystemet er synkron for teknisk kvittering, men funksjonelt asynkron. Saksbehandling skjer videre i kvalitetssystemet, og kvalitetssystemet sender statusoppdateringer når det er relevant.
Hvis Aidn ikke kan overføre avviket til kvalitetssystemet når brukeren signerer, blir avviket liggende i kladdemodus i Aidn. Brukeren kan signere avviket på nytt senere etter at integrasjonsfeilen er rettet.
Motta avvik fra Aidn
Aidn sender et signert avvik til kvalitetssystemets mottaksendepunkt som JSON.
POST <QMS_ADVERSE_EVENT_ENDPOINT> HTTP/1.1
Host: <QMS_HOST>
Accept: application/json
Content-Type: application/json
{
"identifier": "019c298c-366b-76a8-b73e-87306ae6550d",
"patientId": "9XFLLS",
"category": {
"code": "1",
"display": "Fall"
},
"severity": {
"code": "5",
"display": "Livstruende/invalidiserende"
},
"occurredDateTime": "2026-02-04T16:39:38.499132+00:00",
"detectedDateTime": "2026-02-04T16:39:38.499132+00:00",
"fields": [
{
"label": "Beskrivelse",
"identifier": 3486,
"value": "Description of adverse event",
"code": null
},
{
"label": "Utførte tiltak",
"identifier": 3492,
"value": "Measures taken",
"code": null
}
],
"reporter": {
"person": {
"name": "Example User",
"nationalId": "<NATIONAL_ID>",
"userPrincipalName": "example.user@example.org",
"actorId": "55598fe4-2826-4a0d-8881-db63ee27afd4"
},
"organization": {
"tenantMunicipalityNumber": "0000",
"tenantName": "Example municipality",
"organizationNumber": "874593842",
"organizationName": "Example nursing home",
"departmentId": "0ed0c8fd-1c82-4b3b-82bc-ae07c2cf38f5",
"departmentName": "Short-term ward"
}
}
}
Avvikspayload
| Egenskap | Type | Beskrivelse |
|---|---|---|
identifier |
string (UUID) | Aidn-identifikator for avviket. Brukes som koblingsnøkkel når status sendes tilbake til Aidn. |
patientId |
string | Anonymisert Aidn-identifikator for pasienten. Pasientens navn og fødselsnummer sendes ikke. |
category |
Coding | Type avvik. |
severity |
Coding | Alvorlighetsgrad. |
occurredDateTime |
string (ISO timestamp) | Dato og tidspunkt for hendelsen. |
detectedDateTime |
string (ISO timestamp) | Valgfritt. Dato og tidspunkt da hendelsen ble oppdaget eller erkjent. |
fields |
Field[] | Innhold fra avviksskjemaet. Minst ett element er inkludert. |
reporter |
Reporter | Teknisk informasjon om melder og organisatorisk kontekst. |
Delte typer
| Type | Egenskaper |
|---|---|
Coding |
code string, display string. |
Field |
label string, identifier number, value string, valgfri code string. |
Reporter |
person og organization. |
Person |
name, valgfri nationalId, valgfri userPrincipalName, actorId UUID. Avhengig av kommunens identitetsoppsett finnes minst nationalId eller userPrincipalName. |
Organization |
tenantMunicipalityNumber, tenantName, organizationNumber, organizationName, departmentId UUID, departmentName. |
Kategori og alvorlighetsgrad
Kategori og alvorlighetsgrad er kodet. Dagens avvikskategorier er:
| Kode | Visningstekst |
|---|---|
1 |
Fall |
2 |
Medisinavvik |
3 |
Ernæring |
4 |
Skade, vold eller trusler |
5 |
Svikt i utstyr |
6 |
Rutinesvikt |
7 |
Tjenesteavvik |
8 |
Personvern og informasjonssikkerhet |
9 |
Annet avvik |
Alvorlighetsgrad bruker kodene 1 til 6, fra ingen skade til død. Norsk display-tekst er ment for sluttbrukere og bør bevares når den vises i kvalitetssystemet.
Skjemafelter
Standardfelter inkluderer:
| Identifikator | Label | Beskrivelse |
|---|---|---|
3486 |
Beskriv avviket | Fritekstbeskrivelse av avviket. |
3492 |
Hvilke tiltak ble iverksatt på grunn av hendelsen | Fritekstbeskrivelse av tiltak som ble iverksatt etter hendelsen. |
3493 |
Forslag til fremtidige tiltak | Fritekstforslag til fremtidige tiltak. |
For kategori 1 (Fall) kan Aidn også inkludere kodede felter for aktivitet ved fall, illebefinnende og brudd:
| Identifikator | Label | Koder |
|---|---|---|
3487 |
Aktivitet | 1 Ut av og opp i seng, 2 Bruk av rullestol, 3 Toalettbesøk, 4 Gange med rullator, 5 Fri gange, 6 Opp og ned av stol, 7 Annet. |
3488 |
Illebefinnende | 1 Ja, 2 Nei, 3 Vet ikke. |
3489 |
Brudd | 1 Ja, 2 Nei, 3 Vet ikke. |
Send statusoppdateringer til Aidn
Kvalitetssystemet sender én eller flere statusoppdateringer til Aidn under saksbehandlingen. Aidn viser siste mottatte status i avviksbildet.
PUT <OPEN_AIDN_QMS_STATUS_ENDPOINT> HTTP/1.1
Host: <OPEN_AIDN_HOST>
Accept: application/json
Content-Type: application/json
Authorization: Bearer <ACCESS_TOKEN>
{
"qmsId": "QMS-12345",
"identifier": "019c298c-366b-76a8-b73e-87306ae6550d",
"status": {
"code": "closed",
"display": "Ferdig behandlet"
},
"text": [
{
"title": "Status",
"date": 1770219578,
"text": "The adverse event has been handled in the QMS.",
"class": "summary"
}
],
"lastUpdated": 1770219578
}
| Egenskap | Type | Beskrivelse |
|---|---|---|
qmsId |
string | Kvalitetssystemets interne saks-ID. Lagres i Aidn for sporbarhet. |
identifier |
string (UUID) | Aidn-identifikator for avviket. Må matche identifier som Aidn sendte. |
status |
Coding | QMS-definert statuskode og brukervennlig visningstekst. Visningsteksten kan vises direkte til sluttbrukere. |
text |
StatusText[] | Én eller flere statustekstblokker. |
lastUpdated |
number | UNIX timestamp for når avviket sist ble oppdatert i kvalitetssystemet. |
StatusText inneholder title, valgfri date, text, valgfri class og valgfrie nøstede objects for QMS-definerte strukturerte tekstblokker.
Personvern og dataminimering
Integrasjonen er utformet for å unngå direkte pasientidentifiserende informasjon:
- Pasientens navn og fødselsnummer sendes ikke.
- Pasienten representeres med en anonymisert Aidn-identifikator.
- Bildevedlegg i Aidn-skjemaet for pasientavvik overføres ikke gjennom API-et.
- Fritekstfelter kan likevel inneholde indirekte identifiserende opplysninger hvis brukere skriver dem inn. Kommunen bør håndtere dette gjennom opplæring, rutiner og DPIA-vurdering ved behov.
- Kvalitetssystemet bør unngå å lagre melders fødselsnummer eller UPN med mindre dette er del av avtalt behandlingsformål.
Aidn viser tekst i avviksskjemaet som informerer brukeren om at avviket blir overført til kvalitetssystemet og ikke må inneholde pasientsensitive opplysninger.
Sjekkliste før produksjonssetting
Valider oppsettet med kommunen og QMS-leverandøren før produksjonssetting:
- Integrasjonen er aktivert for riktig kommune og miljø.
- QMS-klienten kan be om
adverseevent.write. - Kommunen har gitt QMS-leverandøren avdelingsnavn og Aidn avdelings-ID-er for avdelingene som bruker QMS-integrasjonen.
- Aidn når kvalitetssystemets mottaksendepunkt over avtalt nettverksvei.
- Kvalitetssystemet lagrer Aidn
identifierog returnerer den uendret i statusoppdateringer. - Kvalitetssystemet håndterer duplikate eller gjentatte avviksmeldinger uten å opprette feil saker.
- Kvalitetssystemet håndterer norske kodeverdier og visningstekster som avtalt.
- Kvalitetssystemet lagrer ikke pasientidentifiserende informasjon utover avtalt formål.
- Nøkkelrotasjon, operasjonell overvåking, retry-adferd og kontaktpunkter ved hendelser er avtalt.