Chapter 23 Resource and Patient Management System Network

Title	Section
Introduction	8-23.1
Purpose	8-23.1A
Background	8-23.1B
Scope	8-23.1C
Authorities	8-23.1D
Acronyms	8-23.1E
Definitions	8-23.1F
Master Patient Index Data Access and Sharing	8-23.2
Purpose	8-23.2A
Policy	8-23.2B
Training	8-23.2C
Master Patient Index Users - Procedures	8-23.3
Purpose	8-23.3A
Training	8-23.3B
Procedures	8-23.3C
Administrator Access to the Master Patient Index System	8-23.4
Purpose	8-23.4A
Responsibilities	8-23.4B
Procedures	8-23.4C
Access to Health Information Exchange	8-23.5
Purpose	8-23.5A
Central IHS HIE Database Procedures	8-23.5B
HIE Site Procedures	8-23.5C
Security Auditing of the Health Information Exchange	8-23.6
Purpose	8-23.6A
Procedures	8-23.6B
Processing Patient Access to Their Personal Health Record	8-23.7
Purpose	8-23.7A
Procedures	8-23.7B
Auditing Process of the Personal Health Record	8-23.8
Purpose	8-23.8A
Procedures	8-23.8B
End User Access to the RPMS Direct Messaging System	8-23.9
Purpose	8-23.9A
RPMS Direct Email System	8-23.9B
Policy	8-23.9C
Responsibilties	8-23.9D
Procedures	8-23.9E
Administrator Access to the RPMS Direct Messaging System	8-23.10
Purpose	8-23.10A
Responsibilities	8-23.10B
Procedures	8-23.10C

Exhibit	Description
Manual Exhibit 8-23-A	"Indian Health Service Health Information Exchange Agreement"
Manual Exhibit 8-23-B	"Indian Health Service Personal Health Record Terms and Conditions"
Manual Exhibit 8-23-C	"Resource Patient and Management System DIRECT Messaging System Terms and Conditions"

8-23.1  INTRODUCTION

1. Purpose.  This chapter establishes Indian Health Service (IHS) policies and procedures that govern use of the IHS Resource and Patient Management System (RPMS) Network, hereafter referenced as the "Network."  It includes guidance for IHS, Tribal, and Urban (I/T/U) health programs participating in the Master Patient Index (MPI), Health Information Exchange (HIE), Personal Health Record (PHR), RPMS Direct Messaging, and access to the eHealth Exchange (Exchange).
2. Background.  The IHS is launching these new technologies and services to introduce a new era of patient engagement and HIE across the Indian health system through the Network, a suite of tools that enable I/T/U health programs to work cooperatively to improve the quality of patient care.  The new features will improve access to essential health information at the point of patient care and provide new options for promoting health communications for patients and healthcare providers.

   These tools address the requirements established by the Centers for Medicare and Medicaid Services (CMS) and the Office of the National Coordinator for Health Information Technology (ONC) detailed in the 2014 Certified Electronic Health Record (EHR) rules that enable eligible healthcare providers and hospitals to achieve meaningful use.  The Network enables actions such as:  access to patient health information through the HIE for permitted purposes, patient access to their RPMS data through the PHR, and the ability for patients to send secure and encrypted emails to their healthcare team using the RPMS Direct email system.  These services can improve the quality of patient care and increase patient satisfaction.

   The Network is organized to facilitate Protected Health Information (PHI) access and sharing for treatment and related disclosures in a manner that complies with all applicable laws and regulations, including without limitation, those protecting the privacy and security of PHI.

3. Scope.  This chapter applies to all IHS organizational components including but not limited to Headquarters, Area Offices, and service units conducting business for and on behalf of the IHS through contractual relationships when using IHS Information Technology (IT) resources.  The policies contained in this chapter apply to all IHS IT activities including the equipment, procedures, and technologies that are employed in managing these activities.  The policy includes teleworking, travel, other off-site locations, and all IHS office locations.  Agency officials will apply this chapter to contractor personnel, interns, externs, students, and other non-Government employees by incorporating such reference in contracts or memorandums of agreement as conditions for using Government-provided IT resources.
4. Authorities.
   1. Federal Information Security Management Act of 2002, Public Law (Pub. L.) 107-347
   2. Health Information Technology for Economic and Clinical Health Act (HITECH), Title XIII of the American Recovery and Reinvestment Act of 2009, Pub. L. 111-5
   3. Health Insurance Portability and Accountability Act (HIPAA) of 1996, Pub. L. 104-191, 45 Code of Federal Regulations (CFR) Parts 160 and 164
   4. Indian Health Care Improvement Act of the Patient Protection and Affordable Care Act of 2010, 25 United States Code (U.S.C.) Section 1662
   5. National Institute of Standards and Technology (NIST) Special Publication 800-73-3, "Interfaces for Personal Identity Verification - Part 1:  End-Point Personal Identity Verification (PIV) Card Application Namespace, Data Model and Representation," February 2010
   6. Office of Management and Budget Circular A-130, "Management of Federal Information Resources"
   7. Privacy Act of 1974, as amended, Title 5 U.S.C. 552a, implemented by Title 5 CFR Part 5b
   8. REAL ID Act of 2005, Division B, Pub. L. 109-13
   9. X.509 Certificate Policy for The Federal Bridge Certification Authority (FBCA)
5. Acronyms.
   1. CA     Certificate Authority
   2. CCD     Continuity of Care Document
   3. CCDA     Consolidated Clinical Document Architecture
   4. CEO     Chief Executive Officer
   5. CFR     Code of Federal Regulations
   6. CIO     Chief Information Officer
   7. DPP     Designated Primary Provider
   8. DQM     Data Quality Manager
   9. EHR     Electronic Health Record
   10. Exchange     eHealth Exchange
   11. FBCA     Federal Bridge Certification Authority
   12. HIE     Health Information Exchange
   13. HIM     Health Information Management
   14. HIPAA     Health Insurance Portability and Accountability Act
   15. HISP     Health Information Service Provider
   16. HITECH     Health Information Technology for Economic and Clinical Health Act
   17. ID     Identification
   18. IHS     Indian Health Service
   19. IRT     Incident Response Team
   20. ISSO     Information Systems Security Officer
   21. IT     Information Technology
   22. ITAC     Information Technology Access Control
   23. I/T/U     IHS/Tribal/Urban
   24. LoA     Level of Assurance
   25. LoA 3     Level of Assurance 3
   26. MPA     Multi-Purpose Agreement
   27. MPI     Master Patient Index
   28. NIST     National Institute of Standards and Technology
   29. OIT     Office of Information Technology
   30. PHI     Protected Health Information
   31. PHR     Personal Health Record
   32. PII     Personally Identifiable Information
   33. PIV     Personal Identity Verification
   34. Pub. L.     Public Law
   35. RA     Registration Authority
   36. RPMS     Resource and Patient Management System
   37. SU/FA     Service Unit/Facility Administrator
   38. T/U     Tribal/Urban
   39. U.S.C.     United States Code
