Applying a Presentation Content Manifest for Signing Clinical Documents

Abstract

In this paper, we demonstrate how to digitally sign a content manifest of a presentable clinical document that contains multiple clinical data with presentations. Only one signature is needed for an entire clinical document with multiple data resources, which can reduce the computation time during signing and verifying processes. In the radiology field, a report may contain text descriptions, images, and annotations that are stored separately in different data resources. The manifest signature would be a proper means for integrity checking for all the clinical data within the manifest. The manifest signature can be extended with a trusted third party to add a digital time signature for long-term verifiability. The performance of the manifest signing compared with that of a traditional digital signing was evaluated. The new manifest signature can be used for signing different types of presentable clinical documents, such HL7 CDA documents and DICOM image reports.

Introduction

Several digital signature mechanisms have been developed, and most of them are based on public key cryptography under public key infrastructure (PKI) environment.¹ In order to implement the digital signature of electronic health records (EHR), some issues should be of concern, including integrity, authenticity, and long-term verifiability.^2,3 The digital signature specifications in the radiology domain have been addressed by Digital Imaging and Communication in Medicine (DICOM)⁴, Health Level 7 (HL7), and Integrating the Healthcare Enterprise (IHE).⁵ In the real world, an EHR may contain many different types of clinical data (text, image, waveform, etc.). For example, a radiology report may contain DICOM-formatted images and presentation states with diagnostic reports (HL7 Clinical Document Architecture (CDA)⁶ or DICOM PDF (Portable Document Format)⁷ format). The HL7 CDA is a document markup standard that specifies the structure and semantics of clinical documents as the Extensible Markup Language (XML) format for the purpose of exchange. DICOM PDF includes source DICOM image files as PDF attachments by a user-defined XML Forms Architecture (XFA).⁸

If the existing electronic signature standards are followed, the integration of different standards will cause lots of trouble when signing and verifying the signatures.⁹ Hollerbach et al. analyzed the different data formats in health care for conclusive and secure long-term archiving. They mentioned the lack of stability of data formats and also the heterogeneity of integration in the clinical field.¹⁰ On the other hand, DICOM only regulates the digital signature for single image and does not offer a suitable solution for multiple resources. A legal signed DICOM file must contain one digest and one digital signature. If a study contains hundreds of DICOM files or the Structure Report (SR) references many DICOM images, then the same number of digital signature is required. However, it is impractical to implement these lengthy signing and verifying processes in the real world due to high computation time demands. The implementation of DICOM-specified signature still has performance problems due to file numbers and huge file sizes.^11,12

Digital Signatures

The integrity and authenticity of digital data can be validated using a digital signature mechanism. A digest of the digital document is calculated from an irreversible one-way hash function. Hash checking of digital data is commonly used on the Internet to prevent unauthorized modification. The digital signature can be implemented by a combination of the hash algorithm and public-key cryptography such as the RSA (Rivest-Shamir-Adleman) algorithm¹³ to reduce the complexity of calculations. When RSA algorithm is used to calculate a digital signature, the signer encrypts the digest of the digital document with his/her own private key. The recipient with access to the public key of the signer may verify the digital signature. The security of the RSA algorithm is based on the difficulty of factoring large integers. Some studies have proposed digital signature mechanisms to provide the authenticity and integrity of clinical data in the radiology field.^14–16 Under PKI, it is possible to work with the certificate and a trusted third party (TTP) to process inter-institutional applications and achieve the long-term verifiability of EHR.¹⁷ Digital signatures are authorized for the clinical data to be accepted as the replacement for paper-based records.

Manifest Signature Mechanism

