Ca Clinical Information Suite (CaCIS) Security and Privacy Architecture Roadmap

Transcription

1 Ca Clinical Information Suite (CaCIS) Security and Privacy Architecture Roadmap

2 Disclaimer Page

3 1.0 Executive Summary Stakeholders CaCIS Architecture Overview Point of Service Enterprise Message Bus Registry Services Patient Registry Provider Registry Location Registry User Registry Clinical Domains Deployment Scenarios Viewer Based Access Integration Based Access Portal based Integration Access Security and Privacy Architecture Overview Identity and Access Management Authentication Service Authentication Services Federation Services De- Identification Service Anonymization Service Psuedonimization Service XML Security Service Non- repudiation Service Security and Privacy Audit Service Consent Registry Service Flow Analysis of Create Referral...21 Appendix B: Conceptual Privacy and Security Use-cases...36

4 1.0Executive Summary CaCIS Security and Privacy Roadmap is a conceptual architecture document that describes the privacy and security services and their possible interactions with other services. This is live document and as the architecture of cacis progresses to logical and physical, this document will be updated to reflect these additions. CaCIS has identified 6 core security and privacy services. The goal of these services is to protect the personal health information (PHI), provide safeguards to ensure accountability, and to prevent unauthorized access to personal health information. The two core components of protection of PHI are policies and technology. This document will describe the technology tools and services that will enable the protection of PHI. The services that will provide the privacy and security functions are as follow: User Authentication Service a transactional service is part of the identity and assess management system and its primary purpose is to establish the validity of the claimed identity of a user logging into the system and thereby providing protection against fraudulent transactions. Authorization Service - provides access control methodologies as part of a unified privilege management service for users. This includes coarse-grain access control only. Consent Registry Service - translates privacy requirements arising from sources such as legislation, policies, and individuals specific consent directives, and applies these requirements in a healthcare system. De-Identification Service - will improve privacy protection by facilitating the separate storage of personal information that uniquely identifies individuals (e.g. name, address, health card number, etc.) from health information relating to their care and treatment; as well as allowing approved researchers access to anonymized longitudinal data by providing pseudonymous identifiers to Personal Health Information (PHI). It can also takes PHI representing an identifiable individual and removes all personal identifiers prior to aggregating the data into data sets of completely anonymized data for use in research and statistical analysis. Non-repudiation services - maintains data confidentiality and integrity using cryptography as well as it allows a health care professional to sign a digital document such as an e-prescription in much the same way they would apply a signature to paper, and with the assurance that the signature cannot be forged and neither the document nor the signature can be altered without rendering the signature invalid. Secure Audit Service - records significant privacy and security-related events in an event log. Component services include event logging and log analysis.

5 2.0Stakeholders Stakeholder Responsibility Executive/Business Representative Inform Review Subject Matter Expert Inform Review Analyst Inform Write Edit Review Architect Inform Write Edit Review Project Team Member Inform Write Edit Review

6 3.0CaCIS Architecture Overview There are many logical components to the EHR architecture. Most of these components are required and are essential in order to implement privacy and security rules and requirements. These components are interconnected to the security services and are considered as part of the reference architecture of the CaCIS. Diagram A is an illustration of the overall architecture for CaCIS architecture. Diag ram A

7 3.1 Point of Service A Point of Service (POS) System is clinical application systems (such as ADT, HIS, etc.) that operate at the NCCCP deployment sites and they are used for delivery of healthcare to patients. These systems may have human computer interfaces or be medical equipment generating data on a user that is then fed into the CaCIS. These systems are the sources for all clinical information that make up the CaCIS data. They may also access data from the CaCIS as it is required (please see section 4.0 for more detail), as well as from their own data stores to provide a more complete view of a patient s health history and current information. The POS in the above illustration can also access the clinical domain data from existing connection points that may possibly exist already within the NCCCP sites. The connection points at the bottom of the diagram demonstrate this type of connection. 3.2 Enterprise Message Bus Conceptually, as part of the security and privacy services the Enterprise Message Bus (EMB) acts as a filter to ensure that confidential PHI is never collected, used or disclosed inappropriately. The 6 P&S services shown in the diagram part of a larger suite of common services built into the EMB work together to create the mesh in that filter. The CaCIS also draws upon several additional information repositories: 1. Patient registry containing an entry for all patients/persons that participate in CaCIS; 2. Provider registry containing an entry for each healthcare provider part of CaCIS; 3. Location registry contains an entry for all possible locations for providers within CaCIS; and 4. User registry containing an entry for each CaCIS user who is registered under the trusted user management model. 3.3 Registry Services Patient Registry The Patient Registry Service is intended to implement a standards compliant service specification exposing interfaces to core capabilities needed by healthcare organizations to facilitate the business process with the Patient Registry. In HL7, the capabilities supported by a patient registry service are defined within the Personal Administration domain. Patient Any individual living (or previously living) being who is (or was) being treated or recipient of care (health care) This service provides an interface to the registry implementation, which holds uniquely, identified records for patients. This service is used by other cacis services to reference the patient information based on matching parameters.

