| # | | Name | Source | Ver | Description |
| 1 | | Audit Event for a Privacy Disclosure as recorded by a Recipient | ihe.iti.balp#current | R4 | 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 |
| 2 | | Audit Event for Expand Value Set Transaction by the Terminology Consumer and Repository | ihe.iti.svcm#current | R4 | Defines constraints on the AuditEvent Resource to record when an Expand Value Set Transaction happens
to expand a ValueSet, as recorded by the Terminology Consumer and Registry. |
| 3 | | Audit Event for Find Document Lists Transaction at Document Responder | ihe.iti.mhd#current | R4 | Defines constraints on the AuditEvent Resource to record when a Find Document Lists Transaction happens, as recorded by the Document Responder.
- Build off of the IHE BasicAudit PatientQuery event
- add the ITI-67 as a subtype
- client is Document Consumer
- server is Document Responder
- entity slices for query, and patient are required
- entity slice for transaction is available |
| 4 | | Audit Event for Find Document Lists Transaction by the Document Consumer | ihe.iti.mhd#current | R4 | Defines constraints on the AuditEvent Resource to record when a Find Document Lists Transaction happens, as recorded by the Document Consumer.
- Build off of the IHE BasicAudit PatientQuery event
- add the ITI-67 as a subtype
- client is Document Consumer
- server is Document Responder
- entity slices for query, and patient are required
- entity slice for transaction is available |
| 5 | | Audit Event for Find Document References Transaction at Document Consumer | ihe.iti.mhd#current | R4 | Defines constraints on the AuditEvent Resource to record when a Find Document References Transaction happens, as recorded by the Document Consumer.
- Build off of the IHE BasicAudit PatientQuery event
- add the ITI-67 as a subtype
- client is Document Consumer
- server is Document Responder
- entity slices for query, and patient are required
- entity slice for transaction is available |
| 6 | | Audit Event for Find Document References Transaction at Document Responder | ihe.iti.mhd#current | R4 | Defines constraints on the AuditEvent Resource to record when a Find Document References Transaction happens, as recorded by the Document Responder.
- Build off of the IHE BasicAudit PatientQuery event
- add the ITI-67 as a subtype
- client is Document Consumer
- server is Document Responder
- entity slices for query, and patient are required
- entity slice for transaction is available |
| 7 | | Audit Event for Find Matching Care Services Transaction by the Care Services Selective Consumer and Care Services Selective Supplier for Query | medcom.sor.mcsd#current | R4 | Defines constraints on the AuditEvent Resource to record when a Find Matching Care Services Transaction happens
to query a Care Services Resource, as recorded by the Care Services Selective Supplier or Care Services Selective Consumer. |
| 8 | | Audit Event for Find Matching Care Services Transaction by the Care Services Selective Supplier and Care Services Selective Supplier for Read | medcom.sor.mcsd#current | R4 | Defines constraints on the AuditEvent Resource to record when a Find Matching Care Services Transaction happens
to read a Care Services resource, as recorded by the Care Services Selective Supplier or Care Services Selective Supplier. |
| 9 | | Audit Event for Generate Metadata ITI-106 Transaction at Recipient | ihe.iti.mhd#current | R4 | Defines constraints on the AuditEvent Resource to record when a Generate Metadata ITI-106 Transaction happens at the Recipient.
- Build off of the IHE Basic Audit Patient Create event
- add the ITI-106 as a subtype
- client is the Document Source
- Server is the Document Recipient
- may have user, app, organization agent(s)
- shall have a patient entity
- shall have a documentReference identity entity |
| 10 | | Audit Event for Generate Metadata ITI-106 Transaction at Source | ihe.iti.mhd#current | R4 | Defines constraints on the AuditEvent Resource to record when a Generate Metadata ITI-106 Transaction happens at the Soure.
- Build off of the IHE Basic Audit Create event
- add the ITI-106 as a subtype
- client is the Document Source
- Server is the Document Recipient
- may have user, app, organization agent(s)
- shall have a document uri
- note the Document Source may add a patient if it knows it. |
| 11 | | Audit Event for Lookup Code Transaction by the Terminology Consumer and Repository | ihe.iti.svcm#current | R4 | Defines constraints on the AuditEvent Resource to record when a Lookup Code Transaction happens
to expand a CodeSystem, as recorded by the Terminology Consumer and Registry. |
| 12 | | Audit Event for Mobile Patient Identity Feed by the Supplier and Consumer | ihe.iti.pmir#current | R4 | Defines constraints on the AuditEvent Resource to record when a Mobile Patient Identity Feed Transaction happens, as recorded by the Supplier and Consumer. |
| 13 | | Audit Event for Patient Identity Feed by the Manager that Deletes a Patient | ihe.iti.pixm#current | R4 | Defines constraints on the AuditEvent Resource to record when a Patient Identity Feed Transaction happens, as recorded by the Patient Identity Cross-reference Manager.
- This profile applies to the Patient Identity Cross-reference Manager actor in
- [Remove Patient](ITI-104.html#2310443-remove-patient)
- Build off of the IHE BasicAudit PatientDelete event
- this will result in two .entity elements with the same logical information
- add the ITI-104 as a subtype
- client is Patient Identifier Source
- server is Patient Identifier Cross-reference Manager
- entity slices for patient are required
- filled with the identifier parameter value from the DELETE
- will be an identifier, not a reference
- entity slice for the data
- filled with the path of the DELETE
- will be the Patient resource id presented
- entity slice for transaction is available |
| 14 | | Audit Event for Patient Identity Feed by the Source that Creates or Updates a Patient | ihe.iti.pixm#current | R4 | Defines constraints on the AuditEvent Resource to record when a Patient Identity Feed Transaction happens, as recorded by the Patient Identity Source.
- This profile applies to the Patient Identity Source actor in
- [Add or Revise Patient](ITI-104.html#2310441-add-or-revise-patient)
- [Resolve Duplicate Patient](ITI-104.html#2310442-resolve-duplicate-patient)
- Patient Identity Source records an Update as using a conditional create, so as to support update if exists else create.
- Build off of the IHE BasicAudit PatientUpdate event
- add the ITI-104 as a subtype
- client is Patient Identifier Source
- server is Patient Identifier Cross-reference Manager
- entity slices for patient are required
- filled with the identifier parameter value from the PUT
- will be an identifier, not a reference
- entity slice for the data
- filled with the body of the PUT
- will be the Patient resource presented
- entity slice for transaction is available |
| 15 | | Audit Event for Patient Identity Feed by the Source that Deletes a Patient | ihe.iti.pixm#current | R4 | Defines constraints on the AuditEvent Resource to record when a Patient Identity Feed Transaction happens, as recorded by the Patient Identity Source.
- This profile applies to the Patient Identity Source actor in
- [Remove Patient](ITI-104.html#2310443-remove-patient)
- Build off of the IHE BasicAudit PatientDelete event
- this will result in two .entity elements with the same logical information
- add the ITI-104 as a subtype
- client is Patient Identifier Source
- server is Patient Identifier Cross-reference Manager
- entity slices for patient are required
- filled with the identifier parameter value from the DELETE
- will be an identifier, not a reference
- entity slice for the data
- filled with the path of the DELETE
- will be the Patient resource id presented
- entity slice for transaction is available |
| 16 | | Audit Event for Patient Identity Feed FHIR by the Manager that Creates a Patient | ihe.iti.pixm#current | R4 | Defines constraints on the AuditEvent Resource to record when a Patient Identity Feed FHIR Transaction happens, as recorded by the Patient Identifier Cross-reference Manager.
- This profile applies to the Patient Identity Cross-reference Manager actor in
- [Add or Revise Patient](ITI-104.html#2310441-add-or-revise-patient)
- [Resolve Duplicate Patient](ITI-104.html#2310442-resolve-duplicate-patient)
- Patient Identity Cross-reference Manager knows the requested conditional create is a create, so records this as an create.
- Build off of the IHE BasicAudit PatientCreate event
- A generic FHIR server might not distinguish an ITI-104
- add the ITI-104 as a subtype
- server is Patient Identifier Source
- server is Patient Identifier Cross-reference Manager
- entity slices for patient are required
- filled with the identifier parameter value from the PUT
- will be an identifier, not a reference
- entity slice for the data
- filled with the body of the PUT
- will be the Patient resource presented
- entity slice for transaction is available |
| 17 | | Audit Event for Patient Identity Feed FHIR by the Manager that Updates a Patient | ihe.iti.pixm#current | R4 | Defines constraints on the AuditEvent Resource to record when a Patient Identity Feed FHIR Transaction happens, as recorded by the Patient Identifier Cross-reference Manager.
- This profile applies to the Patient Identity Cross-reference Manager actor in
- [Add or Revise Patient](ITI-104.html#2310441-add-or-revise-patient)
- [Resolve Duplicate Patient](ITI-104.html#2310442-resolve-duplicate-patient)
- Patient Identity Cross-reference Manager knows the requested conditional create is an update, so records this as an update.
- Build off of the IHE BasicAudit PatientUpdate event
- A generic FHIR server might not distinguish an ITI-104
- add the ITI-104 as a subtype
- server is Patient Identifier Source
- server is Patient Identifier Cross-reference Manager
- entity slices for patient are required
- filled with the identifier parameter value from the PUT
- will be an identifier, not a reference
- entity slice for the data
- filled with the body of the PUT
- will be the Patient resource presented
- entity slice for transaction is available |
| 18 | | Audit Event for PDQm Query at Consumer | ihe.iti.pdqm#current | R4 | Defines constraints on the AuditEvent (AuditMessage) Resource for a Patient Demographics Consumer to record when it performs a Patient Demographics Query [ITI-78](./ITI-78.html).
- Build off of the IHE BasicAudit Query event
- add the ITI-78 as a subtype
- client is Patient Demographics Consumer
- server is Patient Demographics Supplier
- entity slice for query are required
- entity slice for transaction is available
- entity for patient should be used when one patient is explicitly identified in the query parameters
- source is the client |
| 19 | | Audit Event for PDQm Query at Supplier | ihe.iti.pdqm#current | R4 | Defines constraints on the AuditEvent (AuditMessage) Resource when a Patient Demographics Supplier responds to a Patient Demographics Query [ITI-78](./ITI-78.html).
- Build off of the IHE BasicAudit Query event
- add the ITI-78 as a subtype
- client is Patient Demographics Consumer
- server is Patient Demographics Supplier
- entity slice for query are required
- entity slice for transaction is available
- entity for patient should be used when one patient is explicitly identified in the query parameters
- source is the server |
| 20 | | Audit Event for PIXm Query by the Consumer | ihe.iti.pixm#current | R4 | Defines constraints on the AuditEvent (AuditMessage) Resource to record when a PIXm Query Transaction happens, as recorded by the Patient Identifier Cross-reference Consumer.
- Build off of the IHE BasicAudit Patient Query event
- add the ITI-83 as a subtype
- client is Patient Identifier Cross-reference Consumer
- server is Patient Identifier Cross-reference Manager
- entity slice for query parameters
- eitity slice for a source patient identifier
- yes both entities likely say the same thing, but one is specifically the patient identifier, and the other is in query parameter format
- source is the client |
| 21 | | Audit Event for PIXm Query by the Manager | ihe.iti.pixm#current | R4 | Defines constraints on the AuditEvent (AuditMessage) Resource to record when a PIXm Query Transaction happens, as recorded by the Patient Identifier Cross-reference Manager.
- Build off of the IHE BasicAudit Patient Query event
- add the ITI-83 as a subtype
- client is Patient Identifier Cross-reference Consumer
- server is Patient Identifier Cross-reference Manager
- entity slice for query parameters
- eitity slice for a source patient identifier
- yes both entities likely say the same thing, but one is specifically the patient identifier, and the other is in query parameter format
- source is the server |
| 22 | | Audit Event for Privacy Disclosure at Source | ihe.iti.balp#current | R4 | 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) |
| 23 | | Audit Event for Provide Bundle Transaction at Recipient | ihe.iti.mhd#current | R4 | Defines constraints on the AuditEvent Resource to record when a Provide Bundle Transaction happens at the Recipient.
- Import event
- shall have source of itself
- shall have a document source agent
- shall have a document recipient agent
- may have user, app, organization agent(s)
- shall have a patient entity
- shall have a submission set identity entity |
| 24 | | Audit Event for Provide Bundle Transaction at Source | ihe.iti.mhd#current | R4 | Defines constraints on the AuditEvent Resource to record when a Provide Bundle Transaction happens at the Source.
- Export event
- shall have source of itself
- shall have a document source agent
- shall have a document recipient agent
- may have user, app, organization agent(s)
- shall have a patient entity
- shall have a submission set identity entity |
| 25 | | Audit Event for Query Code System Transaction by the Terminology Consumer and Repository for Query | ihe.iti.svcm#current | R4 | Defines constraints on the AuditEvent Resource to record when a Query Code System Transaction happens
to query a CodeSystem, as recorded by the Terminology Consumer and Registry. |
| 26 | | Audit Event for Query Code System Transaction by the Terminology Consumer and Repository for Read | ihe.iti.svcm#current | R4 | Defines constraints on the AuditEvent Resource to record when a Query Code System Transaction happens
to read a CodeSystem, as recorded by the Terminology Consumer and Registry. |
| 27 | | Audit Event for Query Concept Map Transaction by the Terminology Consumer and Repository for Query | ihe.iti.svcm#current | R4 | Defines constraints on the AuditEvent Resource to record when a Query Concept Map Transaction happens
to query a ConceptMap, as recorded by the Terminology Consumer and Registry. |
| 28 | | Audit Event for Query Concept Map Transaction by the Terminology Consumer and Repository for Read | ihe.iti.svcm#current | R4 | Defines constraints on the AuditEvent Resource to record when a Query Concept Map Transaction happens
to read a ConceptMap, as recorded by the Terminology Consumer and Registry. |
| 29 | | Audit Event for Query Value Set Transaction by the Terminology Consumer and Repository for Query | ihe.iti.svcm#current | R4 | Defines constraints on the AuditEvent Resource to record when a Query Value Set Transaction happens
to query a ValueSet, as recorded by the Terminology Consumer and Registry. |
| 30 | | Audit Event for Query Value Set Transaction by the Terminology Consumer and Repository for Read | ihe.iti.svcm#current | R4 | Defines constraints on the AuditEvent Resource to record when a Query Value Set Transaction happens
to read a ValueSet, as recorded by the Terminology Consumer and Registry. |
| 31 | | Audit Event for Request Care Services Updates Transaction by the Care Services Update Consumer and Care Services Update Supplier | medcom.sor.mcsd#current | R4 | Defines constraints on the AuditEvent Resource to record when a Request Care Services Updates Transaction happens
for a Care Services Resource updates, as recorded by the Care Services Update Supplier or Care Services Update Consumer. |
| 32 | | Audit Event for Retrieve Document Transaction at Document Consumer | ihe.iti.mhd#current | R4 | Defines constraints on the Document Consumer AuditEvent Resource to record when a Retrieve Document Transaction happens, as recorded by the Document Consumer.
- Build off of the IHE BasicAudit PatientRead event
- add the ITI-68 as a subtype
- client is Document Consumer
- server is Document Responder
- entity slices for data, and patient are required
- entity slice for transaction is available |
| 33 | | Audit Event for Retrieve Document Transaction at the Document Responder | ihe.iti.mhd#current | R4 | Defines constraints on the Document Responder AuditEvent Resource to record when a Retrieve Document Transaction happens, as recorded by the Document Responder.
- Build off of the IHE BasicAudit PatientRead event
- add the ITI-68 as a subtype
- client is Document Consumer
- server is Document Responder
- entity slices for data, and patient are required
- entity slice for transaction is available |
| 34 | | Audit Event for Retrieve File Transaction at File Consumer | ihe.iti.npfs#current | R4 | Defines constraints on the File Consumer AuditEvent Resource to record when a Retrieve File Transaction happens, as recorded by the File Consumer.
- Build off of the IHE BasicAudit Read event
- add the ITI-109 as a subtype
- client is File Consumer
- server is File Manager
- entity slices for data
- entity slice for transaction is available |
| 35 | | Audit Event for Retrieve File Transaction at the File Manager | ihe.iti.npfs#current | R4 | Defines constraints on the File Manager AuditEvent Resource to record when a Retrieve File Transaction happens, as recorded by the File Manager.
- Build off of the IHE BasicAudit Read event
- add the ITI-109 as a subtype
- client is File Consumer
- server is File Manager
- entity slices for data
- entity slice for transaction is available |
| 36 | | Audit Event for Search File Transaction at File Manager | ihe.iti.npfs#current | R4 | Defines constraints on the AuditEvent Resource to record when a Search File Transaction happens, as recorded by the File Manager.
- Build off of the IHE BasicAudit Query event
- add the ITI-88 as a subtype
- client is File Consumer
- server is File Manager
- entity slices for query
- entity slice for transaction is available |
| 37 | | Audit Event for Search File Transaction by the File Consumer | ihe.iti.npfs#current | R4 | Defines constraints on the AuditEvent Resource to record when a Search File Transaction happens, as recorded by the File Consumer.
- Build off of the IHE BasicAudit Query event
- add the ITI-88 as a subtype
- client is File Consumer
- server is File Manager
- entity slices for query
- entity slice for transaction is available |
| 38 | | Audit Event for Simplified Publish ITI-105 Transaction at Recipient | ihe.iti.mhd#current | R4 | Defines constraints on the AuditEvent Resource to record when a Simplified Publish ITI-105 Transaction happens at the Recipient.
- Build off of the IHE Basic Audit Patient Create event
- add the ITI-105 as a subtype
- client is the Document Source
- Server is the Document Recipient
- may have user, app, organization agent(s)
- shall have a patient entity
- shall have a documentReference identity entity |
| 39 | | Audit Event for Simplified Publish ITI-105 Transaction at Source | ihe.iti.mhd#current | R4 | Defines constraints on the AuditEvent Resource to record when a Simplified Publish ITI-105 Transaction happens at the Soure.
- Build off of the IHE Basic Audit Patient Create event
- add the ITI-105 as a subtype
- client is the Document Source
- Server is the Document Recipient
- may have user, app, organization agent(s)
- shall have a patient entity
- shall have a documentReference identity entity |
| 40 | | Audit Event for Submit File Transaction at Manager | ihe.iti.npfs#current | R4 | Defines constraints on the AuditEvent Resource to record when a Submit File Transaction happens at the Manager.
- Import event
- shall have source of itself
- shall have a File Source agent
- shall have a File Manager agent
- may have user, app, organization agent(s)
- shall have a DocumentReference identity entity |
| 41 | | Audit Event for Submit File Transaction at Source | ihe.iti.npfs#current | R4 | Defines constraints on the AuditEvent Resource to record when a Submit File Transaction happens at the Source.
- Export event
- shall have source of itself
- shall have a File Source agent
- shall have a File Manager agent
- may have user, app, organization agent(s)
- shall have a patient entity
- shall have a submission set identity entity |
| 42 | | Audit Event for Subscribe to Patient Updates Transaction by the Patient Identity Subscriber and Registry for Create | ihe.iti.pmir#current | R4 | Defines constraints on the AuditEvent Resource to record when a Subscribe to Patient Updates Transaction happens
to create a new subscription, as recorded by the Patient Identity Subscriber and Registry. |
| 43 | | Audit Event for Subscribe to Patient Updates Transaction by the Patient Identity Subscriber and Registry for Delete | ihe.iti.pmir#current | R4 | Defines constraints on the AuditEvent Resource to record when a Subscribe to Patient Updates Transaction happens
to delete a subscription, as recorded by the Patient Identity Subscriber and Registry. |
| 44 | | Audit Event for Subscribe to Patient Updates Transaction by the Patient Identity Subscriber and Registry for Read | ihe.iti.pmir#current | R4 | Defines constraints on the AuditEvent Resource to record when a Subscribe to Patient Updates Transaction happens
to read a subscription, as recorded by the Patient Identity Subscriber and Registry. |
| 45 | | Audit Event for Subscribe to Patient Updates Transaction by the Patient Identity Subscriber and Registry for Update | ihe.iti.pmir#current | R4 | Defines constraints on the AuditEvent Resource to record when a Subscribe to Patient Updates Transaction happens
to update a subscription, as recorded by the Patient Identity Subscriber and Registry. |
| 46 | | Audit Event for Translate Code Transaction by the Terminology Consumer and Repository | ihe.iti.svcm#current | R4 | Defines constraints on the AuditEvent Resource to record when a Translate Code Transaction happens
to translate a code using a ConceptMap, as recorded by the Terminology Consumer and Registry. |
| 47 | | Audit Event for Update DocumentReference Transaction at File Source | ihe.iti.npfs#current | R4 | Defines constraints on the File Source AuditEvent Resource to record when an Update DocumentReference Transaction happens, as recorded by the File Source.
- Build off of the IHE BasicAudit Update event
- add the ITI-89 as a subtype
- client is File Source
- server is File Manager
- entity slices for the DocumentReference reference
- entity slice for transaction is available |
| 48 | | Audit Event for Update DocumentReference Transaction at the File Manager | ihe.iti.npfs#current | R4 | Defines constraints on the File Manager AuditEvent Resource to record when a Update DocumentReference Transaction happens, as recorded by the File Manager.
- Build off of the IHE BasicAudit PatientRead event
- add the ITI-89 as a subtype
- client is File Source
- server is File Manager
- entity slices for DocumentReference reference
- entity slice for transaction is available |
| 49 | | Audit Event for Validate Code Transaction by the Terminology Consumer and Repository | ihe.iti.svcm#current | R4 | Defines constraints on the AuditEvent Resource to record when a Validate Code Transaction happens
to validate a code, as recorded by the Terminology Consumer and Registry. |
| 50 | | AuditEventIEHR | fhir.uv.crossborderdataexchange#current | R4 | |
| 51 | | Basic AuditEvent for a successful Create not related to a Patient | ihe.iti.balp#current | R4 | A basic AuditEvent profile for when a RESTful Create action happens successfully.
- Given a Resource Create is requested
- And that resource does not have a Patient subject or is otherwise associated with a Patient
- when the resource is Patient specific then [PatientCreate](StructureDefinition-IHE.BasicAudit.PatientCreate.html) is used
- And the request is authorized
- Authorization failures should follow [FHIR core Access Denied](http://hl7.org/fhir/security.html#AccessDenied)
- When successful
- Note a failure AuditEvent may follow this pattern, but would not be a successful outcome and should have an OperationOutcome
- Then the AuditEvent recorded will conform |
| 52 | | Basic AuditEvent for a successful Create with known Patient subject | ihe.iti.balp#current | R4 | 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
- And that resource has a Patient subject or is otherwise associated with a Patient
- And the request is authorized
- Authorization failures should follow [FHIR core Access Denied](http://hl7.org/fhir/security.html#AccessDenied)
- When successful
- Note a failure AuditEvent may follow this pattern, but would not be a successful outcome and should have an OperationOutcome
- Then the AuditEvent recorded will conform |
| 53 | | Basic AuditEvent for a successful Delete | ihe.iti.balp#current | R4 | A basic AuditEvent profile for when a RESTful Delete action happens successfully.
- Given a Resource Delete is requested
- And that resource has does not have a Patient subject or is otherwise associated with a Patient
- when the resource is Patient specific then [PatientDelete](StructureDefinition-IHE.BasicAudit.PatientDelete.html) is used
- And the request is authorized
- Authorization failures should follow [FHIR core Access Denied](http://hl7.org/fhir/security.html#AccessDenied)
- When successful
- Note a failure AuditEvent may follow this pattern, but would not be a successful outcome and should have an OperationOutcome
- Then the AuditEvent recorded will conform |
| 54 | | Basic AuditEvent for a successful Delete with Patient | ihe.iti.balp#current | R4 | 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 Delete is requested
- And that resource has a Patient subject or is otherwise associated with a Patient
- And the request is authorized
- Authorization failures should follow [FHIR core Access Denied](http://hl7.org/fhir/security.html#AccessDenied)
- When successful
- Note a failure AuditEvent may follow this pattern, but would not be a successful outcome and should have an OperationOutcome
- Then the AuditEvent recorded will conform |
| 55 | | Basic AuditEvent for a successful Operation | ihe.iti.svcm#current | R4 | A basic AuditEvent profile for when a RESTful Operation action happens successfully.
- Given a RESTful Operation is requested
- And the request is authorized
- Authorization failures should follow [FHIR core Access Denied](http://hl7.org/fhir/security.html#AccessDenied)
- When successful
- Note a failure AuditEvent may follow this pattern, but would not be a successful outcome and should have an OperationOutcome
- Note success may result in zero or more results. The number of results and the content of the results are not recorded.
- Then the AuditEvent recorded will conform
- The raw operation parameters is placed in the .contained element. The contained parameters enables preserving exactly what was requested, including possibly malicious patterns. This enables detection of malicious or malformed requests.
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. |
| 56 | | Basic AuditEvent for a successful Query | ihe.iti.balp#current | R4 | A basic AuditEvent profile for when a RESTful Query / Search action happens successfully.
- Given a RESTful Query is requested
- And the request does not have a Patient subject indicated
- The requestor logging the event would potentially not know they have requested Patient specific data
- The data objects may not be patient specific kind of objects
- when the request is Patient specific then [PatientQuery](StructureDefinition-IHE.BasicAudit.PatientQuery.html) is used
- And the request is authorized
- Authorization failures should follow [FHIR core Access Denied](http://hl7.org/fhir/security.html#AccessDenied)
- When successful
- Note a failure AuditEvent may follow this pattern, but would not be a successful outcome and should have an OperationOutcome
- Note success may result in zero or more results. The number of results and the content of the results are not recorded.
- And the results are not Patient specific
- when the results are Patient specific then [PatientQuery](StructureDefinition-IHE.BasicAudit.PatientQuery.html) are used
- Then the AuditEvent recorded will conform
- 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. |
| 57 | | Basic AuditEvent for a successful Query with Patient | ihe.iti.balp#current | R4 | 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 is requested
- And the request is for a Patient subject indicated
- The requestor includes a Patient id or identifier as a query parameter
- The requestor security context is limited to a given Patient identity
- And the request is authorized
- Authorization failures should follow [FHIR core Access Denied](http://hl7.org/fhir/security.html#AccessDenied)
- When successful
- Note a failure AuditEvent may follow this pattern, but would not be a successful outcome and should have an OperationOutcome
- Note success may result in zero or more results. The number of results and the content of the results are not recorded.
- Then the AuditEvent recorded will conform
- 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.
- And When multiple patient results are returned, 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. |
| 58 | | Basic AuditEvent for a successful Read | ihe.iti.balp#current | R4 | A basic AuditEvent profile for when a RESTful Read action happens successfully.
- Given a Resource Read is requested
- And that resource does not have a Patient subject or is otherwise associated with a Patient
- when the resource is Patient specific then [PatientRead](StructureDefinition-IHE.BasicAudit.PatientRead.html) is used
- And the request is authorized
- Authorization failures should follow [FHIR core Access Denied](http://hl7.org/fhir/security.html#AccessDenied)
- When successful
- Note a failure AuditEvent may follow this pattern, but would not be a successful outcome and should have an OperationOutcome
- Then the AuditEvent recorded will conform |
| 59 | | Basic AuditEvent for a successful Read with a Patient | ihe.iti.balp#current | R4 | 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 Read is requested
- And that resource has a Patient subject or is otherwise associated with a Patient
- And the request is authorized
- Authorization failures should follow [FHIR core Access Denied](http://hl7.org/fhir/security.html#AccessDenied)
- When successful
- Note a failure AuditEvent may follow this pattern, but would not be a successful outcome and should have an OperationOutcome
- Then the AuditEvent recorded will conform |
| 60 | | Basic AuditEvent for a successful Update | ihe.iti.balp#current | R4 | A basic AuditEvent profile for when a RESTful Update action happens successfully.
- Given a Resource Update is requested
- And that resource does not have a Patient subject or is otherwise associated with a Patient
- when the resource is Patient specific then [PatientUpdate](StructureDefinition-IHE.BasicAudit.PatientUpdate.html) is used
- And the request is authorized
- Authorization failures should follow [FHIR core Access Denied](http://hl7.org/fhir/security.html#AccessDenied)
- When successful
- Note a failure AuditEvent may follow this pattern, but would not be a successful outcome and should have an OperationOutcome
- Then the AuditEvent recorded will conform
- And where the server supports FHIR Versioning the AuditEvent should use the version specific id |
| 61 | | Basic AuditEvent for a successful Update with a Patient subject | ihe.iti.balp#current | R4 | 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 Update is requested
- And that resource has a Patient subject or is otherwise associated with a Patient
- And the request is authorized
- Authorization failures should follow [FHIR core Access Denied](http://hl7.org/fhir/security.html#AccessDenied)
- When successful
- Note a failure AuditEvent may follow this pattern, but would not be a successful outcome and should have an OperationOutcome
- Then the AuditEvent recorded will conform
- And where the server supports FHIR Versioning the AuditEvent should use the version specific id |
| 62 | | Basic AuditEvent pattern for oAuth Opaque | ihe.iti.balp#current | R4 | Used when access to the oAuth token, but want to log minimal details.
- oUser slice holds only the JWT ID |
| 63 | | Basic AuditEvent pattern for oAuth Opaque | ihe.iti.balp#current | R4 | Used when:
- only have an opaque oAuth token (e.g. clients).
- have access to the oAuth token, but want to log minimal details.
- oUser slice holds fragment of the opaque oAuth token
- record only the last 32 characters of the oAuth token to limit risk or replay
- presume 32 characters is enough to coorelate AuditEvent log entries |
| 64 | | Basic AuditEvent pattern for when an activity was authorized by an IUA access token | ihe.iti.balp#current | R4 | 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.
- Given an activity has occured
- And OAuth is used to authorize (both app and user)
- And the given activity is using http with authorization: bearer mechanism
- IUA - [3.72 Incorporate Access Token \[ITI-72\]](https://profiles.ihe.net/ITI/IUA/index.html#372-incorporate-access-token-iti-72)
- Bulk Data Access - [11. Presenting an Access Token to FHIR API](https://hl7.org/fhir/uv/bulkdata/authorization/index.html#presenting-an-access-token-to-fhir-api)
- SMART-app-launch - [7.1.5 Step 4: App accesses clinical data via FHIR API](http://hl7.org/fhir/smart-app-launch/index.html#step-4-app-accesses-clinical-data-via-fhir-api)
- [HL7 Security for Scalable Registration, Authentication, and Authorization (aka UDAP) ](http://hl7.org/fhir/us/udap-security/history.html) when it gets published
- When an AuditEvent is recorded for the activity
- Then that AuditEvent would follow this profile regarding recording the IUA access token details
- note: this profile records minimal information from the IUA access token, which presumes that use of the AuditEvent at a later time will be able to resolve the given information.
- client slice holds the application details
- This is likely replicated in other slices, but is consistently identified as the Application slice for ease of tracking all events caused by this client
- place the client_id into .who.identifier.value (system is not needed, but avaialble if you have a system)
- any network identification detail should be placed in .network (may be a IP address, or hostname)
- oUser slice holds the user details
- user id is recorded in the .who.identifier
- user id is also recorded in .name to be more easy searched
- if roles or purposeOfUse are known record them here
- the JWT ID is recorded in .policy. Expecting that during audit anaysis this ID can be looked up and dereferenced |
| 65 | | Basic AuditEvent pattern for when an activity was authorized by an SAML access token Comprehensive | ihe.iti.balp#current | R4 | 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 |
| 66 | | Basic AuditEvent pattern for when an activity was authorized by an SAML access token Minimal | ihe.iti.balp#current | R4 | 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. |
| 67 | | Basic AuditEvent pattern for when an Authorization permit is decided | ihe.iti.balp#current | R4 | 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 |
| 68 | | EHRS Functional Model - Record Lifecycle Events - AuditEvent | hl7.fhir.uv.ehrs-rle#current | R5 | Defines the elements to be supported within the AuditEvent resource in order to conform with the Electronic Health Record System Functional Model Record Lifecycle Event standard |
| 69 | | General Audit Event Requirements | hl7.fhir.uv.saner#current | R4 | Defines general constraints on the AuditEvent Resource. |
| 70 | | IHE IUA ITI-71 AuditEvent for a successful Get Access Token | ihe.iti.balp#current | R4 | 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 |
| 71 | | Slicing a Sliced Extension Profile | johnmoehrke.slicingslicedextension#current | R4 | Profile showing problems with slicing a sliced extension
- adds an extension *otherId* on .agent
- a slice on the *otherId* extension for *npi* and *prn*
- adds an extension on the *prn* slice for *otherIdName*
- a slice on .agent for for *user*
- a slice on .agent for *userorg* |