Basic Audit Log Patterns (BALP)
1.1.0 - Trial-Implementation International flag

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

Artifacts Summary

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

Structures: Resource Profiles

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.

  • User Authenticated event
  • ITI-71 subtype
  • 2 or 3 agents
    • client -
    • auth-server
    • user user
  • 1 entity
    • the access token request
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.

  • Import event
  • shall have source of itself
  • shall have a source agent
  • shall have a recipient agent
  • may have user, app, organization agent(s)
    • combine with the Security Token pattern
  • may, if known, have the custodian that released the data
  • may, if known, have the authorizer that represented the patient (may be the patient)
  • shall have a patient entity
  • shall have a set identity entity
Audit Event for Privacy Disclosure at Source

Defines constraints on the AuditEvent Resource to record when a Privacy Disclosure happens at the Source.

  • Import event
  • shall have source of itself
  • shall have a source agent
  • shall have a recipient agent
  • may have user, app, organization agent(s)
    • combine with the Security Token pattern
  • should have the custodian that released the data
  • should have the authorizer that represented the patient (may be the patient)
  • shall have a patient entity
  • shall have the set of data entity(ies)
Basic AuditEvent pattern for when an Authorization permit is decided

An AduitEvent recording a permit authorization decision by a Consent Decision Service,

  • Given an Authorization Decision resulted in a permit
  • And based on a Consent resource (C1)
  • And filed by a patient (P1),
  • And in response to a request by an organization (Org1)
  • And for the purpose of treatment (TREAT).
  • And the given request is authorized
  • When an AuditEvent is recorded for the activity
  • Then that AuditEvent would follow this profile regarding recording the authorization decision
    • Security Alert
    • Authorization Decison by Consent
    • Execute action
    • date/time recorded
    • outcome
      • success when Permit
      • failure when Deny
      • outcomeDesc would explain why a deny
    • recorded by the authorization server
    • Agents
      • client app
      • user
        • user requested purposeOfUse
      • user organization
      • authorization service
    • Entity
      • patient subject
      • consent on file for that patient
      • the token id (JWT ID) issued (if one is issued) should be recorded
      • other data may be recorded that was used in the decision
Basic AuditEvent for a successful Create not related to a Patient

A basic AuditEvent profile for when a RESTful Create action happens successfully.

  • Given a Resource Create is requested with no Patient subject
  • And OAuth is used to authorize both app and user
  • When an App requests a RESTful Create of a new Resource
  • And the new Resource is successfully created thus having an id assigned
  • Then an AuditEvent following this profile is recorded
  • And when a user is known they are the Author, Informant, or Custodian
Basic AuditEvent for a successful Delete

A basic AuditEvent profile for when a RESTful Delete action happens successfully.

  • Given a Resource has no Patient subject
  • And OAuth is used to authorize both app and user
  • When an App requests a RESTful Delete of a target Resource
  • And the target Resource is successfully Deleted thus having an id that is no longer valid
  • Then an AuditEvent following this profile is recorded using the id that is no longer valid
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.

  • Given a Resource Create is requested with a Patient subject
  • And OAuth is used to authorize both app and user
  • When an App requests a RESTful Create of a new Resource
  • And the new Resource is successfully created thus having an id assigned
  • Then an AuditEvent following this profile is recorded
  • And when a user is known they are the Author, Informant, or Custodian
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.

  • Given a Resource has a Patient subject
  • And OAuth is used to authorize both app and user
  • When an App requests a RESTful Delete of a target Resource
  • And the target Resource is successfully Deleted thus having an id that is no longer valid
  • Then an AuditEvent following this profile is recorded using the id that is no longer valid
  • Patient is specified
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).

  • Given a RESTful Query
  • And there is a known Patient subject.
    • The query parameters may have identified a specific patient, or
    • The data resulting from a query do have a patient subject
  • And OAuth is used to authorize both app and user
  • When an App requests a RESTful Query to retrieve Resource(s)
  • Then the search request is recorded
    • The raw search request is base64 encoded and placed in the .entity[query].query element. The base64 encoding of the raw search request enables preserving exactly what was requested, including possibly malicious patterns. This enables detection of malicious or malformed requests.
    • The cleaned search may be recorded (not base64) in the .entity[query].description. The cleaned search request would have removed parameters that were not understood/supported. The cleaned search request in the .description element enables more efficient processing.