8 3.3.2 Provider Registry A Provider is a person that provides goods or services to (within, or on behalf of) for the purposes of healthcare. They are a Person or Organization that is authorized to provide health care services by a recognized authority or agency that participates in broader health sector. A Provider Registry is a centralized directory providing a comprehensive and unambiguous identification of all providers practicing in an area (state, county, etc) including doctors, dentists, pharmacists, nurses, lab clinicians, diagnostic imaging technologists and any other healthcare professionals. It is where a health care provider's information (for example, name, address, practice licenses) is securely stored and maintained at an HER level and made available to other systems and users that interact and participate in the EHR. Typical inputs for Provider Registry come from the provider regulatory authorities (for example, Colleges of Physicians and Surgeons, Colleges of Pharmacists, College of Registered Nurses), Professional Associations (for example, Pharmacist Associations). Provider registry may interact with security services for several scenarios, consent directives maybe registered against a provided therefore the consent registry may check against the registry. Another in some implementations of the EHR restrictions enforced on a practitioner by the regulatory authority as to the norm of those practitioners duties may be recorded in the provider registry. An example of this would be if the College of Physicians has temporary removed or restricted a physician from provide prescription for narcotics Location Registry The Location Registry is the location of a facility (including actual places on the globe) designated to be either dedicated or incidental service delivery locations, including locations where a provider can assess CaCIS. Location Registration is associated with a facility, or any place that a provider may use to access CaCIS. This may include locations such as a physician s home, office, hospital, clinic, etc. The location registry is predominately used by the authorization service to grant access to a provider based on the assurance level associated with a particular location. The Location Registration process applies to both newly created locations and a new version of a place that is repurposed as one or more newly created service delivery locations. The identity of Locations must be managed at the most granular level capable of delivering services mailing addresses, telephone numbers and other identifiable attributes. How they are managed as a shared resource has to be defined according to the appropriate. The following principles can be applied in the management of Location registries Unique identity of the Location instance must be guaranteed across the full scope of all possible instances Identity must be shared across organizations that need to consume the same identity of a unique Location Each user (in different roles) must be able to understand the context of the Location s identity Any SDL that is managed by a different health program must be managed uniquely

9 3.3.4 User Registry The User Registry is a registry service that includes a list of all users that participate in CaCIS. This registry interacts with security services such as the Identity Management services and is used to enforce a user s authorized use of CaCIS and user s access rules. It is the user s role that determines which application function / transaction, screen, table, record, field, report, object, etc the user has permission for. The User Registry will not only contain information related to registered health service providers, but also any person with authorization to access the CaCIS. Users are individuals authorized to access application instances with differing scopes of authority depending on a user s role and providing services from different service delivery locations such as a physician accessing from home versus a hospital network. Users must include licensed Providers and may also be support users who are responsible to the Providers (or Provider organizations) who delegated their authority such as security administrators, technical administrators, registration clerks, etc. Patients and their delegates (ie substitute decision maker) may also be users who need or want access to their own Personal Health Information (PHI) that is stored on CaCIS. They may also need access to CaCIS in order to update or register consent directives. It is possible for a Provider to also be a patient. Patient users who need to access their PHI data will also be in a Patient Registry as it is assumed in order for the patient s data to be present in the CIS, the patient would need to be first either added and / or identified in a Patient Registry. If Patient users are not identified as themselves in a User Registry, they may be assigned a delegated role defined as substituted decision maker. When accessing their data, patients should be given a user role that defines their use and scope of application access. The following scenarios are examples of use cases for patient access: A patient wants to request or cancel an appointment A patient wants to register a disagreement with a medical finding A patient wants to manage their consent directives 3.4 Clinical Domains Clinical domains are any external system to cacis that needs to provide clinical information about patients that are participating in cacis. These systems typically are existing systems at the NCCCP sites, or systems at the partnering facilities. Some of the systems may include lab system (LIS), Diagnostic Imaging (DI), and other systems that assist current tumor staging, and pathology services. 4.0Deployment Scenarios This document has taken the approach that there are three possible ways to access CaCIS. These are via a viewer, via a direct integration, and through portlet integration with an existing portal. In this section these scenarios are described in more detail. 4.1 Viewer Based Access

