Annex W Digital Signatures in Structured Reports Use Cases (Informative)

The scenarios in which Digital Signatures would be used in DICOM Structured Reports include, but are not limited to the following.

Case 1: Human Signed Report and Automatically Signed Evidence.

  1. The archive, after receiving an MPPS complete and determining that it has the complete set of objects created during an acquisition procedure step, creates a signed Key Object Selection Document Instance with secure references to all of the DICOM composite objects that constitute the exam. The Document would include a Digital Signature according to the Basic SR Digital Signatures Secure Use Profile with the Digital Signature Purpose Code Sequence (0400,0401) of (14,ASTM-sigpurpose,”Source Signature“). It would set the Key Object Selection Document Title of that Instance to (113035,DCM, “Signed Complete Acquisition Content”). Note that the objects that are referenced in the MPPS may or may not have Digital Signatures. By creating the Key Object Selection Document Instance, the archive can in effect add the equivalent of Digital Signatures to the set of objects.

  2. A post-processing system generates additional evidence objects, such as measurements or CAD reports, referring to objects in the exam. This post-processing system may or may not include Digital Signatures in the evidence objects, and may or may not be included as secure references in a signed Key Object Selection Document.

  3. Working at a reporting station, a report author gathers evidences from a variety of sources, including those referenced by the Key Object Selection Document Instance and the additional evidence objects generated by the post-processing system, and incorporates his or her own observations and conclusions into one or more reports.

  4. It is desired that all evidence references from a DICOM SR be secure. The application creating the SR may either:

  5. create secure references by copying a verified Digital Signature from the referenced object or by generating a MAC code directly from the referenced object,

  6. make a secure reference to a signed Key Object Selection Document that in turn securely references the SOP Instances, or

  7. copy the secure reference information from a trusted Key Object Selection Document to avoid the overhead of recalculating the MAC codes or revalidating the reference Digital Signatures.

  8. When the author completes a DICOM SR, the system, using the author’s X.509 Digital Signature Certificate generates a Digital Signature with the Digital Signature Purpose Code Sequence (0400,0401) of (1,ASTM-sigpurpose,”Author Signature“) for the report.

  9. The author’s supervisor reviews the DICOM SR. If the supervisor approves of the report, the system sets the Verification Flag to “VERIFIED” and adds a Digital Signature with the Digital Signature Purpose Code Sequence (0400,0401) of (5,ASTM-sigpurpose,”Verification Signature“) or (6,ASTM-sigpurpose,”Validation Signature“) using the supervisor’s X.509 certificate.

  10. At some later time, someone who is reading the DICOM SR SOP Instance wishes to verify its authenticity. The system would verify that the Author Signature, as well as any Verification or Validation Signature present are intact (i.e., that the signed data has not been altered based on the recorded Digital Signatures, and that the X.509 Certificates were valid at the time that the report was created).

  11. If the report reader wishes to inspect DICOM source materials referenced in a DICOM SR, the system can insure that the materials have not been altered since the report was written by verifying the Referenced Digital Signatures or the Referenced SOP Instance MAC that the report creator generated from the referenced materials.

Case 2: Cross Enterprise Document Exchange

  1. An application sends by any means a set of DICOM composite objects to an entity outside of the institutional environment (e.g. for review by a third party).

  2. The application creates a signed Key Object Selection Document Instance with a Key Object Selection Document Title of (113031,DCM, “Signed Manifest”) referencing the set of DICOM Data Objects that it sent outside the institutional environment, and sends that SR to the external entity as a shipping manifest.

  3. The external entity may utilize the Key Object Selection SR SOP Instance to confirm that it received all of the referenced objects intact (i.e., without alterations). Because the signed Key Object Selection Instance must use secure references, it can verify that the objects have not been modified.

Annex X Dictation-Based Reporting with Image References (Informative)

This Annex describes a use of Key Object Selection (KO) and Grayscale Softcopy Presentation State (GSPS) SOP Instances, in conjunction with a typical dictation/transcription process for creating an imaging clinical report. The result is a clinical report as a Basic Text Structured Report (SR) SOP Instance that includes annotated image references (see section X.2). This report may also (or alternatively) be encoded as an HL7 Clinical Document Architecture (CDA) document (see section X.3).

Similar but more complex processes that include, for instance, numeric measurements and Enhanced or Comprehensive SR, are not addressed by this Annex. This Annex also does not specifically address the special issues associated with reporting across multiple studies (e.g., the “grouped procedures” case).

X.1 Basic Data Flows

X.1.1 Dictation/Transcription Reporting

