The issue of whether to what extent, and how individuals should have the ability to access and control over their health information represents one of the foremost policy challenges related to the electronic exchange of health information.

1. This document is confidential and contains proprietary information, including trade secrets of CitiusTech. Neither the document nor any of the information
contained in it may be reproduced or disclosed to any unauthorized person under any circumstances without the express written permission of CitiusTech.
CitiusTech Thought
Leadership
14 December, 2018 | Author: Aniruddha Mandale , Rakesh Waghulde | Technical Lead,
Sr. Software Engineer
Implementation of Consent in Health
Information Exchange (HIE)
CitiusTech Thought
Leadership

2. 2
Objective
 The issue of whether to what extent, and how individuals should have the ability to access and
control over their health information represents one of the foremost policy challenges related
to the electronic exchange of health information
 States and federal laws are engaged in facilitating the exchange of electronic health
information are struggling with a host of challenges, primarily on establishment of policies and
procedures for patient participation in their exchange efforts
 The purpose of this deck is to overcome the challenges faced by HIE’s while managing consent
for the patients by different methods and use cases
• To understand concept of consent management and types of concept in HIE (Health
Information Exchange)
• To illustrate five consent models, granularity and its types
• To explain payer and provider use case with use of consent models and granularity
 Until the time when we are confident that we can protect health information in a systematic
and thorough way, prudent use of the mechanism of consent appears to be one of the most
reliable ways to pursue that goal
 We are assuming that readers are already aware about HIE workflows and basic concepts of
consent

3. 3
Agenda
 Consents in HIE
 Consent Management in HIE
 Consent Management Case Study
 The Five Consent Models
 Granularity and Choice
 Users and Roles in HIE
 Use Case for Consent Implementation
 Key Takeaways
 References

4. 4
Consent in HIE
 In HIE, user access to patient data is controlled by consent which can be granted to users for
specific purposes of use at different levels and for a specific period of time (start and end time)
 The consent models at HIE range from No Consent, to Opt-out, Opt-out with Exceptions, to Opt-
in, and Opt-in with restrictions; or a combination of these models
 The selection of a Consent model is typically influenced by federal and state law, HIE policy, as
well as the input of stakeholders – providers, patients, public health, and others
 HIEs today collect consent preferences from patients using a number of methods which can be
