A Study of Secure Document Sharing System for Electronic Medical Records

A Study of Secure Document Sharing System for Electronic Medical Records

Chien Hua Wu

Graduate Institute of Business Administration, Fu Jen Catholic University,

Taiwan FJU

New Taipei City, Taiwan

Da Wei Wang

Institute of Information Science, Academia Sinica.

Taipei, Taiwan

Ruey Kei Chiu

Department of Information Management, Fu Jen Catholic University

FJU

New Taipei City, Taiwan

AbstractThe exchange of electronic medical records can reduce the preservation and the use of papers of medical records for management issues To the people, it allows the physician to access to his medical treatments in different hospitals resulting in avoiding the waste of medical resources. The sharing of electronic medical records has been effective in Taiwan. Now days, hospitals are sharing their electronic medical records through the Exchange Center of EMR under the Virtual Private Network but slightly less secure. This study aims to propose a security mechanism for the sharing of electronic medical records. The combination of security mechanism of S/MIME message level and RESTFul Service were adopted to build a secure mechanism for the sharing of electronic medical records. Two scenarios were simulated and implemented to verify the feasibility of this mechanism. From the results of the simulation presented, it has been conclude that the use of RESTful and S/MIME can enhance the confidentiality, integrity, authentication and non-repudiation of current exchange process of electronic medical records.

KeywordsElectronic Medical Record, Document Exchange, RESTFul, HL7

1. INTRODUCTION

   Fig. 1. EEC Architecture

   The Ministry of Health and Welfare (MOHW) planned to conduct an electronic medical record exchange center(EEC) from 2009 to share electronic medical records for hospitals in Taiwan[1]. MOHW to implement and promote the exchange

   of electronic medical records has been quite effective up to date. Figure 1 shows that hospitals are exchanging electronic

   medical records through the EEC under the Virtual Private Network (VPN) environment . There are already five categories of electronic medical records that can be exchanged through the EEC between hospitals under Virtual Private Network [2]. The development of electronic medical records in the hospital now has a considerable effect. After having legislation of electronic medical records [3], hospitals can use electronic medical records, do not need to create and save papers of medical records. Hwang et al. indicated that information quality of EMR exchange was the key factor which influencing users [4]. EMR allows physicians rapid access to medical treatment in different hospitals, save the use of medical resources. This paper references to the prevailing exchange EHR architecture. Aim to explore a core technology and the security approach among health care information systems. Figure 2 represents two scenarios were simulated and implemented to evaluate and verify the feasibility of such a mechanism. The purpose of this study was to propose a security mechanism, and to achieve the information exchange security:(1) Authentication of EMR;(2) Confidentiality storage of EMR;(3) Integrity of EMR;(4) Non-repudiation of EMR exchange with each stakeholder.

   Fig. 2. Scenarios of SEMRS System