During the softcopy reading of an imaging study, the physician dictates the report, which is sent to a transcription service or is processed by a voice recognition system. The transcribed dictation arrives at the report management system (typically a RIS) by some mechanism not specified here. The report management system enables the reporting physician to correct, verify, and “sign” the transcribed report. See Figure X.1-1. This data flow applies to reports stored in a proprietary format, reports stored as DICOM Basic Text SR SOP Instances, or reports stored as HL7 CDA instances.

[pic]

Figure X.1-1 Dictation/Transcription Reporting Data Flow

The report management system has flexibility in encoding the report title. For example, it could be any of the following:

There are LOINC codes associated with each of these types of titles, if a coded title is used on the report (see PS3.16 CID 7000).

The transcribed dictation may be either a single text stream, or a series of text sections each with a title. Division of reports into a limited number of canonically named sections may be done by the transcriptionist, or automated division of typical free text reports may be possible with voice recognition or a natural language processing algorithm.

For an electronically stored report, the signing function may or may not involve a cryptographic digital signature; any such cryptographic signature is beyond the scope of this description.

X.1.2 Reporting with Image References

To augment the basic dictation/transcription reporting use case, it is desired to select significant images to be attached (by reference) to the report. During the softcopy reading, the physician may select images from those displayed on his workstation (e.g., by a point-and-click function through the user interface). The selection of images is conveyed to the image repository (PACS) through a DICOM Key Object Selection (KO) document. When the report management system receives the transcribed dictation, it queries the image repository for any KO documents, and appends the image references from the KO to the transcription. In this process step, the report management system does not need to access the referenced images; it only needs to copy the references into the draft report. The correction and signature function potentially allows the physician to retrieve and view the referenced images, correct and change text, and to delete individual image references. See Figure X.1-2.

[pic]

Figure X.1-2 Reporting Data Flow with Image References

The transcribed dictation must have associated with it sufficient key attributes for the report management system to query for the appropriate KO documents in the image repository (e.g., Study ID, or Accession Number).

Each KO document in this process includes a specific title “For Report Attachment”, a single optional descriptive text field, plus a list of image references using the SR Image Content Item format. The report management system may need to retrieve all KO documents of the study to find those with this title, since the image repository might not support the object title as a query return key.

Multiple KO instances may be created for a study report, e.g., to facilitate associating different descriptive text (included in the KO document) with different images or image sets. All KOs with the title “For Report Attachment” in the study are to be attached to the dictated report by copying their content into the draft report (see sections X.2 and X.3). (There may also be KOs with other titles, such as “For Teaching”, that are not to be attached to the report.)

The nature of the image reference links will differ depending on the format of the report. A DICOM SR format report will use DICOM native references, and other formats may use a hyperlink to the referenced images using the Web Access to DICOM Persistent Objects (WADO) service (see PS3.18).

X.1.3 Reporting with Annotated Images

The KO also allows the referencing of a Grayscale Softcopy Presentation State (GSPS) instance for each selected image. A GSPS instance can be created by the workstation for annotation (“electronic grease pencil”) of the selected image, as well as to set the window width/window level, rotation/flip, and/or display area selection of the image attached to the report. The created GSPS instances are transferred to the image repository (PACS) and are referenced in the KO document.

As with image references, the report management system may include the GSPS instance references in the report. When the report is subsequently displayed, the reader may retrieve the referenced images together with the referenced GSPS, so that the image is displayed with the annotations and other GSPS display controls. See Figure X.1-3.

Note that the GSPS display controls can also be included in WADO hyperlinks and invoked from non-DICOM display stations.

[pic]

Figure X.1-3 Reporting Data Flow with Image and Presentation/Annotation References

X.2 Transcribed Diagnostic Imaging SR Instance Content

This section describes the use of transcribed dictation and Key Object Selection (KO) instances to produce a DICOM Basic Text SR instance. A specific SR Template, TID 2005 (see PS3.16), is defined to support transcribed diagnostic imaging reports created using this data flow.

X.2.1 SR Header Content

The attributes of the Patient and Study Modules will be identical to those of the Study being reported. The following information is encoded in the SR Document General Module:

X.2.2 Transcribed Text Data Format

The transcribed dictation is used to populate one or more section containers in the content tree of the SR Instance. If the transcription consists of a single undifferentiated text stream, it will typically be encoded using a single CONTAINER content item with Concept Name “Findings”, and the text encoded as the value in a subsidiary TEXT content item with Concept Name “Finding”. When the transcription is differentiated into multiple sections with captions, e.g., using the concepts in CID 7001 (see PS3.16), each section may be encoded in a separate CONTAINER, with the concept from CID 7001 as the container Concept Name, and the corresponding term from CID 7002 as the Concept Name for a subsidiary TEXT content item. See Figure X.2-1.

