DICOM Supplement 95 - Audit Trail Messages - DICOM

This is a discussion on DICOM Supplement 95 - Audit Trail Messages - DICOM ; I am looking at implementing an Auditing System and was hoping that someone in this group could verify some of the things that I have discovered in my research and perhaps answer some questions. 1) It seems that there are ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: DICOM Supplement 95 - Audit Trail Messages

  1. DICOM Supplement 95 - Audit Trail Messages

    I am looking at implementing an Auditing System and was hoping that
    someone in this group could verify some of the things that I have
    discovered in my research and perhaps answer some questions.

    1) It seems that there are 3 separate documents that describe Security
    Auditing: Dicom Supplement 95, RFC 3881, and IHE ATNA. The IHE is built
    on top of the lexicon defined in DICOM and DICOM on top of that defined
    in RFC 3881.

    2) IHE had a provisional schema, but new implementations should use the
    RFC 3881 schema and perhaps provide a XSLT transform to map from the
    provisional schema to the one in RFC 3881.

    3) The IHE provisional schema looks like a nicer schema to use because
    it is more structured and presents a better domain interface. The one
    in RFC 3881 is more flexible.

    4) It seems that the concept of Organization is not well defined in the
    schema. RFC 3881 section 5.5.6 "Participant Object ID" states that the
    id field can be a composite data field. Does this mean if you want to
    scope, for instance a patient, by the organization then it would be
    something like org1\12345 (Organization\PatientID)? If so, then it
    seems the contents of this field would be implementation specific and
    not generally consumable. It seems there should be an "Issuer"
    attribute for scoping Participant Object ID's in a
    multi-organization/multi-RIS environment.

    5) If an implementation is both the Audit consumer and supplier and
    wants to pass around GUIDs for patients, procedures, etc., would the
    right thing to do be to add a ParticipantObjectDetail type/value pair
    that identifies the object in question?

    6) Why is there so little discussion of this standard in any groups?
    Are people waiting for it to be finalized before they implement it?


  2. Re: DICOM Supplement 95 - Audit Trail Messages

    ATNA essentially supercedes the Basic Security profile that was added
    in earlier versions of the IHE Radiology technical framework, which
    was implemented for various different IHE connectathons.

    The updated radiology-specific messages are now being defined in the
    IHE Audit Trail Option supplement. The public comment text of this is
    available at:

    http://www.ihe.net/tf/IHE_TF_Suppl_R...2005-02-21.pdf

    A draft for trial use should be out shortly.

    David

    jonny31415@yahoo.com wrote:

    > I am looking at implementing an Auditing System and was hoping that
    > someone in this group could verify some of the things that I have
    > discovered in my research and perhaps answer some questions.
    >
    > 1) It seems that there are 3 separate documents that describe Security
    > Auditing: Dicom Supplement 95, RFC 3881, and IHE ATNA. The IHE is built
    > on top of the lexicon defined in DICOM and DICOM on top of that defined
    > in RFC 3881.
    >
    > 2) IHE had a provisional schema, but new implementations should use the
    > RFC 3881 schema and perhaps provide a XSLT transform to map from the
    > provisional schema to the one in RFC 3881.
    >
    > 3) The IHE provisional schema looks like a nicer schema to use because
    > it is more structured and presents a better domain interface. The one
    > in RFC 3881 is more flexible.
    >
    > 4) It seems that the concept of Organization is not well defined in the
    > schema. RFC 3881 section 5.5.6 "Participant Object ID" states that the
    > id field can be a composite data field. Does this mean if you want to
    > scope, for instance a patient, by the organization then it would be
    > something like org1\12345 (Organization\PatientID)? If so, then it
    > seems the contents of this field would be implementation specific and
    > not generally consumable. It seems there should be an "Issuer"
    > attribute for scoping Participant Object ID's in a
    > multi-organization/multi-RIS environment.
    >
    > 5) If an implementation is both the Audit consumer and supplier and
    > wants to pass around GUIDs for patients, procedures, etc., would the
    > right thing to do be to add a ParticipantObjectDetail type/value pair
    > that identifies the object in question?
    >
    > 6) Why is there so little discussion of this standard in any groups?
    > Are people waiting for it to be finalized before they implement it?
    >


  3. Re: DICOM Supplement 95 - Audit Trail Messages

    Thanks very much for the info David.


+ Reply to Thread