IHE adopts XML Advanced Electronic Signatures (XAdES) for signing and verifying clinical documents (either XML or non-XML data).⁵ XAdES is based on World Wide Web Consortium (W3C) XML Signature with XML-extended attributes for long-term verifications. The W3C XML Signature provides two mechanisms to sign multiple data resources: manifest signature and multiple signatures. In the first mechanism, the digest of each data resource is obtained, and the manifest consists of a list of digests. Only one signature is created from signing this manifest, and the signature with the manifest would be a proper means for integrity check for all the clinical data within this signed manifest. In the second mechanism, the multiple signatures are applied to a large number of documents. Each signature represents the specific data resource, as DICOM has suggested.

Inconsistent Presentation of EHR

Many clinical documents are presented in specific application, such as using a browser to present HL7 CDA data with Extensible Stylesheet Language Transformations (XSLT), which transforms the XML formatted document to HTML using a predefined XSLT style sheet¹⁸, or a DICOM viewer to display DICOM image with corresponding presentation objects. For example, if only the CDA document is signed, and not the XSLT style sheet, inconsistent presentation of CDA document will occur. The principle of implementing the electronic signature (both traditional digital signature and manifest signature) for presentable documents does not sign only the clinical data but also presentation.¹⁹ The signing range should contain all of the data related to the clinical data. If there is only signing of clinical data, incorrect or ambiguous display could happen when presenting the clinical document between the signer and the receiver.^20–22 Unfortunately, the manifest signature in IHE and W3C specifications does not clearly identify what presentation documents should be signed.

In this paper, we propose a new manifest signature architecture modified from IHE specifications to digitally sign the clinical data with its presentation. Only one signature represents the signature for an entire clinical document with multiple data, which can reduce the computation time during signing and verifying processes. We can clearly identify and manage the clinical documents that are signed in the content manifest. Based on previous work^23,24, we demonstrate how to use the content manifest for handling presentable radiology reports (CDA documents, DICOM objects, and HTML web pages) that are stored in a medical image content repository.

Methods

Proposed Manifest Architecture

The new manifest modified from the Sharable Content Object Reference Model (SCORM)²⁵ is used to define and access the resources. The proposed manifest-generating process is shown in Figure 1. The new manifest structure contains three parts: metadata M, organizations O_RG, and resources R_S. M is used to facilitate the discovery of the documents for exchange by following the IHE Cross-Enterprise Document Sharing (XDS) profile. O_RG is used to define and manage the documents in the manifest. R_S provides an index of all documents to query and retrieve by a resource mapping.

Fig 1.

Manifest-generating process.

In the manifest, there are N documents, D₁, D₂,..., D_N, needing to be signed. For each reference, is calculated. The symbol “^” means cascade. Ref(D_k) represents the reference of D_k. Information related to D_k is defined in ID(D_k), which describes the identifier and transform algorithm used. H(D_k) is the hash value of D_k, where H is a hash function such as Message-Digest Algorithm 5 (MD5), Secure Hash Algorithm 1 (SHA1), etc. The reference can provide document with well authenticated and authored and can check the identity of the author and authenticator of each document. The resources R_S, constructed by cascading N number of Ref(D_k), is defined as follows:

1

Figure 2 shows three examples of Ref(D_k) for different data types presented as XML. In Figure 2, the value in <Transform Algorithm> of the DICOM data object type is urn:oid:1.2.840.10008.1.2.1, which expresses the explicit little endian coding for DICOM; this attribute can deal with different data formats. In addition, it can be extended for multiple data formats defined by the user. We reconstructed the reference of metadata Ref(M), organizations O_RG, and Rs as the manifest M_D, defined as:

2

Fig 2.

An example of reference types of data formats. This example shows three reference types of Ref(D_k): DICOM data object, JPG image, and XML data. The value of “Transform Algorithm” means canonicalization, which is a process for converting XML data into a “standard” canonical representation.

Signing Process

The signing process is shown in Figure 3. Based on the RSA digital signature algorithm, using the signer’s private key P_r to encrypt H(M_D), the digest value of M_D, as the digital signature DS(M_D), we then defined the digital signature process as

3