categorized into two groups: directly from the patient to HIE and indirectly through the patient's
provider
 In both methods, the consent is collected from the patient (or the patient's authorized agent)
either electronically (such as on a web-based form), on paper, or orally (which may be in person,
or over the telephone)
 In general, consent is obtained (or not) at the provider point of care level, with educational
assistance regarding notification and consent options often facilitated by the relevant HIO
 The operational requirements of obtaining and managing consent in an HIE are influenced by the
consent model selected by the HIE

5. 5
Consent Management in HIE
 The timely exchange of health information between health providers in an HIE to support care coordination is a
critical element of the National Quality Strategy and health reform efforts. However, privacy and confidentiality
concerns are currently limiting the inclusion of behavioral health data in electronic health information
exchange efforts
 The Office of the National Coordinator (ONC) for Health Information Technology encourages providers and
organizations involved in electronic health information exchange to develop policies and technical approaches
that offer patients more consent choices than simply having all or none of their information shared
 There are two ways consent can be managed in HIE’s – Consent to Access and Consent to Disclose
Consent to Access (and Display)
 Consent to Access preferences control if a provider can see any set of available records
 If you consider the patient’s entire set of records as a house, you can consider Consent to Access as a lock on
the front door (in this case the only door to enter the house from outside). So, if it is locked or Consent to
Access is N, the user is “stuck outside” and cannot view any of the patients’ records within the house
Consent to Disclose
 Consent to Disclose preferences control if a provider can see records that come from a specific data source
 In the house analogy, imagine that each room in the house stores contents from a specific data source, and
each of these rooms also has a door / lock on it. So if a user has achieved access to the house through the front
door, then they may or may not be allowed access to specific rooms based on Consent to Disclose preference
 If Consent to Disclose for any data source is N, then the user will be “stuck outside” that room and will not
have access to that room / data sources data

6. 6
Consent Management Case Study (1/2)
 A patient, John Doe, visits various hospitals in HIE. He first goes to doctor Smith of InGen
hospital and gets a few medical tests done. These reports / documents are submitted to HIE.
We call these set of documents as D1. Later he goes to another facility Kandy and gets another
set of medical tests done. These reports are submitted to HIE. We will call these set of
documents as D2
 Whether a user can see documents from other facility or not, is decided by cumulative result
of Consent to Access and Consent to Disclose
As doctor Smith is currently logged in, he is from InGen workgroup, and his
Consent to Access is Yes. He can view documents in HIE based on Consent
to Disclose preference. As Consent to Disclose for both the workgroups
(Ingen and Kandy) is Yes, he can view D1 and D2 both
Case 1 Hospital Name Consent to Access Consent to Disclose
InGen(D1) Yes Yes
Kandy(D2) No Yes

7. 7
Consent Management Case Study (2/2)
In this case, as Consent to Access is Yes for InGen, he can view documents
based on Consent to Disclose. As Consent to Disclose for Kandy workgroup
is No, he can’t view documents from Kandy workgroup
Case 2
Hospital Name Consent to Access Consent to Disclose
InGen(D1) Yes Yes
Kandy(D2) No No
In this case, as Consent to Access itself is No for both the hospitals, he can’t
view any of the document. In this case, Consent to Disclose would not be
considered
Case 3
Hospital Name Consent to Access Consent to Disclose
InGen(D1) No Yes
Kandy(D2) No Yes

8. 8
The Five Consent Models (1/3)
 Based on various forms of electronic exchange in the U.S., as well as other sources in the public
domain, there are five core consent models:
• No consent
• Opt-out
• Opt-out with exceptions
• Opt-in
• Opt-in with restrictions
 These consent models are presented in order from “lowest” to “highest” in terms of reflecting
the extent to which consumer preferences are integrated and accommodated
 It is important to note that the models are intended to apply for participation in a HIE effort and
are not intended to imply constraints to the usual transmission which is paper or electronic type
of information for treatment, payment, or healthcare operation purposes as permitted under
HIPAA and other relevant federal and state laws

9. 9
The Five Consent Models (2/3)
No Consent
 This model provides no opportunity to accommodate individual preference with respect to
participation in electronic exchange, so the health information of patients under the care of a
participating provider organization is automatically included in and available (often according to
certain rules) through the exchange
 Any provider can access the data for the patients in HIE
Opt-out
 In a typical Opt-out scenario, either the information of the patient who opts out is collected
through the exchange (used only for legally permitted purposes, such as public health reporting,
but never shared with other providers for clinical care), or the patient’s preferences are captured
and propagated such that his/her clinical information never enters the exchange
 In an Opt-out model a provision that patients must be given the opportunity to Opt-out fully
means all the patients have by default consent as Opt-in
Opt-out with Exceptions
 In an Opt-out with exceptions model, the default is that all or some pre-defined set of data is
eligible for exchange, but patients can either Opt-out fully (as described in Opt-out model) OR
selectively exclude categories of data / specific data elements from the exchange
 Limit exchange of their information to specific providers / provider organizations
 Limit exchange of their information for specific purposes like for payment, operations, treatment,
emergency etc.

10. 10
Opt-in
 In an Opt-in model, the default is that no patient data are automatically made available for
electronic exchange
 In an Opt-in model a provision that patients must be given the opportunity to Opt-in fully means
all the patients have by default consent as Opt-out in Opt-in model
 Patients wishing to make all, or a pre-defined set, of their information available must actively
express their desire to participate.
Opt-in with Restrictions
 In an Opt-in with restrictions model, the default is that no patient data are automatically made
available for electronic exchange. Patients wishing to make all, or a pre-defined set, of their
information available for exchange must actively grant their consent to participate
 Patients have an option to include only specific categories of data or / data elements, enable
information to flow only to specific providers as well as allow their information to be exchanged
only for specific purposes
The Five Consent Models (3/3)

11. 11
Granularity and Choice (1/3)
In numerous ways, and for a variety of reasons, patients participating in electronic exchange may
prefer to:
 Exert some control over the type and level of information that can be shared (Granularity by data
type);
 Restrict information accessed via electronic exchange to a limited (and potentially specified) set
of individuals or entities (Granularity by provider)
 Establish preferences for the given timeframe for which information could be accessed via
electronic exchange (Granularity by time range)
 Specify various purposes for which their information could be used via electronic exchange
(Granularity by purpose)

12. 12
Granularity and Choice (2/3)
Granularity by Data Type
 One of the most commonly discussed issues in the context of HIE is whether patients should be
able to block specific data elements (e.g., a recent lab test), categories of data (e.g., all
medications) from being exchanged electronically
 Most HIE expressly exclude the exchange of sensitive information and do so because they do not
know how to interpret the various federal and state policies and regulations that apply to
sensitive information. Along with that they have not yet determined how best to handle the
technical and procedural challenges associated with data segmentation as well as they wish to
establish a basic level of trust before exchanging information considered as “sensitive”
Granularity by Provider
 One way of addressing consumer concern about electronic exchange is to restrict information
access to only those providers approved by the patient. This method is referred to as granularity
of consent by provider
 The patient is given the option to permit access to only specific provider or staff types (e.g., all
MDs and RNs could be granted access, but not office staff); or the patient is given the option to
restrict access at the provider entity level (e.g., primary care and cardiology practices are granted
access, but the allergist is not)

13. 13
Granularity by Time Range
 An entity engaging in electronic exchange with HIE could make the determination that it is only
necessary to have the most recent clinical information available to providers and other partners
via exchange
 An entity engaging in electronic exchange could allow patients to apply a time range restriction
that corresponds to specific episodes of care that may be particularly “sensitive’ in nature (e.g., a
month spent in a rehabilitation clinic). In this case, provider access to all other clinical
information on the patient could be allowed, but any clinical information recorded between X
and Y dates would be blocked
 An entity engaging in electronic exchange could institute specific time-sensitive “use cases” that
enable information access only for a certain period of time
Granularity by Purpose
 The primary appeal of granularity by purpose is that, assuming patients choose to consent for
allowing their information to be used for treatment purposes, and unless this choice is coupled
with other granularity options, it enables all relevant clinical information to be made available via
electronic exchange
 With this type of consent, patients would have the option to consider all possible uses of their
information that is available via electronic exchange (e.g., care delivery, quality improvement,
clinical research, health services research), and then determine which uses would be acceptable
to them (i.e., consent to use of information for specified purposes only)
Granularity and Choice (3/3)

14. 14
Users and Roles in HIE
Admin have all the rights as shown below, but caregiver can only view the records and change the
consent for a patient. Security Officer have rights for auditing the patient and provider logs history
View Patient Data
Manage Patient Consent
Patient
Audit History
Admin Settings
Provider (User)
Audit History
PE Admin
Caregiver
HIE Admin
Security
Officer
HIE Hospital
Roles

15. 15
Use Case for Consent Implementation
The use case defines an access to patient data in HIE by Payers and Non-Payers (Hospitals) with set of
rules defined below:
1. With reference to granularity by purpose, the user (Payers) should only be able to see a patient in
HIE if:
• Consent status for payer is explicit Opt-in
• Consent is valid or a specified time range
2. Payer should not see data if:
• HIE consent model is complete Opt-out or complete Opt-in
• Payer consent is complete Opt-in model
• HIE consent is default or unknown
4. Payers cannot change:
• The HIE consent
• Their own consent if HIE consent model is Opt In
5. Payers can change their own consent if HIE consent is according to Opt-out model
6. Non-payers (Hospitals) can change the HIE consent or their own consent in both the Opt-out and
Opt-in models
7. Complete Opt-out model means any user can access the patient data and all patients have by
default consent as Opt-in
8. Complete Opt-in model means no user can access patient data unless consent is explicitly applied

16. 16
Payer’s Consent to Access Patient (1/3)
Below is the flow chart which follows set of rules of consent implementation explaining all the use
cases of payer’s consent to access the patient information:

17. 17
Payer’s Consent to Access Patient (Opt-in) (2/3)

18. 18
Payer’s Consent to Access Patient (Opt-out) (3/3)

19. 19
Non Payer’s Consent to Access Patient (1/3)
Below is the flow chart which follows set of rules of consent implementation explaining all the use
cases of non payer’s consent to access the patient information:

20. 20
Non Payer’s Consent to Access Patient (Opt-in) (2/3)

21. 21
Non Payer’s Consent to Access Patient (Opt-out) (3/3)

22. 22
Key Takeaways
 Patients, providers, payers, HIEs, and other participants in electronic exchange efforts all have
something at stake in individual choice model decisions
 The choice of which patient consent model to apply for the purposes of electronic exchange will
have immediate implications for a variety of stakeholders, and possibly longer-term
consequences for national HIE goals
 The effects of consent related policy implementation at the state level are substantially similar,
except that states only have the legal power to mandate action within their geographic
boundaries and cannot contradict superseding federal law
 State laws supporting the use of No Consent models would essentially maintain the status quo;
laws mandating use of an Opt-out model would require entities to develop compliant policies;
and laws requiring use of an Opt-in model would demand alteration of the practices of all entities
currently using No Consent or Opt-out models
 The selection of consent models has to come with the level of granularity or combination of
multiple granularities to have patient chart access in an exchange
 The state can define their own consent policies according to federal laws like minor consent and
Participating Entity (PE) level consent

23. 23
References
 https://www.healthit.gov/
 http://healthit.hhs.gov/portal/server.pt?open=512&mode=2&cached=true&objID=1147.
 http://www.himss.org/ihie-community-roundtable
 http://www.optuminsight.com/healthcare-connectivity/systems-integration/hie/
 http://www.markle.org/health/markle-common-framework
 http://healthit.hhs.gov/HISPC
 http://www.hawaiihmis.org/governance/consentprivacy-docs/

24. 24
Thank You
Authors:
Aniruddha Mandale
Rakesh Waghulde
thoughtleaders@citiustech.com
About CitiusTech
2,900+
Healthcare IT professionals worldwide
1,200+
Healthcare software engineers
700+
HL7 certified professionals
30%+
CAGR over last 5 years
80+
Healthcare customers
 Healthcare technology companies
 Hospitals, IDNs & medical groups
 Payers and health plans
 ACO, MCO, HIE, HIX, NHIN and RHIO
 Pharma & Life Sciences companies