6. Definitions.
   1. Access Manager.  A web-based MPI administrative application that allows MPI administrators to manage the application, user access, and user profiles based on their designated roles within the application.
   2. Active Directory.  A directory service that Microsoft developed for Windows domain networks that provides integrated authentication and authorization services for a Windows computing environment.
   3. Active Directory Domain Controller.  Authenticates and authorizes all the users and computers in a Windows domain type network, assigning and enforcing security policies for all computers and installing or updating software.  For example, when a user logs into a computer that is part of a Windows domain, Active Directory checks the submitted password and determines whether the user is a system administrator or normal user.
   4. Audit Log.  A chronological record of system activities that includes records of system accesses and operations performed in a given period.
   5. Audit Trail.  A chronological record that reconstructs and examines the sequence of activities surrounding or leading to a specific operation, procedure, or event in a security relevant transaction from inception to final result.  For the purposes of this IHM chapter, the term "Audit Report" is considered the same as an "Audit Trail."
   6. Breach.  The unauthorized acquisition, access, use, or disclosure of PHI which compromises the security or privacy of such information, except where an unauthorized person to whom such information is disclosed would not reasonably have been able to retain such information.
   7. Continuity of Care Document.  A document form that contains the clinical content using the Health Level 7 American National Standards Institute's standard format for the transmission and exchange of clinical content.  The Continuity of Care Document (CCD) and successor formats are based on the Consolidated Clinical Document Architecture (CCDA).
   8. Consolidated Clinical Document Architecture.  A standard that provides a common architecture, coding, semantic framework, and markup language for the creation of electronic clinical documents.
   9. Data Quality Manager.  A web-based MPI user application that allows users to view patient demographic data, and definitive and potential duplicates between patient records.  Once duplicates are identified, the Data Quality Manager (DQM) allows users to merge or resolve the duplicate records and/or make corrections and enhancements based on designated roles within the application.
   10. Domain.  A form of a computer network in which all user accounts, computers, printers and other security principals are registered with a central database (called "Active Directory Service").  Authentication takes place on domain controllers.  Each person who uses computers within a domain receives a unique user account that can then be assigned access to resources within the domain.  The IHS has two separate domains, the "D1" federated domain and the "E1" Non-Federal domain.
   11. eHealth Exchange.  A set of standards, services, and policies that enables secure HIE over the Internet.  The IHS HIE will provide a foundation for the exchange of health information between participating Indian health programs.  The Exchange will broaden access across diverse entities across the country, helping to achieve the goals of the HITECH Act.
   12. Electronic Protected Health Information.  Protected Health Information that is transmitted by "electronic media" or that is maintained in any form of electronic media (as that term is defined at 45 CFR § 160.103).
   13. Health Information Service Provider.  An organization that provides services on the Internet to facilitate use of Direct messaging among Providers.  A Health Information Service Provider (HISP) is a logical concept that encompasses certain services that are required for Direct-mediated exchange, such as the management of trust between senders and receivers.  A user typically agrees to allow the HISP to maintain a digital certificate on their behalf.  Using this digital certificate, the HISP can securely send or receive Direct messages for the entity.  The user initiates outgoing messages, and accesses incoming messages through the systems provided by the HISP, often through a secure e-mail web portal or a secure e-mail client software application.
   14. Health Insurance Portability and Accountability Act Privacy and Security Rules.  Standards for Privacy and Security of Individually Identifiable Health Information at 45 CFR Parts 160, 162 and 164, as amended.  The Privacy Rule provides Federal protections for personal health information held by covered entities and gives patients an array of rights with respect to that information.  At the same time, the Privacy Rule is balanced so that it permits the disclosure of personal health information needed for patient care and other important purposes.  The Security Rule specifies a series of administrative, physical, and technical safeguards for covered entities to use to assure the confidentiality, integrity, and availability of electronic PHI.
   15. Indian Health Service CONNECT Gateway.  An open source software that promotes IT interoperability in the U.S. healthcare system.  CONNECT enables secure, electronic health data exchange among healthcare providers, insurers, government agencies, and consumer services.
   16. Indian Health Service Health Information Exchange.  A system that provides a service to collect, store, query, and retrieve patient health summary information in the form of a CCD or successor format, exported from the IHS RPMS facilities or other healthcare systems meeting the interface requirements.  The IHS HIE provides user access to summary medical record information from multiple Indian Health facilities utilizing RPMS databases and other eHealth Exchange communities from across the country.
   17. Indian Health System.  The IHS and participating Tribal and Urban (T/U) programs.
   18. Level of Assurance.  One's ability to determine, with some level of certainty that the electronic credential representing an entity (machine or human); can be trusted to belong to the entity.  The NIST and FBCA outlines four Levels of Assurance (LoA) ranging in confidence level from low to very high, which is measured by the strength and rigor of the identity proofing process conducted by the Registration Authority (RA).
   19. Level of Assurance 3.  One of the four identity authentication assurance levels used for e-government transactions.  Individual vetted at LoA 3 provides high confidence in the asserted identity's validity.  Credentials required are one Federal Government issued Picture Identification (ID), one REAL ID Act compliant picture ID, or two Non-Federal Government IDs, one of which shall be a photo ID (e.g., Non-REAL ID Act compliant Driver's License).  Any credentials presented must be unexpired.  REAL ID Act compliant IDs are identified by the presence of the Department of Homeland Security REAL ID star.  See "X.509 Certificate Policy for the FBCA").
   20. Master Patient Index.  Contains records for all the patients from all of the Indian health system facilities participating in the MPI.  Each facility record belongs to an MPI record, which is created by the MPI.  Two facility records that represent the same real-life person belong to the same MPI record.  An MPI record contains its own set of patient demographics called the Single Best Record, which is calculated from the demographics data of its facility records.  The MPI generates a unique patient ID for each MPI record.  The MPI enables the HIE.
   21. Personal Health Record.  A secure web application that enables verified patients to view their clinical information and use this information to interact with their medical team.
   22. Personally Identifiable Information.  See definition in the IHM, Part 8, Chapter 18, "Encryption" (dated 5/1/09, as amended).
   23. Proactive Audit.  An audit conducted on a regular basis for possible inappropriate use or activity.  As an example, audit monitoring identifies user patterns and allows for access monitoring to evaluate and update user access accordingly.
   24. Protected Health Information.  The term "Protected Health Information" and the abbreviation "PHI" shall have the same meaning as the term "protected health information" in 45 CFR § 160.103, limited to the individually identifiable health information received by a Business Associate from or on behalf of a Covered Entity.  This term shall include Electronic PHI.
   25. Reactive Audit.  An audit conducted in response to a request or to a triggered event, such as a complaint or breach in privacy or security.
   26. Retention of Audit Records.  The required period that audit records are retained by a covered entity.  Audit logs must be retained for 90 days or longer, as storage permits; audit reports must be retained for six years.  Records retained for legal action or as otherwise needed for compliance activity may be retained longer than six years.
   27. Patient Auditing.  Patients can view their PHR and secure messaging activities on the My Health Records (Home) page, according to the "Personal Health Record Web Portal User Manual".
   28. Resource and Patient Management System.  Decentralized, integrated system for management of both clinical and administrative information in healthcare facilities that is managed and maintained by the IHS.
   29. RPMS Direct Messaging.  A secure web-based messaging service intended for the exchange of patients' health information among healthcare providers and their patients and/or patients' personal representatives.  RPMS Direct Messaging is HIPAA compliant and integrated with applicable systems, such as EHR and PHR, to provide an easy way for registered healthcare providers, healthcare organizations, patients, and patients' personal representatives to securely share Personally Identifiable Information (PII) and PHI electronically.
   30. Trusted Agent.  An individual appointed on behalf of the RA to complete an in-person identity verification of the RPMS Direct users.  The RPMS Direct Administrators and PHR Registrars will serve as Trusted Agents.

8-23.2  MASTER PATIENT INDEX DATA ACCESS AND SHARING.

1. Purpose.  This section establishes the process for the Indian health system to participate in accessing and sharing data through the MPI application.  The Indian health system includes IHS and participating T/U programs.  The MPI was designed to facilitate data exchange across the IHS enterprise thereby helping to improve patient access to care and provider access to patient information.  Patient demographic data from RPMS systems across the country are interfaced to the central MPI database and will serve to link information for individual patients who receive care from multiple locations within the Indian health system.  The MPI serves as the core infrastructure for HIE capabilities in IHS which integrates with other services such as the PHR and the Exchange.

   The MPI contains records for all the patients from all of the Indian health system facilities participating in the MPI.  Each facility record belongs to an MPI record, which is created by the MPI.  Two facility records that represent the same real-life person belong to the same MPI record.  An MPI record contains its own set of patient demographics called the Single Best Record, which is calculated from the demographics data of its facility records.  The MPI generates a unique patient ID for each MPI record.  The MPI enables the HIE.

2. Policy.  It is IHS policy that all patient data contained in the central MPI database will be accessible only by authorized users of the MPI and HIE.  All MPI access and sharing of data shall comply with the HIPAA Privacy and Security Rules, Privacy Act, and all IHS policies related to privacy, security and data use:
   1. All IHS facilities are required to upload their patient demographic information into the central MPI database.
   2. All organizations that participate in the MPI will do so with the understanding that all patient data will be included in the central MPI database.
   3. There is no ability to exclude individual patient records from a given site whose data has been uploaded to the central MPI database.