10 It is envisioned that some of the NCCCP sites or their satellite sites may not have an existing EHR or any HIS/CIS system in place. In these scenarios it is a Viewer based access is meant to be the point of access to CaCIS. The Viewer is a component of the CaCIS ore architecture. The Viewer is accessed using a web-browser and provides full functionality and end-user experience. Advantages and disadvantages The advantage of this solution is that no additional development effort is required leading to lower cost, less time and effort implementing and maintaining the solution. It is currently thought that this is the second probable deployment scenario. 4.2 Integration Based Access In this scenario the NCCCP site has already in place electronic applications just as HIS/CIS (just as Meditech, Cerner) and they desire to receive and view the CaCIS information and data within the existing application(s) as part of their existing screens and flows. In this type of access integration must take place in back end systems and modification to existing menus and screen are also required. Advantages and disadvantages The advantage to this type of access is familiar user experience and minimal training for end users is required. However it also has several drawbacks. The integration cost is usually high as the software manufactures need to create modifications leading to higher costs. Some of the older systems may also have very limited integration capability meaning third party software packages may be required leading to more costs. At this point this type of access is seen as the least possible deployment scenario. 4.3 Portal based Integration Access Portal integration is seen suitable for an NCCCP that already have an EHR viewer that is portal base. The CaCIS will be simply published as a portlet within the existing portal environment. This should keep the user experience the same and simply introduce the new functionality. Advantages and disadvantages The advantage to this solution is that by use open standards and industry accepted technologies integration should be simple and seamless. It can also lead to lower deployment cost, less training and change management for end users, and a standard based approach to software development and integration. The disadvantage is that an existing portal infrastructure is required and it must be standards based. This is foreseen to be the most common deployment scenario.

11 5.0Security and Privacy Architecture Overview 5.1 Identity and Access Management There are three components to the Identity and Access Management (IDAM) service, authentication, authorization, and federation services. In this section these services are explored in more detail Authentication Service The User Authentication Service a transactional service that builds upon identity management to establish the validity of the claimed identity of a user logging into the system and thereby providing protection against fraudulent transactions, it is also a basic building block for protecting PHI data described in the business context. For the User Authentication Service, the following is a summary of the business requirements: Once a user is authenticated with the CaCIS, the user should be able to access any of the information without having to login again (if the user has the necessary access rights to the information) The User Authentication service should validate the user s identity. Once authenticated, the system should retrieve all accessing trustees and locations associated to the user. The user is then presented with the list of organizations or locations and is required to select one (in the event the user practices and is associated to multiple organizations) Once authenticated, token generation for domain access is performed. The authentication token must contain: the hard expiration time for the token and information important to the referring application (such as a unique user identifier) Enterprise Single Sign On (ESSO) is desired and it is envisioned that it will leverage services and standards such as SAML, WS-Federation, and WS- Trust, etc. Authentication Options The logical flow of user authentication is seen as the following. Every user has a unique CaCIS account in the user registry (most likely an LDAP server). During user registration process, the user can decide on a password. It is possible for the NCCP to use existing AD ID and password is a convenient service available for in a synchronized LDAP scenario. If a user has many AD accounts, he/she can nominate one AD account and password to use. The information is then saved in the master LDAP during the user registration process and set as a flag in the user account. If the user chooses to use AD password, the Authentication service will verify the user password against the AD server, otherwise, the password is verified against the LDAP server. It is also possible to utilize the local AD server as an LDAP server given the LDAP extensions are enabled.

