Loading...
The URL can be used to link to this page
Your browser does not support the video tag.
Home
My WebLink
About
29426
vliNLAND -cc. Empire HIE .. IN WITNESS WHEREOF, the parties hereto have executed this Agreement as of the day and year first hereinabove written. CONTRACTOR ~u~ ~Gmen ExECUTIVE DIRECTOR 3993 JURUPA AVENUE RIVERSIDE, CA 92506 Mailing Address DATE: September 1. 2016 FOR ACCOUNTING USE ONLY: ORG No.: 56201-621 Account No.: 7295 Requisition No.: 31 COUNTY OF FRESNO [. ::r ~'-7-~ Ernest Buddy Mendes, Ch rman, Board of Supervisors ATTEST: BERNICE E. SEIDEL, Clerk Board of Supervisors syd.~~'"" DATE: ~ \\,~Oilo RAPPROVAL APPROVED AS TO ACCOUNTING FORM {}.th !It R ../L.e::= ·~------Vicki Crow, C. . . ~ Auditor-Controller!Treasurer-Tax Collector .,.. INLAND \: Empire HIE BUSINESS ASSOCIATE AGREEMENT Signature Page ln witness whereof, Covered Entity and Business Associate have entered into this Agreement as of the Effective Date ofthe Participation Agreement. "Covered Entity" County of Fresno 1221 Fulton Mall Fresno, CA 93721 '"Business Associate" Inland Empire E.H.R. Resource Center, a California 501(c)(3) nonprofit corporation, on behalf of the Inland Empire Health Information Exchange ("IEHIE") project. 3993 Jurupa Avenue Riverside, CA 92506 By: E ~~By:~~~Ot.--Name: EX'li\.O;k ~~ ~ Nam==GreelJ Title: ~~ . ..d. n~~ Title: Chief Executive Officer Date: ~ 1\1d-n\Jo Date: 9 \1\\l q,_ ATIEST: BERNICE E. SEIDEL, Clerk of Supervisors 38 IEHIE Policies and Procedures v2.1.2 1 INLAND EMPIRE HEALTH INFORMATION EXCHANGE (IEHIE) POLICIES & PROCEDURES MANUAL – V2.1.2 CONTENTS REVISION HISTORY ......................................................................................................................... 3 INTRODUCTION .................................................................................................................................. 4 EXECUTIVE SUMMARY ...................................................................................................................... 5 1. OPENNESS, TRANSPARENCY AND PRIVACY .................................................................... 6 1.1. HIE PARTICIPATION REQUIREMENTS .............................................................................................. 6 1.2. NOTICE OF PRIVACY PRACTICES .................................................................................................... 7 1.3. CLEAR NOTICE TO PARTICIPANTS ............................................................................................... 7 1.4. ACCESS TO PHI ................................................................................................................................... 7 1.5. DECEASED INDIVIDUALS .................................................................................................................. 7 2. PURPOSE SPECIFICATION AND MINIMIZATION ................................................................ 8 2.1. ROLE-BASED ACCESS TO PROTECTED HEALTH INFORMATION ................................................. 8 2.2. RESTRICTIONS ON ACCESS TO SENSITIVE INFORMATION ........................................................ 9 2.3. ACCESS TO PATIENT INFORMATION THROUGH THE “CIRCLE OF CARE” ............................... 9 3. USE LIMITATION AND DE-IDENTIFIED DATA .................................................................. 10 3.1. USE LIMITATION .............................................................................................................................. 10 3.2. DISCLOSURE OF PROTECTED HEALTH INFORMATION FOR MARKETING PURPOSES ...... 10 3.3. DE-IDENTIFIED DATA AND LIMITED DATA SETS ...................................................................... 10 3.4. HEALTH PLAN PARTICIPATION ....................................................................................................... 10 3.5. BEHAVIORAL HEALTH ACCESS AND USE ..................................................................................... 11 4. INDIVIDUAL PARTICIPATION AND CONTROL .................................................................. 12 4.1. INDIVIDUAL ACCESS TO DATA ......................................................................................................... 12 4.2. CONSENT ........................................................................................................................................... 12 5. DATA INTEGRITY, AND QUALITY ....................................................................................... 14 5.1. ROLE OF HIE PARTICIPANTS IN MAINTAINING DATA QUALITY AND INTEGRITY ............... 14 5.2. ENCRYPTION AND PROGRAM ACCESS ........................................................................................ 14 6. ADMINISTRATION ............................................................................................................... 15 6.1. ROLES AND RESPONSIBILITIES .................................................................................................... 15 6.2. BREACH NOTIFICATION POLICY .................................................................................................. 19 7. SYSTEM SUPPORT AND MAINTENANCE .......................................................................... 22 7.1. DISASTER RECOVERY PLAN ........................................................................................................... 22 7.2. DISASTER RECOVERY OBJECTIVES .............................................................................................. 22 8. SECURITY SAFEGUARDS AND ACCESS CONTROLS ...................................................... 23 8.1. ACCESS CONTROL POLICY ............................................................................................................. 23 8.2. LOGICAL ACCESS CONTROLS ....................................................................................................... 23 8.3. GRANTING OR CHANGING USER ACCESS RIGHTS AND PASSWORDS ................................. 24 9. OPERATIONAL SECURITY ................................................................................................. 25 9.1. ASSIGNING PRIVACY AND SECURITY RESPONSIBILITIES .......................................................... 25 9.2. ACCEPTABLE USE GUIDELINES ...................................................................................................... 25 9.3. INTERNET ACCESS ACCEPTABLE USE .......................................................................................... 26 9.4. REMOTE ACCESS ACCEPTABLE USE GUIDELINES FOR NON-PARTICIPANTS ........................ 26 IEHIE Policies and Procedures v2.1.2 2 10. ADMINISTRATIVE SECURITY POLICIES ............................................................................ 28 10.1. PRE-EMPLOYMENT BACKGROUND CHECKS ................................................................................ 28 10.2. PERSONNEL EDUCATION SCHEDULE............................................................................................ 28 10.3. EMPLOYMENT TERMINATION SECURITY PRACTICES ........................................................... 28 11. SYSTEM AND NETWORK ADMINISTRATION AND SECURITY POLICIES ........................ 29 11.1. INDIVIDUALS COVERED BY THIS POLICY .................................................................................... 29 11.2. AUDIT TRAIL SECURITY .................................................................................................................. 29 11.3. IDENTIFICATION AND AUTHENTICATION ................................................................................ 30 11.4. ADMINISTRATIVE ACCOUNT MANAGEMENT ............................................................................. 30 12. RISK MANAGEMENT REVIEW S ........................................................................................... 31 12.1. MANAGEMENT AND OVERSIGHT ................................................................................................ 31 12.2. COMPLIANCE MANAGEMENT .......................................................................................................... 31 13. OPERATION OF THE INCIDENT RESPONSE PLAN ........................................................... 32 APPENDIX A – CMIA DISCLOSURE EXCEPTIONS .............................................................................. 33 APPENDIX B – SAMPLE NOTICE OF PRIVACY PRACTICES ................................................................ 37 APPENDIX C – SAMPLE NOTICE OF PRIVACY PRACTICES (SPANISH) ............................................ 39 APPENDIX D – SAMPLE OPT-OUT REQUEST FORM .......................................................................... 41 APPENDIX E – STATEMENT OF UNDERSTANDING............................................................................ 42 APPENDIX F – ACCESS REQUEST FORM .......................................................................................... 43 SUPPLEMENTAL 1: CTEN POLICIES FOR DIRECT PARTICIPANTS ............................................ 47 101. PRIVACY, SECURITY AND CONFIDENTIALITY OF DIRECT SECURE MAIL ................................. 47 102. USER IDENTITY VERIFICATION ....................................................................................................... 50 103. CTEN BREACH NOTIFICATION ........................................................................................................ 53 104. CTEN ENTERPRISE SECURITY ........................................................................................................ 55 105. CTEN REQUIREMENT TO RESPOND .............................................................................................. 56 106. CTEN DUTIES WHEN SUBMITTING A MESSAGE ........................................................................... 57 107. CTEN APPLICABILITY OF HIPAA REGULATIONS ........................................................................... 58 108. CTEN AGREEMENTS WITH PARTICIPANTS ................................................................................... 59 109. CTEN INCOMPLETE MEDICAL RECORD ......................................................................................... 60 1010. CTEN DIRECT MESSAGING CERTIFICATE VERIFICATION PROCESS ........................................ 61 1011. CTEN USE OF MESSAGE CONTENT ............................................................................................... 66 1012. CTEN CONFIDENTIAL PARTICIPANT INFORMATION .................................................................... 68 1013. CTEN SAFEGUARDS ......................................................................................................................... 69 1014. DIRECT SECURE MESSAGING USER SETUP ................................................................................ 71 IEHIE Policies and Procedures v2.1.2 3 Revision History Name Date Reason For Changes Version Rich Swafford 03/20/2012 Initial, IEEHRC Board Approved 1.0 Rich Swafford 10/25/2012 Add, Sec 3, “Health Plan”, “Behavioral Health” policies 1.1 Dawn Goodman 040/4/2013 Change, HITECH Act modifications 1.2 Linda Ackerman 04/04/2013 Change, HIPAA Omnibus Rule compatibility updates 1.2 Leo Pak 05/17/2015 Change, Sec 6, “ED” to “CTO” 1.3 Leo Pak 05/17/2015 Change, Sec 4, “break the glass” to “break the seal” 1.3 Lyman Dennis 10/23/2015 Add, Appx C-F, CTEN Policies for Direct 2.0 Leo Pak 01/27/2016 Change, Sec 11, 72-hour notification of terminated employees 2.0.3 Leo Pak 02/26/2016 Change, Sec 2 – Clarification of User Profiles Change, Appx F – Reflect changes to Sec 2 2.0.4 Leo Pak 03/08/2016 Add, Sec 1.1 – HIE Participation descriptions 2.1.0 Leo Pak 05/03/2016 Change, IEHIE new logo 2.1.1 Leo Pak 06/03/2016 Add, Sec 5 – Encryption procedure Change, Sec 6, 8, 9, 12 – Officer roles and responsibilities Add, Sec 7 – Disaster Recovery Plan Add, Sec 10 – Employee hiring and training practices 2.1.2 4 IEHIE Policies and Procedures v2.1.2 Introduction The IEHIE Policies and Procedures govern the operation of the Inland Empire Health Information Exchange (HIE), and are specific to its function and technology. They set a minimum or base standard for participants in the IEHIE. Participants should develop their own policies and operational procedures accordingly knowing that they may exceed the IEHIE standards but not fall below them. These policies: Set forth the expectations of IEHIE management for the performance, behavior, and accountability for information security and privacy in the operation of the HIE, by all employees, participants, and business associates. Identify policies and procedures governing the protection of protected health information (PHI) and other sensitive information whose transmission is facilitated by IEHIE. Establish an infrastructure and operational guidance for policy implementation, enforcement, exception handling and maintenance. Identify security-related roles and responsibilities. Supplemental IEHIE CTEN Policies (101-1014) address the requirements of the California Trusted Exchange Network (CTEN) and the California Data Use and Reciprocal Support Agreement (CalDURSA). For Direct participants, when the IEHIE CTEN Policies and the Policies and Procedures Manual are in conflict, the CTEN Polices shall take precedence. To ensure that these policies are properly implemented, IEHIE requires all its employees, HIE participants, and business associates to be trained in: procedures governing protected health information (PHI); IEHIE procedures and requirements to maintain compliance with HIPAA Privacy and Security Rule (45 CFR Parts 160 and 164); 42 Code of Federal Regulations (CFR) Part 2: Substance Abuse Records; Welfare & Institution Code (W&I) 5328: Confidentiality of Mental Health Records; and all other federal and State laws and regulations pertaining to the privacy and security of personal health information exchange. 5 IEHIE Policies and Procedures v2.1.2 Executive Summary These policies are organized as follows, according to recognized Fair Information Practices: 1. Openness, Transparency and Privacy IEHIE is committed to developing and maintaining a trust relationship with individuals whose protected health information it facilitates the sharing of through its community health information exchange. In order to do this, IEHIE will be open about its information-handling practices and will strive to maintain the highest levels of privacy and security in its operations. It will also require the same or higher standards of participants in the HIE and business associates as a condition of their participation. 2 - 3. Purpose Specification, Minimization, and Data Limitations The IEHIE will facilitate the sharing and hosting of PHI for patient evaluation and treatment purposes only, although authorized data users may subsequently use information for other legally permitted purposes, including payment and health care operations. Access to sensitive health information is role based and is granted on a need-to-know basis designed to allow access to the minimum necessary amount of data to perform assigned responsibilities. All PHI is subject to federal and state statutory and regulatory requirements, including proper legal process, and to public health exceptions. Data that has been de-identified according to HIPAA standards may be used for other purposes, subject to the strict requirements set forth in these policies. 4. Individual Participation and Control Individuals will have the ability to opt-out of having their protected health information shared through the HIE. They will be able to request information about who has requested and received their PHI through the HIE. In the event an individual opts-out of the HIE, their information will continue to be collected and managed; however, no access will be provided to that information with out the expressed consent of the individual. 5. Data Integrity and Quality The success of the HIE depends upon its ability to provide the most complete, accurate and up- to-date information possible. IEHIE maintains the highest security standards to protect data and expects HIE participants to do the same. Participants are also responsible for the quality of data they provide to the HIE in response to user requests. 6 - 7. Organizational Administration, System Support, and Maintenance IEHIE aspires to the highest standards of performance in the administration and management of the organization. Roles and responsibilities are assigned in order to meet the operational privacy and security requirements of the HIE and business associates. 8 - 13. Security Safeguards and Access Controls Because safeguarding protected health information is the highest priority of IEHIE, the greater part of these Policies and Procedures is concerned with security safeguards and access controls. IEHIE maintains the best possible security technologies and procedures that are compatible with its business purpose of locating data and facilitating its exchange between providers and users. 6 IEHIE Policies and Procedures v2.1.2 1. Openness, Transparency and Privacy Openness about developments, procedures, policies, technology, and practices with respect to the treatment of protected health information (PHI) is essential to protecting privacy. Individuals should be able to understand what information exists about them, how it is used, and how they can exercise reasonable control over it. Transparency encourages a commitment to strong privacy practices and instills patient confidence in the privacy of their information, which in turn increases participation in health information exchanges. 1.1. HIE Participation Requirements Only persons who enter into Participation Agreements with IEHIE shall be permitted to access the System and use the Services. A participant must act as a Data Provider and a Data Recipient, as described in this Section 1.1.1. A participant may use some or all of the Services, as specified and in accordance with Section 1.4 (Description of Services) and Exhibit C (Fees and Payments) of that participant’s Participation Agreement. 1.1.1. Participant Type Any party may inquire to enter into a participation agreement with IEHIE. IEHIE shall not be required to approve any inquiry to be a participant. IEHIE will review all requests to join the HIE, but applicants must have a use for clinical data. The following list seeks to categorize applicants into their respective roles in the healthcare system, but is only meant to be illustrative, not exhaustive. Examples of Participant Types include: a) Physician, medical group, or independent physician association; b) Laboratory; c) Hospital; d) Public health agency; e) Emergency medical services (EMS); f) Pharmacy; and g) Health plan, insurer, or other payor. Each IEHIE participant is expected to be both a Data Recipient and a Data Provider*, and therefore subject to both provisions in Section 6 (Data Recipients’ Use of System and Services) and Section 7 (Data Providers’ Use of System and Services) of the IEHIE Participation Agreement. “Data Provider” means a participant that is registered to provide information to HIE for use through the Services. IEHIE receives labs, radiology reports, discharge summaries, consultations, electronic orders, demographic and financial data, discharge summaries, and chart notes, as well as other data types that may be deemed appropriate or necessary in the future. “Data Recipient” means a Participant that uses the Services to obtain health information. *With the approval of the IEHIE Governing Council and management team, a participant may, under certain circumstances or specific use cases, be permitted to become a Data Recipient-only. Participants approved as Data Recipients-only will have their agreements reviewed from time to time, and not less than annually, to determine if it is appropriate for them to begin sharing data as Data Providers. 7 IEHIE Policies and Procedures v2.1.2 1.2. Notice of Privacy Practices IEHIE will publish a Notice of Privacy Practices that meets the requirements of the HIPAA Privacy rule (45CFR 164.520(b)), and includes all necessary information as outlined in the Policies and Procedures Manual, although it is not legally required to do so. 1.3. Clear Notice to Participants IEHIE also expects each participant to have its own Notice of Privacy Practices, consistent with these Policies and Procedures, and in compliance with applicable laws and regulations. A sample Notice of Privacy Practices and Consent are included in Appendix B and Appendix C (Spanish-language version). IEHIE will respond to requests for protected health information (PHI) for treatment and other legally permitted purposes only. Since HIPAA notice requirements specify that patients must be informed how their information may be used and disclosed, HIE participants must clearly notify patients that their PHI, and specifically what kinds of PHI, may be shared with other participants in the HIE. Section 164.520 also requires that patients be informed how they can access to their medical information and Sections 164.524 and 164.528 sets out the disclosure requirements for covered entities. IEHIE accordingly expects all HIE participants to inform patients how they can access their medical records and request information about the disclosure of those records. HIE participants, and not IEHIE, shall provide such information. 1.4. Access to PHI Access to PHI has different use cases for different situations. 1. “Break the glass” is an activity whereby a provider who requires access to a patient’s PHI when that patient has expressly opted out of sharing their PHI with the HIE. In a situation where the patient is unable to give consent (for example, if they are unconscious), the provider will “break the glass” to access their PHI in lieu of an explicit consent. 2. “Break the seal” is an activity whereby a provider without a previously established relationship, such as “circle of care or facility relationship” with the patient and requires access to the patient’s PHI via a “break the seal” activity to document the rational for access. Since the IEHIE maintains an opt-out consent management policy, facilities and providers are far more likely to “break the seal” of known care boundaries rather than “break the glass” of a patient’s expressly withdrawn consent from sharing their PHI. Both authorizations produce required audit trails to examine the provider who accessed the PHI and the reason for the access. 1.5. Deceased Individuals It is IEHIE policy that privacy protections extend to information concerning deceased individuals. An HIE participant that is a covered entity may, but is not required to, use or disclose for any purpose the PHI of individuals who have been deceased for 50 years or longer, although a covered entity is not required to retain records for 50 years. 8 IEHIE Policies and Procedures v2.1.2 2. Purpose Specification and Minimization Data requests by participants or their business associates should be limited to only what is necessary to accomplish specified purposes. In the IE health information exchange, these purposes must be for treatment and health care operations only. Strict minimization is intended to help reduce privacy violations, which can easily occur when data is collected for one legitimate reason and then reused for different or unauthorized purposes. Along with minimization of use, the purpose for which HIE participants collect PHI should be specified at the time of data collection. This includes notification that one purpose of collection is for sharing of PHI through the IE health information exchange. 2.1. Role-Based Access to Protected Health Information It is IEHIE policy that access to protected health information received as the result of a request to IEHIE must be granted to each HIE participant, employee or business associate based on their assigned job functions. Such role-based access privileges should not exceed those necessary to accomplish the assigned job function. Access to PHI by HIE participants is also based on defined roles or profiles. For additional information on role-based access, see Section 8.1 “Access Control Policy.” The following user profiles and descriptions are established in the IEHIE environment: Level 1 – Primary Provider: Designed to access all clinical content available within the Clinical Data Repository (CDR). This role will assume responsibility to unfetter access to full clinical information as is aligned to access privilege under HIPAA to support point of care clinical treatment. o Full access to all clinical views, including sensitive data o May “break the seal” to access patient information without an established relationship o May “break the glass” for patients who have chosen to opt-out of the IEHIE o Access to patient notifications o Access to Direct Secure Messaging (additional feature) Level 2 – Secondary Provider: Designed to access limited clinical content available within the Clinical Data Repository (CDR). This role will assume responsibility to access non-sensitive clinical content within the CDR to support point of care clinical treatment. o Full access to all clinical views, but NOT sensitive data o May “break the seal” to access patient information without an established relationship o Access to patient notifications o Access to Direct Secure Messaging (additional feature) Level 3 – Reporting: Designed to obtain non-clinical information via utilization reports. Level 4 – Front Desk: Designed to access patient information to provide administration services to their supporting organization. It is not intended to support point of care or clinical treatment. Level 5 – HIE Administrator: Designed to support the operational nature of providing user access controls and onboarding of facility user. It is not intended to support point of care for clinical treatment. o Access to user administration and auditing screens o Access to Direct Secure Messaging (additional feature) 9 IEHIE Policies and Procedures v2.1.2 Level 6 – HIE Chief Privacy Officer: Designed to support auditing capabilities with access to usability reports and basic configurations of the system. It is not intended to support point of care for clinical treatment. o Access all patient administration screens to manage consent o Access to Direct Secure Messaging (additional feature) Clinical Portal Access Level 1 Level 2 Level 3 Level 4 Level 5 Level 6 Access to Clinical Data (including sensitive) X May “break the glass” for patients who have chosen to opt-out of the IEHIE X May “break the seal” to access patient information without an established relationship X X Access to patient notifications X X Direct Secure Messaging - Additional Feature X X X X Access to Clinical Data (non-sensitive) X Patient Administration – Consent Management X User Administration X 2.2. Restrictions on Access to Sensitive Information Data maintained in the patient record that is sensitive in nature, is flagged as such by the system. This serves as a warning to users that they are about to access a record with sensitive data. The IEHIE user authorization model allows for the creation of user classes that do not have access to sensitive records. Management may also create user classes that restrict access to records based on a proven relationship between a patient and a physician. Examples of sensitive data include but are not limited to: information related to minors, and to sexual and mental health, and substance abuse. Sensitive data criteria will be reviewed to ensure changes are included in the policy restrictions. Data kept online is also secure from non-authorized users accessing a terminal on the customer’s site through application level security. All access is by username and password. Each username is allowed certain right of access. Communication between the Participants browser and the application server happens over a secure channel through the use of an expiring one-time session key that maintains the user’s session until a time- out or log-off (which ever happens first). The expiring nature of the session prevents unauthorized access when the user leaves the terminal unattended while logged in. 2.3. Access to Patient Information Through the “Circle of Care” Each patient within the HIE’s clinical data repository (CDR) maintains a list of providers and facilities with a clinical link to that patient called the “Circle of Care”. When a patient is seen by a particular provider and/or in a particular facility, that provider and/or facility is added to the circle of care. A facility or provider not in the circle of care does not have access to the patient information unless the provider or facility has “Break the Seal” privileges. Primary Care Providers will remain within the circle of care for a period of 36 months and referring providers will remain for 18 months following the most recent update of information to the patient record in the exchange. 10 IEHIE Policies and Procedures v2.1.2 3. Use Limitation and De-Identified Data IEHIE will facilitate the sharing and hosting of PHI for treatment and other legally permitted purposes, including payment and health care operations, provided there is an established treatment relationship with the patient whose data is requested. HIE users’ access to PHI is conditioned on their acceptance of these limits. Subject to certain exceptions discussed below, only data that has been properly de- identified may be used for certain other purposes. 3.1. Use Limitation In addition to the limitations set forth in Section 3, above, certain statutory exceptions contained in California Civil Code Sec. 56.10(b), including those for law enforcement and public health reporting requirements, may permit or require disclosure of data for other purposes. A complete list of these exceptions and the type of authorization they require, where applicable, is attached as Appendix A to this document. 3.2. Disclosure of Protected Health Information for Marketing Purposes IEHIE will not release personally identifiable information from the HIE for any marketing purposes, excluding the permitted purpose of sending prescription refill reminders. Regulatory resources for disclosure of information: 1. 45 CFR 164.514, other requirements relating to uses and disclosures of protected health information; 2. California Medical Information Act (CMIA) California Civil Code Section 56.10, Disclosure of Medical Information by Providers. 3.3. De-identified Data and Limited Data Sets IEHIE may use data that has been de-identified or that is a limited data set according to HIPAA standards without consent or authorization. The CMIA also permits such use of de-identified data (Civil Code Section 56.05(g)). The standard for de-identification is that there is no reasonable basis to believe the data can be used to identify an individual. Data that has had 18 specific elements of individually identifiable information removed is considered de-identified under HIPAA. (45 CFR 164.514) IEHIE may use “limited data sets'' for specified purposes (e.g., public health reporting, research, and health care operations), without authorization or a waiver of authorization, pursuant to a data use agreement with the recipient. A limited data set is not the same as de-identified data, but it has been stripped of almost all personal identifiers. (45 CFR Section 164.514(e)(2)) 3.4. Health Plan Participation A health plan or health insurance provider may participate in the exchange with the sole purpose of providing case management for those patients with current eligibility or an eligibility hold status. Health Plan participants are considered Level 3 providers (as outlined in Section 2.1) with no capacity to “break the seal” or access the record of a patient for whom current enrollment and eligibility have not been 11 IEHIE Policies and Procedures v2.1.2 established. Health Plan participants may perform population-level reporting of currently enrolled and eligible patients in a de-identified manner for the purpose of performing chronic illness or population management activities. 3.5. Behavioral Health Access and Use Behavioral Health providers may access clinical information in the HIE in order to provide care within the behavioral health setting. Behavioral health providers are considered Level 1 based upon the configuration to allow explicit permission to view such data as outlined in section 2.1. 12 IEHIE Policies and Procedures v2.1.2 4. Individual Participation and Control Individuals have the right to request and receive in a timely and intelligible manner information regarding who has their health data and what specific data the party has, to know any reason for a denial of such request and to challenge or amend any such data. Because individuals have a vital stake in their own PHI and the privacy of that information, its collection and use should be transparent to them. Individual participation promotes data quality, and confidence in privacy and security practices. 4.1. Individual Access to Data IEHIE retains demographic data in the Master Patient Index (MPI) and Record Locator System (RLS) and clinical data. Patients who become aware of errors in their demographic or clinical data either through access to the Patient Portal or through their treating physician should request that the HIE participant that provided the incorrect data to the MPI or RLS correct that data. Patients who wish to access their Protected Health Information (PHI) stored in the HIE, or obtain information about who has requested or received their PHI may request that the HIE participant release such data to the Patient Portal for such access. HIE participants must fulfill patients’ requests within the timeframe required by the HIPAA Privacy Rule 164.524, “Access of individuals to protected health information.” Participants that maintain EHRs (electronic health records) must account for all disclosures of PHI for treatment, payment and health care operations made up to three years prior to the date of the request. Participants have 30 days to fulfill requests for electronic records and also for records in any format that are stored off-site. 4.2. Consent IEHIE allows individuals to choose whether to have their information included in the HIE. Patients may choose to opt-out of electronic data sharing at their initial point of contact with an HIE participant. It is the responsibility of IEHIE participants to notify patients of their choice to share their information with IEHIE through material provided by the IEHIE participant, not IEHIE. Failure to opt-out results in being automatically opted into the HIE. For opt-out requests made directly to the IEHIE, participants or patients can utilize the Sample Opt-Out Request Form, included as Appendix D. The Sample Opt-Out Request Form is not intended to be used in place of Notice of Privacy Practices. Validation of a patient’s consent to share information through the HIE is one factor taken into account by the IEHIE system in facilitating participants’ access to medical records. This protection makes individuals active participants in the process of sharing electronic health information. Also, patients’ ability to allow the use of their data, or not, will help them understand the conditions under which information might be used and promote confidence in the security surrounding the use of their data. 4.2.1. Effect of Individual Choice A patient’s choice not to allow PHI to be made available shall be exercised through HIE participants; at a patient’s request, their PHI will no longer be visible in the HIE. While that patient’s data will reside in the HIE, access to such information will be based on the patient’s level of consent. For example, a patient may choose to “opt-out” of the HIE for his or her primary care provider, but remain active for the purpose of emergency care. In this case, the patient may determine his or her optimal access conditions. 13 IEHIE Policies and Procedures v2.1.2 4.2.2. Revising Individual Choice Someone who has previously chosen to opt-out of the HIE, and who later wishes to opt-in may do so. This choice shall be exercised through HIE participants, who will then notify the IEHIE. Patients must notify IEHIE in writing of the change, not only the participant who is the patient’s initial point of contact with the health information exchange system. A decision to opt-out after having previously opted in shall not be retroactive as to information already released through IEHIE, but it will restrict future dissemination of data retained by properly notified participants. 4.2.3. Provision of Coverage or Care No one may be denied coverage or care based on a decision to opt-out of the HIE. 4.2.4. Patient Identification Process Protects Privacy IEHIE patient identification mechanisms afford additional protection to protected health information through the Master Patient Index (MPI) and Record Locating System (RLS). Both employ probabilistic matching to determine if a requested patient’s information is in the system and to ensure with a high degree of certainly that the correct patient’s records have been identified. 14 IEHIE Policies and Procedures v2.1.2 5. Data Integrity, and Quality 5.1. Role of HIE Participants in Maintaining Data Quality and Integrity IEHIE participants must develop policies and procedures to verify the quality and integrity of the data they provide to those who request it through IEHIE. This should include policies related to data access (i.e., “minimum necessary” standards) and technical security and controls. Policies and procedures should include at a minimum all requirements under HIPAA, and other state and federal regulations related to the use and disclosure of personal health information among covered entities. 5.2. Encryption and Program Access Because IEHIE is strongly committed to ensuring the confidentiality and integrity of data that is shared through the HIE, it uses either encryption or some other form of secure messaging for any transmission of sensitive information or data. All data providers who participate in the HIE must encrypt PHI prior to transmission. The IEHIE information exchange system includes a progressive strategy of assimilating encryption into applications as the technologies mature. Encryption is required for all of the following: • Data housed in the HIE is “encrypted at rest”. • Sensitive information stored on portable devices. • Passwords of all systems accessing sensitive information on public networks. Verification of system and device encryption, and access to all company and HIE system programs is verified monthly and is the responsibility of the HIE Chief Compliance Officer. 15 IEHIE Policies and Procedures v2.1.2 6. Administration This policy establishes formal guidelines for assigning responsibilities and duties related to managing and operating IEHIE systems, policies and procedures. In order to effectively implement and enforce information security and privacy throughout IEHIE operations specific roles and responsibilities have been assigned to the Board of Directors, the Chief Compliance Officer, and IEHIE management. The Board will periodically assess the capabilities and expertise of staff and outside business associates, vendors and other third parties to ensure that all systems and services are effectively managed and that responsibilities have been assigned that accomplish IEHIE security and privacy program objectives and also segregate roles to assure adequate oversight. The roles and responsibilities assigned in this policy impact the entire organization, along with participants in the HIE, individual consumers, business associates, vendors and third parties. 6.1. Roles and Responsibilities The Board of Directors has ultimate responsibility for oversight of systems, data security and technology integration for delivery of IEHIE services. The Board has assigned oversight responsibility for the Information Security Program to the Chief Technology Officer (CTO). The CTO will also manage the Information Security Program and the Privacy Program. Depending on levels of staffing, the CTO may delegate management of the Privacy Program to another qualified employee. IEHIE managers and key staff are assigned responsibilities as defined in the guidelines below. 6.1.1. IEEHRC Board of Directors The IEEHRC Board of Directors shall oversee the development, implementation, maintenance and enforcement of the Policies and Procedures, approving the initial policies and all subsequent changes to them. The Board shall assign specific implementation responsibilities, mindful of the need for proper segregation of duties in making these assignments. The Board shall periodically review and audit the Policies and Procedures Manual to ensure that they are compliant with regulatory changes and that appropriate controls are in place to manage risks successfully. At a minimum, the Board shall review an annual information security report presented by the Information Security Officer and a privacy report presented by the HIE Chief Compliance Officer or other qualified employee acting in that capacity, which includes updated assessments of security and privacy risks and policy adjustments necessary to address them. To ensure continued alignment of the Policies and Procedures with risks and consistent enforcement of the standards and guidelines they establish, the Board has delegated responsibility for oversight of these policies to the CTO. 6.1.2. Duties of the Chief Technology Officer The Chief Technology Officer (CTO) and Chief Officers of Privacy, Security, and Compliance will meet to review the Policies and Procedures and recommend changes to the Board. Reviews will include standard agenda items to analyze losses due to cyber events, security assessments, audits and other management reports. With this information, the CTO shall determine whether appropriate controls are deployed and are being enforced to successfully manage risk in accordance with the Policies and Procedures Manual. 6.1.2.1. Risk Management 16 IEHIE Policies and Procedures v2.1.2 The CTO is assigned duties to ensure the effective management of the physical and technological risks affecting all IEHIE systems and networks in accordance with the Policies and Procedures Manual. 6.1.2.2. Security Monitoring The CTO must perform all of the duties related to security monitoring as specified in the Policies and Procedures Manual. 6.1.2.3. Internal Auditing and Testing IEHIE HIE systems will be audited periodically and the results reported to the Board of Directors. The CTO and the auditor shall track all exceptions; the CTO will prepare a response for deficiencies identified in the audit report. The CTO will use the following audit schedule conducted by its system vendor Orion Health Incorporated to perform this reporting: Quarterly Review of corporate firewall rules, updating of policies to address new/removed rules and their justification Review of stored data on corporate network to determine if stored data is exceeding the data retention requirement. If so, extraneous data will be purged according to accepted standards (Department of Defense standard 5220-22M). Review of changes to network that may require penetration testing Application of non-critical system-level patches Penetration testing of all networks in hosting facilities Monthly Run wireless sniffer at corporate office, data center facilities Weekly Evaluation of newly discovered security vulnerabilities with recommendations for action Review of video camera data Daily Review of event/security logs Ongoing security checks such as third-party intrusion detection hardware Results will be reported to the IEEHRC Board in accordance with the Policies and Procedure Manual. 6.1.2.4. External Examination The CTO will supervise an independent annual review of the effectiveness of the IEHIE information security program. This may include evaluating system security parameters and profiles such as access controls, password strength, staff training, start-up files and log-in violations. See generally, Section 9 “Operational 17 IEHIE Policies and Procedures v2.1.2 Security.” All assessments will be presented to Board of Directors to assist in their understanding of threats and hazards to protected health information and systems. 6.1.2.5. Staying Current with Security and Privacy Technology, Laws and Regulations The IEHIE will operate at the most current level of privacy and security laws and regulations and will stay current with any changes in those laws and regulations in order to: • Support the research, development, distribution, and maintenance of information security and privacy policies that comply with all federal and state laws and regulations. • Maintain an active oversight role of new or improved products, services and technologies. 6.1.3. Duties of the Chief Privacy Officer The HIE Chief Privacy Officer (CPO) oversees that all IEHIE personnel are responsible for protecting all PHI information assets and is ultimately accountable for ensuring all personnel know, understand and follow the privacy policies. 6.1.4. Duties of the Chief Information Security Officer The HIE Chief Security Officer (CSO) has primary responsibility for the security of IEHIE systems, and must establish a monitoring and reporting program that is outlined in the Policies and Procedure Manual and includes at a minimum risk management reviews with Orion Health Systems and reporting to the IEEHRC Board. 6.1.5. Duties of the HIE Chief Compliance Officer The HIE Chief Compliance Officer (CCO) has primary responsibility for day-to-day oversight of information security at IEHIE. IEHIE outsources its information services and the CCO is responsible for maintaining those appropriate contracts and delegation agreements and for continuous oversight of operations. IEHIE is responsible for all operational services, whether performed by its employees or outsourced to third parties. 6.1.6. Duties of the Security Incident Response Team The IEHIE Security Incident Response Team (SIRT) is an identified cross-disciplinary group entrusted to provide effective leadership in the event of an Information Services-related security incident. SIRT will include technical staff whose role is to halt or minimize the effects of an incident and facilitate speedy recovery. It will also include IEHIE personnel with the authority to make governing decisions, and individuals who can appropriately communicate messages about the incident to external parties. The SIRT may include the Chief Technology Officer, Chief Compliance Officer and/or Participant Representatives from the stakeholders of the HIE. 6.1.7. Duties of Employees, Contractors and Temporary Staff IEHIE employees are responsible for safeguarding all sensitive, confidential or personally identifiable information collected, retained or transmitted by IEHIE, from unauthorized access, modification, 18 IEHIE Policies and Procedures v2.1.2 destruction, or disclosure, whether accidental or intentional. In addition, they are responsible for complying with this and all other IEHIE policies defining computer, network and information security and privacy measures. All employees, contractors or temporary staff members with access to sensitive, confidential or personally identifiable information must sign an Access Request Form and acknowledge willingness to comply with these Policies and Procedures in a signed Statement of Understanding, included here as Appendix E. The HIE Chief Compliance Officer shall be responsible for verifying, logging, enforcing, and auditing the Statement of Understanding for relevant staff and contractors on an annual basis, at minimum. All employees, contractors and temporary staff are expected to: • Protect the security and confidentiality of sensitive, confidential or personally identifiable information transmitted by IEHIE systems and networks. • Use IEHIE resources only for the purposes specified. • Comply with the security controls and guidance established by IEHIE. • Notify the proper level of management of security breaches. 6.1.8. Duties of IEHIE Business Associates The IEHIE Information Security and Privacy programs and policies require that business associates such as service partners and vendors entrusted with aspects of IEHIE sensitive operations also develop and enforce their own information security and privacy programs that are equivalent to or more stringent than the IEHIE Policies and Procedures. • IEHIE relies on a third party for hosting web operations, and may also rely on a third party for security scanning at regular intervals. • IEHIE uses operating systems and network devices, and relies upon respective vendors for secure functionality and timely release of necessary security patches. 6.1.9. Duties of Legal Counsel IEHIE may require the services of legal counsel from time to time, to provide critical guidance concerning legal matters (e.g., incident liability, partnership and business associate agreements, etc.). IEHIE has contracted with legal counsel who is knowledgeable about HIPAA and the California Confidentiality of Medical Information Act (CMIA), as well as other federal and state laws and regulations relevant to electronic health information exchange. 19 IEHIE Policies and Procedures v2.1.2 6.2. Breach Notification Policy California law and HIPAA and HITECH Act regulations impose very specific notification requirements on covered entities and their business associates in the event of a breach of unsecured personal health information. This policy represents the IEHIE’s implementation of breach notification requirements found in 45 CFR 164.402, Subpart D and California Civil Code Sec. 1798. For Direct participants, breach reporting requirements are described in CTEN Policy 103. 6.2.1. Breach Defined California Civil Code Sec. 1798.82 requires notification when unencrypted personally identifiable information, including PHI, is “reasonably believed to have been, acquired by an unauthorized person.” The federal notification standard is now equivalent to California’s. The standards for assessing whether notification is required are in Section 6.2.3, below. The current applicable standards are as follows: For electronic PHI at rest, data that have been encrypted using a process consistent with National Institute of Standards and Technology (NIST) Special Publication 800-111, Guide to Storage Technologies for End User Devices. For electronic PHI in motion, data that have been encrypted using a process that complies with the requirements of Federal Information Processing Standards (FIPS) 140-2. Paper, film or other hard copy media that have been shredded or destroyed such that the PHI cannot be read or otherwise cannot be reconstructed. Electronic media that have been cleared, purged or destroyed consistent with NIST Special Publication 800-88 6.2.2. Who Is Covered by Breach Notification Requirements? All covered entities and business associates, as defined by HIPAA and the HITECH Act, must provide notification of breaches if the conditions described in this policy are met. All business associates of covered entities are required to inform the covered entity with which they have a business associate agreement of known or suspected breaches, as well as breaches they should have known about through the exercise of reasonable diligence. All subcontractors of business associates are required to inform the business associate with which they have a business associate agreement of known or suspected breaches, as well as breaches they should have known about through the exercise of reasonable diligence. Business associates must inform covered entities of a breach without unreasonable delay, but in no case later than 60 days after discovering the breach. 6.2.3. Assessment of Need for Breach Notification Breach notification may be triggered by the unauthorized acquisition of unencrypted personal health information. In order to determine whether a breach requires notification to affected individuals, a covered entity must assess the risk that PHI has been ‘‘compromised’’ by a data breach. Such an assessment must take these four factors into account: The nature and extent of the PHI; The unauthorized person who used or received the PHI; 20 IEHIE Policies and Procedures v2.1.2 Whether the PHI was actually viewed or acquired; and The extent to which the risk to the PHI has been mitigated (e.g., by encryption or de- identification). All actions taken to assess risk that PHI has or has not been compromised must be carefully documented, because IEHIE has the burden of proving to the Secretary of HHS why notification is not required. 6.2.4. Exceptions to Breach Notification Requirements Section 164.402 of the HIPAA regulations provides three exceptions to the definition of a breach, which IEHIE will take into account in assessing whether a breach has occurred: A workforce member who unintentionally accesses or uses PHI in good faith does not trigger a breach. An inadvertent disclosure between two individuals authorized to access PHI at the same covered entity, business associate, or organized health care arrangement is not a breach. A disclosure where the covered entity has a good faith belief that an unauthorized person to whom the disclosure was made would not reasonably have been able to retain the PHI is not a breach. 6.2.5. Who Must Be Notified In the event of a data breach that requires notification, the provisions below shall apply. 6.2.5.1. Affected Individuals IEHIE is responsible for notifying all individuals whose unsecured PHI has been or is reasonably believed to have been breached; that is, when it is reasonably believed to have been acquired by an unauthorized person and no exception applies. 6.2.5.2. Media IEHIE will work with the covered entities to determine who will notify and manage the prominent media outlets in the counties where affected individuals reside in the event of a breach of the unsecured PHI more than 500 individuals within the area of the state where IEHIE facilitates the sharing of such information. 6.2.5.3. Secretary of HHS IEHIE will notify the Secretary of Health and Human Services within 60 days by means determined by HHS of all breaches of unsecured PHI involving 500 or more individuals. HHS will post information concerning breaches of this size on its web site. IEHIE will maintain a log of breaches concerning fewer than 500 persons to submit annually to the Secretary of HHS. 6.2.5.4. Timeliness A breach is considered to have occurred either on the day it was discovered or the day when, in the exercise of reasonable diligence, it should have been discovered. “Reasonable diligence” means the level 21 IEHIE Policies and Procedures v2.1.2 of business care and prudence expected from an individual satisfying a legal requirement. Since IEHIE and its business associates are liable for failing to notify of a breach they did not know of but should have known in the exercise of reasonable diligence, IEHIE will adhere to security procedures and auditing policies that minimize to the greatest extent possible the likelihood of a breach going undetected. Once a breach is discovered, IEHIE will work with covered entities to determine who will provide notification to all individuals whose PHI has been or is believed to have been acquired by an unauthorized person without unreasonable delay and in no case later than 5 business days after the discovery. California’s notification period is far more stringent than federal requirements. The same timeliness requirement applies when the size of the breach requires IEHIE to notify media outlets. Notification time for breaches reported by business associates begins when they are discovered, not when they are reported to IEHIE. 6.2.6. Content and Methods of Notification The breach notification standards described below shall apply. 6.2.6.1. Content of Notice IEHIE will work with covered entities to determine who will provide individual breach notifications that are written in plain language and include all the elements required by HHS in accordance with Civil Code 1798.82(b) which exceeds the HITECH Act breach notification requirements. 6.2.6.2. Methods of Notice IEHIE will work with covered entities to provide written notice to all individuals affected by a breach by first- class mail at their last known address. E-mail notice will be substituted for individuals who have previously agreed to electronic notice. In the case of minors and persons lacking capacity, IEHIE will notify parents or legal representatives. If IEHIE knows that an affected individual is deceased, it will notify the next of kin or a legal representative if it has such person’s address. If IEHIE or a covered entity has no address for an affected individual or a notification is returned as undeliverable, IEHIE or the covered entity will provide substitute notice as soon as reasonably possible. If fewer than ten people are involved and the information is known, substitute notice may be by e-mail or telephone. If more than ten affected individuals cannot be notified by first-class mail, IEHIE or the covered entity will provide substitute notice by conspicuously posting the breach and remedial information on its web site or through major media outlets in the areas where the affected individuals reside. Such public forms of substitute notice will not include the names of affected individuals, but will ask all patients of IEHIE participants to call a toll-free number to find out if their PHI has been compromised by a breach. To facilitate this, IEHIE will maintain a toll-free telephone number for at least 90 days after publicly posting a breach notification. 22 IEHIE Policies and Procedures v2.1.2 7. System Support and Maintenance IEHIE aspires to the highest standards of performance in the administration and management of the organization. Roles and responsibilities are assigned in order to meet the operational privacy and security requirements of the HIE. IEHIE has secured services for the operation of the hardware, software and management of the HIE operations from Orion Health Systems. The Operations Agreement outlines the roles and responsibilities for system support and maintenance. 7.1. Disaster Recovery Plan Since IEHIE has secured operations and management services of the HIE operations from Orion Health Systems, their Disaster Recovery Plan informs any response in the occurrence of a catastrophic disruption. The Disaster Recovery Plan documents and describes the activities and initiatives to anticipate and manage an IT failure. In support of of the SaaS Business Continuity Program, the IT disaster recovery plan provides reliable and repeatable processes that support recovery of critical systems and applications within the agreed upon recovery time objective. The mission of disaster recovery is proactive protection and resumption of critical SaaS infrastructure for defined failure scenarios with minimal impact to clients through ongoing controllership to test, validate, and improve the plan. 7.2. Disaster Recovery Objectives The Disaster Recovery Plan is Commercial in Confidence, so a high level description of functions will be described here. The Disaster Recovery Architecture is set up to provide for a continuous flow of data from the Production facility to the Disaster Recovery (DR) Facility. Backups are processed daily, and any switch over to the DR Facility would result in the most up to date data present and available to participants, up until the last 10 minute segment from the Production facility is received. 23 IEHIE Policies and Procedures v2.1.2 8. Security Safeguards and Access Controls Security safeguards are essential to preventing the loss, corruption, unauthorized use, modification and disclosure of data. Networked data is particularly vulnerable to unauthorized exposure. Adequate controls, rigorously enforced, are essential to protecting the security and privacy of networked information. The design and implementation of policies and technical security precautions governing access to IEHIE systems are necessary to providing effective information privacy. 8.1. Access Control Policy Individual access to IEHIE systems and data they transmit is subject to strict controls. 8.1.1. Role-Based Access Role-based access, dependent on a user’s proven “need to know” and granting the minimum necessary access to meet the responsibilities of a given job, is a fundamental security policy identified in Section 2.1. 8.1.2. Basis for Being Granted Access to the HIE IEHIE employees and business associates requesting access must submit an Access Request Form, included here as Appendix F, which has been approved by the applicant’s supervisor. Access will be granted by the HIE Administrator to specific applications, menus and data as stipulated on the form. The Chief Compliance Officer shall be responsible for verifying, logging, enforcing, and auditing the Access Request Form of IEHIE staff, contractors, and facility administrators, and annually for the system users of each facility administrator. HIE participants’ access will be based on acceptance of terms of use set forth in the IEHIE Participation Agreement. Anyone who requests access, including participants, IEHIE employees and business associates must sign a confidentiality agreement annually prior to being granted access. 8.2. Logical Access Controls Access controls must be implemented for all system objects including files, directories and whole computers. IEHIE shall implement specific procedures to support logical access controls. Group policies will be defined to achieve the requirements that follow. These policies will be deployed at the domain level and also be implemented on any self-contained systems. The minimal logical access controls shall be as follows: No shared administrative user accounts; this is necessary to ensure proper control and access to network and system resources, Accounts will be disabled after a specific number of failed log-in attempts, to be determined by the Chief Security Officer (CSO) and enabled by a system administrator. Desktops will be set to lock after being idle for a period determined by the HIE CSO. The HIE CCO will be responsible for verifying and logging system machines monthly. Accounts that have been inactive for 45 days will be removed. 24 IEHIE Policies and Procedures v2.1.2 All guest accounts (i.e., default accounts that are part of hardware as delivered by vendors) will be disabled and the use of shared accounts is prohibited on all IEHIE systems. Accounts used by vendors and other business associates for remote maintenance will be activated only during a requested time needed during a short maintenance window. 8.3. Granting or Changing User Access Rights and Passwords The IEHIE Participants shall enforce the following access control guidelines to prevent unauthorized access to sensitive systems and protected medical information through their systems in accordance with the IEHIE Participation Agreement. Supervisor approval is required prior to granting access or privileges. Approval is based upon a “business need to know” as determined by the supervisor. All users whose access to protected health information is facilitated by the HIE will be given a unique username and an initial password to permit access to system components or sensitive data. Users will choose their own password at the time of their first login. User identification must be verified and supervisor approval obtained prior to processing changes to user access including passwords or privileges. Supervisor approval for making changes to user access rights must be recorded and stored in writing. Access for terminated users will be revoked immediately. 8.3.1. Administrator Privileges Administrator privileges at the Participant sites are limited to the minimum number of staff required to perform sensitive duties (e.g., granting access to sensitive systems and confidential information). 25 IEHIE Policies and Procedures v2.1.2 9. Operational Security IEHIE operations and systems change constantly, as do the general threat environment and security controls available. System and operation changes and periodic turnover of staff and critical partners may introduce new threats into the environment. To enforce security and privacy criteria and identify new threats, IEHIE will regularly monitor program effectiveness and compliance, making adjustments to minimize risk. IEHIE will actively perform ongoing system security reviews and audits, ensure company- wide security awareness and adherence to policies at all staff levels, and clearly define enforcement procedures and disciplinary actions associated with security breaches and the misuse of IEHIE systems. Security operations, including reviews and audits, will impact all IEHIE managers of employees with access to sensitive information, regarding staff training, risk management and effective security controls. This policy will be enforced by the IEHIE management and the IEEHRC Board of Directors. 9.1. Assigning Privacy and Security Responsibilities Designated IEHIE employees will be responsible for implementing and maintaining the HIPAA Privacy and Security Rule and the IEHIE Policies and Procedures. They will have the resources and authority needed to meet their responsibilities. At a minimum, one individual or job description will be designated as the HIE Chief Security Officer and another one as the HIE Chief Privacy Officer, though one person may be designated to fill both roles. The CTO will also designate a different person as the HIE Chief Compliance Office, or select a qualified employee to carry out the duties of the HIE Chief Compliance Officer if that position has not been officially filled. The HIE CCO may also be designated to serve as the CSO or the CPO if those positions have not been filled, but no single employee may serve as designee to all three Officer positions. 9.2. Acceptable Use Guidelines The acceptable use of the IEHIE system includes the provisions below. 9.2.1. Access of Administrative System Usage and Data without Consent Users have no expectation of privacy or confidentiality in any of their system usage, including Internet access and e-mails. Usage may be monitored for policy, security, and/or network management reasons from time to time and is subject to inspection at any time. Inspection of IEHIE systems, data, e-mail and voicemail by management does not require the consent of individual users. Any personal information placed on IEHIE information system resources becomes the property of IEHIE. 9.2.2. Users Are Responsible for All Entries Made Under Their User ID or User Name A user ID or user name is equivalent to a user signature. Individuals are responsible for all entries under their user ID and/or user name. Shared accounts or passwords are prohibited. 9.2.3. Unacceptable Use Guidelines Although the behaviors described in this section do not constitute an exhaustive list, the following uses of IEHIE systems are expressly prohibited: Communicating sexual or other types of harassment by any means. While online, employees 26 IEHIE Policies and Procedures v2.1.2 should avoid using language that could be construed as derogatory, based on race, color, gender, age, disability, national origin or any other category. Any attempt to negate or circumvent IEHIE security controls, policies and procedures (e.g., disabling virus protection or tunneling a protocol through a firewall) is strictly prohibited. The unauthorized use, destruction, modification and distribution of IEHIE information or information systems are prohibited. Release of IEHIE information must be in accordance with IEHIE policies and business associate agreements. Removal of any equipment or software from IEHIE premises or computers is not allowed without prior approval by the employee’s immediate supervisor. Removal of any IEHIE equipment or software for personal use is not permitted. Use of tools that compromise security (e.g., password crackers and network sniffers) is prohibited except by the Information Services Department staff as part of an ongoing security program authorized by the CSO. Intentional interference with the normal operation of the network, including propagation of computer viruses and sustained high-volume network traffic, which substantially hinders others in their use of the network is prohibited. Theft of IEHIE resources including sensitive information is prohibited. Any use that violates local, state or federal laws is also prohibited. 9.3. Internet Access Acceptable Use Employees using IEHIE Internet access are responsible for acting in an ethical and lawful manner. Since it is well known that the Internet is not secure, employees must be aware of the guidelines identified in the Policies and Procedure Manual when using the IEHIE Internet service: 9.4. Remote Access Acceptable Use Guidelines for Non-Participants Business associates including vendors, contractors and third-party providers accessing IEHIE networks must adhere to the guidelines set forth in this section. The Chief Compliance Officer must approve the configuration of all remotely connected systems. If the remote access software used has logging capability, a log must be produced. Vendors will be limited to the minimum amount of access required to perform the necessary duties while the session is active. All other access and privileges will be limited to the specific function performed by each vendor or service provider. Remote access users must disconnect from any other network connection prior to connecting remotely to IEHIE systems. No split tunnels are allowed. All devices that remotely access IEHIE systems and data must employ boot protection via a password on all computers containing sensitive IEHIE data. Wireless networks will have their access passwords changed no less than monthly by the CSO and confirmed by the HIE Chief Compliance Officer. When it is not in use, any equipment and media used to remotely access IEHIE systems should 27 IEHIE Policies and Procedures v2.1.2 be stored where it can be securely locked up. Current virus protection and a personal firewall should be maintained on remote systems to protect IEHIE systems from viruses and other remote attacks. Current anti-virus update verification is performed monthly and is the responsibility of the HIE Chief Compliance Officer. To terminate a remote session with IEHIE systems, a user must log out rather than just disconnect. If the connection is through a web browser, the browser must be closed at the conclusion of the session. If remote processing is inactive for a 20-minute period, remote accesses will time out, resulting in a forced log-off. 28 IEHIE Policies and Procedures v2.1.2 10. Administrative Security Policies 10.1. Pre-Employment Background Checks IEHIE will perform background checks, criminal checks and other investigations as determined appropriate for job and information access responsibilities. Such checks will be carried out in accordance with relevant laws, regulations and ethics, and in compliance with Foundation Administrative Services, Inc., the Human Resources department for all new hires. The following two background checks are performed on every employment candidate: a. County Criminal Court Search: A County Criminal Court Search will include a minimum of seven years for both felony and misdemeanor court convictions. b. Social Security Address/Alias Trace: Using information found in credit headers and other sources associated with an applicant’s social security number, the Social Security Address/Alias Trace provides historical address information as well as AKA names. If the employee is fulfilling a position which requires access to PHI, the following investigations may further be performed by the Human Resources department: Check of prior employment references; Driver’s license check; and/or Check of industry sanctions and government debarment lists. 10.2. Personnel Education Schedule All IEHIE Personnel will receive privacy and security training as it relates to these Policies and Procedures and will continue to receive ad hoc policy updates during their employment. Training will include a review of relevant information security and privacy policies, regulatory information, technology changes and procedures to follow in order to properly protect sensitive information. Affected Employees Description Frequency All IEHIE Personnel HIPAA and security policies and protocols Annually All IEHIE Personnel Updates to IEHIE Policies & Procedures Manual Ad hoc All IEHIE Personnel Updates to HIE system and/or change in functionality Ad hoc All new Personnel are required to attend a HIPAA training, a two-hour online course that concludes with an exam. In addition to emphasizing the importance of privacy and security awareness, the curriculum also covers the following topics (illustrative, not comprehensive): Information Security Essentials Business Associates and Covered Entities Security Awareness Training Data Security Breaches Workstation, Laptop, Software, and Physical Threats HITECH regulations Red Flag Rules HIPPA Security Rule Protecting PHI and PII HIPAA Privacy Rule Account Security and Access Rights Final Omnibus Rule Change; FERPA; FACTA Malware, Phishing, and other Internet Scams 10.3. Employment Termination Security Practices Upon termination, employees shall return property and access devices they were provided with for their work. Supervisors of terminated employees shall be responsible for notifying the CSO to ensure that all associated accesses and accounts are immediately removed. Termination of administrative users shall require re-keying of all user accesses that they managed. 29 IEHIE Policies and Procedures v2.1.2 11. System and Network Administration and Security Policies The following information applies to the administration and security of IEHIE systems and networks. 11.1. Individuals Covered by this Policy The IEHIE System and Network Administration and Security Policies apply to all IEHIE employees, business associates, affiliate companies, partners, contractors, vendors and any other person or entity using or accessing sensitive data or information systems connected to IEHIE networks. The CTO or designated representatives must approve exceptions to this policy. The policies discussed in this section provide guidelines for administration of the IEHIE systems and networks and set forth the requirements for their operational security. System and network administration will be performed to protect all sensitive data in addition to providing a platform to meet technical services function requirements. At a minimum, the CSO, CCO, or a designated member of IEHIE Personnel will define and publish procedures, diagrams and inventories to accomplish the objectives outlined in this section. A copy of the operating procedures will be submitted to the Boards of Directors for approval annually as the policies are updated. Operating procedures shall cover the functions in the sections that follow. 11.2. Audit Trail Security Audit trails will be secured so they cannot be altered in any way. Orion Health Systems has been contracted to control the security of audit trails in the following ways: Limit viewing of audit trails to those with a job-related need. Protect audit trail files from unauthorized modifications. Promptly back up audit trail files to a centralized log server or other difficult to alter media. Copy logs for wireless networks onto a log server on the internal LAN. Use file integrity monitoring/change detection software (such as a Tripwire) on logs to ensure that existing log data cannot be changed without generating alerts; adding new data should not cause an alert. If HIPAA logging and auditing is done, it must be performed on systems processing and storing PHI or Personal Information (PI). Such sensitive data will be stored on cache servers located on HIE participants’ premises. Logs will be audited and monitored for individual access to records containing sensitive, personally identifiable or confidential information. Logs will contain at a minimum, date and time stamp, user account accessing the data, and function performed. 30 IEHIE Policies and Procedures v2.1.2 11.3. Identification and Authentication Administrative access control is based on permission to use the IEHIE system. Permissions must be applied for and will be granted based on employment and/or contractual agreements. Any grant of permission requires a signed Statement of Understanding. All permissions to access the system are restricted by the user’s role and need to know. 11.4. Administrative Account Management The Chief Privacy Officer administratively controls user accounts by following the procedures discussed in the sections below. 11.4.1. Account Activation Accounts associated with sensitive operations shall be activated only for individuals with a business need to know and proper authorization. Shared accounts are not permitted, and users must choose strong passwords upon initial log-in. All default accounts must be removed prior to installing a system or device. 11.4.2. Account Termination Account access shall be terminated immediately upon termination of employment. Supervisors of employees who are terminated or end their association with IEHIE should immediately report this change to the HIE Administrator, and in no case later than 72 hours. Administrators shall also check existing accounts regularly to identify dormant accounts and escalate the need for their termination. 11.4.3. Sanctions and Enforcement Neglect or intentional violation of these account management policies will result in disciplinary action, which may include termination of employment or cancellation of a contract. Other actions could include civil lawsuits and notification of law enforcement agencies. 11.4.4. Exceptions Should this policy prevent access to a computer system during an emergency, the IEHIE CTO may authorize a password to be generated, reset, regenerated or delivered in a manner not covered in the policy. 31 IEHIE Policies and Procedures v2.1.2 12. Risk Man agement Reviews In order that the IEEEHRC Board of Directors may be kept up to date on the types of information security risks the HIE is exposed to, risk management reviews shall be implemented to: Delineate clear accountability and lines of authority across IEHIE businesses and information security activities. Provide clear guidance regarding acceptable levels of security over sensitive, personally identifiable or confidential information stored in or transmitted by IEHIE systems. Ensure that the established policies, procedures, and controls are communicated to and observed by all employees. Perform a periodic review and approval of the IEHIE internal audit program for scope and frequency. 12.1. Management and Oversight Business Associates such as vendors and other independent third parties that provide support or services to IEHIE information systems shall be required to observe the same standards and level of data confidentiality and controls as those instituted by IEHIE. IEHIE is responsible for periodically reviewing the financial condition, stability, system security, recovery plans/testing, security assessment tests and internal control practices of all service providers and vendors. The HIE Chief Compliance Officer shall be responsible for maintaining logs of current vendors, their access to PHI (if any) and all supporting contracts and access forms, including business associate agreements, at least annually. A summary of the vendor review will be presented to the Board of Directors on an annual basis. 12.2. Compliance Management It is the responsibility of the HIE Chief Compliance Officer to oversee and review new and current vendors’ compliance with IEHIE Policies and Procedures. 32 IEHIE Policies and Procedures v2.1.2 13. Operation of the Incident Response Plan Orion Health Systems has developed and implemented a plan to prevent and respond to cyber incidents. This plan includes immediate notification to IEHIE as required by State and Federal regulations. IEHIE upon receiving notification will operate and Incident Response Plan. To respond to cyber incidents as effectively as possible, IEHIE will ensure that all procedures outlined in the Policies and Procedures Manual are followed. 33 IEHIE Policies and Procedures v2.1.2 APPENDIX A – CMIA DISCLOSURE EXCEPTIONS Confidentiality of Medical Information Act Disclosure Exceptions: CMIA Sections 56.10 and 56.1007 56.10. (a) No provider of health care, health care service plan or contractor shall disclose medical information regarding a patient of the provider of health care or an enrollee or subscriber of a health care service plan without first obtaining an authorization, except as provided in subdivision (b) or (c). (b) A provider of health care, a health care service plan, or a contractor shall disclose medical information if the disclosure is compelled by any of the following: (1) By a court pursuant to an order of that court. (2) By a board, commission, or administrative agency for purposes of adjudication pursuant to its lawful authority. (3) By a party to a proceeding before a court or administrative agency pursuant to a subpoena, subpoena duces tecum, notice to appear served pursuant to Section 1987 of the Code of Ci vil Procedure, or any provision authorizing discovery in a proceeding before a court or administrative agency. (4) By a board, commission, or administrative agency pursuant to an investigative subpoena issued under Article 2 (commencing with Section 11180) of Chapter 2 of Part 1 of Division 3 of Title 2 of the Government Code. (5) By an arbitrator or arbitration panel, when arbitration is lawfully requested by either party, pursuant to a subpoena duces tecum issued under Section 1282.6 of the Code of Civil Procedure, or another provision authorizing discovery in a proceeding before an arbitrator or arbitration panel. (6) By a search warrant lawfully issued to a governmental law enforcement agency. (7) By the patient or the patient's representative pursuant to Chapter 1 (commencing with Section 123100) of Part 1 of Division 106 of the Health and Safety Code. (8) By a coroner, when requested in the course of an investigation by the coroner's office for the purpose of identifying the decedent or locating next of kin, or when investigating deaths that may involve public health concerns, organ or tissue donation, child abuse, elder abuse, suicides, poisonings, accidents, sudden infant deaths, suspicious deaths, unknown deaths, or criminal deaths, or when otherwise authorized by the decedent's representative. Medical information requested by the coroner under this paragraph shall be limited to information regarding the patient who is the decedent and who is the subject of the investigation and shall be disclosed to the coroner without delay upon request. (9) When otherwise specifically required by law. (c) A provider of health care or a health care service plan may disclose medical information as follows: (1) The information may be disclosed to providers of health care, health care service plans, contractors, or other health care professionals or facilities for purposes of diagnosis or treatment of the patient. This includes, in an emergency situation, the communication of patient information by radio transmission or other means between emergency medical personnel at the scene of an emergency, or in an emergency medical transport vehicle, and emergency medical personnel at a health facility licensed pursuant to 34 IEHIE Policies and Procedures v2.1.2 Chapter 2 (commencing with Section 1250) of Division 2 of the Health and Safety Code. (2) The information may be disclosed to an insurer, employer, health care service plan, hospital service plan, employee benefit plan, governmental authority, contractor, or any other person or entity responsible for paying for health care services rendered to the patient, to the extent necessary to allow responsibility for payment to be determined and payment to be made. If (A) the patient is, by reason of a comatose or other disabling medical condition, unable to consent to the disclosure of medical information and (B) no other arrangements have been made to pay for the health care services being rendered to the patient, the information may be disclosed to a governmental authority to the extent necessary to determine the patient's eligibility for, and to obtain, payment under a governmental program for health care services provided to the patient. The information may also be disclosed to another provider of health care or health care service plan as necessary to assist the other provider or health care service plan in obtaining payment for health care services rendered by that provider of health care or health care service plan to the patient. (3) The information may be disclosed to a person or entity that provides billing, claims management, medical data processing, or other administrative services for providers of health care or health care service plans or for any of the persons or entities specified in paragraph (2). However, information so disclosed shall not be further disclosed by the recipient in a way that would violate this part. (4) The information may be disclosed to organized committees and agents of professional societies or of medical staffs of licensed hospitals, licensed health care service plans, professional standards review organizations, independent medical review organizations and their selected reviewers, utilization and quality control peer review organizations as established by Congress in Public Law 97-248 in 1982, contractors, or persons or organizations insuring, responsible for, or defending professional liability that a provider may incur, if the committees, agents, health care service plans, organizations, reviewers, contractors, or persons are engaged in reviewing the competence or qualifications of health care professionals or in reviewing health care services with respect to medical necessity, level of care, quality of care, or justification of charges. (5) The information in the possession of a provider of health care or health care service plan may be reviewed by a private or public body responsible for licensing or accrediting the provider of healt h care or health care service plan. However, no patient-identifying medical information may be removed from the premises except as expressly permitted or required elsewhere by law, nor shall that information be further disclosed by the recipient in a way that would violate this part. (6) The information may be disclosed to the county coroner in the course of an investigation by the coroner's office when requested for all purposes not included in paragraph (8) of subdivision (b). (7) The information may be disclosed to public agencies, clinical investigators, including investigators conducting epidemiologic studies, health care research organizations, and accredited public or private nonprofit educational or health care institutions for bona fide research purposes. However, no information so disclosed shall be further disclosed by the recipient in a way that would disclose the identity of a patient or violate this part. (8) A provider of health care or health care service plan that has created medical information as a result of employment-related health care services to an employee conducted at the specific prior written request and expense of the employer may disclose to the employee's employer that part of the information that: (A) Is relevant in a lawsuit, arbitration, grievance, or other claim or challenge to which the employer and the employee are parties and in which the patient has placed in issue his or her medical history, mental or physical condition, or treatment, provided that information may only be used or disclosed in connection with that proceeding. 35 IEHIE Policies and Procedures v2.1.2 (B) Describes functional limitations of the patient that may entitle the patient to leave from work for medical reasons or limit the patient's fitness to perform his or her present employment, provided that no statement of medical cause is included in the information disclosed. (9) Unless the provider of health care or health care service plan is notified in writing of an agreement by the sponsor, insurer, or administrator to the contrary, the information may be disclosed to a sponsor, insurer, or administrator of a group or individual insured or uninsured plan or policy that the patient seeks coverage by or benefits from, if the information was created by the provider of health care or health care service plan as the result of services conducted at the specific prior written request and expense of the sponsor, insurer, or administrator for the purpose of evaluating the application for coverage or benefits. (10) The information may be disclosed to a health care service plan by providers of health care that contract with the health care service plan and may be transferred among providers of health care that contract with the health care service plan, for the purpose of administering the health care service plan. Medical information shall not otherwise be disclosed by a health care service plan except in accordance with this part. (11) This part does not prevent the disclosure by a provider of health care or a health care service plan to an insurance institution, agent, or support organization, subject to Article 6.6 (commencing with Section 791) of Chapter 1 of Part 2 of Division 1 of the Insurance Code, of medical information if the insurance institution, agent, or support organization has complied with all of the requirements for obtaining the information pursuant to Article 6.6 (commencing with Section 791) of Chapter 1 of Part 2 of Division 1 of the Insurance Code. (12) The information relevant to the patient's condition, care, and treatment provided may be disclosed to a probate court investigator in the course of an investigation required or authorized in a conservatorship proceeding under the Guardianship-Conservatorship Law as defined in Section 1400 of the Probate Code, or to a probate court investigator, probation officer, or domestic relations investigator engaged in determining the need for an initial guardianship or continuation of an existing guardianship. (13) The information may be disclosed to an organ procurement organization or a tissue bank processing the tissue of a decedent for transplantation into the body of another person, but only with respect to the donating decedent, for the purpose of aiding the transplant. For the purpose of this paragraph, "tissue bank" and "tissue" have the same meanings as defined in Section 1635 of the Health and Safety Code. (14) The information may be disclosed when the disclosure is otherwise specifically authorized by law, including, but not limited to, the voluntary reporting, either directly or indirectly, to the federal Food and Drug Administration of adverse events related to drug products or medical device problems. (15) Basic information, including the patient's name, city of residence, age, sex, and general condition, may be disclosed to a state-recognized or federally recognized disaster relief organization for the purpose of responding to disaster welfare inquiries. (16) The information may be disclosed to a third party for purposes of encoding, encrypting, or otherwise anonymizing data. However, no information so disclosed shall be further disclosed by the recipient in a way that would violate this part, including the unauthorized manipulation of coded or encrypted medical information that reveals individually identifiable medical information. (17) For purposes of disease management programs and services as defined in Section 1399.901 of the Health and Safety Code, information may be disclosed as follows: (A) to an entity contracting with a health care service plan or the health care service plan's contractors to monitor or administer care of enrollees for a covered benefit, if the disease management services and care are authorized by a treating physician, or (B) to a disease management organization, as defined in Section 1399.900 of the Health and Safety Code, 36 IEHIE Policies and Procedures v2.1.2 that complies fully with the physician authorization requirements of Section 1399.902 of the Health and Safety Code, if the health care service plan or its contractor provides or has provided a description of the disease management services to a treating physician or to the health care service plan's or contractor's network of physicians. This paragraph does not require physician authorization for the care or treatment of the adherents of a well-recognized church or religious denomination who depend solely upon prayer or spiritual means for healing in the practice of the religion of that church or denomination. (18) The information may be disclosed, as permitted by state and federal law or regulation, to a local health department for the purpose of preventing or controlling disease, injury, or disability, including, but not limited to, the reporting of disease, injury, vital events, including, but not limited to, birth or death, and the conduct of public health surveillance, public health investigations, and public health interventions, as authorized or required by state or federal law or regulation. (19) The information may be disclosed, consistent with applicable law and standards of ethical conduct, by a psychotherapist, as defined in Section 1010 of the Evidence Code, if the psychotherapist, in good faith, believes the disclosure is necessary to prevent or lessen a serious and imminent threat to the health or safety of a reasonably foreseeable victim or victims, and the disclosure is made to a person or persons reasonably able to prevent or lessen the threat, including the target of the threat. (20) The information may be disclosed as described in Section 56.103. (d) Except to the extent expressly authorized by a patient or enroll ee or subscriber or as provided by subdivisions (b) and (c), a provider of health care, health care service plan, contractor, or corporation and its subsidiaries and affiliates shall not intentionally share, sell, use for marketing, or otherwise use medical information for a purpose not necessary to provide health care services to the patient. (e) Except to the extent expressly authorized by a patient or enrollee or subscriber or as provided by subdivisions (b) and (c), a contractor or corporation and its subsidiaries and affiliates shall not further disclose medical information regarding a patient of the provider of health care or an enrollee or subscriber of a health care service plan or insurer or self-insured employer received under this section to a person or entity that is not engaged in providing direct health care services to the patient or his or her provider of health care or health care service plan or insurer or self-insured employer. 37 IEHIE Policies and Procedures v2.1.2 APPENDIX B – SAMPLE NOTICE OF PRIVACY PRACTICES Sample Notice of Privacy Practices IEHIE Notice of Privacy Practices and Consent Form You are receiving this Notice of Privacy Practices in addition to the Notice of Privacy Practices you have received from your health care provider. The purpose of this Notice is to advise you that the Inland Empire Health Information Exchange (IEHIE) may facilitate electronic sharing of your personal health information among your health care providers in order for your medical treatment to be based on as complete a record as possible. What is a health information exchange? IEHIE is a health information exchange. [PROVIDER] is a participant in the Exchange. The Exchange facilitates the electronic transfer of protected health information among participating health care providers. IEHIE houses and stores data in a secure environment and also makes the exchange of health care data among participating health care providers possible. What information about you will be disclosed through the Exchange? To the extent permitted by law, [PROVIDER] may disclose your protected health information to other health care providers who request that information, via the Exchange. Protected health information in this case includes information that has been created or received by a health care provider, which relates to your past, present or future mental or physical condition, and that is personally or individually identifiable as belonging to you. In cases where your specific consent or authorization is required to disclose certain health information to others, [PROVIDER] will not disclose that health information to other health care providers participating in the Exchange without first obtaining your consent. Information that requires your additional consent in order to be shared includes; psychotherapy notes, treatment for substance or alcohol abuse and records of tests or treatment for sexually transmitted diseases. Who may access information through the Exchange? Only participants in the exchange who are your health care providers may access information through the Exchange. For what purposes such information can be accessed? Information may be accessed ONLY for the purpose of your medical treatment by your health care provider. Can you request your medical records and/or an accounting of disclosures of who has received them? You may access your medical records or obtain information about who has requested or received them by making a written request to each Exchange participant to release such data to you via the Patient Portal for such access. A participant has up to 5 days to respond. Participants that maintain EHRs (electronic health records) must account for all disclosures of your personal health information that were made for treatment, payment and health care operations for up to three years prior to the date of the request. Can you opt-out of sharing your personal health information with your health care providers via the Exchange? Consumers have the ability to opt-out of sharing their PHI through the IEHIE system. Please see the information about opting out below. CONSENT: If you do not opt-out of sharing personal health information with your other health care providers by way of the Exchange your consent to such sharing is assumed. 38 IEHIE Policies and Procedures v2.1.2 If you do NOT wish to allow [PROVIDER] to share your personal health information electronically with other providers via the Exchange you may exercise your right to opt-out of sharing by signing and dating this document, below. The effect of opting out of the Exchange is that each health care provider will need to request that a copy of your record be transferred by other means. If you consent now to sharing your personal health information via the Exchange, you may opt-out at a later date. Data that has already been shared will not be recalled from the provider(s) who have already received it, but no new data will be shared by the Exchange. You may not be denied treatment or otherwise penalized if you opt-out of sharing your personal health information through the Exchange. If you opt-out of sharing your personal health information via the Exchange and change your mind, you may opt-in at a later date. All health information collected during the opt-out period will be visible upon opt- in. I do not wish to have my personal health information shared via the Inland Empire Health Information Exchange (IEHIE) and hereby exercise my right to opt-out of such sharing: I have previously opted out of the Inland Empire Health Information Exchange (IEHIE) and wish to now opt back in. I understand that my past and present health information will be visible to my health care provider: (Name) (Date) (Signature) (Facility) 39 IEHIE Policies and Procedures v2.1.2 APPENDIX C – SAMPLE NOTICE OF PRIVACY PRACTICES (SPANISH) Aviso de Practicas de Privacidad y Consentimiento del Paciente para Participar del Programa de Intercambio de Información sobre Salud de Inland Empire Health Information Exchange (IEHIE) Usted está recibiendo información sobre IEHIE dedicada a compartir información sobre la salud de las personas en forma electrónica y a mejorar la calidad de los servicios de salud de manera segura. ¿Que es Intercambio de Información sobre Salud? IEHIE es una organización que contribuye al intercambio de información de salud entre los proveedores de servicios de salud que tienen pacientes en común. Esto ayuda a reunir los archivos médicos que usted tiene en los distintos lugares donde recibe atención de salud, poniéndolos electrónicamente a disposición de los participantes que le brindan servicios. ¿Que Información sobre Usted se Intercambia in IEHIE? Dentro lo que está permitido por ley, su proveedor de salud podrá acceder a toda la información electrónica sobre su salud disponible a través de IEHIE. Los proveedores Participantes que emplearan la información electrónica sobre su salud únicamente para brindarle tratamiento médico y servicios relacionados. Verificar si cuenta con seguro de salud y lo que este cubre. Evaluar y mejorar la calidad de la atención medica que se brinda a todos los pacientes. Este aviso le informa sobre las maneras en que podemos usar y divulgar su información médica. También describe sus derechos y ciertas obligaciones que tenemos sobre el uso y la divulgación de su información de salud. La siguiente información se necesita su consentimiento antes de dar información de drogas y alcohol y VIH tiene derecho a restricciones especiales relacionadas con su uso y divulgación. Notas de psicoterapia quiere decir notas grabada (encualquier medio) por un proveedor de salud que es un profesional que documenta o analiza el contenido de la conversación en consulta privadas de consejería o en grupo, conjunto o junta de familia de consejería y se separan del resto del expediente medico del individuo. ¿Quiénes pueden acceder a la información sobre usted in el Intercambio (IEHIE)? Únicamente las personas pertenecientes al intercambio y estén autorizados. Que forman parte de atención a su salud. ¿Propósito de la entrega de información y acceso a sus datos de salud? Sus datos de salud solo se proporciona para su tratamiento médico y servicios relacionados por su proveedor medico. ¿Se puede retirar de su información médica del Intercambio? IEHIE puede retirar su consentimiento en todo momento. La información ya compartida con su médico no se puede retirar. ¿Se puede pedir copia sobre su información médica y/o contabilidad sobre quien ha recibido su información del Intercambio? Para inspeccionar y/o recibir una copia de su información médica, usted debe presentar su solicitud por escrito a cada proveedor medico que intercambia su información de salud en IEHIE. Cada participante en el Intercambio (IEHIE) tiene 5 días para responder a su solicitud. Los hospitales y médicos que usan registros electrónicos de salud (EHR) deben dar información sobre toda vez que se revele información sobre su salud, tratamiento, pagos, y todo movimiento sobre su información por tres años anteriores de su solicitud. ¿Se puede no dar consentimiento para compartir su información médica en el Intercambio (IEHIE)? Usted puede utilizar el presente Formulario de Consentimiento para decidir no compartir sus datos de 40 IEHIE Policies and Procedures v2.1.2 salud a través del Intercambio (IEHIE). Por favor, lea cuidadosamente la siguiente información. Su decisión no afectara su capacidad de obtener atención médica ni su cobertura de seguro de salud. La decisión de no dar consentimiento no podrá ser motivo para que se le nieguen los servicios de salud. Si usted no firma hoy de negar consentimiento, pero luego decide, puede hacerlo en cualquier momento. Niego Mi Consentimiento, usted está diciendo “No, no deseo que mi proveedor de salud a dar información de mis datos de salud por el Intercambio” Si usted anteriormente negó su consentimiento a dar información de sus datos de salud por el Intercambio y ahora decide dar su consentimiento para brindarle atención de salud y que reciban su Información. NO DOY MI CONSENTIMIENTO para que todos los participantes involucrados en brindarme atención de salud puedan acceder a la información electrónica sobre mi salud a través de Intercambio de Información sobre Salud de Inland Empire Health Information Exchange (IEHIE). DOY MI CONSENTIMIENTO para que todos los Participantes involucrados en brindarme atención de salud puedan acceder a TODA la información electrónica sobre mi salud a través de Intercambio de Información sobre Salud de Inland Empire Health Information Exchange (IEHIE). (Nombre en letra de molde) (Fecha) (Firma del paciente o representante del paciente) (Sitio de servicio) 41 IEHIE Policies and Procedures v2.1.2 APPENDIX D – SAMPLE OPT-OUT REQUEST FORM Sample Opt-Out Request Form I request that my health information not be viewable through the Inland Empire Health Information Exchange (IEHIE) system. Please initial, sign and date this document that you have read and understand each the following statements: _______ I understand that by submitting this HIE Opt-Out Request Form my health information will not be viewable by health care providers (including emergency room physicians) through the IEHIE system. However, under HIPAA (45 C.F.R. 164.512) the physician does obtain the right to “break the glass”. _______ I hereby request that IEHIE to block access to my health information through the IEHIE system. _______ I understand that I am free to “opt-in” at any time during my next visit to a participating organization. _______ I understand that if I do not intentionally “opt-out” at my next visit to a participating organization, I will be automatically “opt-in” by default. Patient’s First Name: ________________________ Patient’s Middle Name: _______________________ Patient’s Last Name: _________________________Date of Birth: ________________ (MM/DD/YYYY) Previous Name(s) or Nicknames: __________________________________ Gender: ☐ Male ☐ Female Street Address: ________________________________________________________________________ City: ____________________________ State: ________ Zip Code: _____________ Phone: __________________ ___________________________________________ ________________________________ Signature of Patient (or Authorized Representative) Date Signed If under 18 years, signature of parent or guardian For your protection, IEHIE requires that you verify your identity in order to process this Request. This form must be completed by a Notary Public. This form must be returned by mail to IEHIE with original signatures in black or blue ink. -------- -------- -------- ---------- ---- Section below to be completed by a Notary Public -------- -------- -------- --------- State of _________________________________County of_____________________________________ The foregoing instrument was acknowledged before me this _________________ by _______________________. (date) (name of person acknowledged) Notary Print Name: ________________________ Notary Signature: __________________________ Please mail this form to: IEHIE, Attn.: Service Desk – HIE Request 3993 Jurupa Ave, Riverside, CA 92506 42 IEHIE Policies and Procedures v2.1.2 APPENDIX E – STATEMENT OF UNDERSTANDING Statement of Understanding As per Section 6.1.5 of the Inland Empire Health Information Exchange (IEHIE) Policies and Procedures Manual, employees are responsible for safeguarding all sensitive, confidential or personally identifiable information collected, retained or transmitted by IEHIE, from unauthorized access, modification, destruction, or disclosure, whether accidental or intentional. In addition, they are responsible for complying with this and all other IEHIE policies defining computer, network and information security and privacy measures. All employees, contractors or temporary staff members with access to sensitive, confidential or personally identifiable information must sign an Access Request Form (if applicable), and acknowledge willingness to comply with these Policies and Procedures in a signed Statement of Understanding. All employees, contractors and temporary staff are expected to: Protect the security and confidentiality of sensitive, confidential or personally identifiable information transmitted by IEHIE systems and networks. Use IEHIE resources only for the purposes specified. Comply with the security controls and guidance established by IEHIE. Notify the proper level of management of security breaches. I, _______________________________________________, hereby acknowledge and declare that: Print Name (i) I am aware that IEHIE’s policies have been delivered to me as a printed copy, and are available to me on the internet or upon request to my manager. It is my responsibility to familiarize myself with these policies. (ii) I agree to conduct my activities in accordance with IEHIE’s policies and understand that breaching these standards may result in disciplinary action up to and including termination or other legal remedy available to the organization. (iii) I will be required to sign a new Statement of Understanding at least annually, or, at times sooner than annually, when relevant revisions are made, as determined by a new version. Signed: _____________________________________ Date: _______________________________________ This signed copy shall reside with the Director of Finance and Human Resources of Foundation Administrative Services, Inc., and the date shall be recorded by the Administrative Assistant of IEHIE. 43 IEHIE Policies and Procedures v2.1.2 APPENDIX F – ACCESS REQUEST FORM Access Request Form for Authorized Users The Inland Empire Health Information Exchange (IEHIE) facilitates health information sharing and aggregation for treatment, payment, operations, public health and other lawful purposes in a manner that complies with all applicable laws and regulations. Access to the HIE is granted to organizations that have entered into a Participation Agreement with IEHIE and to individuals affiliated with these organizations. Inland Empire Health Information Exchange (IEHIE) policy requires that access to protected health information and other patient information (Patient Data) received as the result of a request to IEHIE, must be granted to each HIE Participant, Business Associate, and employee (collectively “Authorized Users”) based on their assigned job functions. Access privileges should not exceed those necessary to accomplish the assigned job function. Role-based access, dependent on a user’s proven “need to know” and granting the minimum necessary access to meet the responsibilities of a given job, is a fundamental security policy. Authorized Users requesting access to Patient Data must submit an Access Request Form, which must be requested and approved by the applicant’s supervisor. Authorized Users will be granted access by the manager of the HIE Administrator to specific applications, menus, and data as stipulated on the Form. For additional information on role-based access and access control policies, refer to Section 2.1 and Section 8.1 of the IEHIE Policies and Procedures, respectively. Authorized User Confidentiality Agreement Terms of Access to Inland Empire Health Information Exchange You have been identified by Participant (the hospital, clinic, physician’s office, health plan or other entity with whom you are affiliated) as an Authorized User (as defined in Section 1.5.3 of the Participation Agreement) who requires access to the HIE. The Inland Empire Health Information Exchange (IEHIE) agrees to provide you with access to the HIE only if you agree to the terms and conditions of this Confidentiality Agreement (Agreement), which are intended to maintain the confidentiality, security and integrity of protected health information and other patient information (Patient Data) accessed via the HIE. You are being provided with a user name and the ability to select a unique password (your Login Credentials) that will provide you with access to Patient Data available through the HIE. In order to be provided this access, you must agree to abide by the following rules: a) You will never reveal your Login Credentials to anyone. b) You will not allow others, including other staff members with whom you work, to access the HIE using your Login Credentials. c) You will log out of the HIE before leaving your workstation to prevent others from accessing the HIE. 44 IEHIE Policies and Procedures v2.1.2 d) You will not fax/print/email/download/copy/photograph or otherwise provide Patient Data to any third parties except in accordance with IEHIE Policies and Procedures and applicable law. You will not make unauthorized copies of the Patient Data. e) You will not save Patient Data to portable media devices (such as CDs, USB drives, or handheld devices) except in accordance with the IEHIE Policies and Procedures. f) You will not use the HIE or access or view any Patient Data except as required for your job with Participant. You will only access information as necessary to perform your professional obligations to a patient. g) You will notify your point of contact designated by the Participant immediately if you have reason to believe that your Login Credentials have been compromised. h) You will maintain the confidentiality of all information in accordance with state and federal laws governing the privacy and security of health information, including HIPAA, and in accordance with Participant’s privacy and security policies and procedures as well as the IEHIE Policies and Procedures. This includes but is not limited to obtaining the necessary patient consent or authorizations for disclosing Patient Data. i) You will not access the HIE via public–use workstations or devices. Public-use workstations and devices are those where general public access is allowed. HIPAA administrative, technical and physical security requirements cannot be applied and controlled on such devices. j) You attest that you have received HIPAA awareness training that meets or exceeds the minimum necessary standard for interacting with Patient Data as explained by the HIPAA Privacy Rule 45 CFR 164.502(b), 164.514(d). Failure to comply with these terms and conditions may result in disciplinary actions against you, which may include without limitation, denial of your privileges to access Data and other actions in accordance with Participant’s policies and the IEHIE Policies and Procedures. IEHIE and Participant have the right at all times to review and audit your use of the HIE and compliance with the terms of this Agreement. This Agreement grants you a nonexclusive, nontransferable right to use the HIE. This right is specific to you. You may not share, sell or sublicense this right with or to anyone else. THIS IS A BINDING AGREEMENT. By completing and signing below, you agree to comply with all terms and conditions for access to Patient Data under this Agreement and all IEHIE Policies and Procedures. This Agreement must be signed annually, with new signatures transmitted to the HIE Administrator. Dated: ___________ Signature: _______________________________________ Print Name: _____________________________________ 45 IEHIE Policies and Procedures v2.1.2 To create Authorized User profiles for use in the HIE, please complete the following information for the new Authorized User and the supervisor granting the permission. Access Control Levels have been provided to determine facility access the accurate security control level associated with different job functions and job titles. When complete, the Access Request Form will be retained by the Participant’s designated HIE administrators. Access Control Levels Please identify the accurate control level for this Authorized User. Level 1 – Primary Provider: Designed to access all clinical content available within the Clinical Data Repository (CDR). This role will assume responsibility to unfetter access to full clinical information as is aligned to access privilege under HIPAA to support point of care clinical treatment. o Full access to all clinical views, including sensitive data o May “break the seal” to access patient information without an established relations hip o May “break the glass” for patients who have chosen to opt-out of the IEHIE o Access to patient notifications o Access to Direct Secure Messaging (additional feature) Level 2 – Secondary Provider: Designed to access limited clinical content available within the Clinical Data Repository (CDR). This role will assume responsibility to access non-sensitive clinical content within the CDR to support point of care clinical treatment. o Full access to all clinical views, but NOT sensitive data o May “break the seal” to access patient information without an established relationship o Access to patient notifications o Access to Direct Secure Messaging (additional feature) Level 3 – Reporting: Designed to obtain non-clinical information via utilization reports. Level 4 – Front Desk: Designed to access patient information to provide administration services to their supporting organization. It is not intended to support point of care or clinical treatment. Level 5 – HIE Administrator: Designed to support the operational nature of providing user access controls and onboarding of facility user. It is not intended to support point of care for clinical treatment. o Access to user administration and auditing screens o Access to Direct Secure Messaging (additional feature) Level 6 – HIE Chief Privacy Officer: Designed to support auditing capabilities with access to usability reports and basic configurations of the system. It is not intended to support point of care for clinical treatment. o Access all patient administration screens to manage consent o Access to Direct Secure Messaging (additional feature) Clinical Portal Access Level 1 Level 2 Level 3 Level 4 Level 5 Level 6 Access to Clinical Data (including sensitive) X May “break the glass” for patients who have chosen to opt-out of the IEHIE X May “break the seal” to access patient information without an established relationship X X Access to patient notifications X X Direct Secure Messaging - Additional Feature X X X X Access to Clinical Data (non-sensitive) X Patient Administration – Consent Management X User Administration X 46 IEHIE Policies and Procedures v2.1.2 Organization Name: _____________________________________________________ Authorized User’s Information Level Number Requested: _________________________________________________ Job Title: ______________________________________________________________ First Name: _____________________________________________________________ Last Name: _____________________________________________________________ Organizational Email: _____________________________________________________ Facility Name: __________________________________________________________ Is the User a Physician? (please check) _____Yes _____No External Identifier*: ______________________________________________________ *National Provider Identifier, if applicable. Supervisor’s Contact Information Job Title: _______________________________________________________________ First Name: _____________________________________________________________ Last Name: _____________________________________________________________ Organizational Email: _____________________________________________________ Facility Name: __________________________________________________________ (Access Request Form will be considered incomplete and unacceptable without a signed attached Confidentiality Agreement) Policy 101 – Direct Secure Email Privacy, Security and Confidentiality 47 SUPPLEMENTAL 1: CTEN Policies for Direct Participants Introduction Direct Secure Mail (DSM) is provided to providers and administrative personnel for the secure transmission of information that would otherwise require a different mode of secure transfer. The DSM method of information movement is designed to be completely secure. DSM provides organizations, providers and individuals involved in or related to the care process with a secure transport approach. This policy addresses the need of the user (“You”) to be always mindful that information is being sent by DSM because it is (1) private, (2) requires secure transfer or (3) merits confidentiality protection. You should always consider that information being sent or received is private, secure and confidential. Applicable Law and Regulation For providers transferring clinical information or any information that would link the identity of a patient to the fact that the patient has a medical condition or is in treatment, several sets of laws and regulations (hereafter “rules”) apply: 1. Federal rules govern protected health information (“PHI”) as defined by the Health Insurance Portability and Accountability Act of 1996 (HIPPA, 45 CFR Parts 160, 162 and 164) as amended. Other federal rules govern behavioral health information including 42 CFR Part 2. 2. State rules add to the network of rules governing the exchange of PHI. These include the Information Practices Act (California Civil Code §1798-1798,78), California Civil Code 56.11 and 56.21, the California Welfare and Institutions Code 5328-5328.9, the Lanterman-Petris-Short Act and other California rules. The responsibility for compliance with applicable rules falls upon the individuals (You) and organizations using DSM. DSM is merely the transport tool. Safeguards DSM and PHI are governed by a number of usage rules. Several are particularly important: 1. Verified identify. You are issued a DSM address only when You have provided identification information and your identity has been verified. Your address is specific to You individually. 2. No sharing of DSM address. You may not allow another person to use Your DSM address or give out Your DSM password to anyone else. 101. Privacy, Security and Confidentiality of Direct Secure Mail Policy: 101 Version: 1.1 Date: September 29, 2015 Approved: Leo Pak Policy 101 – Direct Secure Email Privacy, Security and Confidentiality 48 3. Reuse of information. Your working assumptions should be that only You can utilize information sent to you. Forwarding the information to another party or otherwise distributing it except in accord with an approved policy of Your organization is almost surely a violation of HIPAA or other federal or state rules. 4. Behavioral health information. The rules for the transfer of behavioral health information (substance abuse treatment, psychiatric notes) and other sensitive information such as AIDs treatment and genetic information require written consent by the patient for transfer and the data can generally not be retransferred. If You think that behavioral health information is to be moved, assure that appropriate consent has been given in accord with the policies and procedures of Your organization. 5. Change in role. In the event that You are moved to a new position or leave the organization, please ask your superior to terminate your DSM address. Otherwise important communications may become stranded in that inbox. 6. Penalties. Violations of federal and state privacy and security rules as indicated above and in the prior section are punishable by severe fines to your organization and may result in Your dismissal. It is important that You understand what data transfers are permitted and how You may use data You receive. Applicable Policies and Procedures You understand that in addition to your organization’s policies and procedures, you are responsible for the following accompanying policies: Policy Number Title 102 User Identity Verification 103 CTEN* Breach Notification 104 CTEN Enterprise Security 105 CTEN Requirement to Respond 106 CTEN Duties when Submitting a Message 107 CTEN Applicability of HIPAA Regulations 108 CTEN Agreements with Participants 109 CTEN Incomplete Medical Record 1010 CTEN Direct Messaging Certificate Verification Process 1011 CTEN Use of Message Content 1012 CTEN Confidential Participant Information 1013 CTEN Safeguards 1014 CTEN Direct Secure Messaging User Setup *”CTEN” is the California Trusted Exchange Network. It relies on an agreement among HIEs called the CalDURSA or California Data Use and Reciprocal Support Agreement. The policies with the CTEN label assure that Participant Users are familiar with key provisions of the CalDURSA that apply to Transacting Message Content (moving message transactions with Direct and Exchange). Summary and Attestation Policy 101 – Direct Secure Email Privacy, Security and Confidentiality 49 DSM is a tool for the secure transfer of patient information. Though it is secure, law and regulation (rules) must still allow for that transfer and the transfer must be done in accordance with permitted processes. Your organization has agreed to provide written policies and procedures for use of Direct and Exchange for transfer of PHI. Your signature on this policy indicates that You generally understand the use of DSM and agree to perform such transfers in accordance with the detailed policies of your organization and the policies listed in the above table. Name: Title: Organization: Signature: Date: Policy 102 – Direct Secure Email Privacy, Security and Confidentiality 50 Introduction Direct Secure Mail (DSM) is supplied to providers and administrative personnel for the secure transmission of information that would otherwise require a different mode of secure transfer such as mail, fax, secure file transfer protocol, etc. The DSM method of information movement is designed to be completely secure. DSM provides organizations, providers and individuals involved in or related to the care process with a secure transport approach. This procedure addresses the need of the Organization authorizing an individual User to have a Direct Address with the Verification of the User’s Identity. A User may be a provider, staff of a provider or a person with an administrative role. Granting Access to a User For purposes of this Policy, an Organization which has individuals desiring access to Direct Secure Messaging (“Direct”) will designate an “Access Manager.” The Access Manager will be the first Direct User (person with a Direct email address) at the Organization and will be responsible for verifying the identity of other individuals applying to become Users of Direct. Verifying identity is a significant legal responsibility and lack of careful execution can have negative privacy and security results that could cause the organization to incur financial liability and negative publicity. If the Access Manager follow s the process indicated below, identity verification can be performed accurately and with almost no risk. Documentation Required to Verify Identity of a User Attached to this Procedure is the Orion Health Declaration of Identity Template. This is for use of the organization’s Access Manager in vetting the identity of users. This section describes the use of the form: 1. Service Provider. This is listed as Orion Health. Inland Empire HIE has a Vendor agreement with Orion Health, one of the largest providers of HIE services. Just leave the Service Provider block as it is. 2. Organization. This is the name and contact information for your Organization. Please provide the Access Manager’s direct telephone line in the Telephone field. 3. Applicant. This is the name, office telephone number and home address, etc., of the person applying for a Direct address. 4. Applicant Signature. The form should be signed in the present of the Access Manager (called the “Trusted Agent” on page 2 of the form. The Trusted Agent signs with his/her information after verifying the information listed in “Instructions to Notary / Trusted Agent.” 5. Instruction to Notary / Trusted Agent. The Access Manager needs to verify the User applicant based on at least one government-issued photo ID. a. Passport 102. User Identity Verification Policy: 102 Version: 1.1 Date: September 29, 2015 Approved: Leo Pak Policy 102 – Direct Secure Email Privacy, Security and Confidentiality 51 b. Driver’s license c. Military ID d. Permanent resident card e. Similar ID If the first ID is not a government ID, a second ID is required such as a. Social security card b. Birth certificate c. School ID d. Vote’s registration card Check that the address on the government ID or other IDs match the address given in the Applicant box. If not, the applicant needs to provide a proof of address: a. Utility bill (telephone, gas, electric, water or Internet) b. Bank statement c. Rental agreement d. Government-issued document. Attach a copy of the IDs used to the Orion form. The User signs as indicated above in the presence of the Access Manager and the Access Manager completes and signs the Trusted Agent’s box. 6. Identification #1 and #2. Indicate what identification items are provided. 7. Use of Notary. If you are completing the form for the Access Manager, the first User for the Organization, the Access Manager will complete the form for him/herself and have a notary verify that the identification is attached per the instructions and then notarizes the document. DSM Web HCO Account Request (version 1.0) Copyright © 2016 Orion Health group of companies 1 DSM Web HCO Account Request DSM Web is a web-based secure mail solution within Orion Health™ Clinical Portal Organization Details Please fill out a separate form for each organization requesting access to the HIE. Organization Name Community Medical Centers OID For example, 2.16.840.1.113883.3.1 A globally unique ISO identifier that consists of numbers and dots. OIDs are paths in a tree structure, with the left-most number representing the root and the right-most number representing a leaf. Enter the OID, if known. If an OID is not provided, Orion Health will create one using the Orion Health OID Registry. Representative Jamie Franklin The representative is an agent of the HCO, and is responsible for authorizing the Orion Health HISP to request Direct certificates on behalf of the HCO. Direct certificates facilitate the secure interstate and inter-agency sharing of electronic health information. Representative’s Email Address jfranklin@communitymedical.org Email Domain direct.communitymedical.HIEEmailDomain.com Your organization’s email domain must only contain letters. Numbers, spaces, punctuation and special characters are not permitted. For example, username@direct.HCOEmailDomain.HIEEmailDomain.com. If this domain is already in use, Orion Health will contact you for an alternative. Organization Administrator(s) Details of up to three employees authorized to act as administrator(s) for your organization. First Name Richard Middle Name Your middle name Last Name Cummins Title Director, Technical Services Group Email Address rcummins@communitymedical.org DSM Web HCO Account Request (version 1.0) Copyright © 2016 Orion Health group of companies 2 First Name Jinyong Middle Name Your middle name Last Name Kim Title Mgr, Technical Services Group Email Address Jin.Kim@communitymedical.org First Name Your first name Middle Name Your middle name Last Name Your last name Title Your title Email Address User’s email address for notifications DSM Direct HCO Account Request (version 1.0) Copyright © 2016 Orion Health group of companies 1 DSM Direct HCO Account Request Organization Details Please fill out a separate form for each organization requesting access to the HIE. Organization Name Name of your HCO OID For example, 2.16.840.1.113883.3.1 A globally unique ISO identifier that consists of numbers and dots. OIDs are paths in a tree structure, with the left-most number representing the root and the right-most number representing a leaf. Enter the OID, if known. If an OID is not provided, Orion Health will create one using the Orion Health OID Registry. HIPAA Compliance A Covered Entity (CE) performs medical services on the patient and has the most trusted access to Protected Health Information (PHI). A Business Associate (BA) is someone who a CE uses for services and who needs access to the PHI of the CE’s patients to perform some level of service. Health care organization that treats protected health information with the privacy and security equivalent to those required by HIPAA. Address Street Address Address Line 2 City Postal Code State Country Telephone Country code - Area code - Phone number Preferred Direct Email Domain direct.yourDomain.HIEEmailDomain.com OR direct.yourDomain.com Your organization’s email domain must only contain letters. Numbers, spaces, punctuation and special characters are not permitted. For example, username@direct.HCOEmailDomain.HIEEmailDomain.com. Alternative Direct Email Domain direct.yourDomain.HIEEmailDomain.com OR direct.yourDomain.com In the event your preferred Direct email domain is already in use, please provide Orion Health with an alternative domain name. DSM Direct HCO Account Request (version 1.0) Copyright © 2016 Orion Health group of companies 2 Organization Representative Name of the representative The representative is an agent of the HCO, and is responsible for authorizing the Orion Health HISP to request Direct certificates on behalf of the HCO. Direct certificates facilitate the secure interstate and inter-agency sharing of electronic health information. Representative’s Email Address Representative’s email address for notifications Technical Contact The main point of contact at the HCO for any questions regarding the deployment or configuration of the XDR server and client. Name Name of the technical contact Title Title of the technical contact Telephone Country code - Area code - Phone number Email Address Corporate email address XDR Details The Technical Contact at the HCO should provide this information. XDR Server URL Public URL of the SOAP end point for the XDR server Private Key CSR Certificate Signing Request (CSR) of the private key that will be used to generate an SSL certificate for the XDR server and client. Copy the CSR and paste it here, or upload the CSR file to the Support Tracker ticket along with this form. When generating your CSR, specify a key size of 2048 or higher. DIRECT IDENTITY VERIFICATION AND AUTHORIZATION Service Provider HISP Name: Orion Health Telephone: +1 800 905 9151 Address: 225 Santa Monica Boulevard, 10th Floor, Santa Monica CA 90401 Account #: 080088 Organization Organization: Telephone: Address: HIPAA Compliance: ⎕ HIPAA covered entity ⎕ HIPAA Business Associate ⎕ Other HIPAA Entity - Health-care organization that treats protected health information with privacy and security protections that are equivalent to those required by HIPAA. Applicant Name: Telephone: Home Address: Email: Date of Birth: By signing this document, I hereby agree to the attached authorization and request a Direct Certificate and declare (or certify, verify, or state) under penalty of perjury under the laws of the United States of America that the foregoing is true and correct. _________________________________________ / / , : am/pm Applicant Signature Date and Time Please have a notary or trusted agent witness your signature and sign the acknowledgement on the next page. The signed form should then be returned to Orion Health by following the instructions given to you. INSTRUCTIONS TO NOTARY/TRUSTED AGENT: Please verify the person named in this document using at least one government-issued photo ID. Examples of acceptable photo ID documents include a passport, driver's license, military ID, permanent resident card, or similar document. If the ID is not a federal government ID, a secondary ID is required. The second ID does not have to be a government- issued ID. Examples of acceptable secondary ID documents include a social security card, birth certificate, school ID, or voter's registration card. If the address on the ID is different from the one stated in this form, a document with the correct address must be provided. Examples of acceptable proof of address include a utility bill (telephone, gas, electric, water or Internet), bank statement, rental agreement or a government-issued document. Attach a copy of all ID documents to this form. Make sure the information listed in the identification boxes on the first page and below match the identity documents presented during the verification process. Notaries should sign the Notarial Acknowledgement, leaving the Trusted Agent information blank. Trusted Agents do not need to complete the Notarial Acknowledgement. Identification #1 Type of Document: Photo: Y N Issued By: Serial #: Name on ID#1: Expiration Date: Identification #2 Type of Document: Photo: Y N Issued By: Serial #: Name on ID#2: Exp. Date: TRUSTED AGENT’S STATEMENT (Not required if notarized) Trusted Agent I hereby declare (or certify, verify, or state) under penalty of perjury under the laws of the United States of America that on the date indicated herein, applicant personally appeared before me, signed the foregoing document in my presence, and presented the identification listed above . Name Organization Address Telephone Email: Trusted Agent Signature Date and Time / / , : am/pm NOTARIAL ACKNOWLEDGMENT STATE/COMMONWEALTH OF _________________} } COUNTY/PARISH OF _____________________ } I hereby certify under penalty of perjury under the laws of the United States of America that at the above-indicated date and time, personally appeared before me, the above -named Applicant, who signed the foregoing document in my presence, and who presented the identification listed above, affixed hereto, which I did review for authenticity. WITNESS my hand ___________________________________________ and official seal Notary Signs Here Date and Time / / , : am/pm Print Name Organization / Employer Telephone Email: AUTHORIZATION PLEASE READ THIS AUTHORIZATION CAREFULLY BEFORE SIGNING THE ATTACHED IDENTITY VERIFICATION DOCUMENT. BY SIGNING THE IDENTITY VERIFICATION, YOU ACKNOWLEDGE THAT YOU HAVE READ THIS AUTHORIZATION, THAT YOU UNDERSTAND IT, AND THAT YOU AGREE TO IT. IF YOU DO NOT ACCEPT THIS AUTHORIZATION OR DO NOT WISH TO APPOINT ORION HEALTH AS YOUR CERTIFICATE AGENT, DO NOT SIGN THE IDENTITY VERIFICATION. IF YOU HAVE ANY QUESTIONS, PLEASE E-MAIL DIGICERT AT LEGAL@DIGICERT.COM OR CALL 1-800-896-7973. DigiCert, Inc. (“DigiCert”) issues X.509 v.3 digital certificates (“Certificates”) to customers of the health information service provider identified on the attestation document (“Orion Health”). You, as the organization that will be named in a certificate, are providing this authorization to assist Orion Health in performing certain digital certificate -related duties that are normally reserved for Certificate subjects, usually an entity’s equipment, personnel, or agents. These tasks include managing keys, registering devices, and authenticating personnel with DigiCert and its Certificate systems and installing, configuring, and managing issued Certificates. Therefore, you hereby agree and authorize Orion Health and DigiCert as follows: 1. Certificates. Orion Health may request and approve Certificates in your name and use issued Certificates for your benefit. DigiCert may issue, refuse to issue, revoke, or restrict access to Certificates in accordance with the instructions provided by Orion Health and rely on these instructions as if originating from you. 2. Representations. You represent that you are a HIPAA covered entity, a HIPAA business associate, or a health -care organization that treats protected health information with privacy and security protections that are equivalent to those required by HIPAA. You represent that you will limit your use of the digital certificate for purposes required as a HIPAA Business Associated or Non-HIPAA Healthcare Entity (HE), defined as an entity that has an appropriate healthcare-related need to exchange Direct messages and which agrees to handle protected health information with privacy and security protections that are equivalent to those required by HIPAA. 3. Authorization. You explicitly appoint Orion Health’s employees and agents as your agent for the purpose of requesting, using, and managing Certificates and corresponding private keys. Orion Health’s employees and agents are authorized to fulfill all obligations imposed by DigiCert with respect to the Certificate, communicate with DigiCert regarding the management of key sets and Certificates, and fulfill all roles related to Certificate issuance, such as a certificate requester, certificate approver, and contract signer (as used in the CA/Browser Forum’s Extended Validation Guidelines for SSL Certificates). You hereby authorize Orion Health and its employees to: (i) Request Certificates for domains and emails owned or controlled by you or your affiliates, (ii) Request Certificates naming you or your equipment, employees, agents, or contractors as the subject, and (iii) Accept terms and conditions related to Certificates issued on your behalf. 4. Trusted Agent. In addition, you are hereby appointed as an agent of DigiCert for the purpose of collecting documentation, verifying identities, and providing identity information to DigiCert. Any information must be verified in accordance with instructions provided by DigiCert. The requirements for identity verification a re set by the applicable CP and may change without notice. Therefore, DigiCert may amend the instructions at any time. 5. Documentation. For each certificate ordered by Orion Health under your authorization, DigiCert must obtain a personal attestation and a copy of all documentation necessary to verify the entity’s identity. DigiCert may reuse this information in some cases. DigiCert may rely solely on the information you provide or previously provided when issuing a Certificate or may elect to perform additional verification prior to issuing a Certificate. You agree to provide, at all times, provide accurate, complete, and true information to DigiCert. If any information provided to DigiCert changes or becomes misleading or inaccurate, then you agree to promptly update the information. You consent to (i) DigiCert’s public disclosure of information embedded in an issued Certificate, and (ii) DigiCert’s transfer of your personal information to DigiCert’s servers, which are located inside the United States. DigiCert shall follow the privacy policy posted on its website when receiving and using information from you or Orion Health. DigiCert may modify the privacy policy in its sole discretion. 6. Representation. You represent that you have the authority to execute this authorization and bind your organization (if applicable) by its terms. By submitting documentation to DigiCert, you represent to DigiCert that (i) you have verified any named individual’s name, address, email address, telephone number, birth date, and any other information required by DigiCert and in accordance with any instructions provided by DigiCert, (ii) you have examined any relied upon documents for modification or falsification and believe that the documents are legitimate and correct, and (iii) you are unaware of any information that is reasonably misleading or that could result in a misidentification of the verified entity. These representations survive termination of this appointment until all Certificates that rely on the documentation expire. 7. Duration. This authorization lasts until revoked by you, and you are responsible for all Certificates requested by Orion Health on your behalf until after DigiCert receives a clear email message revoking the authorization at legal@digicert.com. Even after revocation, all representations and obligations herein survive until all Certificates issued under this authorization expire or are revoked in accordance with DigiCert’s agreement with Orion Health. DigiCert may require that you periodically renew this authorization by resubmitting a copy of this authorization to DigiCert. 8. Certificate Revocation and Termination. DigiCert will revoke any Certificate issued to Orion Health on your behalf after receiving notice from you and after verifying the legitimacy of the revocation request. DigiCert may also revoke a Certificate issued to Orion Health on your behalf for any reason and without notice. 9. Warranty Disclaimers. DIGICERT SERVICES ARE PROVIDED "AS IS" AND "AS AVAILABLE”. TO THE MAXIMUM EXTENT PERMITTED BY LAW, DIGICERT DISCLAIMS ALL EXPRESS AND IMPLIED WARRANTIES, INCLUDING ALL WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. DIGICERT DOES NOT WARRANT THAT ANY SERVICES WILL MEET ANY EXPECTATIONS OR THAT ACCESS TO SERVICES WILL BE TIMELY OR ERROR-FREE. DigiCert may modify or discontinue specific service or product offerings at any time. Nothing herein requires DigiCert to provide Certificates or other related services to you or Orion Health. 10. Limitation on Liability. YOU HEREBY WAIVE ANY RIGHT TO ANY DAMAGES RELATED TO DIGICERT’S SERVICES, INCLUDING THE ISSUANCE OR USE OF CERTIFICATES. DIGICERT IS NOT LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, SPECIAL, OR PUNATIVE DAMAGES OR ANY LOSS OF PROFIT, REVENUE, DATA, OR OPPORTUNITY, EVEN IF DIGICERT IS AWARE OF THE POSSIBILITY OF SUCH DAMAGES. The limitations in this section apply to the maximum extent permitted by law and apply regardless of (i) the reason for or nature of the liability, including tort claims, (ii) the number of claims of liability, (iii) the extent or nature of the damages, or (iv) whether any other provisions of this agreement were breached or proven ineffective. 11. Indemnification. To the maximum extent permitted by law, you will indemnify and defend DigiCert and its contractors, agents, employees, officers, directors, shareholders, affiliates, and assigns against all liabilities, claims, damages, and costs (including reasonable attorney's fees) related to either DigiCert’s reliance on this authorization or the use of a Certificate issued under this authorization. 12. Notices. You must send all notices (i) in writing, (ii) with delivery confirmation via first class mail, commercial overnight delivery service, facsimile transmission, email, or by hand, and (iii) addressed to DigiCert, Inc., Attn: Legal Department, 2600 West Executive Parkway, Suite 500, Lehi, Utah 84043, email: legal@digicert.com, fax: 1-866- 842-0223. DigiCert may change its address for notices by sending notice of the change to Orion Health. Orion Health is solely responsible for conveying notices to you. All notices to DigiCert are effective on receipt. Dig iCert will deliver notices to you by delivering the notice to Orion Health. Notices are effective when sent to Orion Health in accordance with DigiCert’s agreement with Orion Health. 13. Severability. The invalidity or unenforceability of a provision under this authorization, as determined by an arbitrator, court, or administrative body of competent jurisdiction, does not affect the validity or enforceability of the remainder of this agreement. The parties shall substitute any invalid or unenforceable provi sion with a valid or enforceable provision that achieves the same economic, legal, and commercial objectives as the invalid or unenforceable provision. 14. Intended Beneficiaries. Orion Health and DigiCert are express and intended beneficiaries of your obligations and representations under this agreement. Policy 103 – CTEN Breach Notification 53 Introduction Breach means (1) the unauthorized acquisition, access, disclosure, or use of Message Content while Transacting Message Content and (2) the use or disclosure of Message Content that is not for a HIPAA Permitted Purpose. The principal HIPAA permitted purposes are (1) treatment, (2) payment and (3) healthcare operations. The focus of Transacting Message Content is upon the treatment purpose. One-Hour Breach Notification For this Policy, a “CTEN Member” is an organization that has signed the CalDURSA and has been accepted by the California Interoperability Committee to the CTEN. Each CTEN Member agrees that within one (1) hour of discovering information that leads the CTEN Member to reasonably believe that a Breach may have occurred, it shall alert other CTEN Members whose Message Content may have been Breached and the Interoperability Committee to such information by sending an email to a dedicated e-mail address (hereinafter “Alert Email”). i. The Alert Email is primarily intended to alert that a Breach may have occurred. CTEN Members will use caution before relaying details of the potential Breach via e-mail. ii. Immediately notify other CTEN Members, who, in the judgment of the CTEN Member making the alert, may have had a Breach of Message Content or otherwise are likely affected by the Breach. iii. CTEN Members are strongly urged to send Breach Notifications through a secure means, where appropriate and possible (i.e., posted on the Secure Site) and labeled as Confidential Participant Information. iv. If, on the basis of the information that the CTEN Member has, the CTEN Member believes that it should temporarily cease exchanging Message Content with all other CTEN Members, it may undergo a service level interruption or voluntary suspension. Twenty-Four Hour Notification of Breach Determination As soon as reasonably practicable, but no later than twenty-four (24) hours after determining that a Breach has occurred, the CTEN Member shall provide a Notification to all CTEN Members likely impacted by the Breach and the Interoperability Committee of such Breach. The Notification should include sufficient information for the Interoperability Committee to understand the nature of the Breach. For instance, such Notification could include, to the extent available at the time of the Notification, the following information: One or two sentence description of the Breach Description of the roles of the people involved in the Breach (e.g. employees, Participants, service providers, unauthorized persons, etc.) The type of Message Content Breached 103. CTEN Breach Notification Policy: 103 Version: 1.0 Date: September 29, 2015 Approved: Leo Pak Policy 103 – CTEN Breach Notification 54 CTEN Members likely impacted by the Breach Number of individuals or records impacted/estimated to be impacted by the Breach Actions taken by the reporting CTEN Member to mitigate the Breach Current Status of the Breach (under investigation or resolved) Corrective action taken and steps planned to be taken to prevent a similar Breach. The CTEN Member shall supplement the information contained in the Notification as it becomes available and cooperate with other CTEN Members and the Interoperability Committee in accordance with Section 20(e) of the CalDURSA relating to rights in a dispute. The Notification required by this policy (Section 14.3 of CalDURSA) shall not include any PHI. If, on the basis of the Notification, a CTEN Member desires to stop Transacting Message Content with the CTEN Member that reported a Breach, it shall stop Transacting Message Content in accordance with Section 12.1(b) of the CalDURSA. If, on the basis of the notification, the Interoperability Committee determines that (i) the other Participants that have not been notified of the Breach would benefit from a summary of the Notification or (ii) a summary of the Notification to the other CTEN Members would enhance the security of the Performance and Service Specifications, it may provide, in a timely manner, a summary to such CTEN Members that does not identify any of the CTEN Members or individuals involved in the Breach. 1. Information provided by a CTEN Member in accordance with this policy (Section 14.3 of CalDURSA), except Message Content, may be “Confidential Participant Information.” Such “Confidential Participant Information” shall be treated in accordance with Section 16 of CalDURSA, Confidential Participant Information. 2. This policy shall not be deemed to supersede a CTEN Member’s obligations (if any) under relevant security incident, breach notification or confidentiality provisions of Applicable Law. 3. Compliance with this policy shall not relieve CTEN Members of any other security incident or breach reporting requirements under Applicable Law including, but not limited to consumers. Policy 104 – CTEN Enterprise Security 55 Maintain Secure Environment Each CTEN Member organization (“Member”) shall be responsible for maintaining a secure environment that supports secure Transactions. Members shall use appropriate safeguards to prevent use or disclosure of Message Content other than as permitted by applicable law and regulation and the Member organization’s policies. These include appropriate administrative, physical, and technical safeguards that protect the confidentiality, integrity, and availability of Message Content. HIPAA Implementation Specifications Appropriate safeguards for Non-Federal Participants shall be in state law, or those identified in the HIPAA Security Rule, 45 C.F.R. Part 160 and Part 164, Subparts A and C, as safeguards, standards, “required” implementation specifications, and “addressable” implementation specifications to the extent that the “addressable” implementation specifications are reasonable and appropriate in the Member’s environment, or both. If an “addressable” implementation specification is not reasonable and appropriate in the Member’s environment, then the Member shall document why it would not be reasonable and appropriate to implement the implementation specification and implement an equivalent alternative measure if reasonable and appropriate. Federal Participants Appropriate safeguards for Federal Participants shall be those required by Applicable Federal Law related to information security. Written Privacy and Security Policies Each Member shall, as appropriate under either the HIPAA Regulations, or under Applicable Law, have written privacy and security policies in place by the Member’s respective Effective Date. 104. CTEN Enterprise Security Policy: 104 Version: 1.0 Date: September 29, 2015 Approved: Leo Pak Policy 105 – CTEN Requirement to Respond 56 Duty to Respond to Treatment Messages All CTEN Members that request, or allow their respective Participants to request, Message Content for Treatment shall have a corresponding reciprocal duty to respond to Messages that request Message Content for Treatment. A CTEN Member shall fulfill its duty to respond by either (i) responding to the Message with the requested Message Content or, (ii) responding with a standardized response that indicates the Message Content is not available or cannot be exchanged. Response for Other Permitted Purposes CTEN Members may, but are not required to, Transact Message Content for a Permitted Purpose other than Treatment. Nothing in this Section 12.1(a) shall require a disclosure that is contrary to a restriction placed on the Message Content by a patient pursuant to Applicable Law. Duty to Respond to All Treatment Messages Each CTEN Member that requests, or allows its respective Participants to request, Message Content for Treatment shall Transact Message Content with all other CTEN Members for Treatment, in accordance with Sections 6, 12.1(a) and 14 of the CalDURSA. If a CTEN Member desires to stop Transacting Message Content with another Member based on the other Member’s acts or omissions in connection with this Agreement, the CTEN Member may temporarily stop Transacting Message Content with such Member either through modification of its Access Policies or through some other mechanism, to the extent necessary to address the Member’s concerns. The Participant will notify IEHIE of the cessation and the reason for it and IEHIE will investigate the problem and attempt to resolve it. 105. CTEN Requirement to Respond Policy: 105 Version: 1.0 Date: September 29, 2015 Approved: Leo Pak Policy 106 – CTEN Duties When Submitting a Message 57 Specific Duties of a CTEN Member When Submitting a Message Whenever a CTEN Member or Participant acts as a Submitter by submitting a Message to another CTEN Member or Participant, the Submitter shall be responsible to: 1. Submit each Message in compliance with Applicable Law and applicable Policies and Procedures including representing that the Message is: a. for a Permitted Purpose; b. submitted by a Submitter who has the requisite authority to make such a submission; c. supported by appropriate legal authority for Transacting the Message Content including, but not limited to, any consent or Authorization, if required; and d. submitted to the intended Recipient. 2. Represent that assertions or statements related to the submitted Message are true and accurate; 3. Submit a copy of the Authorization, if the Submitter is requesting Message Content from another CTEN Member or Participant which requires an Authorization. 4. For Federal Participants only, in addition to complying with 1 through 3 above, ensure that Messages submitted by such Federal Participant adhere to interoperability standards adopted by the Secretary of Health and Human Services, California Data Use and Reciprocal Support Agreement FINAL – July 24, 2014, and the National Institute of Standards and Technology (NIST) and the Federal Information Processing Standards (FIPS), as applicable. 106. CTEN Duties When Submitting a Message Policy: 106 Version: 1.0 Date: September 29, 2015 Approved: Leo Pak Policy 107 – CTEN Applicability of HIPAA Regulations 58 Applicability of HIPAA Regulations Message Content may contain protected health information (PHI). Furthermore, some, but not all, CTEN Members (“Members”) are either a Covered Entity or a Business Associate. Because the Members are limited to Transacting Message Content for only a Permitted Purpose, the Members do not intend to become each other's Business Associate. To support the privacy, confidentiality, and security of the Message Content, each Member and its Participants agrees as follows: a. If the Member is a Covered Entity, the Member does, and at all times shall, comply with the HIPAA Regulations and Applicable Law to the extent applicable. b. If the Member is a Business Associate of a Covered Entity, the Member does, and shall at all times, comply with the provisions of its Business Associate Agreements (or for governmental entities relying upon 45 C.F.R. §164.504(e)(3)(i)(A), its Memoranda of Understanding) and Applicable Law. c. If the Member is a Governmental Participant, the Member does, and at all times shall, comply with the applicable privacy and security laws and regulations. d. If the Member is neither a Covered Entity, a Business Associate nor a Governmental Participant, the Member shall, as a contractual standard, at all times, at a minimum, comply with the provisions of the HIPAA Regulations as if it were acting in the capacity of a Covered Entity or such other standards as may be determined in the future. 107. CTEN Applicability of HIPAA Regulations Policy: 107 Version: 1.0 Date: September 29, 2015 Approved: Leo Pak Policy 108 – CTEN Agreements with Participants 59 Enforceable Agreements Each CTEN Member (“Member”) has valid and enforceable agreements with each of its Participants that require the Participants to, as a minimum: 1. Comply with all Applicable Law; 2. Reasonably cooperate with the Member on issues related to Transacting Message Content; 3. Transact Message Content only for a Permitted Purpose; 4. Use Message Content received from another Member or Participant in accordance with the terms and condition of the Participation Agreement, CalDURSA and Member’s Policies and Procedures; 5. As soon as reasonably practicably after determining that a Breach occurred, report such Breach to the Member; and 6. Refrain from disclosing to any other person any passwords or other security measures issued to the Participant by the Member. For Participants who are employed by a Member or who have agreements with the Member, compliance with this Policy may be satisfied through written policies and procedures that address these items 1 through 6 so long as the Member can document that there is a written requirement that the Participant comply with the policies and procedures. 108. CTEN Agreements with Participants Policy: 108 Version: 1.0 Date: September 29, 2015 Approved: Leo Pak Policy 109 – CTEN Incomplete Medical Record 60 Medical Records and Message Content Each CTEN Member and Participant acknowledges that Message Contact Transacted by Members and Participants shall not include the individual’s full and complete medical record or history. Such Message Content will only include that data which is the subject of Message and available for exchange among CTEN Members. 109. CTEN Incomplete Medical Record Policy: 109 Version: 1.0 Date: September 29, 2015 Approved: Leo Pak Policy 1010 – CTEN Direct Messaging Certificate Verification Process 61 Inland Empire HIE (IEHIE) contracts with Orion Health for Direct services. Orion Health maintains CTEN Direct messaging certificates for itself and makes those available to IEHIE which makes them available to all Direct Participants. Under this arrangement, the primary responsibility for maintaining valid and current certificates lies with Orion Health, which automates the process as much as possible to reduce service interruptions. IEHIE can periodically check the existence and termination date of the Direct messaging certificate it is using. This policy describes that process. The California Interoperability Committee maintains specific policies that define business process and technical requirements for each transaction pattern supported on the CTEN. A list of the Exchange Policies for the current CTEN transaction patterns can be found at http://www.ca-hie.org/projects/cten/policies. Processes: Process 1 (P1): Obtain HPD and verify current organizations using DSM and XDR Process 2 (P2): Verify certificate expiration dates of Direct addresses Process 3 (P3): Download the IEHIE Trust Anchor Process 4 (P4): Verify inclusion of certificate into CTEN Trust Bundle Required Artifacts: Artifact 1 (DCVv2): Direct_Certificate_Verification_v2.xlsx (spreadsheet) 1010. CTEN Direct Messaging Certificate Verification Process Policy: 1010 Version: 2.0 Date: September 29, 2015 Approved: Leo Pak Policy 1010 – CTEN Direct Messaging Certificate Verification Process 62 P1 – Obtain HPD and Verify Current Organizations using DSM and XDR Step 1: Export the Healthcare Provider Directory (HPD) as a comma-separated values (CSV) file from Orion Health DSM Web Portal. The CSV file contains the Direct addresses of every provider and shared mailbox group in IEHIE's HPD. 1. Log into DSM Web as the HIE Administrator. 2. From the menu, select DSM ADMIN > HPD Export. 3. In the Modified since field, select the date from which you want to export the HPD, then press the Search button. 4. Press the Download CSV results link to download the HPD as a CSV file. [Image restricted due to confidential in commercial requirements] Step 2: Using the downloaded HPD, open DCVv2 to verify that (a) each healthcare organization (HCO) using a Direct address is identified, adding or removing organizations as necessary; (b) each Direct address is preceded with “postmaster@”, followed by the full Direct address. Example: postmaster@direct.xxxxx.inlandempirehie.com, where “xxxxx” is the name of the organization to which the address belongs Note 1: Some HCOs may utilize multiple Direct addresses (DSM and XDR). A record must be maintained for each unique Direct address. Policy 1010 – CTEN Direct Messaging Certificate Verification Process 63 P2 – Verify Certificate Expiration Dates of Direct Addresses Step 1: Orion Health’s certificate management system automates the monitoring and notification process to ensure continuous service to all Direct users. Organization administrators are notified two months prior to the upcoming expiration and are required to confirm the organization’s details for certificate extension. After confirmation, the public key of the Direct certificate may be verified outside of the Orion Health Portal by using the MaxMD (MMD) Direct Certificate Search, which can be found at http://www.maxmddirect.com/ maxmdirect-certificate-search.html. 1. Navigate to the MMD website. 2. In the field, enter the Direct address and press Search. There are two results available: 1. If certificate is not found or invalid: 2. If certificate is found and valid: Step 2: If certificate is valid, locate the Valid Date in the Certificate Information tab (default tab), shown below. 1. In DCVv2, record the validity dates, your name, and the date of the observation. 2. Repeat steps of P2 with each unique Direct address whenever a new Direct certificate is issued or updated. Policy 1010 – CTEN Direct Messaging Certificate Verification Process 64 Step 1: The presence of an organization’s Trust Anchor certificate in a Trust Bundle is the sole technical indication of a Participant’s participation in the CTEN and conformance with the policies and procedures of a Trust Profile. Technical testing with other Participants of the CTEN will be accomplished using a Staging Trust Bundle. 1. Navigate to the MMD website, http://www.maxmddirect.com/maxmdirect-certificate- search.html. 2. In the field, enter any current Direct address and press Search with CA Chain. 3. Scroll down to the Certificates and CAs section. 4. The second blue box (Depth 1) contains the public key for the IEHIE. 5. Download the DER certificate. 6. If sending the certificate to CTEN, change the .der file type to .txt or compress the file into a .zip to avoid issues with email virus scanners. Note 2: This image shows the certificate chain of custody. The first blue box (Max-Depth 10) is the certificate for the Participant whose Direct address was searched. The green box (Depth 2) is the certificate for Orion Health DSM, with who IEHIE current contracts DSM services. Policy 1010 – CTEN Direct Messaging Certificate Verification Process 65 Step 1: Trust among CTEN Members is established using collections of digital certificates. To retrieve copies of specific trust bundles, the publication site for CTEN Trust Bundles can be found at https://cten.ca-hie.net/bundles. 1. Navigate to the CTEN website and locate the CTEN Production Trust Bundles. 2. Press Show Bundle Details for the CTEN Direct Trust Bundles group. 3. Verify that IEHIE is among Participant column. In the Expires column, verify that all other Participants have current Trust Anchors. Step 2: In DCVv2, record the validity dates, your name, and the date of the observation. Policy 1011 – CTEN Use of Message Content 66 Message Content Shall Be Used Only as Indicated Below. 1. Permitted Purpose. CTEN Members shall only Transact Message Content for a Permitted Purpose as defined below. Each Member shall require that its Participants and Authorized Users comply with this provision. Permitted Purpose shall mean one of the following reasons for which Participants or Authorized Users ma y legitimatel y Transact Message Content: 1. Treatment of the individual who is the subject of the Message; 2. Payment activities of the Health Care Provider for the individual who is the subject of the Message which includes, but is not limited to, Transacting Message Content in response to or to support a claim for reimbursement submitted by a Health Care Provider to a Health Plan; 3. Health Care Operations of either (a) the Submitter if the Submitter is a Covered Entity; (b) a Covered Entity if the Submitter is Transacting Message Content on behalf of such Covered Entity; or (c) the Recipient if (i) the Recipient is a Health Care Provider who has an established Treatment relationship with the individual who is the subject of the Message or the Recipient is Transacting Message Content on behalf of such Health Care Provider; and (ii) the purpose of the Transaction is for those Health Care Operations listed in paragraphs (1) or (2) of the definition of Health Care Operations in 45 C.F.R. §164.501 or health care fraud and abuse detection or compliance of such Health Care Provider, and, for Participants operating in California, in California Civil Code section 56.10; 4. Public health activities and reporting as permitted or required by Applicable Law, including the HIPAA Regulations at 45 C.F.R. §164.512(b) or 164.514(e); 5. Any purpose to demonstrate meaningful use of certified electronic health record technology b y the (i) Submitter, (ii) Recipient or (iii) Covered Entity on whose behalf the Submitter or the Recipient may properly Transact Message Content, provided that the purpose is not otherwise described in subsections 1-4 of this definition and the purpose is permitted by Applicable Law, including but not limited to the HIPAA regulations. “Meaningful use of certified electronic health record technology” shall have 1011. CTEN Use of Message Content Policy: 1011 Version: 1.0 Date: September 29, 2015 Approved: Leo Pak Policy 1011 – CTEN Use of Message Content 67 the meaning assigned to it in the regulations promulgated by the Department of Health and Human Services under the American Recovery and Reinvestment Act, Sections 4101 and 4102; 6. Uses and disclosures pursuant to an Authorization provided by the individual who is the subject of the Message or such individual's personal representative as described in 45 C.F.R. §164.502(g) of the HIPAA Regulations and for Participants operating in California, in California Civil Code section 56.11(c); and 7. With regard to State Entities, uses and disclosures permitted by California law, including Civil Code sections 1798.24, 1798.24a and 1798.24b. 2. Permitted Future Uses. Subject to this Section (Permitted Future Uses) and CalDU RSA Section 19.7 (Disposition of Message Content on Termination), Recipients may retain, use and re-disclose Message Content in accordance with Applicable Law and the Recipient's record retention policies and procedures. If the Recipient is a CTEN Member that is a Business Associate of its Participants, such Member may retain, use and re-disclose Message Content in accordance wit h Applicable Law and the agreements between the CTEN Member and its Participants. 3. Management Uses. The CTEN Interoperabilit y Committee may request information from CTEN Members, and Members shall provide requested information, for the purposes listed in Section 4.3 (Grant of Authority) of the CalDURSA relating to management of CTEN. Notwithstanding the preceding sentence, in no case shall a CTEN Member be required to disclose (i) PHI to the Interoperability Committee in violation of Applicable Law or (ii) Participant Confidential Information. Any information, other than Message Content, provided by a CTEN Member to the Interoperability Committee shall be labeled as Confidential Participant Information and shall be treated as such in accordance with Section 16 (Confidential Participant Information) of the CalDURSA. Policy 1012 – CTEN Confidential Participant Information 68 Confidential Participant Information 1. Agreement not to redisclose. Each Receiving Party shall hold all Confidential Participant Information in confidence and agrees that it shall not, during the term or after the termination of this Participation Agreement, redisclose to any person or entity, nor use for its own business or benefit, any information obtained by it in connection with this Participation Agreement, unless such use or redisclosure is permitted by the terms of that Agreement. 2. Conditions of redisclosure. Confidential Participant Information may be redisclosed as required b y operation of law, provided that the Receiving Party immediately notifies the Discloser of the existence, terms and circumstances surrounding such operation of law to allow the Discloser its rights to object to such disclosure. If after Discloser's objection, the Receiving Party is still required by operation of law to redisclose Discloser's Confidential Participant Information, it shall do so only to the minimum extent necessary to comply with the operation of the law and shall request that the Confidential Participant Information be treated as such. 1012. CTEN Confidential Participant Information Policy: 1012 Version: 1.0 Date: September 29, 2015 Approved: Leo Pak Policy 1013 – CTEN Safeguards 69 Safeguards In accordance with Enterprise Security, Equipment and Software, and Auditing which follow. CTEN Member (“Member”) agrees to use reasonable and appropriate administrative, physical, and technical safeguards and any Performance and Service Specifications and Operating Policies and Procedures to protect Message Content and to prevent use or disclosure of Message Content other than as permitted by IEHIE Policy 1011 (Use of Message Content). Enterprise Security General Each Member shall be responsible for maintaining a secure environment that supports the operation and continued development of the Performance and Service Specifications. Participants shall use appropriate safeguards to prevent use or disclosure of Message Content other than as permitted by the Participation Agreement and including appropriate administrative, physical, and technical safeguards that protect the confidentiality, integrity, and availability of that Message Content. Appropriate safeguards for Non- Federal Participants shall be in state law, or those identified in the HIPAA Security Rule, 45 C.F.R. Part 160 and Part 164, Subparts A and C, as safeguards, standards, “required” implementation specifications, and “addressable” implementation specifications to the extent that the “addressable” implementation specifications are reasonable and appropriate in the Member’s environment, or both. If an “addressable” implementation specification is not reasonable and appropriate in the Member’s environment, then the Member shall document why it would not be reasonable and appropriate to implement the implementation specification and implement an equivalent alternative measure if reasonable and appropriate. Appropriate safeguards for Federal Participants shall be those required by Applicable Federal Law related to information security. Each Member shall, as appropriate under either the HIPAA Regulations, or under Applicable Law, have written privacy and securit y policies in place by the Member’s respective Effective Date. Member shall also be required to comply with any Performance and Service Specifications or Operating Policies and Procedures adopted by the CTEN Interoperability Committee, respectively, that define expectations for Participants with respect to enterprise securit y. Malicious Software Each Member shall ensure that it employs security controls that meet applicable industry or Federal standards so that the information and Message Content being Transacted and any method of Transacting such information and Message Content will not introduce any viruses, worms, unaut horized cookies, trojans, malicious software, “malware,” or other program, routine, subroutine, or data designed to disrupt the proper operation of a System or any part thereof or any hardware or software used by a Member in connection therewith, or w hich, upon the occurrence of a certain event, the passage of time, or the taking of or failure to take any action, will cause a System or any part thereof 1013. CTEN Safeguards Policy: 1013 Version: 1.0 Date: September 29, 2015 Approved: Leo Pak Policy 1013 – CTEN Safeguards 70 or any hardware, software or data used by a Member in connection therewith, to be improperly acc essed, destroyed, damaged, or otherwise made inoperable. In the absence of applicable industry standards, each Member shall use all commercially reasonable efforts to comply with the requirements of this Section. Equipment and Software Each Member shall be responsible for procuring, and assuring that its Participants have or have access to, all equipment and software necessary for it to Transact Message Content. Each Member shall ensure that all computers and electronic devices owned or leased by the Member and its Participants that will be used to Transact Message Content are properly configured, including, but not limited to, the base workstation operating s ystem, web browser, and Internet connectivity. Auditing Each Member represents that, through its agents, employees, and independent contractors, it shall have the ability to monitor and audit all access to and use of its System related to the CalDURSA, for system administration, security, and other legitimate purposes. Each Member shall perform those auditing activities required by the Performance and Service Specifications. Policy 1014 – Direct Secure Messaging User Setup 71 New User Process Description The typical new user is set up for Direct Secure Messaging (DSM) as follows: 1. A user is only set up after the user applicant has completed the identity verification process (Policy 102, User Identification Verification). Either the IEHIE Direct Administrator or a delegated Direct Administrator in a participant organization provides the new user applicant with instructions for self-registration using a secure web link only available for administration purposes. The applicant enters personal demographics, work site, and submits the information. 2. The responsible Direct Administrator receives an email that the application is complete, logs on to the administration site, reviews the application, and if it is satisfactory (expected identity- verified person) and complete, the Administrator accepts it. The system sends the applicant an email indicating acceptance. The Administrator sends the applicant instructions to log on to the DSM user site for the first time using a username produced by the system, normally “First.Last” names and a temporary password. 3. When the user logs on for the first time, the user is asked to change the password and provided length and character variety requirements. The user is also asked to select and respond to three Challenge Questions. In the future, should the user forget the password or miss-type it three times, the user will be asked to answer the Challenge Questions. If answered correctly, the user can select a new password, which cannot repeat a prior password for six (6) changes and cannot be largely similar to a past password. 4. The system requires that a user’s password be changed every ninety (90) days. 1014. Direct Secure Messaging User Setup Policy: 1014 Version: 1.0 Date: September 29, 2015 Approved: Leo Pak