Role-Based Access to Patients Clinical Data: the Intercare Approach in the Region of Crete G
Total Page:16
File Type:pdf, Size:1020Kb
Role-Based Access to Patients Clinical Data: The InterCare Approach in the Region of Crete G. Potamias, M. Tsiknakis, D. Katehakis, E. Karabela, V. Moustakis, and S. Orphanoudakis HYGEIAnet: The Integrated Health Telematics Network of Crete HYGEIAnet: The HYGEIAnet Reference Architecture HYGEIAnet is an integrated healthcare telematics network installed and the Integrated Health Telematics Network of Crete operating in the region of the Greek island of Crete. The underlying Healthcare Information Infrastructure (HII) confronts to a Reference Architecture which Internet guides the development of the health-telematics network for the provision of User-Oriented Services Application Layer integrated healthcare services. It provides a general framework in which Supports the users’ healthcare related information systems are integrated to provide media-rich activities in the various Clinical Information Administrative Information Other Healthcare-related areas of the organization services to healthcare professionals, social workers, and the public. Chania Systems Systems Information Systems Users are primarily interested in information seeking and processing Kissamos Vamos Provides access to middleware services applications. Applications and enabling services employ certain information Heraklion based on particular policies related to the PPC-1 Rethymno Interface Information Task current task, user preferences and authorities AgentsInterface InformationAgents AgentsTask processing operations, and systems for data transport,PPC-1 which may be distributed Agents Agents Agents Hersonissos throughout the existing HII. Thus, HII consists of three basic components: Anogia Agios applications, enabling/ middleware services, and network infrastructure. Perama Neapoli Kandanos Nikolaos Sitia Middleware Layer Healthcare-related Services Palekastro Generic Services Healthcare-related as well as Terminology Semantic Mapping Directory The Integrated Electronic Health Record (I-EHR) is one of the basic services Kasteli generic middleware services, Authentica- Charging Directory TerminologyServices SemanticServices Mapping ServicesDirectory Archanes tionAuthenticaService - ServicesCharging ServicesDirectory Services Services Services offered in the context of the HYGEIAnet network. PPCThe-2 main middleware Spili that provide mechanisms for tion Service Services Services Zakros Resource Management of information provision, Resource Management of infrastructure supporting the I-EHR environment are: Moires Arkalochori Tzermiado Event Naming Logging Services Medical Acts … filtering, and fusion ServicesEvent ServicesNaming ServicesLogging Services Medical Acts … & Agia Services Services Services A set of security servicesPPC which-1 provide for the safe and authorised access Ziros Authorization Other Meta Data Varvara Vianos Encryption Messaging Authorization Other Meta Data Encryption Messaging ··· Services Services to the confidential clinical information and record any interaction with the Harakas Makrigialos Services Services ··· Services Services -1 Services Services service. Ierapetra 2 Mbps link Support the management of activities and information Provide generic mechanisms and services & 512 Kbps link Provide generic mechanisms and services relevant for the whole organization The information systems registry which includes information about the Services related to the 384 Kbps link integration and inter- clinical information systems that belong to the regional federation. Gavdos 256 Kbps link working of the technological Infrastructure layer (bitways) & The patient registry which identifies and locates the patients in the region. environments 128 Kbps link Media Synchronization Media Selection Quality of Service & The medical encounter registry which includes patients’ encounter Media Synchronization Media Selection Quality of Service Services Services Guarantees ··· Services Services Guarantees ··· information, and facilitates the access to the related clinical data. Regional Hospital District Hospital Primary HealthCare Center Community Doctors I-EHR services are offered via a specially designed, developed and deployed Patient Clinical Data Directory server. PCDD - Patient Clinical Data Directory services: An approach to the IEHR PCDD Components and underlying Architecture The main objective of the PCDD middleware infrastructure is to provide basic support for I- DIRECTORY SERVERS END USERS AUDITING EHR services in a consistent, reusable, and extensible way. PCDD indexes (i.e., provides a Standard Browser: Netscape SERVER registry) clinical feeder systems, patients, as well as information about the clinical objects of Communicator or Microsoft Internet Netscape V4.1, Explorer patient’s Her segments. Solaris 450MHz Life-Long View of / Navigation through-Patients’ Encounters Data Models: Information about clinical objects in the directory refers to clinical patient’s data, i.e., Patients’ clinical encounters. Medical encounter entries follow the Subjective- Resources Objective-Assessment-Plan (SOAP) models, which is a standard for recording and User Profiles Security WEB SERVERS representing clinical data generated during the contact of a patient and a healthcare PCDD provider. Subjective refers to the reason of the contact (i.e., the context of the encounter); Objective applies to medical examinations requested or, reviewed during the contact (e.g., DB1 Blood lab test); Assessment refers to the clinical diagnosis and associated reports; and Plan Sybase, Solaris DATABASE CORBA refers to the clinical actions that are taken (i.e., Treatment plan- drug prescriptions, surgery DB2 SERVERS SERVERS etc). Oracle, PC with NT, Pentium II 300MHz 64MB HRS RAM IIS 4.0, PC with NT, Architecture: PCDD comprises an integrated architecture where, different server-based DB3 PIDS IASO COAS Pentium II 400MHz applications communicate via standardized IDL interfaces, interconnected via a CORBA - SQL Anywhere V5.0, PC 128MB RAM with NT, Pentium II PSCIS based communication infrastructure. In the heart of PCDD rest an LDAP directory server. 300MHz 64MB RAM Orbix V2.3c, PC with PHCCIS PCDD NT, Pentium II 400MHz 128MB RAM Clinical Feeder Systems: PCDD provides the information required for accessing clinical information directly from its sources- the PCDD feeder systems. Feeder systems may support a wide variety of access methods ranging from human-mediated to CORBA object The SOAP model references, and HTTP URLs. Each feeder system is associated with a dedicated gateway that facilitates data extraction from it. Gateways get data from the feeder system, map them to Subjective Objective Assessment Plan the model of the directory, and translate them into LDAP statements, which are stored in a standard LDAP modify file. PCDD does not deal with the semantic mapping problem directly. Date Doctor Reason Clinical Gynecological Blood Biochemical Imaging Diagnosis Action It is in the responsibility of the feeder system to map an export schema of its information model . Exam Exam Exam Exam Exam . to the directory information model. A minimal export schema of a feeder system should express the existence of a patient’s EHR segment, by providing patient identification PCDD Update Schedule Introducing a New Feeder System into PCDD Updating PCDD Update Feeder System attributes. Based on this arrangement, mechanism, and respective servers for “ ” Directory the PCDD directory, and “Introducing a New feeder System”, were designed, developed mechanism Feeder System PCDD Feeder System Data Information Model Information Model and appropriately deployed. Directory Update Agent PCDD (wm client) Directory Updates (PERL) Step 1: update schedule Concept Mapping Concept Mapping The Human Computer Interface: An advanced, and fully operational Graphical User Inerface wm Directory Update Files (LDAP modify format) Life-Long View of, and Navigation through Patients’ via HTTP has been developed, which offers ‘ Shared Workspace Step 2: PCDD Entry Templates Change of LDAP Modify Files Creation of (LDAP modify) schedule Feeder system Clinical Encounters and respective Clinical Data’. The GUI encompasses functions for: Directory Update Files Export View DBMS (LDAP modify format) easy and parameterised search (by date, clinical information system, place, time etc), and Export View Remote site Remote site Step 3: LDAP Implementation of Data Data Extraction ODBC, modify respective query formulation capabilities - regional statistics - snapshots of patients’ Extraction Gateway ODBC, Gateway Data Collection Agent Data Collection Agent Extraction Gateway DICOM, etc. file (wm client) (wm client) Directory Update Files encounters, and messaging operations (i.e., Exchanging patients’ clinical snapshots Feeder system Step 4: (LDAP modify format) Image Archive Step 4: DBMS activate activate Update System Type PCDD Directory branch SystemType Entry, between co-operating healthcare personnel). DICOM Export View SystemInstallation Entry Interface ODBC-LDAP DICOM-LDAP Step 5: Update Healthcare Record Gateway Gateway Patient entries, MedicalEncounter entries, Directory branch ODBC DICOM HealthcareRecordSegment entries Role-Based Access Control: Administrating Authorised Access to Clinical Data Security Services: Role-Based Access Control Architecture The Organizational Access Rule Editor: A Web Client application The aim of security, in terms of access-control, is to check the legitimacy of access requests from healthcare agents, e.g., Healthcare professionals, and patients. The requirements of an underlying GUI