INFOWAY EHRI PRIVACY & SECURITY CONCEPTUAL ARCHITECTURE V1.1

Transcription

1 INFOWAY EHRI PRIVACY & SECURITY CONCEPTUAL ARCHITECTURE V1.1 Review and Recommendation Report to the Ontario Health Informatics Standards Council (OHISC) By: Ontario Privacy & Security Architecture January 16, 2006

2 Table of Contents Background... 2 Purpose of this Report... 2 Ontario Privacy and Security Architecture Participants... 3 Overview of the Infoway EHRi Privacy & Security Conceptual Architecture v Ontario Privacy & Security Architecture Recommendations... 4 Concluding Remarks... 7 Appendix A: List of Acronyms... 8 Appendix B: References... 9 Page 1 of 9

3 Background The Ontario Privacy and Security Architecture (OPSA) was initiated to review issues and discussions emanating from the Canada Health Infoway (Infoway) Electronic Health Record Infostructure (EHRi) Privacy and Security Conceptual Architecture (PSA) project. Working group members contributed, reviewed and validated business requirements and associated standards development (adoption, adaptation, development) generated from the pan-canadian work, as to their relevance and appropriateness for Ontario. This work supports two initiatives; Infoway projects needs and analysis in support of related upcoming initiatives or affected projects that are part of Ontario s e-health Strategy, including Ontario s eventual EHR solution. To ensure continuity of communications and analysis needs between Ontario and the Infoway stakeholders, a series of working group meetings were held. Initial feedback generated from the working group discussions has been integrated with the recent version of the architecture, v1.1 [1]. Purpose of this Report This report is intended to inform the Ontario Health Informatics Council (OHISC) on the outstanding issues and concerns identified during the review of Canada Health Infoway s Electronic Health Record Infostructure (EHRi) Privacy & Security Conceptual Architecture document v1.1 [1]. Page 2 of 9

4 Ontario Privacy and Security Architecture Participants The following stakeholders and Subject Matter Experts from Ontario were consulted in the review of the Infoway EHRi Privacy & Security Conceptual Architecture document(s). We would like to acknowledge the participants for their support and contribution in producing this report. Chair(s): Gurjeet Dosanjh... SSHA Standards Management and Business Integration Pat Jeselon... MOHLTC e-health Office Participants: Iryna Bonya... MOHLTC Strategic Policy Branch Mel Casalino... MOHLTC e-health Office Fred Carter... MOHLTC Information and Privacy Commissioner Peter Catford... Continuing Care e-health Angela Chung... SSHA Standards Management and Business Integration Danna Dobson... SSHA Standards Management and Business Integration Sharan Dosanjh... SSHA Privacy & Security Brent Fraser... MOHLTC Drug Programs Branch Julia Gallo... MOHLTC Health Information Privacy Unit Martin Green... SSHA Privacy & Security Nicole Hamacher... MOHLTC Client Registry and Identification Management Dietmar Klonikowski... MOHLTC Ontario Laboratories Information System Richard Liu... SSHA e-health Solutions Patrick Lo... Ontario MD Marion Lyver... SSHA Standards Management and Business Integration Ron McEwen... SSHA Infrastructure Services Stephen Milling... MOHLTC IT Security Policy, Human Services I&IT Cluster Kees Pouw... MOHLTC IT Security Policy, Human Services I&IT Cluster Michele Sanborn... MOHLTC Health Information Privacy Unit Angela Schroen... Continuing Care e-health Brendan Seaton... SSHA Privacy & Security Martha Turner... MOHTLC Client Registry and Identification Management Duncan Weatherston... MOHLTC Ontario Laboratories Information System Page 3 of 9