where SIG is the signing process. The H(DS(M_D)) is calculated and sent to the time stamp authority (TSA). The TSA concatenates a timestamp T_SS to the H(DS(M_D)) and calculates the hash of this concatenation as H H(DS(M_D))||T_SS). The symbol “||” represents the concatenation process, and T_SS is the Greenwich Mean Time (GMT) timestamp which confirms the synchronized time. The H(H(DS(M_D))||T_SS) is encrypted by P_rTSA, which is the TSA’s private key as the qualified digital time signature TSA_SIG defined as:

4

Fig 3.

Digital signing and retrieving digital time signature process.

Performance Analysis

Assume the times required for hashing, signing, and digital time signature retrieval for document n are T_n, T_r, and S_n, respectively, where 1 ≤ n ≤ N. The signing time T_r is the same for each document. Since the timestamp retrieval time depends on the network status, here S_n is just for reference. If we create digital signature for each document one by one, the total calculation time is

5

However, using the method proposed in this study, the total time will be reduced to

6

T_M and T_MD are the times for hashing metadata and manifest, respectively. The number of calculations needed for verification process is also reduced from 3N to N + 4.

Results

We demonstrated an example of a radiology report containing viewing settings, textual reports, image references, and annotations to be signed using the manifest signature. The radiology report containing several files to present the results of visualization on a web browser is shown in Figure 4. We reconstructed Ref(D_n) for each file, and created manifest M_D presented as the XML format, as shown in Figure 5. The O_RG included four items to identify the clinical documents: discharge note, diagnostic image report, image result, and DICOMDIR. Each item had a resource list to identify the URIs and hash values of resource data in the item. The clinical data were the Admission.htm, CDA_Report.xml, serimg00001L.jpg, and serimg00002L.jpg, which were converted from the original DICOM file. The CDA_Report.xml was modified from the IHE Simple Image and Numeric Report (SINR). The presentation states were Manifest.xsl, CDA_Report.xsl, CreateSilverlight.js, and Silverlight.js; the annotations were presented by Ann.xaml, which was created from Microsoft Silverlight component. The study images were stored as DICOMDIR.

Fig 4.

The display of a radiology report on a web browser. This radiology report includes discharge note, diagnostic image report, and image results. In this 43-year-old male, an 8-cm firm mass was found over the left level II area and a 2-cm mass over the left level V area. Irregular surface over left nasopharynx area was noted. Magnetic resonance imaging of head and neck before and after intravenous gadolinium injection was performed. All records were de-identified before disclosure.

Fig 5.

An example of manifest structure of a radiology report presented as XML. The discharge note, diagnostic image report, image results, and DICOMDIR are managed by O_RG using Items, Item001 to Item004, respectively. Each Item refers to the data in the R_s using the attribute identifierefr: Src001 to Src004. For example, Item004 of O_RG represents the DICOMDIR, and the images are mapped from <resource identifier=“Src004”″> in the R_s.

Performance Analysis

We used the Taiwan Health Professional Card (HPC) with a smart card-based certificate to deal with the cryptography. The average time of one RSA encryption process for 128- or 160-bit digest was about 1.3 s. A Windows PC with Pentium 4 2.0 GHz and 1 GB memory was chosen for demonstrating the results. Figure 6 illustrates the calculation time dependence on the size of the file by using two methods: RSA-MD5 and RSA-SHA1. Figure 7 shows a comparison of the operation time for testing files by one-by-one method (multiple digital signatures) and the manifest method. From the figure, we can find that the time for digital signing was a nearly linear dependence on the number of the files. The differences in calculation time by using the manifest method in three different file sizes (515 KB, 10 MB, and 20 MB) are not obviously different. In the experimental results, the number of files was the most important factor to determine the performance, not file size. Due to the number of RSA encryption process reduced from N to 1, the time needed for the manifest method was much lower than that of one-by-one method.

Fig 6.

Performance of signing computation.

Fig 7.

Performance of digital signing using one-by-one and manifest methods with different file sizes.

