Basic Audit Log Patterns (BALP)
1.1.0 - Trial-Implementation
Basic Audit Log Patterns (BALP)
1.1.0 - Trial-Implementation
This page is part of the IHE Basic Audit Log Patterns (BALP) (v1.1.0: Trial Implementation) based on FHIR R4. This is the current published version. For a full list of available versions, 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
| 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.
|
||||||||||||||||||||||||||||||||
| 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.
|
||||||||||||||||||||||||||||||||
| Audit Event for Privacy Disclosure at Source |
Defines constraints on the AuditEvent Resource to record when a Privacy Disclosure happens at the Source.
|
||||||||||||||||||||||||||||||||
| Basic AuditEvent pattern for when an Authorization permit is decided |
An AduitEvent recording a permit authorization decision by a Consent Decision Service,
|
||||||||||||||||||||||||||||||||
| 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 Delete |
A basic AuditEvent profile for when a RESTful Delete action happens successfully.
|
||||||||||||||||||||||||||||||||
| 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 oAuth Comprehensive |
Used when only have access to the oAuth token details (JWT). |
||||||||||||||||||||||||||||||||
| Basic AuditEvent pattern for oAuth Minimal |
Used when only have access to the oAuth token details (JWT). |
||||||||||||||||||||||||||||||||
| Basic AuditEvent pattern for oAuth Opaque |
Used when only have an opaque oAuth token. |
||||||||||||||||||||||||||||||||
| 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 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 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).
no results returned
multiple patient results are returned. Note that one AuditEvent is created for every Patient identified in the resulting search set. Note this is true when the search set bundle includes any number of resources that collectively reference multiple Patients. This includes one Resource with multiple subject values, or many Resources with single subject values that are different.
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 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 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 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 Read |
A basic AuditEvent profile for when a RESTful Read action happens successfully.
|
||||||||||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||||||||||
| Basic AuditEvent for a successful Update |
A basic AuditEvent profile for when a RESTful Update action happens successfully.
|
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
| 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. |
| participant source types for RESTful create |
create agent participant types for user operators that are in REST |
| 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 |
| 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.
|
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 |
| XCA code for homeCommunity |
one code |
| 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
| SAML example from CareQuality |
Example of a SAML assertion as seen in CareQuality. |
||||||||||||||||||||||||||||||
| Audit Example of a basic Authorization Permit access |
Example AuditEvent showing an authorization decision. |
||||||||||||||||||||||||||||||
| Audit Example of a basic Authorization Deny access |
Example AuditEvent showing an authorization decision resulting in deny. |
||||||||||||||||||||||||||||||
| 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 Create by a custodian |
Audit Example for a RESTful Create of a resource with a patient subject by a custodian
|
||||||||||||||||||||||||||||||
| 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
|
||||||||||||||||||||||||||||||
| 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.
|
||||||||||||||||||||||||||||||
| 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 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.
|
||||||||||||||||||||||||||||||
| Server - Audit Example of a basic patient identifiable Create |
Audit Example for a RESTful Create of a resource with a patient subject
|
||||||||||||||||||||||||||||||
| 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
|
||||||||||||||||||||||||||||||
| 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 object Delete at server |
Audit Example for a RESTful Delete of a resource that is NOT patient specific
|
||||||||||||||||||||||||||||||
| 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 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.
|
||||||||||||||||||||||||||||||
| 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 Update using Patch |
Audit Example for a RESTful Update using Patch of a resource with a patient subject
|
||||||||||||||||||||||||||||||
| 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
|
||||||||||||||||||||||||||||||
| 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 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
|
||||||||||||||||||||||||||||||
| Client - 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 |
Audit Example for a RESTful read of a resource with no 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.
|
||||||||||||||||||||||||||||||
| 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 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 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 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 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 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.
|
||||||||||||||||||||||||||||||
| Audit Example of ITI-66 at Consumer |
Audit Example for a Find Document Lists Transaction as recorded at the consumer |
||||||||||||||||||||||||||||||
| Audit Example of ITI-66 at responder |
Audit Example for a Find Document Lists Transaction from responder perspective |
||||||||||||||||||||||||||||||
| Audit Example of ITI-67 at Consumer |
Audit Example for a Find Document References Transaction as recorded at the consumer |
||||||||||||||||||||||||||||||
| Audit Example of ITI-67 using POST recorded at responder |
Audit Example for a Find Document References Transaction using POST search as recorded at the responder perspective |
||||||||||||||||||||||||||||||
| Audit Example of ITI-67 at responder |
Audit Example for a Find Document References Transaction from responder perspective |
||||||||||||||||||||||||||||||
| Audit Example of ITI-78 at Consumer |
Audit Event for PDQm Query Transaction by the Patient Identifier Cross-reference Consumer where the Query was executed with a GET as follows: |
||||||||||||||||||||||||||||||
| Audit Example of ITI-78 at Supplier |
Audit Event for PDQm Query Transaction by the Patient Identifier Cross-reference Supplier where the Query was executed with a GET as follows: Note the Supplier may choose to record patient identities found, but is not required to. Given the Supplier chooses to record a patient in the AuditEvent When the search finds multiple Patients, Then the Supplier would create an AuditEvent for each of those Patients. This example shows where ex-patient is returned. This single result does not affect the response returned on the ITI-78 that would include all results. |
||||||||||||||||||||||||||||||
| Audit Example of ITI-83 at Consumer |
Audit Event for PIXm Query Transaction ITI-83 by the Patient Identifier Cross-reference Consumer |
||||||||||||||||||||||||||||||
| Audit Example of ITI-83 at Manager |
Audit Event for PIXm Query Transaction ITI-83 by the Patient Identifier Cross-reference Manager |
||||||||||||||||||||||||||||||
| 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 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 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.
|
||||||||||||||||||||||||||||||
| 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 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 Privacy Disclosure of a patient specific MeasureReport |
Audit Example for a Privacy Disclosure from source perspective of a MeasureReport |
||||||||||||||||||||||||||||||
| 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 ITI-68 at consumer |
Audit Example for a Retrieve Document Transaction as recorded at the consumer |
||||||||||||||||||||||||||||||
| Audit Example of ITI-68 at responder |
Audit Example for a Retrieve Document Transaction from responder perspective |
||||||||||||||||||||||||||||||
| Dummy Device authorization service example |
Dummy Device authorization service 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 |
||||||||||||||||||||||||||||||
| Dummy Consent example |
Dummy Consent 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 example |
Dummy DocumentReference 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 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 |
IG © 2022+ IHE IT Infrastructure Technical Committee. Package ihe.iti.balp#1.1.0 based on FHIR 4.0.1. Generated 2022-05-04
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
|
Propose a change