Protecting the Exchange of Medical Images in Healthcare Process Integration with Web Services

1. Protecting the Exchange of Medical Images in Healthcare Process Integration with Web Services

2. Introduction • Medical images exist in electronic format • for easy storage and maintenance • promote high quality healthcare services for patients • a picture is worth a thousand words • Problem: uncontrolled exchange of medical images • Human initiated: emails, fax, ad hoc file transfer, … • Software initiated or software-to-software • Cross-institutional healthcare processes integration • Health Insurance Portability and Accountability Act of 1996 (HIPAA) • (1) Privacy, (2) Security, (3) Identifiers (4) Transactions and Code Sets • rules cover PHI “in any form or medium”

3. Proposed Approach • Medical Image Exchange Platform (MIEP) • Layered approach • Contemporary information technologies • Web services for the information transport • Role based access control (RBAC) • Watermarking for the integrity and privacy protection • Single-point border check

4. Protocol and Architecture Summary

5. Layered Architecture Protection Policy Protection Policy and Rules and Rules Audit Application Audit Application Enterprise Process Enterprise Process Privacy + Access Privacy + Access Control Rules Control Rules Ontology Ontology Watermarked Watermarked Images Images Web Services Web Services Secured transport Secured transport Laws / Regulation / Standards Monitoring BPEL EPAL / P3P & APPEL OWL / DAML Watermarking Protocol WSDL Internet SSL and PKI Medical Partner Medical Partner

6. Development Methodology - Overview • Policies • Rules • Technical • Auditing

7. Development Methodology - Policies • Protection policies should comply with requirements in laws, regulations, and code of practices. • Healthcare process integration should comply with the protection policies - privacy and access control requirements should be specified explicitly. • Existing protectionpolicy guarding internal operations may serve as basic hints for external partners.

8. Development Methodology - Rules • RBAC for employees of internal and external parties • Need-to-know principle - consider: • the access need of each task of each process for each role • sensitivity of the image content • contingencies and necessary override mechanisms => avoid ad hoc decisions. • Make sure that medical partners understand not only the protection policies but also the ontology based on which these rules are defined

9. Development Methodology - Technical • Express these rules in a high level language such as EPAL, P3P, and APPEL. • Ensure document images are exchanged via only the pre-defined MIEP Web service calls and from authenticated partners. • Firewall and email filters may be implemented to scan for and stop uncontrolled image traffic. • Watermark (containing protection information) is inserted into each image sent or received via the MIEP Web services. • Validation of document access against the access information embedded in the image watermark.

10. Development Methodology - Auditing • Auditing application may use existing in-house software as a blue-print, but now stricter. • Monitor actively all document image access to ensure • security and privacy constraints are met • the integrity of image data • otherwise, alerts should be sent to the management.

11. MIEP Concept Model

12. Some Technical Details • Outgoing Images • Incoming Images • Image Pickup Service • Privacy Policies and Rules

13. Outgoing Images • Routed through the outgoing proxy Web service SendDocumentImage (S) - parameters: • destination Web service to receive the images, purpose, sender, and target information (such as task, application, personnel, and/or role), image format descriptions, … • S calls the enterprise image exchange auditing Web service AuditSend • Existing watermark (if any) analyzed for validity and protection policies • sender & receiver are indeed legible • the exchange does not violate any protection policies • Watermark insertion: vital information such as the purpose, sender and target information (such as task, application, personnel, and/or role). • Such transactions are logged.

14. Incoming Images • Routed through the incoming proxy Web service ReceiveDocumentImage (R) - parameters: • destination to receive the images (Web service URL, port and operation), the user id, purpose, sender and target information (such as task, application, personnel, and/or role), image format descriptions, … • R call the enterprise image exchange auditing Web service AuditReceive for validation. • Compliant watermark from partner’s MIEP (if any) can be extracted for addition validation. • Similar watermark insertion for tracking. • Such transactions are logged.

15. Image Pickup Service • Not every business partner could immediately switch to a MIEP platform. • Initially allow a “pick up” service to cater for manual retrieval of the image in case the partner is not fully automated. • Used in a call back mode to further enhance the security for program-to-program interaction. • Pre-registration required for auditing and protection.

16. Privacy Policies and Rules • P3P - user agents allow users to automatically be informed of site practices and to facilitate decision-making based on the Web sites’ privacy practices. • APPEL for expressing users’ preferences of making automated or semi-automated decisions regarding the acceptability of machine-readable privacy policies from P3P enabled Web sites. • Matching mechanism A’s preferences (in APPEL) of vs. B’s P3P policies in Step 1.

17. Validation with HIPAA rules • The right to view and make a copy of a patients own medical records, and the right to request PHI to be shared with the patient in a particular way. • Patients can readily request their own medical images through the MIEP image pick up services • The right to find out where PHI has been shared for purposes other than care, payment, or healthcare operations • MIEP tracks and logs all cross-institutional exchange of medical image. • The right to request special restrictions on the use or disclosure of PHI. • MIEP maintains the patients’ profiles regarding their privacy preferences • The right to file complaints. • MIEP can provide exchange records and evidence.

18. Summary • Replace ad hoc and manual image exchange procedures with a unified Medical Image Exchange Platform (MIEP) • Layered MIEP architecture • Design and implementation methodology • Image exchange protocol • Application of Web services and watermarking technologies • Embedded watermark ensure integrity, privacy, and access control • Advantages of Web service / SOA • Legacy systems and existing practices corrected with MIEP • Reusability of MIEP => streamlines the development, deployment, and maintenance of software components for image exchange • Single border check for all the protection policies and auditing procedures => adequate control and auditing • Expandability For future tracking and auditing purposes

19. Future Work • Exploration of any potential usability and performance issues. • Mechanisms and tools for managing the interactions taking place between different layers in the proposed framework. • Further requirements engineering for privacy and security. • Application of ontologies • role classifications • terms used to present a domain of knowledge • Representation of the privacy access control policy in EPAL and the compliance of EPAL to the Web services. • Adoption issues • Application in other professional business domains:financial, legal …

20. Question and Answer Thank you! Contact: dicksonchiu@ieee.org

21. An Illustrative APPEL Privacy Preference <appel:RULE behavior="EnterpriseA"> … <-- evidence (abbreviated) --> … <POLICY> <STATEMENT> <RECIPIENT appel:connective="or-exact"> <ours/> </RECIPIENT> <DATA-GROUP appel:connective="or-exact"> <DATA ref="#DocumentImage"/> </DATA-GROUP> </STATEMENT> <STATEMENT> <PURPOSE appel:connective="or-exact"> <healthcare/> </PURPOSE> <DATA-GROUP> <DATA> <CATEGORIES appel:connective="or-exact"> <DATA ref="#DocumentImage"/> </CATEGORIES> </DATA> </DATA-GROUP> </STATEMENT> </POLICY> … <-- evidence (abbreviated) --> ... </appel:RULE>

22. An Illustrative P3P Privacy Policy <POLICY> ... <-- evidence (abbreviated) --> ... <STATEMENT> <RECIPIENT><ours/></RECIPIENT> <PURPOSE><insurance/></PURPOSE> <DATA-GROUP> <DATA ref="#DocumentImage"/> </DATA-GROUP> </STATEMENT> ... <-- evidence (abbreviated) --> ... </POLICY>