12 Once the user is authenticated, the user is presented with a list of organizations and locations. The user will be prompted to select the organization and/or location: If the user belongs (or affiliated) with one organization, the user will not be prompted to select the organization. If the user belongs to more than one organization, the user will be prompted to select the organization. If the requested CaCIS service depends on location for authorization then the user will be prompted to select the location. The advantage of this approach is that the Authentication service will always forward the authentication request to the source directory, thus avoiding the need for password synchronization. An authentication request will traverse through this architecture based on a OpenSSO model by the following steps: The user attempts to access the CaCIS. OpenSSO intercepts the request, and prompts the user for credentials. The user enters user id and password on OpenSSO login page. OpenSSO verifies user credentials, and depending on the user s authentication option, OpenSSO validates either against CaCIS LDAP or user s AD. Once user is successfully authenticated, the user is presented with a list of organizations or locations associated with their user id. The user selects an organization or location from the list (in the event the user is attached to multiple organizations) The OpenSSO sends an HTTP request to the web-service (any service that the request was issued for) with a token (the user id) in the http header Any web-service should be able to extracts the user id from the header and makes a secure login call as part of the application functionality This architecture can support Web Single Sign On (Web SSO) among other applications as well. For each application which needs to leverage Web SSO, the following requirements must be met: The Application is a web application and can accept and consume OpenSSO token as the authenticated token If the Application currently has its own internal user registry, there will be customization needed to allow the application to use the user registry Authentication Services Authorization is an essential building block for protecting the PHI data; it provides access control methodologies as part of a unified privilege management service for CaCIS. The centralized authorization service is used as a coarse grain authorization engine. The fine grain authorization rules are handled by the application. The following is a summary of the business requirements for the Authorization service: The application interacting with the CaCIS must capture and transmit the Organization-ID (along with User-ID) to establish the authorization context for the user according to their organizational affiliation The Authorization Service must be applied to all requests for access to CaCIS data

13 Authorization is based on the predefined set of roles, attributes and functions The following describes the logic flow of the role based access control: The authenticated user request access to CaCIS services CaCIS Authorization Service gets Roles information from LDAP server based on user membership information The LDAP returns the Role information based on user id and it s enrolment into groups The Authorization Service inspects the role associated with the user to decide if the user has the appropriate role for the service requested The request is either granted or denies based on the role Role Based Access Control Conceptual Flow The following diagram shows the overall architecture for Authorization. The conceptual flow for Role Based Access Control is described in the previous section.

14 Role Access Attributes Exceptions Physician Administration Nurse Pathologist Lab technician Modality Technician Read, Write, Change Read, Write, Change Read, Write, Change Read, Write, Change Read, Write, Change Read, Write, Change Authorization Table Federation Services Federation service is used in order to have the same user id used by end users to access multiple different applications within multiple different organizations. Federation has several well-known and accepted standards established by OASSIS and W3 organization. The most commonly known and used is Security Assertion Markup Language (SAML). The current most commercial version of SAML is 2.0 For the Federation Service, the following is a summary of the business requirements and assumptions: A trust model (business and process) independent of technology is established by participating organizations The User Authentication is completed to organization A prior to establishing a federated authentication to organization B A SAML token with predetermined attributes is exchanged between the organizations The user may be challenged for additional authentication challenge should the assurance level from the source organization be lower than of organization B Federation Scenario A federation exchange will have the following steps given administrative and policy federate exists with organizations: The user attempts to access the CaCIS with a federated id. A SAML token is presented to CaCIS The SAML id is verified for content and the signing authority The signature is validated for accuracy, and authority The userid is extracted from the SAML token and cross referenced with local LDAP for and within the group membership associated with the signing organization

15 If user exists user is authentication and provided with access in accordance to the attributes associated with the local ID If the user doesn t exist the user is created within the appropriate LDAP container and then the appropriate access is granted based on the membership and attributes 5.2 De-Identification Service The de-identification service encompasses two services, anonymization and pseudonimization services. Anonymization service is used to remove personal identifiable health information, however it preserves a mechanism for appropriate and authorized individuals to reassemble the data back into PHI. Whereas Pseudonimized data cannot be reassembled as the way to identify personal information has been completely removed Anonymization Service Anonymization service will be consumed by anyone that needs to provide identity protection. Audit and log files is an example of a consumer as well as any reporting service that needs to anonymize patient information however still track the patient across multiple care episodes. Anonymization service will utilize an algorithm that is known to authorized parties to scramble patient identifiable information. This process can be reversed. It is desired that the anonymization service be offered as a web-service that can be consumed by CaCIS deployments. An ideal solution would be the CaBIG Grid 2.0 with the offering of this service Psuedonimization Service Psuedonimization service is typically required to performing statistical analysis on data to evaluate patient outcomes and is an important component of cancer treatment centers. In the process of doing so, it must be possible for deidentified (i.e. aggregated) or pseudonymized patient information to be used. Most other information such as those stored in audit logs are anonymized. A psuedonimization service is an implementation of a unique algorithm that is able to remove data fields, data types, or any other predefined information and replace with data that is unrecognizable as the source patient. This process is irreversible. It is desired that the psuedonimization service be offered as a web-service that can be consumed by CaCIS deployments. An ideal solution would be the CaBIG Grid 2.0 with the offering of this service. 5.3 XML Security Service Implementing security in SOA is a complex and error prone task for developers. Developers have to contend with a large number of WS*, WS-I, SAML and XACML standards. They have to deal with integration issues between their service and various existing enterprise security infrastutures they want to