5 Overview of the Infoway EHRi Privacy & Security Conceptual Architecture v1.1 Canada Health Infoway (Infoway) has undertaken the development of an Electronic Health Record Infostructure (EHRi) Privacy and Security Conceptual Architecture (PSA) project to help ensure that future interoperable EHR systems will comply with federal/provincial/ territorial (FPT), as well as cross-jurisdictional Privacy and Security (P&S) requirements. This robust and scalable P&S architecture will also guide Infoway s future investments in EHR systems. The architecture defines the privacy and security requirements for an interoperable EHR based on existing legal and regulatory requirements, as well as national and international standards and best practices. It provides a high-level view of how different functions and components in the system interact with one another and how they will facilitate secure interoperability. Jurisdictions can use this as a guide in the development and implementation of privacy and security requirements for organizational and FPT information technology initiatives. The architecture also addresses cross-jurisdictional data protection requirements as personal health information becomes more broadly accessible to authorized healthcare professionals. Ontario Privacy & Security Architecture Recommendations OPSA acknowledges that Infoway has addressed some of the concerns and issues that the working group identified in earlier iterations of the Privacy and Security Conceptual Architecture document. The following are some of the remaining issues and concerns for Ontario that have been identified through subsequent review sessions. The security architecture addresses controls appropriate for well-behaved users, but does not provide significant architectural defenses against malicious or hostile attackers, some of whom may be, or be acting as, authorized users. Harm caused by such attackers can often not be prevented or contained by detective controls such as intrusion detection and audit. A suggestion would be to incorporate active security features in the architecture to eliminate the possibility of substantial harm by determined attackers. Consider the incorporation of real-time, inline abuse/fraud detection systems. Also, include more advanced authentication mechanisms to recognize users based on a wide range of criteria such as location, time, client system profile, usage patterns, and dynamic personal knowledge. The document implies that EHRi trusts every other EHRi. It is recognized that trust relationships should be cautious and minimal. Strength of trust should depend on evidence that trusted parties provide regarding their security management practices. Page 4 of 9

6 Instead of an implied trust model security architecture and management systems should be used to provide a basis for trust where needed and warranted. The document fails to address the requirement for the integrity of portals, since compromise of a portal could be leveraged by an attacker. With respect to the ten P&S services, there are no services included in the document to provide an assurance that privacy and security objectives and commitments are being met on an ongoing basis. This is a common problem with security architectures. One should not assume, without evidence, that individual or integrated security controls are effective and reliable. Identified services and service functions frequently address only the functions required to initiate service, and fail to address changes during operations and termination of service, that is there is a lack of a full lifecycle perspective. With reference to User Identity Management Service, it should address all attributes of people and context within organizations. It will also be necessary to capture organizational structure, positions, incumbents, roles, and authority hierarchies. One of the most challenging requirements will be the ability to implement major changes in organizational structure while maintaining appropriate access. Additionally, User Authentication Services do not address the need to manage authentication credentials throughout their lifecycle. Runtime authentication and authorization services should employ standards such as Security Assertion Markup Language (SAML) and extensible Access Control Markup Language (XACML). The architecture, as defined, references authentication tokens but the description seems quite different from SAML assertions. There is confusion between authentication tokens and the session vectors typically used as part of session management. Access control services should include services to manage authorization work flows, including persons/positions involved in the approvals process, and to report on access permissions and changes to appropriate managers so that inappropriate entitlements will be identified and corrected. In a decentralized model this further complicates the issue of permissions management. Point of Service (POS) systems will still require session management services, but may be irrelevant within EHRS due to HL7 based messaging. It can be argued that implementation of the EHRi does not necessarily exist within a uniform high trust model as assumed by the document. Authentication of POS systems by EHRS should not be needed. Authentication should be conveyed within the XML messages, which the POS must know how to do. As noted above and in the Standards Assessment document [2], user authentication to EHRS should be based on SAML. Page 5 of 9