3. Procedures.  These procedures must be followed by all participating sites:
   1. All authorized MPI users will be required to complete orientation and training, and sign the IHS Rules of Behavior prior to using the MPI application.
   2. Participating T/U organizations will be required to enter into the Multi-Purpose Agreement (MPA) by executing a Joinder Agreement and agreeing to all terms.  See the MPA for terms of the agreement.
   3. Access will not be granted until an approved/processed request to access the MPI has been submitted by the user's supervisor through:
      1. The ITAC System for users within an IHS facility and for T/U users that participate in the ITAC System; or
      2. An IHS Service Desk ticket for users within T/U facilities that do not participate in the ITAC System.
   4. Authorized users are granted specific roles within the MPI by their supervisor/administrator at their local site.  See Section 8-23.3, "Master Patient Index Users."
   5. All inappropriate or suspicious activity, such as incorrectly linked accounts (breaches), must be reported as follows:
      1. All IHS facilities shall use the Incident Response Team (IRT) procedures for reporting contained in Part 8, Chapter 9, "Establishing an Incident Response Capability," Indian Health Manual (IHM), and local facility procedures.
      2. The T/U facilities shall use their local breach procedures:
      3. The local policies and procedures for audit must comply with policies herein and HIPAA procedures for breach notification.
      4. The IHS IRT should be notified whenever an incident impacts the IHS network and/or data owned or maintained by IHS.  The T/U facilities must notify the IHS IRT in case of a suspected breach by e-mail.
4. Additionally, local administrators shall advise the Area and/or local Privacy Officer and Information Systems Security Officer (ISSO) of the incident(s) and include them in the investigation, response, and any subsequent notification that is required by law.

8-23.3  MASTER PATIENT INDEX USERS - PROCEDURES

1. Purpose.  This section establishes the process for MPI administrators and users to access and manage the MPI application to establish unique identifiers to identify patients throughout the Indian health system.  This system includes IHS and participating T/U health programs.  The MPI contains records for all the patients from all of the Indian health system facilities participating in the MPI.  Each facility record belongs to an MPI record, which is created by the MPI.  Two facility records that represent the same real-life person belong to the same MPI record.  An MPI record contains its own set of patient demographics called the Single Best Record, which is calculated from the demographics data of its facility records.  The MPI generates a unique patient ID for each MPI record.  The MPI enables the HIE.
2. Training.  In addition to the annual Information Systems Security Awareness (ISSA) training all of the participating Indian health system facilities are required to train MPI users prior to using the software.  Staff responsible for managing multiple patient records shall have a thorough understanding prior to using the MPI application.  IHS personnel, either federal or contractor, may also be responsible for completing role-based or system-based training and must acknowledge any specifically related Rules of Behavior, such as the Rules of Behavior for privileged users.  Role-based training courses can be found on the HHS Intranet Role-Based Training site.
3. Procedures.  The MPI application will be used to identify and verify potential duplicates and to link patient records using patient demographic data.  The Health Information Management (HIM) and Patient Registration staff, where applicable, must be trained in the use of the application.  It is important for sites to understand the criticality of completing training and development of specific procedures to ensure accuracy in identifying, verifying, and linking electronic data.  These procedures must be followed by all authorized users that have access to the MPI application:
   1. All authorized MPI users will be required to complete orientation and training, and sign the IHS Rules of Behavior prior to using the MPI.
   2. The MPI local administrator will authorize MPI application access within local facilities.  See the "Master Patient Index User Manual".
   3. The MPI user shall query and verify potential duplicate patient records, and link patient records using patient demographic data.
   4. The MPI user shall also unlink patient records for potential wrong patient linkage.  See Section 8-23.2.C(5) above for reporting potential breaches.
   5. The MPI user shall review and reconcile periodic duplicate patient reports.
   6. View Only users have query capability to identify potential multiple patient records and notify MPI users to reconcile the multiple records.
   7. It is highly recommended that HIM and Patient Registration staff, where applicable, be appointed as MPI users and MPI View Only users.
   8. Each participating Indian health system facility shall develop policies and procedures to ensure accuracy in identifying, verifying, linking, and unlinking electronic data.

8-23.4  ADMINISTRATOR ACCESS TO THE MASTER PATIENT INDEX SYSTEM

1. Purpose.  This section establishes the process for administrators' access to the IHS MPI system.  For system and user management, MPI Administrators will be designated at three levels:  National, Area, and Service Unit.  These authorized administrators will manage system related functions, such as user management and audits, using the MPI system.
2. Responsibilities.  Authorized MPI Administrators shall manage and provide user access to the MPI system following the procedures contained in this chapter to ensure appropriate user access and monitoring of the MPI system.  The IHM, Part 8, Chapter 12, "Information Technology Security", describes a full set of roles and responsibilities to which staff must adhere.  This policy describes additional roles and responsibilities that are required for MPI.
   1. Chief Information Officer.  The IHS Chief Information Officer (CIO) is the MPI system owner.  The CIO will appoint the National Administrator(s) for the IHS MPI.
   2. MPI National Administrator will:
      1. Be responsible for the MPI system, ongoing operation and maintenance, auditing, and assisting with MPI Area Administrators' onboarding, training, and support.
      2. Have privileges to manage MPI Groups, Roles, and the Access Functions and Access Details for each role using the MPI Administrative application.
      3. Be able to approve, deny, and update administrators' accounts.
   3. Area Directors.  Each Area Director shall appoint an Area MPI Administrator.
   4. Area MPI Administrators will:
      1. Work with the National Administrator and local Service Unit/Facility Administrators (SU/FA) to facilitate MPI onboarding for facilities within the Area Office.
      2. Manage access, provide training, support, and perform required audits for SU/FA.
      3. Be able to approve, deny, and updates administrators' accounts.
   5. Chief Executive Officer.  The Chief Executive Officer (CEO) will appoint the local SU/FA.
   6. Service Unit/Facility Administrators will:
      1. Work with their designated Area MPI Administrator to complete their facility MPI onboarding.
      2. Manage user access, complete identity verification and provide role based access, conduct audits, and provide training for their local facility MPI Users, View Only Users, and administrators.
   7. MPI Users.  MPI Users will have full user access to the MPI DQM tool to manage patient records and generate audit reports.  Full access allows them to search and view patient records; to search and view potential duplicates; to compare patient data; to merge valid duplicate patient records; to un-merge patient records; to resolve or permanently resolve patient records; and to view audit history.
   8. MPI View Only Users.  The MPI View Only Users will have limited DQM access to search and view patient records; to search and view potential duplicates; to compare patient data; and to view audit history.
