Establishing End-to-End Security in a Nationwide Network for Telecooperation

Transkript

1 Establishing End-to-End Security in a Nationwide Network for Telecooperation M. Staemmler a, M. Walz b, G. Weisser c, U. Engelmann d, R. Weininger e, A. Ernstberger f, J. Sturm g a Fachhochschule Stralsund, Deutschland b Ärztliche Stelle für Qualitätssicherung in der Radiologie Hessen, TÜV SÜD Life Service GmbH, Frankfurt, Deutschland c Radiologie und Geschäftsfeld Informationstechnologie und Qualitätssicherung, Universitätsmedizin Mannheim, Deutschland d Chili GmbH, Dossenheim/Heidelberg, Deutschland e pegasus gmbh, Regenstauf, Deutschland f Abteilung für Unfallchirurgie, Universitätsklinikum Regensburg, Deutschland g Akademie der Unfallchirurgie GmbH, München, Deutschland Contact: martin.staemmler@fh-.de MIE2012, Wien, ehealth Pisa, 2012,

2 Establishing End-to-End Security in a Nationwide Network for Telecooperation contents organizing trauma patient treatment system architecture data protection requirements results discussion

3 organizing trauma patient treatment - trauma treatment (ca cases in DE / year, 25% transfers) - white paper German Society of Trauma Surgery (DGU*) - established and reliable collaboration between hospitals regional trauma network characteristics hospitals / trauma network - structured in local, regional and supra- regional trauma care centers (with increasing treatment capabilities) - certified (equipment, workflow) - quality assured with a Traumaregister excellent organisational structure for trauma treatment 55 trauma networks representing ca. 800 hospitals in DE but: communication of image and treatment data? *DGU - Deutsche Gesellschaft für Unfallchirurgie

4 collaboration within trauma networks analysis of communication infrastructures - heterogene (architecture, coverage, operation, ) per trauma network - nearly not existing between trauma networks objective: unrestricted, national approach TKmed user requirements - emergency consultation - second opinion - transfer - image provisioning - teleradiology RöV* contents: - indication - ad hoc report - image data DICOM and non-dicom objects scalable: functionality, connection with/without HW, easy to use UI stepweise approach: TK-Basis, TK-Router, TK-Gateway *RöV Röntgenverordnung regulation for the application of X-rays

5 system architecture RIS Web- Viewer store & forward Architektur PACS RIS TK-Basis centralized TK infrastructure Portal DICOM / data Portal usage - mesages - non-dicom data object DICOM services PACS RIS TK-Router implementation / usage - manual up/download - automatic forward - with local Mini PACS PACS TK-Gateway

6 Establishing End-to-End Security in a Nationwide Network for Telecooperation contents organizing trauma patient treatment system architecture data protection requirements results discussion

7 data protection requirements user authentication according to national office (BSI*) 2-factor authentication e.g. - knowledge login, password - ownership smartcard, token, mtan - personal attributes finger print, iris scan Tkmed login, pwd Token - clinical user Web- Viewer central TK- Infrastructure access rights LDAP (AUC ) external token service start Viewer login password HTTPS connection authentication forward result test result check token 2-factor authentication forward result forward for check using a secured channel result check compliant procedure - but may be troublesome for clinical users simplification without token, when initiated from a known and safe institution (e.g. proven with a unique and static IP-address) *Bundesamt für Sicherheit in der Informationstechnik, Academy of trauma surgery Akademie der Unfallchirurgie (AUC)

8 data protection requirements end-to-end security in principal quite easy when using personalized accounts but in emergency cases Who is the person on duty at the recipient site? employing the organisational structure institution 1 department 1 department 2 clinical user 1 doctor clinical user 2 assistant clinical user 3 doctor : clinical user m doctor : department n institution 2 : institution k transmit to department 2 (only department 2 is entitled to receive) access, read, modify medical data by clinical users within department 2 audit trail states and identifies entitled sender and recipient organisational structure via LDAP services

9 data protection requirements end-to-end security typical approach with a centralized infrastructure institution A centralized infrastructure institution B encrypt decrypt encrypt decrypt RIS gateway DICOM store & forward gateway PACS step 1: sender encrypts data transmission to central infrastructure step 2: decrypt in central infrastructure encrypts for recipient step 3: transmission to recipient recipient decrypts data but: medical data is accessible centrally (at least for administrators) contradicts with data protection regulations

10 data protection requirements end-to-end security requirements 1 sender encrypts transmission recipient decrypts 2 sender encrypts for department as virtual recipient - transmission any medical doctor of the department is an entitled recipient 3 meta data (e.g. header, thumbnails) are encrypted separately to allow for fast navigation without download of the whole data object asymmetric encryption + secure + risk of compromizing limited to the key owner + life-cycle private / public key nearly unlimited (except techn. renewal) - slow, computational intensive - only the intended recipient is able to decrpyt data objects - PKI required e.g. based on a smartcard complies only to requirement 1 and 3

11 data protection requirements end-to-end security symmetric key encryption + secure and computational effective + no PKI required + each entitled recipient of a department has access to data objects - life-cycle in principle unlimited (potential key renewal for security) - risk: compromizing the key endangers all data objects compliant to all requirements method of choice but with establishing additional secutity meassures - symmetric key provided at run-time - separation of concern between - operator of the centralized TK-infrastructure - symmetric key management by external trusted services (ESZ)

12 data protection requirements end-to-end security clincal user webviewer central TKinfrastructure access rights LDAP (AUC) ESZ external trusted service external token service after successful authentication start transmission request symmetric key with ticket forward encrypt object forward using a secured channel check ticket provide symmetric key ciphered in a message check for medical user encrypt meta data store encrypted data in central infrastructure symmetric key supports confiscation protection (infrastructure with encrypted data only, ESZ to protect the symmetric key) ESZ provides further services (role medical user, audit trail, application integrity check)

13 system architecture RIS Web- Viewer organisation LDAP services PACS RIS TK-Basis centralized TK infrastructure Portal DICOM / data PACS RIS PACS TK-Router TK-Gateway external trusted services (ESZ) token services key management medcial professional integrity, audit trail

14 results TKmed - implements user requirements - use cases - handling of DICOM and non-dicom objects - clinically oriented address schemas - sender recipient - sender department recipient of a department - stepwise functionality (TK-Basis, TK-Router, TK-Gateway) - compliant to data protection regulation - 2-factor authentication - end-to-end security - external trusted service (audit trail, integrity check) - status - initial operation since autumn routine operation since 2012 with trauma networks and hospitals - initial seed money from the AUC, routine operation by end-users - impact evaluation ongoing with the TraumaRegister

15 discussion - German national Health Telematics Infrastructure - initial specification excluded transfer of large data objects - infrastructure work-in-progress not yet available - German case based record ( Fallakte ) - access control linked to record (at setup time) - regional scope, limited experience with cross regional use - IHE-XDS and XDS-I - requires patient identification as central service - XDS-I needs institutional gateways, leads to local repositories - stepwise functionality: web-based approach (TK-Basis)? - call for tender: applications exhibited limited usability a record based approach is foreseen

16 Establishing End-to-End Security in a Nationwide Network for Telecooperation thank you for your attention? questions?