[pic]

Figure X.2-1 Transcribed Text Content Tree

X.2.3 Image Reference Format

The content items from each associated KO object will be included in the SR in a separate CONTAINER with Concept Name (121180, DCM, “Key Images”). The text item “Key Object Description” and all image reference items shall be copied from the KO content tree to the corresponding SR container. See Figure X.2-2.

[pic]

Figure X.2-2 Inputs to SR Basic Text Object Content Tree

The KO and SR IMAGE content item format allows the encoding of an icon (image thumbnail) with the image reference, as well as a reference to a GSPS instance controlling image presentation. Whether or not to include icons or GSPS references is an implementation decision of the softcopy review station that creates the KO; the IMAGE content item as a whole may be simply copied by the report management system from the KO to the Basic Text SR instance.

The intended process is that all KOs “For Report Attachment” are to be automatically included in the draft report. Therefore, the correction and signature function of the report management system should allow the physician to delete image references that were included, perhaps unintentionally, by the automatic process.

X.3 Transcribed Diagnostic Imaging CDA Instance Content

This section describes the use of transcribed dictation and Key Object Selection (KO) documents to produce an HL7 Clinical Document Architecture (CDA) Release 2 document.

Note: While this section describes encoding as CDA Release 2, notes are provided about encoding issues for CDA Release 1.

X.3.1 CDA Header Content

The header of the CDA instance includes:

Note: The markup components in CDA Release 1 use different names.

X.3.2 Transcribed Text Content

Each transcription section can be encoded in a Section in the CDA document. The Section.Code and/or Section.Title can be derived from the corresponding transcription section title, if any. Although the transcription text can be encoded in the Section.Text without further markup, it is recommended that it be enclosed in <paragraph> tags.

X.3.3 Image References

Images are referenced using hypertext links in the narrative text. These links in CDA are not considered part of the attested content.

Notes: 1. The primary use case for this Annex is the dictation/transcription reporting model. In the historical context of that model, the images (film sheets) are usually not considered part of the attested content of the report, although they are part of the complete exam record. I.e., the report is clinically complete without the images, and the referenced images are not formally part of the report. Therefore, this Annex discusses only the use of image references, not images embedded in the report.

2. Being part of the attested content would require the images to be displayed every time the report is displayed – i.e., they are integral to understanding the report. If the images are attested, they must also be encapsulated with the CDA package. I.e., the CDA document itself is only one part of the interchanged package; the referenced images must also always be sent with the CDA document. If the images are for reference only and not attested, the Image Content Item may be transformed to a simple hypertext link; it is then the responsibility of CDA document receiver to follow or not follow the hyperlink. Moreover, as the industry moves toward ubiquitous network access to a distributed electronic healthcare record, there will be less need to prepackage the referenced images with the report.

In the current use case, there will be one or more KO instances with image references. Each KO instance can be transformed to a Section in the CDA document with a Section.Title “Key Images”, and a Section.Code of 121180 from the DICOM Controlled Terminology (see PS3.16). If the KO includes a TEXT content item, it can be transformed to <paragraph> data in that Section.Text of the CDA document. Each IMAGE content item can be transformed to a link item using the <linkHtml> markup.

Within the <linkHtml> markup, the value of the href attribute is the DICOM object reference as a Web Access to Persistent DICOM Objects (WADO) specified URI (see Table X.3-1).

Notes: 1. When a DICOM object reference is included in an HL7 CDA document, it is presumed the recipient would not be a DICOM application; it would have access only to general Internet network protocols (and not the DICOM upper layer protocol), and would not be configured with the means to display a native DICOM image. Therefore, the recommended encoding of a DICOM Object Reference in the CDA narrative block <linkHtml> uses WADO for access by the HTTP/HTTPS network protocol (see PS3.18), using one of the formats broadly supported in Web browsers (image/jpeg or video/mpeg) as the requested content type.

2. In CDA Release 1, the markup tag for hyperlinks is <link_html> within the scope of a <link> tag.

Table X.3-1 WADO Reference in an HL7 CDA <linkHtml>

