Et AuditEvent er en strukturert post, ikke en loggmelding — alt nedenfor er et reelt felt i JSON-svaret du får tilbake, ikke noe du må tolke ut av fritekst.
Element | Hva det forteller deg | Eksempel / verdier |
|---|---|---|
| Hva slags hendelse dette var — en generell livssyklus-kategori, pluss den spesifikke IHE ITI-transaksjonen |
|
| Create, Read, Update, Delete eller Execute |
|
| Når hendelsen ble registrert |
|
| Om den underliggende transaksjonen lyktes, og hvorfor ikke hvis den feilet |
|
| Den identifiserte fagpersonen eller systemet som utførte handlingen, når den identiteten var tilgjengelig i den opprinnelige transaksjonen | Navn og behandler-id |
| Organisasjonen klienten var autentisert som | Overordnet organisasjonsnummer, klient-id, klientnavn |
| Hvem journalen gjelder, når det finnes en pasientkontekst | Pasientidentifikator(er), navn hvis tilgjengelig |
| Det konkrete dokumentet som ble berørt, for dokumentnivå-transaksjoner | Tittel, MIME-type, klassekode, dokument-/innsendingssett-id, hjemmefellesskap |
| Det kliniske formålet (purpose of use) bak tilgangen, når det ble oppgitt | En kodet purpose-of-use-verdi |
| Hvilket system som produserte hendelsen | Identifisert ved repository-id og hjemmefellesskaps-id |
Ikke alle felt er alltid til stede: Felt for bruker, pasient, klientorganisasjon og formål avhenger av hvilken identitets- og formålsinformasjon som var knyttet til den opprinnelige transaksjonen. Et system-til-system-kall med en tynnere sikkerhetskontekst vil la noen av disse feltene stå tomme, i stedet for å fylle dem med plassholderverdier — sjekk om et felt finnes før du stoler på det.