16 leverage like LDAP, Kerberos, SSO cookies, SAML tokens, virus scanners, CA authorities, HSM's, SSL termination devices etc. They have to deal with lifecycle issues across dev, test and production. And they have to deal with the vagaries of coordinating security policies and implementation across distributed services and the client applications that call them. XML security service makes security definition and implementation in SOA simple. XML Security service will provide the ability to define and enforce security policy through a point of entry utilized by all b2b services. Defining policies for authentication, coarsegrained authorization, identity federation, data encryption, data signing, data validation, API protection, throttling among other SOA security operations can all be offered and enforced consistently through the XML Security service. The following services will be provided by the XML security service: Coarse-grained service-level access control Message level data validation, privacy, and integrity for incoming and outgoing messages WS*, WS-I enforcement and interoperability Protection against XML threats (including viruses in SOAP attachments) API security for REST and WSDL Identity-based access control for XML / Web services Credential chaining and substitution operations SAML generation and consumption Controls for XML communications Unified audit entries in the audit registry for all b2b services and XML communications 5.4 Non-repudiation Service The purpose of the Encryption Service is to provide cryptographic tools or toolkit that will be used to encrypt PHI to ensure confidentiality. The encryption service includes the creation, renewing, and revoking encryption keys as well as the services (interfaces) to perform encryption and decryption functions. The encryption of data is classified at three levels: 1. Encryption of data in-transit To ensure the confidentiality of data transited between (or any participating component) and the system. 2. Encryption of data at rest within the operational repositories and databases of the system. 3. Encryption of backup data. This level can fall either under (1) or (2), it is classified as a third level to ensure that data is encrypted in transit and remains encrypted at rest (on the tape). The available encryption options to protect data in transit are: Network-level encryption - using VPN IPsec (Point2Point) encryption to complement transport and/or message-level encryption Transport-level encryption Using SSL or TLS to encrypt traffic between systems. Message-level encryption - Using XMLEnc as part of WSSec* services to encrypt all messages ie HL7 v3 message.

17 The above options are not mutual exclusive, for example, a user at home can establish a VPN connection (network-level encryption) and access CaCIS using HTTPS/SSL. The recommended practice with respect to protecting PHI in-transit should be at minimum what is prescribed by IHE ATNA Secure Node Integration Profile. The IHE ATNA Secure Node profile requires that the two participating nodes to mutually authenticate by way of exchanging X.509 certificates. After the secure handshaking and the exchange of certificates, encryption of traffic uses AES-256 (or 128-bit as IHE prescribed) symmetric cipher. Data in-transit is protected using Transport Layer Security protocol (TLS version RFC 2246) messages. For system-to-system, this approach is achievable by installing/configuring a certificate for each participating system. For Portal access over HTTPS, unless client certificates are used, the only authentication that can be performed is server-authentication and the browser node cannot be authenticated by the web server. Therefore, the encryption in-transit can implemented as follows: System-to-system: using mutual authentication over TLS by exchanging certificates and user-to-system using HTTPS/SSL. Encryption of data at rest is not required at this point although it is desired that the systems have this capability should it be required in the future. A recommended approach would be to protect data in active/ operational storage within clinical domains and registries is to use database encryption services ie SQL native encryption or Oracle DataGuard. However, there are issues that must be considered when using this technology such as system performance, additional storage necessary. To ensure confidentiality of data stored in clinical domain, an alternative to native database encryption is to utilize database technologies that lock the database down to prevent highly privileged users (DBA) from accessing the data. Another use for none-repudiation service is to issue certificates as digital identity and signature. Digital identities and signatures are use in order to provide e-prescribing service. 5.5 Security and Privacy Audit Service It is identified that CaCIS must have logging capabilities to record all transactions processed by the system. The log information must include who access information, what was seen or done including the patient information, and it needs to include time stamps. Furthermore these logs must be available for viewing in the event a request is made by an investigating authority such as a privacy officer. The following requirements are identified as those related to audit services: CaCIS must create a secure audit record each time a user (including Administrators): - accesses, creates or updates PHI of the subject of care via the CaCIS - overrides the consent directives of the subject of care via the CaCIS; -attempts to access masked PHI, but is prevented due to the application of the consent directives; - accesses, via the CaCIS, data that is locked or masked by instruction of the subject of care; - accesses, creates or updates registration data on an CaCIS user; or