no results returned

  • Given no Resource(s) are available for a given Patient identity
  • And OAuth is used to authorize both app and user
  • When an App requests a RESTful Query to retrieve Resources(s) for a given single Patient
  • When policy indicates success with an empty bundle should be returned
  • Then an AuditEvent following this profile is recorded for the requested given Patient

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.

  • Given Resource(s) are known associated with multiple subjects
  • And OAuth is used to authorize both app and user
  • When an App requests a RESTful Query to retrieve Resource(s)
  • And when the query resulting search set contains Resources associated with more than one Patient
  • Then an AuditEvent following this profile is recorded for the Patient identified in the search set returned

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.

  • Given a Resource has a Patient subject
  • And OAuth is used to authorize both app and user
  • When an App requests a RESTful Read to retrieve that Resource
  • Then an AuditEvent following this profile is recorded
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.

  • Given a Resource has a Patient subject
  • And OAuth is used to authorize both app and user
  • When an App requests a RESTful Update of an existing Resource
  • And the Resource is successfully Updated thus where the server supports FHIR Versioning the updated Resource has a new id version assigned
  • Then an AuditEvent following this profile is recorded where the Resource is identified by the updated version specific id where versioning is available
Basic AuditEvent for a successful Query

A basic AuditEvent profile for when a RESTful Query / Search action happens successfully.

  • Given a RESTful Query
  • And there is no known Patient subject.
    • The requestor logging the event would potentially not know a patient identity
    • The data objects may not be patient specific kind of objects
  • And OAuth is used to authorize both app and user
  • When an App requests a RESTful Query to retrieve Resource(s)
  • Then the search request is recorded
    • The raw search request is base64 encoded and placed in the .entity[query].query element. The base64 encoding of the raw search request enables preserving exactly what was requested, including possibly malicious patterns. This enables detection of malicious or malformed requests.
    • The cleaned search may be recorded (not base64) in the .entity[query].description. The cleaned search request would have removed parameters that were not understood/supported. The cleaned search request in the .description element enables more efficient processing.

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.

  • Given a Resource has no Patient subject
  • And OAuth is used to authorize both app and user
  • When an App requests a RESTful Read to retrieve that Resource
  • Then an AuditEvent following this profile is recorded
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 ~ character represents attributes under the SAML AttributeStatement.

Builds upon the Minimal

SAML field Comprehensive AuditEvent
ID agent[user].policy
Issuer agent[user].who.identifier.system
Subject.NameID agent[user].who.identifier.value
~subject:role agent[user].role
~subject:purposeofuse agent[user].purposeOfUse
AuthnContextClassRef agent[user].extension[assuranceLevel]
~subject:subject-id agent[user].extension[otherId][subject-id].value
~subject:npi agent[user].extension[otherId][npi].value
~subject:provider-identifier agent[user].extension[otherId][provider-id].value
~subject:organization agent[userorg].who.display
~subject:organization-id agent[userorg].who.identifier.value
~homeCommunityId agent[homeCommunityId].who.identifier.value
~bppc:2007:docid entity[consent].what.identifier.value
~xua:2012:acp entity[consent].detail.valueString
~resource:resource-id entity[consent-patient].what.identifier.value
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.

  • Given an activity has occurred
  • And SAML is used to authorize a transaction
  • And the given activity is using the SAML
    • XUA
    • SAML requires ID and Issuer, so this profile of AuditEvent will work with any SAML token.
    • usually SOAP, but not limited to SOAP
  • When an AuditEvent is recorded for the activity
  • Presumes that the consent and server have been identified in agent elements, best case with certificate identities
  • Then that AuditEvent would follow this profile regarding recording the SAML access token details

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 ~ character represents attributes under the SAML AttributeStatement.

SAML field Minimal AuditEvent
ID agent[user].policy
Issuer agent[user].who.identifier.system
Subject.NameID agent[user].who.identifier.value
~subject:purposeofuse agent[user].purposeOfUse

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.

  • Given a Resource has no Patient subject
  • And OAuth is used to authorize both app and user
  • When an App requests a RESTful Update of an existing Resource
  • And the Resource is successfully Updated thus where the server supports FHIR Versioning the updated Resource has a new id version assigned
  • Then an AuditEvent following this profile is recorded where the Resource is identified by the updated version specific id where versioning is available