2. MATERIALS AND METHODS

   1. Clinical Document Standard

      Health Level Seven International was founded in 1987 [5]. American National Standards Institute (ANSI) [6] and the International Organization for Standardization (ISO) [7] accredited international standards for the EMR exchange and sharing that support clinical practice. Due to the wide range of medical services covered by the industry, such as medical care, medicines, medical equipment, medical information, health care, etc. The main objective of HL7 is to develop a

      commonality and interoperability system. The Level 7 layer also supports the secure authentication and identification of data exchange. HL7 standards can be quickly applied in hospital and can be easily integrated with several of the other systems.

      Clinical Document Architecture, Release Two (CDA R2), became an ANSI-approved HL7 Standard in May 2005 [8]. CDA documents are encoded in Extensible Markup Language (XML) that specifies the structure and semantics of a clinical document. A CDA document can include text, images, sounds, and other multimedia content. The CDA is a documentation of observations and services defines six characteristics of a clinical document with Persistence, Stewardship, Potential for authentication, Context, Wholeness and Human readability. Figure 3 represents an example of CDA document has a header and a body. The header is consistent across all clinical documents. The body contains the human readable content which comprises sections, paragraphs, lists, and tables.

      Fig. 3. An Example of CDA document

      Digital Imaging and Communications in Medicine (DICOM) is currently the standard format widely used in hospitals for medical imaging message [9]. This standard was announced by the committee (ACR-NEMA) which established by American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA), published in 1993, and officially named DICOM 3.0 to help the image storage, content distribution and viewing of medical images, such as Computerized Tomography (CT), Magnetic Resonance Imaging (MRI) and ultrasound.

   2. Representational State Transfer

      Representational State Transfer (REST) is a design concept. This concept comes from the Roy published PhD thesis [10]. He proposed REST software architecture style as an abstract model of network applications, but it is not a standard. REST systems interface with external systems as web resources, each resource will have a URI (Uniform Resource Identifier). It relies on a stateless, client-server, cacheable communications protocol. Because Web applications in HTML only defined to the GET POST, cause

      little use to other methods such as PUT and DELETE on Web-based applications as well as HEAD, STATUS and other methods. REST is simple interface often used to describe any use of XML (or YAML, JSON, plain text), without having to rely on other mechanisms (such as SOAP). Compared to other commonly used Web Service standards, such as SOAP and XML-RPC, it is more simple and easy to use. It has the following characteristics:(1) All of the API is Resource form;(2) This service can accept and return MIME-TYPE, also can return XML / JPG / TXT and other formats; (3)Supporting the operation of the various HTTP methods (such as GET, POST, PUT, DELETE).

   3. Multipurpose Internet Mail Extensions

      Multipurpose Internet Mail Extensions (MIME) is a network messaging applied to flexible message format standard [11]. It extends the standard of E-mail, MIME standard can support transmission such as images, audio, video, and other binary file. MIME message format consists of Header and Body. Header is a set of Header Fields, Body contains a single Party or more Parties. MIME Header provides the information structure and encoding. MIME Body is the actual message content, supports a variety of data formats, sometimes also referred to as "Payload". Secure MIME (S/MIME) is a standard message format [12]. S/MIME provide MIME message format standard encryption and digital signatures to send and receive secure messages in MIME format on the web. It provides digital signature and encryption; these two security mechanisms are based on RSA public key infrastructure (PKI).

   4. RESTFul Services and Web Services

      We Service is based on the Simple Object Access Protocol (SOAP) agreement, WS-Security is the core of Web services security standards [13]. Gabriel et al. [14], respectively, used the GET and POST methods to compare different security mechanisms among them. In the conditions of plain text, encryption or signature, the results show that RESTful services were processed more efficiently than Web Services. Cesare et al. describes the differences between REST services and WS- * services [15]. He used a variety of architectural decision models to determine which type of service were more appropriate. Their result shows that REST was more suitable for basic and ad-hoc integration scenarios. When business requirements demand a higher quality of service WS- * was more flexible. AlShahwan et al. presented SOAP-base and REST-base frameworks for providing distributed mobile Web Services. Their result showed that a RESTful-based is more suitable for mobile environments than a SOAP-base.

