42CFR

= = =Executive Summary= An electronic behavioral health record (eBHR) has an additional privacy constraint due to 42-CFR Part II that requires consent before federal funded substance abuse programs can disclose a patient’s identify. However, an eBHR can be shared similar to other types of health records once proper consent is acquired. Data is electronically shared on a Health Information Exchange (HIE) and there are two types of HIE models where this occurs. Additional agreements related to the operation of the HIE are required depending on what model HIE the information is shared on. HIEs have consent models that define implicit patient consent on participating patient records. For 42 CFR Part II, the HIE consent model must require patient consent before an eBHR would be disclosed to a new entity. =Introduction= The ONC’s publication describes how consent is implemented within the existing electronic health information exchange (HIE) landscape of 2010. The SAMHSA publication applies 42-CFR Part II non-disclosure requirements to an electronic behavioral health record (eBHR). Three key finding from the SAMHSA publication are specifically addressed in this paper on the feasibility of eBHR sharing.
 * parent**: Thoughts
 * Recommendations **
 * 1) Incorporate, don’t replace existing patient consent processes for 42-CFR Part II with an HIE
 * 2) Ensure that the HIE’s consent model requires patient consent for providers to subsequently re-disclosure to other providers of information
 * 3) Ensure that patient consent can be updated
 * ~ # ||~ 42-CFR Finding ||~ Addressed ||
 * 1 1 || **A Qualified Service Organization Agreement (QSOA) is necessary for eBHR sharing on certain HIEs** || ** “ **Consent Requirements” ||
 * 2 2 || **Patients can provide consent at the releasing agency or requesting agency** || ** “Patient Consent” ** ||
 * 3 3 || **HIEs are required to enable patient’s to update their consent preferences** || ** “Consent Management” ** ||

