1 / 22

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

Protecting the Exchange of Medical Images in Healthcare Process Integration with Web Services. 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

etana
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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>

More Related