18 -performs an administrative task on metadata associated with the CaCIS. The audit logs will themselves contain confidential information and must therefore be made both secure and tamper-proof. Audit information may be stored in the CaCIS or a component of CaCIS. To construct an authoritative transcript of which users have accessed a patient/person s PHI or what PHI a user has accessed, all audit records may to be accessible. CaCIS must be capable of logging all transmissions of PHI from another EHR systems. CaCIS must record in an audit log every instance of a user (including Administrators) accessing, updating, or archiving PHI. CaCIS audit logs must contain: - the user ID of the accessing user; - the role the user is exercising; - the organization of the accessing user (at least in those cases where an individual accesses information on behalf of more than one organization); - the PHIN of the data subject of care; - the function performed by the accessing user; - a time stamp; - in the case of access override to blocked or masked records or portions of records, a reason for the override, as chosen by the user making the access; - in the case of changes to consent directives made by a substitute decision-maker, the identity of the decision-maker; and -and other information as determined in detailed P&S design. CaCIS must retain the audit log for the entire retention period of the records audited, to enable investigations to be carried out when necessary and to provide evidence where necessary. CaCIS audit logging must be operational at all times. CaCIS must provide automated analysis tools to assist management and system auditors in the detection and prevention of system misuse (e.g. data harvesting). CaCIS must be capable of identifying of all users who have accessed or modified a given subject of care's record(s) over a given period of time within the retention period. CaCIS must be capable of identifying all Subjects of Care whose records have been accessed or modified by a given user over a given period of time within the retention period. CaCIS must provide functions for analyzing logs and audit trails for patterns of misuse, to allow the identification of all users who have accessed or modified such record(s) over a given period of time. CaCIS must secure access to audit records and must safeguard access to system audit tools and audit trails to prevent misuse or compromise. CaCIS must provide appropriate security measures to protect audit logs from tampering. In order to meet these obligations CaCIS is planning to implement an audit registry that capture what information the users have accessed, viewed or modified within the system and its associating components. These entries are date and time stamp and saved to the audit registry. In turn, these will enable authorities to identify and/or investigate privacy breaches. It is important that the protect the audit registry, and the functionality to compile the logs, from unauthorized access or tampering. The following types of information will be capture in the audit registry:

19 Administrative security events, which includes users, roles, application and organization definition events (e.g., create, update,...) Transactional Security events, which include authentication and authorization events (success or failures). Any data access events, which includes all events related to PUT, LIST and GET transactions. Consent related events, which includes consent directives administrative events (create, update, revoke, ) and consent validate and override events. Operational or application infrastructure event logs, which includes errors/exceptions and performance related event logs to provide insight to the general health of the CIS and its components. Even though, these types of audit records do not include PHI, they are important to ensure accountability for the proper operation of the CIS as a whole. For separation of duties, the operational related event logs is recommended to be stored separate from the other type of logs, given there purpose and audience is entirely different. Note: For security, access, and privacy (consent) audit events, it is recommended that the audit repository is based on IHE ATNA (RFC 3881). It is commonly used and accepted by Healthcare vendors, and it is comprehensive enough for capturing security and data access audit events. Ideally, the Secure Audit Service should utilize the anonymization service to remove PHI from being stored in the audit registry. Therefore the data is protected from incidental disclosure of PHI. In the event access to this data is required, the information is once again reassembled prior to rendering to the authorized party. Although not ideal, encryption is an alternative to encrypt all transactions that contain Personal Health Information using the Nonerepudiation Service prior to storing the transaction in a permanent (write-once) the audit log repository. 5.6 Consent Registry Service As part of conceptual privacy and security requirements CaCIS must have functionality to support consent directive management. More specifically the following functions must be supported: CaCIS must be able to Capture, record, and apply consent directives, apply and communicate consent directives to external systems that CIS communicates with and to be able to consume a consent directive message from an external system and apply appropriate controls CaCIS must be able to lock-box information in accordance with patient's consent directive to restrict access to data element or data type, practitioner, and both data element and practitioner. Patients should also be able to change, remove, or time-box their consent directive. If consent directive exist, CaCIS must inform the practitioner that part or all of health record is blocked from their view due to consent directives. CaCIS must support break-glass capability to deal with consent directives so that practitioners can override consent directives in emergency situations. In the event of break-glass an automated message should be generated to create an investigation and the patient must be informed of the over-ride and the reason for it.