Structures: Extension Definitions

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 saml:AuthnContextClassRef, but may be carried elsewhere based on the use-case and profiling of SAML.

The Vocabulary is not defined here. Some sources of vocabulary:

AuditEvent.agent other identifiers

Carries other identifiers are known for an agent.

Terminology: Value Sets

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.

  • http://terminology.hl7.org/CodeSystem/v3-ParticipationType#IRCP // use for query/retrieve
  • http://terminology.hl7.org/CodeSystem/v3-RoleClass#AGNT // use for push/create/update
  • http://terminology.hl7.org/CodeSystem/v3-RoleClass#PAT // use when the user is the patient
  • http://terminology.hl7.org/CodeSystem/v3-ParticipationType#AUT “Author” // used with create/update
  • http://terminology.hl7.org/CodeSystem/v3-ParticipationType#INF “Informant” // used with export
  • http://terminology.hl7.org/CodeSystem/v3-ParticipationType#CST “Custodian” // used with export

Terminology: Code Systems

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

Example: Example Instances

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

  • recorded by the server
  • server is FHIR application server defined by ex-device
  • client is an app on myMachine on myMachine
  • user is an Informant Betty Jones
  • patient is ex-patient
  • created resource is ex-list
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

  • recorded by the server
  • server is FHIR application server defined by ex-device
  • client is an app on myMachine on myMachine
  • user is an Custodian Charley Miller
  • patient is ex-patient
  • created resource is ex-list
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

  • recorded by the client with server
  • server is FHIR application server defined by ex-device
  • client is an app on myMachine on myMachine
  • user is the author John Smith
  • patient is ex-patient
  • created resource is ex-list
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.

  • recorded by the client
  • server is FHIR application server defined by ex-device
  • client is an app on myMachine on myMachine
  • user is John Smith
  • created resource is ex-measurereport
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.

  • recorded by the client - ex-device
  • server is FHIR application server defined by ex-device
  • client is an app on myMachine on myMachine
  • patient is ex-patient
  • created resource is ex-list
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.

  • recorded by the client - ex-device
  • server is FHIR application server defined by ex-device
  • client is an app on myMachine on myMachine
  • patient is ex-patient
  • created job is ex-documentreference
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.

  • recorded by the client - ex-device
  • server is FHIR application server defined by ex-device
  • client is an app on myMachine on myMachine
  • patient is ex-patient
  • created resource is ex-documentreference
Server - Audit Example of a basic patient identifiable Create

Audit Example for a RESTful Create of a resource with a patient subject

  • recorded by the server with client
  • server is FHIR application server defined by ex-device
  • client is an app on myMachine on myMachine
  • user is John Smith
  • patient is ex-patient
  • created resource is ex-list
Client - Audit Example of a basic patient identifiable Delete

Audit Example for a RESTful Delete of a resource with a patient subject

  • recorded by the client
  • client is an app on myMachine
  • user is an Custodian Charley Miller
  • patient is identified as ex-patient
  • deleted object is ex-list
Client - Audit Example of a basic patient identifiable Delete at Client

Audit Example for a RESTful Delete of a resource with a patient subject

  • recorded by the client peer server
  • client is an app on myMachine
  • user is the Author John Smith
  • patient is identified as ex-patient
  • deleted object is ex-list
Server - Audit Example of a basic patient identifiable Delete by Informant

Audit Example for a RESTful Delete of a resource with a patient subject

  • recorded by the server
  • server is FHIR application server defined by ex-device
  • client is an app on myMachine on myMachine
  • user is an Informant Betty Jones
  • patient is identified as ex-patient
  • deleted object is ex-list
Server - Audit Example of a basic object Delete at server

Audit Example for a RESTful Delete of a resource that is NOT patient specific

  • recorded by the server
  • client is an app on myMachine
  • user is the Author John Smith
  • deleted object is ex-measurereport that is a summary FEMA COVID report draft
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.

  • recorded by the client
  • client is an app on myMachine
  • user is NOT specified.
  • patient is identified as ex-patient
  • deleted object is ex-list
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.

  • recorded by the client
  • client is an app on myMachine
  • user is NOT specified.
  • patient is identified as ex-patient
  • deleted Job is ex-documentreference
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.

  • recorded by the client
  • client is an app on myMachine
  • user is NOT specified.
  • patient is identified as ex-patient
  • deleted Report is ex-documentreference