The Health Certificate Authority Timestamping Authority (HCA-TSA) provides the timestamp service as the TTP. We retrieved the digital time signature from the Health Information Network through the Taiwan Academic Network. Figure 8 illustrates the time distribution of retrieving the digital time signature from HCA-TSA continuously during 1 month period.

Fig 8.

The time distribution of retrieving digital time signature from HCA-TSA. The total retrieval numbers were 3,272, including 17 errors due to the failure of connection. The average time was 1.40 s.

An Example of Inconsistent Presentation

In Figures 4 and 5, the CDA_Report.xml was signed as required and the transformation of presentation was defined in the CDA_Report.xsl. This example illustrates how modifying the presentation data could change the meaning of a clinical document. For example, the gender information (male) in CDA_Report.xml is

• <administrativeGenderCode codeSystem=“2.16.840.1.113883.5.1”code=“M”/>

The XSLT transformation expressions in CDA_Report.xsl

• <xsl:variable name=“sex” select=“administrativeGenderCode/@code”/>

• <xsl:when test=“$sex=‘M’”> Male </xsl:when>

• <xsl:when test=“$sex=‘F’”> Female </xsl:when>

transform the value “M” or “F” to “Male” or “Female”, respectively. If “Female” and “Male” were interchanged in the above expressions, the patient’s sex is changed to female and that is not the correct result, although the original CDA document is not changed.

Discussion

Further characteristics of many EHR formats is the ability to include various components to reconstruct dynamic content in display. Inconsistent presentation of EHR between author and reader is normally caused by the transformation processes. One explanation for this is that the transformation processes were not protected. The transformation processes of EHR obviously should be protected as well as the clinical data if all of these data are protected well under a trusted infrastructure (i.e., PKI). This concept is described in W3C XML Signature as follows:

This recommendation applies to transforms specified within the signature as well as those included as part of the document itself.

In general, most of the medical information standards and national regulations regulating the legal EHR do not consider the presentation problem. The signing range should contain all of the data related to clinical data. If only clinical data is signed and not presentation data, the inconsistent presentation of EHR could happen when presentation data is being modified. There is also some potential risk that the application may be threatened by certain attacks (e.g., phishing, viruses, and Trojan horses). If following different digital signature specifications in the health care domain, the practice will cause lots of trouble. Therefore, a unique signature standard for handling all the clinical data is required.

DICOM suggested composing radiology reports directly in clinical document architecture (CDA) format. DICOM has addressed the digital signature issue of Structure Report (SR), which collects references to a set of related objects into a key object (KO) with digital signatures (i.e., signed KO document). The signed KO document refers to the set of DICOM data objects by using the signed manifest, which means a signed list of multiple digital signatures. It needs many files to construct the presentation of a radiology report. It also requires multiple signatures to secure multiple data format and standards. The performance problem is still not solved in this architecture. If following the existing standards such as DICOM and HL7 to sign radiology report with many files, a great number of digital signatures and digital time signatures are required. It is impractical due to the high computational time of the signing and verifying processes in real-world clinical operations. Fast and reliable proof of authenticity and integrity is needed for security considerations when implementing the digital signature. The manifest signature architecture needs only one signature to represent the signature for an entire clinical document with multiple data, which can reduce the computation time during signing and verifying processes.

Conclusion

Digital signature can provide the authenticity and integrity for digital data, since cryptographic techniques can be algorithmically proven in the radiology field. However, there are many weak points in the processes of digitally signing and verifying data, like the presentation problem and performance issues. How to integrate the multiple data formats and standards becomes an important issue. The manifest signature can provide the framework for handling all clinical data and specifications to realize the security requirements under a trusted relationship. It also can be extended to add the digital timestamp and digital time signature for long-term verifiability. We also addressed the issue of performance during digital signing and verifying. The computational time of the manifest signature is much lower than that of the traditional digital signature method. Following the existing medical information digital signature rules in DICOM, the practice is not feasible. Using the proposed method, the computational time is reduced.