This paper analyzes the feasibility of sharing an eBHR with-in the 2010 HIE landscape with specific focus on the following four questions.
 * 1) Given the constraints 42-CFR Part II SAMHSA FAQ, can the behavioral health records of substance abuse patients be shared on an existing HIE?
 * 2) If so, how would an SSA or County do this in a HIE?
 * 3) What are some scenarios for sharing an eBHR?
 * 4) Is there precedent on reporting from HIEs? [[file:///C:/Users/tcalice/Downloads/ReactionTo42CFR_FAQ_2010_1004%20draft03.docx#_msocom_1|[A1]]]


 * References **
 * **# ** || **Reference ** ||
 * **1 ** || Legal Action Center for the Substance Abuse and Mental Health Services Administration. (2010, 6 17). //Frequently Asked Questions: Applying the Substance Abuse Confidentiality Regulations to Health Information Exchange (HIE).// Retrieved 10 11, 2010, from The Substance Abuse and Mental Health Services Administration : http://www.samhsa.gov/HealthPrivacy/docs/EHR-FAQs.pdf ||
 * **2 ** || Goldstein, JD, M. M., Rein, MS, A. L., Hughes, JD, P. P., Lappas, JD, J. K., Weinstein, S. A., & Williams, B. (2010, 03 23). //CONSUMER CONSENT OPTIONS FOR ELECTRONIC HEALTH INFORMATION EXCHANGE: POLICY CONSIDERATIONS AND ANALYSIS.// Retrieved 10 11, 2010, from HealthIT.hhs.gov: http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_11673_911197_0_0_18/ChoiceModelFinal032610.pdf ||

Electronic Behavioral Health Record (eBHR) Overview
An electronic behavioral health record (eBHR) is electronic documentation of a patient's medical history and care. In eBHR systems, there are two layers of control that protect patient privacy by limiting access to the eBHR. As displayed in the figure below “Restricting Access to the eBHR”, the first layer of protection is privacy. This layer restricts who can access what aspects of the patient’s record. In the context of a federal funded substance abuse facility, even access to a patient’s name is restricted without patient consent. The final layer of protection is security that consists of technical safeguards designed to prohibit or detect access to a record.


 * ** Restricting Access to the eBHR ** ||
 * The **electronic behavioral health** **record** is maintained in a restricted manner in which two layers limit the access to the record.

The first is a **privacy** layer that controls the extent in which information can be made available. This is often based on a combination of: roles, patient consent, and Personal Health Information (PHI)

The last layer in a typical eBHR is **security** which is an implementation of technical safeguards such as user-ids/passwords, logging, encryption, and tamper evident hashing. ||   ||

=The 42 CFR Part-II “non-disclosure” constraint= In the absence of patient consent to share records, an additional “non-disclosure” safeguard prevents federally funded substance abuse facilities from acknowledging the existence of a patience record. This safeguard makes the patient invisible to the other providers on the Health Information Exchange (HIE). Requesting organizations should be unaware of a patient existing on the HIE without a patient consenting their eBHR to be disclosed. This constraint impacts how patient discovery occurs on an HIE. Patient discovery is a transaction consisting of patient identifying information sent by a requesting provider to another provider in order to establish the existence of a patient. This transaction is the root for all subsequent health record requests. =eBHR data sharing in an HIE= Electronic health records are shared on HIEs. Based on the types of HIE, 42-CFR has different constraints on the agreements needed in order to share data. The two basic models of health information exchanges are the central data repository (CDR) and federated model (health record messaging). The CDR is a single data repository. In this repository (see Figure 1), the patient’s longitudinal record of care is integrated with multiple organizations. Access to a patient record is centrally managed by a Health Information Organization (HIO) and requires a common understanding of CDR’s data elements between the participating organizations. The federated model (see figure 2), on the other hand, lacks a central repository and participating organizations directly share information with each other through health message containing an interoperable eBHR. Figure 1 ~ Hub and Spoke Model (CDR) || Figure 2 ~ Federated Model (Health Record Messaging) || Figure 2: The eBHR is messaged between various nodes in the HIE and not stored in a central repository ||
 * Patient Consent **
 * Excluding medical emergencies, patient consent (see **//42 CFR Patient Consent (9 required elements)//**on page ****8 ****) is required before a patient’s eBHR can be shared with another provider. Patient consent can be provided at either the releasing agency or the sending agency. **
 * In an HIE, two aspects of the patient consent require special attention for sharing an eBHR. The first is the ability for the patient to revoke consent at any point in time. The second is the identification of all parties that disclosure will be made to. This impacts the various types of consent models (see Consent Models page 6) and some of the technology available to share records on an HIE (see Two HIE Models on page 3) **
 * Impact to sharing in an HIE **
 * Two HIE Models **
 * ** What would data sharing look like in an HIE? ** ||
 * [[image:HubAndSpokeSharing.png]]
 * Figure 1: The eBHR is centrally located and updated in a central data repository. Access to the patient’s record is centrally controlled

Based on the type of HIE, there may be different consent required. As mentioned previously, patient consent<span style="font-family: Calibri,sans-serif; font-size: 11pt;"> is required in order for a federally funded substance abuse facility to disclose any aspect of an eBHR including patient name. If an eBHR is exchanged on an HIE that uses a CDR model, two additional agreements (see figure 3) are required. The HIO managing the CDR must have an executed Qualified Service Organization Agreement (QSOA) with the source of the patient eBHR and the patient must additionally consent to the HIO having a copy of their eBHR. The QSOA is typically a one-time agreement between organizations on the HIE that doesn’t need to be created every time a patient provides consent. On the other hand, the federated HIE (as shown in figure 4) does not have an intermediary and therefore doesn’t require additional consent.
 * <span style="font-family: Calibri,sans-serif;">Consent Requirements **
 * ** Types of Consent Required for 42 CFR Part II ** ||
 * [[image:ConsentInHubAndSpoke.png align="center"]]

Figure 3 Consent in an Hub and Spoke HIE ||

Figure 4 Consent in a Federated HIE ||
 * In Figure **3**: At least 4 agreements are required before a patient’s record can be shared between federally funded substance abuse providers || In Figure 4: The patient just needs to provide consent for the source provider to share their eBHR with another provider. ||

In addition to explicit patient consent, the HIE (CDR or Federated) will have an implicit type of consent by virtue of the eBHR being share on the exchange called a consent model. There are five consent models –as displayed in the image below- in a HIE that vary in the spectrum of most restrictive to least restrictive. A consent model defines if and to what extend information can be shared in an HIE. Since 42 CFR requires a patient’s knowledge of the information to be shared with an organization, substance abuse information could only be shared in either an “Opt-In” or more restrictive model. =Exchanging an eBHR= The “non-disclosure” safeguard is not an impediment to sharing an eBHR. Multiple exchange patterns exist for sharing health records. An exchange pattern is a collection of one or more transactions for sharing a health record between systems. Two exchange patterns, in particular, that provide practical solutions to the “non-disclosure” constraint of the eBHR are the Asynchronous patient discovery and Directed Message. An asynchronous patient discovery protects the patient’s anonymity until it is determined that there is appropriate consent to disclose patient information. This is accomplished by separating patient discovery into two separate, independent transactions. The initiating patient discovery is not immediately responded to and the pause allows the provider to manually determine if they have the proper patient consent in order to disclose their information. If there is appropriate consent, the request is responded to. Otherwise the request would remain indefinitely in queue and unacknowledged. Asynchronous patient discovery satisfies eBHR privacy constraints and allows providers to use their own process to manage consent. The directed message is a one-way push of the patient’s health record to a source. This type of exchange is straightforward and eliminates multiple burdens. Similar to when information is shared via other direct channels (primarily fax or mail), the initiator of the transaction is responsible for ensuring proper consent is acquired before sharing information. Furthermore, this reduces complexity around the correct identification of patient data. This type of exchange, however, is dependent on patient pro-actively providing consent and directing their provider to send information. In either the Asynchronous Patient Discovery or the Directed Message, patient consent is able to be acquired/stored in an “out of band”<span style="font-family: Calibri,sans-serif; font-size: 11pt;"> process. As a result existing consent management processes would likely be compatible with sharing an eBHR electronically. =Conclusion and Recommendations= Sharing an eBHR is initially dependent on data standards. The eBHR safe guards required by 42-CFR Part II do not prohibit electronic sharing of information. An eBHR can be shared on any model of HIE as long as patient consent has been acquired. The consent model of the HIE, however, must require patient consent before records can be shared with other entities. Give that, all consent requirements can be satisfied with existing processes and the same technology for an eHR.
 * <span style="font-family: Calibri,sans-serif;">Consent Model **
 * <span style="font-family: Calibri,sans-serif;">Consent Management **
 * <span style="font-family: Calibri,sans-serif;">After patient consent **<span style="font-family: Calibri,sans-serif; font-size: 11pt;">[[file:///C:/Users/tcalice/Downloads/ReactionTo42CFR_FAQ_2010_1004%20draft03.docx#_ftn5|[5]]] **<span style="font-family: Calibri,sans-serif;"> is given to share an eBHR, there is the potential for circumstances that may cause patients to alter their consent. Therefore it is necessary for HIEs to manage the consent patient have/are giving for their records to be shared. **
 * //<span style="font-family: Calibri,sans-serif;">Bottom line //**
 * <span style="font-family: Calibri,sans-serif;">The HIE must have a consent model that requires patient consent for subsequent information sharing. Additionally, patients must have the ability to change their privacy preferences. **
 * <span style="font-family: Calibri,sans-serif;">Asynchronous patient discovery **
 * <span style="font-family: Calibri,sans-serif;">Directed Message **
 * //<span style="font-family: Calibri,sans-serif;">Bottom line: //**
 * <span style="font-family: Calibri,sans-serif;">Recommendations **
 * 1) Adopt data standards
 * 2) Incorporate, don’t replace existing patient consent processes for 42-CFR Part II with an HIE
 * 3) Ensure that the HIE’s consent model requires patient consent for subsequent disclosure of information
 * 4) Ensure that patient consent can be updated

=Appendix=

42 CFR Patient Consent (9 required elements)

 * # || Element Description ||
 * 1 || Program or person __permitted to make the disclosure__ ||
 * 2 || name or title of the individual or the name of the organization __to which disclosure is to be made__ ||
 * 3 || Patient Name ||
 * 4 || __purpose__ of the disclosure ||
 * 5 || __What information__ to be disclosed ||
 * 6 || Consent (signature of patient or guardian) ||
 * 7 || date of consent ||
 * 8 || statement that the **consent is subject to** __revocation__ at any time ||
 * 9 || __Consent expiration__ (date, event or condition upon which the consent will expire) ||

<span style="font-family: Calibri,sans-serif; font-size: 10pt;"> dictated by 42 CFR Part II, HIPAA, and GINA <span style="font-family: Calibri,sans-serif; font-size: 10pt;"> dictated by Federal Health Information Processing Standards (FIPS) <span style="font-family: Calibri,sans-serif; font-size: 10pt;"> Identifying information is typically: First Name, Last Name, Gender, and Date of Birth <span style="font-family: Calibri,sans-serif; font-size: 10pt;"> The signed consent must nine elements (including the patient’s signature and the organization to which disclosure is being made). <span style="font-family: Calibri,sans-serif; font-size: 10pt;"> See Appendix (9 Elements of Consent Given in 42-CFR) <span style="font-family: Calibri,sans-serif; font-size: 10pt;"> “Out of Band” is a term used to indicate an information exchange occurring outside of an HIE, such as paper.



I have started to address these two items in addition to the way a privacy profile for NHIN could enable Federally Funded SA facilities to exchange eBHRs on current HIEs.