Server - Audit Example of a basic patient identifiable Delete at server

Audit Example for a RESTful Delete of a resource with a patient subject

  • recorded by the server peer client
  • client is an app on myMachine
  • user is the Author John Smith
  • patient is identified as ex-patient
  • deleted object is ex-list
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

  • recorded by the server
  • server is FHIR application server defined by ex-device
  • client is an app on myMachine on myMachine
  • user is John Smith
  • patient is ex-patient
  • created resource is ex-list
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

  • recorded by the client
    • see same event as recorded by the server
  • server is FHIR application server defined by ex-device
  • client is a computer at myMachine.example.org
  • user is John Smith
  • query is for an Observation for given patient
  • patient is specified
  • X-Request-Id is specified
Server - Audit Example of a basic Query (GET)

Audit Example for a RESTful Query using GET with NO patient subject, recorded by the Server.

  • recorded by the server
  • server is FHIR application server defined by ex-device
  • client is a computer at myMachine.example.org
  • user is John Smith
  • query is for a MeasureReport
  • X-Request-Id is specified
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

  • recorded by the server
    • see same event as recorded by the client
  • server is FHIR application server defined by ex-device
  • client is a computer at myMachine.example.org
  • user is John Smith
  • query is for an Observation for given patient
  • patient is specified
  • X-Request-Id is specified
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

  • recorded by the server
  • server is FHIR application server defined by ex-device
  • client is a computer at myMachine.example.org
  • user is John Smith
  • query is for an Observation for given patient
  • patient is specified
Client - Audit Example of a basic patient identifiable read

Audit Example for a RESTful read of a resource with a patient subject

  • recorded by the client peer server
  • server is FHIR application server defined by ex-device
  • client is an app on myMachine on myMachine
  • user is John Smith
  • patient is ex-patient
  • read resource is ex-list
  • x-request-id is 76d148b6-586d-11ec-bf63-0242ac130002
Server - Audit Example of a basic patient identifiable read

Audit Example for a RESTful read of a resource with no patient subject

  • recorded by the server
  • server is FHIR application server defined by ex-device
  • client is an app on myMachine on myMachine
  • user is John Smith
  • read resource is ex-measurereport
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.

  • recorded by the server
  • server is FHIR application server defined by ex-device
  • client is an app on myMachine on myMachine
  • user is John Smith
  • patient is ex-patient
  • read resource is ex-list
  • x-request-id is c07cf648-f068-4dd9-9411-8e69ca07d525
Server - Audit Example of a basic patient identifiable read

Audit Example for a RESTful read of a resource with a patient subject

  • recorded by the server peer client
  • server is FHIR application server defined by ex-device
  • client is an app on myMachine on myMachine
  • user is John Smith
  • patient is ex-patient
  • read resource is ex-list
  • x-request-id is 76d148b6-586d-11ec-bf63-0242ac130002
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

  • recorded by the server
  • server is FHIR application server defined by ex-device defined by ex-device
  • client is an app on myMachine on myMachine
  • user is an Informant Betty Jones
  • patient is ex-patient
  • created resource is ex-list
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.

  • recorded by the server
  • server is FHIR application server defined by ex-device defined by ex-device
  • client is an app on myMachine on myMachine
  • user is an Custodian Charley Miller
  • patient is ex-patient
  • created resource is ex-list
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.

  • recorded by the server
  • server is FHIR application server defined by ex-device defined by ex-device
  • client is an app on myMachine on myMachine
  • user is John Smith
  • created resource is ex-measurereport
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.

  • recorded by the server
  • server is FHIR application server defined by ex-device defined by ex-device
  • client is myMachine
  • patient is ex-patient
  • created resource is ex-list
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.

  • recorded by the server
  • server is FHIR application server defined by ex-device defined by ex-device
  • client is an app on myMachine on myMachine
  • patient is ex-patient
  • created Job is ex-documentreference
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.

  • recorded by the server
  • server is FHIR application server defined by ex-device defined by ex-device
  • client is an app on myMachine on myMachine
  • patient is ex-patient
  • created report is ex-documentreference
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:

GET https://server.example.com/fhir/Patient?family=MOHR&given=ALICE&active=true&gender=female
Accept: application/fhir+json; fhirVersion=4.0
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:

GET https://server.example.com/fhir/Patient?family=MOHR&given=ALICE&active=true&gender=female
Accept: application/fhir+json; fhirVersion=4.0

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

SAML field example value
Subject.NameID “05086900124”
Issuer “https://sts.sykehuspartner.no”
ID “XC4WdYS0W5bjsMGc5Ue6tClD_5U”
purposeOfUse “http://terminology.hl7.org/CodeSystem/v3-ActReason#PATRQT”
assurance authenticated AAL 4
~subject:subject-id “JohnDoe”
~subject:npi “1234567@myNPIregistry.example.org”
~subject:provider-identifier “JohnD”
~subject:organization “St. Mary of Examples”
~subject:organization-id “1234567@myOrganizationRegistry.example.org”
~bppc:2007:docid “urn:uuid:a4b1d27e-5493-11ec-bf63-0242ac130002”
~xua:2012:acp “urn:uuid:b8aa8eec-5493-11ec-bf63-0242ac130002”
~homeCommunityId “urn:uuid:cadbf8d0-5493-11ec-bf63-0242ac130002”
~resource:resource-id “urn:uuid:d7391e5a-5493-11ec-bf63-0242ac130002”
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.

SAML field example value
Subject.NameID “05086900124”
Issuer “https://sts.sykehuspartner.no”
ID “XC4WdYS0W5bjsMGc5Ue6tClD_5U”
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.

SAML field example value
Subject.NameID “JoeL”
Issuer “https://carequality.org”
ID “_5a6b51b7-cd3e-4629-aac8-9846cbc3cf84”
~purposeOfUse http://terminology.hl7.org/CodeSystem/v3-ActReason, TREAT
~purposeOfUse http://terminology.hl7.org/CodeSystem/v3-ActReason, ETREAT
~purposeOfUse http://terminology.hl7.org/CodeSystem/v3-ActReason, HPAYMT
~purposeOfUse http://terminology.hl7.org/CodeSystem/v3-ActReason, HOPERAT
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).

SAML example value
Subject.NameID “UID=kskagerb”
Issuer “CN=John Miller,OU=Harris,O=HITS,L=Melbourne,ST=FL,C=US”
ID “_d87f8adf-711a-4545-bf77-ff8517b498e4”
subject-id “Karl S Skagerberg”
subject:organization “connectred5.fedsconnect.org”
subject:organization-id “urn:oid:2.16.840.1.113883.3.333”
homeCommunityId “urn:oid:2.16.840.1.113883.3.333”
subject:role “2.16.840.1.113883.6.96#307969004”
purposofuse “2.16.840.1.113883.3.18.7.1#PUBLICHEALTH”
resource-id “500000000^^^&2.16.840.1.113883.3.333&ISO”
AuthzDecisionStatement nesting
.AccessConsentPolicy “urn:oid:1.2.3.4”
.InstanceAccessConsentPolicy “urn:oid:1.2.3.4.123456789”
AuthnContextClassRef “urn:oasis:names:tc:SAML:2.0:ac:classes:X509”
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.

SAML field example value
Subject.NameID “UID=kskagerb”
Issuer “CN=John Miller,OU=Harris,O=HITS,L=Melbourne,ST=FL,C=US”
ID “_d87f8adf-711a-4545-bf77-ff8517b498e4”
subject-id “Karl S Skagerberg”
subject:organization “connectred5.fedsconnect.org”
subject:organization-id “urn:oid:2.16.840.1.113883.3.333”
homeCommunityId “urn:oid:2.16.840.1.113883.3.333”
subject:role “2.16.840.1.113883.6.96#307969004”
purposofuse “2.16.840.1.113883.3.18.7.1#PUBLICHEALTH”
resource-id “500000000^^^&2.16.840.1.113883.3.333&ISO”
AuthzDecisionStatement nesting
.AccessConsentPolicy “urn:oid:1.2.3.4”
.InstanceAccessConsentPolicy “urn:oid:1.2.3.4.123456789”
AuthnContextClassRef “urn:oasis:names:tc:SAML:2.0:ac:classes:X509”
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