WADO Component Source
<scheme>://<authority>/<path> Configuration setting, used by the conversion process, identifying the WADO server
?requestType=WADO Fixed
&studyUID=<uid> Study Instance UID for referenced image obtained from the Current Requested Procedure Evidence Sequence or the Pertinent Other Evidence Sequence in the KO Instance
&seriesUID=<uid> Series Instance UID for referenced image obtained from the Current Requested Procedure Evidence Sequence or the Pertinent Other Evidence Sequence in the KO Instance
&objectUID=<uid> Referenced SOP Instance UID from IMAGE content item
&frameNumber=<list> Referenced Frame Number from IMAGE content item (if present)
&presentationUID=<uid> Referenced SOP Instance UID from Referenced SOP Sequence within IMAGE content item
&presentationSeriesUID=<uid> Series Instance UID for referenced presentation state obtained from the Current Requested Procedure Evidence Sequence or the Pertinent Other Evidence Sequence in the KO Instance
&contentType=video/mpeg Present if Referenced SOP Class UID from IMAGE content item is for a multi-frame image IOD

Notes: 1. Literal strings are in normal typeface, while <italic typeface within angle brackets> indicates values to be copied from the identified source.

2. The default contentType for single frame images is image/jpeg, which does not need to be specified as a WADO component. However, the default contentType for multiple frame images is application/dicom, which needs to be overridden with the specific request for video/mpeg.

3. There is not yet a standard mechanism for minimizing the potential for staleness of the <scheme> :// <authority> / <path> component.

X.3.4 Icons

If the IMAGE content item includes an Icon Image Sequence, the report creation process may embed the icon in the Section.Text narrative. The Icon Image Sequence Pixel Data is converted into an image file, e.g., in JPEG or GIF format, and base64 encoded. The file is encoded in an ObservationMedia entry in the CDA instance, and a <renderMultimedia> tag reference to the entry is encoded in the Section.Text adjacent to the <linkHtml> of the image reference.

X.3.5 Structured Entries

The Current Requested Procedure Evidence Sequence (0040,A375) of the KO instance lists all the SOP Instances referenced in the IMAGE content items in their hierarchical Study/Series/Instance context. It is recommended that this list be transcoded to CDA Entries in a Section with Section.Title “DICOM Object Catalog” and a Section.Code of 121181 from the DICOM Controlled Terminology (see PS3.16).

Notes: 1. Structured Entries are not defined in CDA Release 1.

2. Since the image hypertext links in the Section narrative may refer to both an image and a softcopy presentation state, as well as possibly being constrained to specific frame numbers, in general there is not a simple mapping from the <linkHtml> to an entry. Therefore it is not expected that there would be ID reference links between the <linkHtml> and related entries.

The purpose of the Structured Entries is to allow DICOM-aware applications to access the referenced images in their hierarchical context.

The encoding of the DICOM Object References in CDA Entries is shown in Figure X.3-1 and Tables X.3-2 through X.3-6. All of the mandatory data elements for the Entries are available in the Current Requested Procedure Evidence Sequence; optional elements (e.g., instance datetimes) may also be included if known by the encoding application.

[pic]

Figure X.3-1 CDA Section with DICOM Object References

Note: The format of Figure X.3-1 follows the conventions of HL7 v3 Reference Information Model diagrams.

Table X.3-2 DICOM Study Reference in an HL7 v3 Act (CDA Act Entry)

Attribute Data Type Multiplicity Value
classCode CS 1..1 ACT
moodCode CS 1..1 EVN
id II 1..1 <Study Instance UID (0020,000D) as root property with no extension property>
code CD 1..1 <113014 as code property, 1.2.840.10008.2.16.4 as codeSystem property, DCM as codeSystemName property, “DICOM Study” as displayName property>
text ST 0..1 <Study Description (0008,1030)>
effectiveTime TS 0..1 <Study Date (0008,0020) and Study Time (0008,0030)>

Table X.3-3 DICOM Series Reference in an HL7 v3 Act (CDA Act Entry)

Attribute Data Type Multiplicity Value
classCode CS 1..1 ACT
moodCode CS 1..1 EVN
id II 1..1 <Series Instance UID (0020,000E) as root property with no extension property>
code CD 0..1 <113015 as code property, 1.2.840.10008.2.16.4 as codeSystem property, DCM as codeSystemName property, “DICOM Series” as displayName property, Modality as qualifier property (see text and Table X.3-4)>
text ST 0..1 <Series Description (0008,103E)>
effectiveTime TS 0..1 <Series Date (0008,0021) and Series Time (0008,0031)>

The code for the Act representing a Series uses a qualifier property to indicate the modality. The qualifier property is a list of coded name/value pairs. For this use, only a single list entry is used, as described in Table X.3-4.

Table X.3-4 Modality Qualifier for the Series Act.Code

Property Data Type Value
name CV <121139 as code property, 1.2.840.10008.2.16.4 as codeSystem property, DCM as codeSystemName property, “Modality” as displayName property>
value CD <Modality (0008,0060) as code property, 1.2.840.10008.2.16.4 as codeSystem property, DCM as codeSystemName property, Modality code meaning (from PS3.16) as displayName property>

