Interface SelfInitializing

All Known Implementing Classes:
BalpAuditEvent, CreateAuditEvent, DeleteAuditEvent, ExportAuditEvent, FindDocumentListsConsumerAuditEvent, FindDocumentListsResponderAuditEvent, FindDocumentReferencesConsumerAuditEvent, FindDocumentReferencesResponderAuditEvent, ImportAuditEvent, PatientCreateAuditEvent, PatientDeleteAuditEvent, PatientQueryAuditEvent, PatientReadAuditEvent, PatientUpdateAuditEvent, PdqmConsumerAuditEvent, PdqmMatchConsumerAuditEvent, PdqmMatchSupplierAuditEvent, PdqmSupplierAuditEvent, PixmConsumerAuditEvent, PixmFeedCreateManagerAuditEvent, PixmFeedDeleteManagerAuditEvent, PixmFeedDeleteSourceAuditEvent, PixmFeedUpdateManagerAuditEvent, PixmFeedUpdateSourceAuditEvent, PixmManagerAuditEvent, ProvideBundleRecipientAuditEvent, ProvideBundleSourceAuditEvent, QueryAuditEvent, ReadAuditEvent, RetrieveDocumentConsumerAuditEvent, RetrieveDocumentResponderAuditEvent, SimplifiedPublishRecipientAuditEvent, SimplifiedPublishSourceAuditEvent, UpdateAuditEvent
public interface SelfInitializing
Common interface for AuditEvents that initialize themselves given a populated AuditMessage, i.e. that convert the ATNA audit record of a transaction into their own profiled shape instead of leaving it to the generic translation.

How much of that is generic is a matter of the FHIR version and of the profile, so it is not decided here: the FHIR-version-agnostic part of IPF cannot reference AuditEvent at all. The R4 implementations inherit theirs from the BALP pattern their profile derives from, in org.openehealth.ipf.commons.ihe.fhir.support.audit.model.

An implementation is instantiated per audit message by the FHIR serialization strategy, through a public no-arg constructor, and is not reused. What the constructor may set is what the profile fixes for every record of the transaction; everything derived from the concrete transaction belongs in initialize(AuditMessage).

Since:
5.3
Author:
Christian Ohr

  • Method Summary

    Modifier and Type
    Method
    Description
    void
    initialize(AuditMessage auditMessage)
    Populates this AuditEvent from the given audit message.
    default boolean
    supports(AuditMessage auditMessage)
    Whether this AuditEvent can represent the given audit message conformantly.

  • Method Details

    • initialize

      void initialize(AuditMessage auditMessage)
      Populates this AuditEvent from the given audit message. Called instead of the generic AuditMessage-to-AuditEvent translation, so everything the resulting resource is to carry has to be set here -- what the constructor fixes is only what the profile fixes.
      Parameters:
      auditMessage - the audit message of the transaction being audited

    • supports

      default boolean supports(AuditMessage auditMessage)
      Whether this AuditEvent can represent the given audit message conformantly. What it cannot represent must not be rendered as this profile at all -- a record claiming a profile it does not satisfy is worse than one translated generically -- so returning false here drops the message to the generic AuditMessage-to-AuditEvent translation.

      By default, only the outcome is examined. Most IHE transaction profiles build on a BALP pattern that fixes the outcome to success, so a failed transaction is not one of them; profiles that constrain the outcome without fixing it -- MHD's Provide Document Bundle, for instance -- override this. A required element the audit message does not carry is not a reason to refuse it: a mandatory patient that the transaction cannot determine, say, is recorded as explicitly absent instead, which keeps the record on the profile its transaction prescribes.

      Parameters:
      auditMessage - the audit message of the transaction being audited
      Returns:
      whether this AuditEvent may be used for it