NO Domain Trust Framework ("Nasjonalt tillitsrammeverk") AuditEvent Implementation Guide
0.9.8 - ci-build
NO Domain Trust Framework ("Nasjonalt tillitsrammeverk") AuditEvent Implementation Guide - Local Development build (v0.9.8) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
These define constraints on FHIR resources for systems conforming to this implementation guide.
no-doc-Trustframework-Location-EncounterPointofcare |
The point of care location of auditevent encounter (Auditevent._encounter). |
no-doc-Trustframework-Location-PractitionerPointofcare |
The point of care location of auditevent health care practitioner actor (Auditevent.agent.who). |
no-doc-Trustframework-Organization-EncounterPointofcare |
The point of care managing organization of the auditevent encounter (Auditevent._encounter) |
no-doc-Trustframework-Organization-EncounterServiceprovider |
The service provider department of auditevent encounter (Auditevent._encounter). |
no-doc-Trustframework-Organization-PractitionerDepartment |
The health care department of the health care auditevent practitioner actor (Auditevent.agent.who). |
no-doc-Trustframework-Organization-PractitionerLegalentity |
The health care managing organization (legal entity) of the health care auditevent practitioner actor (Auditevent.agent.who). |
no-doc-Trustframework-Organization-PractitionerPointofcare |
The point of care managing organization of auditevent health care practitioner actor (Auditevent.agent.who). |
no-domain-Trustframework-Auditevent |
This is the main profile that describes the mapping of Norwegian Trust Framework attributes ("Tillitsrammeverk") to AuditEvent Resource. |
no-domain-Trustframework-Encounter |
The encounter associated with auditevent if any (Auditevent._encounter). |
no-domain-Trustframework-Patient |
The patient (patients:identifier) that is the subject of the auditevent activity if any (Auditevent._patient). NOTE! Single auditevent per patient, i.e. need to duplicate auditevent for each patient in list. |
no-domain-Trustframework-PractitioneRole |
The health care practitioner auditevent actor at managing organization (Auditevent.agent.who). NOTE! The organization element reference either a department that again references a legal entity as the top level (hierarchy) or legal entity directly. Small organizations, like GPs, the organization element will reference the GP's own business (legal entity), but a clinician working in hospital will reference a department that again references its hospital (legal entity). |
no-domain-Trustframework-Practitioner |
The health care audit event practitioner actor (Auditevent.agent.who). |
These define constraints on FHIR data types for systems conforming to this implementation guide.
AuditEventCareRelationMetaData |
This extensins carries information about a 'user session' defined as access to health information for a patient or group where the access criteria are the same and access occurs from a single logical system within a given time window. |
AuditEventEncounterExtension |
Extension that extends FHIR AuditEvent R4 with Encounter reference which was introduced in FHIR AuditEvent R5 |
AuditEventPatientExtension |
Extension that extends FHIR AuditEvent R4 with en Patient reference which was introduced in FHIR AuditEvent R5 |
These define new code systems used by systems conforming to this implementation guide.
DIPS decision template codes used as basis of care relation between health care personel and patient. |
These are templates with various justifications that can be used as a basis for accessing the patient's medical record at hospitals that utilize DIPS as their journal system. Templates that user, if authorized, can select manually as reason for accessing patient's medical record are marked as '(Eksplisitt mal)'. NB! This code system is currently vendor specific (DIPS) and defined in this profile temporarily until a more suitable place is found. |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
GP example |
ENG: Example of GP as open document content. NO: Eksempelet hvor en fastlege åpner dokumentinnhold. |
Hospital example |
ENG: In this example, an anesthesiologist formally associated with Rikshospitalet is preparing to administer anesthesia to a patient undergoing eye surgery at Ullevål Hospital. The anesthesiologist needs access to read documents from previous practitioners in other institutions to determine which substances were used during prior anesthesia, as the patient reports experiencing allergic reactions. NO: I dette eksempelet skal en anestesilege som formelt tilhører Rikshospitalet forberede seg på å gi anestesi til en pasient som er inne for en øyeoperasjon ved Ullevål sykehus, og anestesilegen trenger derfor tilgang til å lese dokumenter fra tidligere behandlere i andre virksomheter for å finne ut hvilke virkestoffer som ble brukt under tidligere anestesi som pasienten rapporterer medførte allergiske reaksjoner |
Municipality example |
ENG: In this example, a nursing home doctor at Madserudhjemmet needs access to a document in another organization to plan further follow-up for a patient receiving home care services from the municipality. NO: I dette eksempelet har en sykehjemslege ved Madserudhjemmet behov for tilgang til et dokument i en annen virksomhet for å planlegge videre oppfølging av en pasient som mottar hjemmehjelpstjenester fra kommunen |