3. Procedures.  Authorized MPI Administrators must comply with appropriate MPI requirements, privacy and security laws, and the following MPI Administrator procedures:
   1. All T/U organizations will be required to enter into the MPA by executing a Joinder Agreement and agreeing to all terms in order to have access to the MPI.  See the MPA for terms of the agreement.
   2. All authorized MPI Administrators will be required to complete training and sign the IHS Rules of Behavior prior to using the MPI system.  
      (See the Master Patient Index Administrator Manual.
   3. The MPI Administrator access shall be requested, tracked, and updated using:
      1. The ITAC System for administrators within an IHS facility and for T/U administrators that participate in the ITAC System; or
      2. An IHS Service Desk ticket for administrators within T/U facilities that do not participate in the ITAC System.
   4. Only authorized MPI Administrators shall grant access to users and additional administrators for purposes defined under this policy and in accordance with Section 8-23.3, "Master Patient Index Users," above.
   5. The National MPI Administrator or designee shall facilitate Area Office onboarding.
   6. The Area MPI Administrators shall work with the National MPI Administrator and Area facilities to coordinate facility onboarding.  Area MPI Administrators shall manage access and training for the alternate Area MPI Administrator and local SU/FAs.
   7. The SU/FA shall:
      1. Collaborate with the Area MPI Administrator for facility onboarding.
      2. Work with the appropriate clinical manager to delegate MPI User and MPI View Only User roles for the local facility.
      3. Collaborate with local staff, such as the Clinical Application Coordinator, HIM Supervisor, or other appropriate staff to provide required training to MPI Users and View Only Users.
      4. Grant and manage MPI access to local users, such as MPI User and MPI View Only User.
      5. Provide support, to their local MPI Users and View Only Users.
   8. All MPI Administrators and users must have their identity verified before a unique username and default password is assigned.
   9. All designated MPI Administrators must utilize the appropriate method as stated below to manage and track assigning, reassigning, or terminating MPI user access:
      1. The ITAC System or administrators within an IHS facility and for T/U administrators that participate in the ITAC System.
      2. The T/U administrators within T/U facilities that do not participate in the ITAC System must develop and utilize internal policies and procedures to manage and track MPI account access for their MPI users.
   10. All supervisors must contact their MPI Administrator immediately, based on local policy, to update user access when a user resigns, is reassigned, or is terminated.
   11. The MPI Administrators must add, remove, or modify users' access in appropriate MPI applications and Active Directory (AD) groups according to valid requests.
   12. The MPI Administrators shall routinely monitor system activities by using audit functionality within the MPI application (see the "Master Patient Index Administrator Manual".
       1. These audits may be reactive audits as requested by the local CEO, HIM staff, Privacy Officer, Security Officer, Compliance Officer, or other individuals that have legitimate need for the information to respond to patients' requests for accounting of disclosure, inquiries, breaches, and/or events.
       2. Routine proactive audit reports that are recommended for user groups, include but are not limited to:
          1. Type of activities performed by users.
          2. User status.
          3. Annual re-authorization evaluation for MPI administrators and users.
   13. Retention of audit records shall be maintained as follows:
       1. Audit logs must be stored for 90 days or longer at each site, as storage permits.
       2. Audit reports must be retained for a minimum of 6 years at each site.
   14. Administrators must report inappropriate or suspicious activities, such as misuse of the MPI system and PII as follows:
       1. The IHS facilities shall use the IHM, Part 8, Chapter 9, "Establishing an Incident Response Capability," and local facility procedures.
       2. The T/U facilities shall use their local breach procedures:
          1. The local policies and procedures for auditing must comply with policies herein and HIPAA procedures for breach notification.
          2. The IHS IRT should be notified whenever an incident impacts the IHS network and/or data owned or maintained by IHS.  The T/U facilities must notify the IHS IRT in case of a suspected breach by e-mail.
       3. Additionally, local administrators shall advise the Area and/or local Privacy Officer and ISSO of the incident(s) and include them in the investigation, response, and any subsequent notification that is required by law.
   15. Local facility MPI policies must be in place and enforced by management responsible for enforcement of privacy, security, and access to PHI.  As an example, the Governing Body, CEO, HIM Supervisor, Privacy/Security Officers and/or Compliance Officer will have established or incorporated specific MPI policies in their training, compliance and/or administrative policies.  Any facility seeking designation of a SU/FA attests to having local policies that are subject to audit, and accepts responsibility for enforcing these policies, at risk of access being disabled to MPI.

8-23.5  ACCESS TO THE HEALTH INFORMATION EXCHANGE

1. Purpose.  Authorized users of the IHS HIE shall follow procedures for PHI though the use of the HIE web-based application.  All data in the central IHS HIE database will be accessible by authorized users of the MPI and IHS HIE.  This section establishes the procedures for Indian health system participation in accessing and sharing data over the IHS HIE and national Exchange provided by HealtheWay.  The IHS HIE service will facilitate access to the Exchange through the IHS CONNECT gateway.  The IHS HIE and Exchange will enable health information to follow the patient, be available for clinical decision-making, and support appropriate use of healthcare information to improve population health.
2. Central IHS HIE Database Procedures.  All IHS facilities are required to upload their patients' CCDA information into the central IHS HIE database.
   1. All organizations that elect to participate in the IHS HIE will do so with the understanding that all patients will be included in the central IHS HIE database.  There is no ability to exclude patient records from a given organization whose data has been uploaded to the central IHS HIE database.  This means that within the Indian health system, data from all patients will be accessible to authorized users anywhere else in the System.
   2. Transmission of patient data outside the Indian health system via the Exchange is governed by patient choice.  By default, patients are not included in the Exchange; however, patients may change their option at any time.  Through the IHS-810 Form or other local form, patients may elect to "opt-in" or "opt-out" of data sharing over the Exchange.  IHS HIE authorized users will update patients' status to "opt-in" or "opt-out" in the IHS HIE Consumer Preference Module, a component of the IHS HIE application.
      [See the HIE Consumer Preferences User Manual.
3. HIE Site Procedures.  The following procedures must be followed by all sites participating in the IHS HIE:
   1. The local CEO will designate an HIE SU/FA.
   2. Access will not be granted until an approved and processed request has been submitted by the user's supervisor through:
      1. The ITAC System for HIE users within an IHS facility and for T/U HIE users that participate in the ITAC System; or
      2. An IHS Service Desk ticket for HIE users within T/U facilities that do not participate in the ITAC System.
   3. All authorized IHS HIE users will be required to complete orientation and training, and sign the IHS Rules of Behavior prior to using the IHS HIE.
   4. Healthcare providers, including physicians, dentists, nurse practitioners, physician assistants, medical assistants, and other healthcare professionals who access the IHS HIE are responsible for adhering to the "Agreement to Health Information Exchange Terms and Conditions" (see Exhibit 8-23-A).
   5. All participating I/T/U sites and their HIE users that access patient data through the Exchange must comply with the Exchange's Data Use and Reciprocal Support Agreement.
   6. Tribal and Urban facilities will be required to enter into the MPA by executing a Joinder Agreement and agreeing to all terms.
      See the MPA for terms of the agreement.
   7. Federal sites are required to have the patient's authorization to use or to revoke the use of their information across the Exchange, by signing the IHS-810 Form, "Authorization for Use or Disclosure of Protected Health Information" or other valid request.  The form and guidance on its use can be found in the IHM, Part 2, Chapter 7, "HIPAA Privacy Rule and the Privacy Act", Section 2-7.7, "Procedure for Use or Disclosure of Health Information Pursuant to Authorization or Valid Written Request." An example of a completed IHS 810-Form is contained in the "Health Information Exchange Consumer Preferences User Manual".
   8. The SU/FA and users must report inappropriate or suspicious activities, such as misuse of the IHS HIE system and PHI/PII, as follows:
      1. The IHS facilities shall use the IRT procedures for reporting contained in the IHM, Part 8, Chapter 9, "Establishing an Incident Response Capability", and local facility procedures.  Additionally, local administrators shall advise the Area and/or local Privacy Officer and ISSO of the incident(s) and include them in the investigation, response, and any subsequent notification that is required by law.
      2. The IHS IRT should be notified whenever an incident impacts the IHS network and/or data owned or maintained by IHS. The T/U facilities must notify IHS IRT in the event of a breach by e-mail.
   9. Local facility IHS HIE policies must be in place and enforced by management responsible for privacy, security, and access to PHI.  As an example, the Governing Body, CEO, HIM Supervisor, Privacy/Security Officers and/or Compliance Officer will have established or incorporated specific IHS HIE access process policies in their training, compliance and/or administrative policies.  Any facility seeking designation of a SU/FA attests to having local policies that are subject to audit, and accepts responsibility for enforcing these policies, at risk of access being disabled from using the IHS HIE.

8-23.6  SECURITY AUDITING OF THE HEALTH INFORMATION EXCHANGE

1. Purpose.  This section establishes the security auditing process for participants of the IHS HIE.  All IHS HIE data will be accessible by authorized users of the IHS HIE.  All HIE Administrators will follow procedures to regularly audit the IHS HIE to ensure appropriate use of the system.
2. Procedures.  Authorized users that have access to the IHS HIE audit web application must follow these procedures:
   1. Only authorized users may be granted access to audit records through the IHS HIE audit web application.
   2. Administrator access to the IHS HIE audit web application will not be granted until an approved/processed request has been submitted by the user's supervisor through:
      1. The ITAC System for administrators within an IHS facility and for T/U administrators that participate in the ITAC System; or
      2. An IHS Service Desk ticket for administrators within T/U facilities that do not participate in the ITAC System.
   3. The HIE National Administrator or designee shall be granted the national audit administrator privileges with access to audit reports across all facilities participating in the HIE.  This role is limited to individuals that are IHS employees or their designees.  These individuals will respond to audit report requests from the HIM Supervisor, Privacy Officer, Security Officer, Compliance Officer, and/or other appropriate staff.
   4. The Area HIE Administrator:
      1. Shall be granted the national audit administrator privileges with access to audit logs across all facilities participating in the HIE.
      2. Must query and run audits for facilities within their Area Office only.
   5. Facility CEOs will designate the HIE SU/FA.
   6. Facility HIE SU/FAs:
      1. Shall monitor system activities of local users.
      2. Will request audit reports from the Area HIE Administrator via an IHS Service Desk ticket.
   7. All HIE Administrators shall monitor system activities routinely using appropriate audit reports available within the IHS HIE audit web application.  See the IHS "Health Information Exchange Administrator Manual."  Routine proactive audit reports that are recommended include, but are not limited to, the following:

      Table 8-23-A: Health Information Exchange Administrator Audit Reports

      Report	Head- quarters	Area	Facility	Frequency (based on tier and activity)
      Type of records viewed by the user		X	X	Monthly
      Type of Activity	X	X	X	Biweekly: depends on tier and activity
      Successful or failed authentication attempts	X	X	X	Weekly
      Users' status: Active, inactive, and locked account	X	X	XX	Daily
      Monitoer activity of staff for access to family records		X	X	Weekly
      Access attempts, unauthorized attempts, compare current access vs. disabled access	X	X	X	Weekly
      Monitor activities of Service Unit/Facility for compliance to audit policy	X	X	X	At least Annually
      Monitor Administratord access to ensure disabled accounts for terminated and retired staff within 24 hours	X	X		Weekly
      Locked out users report			X	BI-weekly
      Annual access review	X	X	X	Annually

   8. Area HIE Administrators shall provide reactive audit reports as requested by the SU/FA, CEO, HIM Supervisor, Privacy Officer, Security Officer, Compliance Officer or other individuals who have a legitimate need for the information for accounting of disclosure, inquiries, breaches, and/or other events.
   9. Retention of audit records shall be as follows:
      1. Audit logs must be stored for 90 days or longer at each site, as storage permits.
      2. Audit reports must be retained for a minimum of six (6) years at each site.
   10. The IHS has two separate domains, the "D1" Federated domain and the "E1" non-Federated domain.  Each domain has an Active Directory: a list of authorized users and their level of access.  All HIE Administrators must report inappropriate or suspicious activities, such as misuse of the IHS HIE system and PHI/PII, using the IHS IRT process and local facility procedures:
       1. IHS facilities (IHS D1/AD Domain users) shall use the IRT procedures for reporting contained in the IHM, Part 8, Chapter 9, "Establishing an Incident Response Capability," and local facility procedures.
       2. T/U facilities (IHS E1/AD Domain users) shall use their local breach procedures:
          1. The local policies and procedures for audit must comply with policies herein and HIPAA procedures for breach notification.
          2. The IHS IRT should be notified whenever an incident impacts the IHS network and/or data owned or maintained by IHS.  The T/U facilities must notify the IHS IRT in case of a suspected breach by e-mail.
       3. Additionally, local administrators shall advise the Area and/or local Privacy Officer and ISSO of the incident(s) and include them in the investigation, response, and any subsequent notification that is required by law.
   11. Local facility IHS HIE policies must be in place and enforced by management responsible for enforcement of privacy, security, and access to PHI.  As an example, the Governing Body, CEO, HIM Supervisor, Privacy/Security Officers and/or Compliance Officer will have established or incorporated specific IHS HIE security audit policies in their trainings, compliance and/or administrative policies.  Any facility seeking designation of an HIE Administrator(s) attests to having local policies that are subject to audit, and accepts responsibility for enforcing these policies, at risk of access being disabled to the IHS HIE.

8-23.7  PROCESSING PATIENT ACCESS TO THEIR PERSONAL HEALTH RECORD

1. Purpose.  This section establishes the process for patients to access and interact with their health information through a secure Internet IHS PHR application.  The IHS PHR is intended to improve the overall health of patients by improving patient and provider collaboration, allowing patient self-management, and increasing patient access to health information.  The IHS PHR provides a secure web-based application where patients can interact with their healthcare information from all medical facilities that utilize the RPMS and associated EHR.  Additionally, patients will have access to health education, health assessments, and electronic services online.  The IHS PHR registration process may be initiated at the patient's request at a facility that utilizes RPMS
2. Procedures.  Authorized users (PHR registrars and administrators) must follow procedures for validation of patient identity and grant or revoke access to the patient's PHI though the use of the PHR web-based application.  The following procedures must be followed by all authorized users who have access to the IHS PHR application:
   1. Only individuals who are authorized to administer access to the PHR application or to register patients may use the IHS PHR Administration application.
   2. All authorized IHS PHR users will be required to complete orientation and training, and to sign the IHS Rules of Behavior prior to using the IHS PHR.
   3. Access will not be granted until an approved/processed request has been submitted by the user's supervisor through:
      1. The ITAC System for administrators within an IHS facility; or
      2. An IHS Service Desk ticket for administrators within T/U facilities.
   4. All PHR users will be granted access based on their level of Administrator or Registrar responsibilities.  See the "Personal Health Record Web Portal Administrator Manual" as follows:
      1. The PHR National Administrator or designee shall be granted the PHR national administrator privileges to approve, deny, and update administrator accounts.
      2. Each Area will designate a PHR Administrator who will be granted privileges to approve, deny, and update SU/FA accounts.
      3. Each Service Unit/Facility CEO will designate a PHR Administrator who will be granted local facility administrator privileges to approve, deny, and update local administrator and PHR registrar accounts.
      4. Service Unit/Facility level PHR Registrars will be identified and assigned PHR privileges to perform the registrar functions.  It is highly recommended that Registrars be identified from the HIM Department due to their familiarity with release of information and role as custodian of the patient health record.
      5. The PHR Registrar will perform the following key functions:
         1. Work directly with patients in their request for a PHR account and registration process.
         2. Provide the patient with a copy of the Notice of Privacy Practices, as amended, which includes the PHR language.
         3. Link and unlink the patient PHR account to their patient health records.
         4. Verify identity of patients.
         5. Create reports as requested by the Service Unit/Facility managers or supervisor.
         6. Update the patient's PHR access status field in the RPMS Patient Registration module.  This is an important step that ensures Meaningful Use performance measures are met.
   5. All PHR Administrators and Registrars will be responsible for the following:
      1. Responding to patient requests to reset their PHR password.
      2. Disabling a patient's PHR account.  See the "Personal Health Record Web Portal Administrator Manual".  In-person requests at the facility shall be in writing using the IHS-810 Form, "Authorization for Use or Disclosure of Protected Health Information" [see Section 8-23.5C(5) above] or other written request.  An example of a completed IHS 810-Form is contained in the "Health Information Exchange Consumer Preferences User Manual".
      3. Providing a copy of the request with the disabled date to the patient.  Once the account is disabled update the PHR access status field in the Patient Registration module.
      4. Providing access to an un-emancipated minor's PHR account by following the IHM, Part 2, Chapter 7, "HIPAA Privacy Rule and the Privacy Act", Section 2.7-23, "Procedure for Access to or Disclosure of Protected Health Information of Unemancipated Minors."
      5. PHR reports to respond to queries, audits, incidents, investigations, and utilization.  See "Auditing Process of the Personal Health Record," Section 8-23.8 below.
      6. Disconnecting the patient's RPMS health record that is linked to an incorrect PHR account.  The inappropriate linkage should be disconnected immediately by the local PHR registrar.  Disassociation of the appropriate account in a timely fashion is of utmost importance.  If the local PHR registrar is not available, the local PHR Administrator may perform the unlinking.  If the local PHR Administrator is not available the Area PHR Administrator may perform the unlinking and if not available, the National PHR Administrator may perform this task.  Further, the inappropriate linking of a PHR account to the wrong patient is considered a breach of confidentiality if the PHR account has been viewed by the patient.  These breaches shall be reported to the IRT and the immediate supervisor.
   6. All inappropriate or suspicious activity, such as incorrect linked accounts (breaches), must be reported as follows:
      1. IHS facilities shall use the IRT procedures for reporting contained in the IHM, Part 8, Chapter 9, "Establishing an Incident Response Capability", and local facility procedures.
      2. T/U facilities shall use their local breach procedures:
         1. The local policies and procedures for audit must comply with policies herein and HIPAA procedures for breach notification.
         2. The IHS IRT should be notified whenever an incident impacts the IHS network and/or data owned or maintained by IHS.  The T/U facilities must notify the IHS IRT in case of a suspected breach by e-mail.
      3. Additionally, local administrators shall advise the Area and/or local Privacy Officer and ISSO of the incident(s) and include them in the investigation, response, and any subsequent notification that is required by law.
   7. Facilities are strongly encouraged to work with their Area or local HIM consultants to develop specific procedures to ensure the accurate linking of patient records and to support the roles and responsibilities of PHR Administrators and Registrars.

8-23.8  AUDITING PROCESS OF THE PERSONAL HEALTH RECORD

1. Purpose.  This section establishes the audit process for authorized users of the IHS PHR.  Authorized PHR Administrators shall conduct audits and run reports on use of the IHS PHR through the PHR Administrator portal.
2. Procedures.  All authorized PHR Administrators must follow procedures defined herein and in the "Personal Health Record Web Portal Administrator Manual" and in Section 8-23.7, "Processing Patient Access to their Personal Health Record," above.
   1. Only authorized PHR Administrators shall have access to "Create Reports" in the PHR Administrator portal for monitoring and auditing.
   2. The PHR Administrator portal access shall be requested, tracked, and updated using:
      1. The ITAC System for administrators within an IHS facility and for T/U administrators that participate in the ITAC System; or
      2. An IHS Service Desk ticket for administrators within T/U facilities that do not participate in the ITAC System.
   3. The PHR National Administrator shall have privileges to run reports on all the users of the PHR portal and PHR Administrator portal.  This role is limited to individuals who are IHS employees or their designees who have IHS-wide security responsibilities.
   4. Each Area Office shall designate an Administrator who shall monitor system level activities for their Area service units and facilities.
   5. The local CEO shall designate a SU/FA who shall monitor local facility system activities.
   6. Based on their level of privileges, the administrators shall monitor system activities using the audit function within the PHR Administrator portal.  See the "Personal Health Record Web Portal Administrator Manual".  Routine audit reports include, but are not limited to the following:

      Table 8-23-B: Personal Health Record Administrator Audit Reports

      Report Type	Reports	National Admin	Area Office Admin	Service Unit/Facility Admin	Frequency
      PHR System Event Type	Successful or Failed login attempts	X	X	X	Weekly
      	User, administrator and facility failures	X	X	X	Daily
      	Successful and failed system event logging	X	X	X	Dailly
      	Service Problem: Master Patient Index (MPI) and Health Information Exchange (HIE)	X			Dailly
      Administrator Application Event Type	Monitor Administrator's access (i.e., Admin account creation, update, inactivation)	X	X	X	Monthly
      	Patient Application process status (i.e. failed or successful)	X	X	X	Daily
      	Patient unlink status (i.e. failed or successful)		X	X	Weekly
      	Annual access review	X	X	X	Anually
      Patient Application Event Type	Patient successful and failed activities (i.e., registration, information update, navigation, etc.)			X	Monthly
      	Patient status: Active, inactive, locked account	X		X	Monthly

   7. Administrators shall provide reactive audit reports as requested by the local CEO, HIM Supervisor, Privacy Officer, Security Officer, Compliance Officer or other individuals who have a legitimate need for the information for an accounting of disclosure, inquiries, breaches, and/or other events.
   8. Retention of audit records shall be maintained as follows:
      1. Audit logs must be stored for 90 days or longer at each site, as storage permits.
      2. Audit reports must be retained for a minimum of six (6) years at each site.
   9. Administrators must report inappropriate or suspicious activities, such as misuse of the PHI/PII under PHR, as follows:
      1. IHS facilities shall use the IRT procedures for reporting contained in the IHM, Part 8, Chapter 9, "Establishing an Incident Response Capability", and local facility procedures.
      2. The T/U facilities shall use their local breach procedures:
         1. The local policies and procedures for audit must comply with policies herein and HIPAA procedures for breach notification.
         2. The IHS IRT should be notified whenever an incident impacts the IHS network and/or data owned or maintained by IHS.  The T/U facilities must notify the IHS IRT in case of a suspected breach by e-mail.
      3. Additionally, local administrators shall advise the Area and/or local Privacy Officer and ISSO of the incident(s) and include them in the investigation, response, and any subsequent notification that is required by law.
   10. Local facility PHR policies must be in place and enforced by management responsible for enforcement of privacy, security, and access to the PHI.  As an example, the Governing Body, CEO, HIM Supervisor, Privacy/Security Officers and/or Compliance Officer will have established or incorporated specific PHR audit process policies in their training, compliance and/or administrative policies.  Any facility seeking designation of a SU/FA attests to having local policies that are subject to audit, and accepts responsibility for enforcing these policies, at risk of access being disabled to PHR.

8-23.9  END USER ACCESS TO THE RPMS DIRECT MESSAGING SYSTEM.

1. Purpose.  This section establishes the process for healthcare providers, patients, and/or their personal representatives, within the Indian health system, to exchange PHI/PII in a secure, encrypted manner using the secure email messaging system known as the RPMS Direct.  For additional responsibilities, see Section 8-23-10, "Administrator Access to the RPMS Direct Messaging System."

   The IHS RPMS Direct is a secure, web-based messaging service, intended for the exchange of patients' health information between healthcare providers and their patients and/or their personal representatives.  It is intended to eliminate and reduce the use of fax services or postal mail that involves the inherent risks of information being misplaced, compromised, or accessed by unauthorized users.  The RPMS Direct is HIPAA compliant and integrated with applicable systems, such as EHR and PHR, to provide an easy way for registered healthcare providers, healthcare organizations, patients, and patients' personal representatives to securely share PHI/PII electronically.

   The Indian health system healthcare providers must register for an RPMS Direct account at each facility where they provide care.  For patients and/or their personal representatives, the PHR registration process will allow creation of an RPMS Direct account.

2. RPMS Direct Messaging System.  The RPMS Direct will be utilized as a secure email system for various healthcare related communications, such as the following:
   1. To transition care.
   2. To ask medical questions.
   3. To make appointments.
   4. To request medication refill.
   5. To upload and send information.
3. Policy.  The IHS RPMS Direct is dedicated solely for the purpose of healthcare related exchanges among RPMS Direct participants only.  All users of RPMS Direct must follow these requirements and standards when using the RPMS Direct.
4. Responsibilities.  The IHM, Part 8, Chapter 12, "Information Technology Security", describes a full set of rules and responsibilities to which staff must adhere.  This section provides additional roles and responsibilities for implementation of RPMS Direct.
   1. Service Unit/Facility Administrator.  The SU/FA is an individual(s) at a local facility responsible for granting access and performing responsibilities, as defined in the "Administrator Access to the RPMS Direct Messaging System," Section 8-23.10, related to identity vetting and making changes to authorized users RPMS Direct access.
   2. Message Agent.  A Message Agent is an individual assigned to a patient or patient group to receive, distribute, and respond to secure messages on behalf of healthcare providers based on local policies and standards of patient care.  The SU/FA will grant access to the Message Agent.  Message Agents can be assigned to the patient or patient groups using the RPMS Designated Primary Provider (DPP) Package.
   3. Healthcare Provider.  Healthcare providers include physicians, dentists, nurse practitioners, physician assistants, medical assistants, and other healthcare professionals who need to transmit and/or receive PHI/PII.  Participating healthcare providers are responsible for adhering to the Agreement to RPMS Direct Messaging Terms and Conditions" (see Manual Exhibit 8-23-B).
   4. Patient.  Participating patients are responsible for adhering to the "Agreement to the Personal Health Record Terms and Conditions," (See Manual Exhibit 8-23-C).
   5. Personal Representative.  An individual authorized by the patient to access their PHI pursuant to an authorization or authorized by applicable law.  Patients' personal representatives are also responsible for adhering to the "Agreement to the Personal Health Record Terms and Conditions" (see Manual Exhibit 8-23-C).  For more information, see the IHM, Part 2, Chapter 7, "HIPAA Privacy Rule and the Privacy Act" Section 2.7-25, "Procedure for the Use and Disclosure of PHI for Emancipated Minors and Adults with Personal Representatives or Legal Guardians."
5. Procedures.  All authorized users that have access to the RPMS Direct system must comply with appropriate IHS HISP requirements, privacy, and security laws, and the following RPMS Direct access procedures:
   1. Tribal and Urban organizations must enter into the MPA by executing a Joinder Agreement and agreeing to all terms to access RPMS Direct.  See the MPA for terms of the agreement.
   2. All authorized RPMS Direct users will be required to complete orientation and training, and sign the IHS Rules of Behavior prior to using the RPMS Direct.
   3. Users must complete the RPMS Direct registration process by verification of identity being completed in person by the designated Trusted Agent.  Provided are the security assurance levels required for the following users:
      1. Healthcare providers and Message Agents must contact their local SU/FA and follow local procedures to complete the registration process.  Healthcare providers and Message Agents require assurance at LoA 3.
         1. Access will not be granted for IHS users or T/U users that participate in the ITAC System until an approved/processed ITAC request has been submitted by the user's supervisor.
         2. Tribal and Urban healthcare providers and Message Agents within T/U facilities that do not participate in the ITAC System must open an IHS Service Desk ticket to initiate access for RPMS Direct.
         3. The designated SU/FA must verify identity information before granting a RPMS Direct account to healthcare providers and Message Agents.
         4. Failure to complete identity vetting requirements will result in access not being granted to the RPMS Direct system.
      2. Patients and/or their personal representative will have to complete the PHR registration process to gain access to RPMS Direct.  See Section 8-23.7, "Processing Patient Access to their Personal Health Record."
   4. The SU/FA will assign a unique user name to each healthcare provider and Message Agent.  The SU/FA must transmit passwords separate from the usernames when providing this information electronically.Healthcare providers and Message Agents must follow the RPMS Direct password and login requirements defined in the "RPMS Direct Messaging User Manual".
   5. IHS supervisors and T/U supervisors that participate in the ITAC System must submit ITAC requests and contact the SU/FA to remove the employee from RPMS Direct immediately when the user resigns, is reassigned or is terminated.  See Section 8-23.10, "Administrator Access to the RPMS Direct Messaging System."
   6. Tribal and Urban SU/FAs within T/U facilities that do not participate in the ITAC System must open an IHS Service Desk ticket to update and track RPMS Direct access for their healthcare providers and Message Agents.
   7. Users or their supervisors must notify the SU/FA to setup message forwarding during the user's absence.
   8. Activities of RPMS Direct users may be monitored, recorded, and subjected to auditing.
   9. The SU/FA must provide reactive audit reports as requested by the local CIO, HIM Supervisor, Privacy Officer, Security Officer, Compliance Officer or other individuals that have a legitimate need for the information to respond to patient's request for an accounting of disclosure, inquiries, breaches, and/or events.
   10. These reports may capture user level activities and data including but not limited to, username, user's full name, successful and failed login and log-out attempts, date and time of each activities, and origin of the activity.
   11. The SU/FA and users must report inappropriate or suspicious activities, such as misuse of the RPMS Direct system and PHI/PII, using the IRT procedures for reporting contained in the IHM, Part 8, Chapter 9, "Establishing an Incident Response Capability", and local facility procedures.  Additionally, local administrators shall advise the Area and/or local Privacy Officer and ISSO of the incident(s) and include them in the investigation, response, and any subsequent notification that is required by law.
   12. Local facility RPMS Direct policies must be in place and enforced by management responsible for enforcement of privacy, security, and access to PHI.
   13. The Supervisor, Privacy/Security Officers and/or Compliance Officer will have established or incorporated specific RPMS Direct Audit Process policies in their training, compliance, and/or administrative policies.  Any facility seeking designation of a SU/FA attests to having local policies that are subject to audit, and accepts responsibility for enforcing these policies, at risk of access being disabled to RPMS Direct.
   14. A request must be submitted to the SU/FA to establish a trust relationship to exchange secure messages with external healthcare organizations.  See Section 8-23.10, "Administrator Access to the RPMS Direct Messaging System," for more information.

8-23.10  ADMINISTRATOR ACCESS TO THE RPMS DIRECT MESSAGING SYSTEM

1. Purpose.  This section establishes the process for IHS RPMS Direct Messaging administrators within the Indian health system to manage the RPMS Direct system.  The RPMS Direct is a secure, web-based messaging service, intended for the exchange of patients' health information between healthcare providers and their patients and/or their personal representatives, and among healthcare providers.  The RPMS Direct administrator portal is a secure, web-based portal, designed to support administrative functions such as managing domains and user accounts, and for performing audits.  The authorized administrative users include the National Administrators, Area Administrators, and SU/FAs.  Authorized users of RPMS Direct may include Message Agents, healthcare providers, patients, and/or their personal representatives.  Note that additional responsibilities are defined in Section 8-23.9, "End User Access to the RPMS Direct Messaging System."  Authorized administrative users of RPMS Direct must adhere to the policies and procedures defined in this chapter, the "X.509 Certificate Policy for the Federal Bridge Certification Authority", and the "DigiCert "Certification Practices Statement".
2. Responsibilities.  The IHM, Part 8 Chapter 12, "Information Technology Security", describes a full set of roles and responsibilities to which staff must adhere.  This section describes additional roles and responsibilities that are required for RPMS Direct.
1. Certificate Authority.  An authority trusted by the IHS HISP for issuance and management of certificates.  The Certificate Authority (CA) will be responsible for performing the following general functions:
   1. Binding identities to cryptographic keys
   2. Creating and signing both organizational and address bound certificates
   3. Distributing certificates appropriately
   4. Revoking certificates
   5. Distributing certificate status information in the form of Certificate Revocation Lists
   6. Providing a repository where certificates and certificate status information is stored and made available
2. Registration Authority.  The RA is an authority trusted by the IHS HISP that works in collaboration with the IHS trusted CA to collect and verify information of the certificate subjects, such as, RPMS Direct Administrators and PHR Registrars, and will evaluate to either approve or reject subscriber certificate management transactions including certificate renewal, re-key, and revocation requests.
3. Chief Information Officer.  The IHS CIO is designated as the RPMS Direct Messaging system owner.  The IHS CIO shall approve the DirectTrust Framework and appoint the National Administrator(s) for the IHS HISP.
4. National Administrator.  The IHS National Administrator will:
   1. Be responsible for the RPMS Direct system and system compliance.
   2. Facilitate onboarding of the IHS HISP, I/T/U facilities and issuance of their certificates.
   3. Be responsible for management and mapping of the organizational certificates and public and private keys.
   4. Be a Trusted Agent appointed on behalf of the RA to complete identity vetting of Area Administrators and additional National Administrators.
   5. Grant and manage RPMS Direct system access for Area Administrators and additional National Administrators.
   6. Perform audits and manage maintenance, upgrades, accreditation, and re-accreditation of the RPMS Direct system.
5. Area Administrator.  The Area Administrator will:
   1. Work directly with the CA to facilitate onboarding of I/T/U facilities and issuance of their organizational certificates.
   2. Appoint local SU/FAs, grant access, and perform their identity vetting at LoA 3.
   3. Manage domain names, Area audits, and RPMS Direct system access and trainings for SU/FA.
6. Chief Executive Officer.  Each I/T/U Chief Executive Officer (CEO) shall designate one or more SU/FA at the local facility.
7. Tribes.  Tribes that have assumed Tier Two (Area level) support will have an individual assigned to an equivalent role as the Area Administrator.  The National Administrator or designated Area Administrator will assist these Tribes in onboarding related tasks that are limited to National and Area Administrators (i.e., facility domain setup and certificate order).
8. Service Unit/Facility Administrator. The SU/FAs shall appoint and grant access for facility Message Agents.  Local SU/FAs shall manage system access and complete identity vetting at LoA 3 for Message Agents, PHR Registrars, and healthcare providers.  They shall manage message forwarding, run audits, and provide trainings for their local facility RPMS Direct users and local administrators.  The SU/FAs shall work directly with the facility supervisors to update access for the local RPMS Direct users.
9. PHR Registrar.  The PHR Registrar shall manage RPMS Direct access for patients and/or their personal representatives.  The PHR Registrars shall complete the identity vetting of the patients and/or their personal representatives in accordance with Section 8-23.7, "Processing Patient Access to their Personal Health Record."
10. Message Agent.  The Message Agent shall be a facilitator of the secure messages.  They shall receive, distribute, and respond to secure messages on behalf of healthcare providers based on local policies and standards of patient care.  Message Agents can be assigned to the patient or patient groups using the DPP package in the RPMS.
3. Procedures.  Authorized users of the RPMS Direct system must comply with appropriate IHS HISP requirements, privacy and security laws, and the following RPMS Direct access procedures:
   1. Tribal and Urban organizations must enter into the MPA by executing a Joinder Agreement and agreeing to all terms in order to have access to the RPMS Direct.  See the MPA () for terms of the agreement.
   2. All authorized RPMS Direct users will be required to complete orientation, training, and sign the IHS Rules of Behavior prior to using the RPMS Direct.
   3. The RPMS Direct usage must be dedicated solely to the purposes of health related exchanges between authorized Federal and non-Federal healthcare providers, patients, patients' personal representatives, legal guardians, and other trusted external healthcare organizations.  Under the IHS HISP, only authorized individuals shall have access to the RPMS Direct system.  Only authorized administrators shall grant this access for purposes defined under the HIPAA policy and procedure at IHM, Part 2, Chapter 7, "Health Insurance Portability and Accountability Act - Privacy Rule and the Privacy Act".
   4. The National Administrator shall provide RPMS Direct system access and training and work directly with the CA and RA to do the following:
      1. Facilitate onboarding
      2. Work with facilities to determine implementation
      3. Validate facility and domain
      4. Issue the X.509 digital certificates for each facility, Area Administrators, SU/FA, and PHR Registrar
   5. The Area Administrators shall work with the CA, RA, National Administrator, and Area facilities to coordinate facility onboarding, such as sub-domain setup, issuance of the organizational certificates, and access and trainings for the alternate Area Administrator and SU/FAs within their Area.
   6. The SU/FA shall collaborate with Area Administrator for facility onboarding and:
      1. Work with the appropriate clinical manager to delegate Message Agents and alternate Message Agents for the local facility.
      2. Grant RPMS Direct access to local users, such as Message Agents and healthcare providers.
      3. Collaborate with local staff, such as the Clinical Application Coordinator, HIM Supervisor, or other appropriate staff to provide required trainings to Message Agents, PHR Registrar, and healthcare providers.
      4. Work with the appropriate clinical manager who will ensure that the Message Agent is assigned to the patient or group of patients using the DPP package in the RPMS.
      5. Setup message forwarding for users during their absence.
   7. All RPMS Direct users must have their identity vetted at LoA 3 and be assigned a default password during initial registration.  Users are advised of the password reset process and required to change their password upon login. Passwords must meet password requirements defined in the "RPMS Direct Messaging User Manual".
   8. All designated RPMS Direct administrators must utilize the appropriate method below to manage and track assigning, reassigning, or resigning of the RPMS Direct account access:
      1. Federal facilities and T/U facilities that participate in the ITAC System must utilize the ITAC System.  More guidance can be found in the "IHS General User Security Handbook".
      2. Tribal and Urban administrators at T/U facilities that do not participate in the ITAC System must develop and utilize internal policies and procedures to manage and track RPMS Direct account access for their RPMS Direct users.
   9. All supervisors must contact RPMS Direct administrators immediately when the user resigns, is reassigned, or is terminated using local policies and procedures in place.
   10. All RPMS Direct administrators must add, delete, or modify users' access based upon requests submitted by supervisors.
   11. All RPMS Direct administrators shall routinely run and monitor system activities using appropriate audit reports or fields available within the RPMS Direct Messaging Administrator Application (see the "RPMS Direct Messaging Administrator Manual".
       1. These audits may be reactive audits as requested by the local CEO, HIM Supervisor, Privacy Officer, Security Officer, Compliance Officer or other individuals that have legitimate need for the information to respond to patient requests for accounting of disclosure, inquiries, breaches, and/or events.
       2. Administrators may customize audit reports based on local needs.
       3. Routine proactive audit reports that are recommended for administrators, but not limited to include: Table 8-23-C: Routine RPMS Direct Administrator Audit Reports

          Type of Activity	National	Area	Facility	Frequency (based on tier and activity
          Successful or failed authentication attempts	X	X	X	Weekly
          User's status: Active, inactive, locked account	X	X	X	Weekly
          Access attempts, unauthorized attempts, compare current access vs. disabled access	X	X	X	Weekly
          Monitor activities of Area Service Unit/Facility for compliance to audit policy	X	X		At least Annually
          Monitor Administrators access to ensure accounts disabled for terminated and retired staff within 24 hours	X	X	X	Weekly
          Locked out users report			X	Bi-weekly
          RPMS Direct users under each domain	X	X	X	Annually
          Annual Re-authorization evaluation	X	X	X	Annually

   12. Retention of audit records shall be maintained as follows:
       1. Audit logs must be stored for 90 days or longer at each site, as storage permits.
       2. Audit reports must be retained for a minimum of six (6) years at each site.
   13. All Administrators must report inappropriate or suspicious activities, such as misuse of the RPMS Direct and PHI/PII as follows:
       1. IHS facilities shall use the IRT procedures for reporting contained in the IHM, Part 8, Chapter 9, "Establishing an Incident Response Capability", and local facility procedures
       2. T/U facilities shall use their local breach procedures.
          1. The local policies and procedures for audit must comply with policies herein and HIPAA procedures for breach notification.
          2. The IHS IRT should be notified whenever an incident impacts the IHS network and/or data owned or maintained by IHS.  The T/U facilities must notify the IHS IRT in case of a suspected breach by e-mail.
       3. Additionally, local administrators shall advise the Area and/or local Privacy Officer and ISSO of the incident(s) and include them in the investigation, response, and any subsequent notification that is required by law.
   14. The IHS HISP must establish a trust relationship with external healthcare organizations to enable secure exchanges using RPMS Direct.  To establish a trust relationship, designated administrators shall follow procedures defined in all RPMS Direct policies and procedures including the following:
       1. The SU/FA must open an IHS Service Desk ticket to notify Area and National Administrators to begin discussion with potential external Direct healthcare organizations and their HISP.
       2. The external healthcare organization's HISP shall work with the National Administrator for onboarding with the same Trust Framework and Trust Bundle with which IHS is established.
       3. Upon successful onboarding with the IHS established Trust Bundle, the National Administrator shall ensure secure exchange is enabled and the Trusted Community Partner (Healthcare Organization) list is updated.
   15. The SU/FA and PHR Registrar shall provide support, as appropriate, to their local healthcare providers and patients and/or their personal representatives, respectively.
   16. Local facility RPMS Direct policies must be in place and enforced by management responsible for enforcement of privacy, security, and access to PHI.  As an example, the Governing Body, CEO, HIM Supervisor, Privacy/Security Officers and/or Compliance Officer will have established or incorporated specific RPMS Direct policies in their training, compliance and/or administrative policies.  Any facility seeking designation of a SU/FA attests to having local policies that are subject to audit, and accepts responsibility for enforcing these policies, at risk of access being disabled to RPMS Direct.