Table X.3-5 DICOM Composite Object Reference in an HL7 v3 Act (CDA Observation Entry)

Attribute Data Type Multiplicity Value
classCode CS 1..1 DGIMG
moodCode CS 1..1 EVN
id II 1..1 <SOP Instance UID (0008,0018) as root property with no extension property>
code CD 1..1 <SOP Class UID (0008,0016) as code property, 1.2.840.10008.2.6.1 as codeSystem property, DCMUID as codeSystemName property, SOP Class UID Name (from PS3.6) as displayName property>
text ED 0..1 <application/DICOM as mediaType property, WADO reference (see Table X.3-6) as reference property>
effectiveTime TS 0..1 <Content Date (0008,0023) and Content Time (0008,0033)>

Notes: 1. The DGIMG class is used to reference all DICOM Composite Instances, not just diagnostic images.

2. The Observation.Text reference property may alternatively use a DICOM protocol based URI, rather than WADO, should such a URI be defined.

Table X.3-6 WADO Reference in an HL7 DGIMG Observation.Text

WADO Component Source
<scheme>://<authority>/<path> Configuration setting, used by the conversion process, identifying the WADO server
?requestType=WADO Fixed
&studyUID=<uid> Study Instance UID for referenced instance
&seriesUID=<uid> Series Instance UID for referenced instance
&objectUID=<uid> SOP Instance UID for referenced instance
&contentType=application/DICOM Fixed

X.4.3 Using the WADO Reference for DICOM Network Protocol Retrievals

An application that receives a CDA with image references, and is capable of using the full services of DICOM upper layer protocol directly, can use the WADO parameters in either the linkHtml or in the DGIMG Observation.Text to retrieve the object using the DICOM network services. Such an application would need to be pre-configured with the hostname/IP address, TCP port, and AE Title of the DICOM object server (C-MOVE or C-GET SCP); this network address is not part of the WADO string. (Note that pre-configuration of this network address is typical for DICOM applications, and is facilitated by the LDAP-based DICOM Application Configuration Management Profile; see PS3.15.)

The application would open a Query/Retrieve Service Association with the configured server, and send a C-MOVE or C-GET command using the study, series, and object instance UIDs identified in the WADO query parameters. Such an application might also reasonably query the server for related objects, such as Grayscale Softcopy Presentation State.

Note: When using the C-GET service, the retrieving application needs to specify and negotiate the SOP Class of the retrieved objects when it opens the Association. This information is not available in the linkHtml WADO reference; however, it is available in the DGIMG Observation.Code. It may also be obtained from the configured server using a C-FIND query on a prior Association.

X.4 SIMULTANEOUS SR and CDA Instance Creation

The report may be created as both an SR instance and a CDA instance. In this case, the two instances are equivalent, and can cross-reference each other.

X.4.1 Equivalence

The CDA Document shall contain clinical content equivalent to the SR Document.

Note: The HL7 CDA standard specifically addresses transformation of documents from a non-CDA format. The requirement in the CDA specification is: “A proper transformation must ensure that the human readable clinical content of the report is not impacted.”

There is no requirement that the transform or transcoding between DICOM SR and HL7 CDA be reversible. In particular, some attributes of the DICOM Patient, Study, and Series IEs have no corresponding standard encoding in the HL7 CDA Header, and vice versa. Such data elements, if transcoded, may need to be encoded in “local markup” (in HL7 CDA) or private data elements (in DICOM SR) in an implementation-dependent manner; and some such data elements may not be transcoded at all. It is a responsibility of the transforming application to ensure clinical equivalence.

Many attributes of the SR Document General Module can be transcoded to CDA Header participations or related acts.

X.4.2 Document Cross-Reference

Due to the inherent differences between DICOM SR and HL7 CDA, a transcoded document will have a different UID than the source document. However, the SR Document may reference the CDA Document as equivalent using the Equivalent CDA Document Sequence (0040,A090) attribute, and the CDA Document may reference the SR Document with a relatedDocument act relationship.

Since the ParentDocument target of the relatedDocument relationship is constrained to be a simple DOCCLIN act, it is recommended that the reference to the DICOM SR be encoded per Table X.3-4, without explicit identification of the Study and Series Instance UIDs, and with classCode DOCCLIN (rather than DGIMG).

Notes: 1. The Study and Series Instance UIDs would be encoded in the WADO reference in the Act.Text ED data type.

2. CDA Release 1 does not provide a standard for the relatedDocument relationship to another document.