20 The consent registry service is a service that stores all consent directives for all patients. As part of the security architecture of CaCIS, once the information is compiled as a response to a providers request, the ESB will conduct a check against the consent registry prior to submitting the response. This check is done to ensure consent wishes of the patient are applied and in the even of a positive match the information is not sent. Instead a message is send to the requesting provider informing them that due to consent directives the information or part of the information requested has not been sent.

21 6.0 Flow Analysis of Create Referral The following is intended to be an example of a real interaction scenario of all systems and sub-systems in CaCIS. The details around each communication are explained below.

22 6.1 Communication Decomposition The above flow diagram is a create referral and all the interaction of systems, subsystems and security services. It is important to keep in mind that each of these systems, sub systems, and services have their own interfaces, however all communication in the above model is brokered through the Enterprise Service Bus (ESB). 1. Create Referral: During the create referral a request is sent for creating a referral in CaCIS. In this demonstrative process and system flow, the assumption is that the user is not logged in, authenticated or authorized to use the system. Therefore flow 2-5 will facilitate this process. 2. At this stage the ESB is validating against the User Registry if the user exist. If the user does not exist an error message is generated and process flow will terminate. In the event of a federated ID, the very first time the user attempts to log in the user would not exist in the User Registry, however Federated Service will coordinate an automated registration of the user in the User Registry. For more detail on this process refer to Federated Service PIM document. 3. After validating the user, the ESB will send an authentication request to the Authentication Service. This service will receive the user credential (username and password) of the user and validate against its own records before granting authentication. The Authentication Service will comply with all appropriate policies and procedures as part of each deployment site. It is important to keep in mind that in some deployment scenarios this service may already exist as a local service. If the username and password combination do not match the system expected username and password an error is produced, and the flow is terminated. 4. Upon a successful authentication the ESB will then query the Authorization Service for the coarse grain authorization of the user. The coarse grain authorization is simply to determine whether the user has access privilege to the application. As part of this request the membership enrolment of the user is also requested. If the user does not have the permission the use the system an unauthorized message is generated and the flow is terminated. 5. An authenticated and authorized user will receive an authorization token from the ESB that includes the enrolment membership of the user. This allows for the user to access any of the subsystems that the ESB has access to and the user is permitted to access. If the token is not presented, invalid, or expired the user is prompted to authenticate again. 6. At this phase the actual create referral is initiated. The patient is validated by a query made to the Patient Registry. The required patient information is retrieved and passed back to the ESB cached on the ESB. 7. The provider is also validated. The Provider Registry is queried by the ESB and the information is cached on the ESB as part of the request. 8. Similar the step 6 and 7 the location is also validated against the Location Registry and cached. 9. Once the patient, provider, and location have been identified (cached on the ESB as part of the same create referral request) the Consent Registry is queried by the ESB to determine if there are any consent directives that prevent the provider from accessing any information of the particular patient. There may also be some restrictions place on the location where the user is located that may prevent access. These are business decision that are unique to each deployment site and are yet to be developed. In the event of a consent directive block, a message is sent back to the user

23 informing them that they are unable to access information on the patient requested due to consent restrictions. 10. During this step ESB is sending the Create Referral request to the Referral subsystem. 11. Once the referral is created the Referral subsystem will send the response back to the ESB. 12. ESB will forward the response from the Referral subsystem to the requestor that the referral has been created. 13. All the above processes, the success of the process, or any error messages are logged to the Audit Service.

24 14. Appendix A: Conceptual Privacy and Security Requirements PS001 PS002 PS003 PS004 PS005 PS006 CaCIS must have policies in place to inform all users that the data being used by them is confidential and they have the responsibility to protect the confidentiality of PHI. CaCIS must: - account for all health information assets available via the hosted component (inventory of assets), - have a nominated custodian of these health information assets, and - have rules governing the acceptable use of these assets that are identified, documented, and put into practice. Upon access to the CaCIS each user must be informed of the confidential nature of PHI by showing this labeling on any hardcopy printout displaying the data and either: - showing this labeling on any screen displaying the data, or else - displaying this labeling to the user - upon logging into the application and/or as part of an acceptable use policy. CaCIS user organizations must document in job definitions the security roles and responsibilities of staff that are registered users of Healthcare applications such as CaCIS, as laid down in the organization s information security policy. These roles must be defined in a standardized or harmonized manner so as to ensure future interoperability of authentication services between POS systems and the CaCIS. CaCIS user organizations must include in the terms and conditions of employment of employees (permanent, part-time or contracted) who are, or will be, users of the CaCIS, a statement about the employee s responsibility for information security and privacy. It is recommended that a signed acknowledgment be kept. The identity of all users of the CaCIS including permanent, part-time, or contract must be verified. The proof of identity verification must be inline with the assurance level identified my each organization as part of their registration process.