3. SEMRS ARCHITECTURE

   A Secure Electronic Medical Records Services system (SEMRS) conducted in this paper references an existing electronic medical records exchange to enhance the message security. Figure 4 presents the whole architecture of SEMRS. Step 1 through Step3 presents the EMR upload and EMR index registry process of Hospital A, step 4 through Step 5presents the EMR index store query process of Hospital B, step 6 through step 7 presents EMR retrieve process of Hospital B.

   TABLE I. HEADER TAGS

   Header	Tag Description
   X-EEC-Sender	Sender
   X-EEC-Receiver	Receiver
   X-EEC-SymmetricAlg	One-time password Algorithm
   X-EEC-AsymmetricAlg	PKI Algorithm
   X-EEC-DistAlg	Message Digest Algorithm
   X-EEC-SignAlg	Digital Signature Algorithm
   X-EEC-BodypartCnt	MIME Body Part count
   X-EEC-HeaderCnt	MIME Header tag count

   Header	Tag Description
   X-EEC-Sender	Sender
   X-EEC-Receiver	Receiver
   X-EEC-SymmetricAlg	One-time password Algorithm
   X-EEC-AsymmetricAlg	PKI Algorithm
   X-EEC-DistAlg	Message Digest Algorithm
   X-EEC-SignAlg	Digital Signature Algorithm
   X-EEC-BodypartCnt	MIME Body Part count
   X-EEC-HeaderCnt	MIME Header tag count

   Fig. 4. System Architecture of SEMRS

   • Step 1 through Step 3 are described as follows: (1)Hospital A puts CDA R2 documents and DICOM documents which will be upload to repository to the Repository Client of Hospital.(2)Repository Client of Hospital A packaged the CDA R2 documents and DICOM documents into a S/MIME envelope then upload it to EMR repository of Hospital A through RESTFul service.(3)EMR repository of Hospital A used RESTFul service to register received EMR index to EMR Registry Center via RESTFul services using S/MIME.

   • Step 4 through Step 5 are described as follows:(4)EMR Repository of Hospital B sent EMR registry store query request to EMR Registry Center via RESTFul services using S/MIME.(5)EMR Registry Center response it to the EMR repository of Hospital B through RESTFul service using S/MIME.

   • Step 6 through Step 7 are described as follows:(6)EMR Repository of Hospital B sent a retrieve request to EMR Repository of Hospital A via RESTFul services using S/MIME.(7)EMR Repository of Hospital A packaged the documents into a S/MIME envelope then response it to the EMR repository of Hospital B through RESTFul service.

   1. Design of the MIME-based Envelope

      Figure 5 presents the message structure of SEMRS. Table I lists the usage of MIME header tags which were used in SEMRS.MIME body presents in figure 5 which encrypted CDA document is in body part 1, encrypted message digest is in body part 2, encrypted digital signature is in body part 3, encrypted one-time password is in body part 4,encrypted DICOM documents are stored from body part 5 to the end part.

      Fig. 5. MIME-based Envelope

   2. Design of SEMRS Model

      Fig. 6. The Scenario of Hospital A.

      TABLE II. ALGIRITHMS OF PROVIDER

      Stage	Algirithm
      Step 1	OTPKey = KeyGenerator(KeyAlg)
      Step 2	For all header.name Mhd[name].value=encryptData(header.value, OTPKey, OTPKeyAlg) End for
      Step 3	EncEMR = encryptData (hisEMR, OTPKey, OTPKeyAlg) If EncEMR is not null then Mpart.AddBodyPart(EncEMR) End if
      Step 4	mDist = digest(hisEMR, DistAlg )
      Step 5	EncDist = encryptData (mDist , OTPKey, OTPKeyAlg) If EncDist is not null then Mpart .AddBodyPart(EncDist) End if
      Step 6	SignEMR = sign(mDist, SenderPriKey, SignAlg) byteSign = concateToByte(mDist, FinPrt )
      Step 7	EncSign = encryptData (SignEMR, OTPKey, OTPKeyAlg) If EncSign is not null then Mpart .AddBodyPart(EncSign) EndIf
      Step 8	EncOTPKey = encryptData (OTPKey, ReceiverPubKey, PKIAlg) If EncOTPKey is not null then Mpart.AddBodyPart(EncOTPKey) End if
      Step 9	EncDICOM = encryptData (hisDICOM, OTPKey, OTPKeyAlg) If EncEMR is not null then Mpart.AddBodyPart(EncDICOM) End if

      Figure 6 represents the processes of Hospital A from step 1 through step 9, corresponding to the steps of algorithm in Table 2 respectively. The processes involved in this principle are:

      • (1)Dynamically generated one-time password;

      • (2)Use one-time password to encrypt all MIME Header tag values;

      • (3) Use one-time password to encrypt CDA R2 document then puts it into MIME body part 1;

      • (4) Use CDA R2 document to generate message digest;

      • (5) Use one-time password to encrypt message digest then put it into MIME body part 2;

      • (6) Use sender's private key and message digest to create digital signature;

      • (7) Use one-time password to encrypt digital signature then put it into MIME body part 3;

      • (8) Use receiver public key to encrypt one-time password then put it into MIME body part 4;

      • (9) Use one-time password to encrypt DICOM document then put it into MIME body part 5 and so on..

        Stage	Algirithm
        Step 1	EncOTPKey = Mpart .GetBodyPart(4)
        Step 2	OTPKey = decryptData (EncOTPKey, ReceiverPriKey, PKIAlg)
        Step 3	For all header.name Mhd[name].value=decryptData(heder.value,OTPKey,OTPKey Alg) End for
        Step 4	EncEMR =Mpart .GetBodyPart(1) hisEMR = decryptData (hisEMR, OTPKey, OTPKeyAlg)
        Step 5	EncDist =Mpart .GetBodyPart(2) mDist = decryptData (EncDist , OTPKey, OTPKeyAlg)
        Step 6	EncSign =Mpart .GetBodyPart(3) SignEMR = encryptData (EncSign, OTPKey, OTPKeyAlg)
        Step 7	EncDICOM =Mpart .GetBodyPart(5) hisDICOM = decryptData (EncDICOM, OTPKey,

        Stage	Algirithm
        Step 1	EncOTPKey = Mpart .GetBodyPart(4)
        Step 2	OTPKey = decryptData (EncOTPKey, ReceiverPriKey, PKIAlg)
        Step 3	For all header.name Mhd[name].value=decryptData(heder.value,OTPKey,OTPKey Alg) End for
        Step 4	EncEMR =Mpart .GetBodyPart(1) hisEMR = decryptData (hisEMR, OTPKey, OTPKeyAlg)
        Step 5	EncDist =Mpart .GetBodyPart(2) mDist = decryptData (EncDist , OTPKey, OTPKeyAlg)
        Step 6	EncSign =Mpart .GetBodyPart(3) SignEMR = encryptData (EncSign, OTPKey, OTPKeyAlg)
        Step 7	EncDICOM =Mpart .GetBodyPart(5) hisDICOM = decryptData (EncDICOM, OTPKey,

        Fig. 7. The Scenario of Hospital B. TABLE III. ALGIRITHMS OF CONSUMER

        Figure 7 represents the processes of Hospital B from step 1 through step 7 correspond to the steps of algorithm in Table 3 respectively. The processes involved in this principle are :

      • (1)Extract encrypted one-time password from MIME body;

      • (2) Decrypted password using receiver's private key then get one-time password;

      • (3)Decrypted MIME header tags using one-time password;

      • (4)Extract MIME body part 1 of encrypted CDA R2 document then decrypted it using one-time password;

      • (5)Extract MIME body part 2 of message digest then decrypted it using one-time password;

      • (6)Extract MIME body part 3 of digital signature then decrypted it using one-time password;

      • (7)Extract MIME body part 4 of DICOM document then decrypted it using one-time password and so on. To verify the digital signature after successfully decrypted.

4. IMPLEMENTATION AND TESTING

   Fig. 8. Figure 12

   Figure 8 shows the environment of this paper. Two scenarios are developed in this paper. One simulates the provider of Hospital A who provides the original EMR documents and the other simulates the consumer of Hospital B who retrieves the EMR documents. One CDA document and 46 DICOM documents are tested in this paper .

   1. Provide and Register of EMR

      Fig. 9. Respository Client of Provider

      Figure 9 represents the Repository Client of Hospital is prepare to submit to EMR Repository of Hospital A. Therefore, hospital A packages CDA R2 and DICOM documents into MIME envelope then uploads to Repository of Hospital A and registers to Registry EMR center. Figure

      10 represents the encrypted MIME header and Figure 11 represents the encrypted MIME body. After successfully uploaded to the Registry EMR Center and signature verification success. It indicates that this transaction has non- repudiation.

      Fig. 10. A Secure MIME Header of SEMRS

      Fig. 11. A Secure MIME Body of SEMRS

      Fig. 12. Retrieved EMR Documents

   2. Retrieve EMR from Hospital A to Hospital B

   Hospital B inquires patient's EMR records from Registry EMR center then retrieves desired EMR records from Repository of Hospital A to Repository of Hospital B. Figure 12 represents the patient's EMR record which successfully retrieved from Hospital A to Hospital B using RESTful service.

5. DISCUSSION AND CONCLUSION

This paper, was focused on how to use S/MIME and RESTful Web service to develop a secure mechanism of EMR documents exchange. With the flexibility of REST and MIME envelope, the RESTful Web service have become more acceptable. It has been a more secure solution compare to VPN. The proposed approach respects the REST philosophy by implementing the message security with MIME envelope. This approach enforces the message to be encrypted and protected during transmission. It was also applied, message digest and digital signature for verification. Thus, the proposed approach can achieve the exchange of confidentiality, integrity, authentication and non-repudiation.

When needed patients electronic medical records can be easily accessed by any hospital. It can be integrated in-house system of hospitals and provide a way to exchange EMR documents securely between different enterprises. Enterprises can exchange patient's information when it is convenient to access the patients treatment. This avoids repetitive inspections to save medical resources.

REFERENCES

1. Ministry of Health and Welfare. "Health Care Platinum program". Available:

   http://www.mohw.gov.tw/news/448238669.

2. National Health Insurance Administration, "Healthcare Information Network Service System (VPN) User Manual".

3. Ministry of Justice , "Law & Regulations Database of The Republic of China"., Available:

   http://law.moj.gov.tw/LawClass/LawAll.aspx?PCode=L0020021

4. H. G., Hwang, C. H. Lu, J. L. Hsiao and R. F. Chen, "Factors Influencing Benefits of Electronic Medical Records Exchange : Physician Perspectives"., Journal of e-business.,2009, 11(1), pp. 95- 118.

5. Health Level Seven International ,"About HL7"., Available: http://www.hl7.org/about/index.cfm?ref=nav.

6. American National Standards Institute ,"HL7 V3 Normative "., Available: http://webstore.ansi.org/RecordDetail.aspx?sku=HL7+V3+Normative- 2011.

7. ISO ,"Data Exchange Standards — HL7 Clinical Document Architecture, Release 2".,Available: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?c snumber=44429.

8. American National Standards Institute ,"HL7 Version 3 Standard: Clinical Document Architecture (CDA), Release 2"., Available: http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI%2FHL7+CDA

   +R2-2005+(R2010).

9. NEMA ,."DICOM PS3.1 2014c – Introduction and Overview"., Available: http://medical.nema.org/medical/dicom/current/output/pdf/part01.pdf.

10. T.F. Roy . "Architectural Styles and the Design of Network-based Software Architectures"., Ph.D. dissertation, University of California, Irvine, USA, 2000.

11. SoftwareAG , "MIME-S/MIME Developers Guide Version 8.2 "., April 2011.

12. Internet Engineering Task Force , "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message specification" , RFC 5751, January 2010.

13. OASIS , "Web Services Security: SOAP Message Security 1.1 (WS- Security 2004)"., OASIS Standard Specification,Available:http://docs.oasis-open.org/wss/v1.1/wss-v1.1- spec-os-SOAPMessageSecurity.pdf

14. S. Gabriel, S. D. O. Anderson, M. Julienand R. Yves ,"Enabling Message Security for RESTful Services"., IEEE 19th International Conference on Web Services (ICWS 2012) , Hawaii, USA, 2012.

15. P. Cesare, Z. Olaf andL. Frank ,"RESTful Web Services vs. "Big" Web Services:Making the Right Architectural Decision"., 17th International World Wide Web Conference (WWW 2008) , Beijing, China, 2008.

16. F. AlShahwan, K. Moessner and . F. Carrez ," Evaluation of Distributed SOAP and RESTful Mobile Web Services"., International Journal on Advances in Networks and Services , 2010, vol 3 no 3 & 4, pp. 447-461..