7 Ideally, authorization of the provider should be able to leverage additional data, such as evidence (via card swipe) that the patient is present. Authorization service should enable complex, risk-based decisions aided by the widest possible range of supporting information. Authorization rules need not always be complex, but the system should support complex rules as needed. The proposed access control model utilizes system- or application-based access control. Digital Rights Management (DRM) should be considered as a major alternative. In DRM, data is encrypted and access is mediated by controlling access to decryption keys. DRM allows policy-based control, including powerful restrictions on use of information. The document fails to address how consent instructions will be enforced if consent is denied to certain users, but EHRS does not know the true identity of all users. This suggests that it is a requirement that EHRS knows, or be able to determine at runtime, the true and unique identity of all users. The document does not substantiate the importance of secure audit service components (i.e. analyze logs and detect intrusions). These are major components of the security architecture, comparable in scale to identity management or authentication, and should have comparable coverage in the architecture. These are the only services specifically designed to detect and respond to attacks. Failure to provide adequate coverage in the architecture is likely to result in inadequate implementation. There needs to be more emphasis on assurance (i.e., policies, agreements, vulnerability assessments, security inspections, managing logs). Although the document addresses the requirement to notify privacy officers and security officers of certain specific events as an essential feature of the P&S conceptual architecture, it should be broadened to address reporting to responsible business managers at different levels of detail in order to enable effective management oversight and risk management, and to provide assurance that security controls are achieving objectives. The document identifies a provider registry as containing regulated providers information only, leaving unregulated providers to be contained within a user registry. However, both regulated and unregulated providers should in fact be contained in a provider registry; a user registry should only contain authorized providers, regulated and unregulated, that have a need to access jurisdictional systems. These users will be authenticating against a provider registry. The document generalizes that provider information is classified as personal information, where as in fact it can be categorized as business information. For example, provider s financial information requires further protection. Most of this needs to be posted in a directory that is available for , blue pages, Public Key Infrastructure (PKI), and etc., which is not discussed in the architecture document. Some attempt should be made to rationalize on the number of personal identifiers. There may be a requirement for the Enterprise Master Patient Index (EMPI) to support this in a provider registry environment. Page 6 of 9

8 The document claims that there are no minimum standards for authentication for access to systems containing Personal Health Information (PHI) exists in Canada. One recommendation would be to look at the National Institute of Standards and Technology s (NIST) recently published document on an authentication standard that uses different levels of authentication [3]. The document suggests that digital signatures should be assigned to electronic health record entries in addition to digital signatures for documents. Also recommended is the incorporation of a digital signature to EHRi messaging service. In general the document does not address many of the Information Technology Infrastructure Library / Information Technology Service Management (ITIL/ITSM) processes, such as Incident Response, Change Management, etc. Concluding Remarks Understanding that this is a conceptual Privacy & Security architecture document it is possible that the target architecture will not be feasible or affordable to implement; the technology being contemplated has not been proven; there will be an enormous amount of overhead in the privacy and security controls, the XML messages and cryptography; the overhead could well account for percent of the effort and cost. The architecture document oversimplifies many aspects of the identified security services. By doing so, implementation of the services is made to look relatively straightforward. Implementation of full-featured services that address the entire life cycle that can cope with both diversity and change will be much more complex than implied. Identity management, authentication, authorization, access management, and effective audit all pose enormous challenges to large organizations that try to implement them. This architecture anticipates achievements that are well beyond current capabilities. Nowadays, the primary route of attack is through malware or other compromises to the end-user s workstation. The proposed architecture has very little to protect against such attacks. While it would not eliminate overhead costs, consideration should be given to server-based solutions, in which users have terminal interfaces to POS software. Page 7 of 9

9 Appendix A: List of Acronyms Acronym DRM HER EHRi EHRS EMPI FPT HL7 ITIL/ITSM NIST OPSA P&S PHI PKI POS PSA SAML XACML XML Definition Digital Rights Management Electronic Health Record Electronic Health Record Infostructure Electronic Health Record Solution Enterprise Master Patient Index Federal/Provincial/Territorial Health Level Seven Information Technology Infrastructure Library / Information Technology Service Management (American) National Institute for Standards in Technology Ontario Privacy and Security Architecture Privacy & Security Personal Health Information Public Key Infrastructure Point of Service Privacy and Security Conceptual Architecture Security Assertion Markup Language extensible Access Control Markup Language Extensible Markup Language Page 8 of 9

10 Appendix B: References 1. Canada Health Infoway. Electronic Health Record Infostructure (EHRi) Privacy and Security Conceptual Architecture Version 1.1, June Canada Health Infoway. Electronic Health Record (EHR), Privacy and Security Standards Assessment, June National Institute for Standards in Technology. Special Publication (SP) , Electronic Authentication Guideline, August Page 9 of 9