25 PS007 PS008 PS009 PS010 PS011 PS012 PS013 PS014 PS015 User organizations of the CaCIS must ensure that information security education and training and regular updates in organizational security policies and procedures are provided to each permanent or temporary employee or third-party contractor who is a registered user of the CaCIS or who has access to hosted components of the CaCIS. User organizations of the CaCIS must ensure that information security education and training and regular updates in organizational security policies and procedures are provided to their staff and the Vendor and their staff involved with PHI through the CaCIS, or who has access to hosted components of the CaCIS. CaCIS user organizations must, as soon as possible, terminate the user access privileges of each permanent or temporary employee or third-party contractor who is a registered user of the CaCIS or who has access to hosted components of the CaCIS upon termination of their employment with the organization. CaCIS and its components must use security perimeters to protect areas that contain information-processing facilities supporting CaCIS servers, applications or data. These secure areas must be protected by appropriate entry controls to ensure that only authorized personnel are allowed access and they support the minimum requirements as provided by legislation or policy. CaCIS and its components must be hosted in such manner that reduces the risks from environmental threats and hazards. CaCIS solution must be protected from disruptions caused by failures in supporting utilities, e.g. power failure, water damage etc. CaCIS must ensure to securely overwrite or else destroy all media containing CaCIS application software, PHI, or security critical system data when no longer required for use. NCI HER equipment, data or software must not be removed without authorization by the organization's management. CaCIS must control changes to information processing facilities and systems that support the CaCIS by means of a formal and structured change control process to ensure the appropriate control of host applications and systems.

26 PS016 PS017 PS018 PS019 PS020 PS021 PS022 CaCIS user community must, where feasible, segregate duties and areas of responsibility of permanent or temporary employees or third-party contractors who have access to hosted components of the CaCIS in order to reduce opportunities for unauthorized modification or misuse of PHI and security critical system data. CaCIS must have separate development and testing environments for those CaCIS components from the operational environments for those components. Rules for the migration of software from development to operational status must be defined and documented by the organization hosting the affected application(s). CaCIS must monitor capacity demands and project future capacity requirements to ensure adequate processing power and storage will be made available to host those CaCIS components. CaCIS must: - establish acceptance criteria for planned new information systems, upgrades and new versions; - carry out functional and security tests of the system prior to acceptance; and - ensure that all existing PHI and security critical data are continually safeguarded during the upgrade. CaCIS must implement appropriate detection and prevention controls and appropriate user awareness procedures to protect against malicious software (viruses, worms, etc.) CaCIS must: - back up PHI and security critical system data in a manner that ensures the confidentiality, integrity, and availability of the data ; and - store the backed-up data in a physically secure environment off-site - Must encrypt backups on backup media CaCIS, must apply industry standard cryptographic algorithms and protocols during electronic transmission of PHI to maintain the confidentiality and integrity of this data whenever it is transmitted or transported outside the physical security perimeter that protects information processing facilities supporting CaCIS servers, applications or data.

27 PS023 PS024 CaCIS must protect the source and destination of the message against masquerade during data transmission of PHI to maintain its confidentiality and integrity. Where appropriate, the CaCIS must obtain acknowledgement of receipt during data transmission of PHI to ensure that the transmitted data was received. CaCIS will destroy, permanently erase or make anonymous PHI contained on media that are no longer required. Note that this requirement refers to disposal of media, not the deletion of records (i.e., it presumes that relevant data have been copied to other media or exist in other systems prior to media disposal. PS025 PS026 PS027 PS028 Finally, it is also important to note that several high profile lapses in health informatics security have been caused by improper disposal of media. See NIST SP CaCIS must provide a facility to de-identify data sets which could be used for training, testing, R&D and reports. CaCIS must only use sanitized, de-identified test data during testing procedures NCI HER must monitor the status and location of media containing unencrypted security sensitive data, PI or PHI, including user registration data, and ensure this data remains logically and physically protected.