Basic Audit Log Patterns (BALP)
1.1.4-current - ci-build
Basic Audit Log Patterns (BALP)
1.1.4-current - ci-build
Basic Audit Log Patterns (BALP), published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 1.1.4-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/qligier/ITI.BasicAudit/ and changes regularly. See the Directory of published versions
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.
| IHE ATNA Audit Record Repository supporting BALP Content |
CapabilityStatement for ATNA Audit Record Repository Actor with the ATNA ATX:FHIR Feed Option and Retrieve Audit Message Option defined in RESTful-ATNA Supplement that also has support for BALP Content. This Actor is derived off of the ATNA Audit Record Repository actor that is not yet defined fully in an IG. This CapabilityStatement does not represent a formal Actor, but rather a system that has grouped ATNA and BALP. |
| IHE BALP Audit Consumer |
CapabilityStatement for Audit Consumer Actor in BALP. This CapabilityStatement replicates the requirements that would come from the ATNA Audit Consumer* actor supporting **ATNA Retrieve Audit Message Option. |
| IHE BALP Audit Creator |
CapabilityStatement for Audit Creator Actor in BALP. This Actor is derived off of the ATNA Secure Application or Secure Node actor with ATNA ATX:FHIR Feed Option using ITI-20. |
These define constraints on FHIR resources for systems conforming to this implementation guide.
| Audit Event for Privacy Disclosure at Source |
Defines constraints on the AuditEvent Resource to record when a Privacy Disclosure happens at the Source.
|
||||||||||||||||||||||||||||||||
| Audit Event for a Privacy Disclosure as recorded by a Recipient |
Defines constraints on the AuditEvent Resource to record when a Privacy Disclosure is detected at the Recipient of the data.
|
||||||||||||||||||||||||||||||||
| Basic AuditEvent for a successful Create not related to a Patient |
A basic AuditEvent profile for when a RESTful Create action happens successfully.
|
||||||||||||||||||||||||||||||||
| Basic AuditEvent for a successful Create with known Patient subject |
A basic AuditEvent profile for when a RESTful Create action happens successfully, and where there is an identifiable Patient subject associated with the create of the Resource.
|
||||||||||||||||||||||||||||||||
| Basic AuditEvent for a successful Delete |
A basic AuditEvent profile for when a RESTful Delete action happens successfully.
|
||||||||||||||||||||||||||||||||
| Basic AuditEvent for a successful Delete with Patient |
A basic AuditEvent profile for when a RESTful Delete action happens successfully, and where there is an identifiable Patient subject associated with the Resource being deleted.
|
||||||||||||||||||||||||||||||||
| Basic AuditEvent for a successful Query |
A basic AuditEvent profile for when a RESTful Query / Search action happens successfully.
Note: the pattern defined in DICOM and IHE have the client is identified as the Source Role ID, and the server is identified as the Destination Role ID. This represents the query parameters are flowing from the client to the server. This may not be so obvious, as the data actually flows the opposite direction. This pattern is established and thus followed here. |
||||||||||||||||||||||||||||||||
| Basic AuditEvent for a successful Query with Patient |
A basic AuditEvent profile for when a RESTful Query action happens successfully, and where there is an identifiable Patient subject associated with the read Resource(s).
Note: the pattern defined in DICOM and IHE have that the client is identified as the Source Role ID, and the server is identified as the Destination Role ID. This may not be so obvious, as the data actually flows the opposite direction. This pattern is established and thus followed here. |
||||||||||||||||||||||||||||||||
| Basic AuditEvent for a successful Read |
A basic AuditEvent profile for when a RESTful Read action happens successfully.
|
||||||||||||||||||||||||||||||||
| Basic AuditEvent for a successful Read with a Patient |
A basic AuditEvent profile for when a RESTful Read action happens successfully, and where there is an identifiable Patient subject associated with the read Resource.
|
||||||||||||||||||||||||||||||||
| Basic AuditEvent for a successful Update |
A basic AuditEvent profile for when a RESTful Update action happens successfully.
|
||||||||||||||||||||||||||||||||
| Basic AuditEvent for a successful Update with a Patient subject |
A basic AuditEvent profile for when a RESTful Update action happens successfully, and where there is an identifiable Patient subject associated with the Update of the Resource.
|
||||||||||||||||||||||||||||||||
| Basic AuditEvent pattern for oAuth Opaque |
Used when access to the oAuth token, but want to log minimal details.
|
||||||||||||||||||||||||||||||||
| Basic AuditEvent pattern for oAuth Opaque |
Used when:
|
||||||||||||||||||||||||||||||||
| Basic AuditEvent pattern for when an Authorization permit is decided |
An AduitEvent recording a permit authorization decision by a Consent Decision Service,
|
||||||||||||||||||||||||||||||||
| Basic AuditEvent pattern for when an activity was authorized by an IUA access token |
A basic AuditEvent profile for when an activity was authorized by an IUA access token. This profile is expected to be used with some other detail that explains the activity. This profile only covers the IUA access token.
|
||||||||||||||||||||||||||||||||
| Basic AuditEvent pattern for when an activity was authorized by an SAML access token Comprehensive |
A basic AuditEvent profile for when an activity was authorized by an SAML access token. This profile is expected to be used with some other detail that explains the activity. This profile only covers the SAML access token. The following table uses a short-hand for the SAML fields and FHIR AuditEvent elements to keep the table compact. It is presumed the reader can understand the SAML field and the FHIR AuditEvent element given. Note the Builds upon the Minimal
|
||||||||||||||||||||||||||||||||
| Basic AuditEvent pattern for when an activity was authorized by an SAML access token Minimal |
A basic AuditEvent profile for when an activity was authorized by an SAML access token. This profile is expected to be used with some other detail that explains the activity. This profile only covers the SAML access token.
The following table uses a short-hand for the SAML fields and FHIR AuditEvent elements to keep the table compact. It is presumed the reader can understand the SAML field and the FHIR AuditEvent element given. Note the
note: this profile records minimal information from the SAML access token, which presumes that use of the AuditEvent at a later time will be able to resolve the given information. |
||||||||||||||||||||||||||||||||
| IHE IUA ITI-71 AuditEvent for a successful Get Access Token |
Defines constraints on the AuditEvent Resource to record when a ITI-71 - Get Access Token succeeds This AuditEvent is recorded by Authorization Client and/or Authorization Server that are grouped with ATNA Secure Node or Secure Application.
|
These define constraints on FHIR data types for systems conforming to this implementation guide.
| AuditEvent.agent Assurance Level |
The assuranceLevel element carries various types of Assurance level. May be an Identity Assurance (IAL), an Authentication Assurance Level (AAL), a Federation Assurance Level (FAL), or other. In SAML this is defined to be carried in the The Vocabulary is not defined here. Some sources of vocabulary:
|
| AuditEvent.agent other identifiers |
Carries other identifiers are known for an agent. |
These define sets of codes used by systems conforming to this implementation guide.
| Agent types holding User-Agent |
AuditEvent.agent.type values holding OAuth/SAML identified user. Note that user is not just users, but representes the higest agent responsible for triggering the activity being recorded in the AuditEvent. Often this agent also has a type coding that is more specific to the transaction and the direction of the transaction.
|
| Authorization subType events valueset |
ValueSet of the Authorization AuditEvent types |
| Entity Types used by IHE BasicAudit |
For use with AuditEvent.entity.type. This includes codes defined in the BasicAudit. |
| Other Id Types ValueSet |
ValueSet of the Other Id Types allowed |
| RESTful objects role in the event |
The role that the given Object played in the Audit Event recorded |
| all Reads |
ValueSet of the restful-interaction reads |
| all Searches |
ValueSet of the restful-interaction searches |
| all Updates |
ValueSet of the restful-interaction updates |
| participant source types for RESTful create |
create agent participant types for user operators that are in REST |
These define new code systems used by systems conforming to this implementation guide.
| Authorization subType events |
These AuditEvent subTypes are related to Authorization Decisions. These are more specific types of Security Alert. |
| Entity Types that are defined in IHE BasicAudit |
These are new codes used in BasicAudit IG, where AuditEvent.entity is used to hold a specific kind of data that is not covered by the existing valueSet. |
| OtherId Identifier Types |
OtherId Types beyond those in the FHIR core |
| The code used to identifiy a User Agent |
Code used to identify the User Agent. Defined codes for SAML vs OAuth to enable differentiation of .policy as the token ID |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
| Audit Example of Privacy Disclosure at recipient |
Audit Example for a Privacy Disclosure as recorded at the recipient |
||||||||||||||||||||||||||||||
| Audit Example of Privacy Disclosure at recipient |
Audit Example for a Privacy Disclosure as recorded at the recipient |
||||||||||||||||||||||||||||||
| Audit Example of Privacy Disclosure at source |
Audit Example for a Privacy Disclosure from source perspective |
||||||||||||||||||||||||||||||
| Audit Example of Privacy Disclosure at source |
Audit Example for a Privacy Disclosure from source perspective |
||||||||||||||||||||||||||||||
| Audit Example of Privacy Disclosure of a patient specific MeasureReport |
Audit Example for a Privacy Disclosure from source perspective of a MeasureReport |
||||||||||||||||||||||||||||||
| Audit Example of a basic Authorization Deny access |
Example AuditEvent showing an authorization decision resulting in deny. |
||||||||||||||||||||||||||||||
| Audit Example of a basic Authorization Permit access |
Example AuditEvent showing an authorization decision. |
||||||||||||||||||||||||||||||
| Audit Example of a basic SAML access token of comprehensive |
Example AuditEvent showing just the comprehensive SAML access token. The event being recorded is a theoretical poke (not intended to represent anything useful). Comprehensive is different than Minimal in that it presumes that when the AuditEvent is used, the appropriate use of the AuditEvent does not have access to the SAML Idenity Provider (IDP), or that the IDP may have forgotten about the issued ID. Builds upon the Minimal
|
||||||||||||||||||||||||||||||
| Audit Example of a basic SAML access token of comprehensive from QDI sample |
Example AuditEvent showing QDI sample with just the comprehensive SAML access token. The event being recorded is a theoretical poke (not intended to represent anything useful).
|
||||||||||||||||||||||||||||||
| Audit Example of a basic SAML access token of minimal |
Example AuditEvent showing just the minimal SAML access token. The event being recorded is a theoretical poke (not intended to represent anything useful). Minimal only records the SAML assertion id, issuer, and subject. Minimal may record roles and purposeOfUse if known. Minimal presumes you have access to the SAML Identity Provider (IDP) to reverse lookup given this information.
|
||||||||||||||||||||||||||||||
| Audit Example of a basic SAML access token of minimal from QDI sample |
Example AuditEvent showing QDI sample with just the minimal SAML access token. The event being recorded is a theoretical poke (not intended to represent anything useful). Minimal only records the SAML assertion id, issuer, and subject. Minimal may record roles and purposeOfUse if known. Minimal presumes you have access to the SAML Identity Provider (IDP) to reverse lookup given this information.
|
||||||||||||||||||||||||||||||
| Audit Example of a basic SAML access token of minimal with multiple PurposeOfUse |
Example AuditEvent showing just the minimal SAML access token. The event being recorded is a theoretical poke (not intended to represent anything useful). Minimal only records the SAML assertion id, issuer, and subject. Minimal may record roles and purposeOfUse if known. Minimal presumes you have access to the SAML Identity Provider (IDP) to reverse lookup given this information.
|
||||||||||||||||||||||||||||||
| Client - Audit Example of a basic patient identifiable Create by the author |
Audit Example for a RESTful Create of a resource with a patient subject created by the author
|
||||||||||||||||||||||||||||||
| Client - Audit Example of a basic patient identifiable Create of a Job with no user |
Audit Example for a RESTful Create of a Job (document) resource with a patient subject with no user. This might be a B2B exchange where the OAuth token just identifies the requesting organization.
|
||||||||||||||||||||||||||||||
| Client - Audit Example of a basic patient identifiable Create of a Report with no user |
Audit Example for a RESTful Create of a Report (document) resource with a patient subject with no user. This might be a B2B exchange where the OAuth token just identifies the requesting organization.
|
||||||||||||||||||||||||||||||
| Client - Audit Example of a basic patient identifiable Create with no user |
Audit Example for a RESTful Create of a resource with a patient subject with no user. This might be a B2B exchange where the OAuth token just identifies the requesting organization.
|
||||||||||||||||||||||||||||||
| Client - Audit Example of a basic patient identifiable Delete |
Audit Example for a RESTful Delete of a resource with a patient subject
|
||||||||||||||||||||||||||||||
| Client - Audit Example of a basic patient identifiable Delete at Client |
Audit Example for a RESTful Delete of a resource with a patient subject
|
||||||||||||||||||||||||||||||
| Client - Audit Example of a basic patient identifiable Delete of a Job with no user |
Audit Example for a RESTful Delete of a Job (document) resource with a patient subject with no user. This might be a B2B exchange where the OAuth token just identifies the requesting organization.
|
||||||||||||||||||||||||||||||
| Client - Audit Example of a basic patient identifiable Delete of a Report with no user |
Audit Example for a RESTful Delete of a Report (document) resource with a patient subject with no user. This might be a B2B exchange where the OAuth token just identifies the requesting organization.
|
||||||||||||||||||||||||||||||
| Client - Audit Example of a basic patient identifiable Delete with no user |
Audit Example for a RESTful Delete of a resource with a patient subject with no user. This might be a B2B exchange where the OAuth token just identifies the requesting organization.
|
||||||||||||||||||||||||||||||
| Client - Audit Example of a basic patient identifiable Query (GET) |
Audit Example for a RESTful Query using GET with a patient subject, recorded by the Client
|
||||||||||||||||||||||||||||||
| Client - Audit Example of a basic patient identifiable read |
Audit Example for a RESTful read of a resource with a patient subject
|
||||||||||||||||||||||||||||||
| Dummy Consent example |
Dummy Consent example for completeness sake. No actual use of this resource other than an example target |
||||||||||||||||||||||||||||||
| Dummy Device authorization service example |
Dummy Device authorization service example for completeness sake. No actual use of this resource other than an example target |
||||||||||||||||||||||||||||||
| Dummy Device example |
Dummy Device example for completeness sake. No actual use of this resource other than an example target |
||||||||||||||||||||||||||||||
| Dummy DocumentReference 2 example |
Dummy DocumentReference 2 example for completeness sake. No actual use of this resource other than an example target |
||||||||||||||||||||||||||||||
| Dummy DocumentReference example |
Dummy DocumentReference example for completeness sake. No actual use of this resource other than an example target |
||||||||||||||||||||||||||||||
| Dummy List example |
Dummy List example for completeness sake. No actual use of this resource other than an example target |
||||||||||||||||||||||||||||||
| Dummy MeasureReport example |
Dummy MeasureReport example for completeness sake. No actual use of this resource other than an example target that is NOT patient specific. |
||||||||||||||||||||||||||||||
| Dummy Organization example |
Dummy Organization example for completeness sake. No actual use of this resource other than an example target |
||||||||||||||||||||||||||||||
| Dummy Patient example |
Dummy patient example for completeness sake. No actual use of this resource other than an example target |
||||||||||||||||||||||||||||||
| Dummy Practitioner example |
Dummy Practitioner example for completeness sake. No actual use of this resource other than an example target |
||||||||||||||||||||||||||||||
| Example document that says: Hello World |
Dummy Binary that just says Hello World |
||||||||||||||||||||||||||||||
| SAML example from CareQuality |
Example of a SAML assertion as seen in CareQuality. |
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic Create |
Audit Example for a RESTful Create of a resource with No patient subject. This example is a summary measure report.
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic Query (GET) |
Audit Example for a RESTful Query using GET with NO patient subject, recorded by the Server.
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic Update of a measure report |
Audit Example for a RESTful Update of a Measure Report resource. This might be a B2B exchange where the OAuth token just identifies the requesting organization.
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic object Delete at server |
Audit Example for a RESTful Delete of a resource that is NOT patient specific
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable Create |
Audit Example for a RESTful Create of a resource with a patient subject
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable Create by a custodian |
Audit Example for a RESTful Create of a resource with a patient subject by a custodian
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable Create by an informant |
Audit Example for a RESTful Create of a resource with a patient subject by an informant
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable Delete at server |
Audit Example for a RESTful Delete of a resource with a patient subject
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable Delete by Informant |
Audit Example for a RESTful Delete of a resource with a patient subject
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable Query (GET) |
Audit Example for a RESTful Query using GET with a patient subject, recorded by the Server
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable Query (POST) |
Audit Example for a RESTful Query using POST with a patient subject, recorded by the server
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable Update by the custodian |
Audit Example for a RESTful Update of a resource with a patient subject, updated by the custodian.
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable Update by the informant |
Audit Example for a RESTful Update by the informant of a resource with a patient subject
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable Update of a Job with no user |
Audit Example for a RESTful Update of a Job (document) resource with a patient subject with no user. This might be a B2B exchange where the OAuth token just identifies the requesting organization.
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable Update of a Report with no user |
Audit Example for a RESTful Update of a Report (document) resource with a patient subject with no user. This might be a B2B exchange where the OAuth token just identifies the requesting organization.
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable Update using Patch |
Audit Example for a RESTful Update using Patch of a resource with a patient subject
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable Update with no user |
Audit Example for a RESTful Update of a resource with a patient subject with no user. This might be a B2B exchange where the OAuth token just identifies the requesting organization.
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable read |
Audit Example for a RESTful read of a resource with no patient subject
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable read |
Audit Example for a RESTful read of a resource with a patient subject
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable read with no user |
Audit Example for a RESTful read of a resource with a patient subject with no user. This might be a B2B exchange where the OAuth token just identifies the requesting organization.
|
||||||||||||||||||||||||||||||
| oAuth Client - Audit Example of a basic patient identifiable read |
Audit Example for a oAuth authorized RESTful read of a resource with a patient subject
|
||||||||||||||||||||||||||||||
| oAuth Server - Audit Example of a basic patient identifiable read |
Audit Example for a oAuth authorized RESTful read of a resource with a patient subject
|
||||||||||||||||||||||||||||||
| oAuth Server Minimal - Audit Example of a basic patient identifiable read |
Audit Example for minimally recorded oAuth authorized RESTful read of a resource with a patient subject
|
IG © 2022+ IHE IT Infrastructure Technical Committee. Package ihe.iti.balp#1.1.4-current based on FHIR 4.0.1. Generated 2024-10-25
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
|
Propose a change