1. Architectures and Processes for Nationwide Patient-Centric Consent Management
P. Mork, A. Rosenthal, and J. Stanford
The MITRE Corporation
Abstract
Background: Before electronic health information can be shared, the patient’s consent must be obtained. However,
the current paper-based process is insufficient at a nationwide scale. Improvements will need to be introduced
gradually, in a manner compatible with an exceedingly complex system: multiple professions, islands of partial
standardization, radical differences in automation and technical sophistication, autonomous players with differing
motivations, refusals to participate, external data sources, an evolving and unpredictable legal landscape, and
pressure groups from privacy advocates, researchers, and health providers.
Objective: We propose pragmatic requirements and a highly patient-centric, Internet-based consent management
architecture .
Methods: We examine requirements for serving a wide variety of patients and providers, including their diverse
incentives. Based partly on experience with our Kairon Consent prototype, we then describe a modular,
incrementally adoptable system design, and illustrate its behavior and advantages via use cases.
Results: Our approach lets patients specify their privacy preferences covering a variety of possible uses of their
personal health information in one virtual document; emergencies and research can be included. Record holders can
retrieve the patient’s privacy policies, reconcile with what they are willing to enforce, and mix in government
defaults and mandates as additional rules. Then, we describe how a record holder uses the consent service to
determine just the privacy constraints that need to be enforced for a particular request. With today’s systems, many
of these constraints need to be verified manually; our architecture enables incremental automation. We illustrate
how our architecture can support a wide variety of use cases, and examine the independent stakeholders’ incentives
to participate. The approach was found able to handle an extremely wide range of requirements, but not all. Open
problems were identified; while new features are needed, the architecture extends naturally.
Conclusion: It is technically feasible to implement very flexible patient-centric consent, considerably beyond the
scope of current Data Segmentation standards initiatives. .
Introduction and Background
1.1 Introduction
As the world moves towards widespread adoption of electronic health records (EHRs), one of the most frustrating
problems is how to meet legal/regulatory requirements to obtain and apply patients’ consent to share data with other
parties. The business case for interoperable EHRs rests in their ability to exchange data to support patient care,
clinical research, and biomedical surveillance. However patients have a justified fear of exposing their health
information to third parties and consider the ability to control the use of their data to be critically important. This
paper proposes a technical approach to meet many of the consent management desiderata established by the Office
of the National Coordinator for Health Information Technology (ONC) [1 Gold1, 2 Mark1]. We also discuss the
policy issues that arise when sharing health information on a nationwide scale, such as the U.S. Nationwide Health
Information Network.
Providers currently supply consent forms, explain them to patients and bear the burden of enforcement, so their
concerns tend to be favored over the patients’ concerns. To minimize burdens, they rarely provide the ability to
express nuanced consent preferences [4 Mark2]. Instead, a typical provider institution creates its own form, usually
notifying patients of the institution’s HIPAA data sharing policies, but not allowing patients to express their own
privacy preferences. Also, its stack of paper consent forms cover a narrow range of anticipated data sharing. If a
patient needs to have his records forwarded to another physician or to be screened for research protocols, he often

2. has to complete additional paper forms for each request. When the patient wishes to revoke consent, providers
holding consent forms that enable them to disclose data need to be identified and those forms updated. (It seems
infeasible to “claw back” data that has been released, because data from an imported document may percolate to
many parts of the recipient’s EHR, and a recipient who has acted on it wants to document what they knew, when.)
We aim to enable systems that support patient privacy, and are flexible enough to adapt to the compliance
requirements of many jurisdictions, both internationally and among the 50 US states. Elegance and flexibility are
required, rather than a mass of idiosyncratic features. The architecture is intended to be flexible enough to adapt to
legal requirements, including future ones, rather than being a perfect fit for today.
Our objective is to get suitable policies (rulesets) to the record holders, automate more decision-making, reduce
costs, and make it feasible to document the patient’s wishes in a form that is readily accessible, understandable and
up-to-date. This paper describes one part in detail -- handling the patient’s preferences. The Future Work section
briefly explains how we will mix in government and record holder preferences, reconcile with a record holder’s
enforcement ability, and provide an integrated ruleset, so patients and others can understand how the combined
system will behave.
In our “Kairon” prototype, a patient manages one preferences document (a ruleset) that is used for all requests to all
record holders. This allows patients to guide data sharing by independent laboratories and health information
exchanges (HIEs) with whom they have no direct relationship. By providing nationwide access to up to date consent
preferences, we enable patients to update their preferences in one place, without contacting every potential record
holder. We propose an Internet-accessible consent service, which is patient-centric in three senses:
• Preference management: The preferences are stored by the consent service on behalf of the patient, not by each
provider. The patient can update them at will. Upon each request; the service provides the current version to
apply.
• Preference choice: The patient expresses their own privacy preferences, usually in terms of recipient’s
attributes (credentials and relationships), rather than as individuals. Record holders cannot reject a patient’s
ruleset, but may return unknown for terms that the automated system cannot evaluate.. (Issues of medical
safety are briefly discussed in the appendix)
• Choice of consent format: The vocabulary and constructs employed to express consent are chosen on behalf of
the patient, by the consent service they subscribe to. The preferences can be defined in patient-friendly terms
and each rule (e.g., “do not release any information about sexually-transmitted diseases”) need be stated only
once. This is as opposed to the patient having to decipher the release form for each provider individually and
struggle to explain specific preferences in the form the provider accepts.
All participants in an exchange gain some benefit from patient-centric preference management. The benefit will be
greatest in jurisdictions where laws permit generalized rules such as “release to any clinician known to be treating
me”. Patients can establish their privacy preferences just once, and update in one place with effect on all record
holders. Record holders do not need to elicit a new document (possibly with counseling) for each new exchange of
health information, nor worry whether their consent is current. Enforcement may be more palatable when bundled
with a capability record holders want, such as enforcement of government and organizational rules. These factors
somewhat mitigate disadvantages, such as lower record holder autonomy and the need to counsel patients for whom
automated help does not suffice. Requestors will not need to solicit consent for every request, nor do it in terms of
the record holder’s consent form. Such a simplification might encourage dentists and chiropractors to push data to
the primary care provider (PCP), or the PCP to share data with any researcher they approve. This would be
especially important for recruiting to research studies or for analyses that need many patients’ data. (Some patients
will be willing to consent to have their data referenced for research, especially after “lite” deidentification and for
approved researchers). Recipients need not separately track privacy constraints that apply to the health information
they receive, but instead just check the patient’s current preference. All are spared paper forms, saving a major
administrative burden [1 Gold1, page ES-2].
We focus in particular on consent management challenges, relying on other services for generic data sharing
capabilities, such as: message handling (e.g., request submission and interception, transport, encryption), identity
services (authentication and matching, for patients and for health system entities), and reconciliation of semantic
heterogeneity.
The remainder of this paper is organized as follows. Section 1.2 describes the background and related work.
Section 2 describes the capabilities needed to manage patient consent and how to assemble those capabilities into a
consent management system. Section 3 demonstrates efficacy by showing how our proposed architecture handles
2

3. several common use cases, with varying degrees of automation. Section 4 summarizes the benefits of patient-centric
consent management as realized by our architecture, and comments on future work.
1.2 Background
Though it offers little flexibility, paper-based consent management is still a burden for all concerned. Some record
holders insist on signed paper, due to regulations or because they do not trust that an easily forged fax sufficiently
protects them. When a consortium of New York City hospitals agreed to upload all data to their Health Information
Exchange (HIE) and then rely on each other’s claim to have an authentic consent, sharing increased fourfold. [10
GSK1]
Several efforts have explored ways to transition to electronic management of patient consent. Integrating the
Healthcare Enterprise (IHE) has developed a conceptual model for consent management [9 IHE1] to be integrated
with EHRs. Storage can be provider-centric or patient-centric. Providers can specify interfaces through which
patients can state preferences. As provider constructs become standardized, some could be incorporated into user
interfaces, to promote easy enforcement.
Goldstein, ET al. [1 Gold1] discuss the privacy options patients are typically given: none, opt-in, opt-out, opt-in with
restrictions and opt-out with restrictions. This paper notes that patients perceive a need for more granular options to
restrict access to their health information based on such aspects as diagnosis, source, recipient, etc. However, few (if
any) of the systems they surveyed allowed patient-specified granular restrictions.
To explore electronic alternatives, ONC’s Security and Privacy Tiger Team [13 ONC2] discussed the state-of-the-
art in automated consent management systems. For example, InterSystems has a product that allows the patient to
specify which diagnosis codes can be released to whom (within that organization). [14 Inter1] This within-
organization focus is common among vendor offerings -- preferences specified in one location cannot be transferred
to another system, so they must be respecified, and updates are not propagated. [HITSP]. Current efforts include
standardization of consent metadata, funding experimental prototypes, and a “Segmentation” initiative that includes
standards for both data annotation and consent.
The President’s Council of Science and Technology Advisors (PCAST) report [16 PCAST1] recommended that
primary care providers explain consent policies and capture patient preferences face to face, but that patients should
also have access to a helpful web interface. Though we began this work two years before the PCAST report was
published, the consent system we describe here can ease these tasks with its intuitive presentation of preferences and
by storing and presenting educational materials.
Halamka [15 Hal1] would like to encourage patients to delegate authority to clinicians, to share their data as
desired. Such delegation is useful, but expresses only the clinician’s wish to receive data, not the patient’s wish to
send.
Our work draws on the privacy use cases established by the Health Information Technology Standards Panel
(HITSP), sponsored by the American Standards Institute [6 HITSP1] augmented by ONC guidance [7 ONC1]. The
HITSP Privacy Consent Directive Working Group presents key questions regarding the “cross validation and
verification of conflicting consents:
• What is the most recent/latest consent from a patient?
• Where can I find the various consents issued by a consumer to perform cross-validation and verification?” [8
Moehrke1]
• Does that override the other consents for specific data, specific purpose?
Internet-based patient-centric preference management answers the first two questions directly. For the third,
specificity is not a logically sufficient criterion, compared for example with a general rule for emergencies or public
health.
The Data Segmentation effort of ONC’s Standards and Interoperability Framework has developed standards for
simple patient preferences, and for compliance with special restrictions on data associated with substance abuse,
mental health, and veterans. HIPAAT http://www.hipaat.com/ and Jericho Systems’ products
http://www.jerichosystems.com/solutions/patientprivacy.html both provide Internet-based repositories for such
preferences, and enforcement at record holders. Neither the standard nor the products supports general, multi-use
consents (e.g., based on known treatment relationships), nor extensibility to other topics. Some state HIEs (e.g.,
Texas) also provide consent capabilities.
3

4. Existing security technologies provide several useful capabilities but do not suffice for consent systems. The basic
security enforcement pattern provides a way to pull access control management and enforcement out of applications,
into the security system. It involves interception by a Policy Enforcement Point (PEP), decision at a Policy Decision
Point (PDP), policy retrieved from a Policy Information Point (PIP) and authored at Policy Administration Point
(PAP). Our system extends the idea, but has multiple instances of each piece, so we do not adopt the vocabulary. We
need the ability to split rule evaluation into multiple stages, initially just substituting attributes from the request and
producing a simplified the ruleset by eliminating rules whose conditions fail for this request’s purpose or
participants. The simplified ruleset may be displayed as part of a “what if” facility, used by a person who enforces
manually, or passed to the next stage of evaluation.
The best known access control language, XACML, is an OASIS standard, and can conveniently encode Boolean
logic; the XPSD profile defines a vocabulary of information to be used in consent policies. However, XACML has
several shortcomings for our purposes. It cannot exploit taxonomies, nor use variables (akin to relational database
join) to test relationships and affiliations, so these must be done by add-on systems. It requires an extra
administration level -- targets to identify relevant rules. The supported actions are just Allow/Deny; other actions are
pushed into an opaque obligation facility, with no conflict management. Academic researchers have proposed to
deconflict based on rule strengths [Jajodia et. al.] and XACML supports that. However, researchers have not
proposed a plausible way to manage strengths in a scenario that is as complex as Consent’s mix of defaults and
mandates from patient tools, governments, and other organizations.
Methods (Technologies for Components)
This section first describes the capabilities of the consent service, and then the capabilities on which it relies:
identity management (Section 2.2), ancillary knowledge sources (Section ), and the rule logic (Section 2.4). Finally,
it describes the overall architecture and workflows, in two configurations. The utility of this approach is shown via
use cases in Section 4.
Consent Service Capabilities
The consent service associates each patient with a set of rules that identify circumstances where health information
can be released. A rule may reference attributes of the request (e.g., requestor, recipient, and purpose), the topics
covered in the item to be released, and additional knowledge (such as affiliations and referrals). Most rules specify
the action “Allow release”, subject to a condition. In our basic language, Allow is the only action, so there is no
need for explicit conflict resolution; instead patients express exceptions by negated terms within Allow condition.
Other rules (possibly expressed in a standard logic programming language) derive ancillary information, such as
ways to derive a relationship Treats(patient, clinician) based on explicit patient assertions plus referrals, on-call
substitution, and affiliations.
Upon a request, the record holder creates an answer to the requestor’s query as a set of candidate items and then
tests consent on each item and releases only those that pass the test; the effect may be, for example, to release a
subset of an XML structure, based ono the topics it contains, and their provenance. Under future work, we discuss
ways to accommodate the awkward likelihood topic detection will never be highly accurate for all data.
Establishing Privacy Preferences
Each patient chooses a consent service provider, and then establishes preferences through a graphical user interface
(UI). In the future, we envision that insurers, HMOs, and others may establish relationships with consent service
providers to make it simpler for patients.
Our prototype’s original UI partitions the patient’s preference-writing as a set of cases, each defined by a purpose
and a set of recipients,, and with predicates specified on metadata attributes. These attributes indicate type of
information (e.g., Allergies) plus presence of sensitive topics (such as mental health). However, a full specification
of an appropriate policy would involve more detail than patients can manage, to handle issues like strength of the
requestor’s authentication, or uncertainty when saying a record does not reveal a sensitive topic.
4

5. We are now exploring a higher level interface, in which experts write detailed rules, while patients merely express
where they want the balance point between protection and sharing. Currently, a slider is used to express each
balance points, both globally and on specific topics such as mental health or pregnancy. The slider values areis then
used to set the thresholds in the expert-written rules. The result is a rule such as:
Allow if purpose = treatment ∧ Identity_certainty ≥ 1 ∧
Topic is not sensitive (with certainty ≥ 2) %just a basic test
∧ Medical Categories breadth ≤ 3 % Can release short summary, not whole record
The patient’s preference may include tests on items’ topics and provenance, but that information may be unavailable
for some data (e.g., pdfs). Today, the patient must negotiate explicitly with each record holder, creating a separate
ruleset (called a directive) that the record holder is confident they can enforce, driven by the low water mark of
record holder’s capabilities. Our approach instead tells the record holder to do their best on each item, returning
Unknown in the worst case and actual topics and provenance in the best. The rule then specifies how to deal with
Unknown attribute values. Our three-valued rule logic (which can return Unknown) allows patients (through their
UIs) to specify rules whose terms that use either forgiving or strict interpretation of Unknown; future extensions
will treat levels of uncertainty.
By storing the patient’s preferences as a set of logical rules, we can support a wide range of UIs. A provider
organization could give its patients a UI that produces rules that execute easily in its EHR; advocacy groups could
develop UIs designed to address their concerns. These UIs can gradually be tailored for the gamut of patients, with
patient-friendly natural language explanations of technical terms, and templates for patients with differing concerns.
In addition, a patient or the government can specify proxies who are authorized to consent to data sharing on behalf
of the patient (e.g., if the patient is uncomfortable with electronic consent management or is a minor). A patient
might even identify a trusted physician as a proxy (assuming the physician is willing), with partial rights to
authorize individual releases or to make permanent changes.
Managing Requests
A request for patient data typically describes the data requested, plus values for purpose, individual and
organization ID for requestor, recipient, record holder, and the patient’s consent ID (Section 2.2). The requestor
and recipient can be individuals, roles, or processes. The automated enforcer has no need special “do not disclose”
constructs or patient policy to the record being sent out; further forwarding simply checks the latest consents. US
law today can require specific verbiage to be inserted into the record for substance abuse data; this text is strictly for
human readers.
When the consent service receives the request, it retrieves the patient’s preferences, and forwards them to the record
holder. Drawing on information in the request message and from other available evidence, it can simplify before
forwarding, to exclude rules that are inapplicable (e.g., Treatment rules are inapplicable to Research requests; PCP
permissions are irrelevant if the recipient is known not to be the patient’s PCP?). Sometimes this process will suffice
to generate a decision (increasingly, as standards and evidence sources improve). The consent service then sends a
decision, or else (simplified) constraints for the record holder to evaluate, in both human friendly form and machine
friendly formalisms (such as XACML or Datalog)..
The record holder needs to enforce the preferences it receives. Some rule terms may be evaluated automatically,
based on data that record holders holds, such as referrals, affiliations, and annotated data in the EHR; other rule
terms may require manual help. We expect record holders to be conservative: if a patient rule includes a term the
record holder is unable or unwilling to evaluate, Unknown is returned. Distributed query optimizing techniques
might help optimize the efficiency of human reviewers, by employing cheap-to-access data first, and manually-
supplied data last, and focusing the human on only those terms that could not be evaluated automatically.
Finally, the consent service maintains an audit log of all activity. This audit log indicates: all information in the
request message; any additional factors that influence the decision-making process (e.g., the patient told the consent
system that Dr. Jones is her PCP); endorsement of this request from the patient or proxies, and the constraints sent to
the record holder.
The patient can interact with the audit subsystem to see the history of requests, or to define alerts that notify him of
requests that meet specific criteria (e.g., a request to access the results of an HIV test). The consent service offloads
5

6. this IT burden from the record holder, who may need to cope with patient questions. As with any security system, it
will be important to avoid trivial alerts.
To manage consent on a large scale, additional capabilities are needed, to make the system trustworthy, and to
obtain ancillary information that belongs in external sources, not in EHRs. These are addressed in the next two
subsections.
Patient Identity and the Consent Systems
This section addresses the consent system’s need to ensure that a patient’s records are released based on their own
consents, rather than an inadvertent mismatch or malicious spoofer. The first step, as in eCommerce, is for the
patient to open a consent account and obtain a consent account ID, hereafter called a “consent ID.” Then, to securely
tie this account to a record holder’s records, the patient must authenticate with the record holder (in person or by
securely logging into the record holder’s system). The patient then provides a consent identifier (if present in person,
possibly via a smart card), which the record holder binds to its master identifier for that patient, rather than requiring
links to individual records. Once this is established, the record holder knows that the preferences sent by the consent
service correspond to this patient. (We examined other approaches to attaching a consent identity, but the ones
without user login seemed insecure – a malicious referral could attach the wrong ID to the recipient’s master patient
record. One could attach the consent ID to the data sent, but then must carry it along as that data is shredded and
inserted into databases.)
The consent service will give a patient voluntary digital IDs on demand; the patient decides which ID to give each
provider. A privacy purist patient might give a distinct identifier to each record holder; another person might give
the same identity to most providers (for its error-reducing benefits) but give distinct identifiers at a substance abuse
clinic and a reproductive health center. Extra IDs make it possible to attach Consent IDs without creating an
unwanted global identifier [Roop, Mark3]. (US laws currently prohibit government funding of creation of such
identifiers, even when voluntary.)
When a record holder receives a request, they are responsible for identifying the appropriate patient. If a requestor
attaches the consentID he uses for the desired patient, it can be part of the identity-matching process, to reduce
errors.
Ancillary Knowledge Sources
The consent service may rely on “ancillary” evidence not in the candidate release or the request message. Examples
include the identity of a patient’s PCP, the PCP’s referrals, and clinician attributes (specialty, and hospital
affiliations). While originating at many provider and state sources, they might be made available 7x24 through a
single interface via an HIE or data aggregator. For example, Health Management Sciences aggregates certification
and affiliation data for multiple clinical professions. Frequent refresh may be required.
Having retrieved whatever ancillary knowledge it can, the consent service matches that information against the
patient’s preferences, allowing the consent service to further simplify the constraints it forwards to the record holder.
The residue is sent to the record holder, whose may possess additional ancillary knowledge (e.g., referrals, staff
assignments), and otherwise needs to gather the information from nonautomated sources.
The consent service and the record holder need to determine if they trust the source of the ancillary information.
Creation of such a trust structure (certifications, trust relationships) is an open problem.
Rules and their logic
The patient preference consists of rules submitted through the patient’s consent specification user interface. We
anticipate that wizards and defaults will do much of the work, being customized by the patient’s expressed level of
privacy concern and topics of particular sensitivity. Our prototype evaluates only the patient preferences. We are
exploring ways to include Allow and Deny rules, especially from organizational and government preferences, to
produce an integrated ruleset.
6

7. Request Response
R: Record Holder System C: Consent Service
Request Interface Consent Interface Trust
Service
EHR (with Consent
consent IDs) Database Ancillary
Knowledge
Sources
XACML Policy
Engine Reasoner
Rules determine their own scope of applicability, by including explicit predicates on metadata available from the
request, the health record, or ancillary sources. Each rule has a condition; if that evaluates to false, the rule is
ignored. If true, then the rule is applicable and a result is created (either an Allow decision or a table that feeds into
later rules; Deny rules will be added soon). Since applicability is handled within each rule, there is no need to
construct and maintain functions to find rules to apply, nor for health records to link to rules.
Rules are currently expressed in a variant of Datalog without recursion. Datalog can express join expressions, such
as determining whether a clinician has a known affiliation with an organization known to be treating the patient;
such conditions cannot be expressed in XACML. We extend Datalog to distinguish “not known” from “not true”;
this enables us to distinguish “has no mental health data” from “as far as we can tell, has no mental health data”,
both in record holder assertions and patient predicates. Future UI extensions will let the patient extend rule conjuncts
to deal with Unknown, and more generally, to support confidence thresholds. We are also investigating semantic
web rule languages that offer easy integration with taxonomies and ontologies, and are W3C standards.
The consent service’s reasoner simplifies the ruleset, based on whatever information is available to it. That is, it
substitutes values from the request message, from ancillary sources, or from the health record, and then does logical
simplifications. Because simplify (rather than evaluate) is our primitive, we can leave a residue for automated
processing at the record holder, or manual processing (as is done today), and can perform “what if” investigations
(e.g., what constraints must be satisfied before a record is released if that record contains mental health information).
Sample Architecture
Figure 1: Configuration C for giving record holder an enforceable consent. The record holder (R) forwards the request
to the consent service (C), which uses a policy reasoner to determine the residual policy to be enforced on the health
record. Our prototype translates the residual policy to XACML and places an efficient XACML engine at the record
holder to make access decisions. The capabilities described above can be combined in multiple ways to instantiate a
consent management system. In this section, we present a high-level architecture and data flow (Figure 1). We then
discuss three sample configurations for implementing it, the first manual and the second idealized, with all requests,
consents, and EHR data employing compatible standards, and automated rule evaluation.
As shown in Figure 1, there is a consent service (C) that maintains the patient’s privacy preferences and related audit
logs in a consent database. Patients create and modify these privacy preferences via a consent specification GUI. To
avoid liability risk and reduce storage, C receives no EHR data. The record holder sends C the consent identity
registered for the patient, finds the proper consent account (resolving aliases), and connects with external sources to
7

8. obtain ancillary knowledge. This is the architecture we prototyped, as a natural extension to today’s practice. It
distributes conventional functionality into several components. One Policy Enforcement Point (PEP) intercepts the
request and sends it to our policy reasoner (acting as a partial Policy Decision Point -- PEP), which in some cases
may provide an answer for the entire request. If not, the reasoner produces a simplified policy (also called residual
policy), as the response is constructed. The relevant policy will (eventually) be constructed at run time as the PIP
mixes patient, organizational, and government rules into a single ruleset.
The processing begins before a request is sent.
• The patient selects a consent service provider, creates an account, and records their preferences as a set of rules.
• The patient gives each record holder a consent account identifier (rather than a set of consent forms), which the
record holder attaches to their master patient index.
Then, for each request to disclose patient data
• An add-on to the recipient EHR (a PEP) intercepts the request. After matching the request to the proper patient
at the record holder, it looks up the consent ID, and sends an evaluation request to the consent service.. (A
registry that indicates the correct consent service for each patient would enable patients to switch consent
services easily).
• The consent service retrieves the patient’s preferences and sends this ruleset to the reasoner. (In the future, the
ruleset will be augmented by mixing in with government and organizational preferences). Relevant ancillary
data from outside the patient record are also retrieved, if available, e.g., provider credentials, affiliations, and
treatment relationships.
• The reasoner substitutes this data into the ruleset, and performs Boolean simplifications, yielding a residual
ruleset. If the ruleset simplified to an Allow or Deny decision, the decision is returned to the record holder. (The
decision is Deny if the reasoner determines that no rule applies).
• Otherwise, the residual rules need to be evaluated at the record holder for each health record item. Items within
the patient record must be annotated (as discussed below) to tell whether they contain topics or sources that are
to be restricted.
• In all cases, each decision yields a record for the audit trail. Other obligations could also be attached.
To enable the tests, software must annotate items (on demand from rules, or in advance in the EHR) for a variety of
topics and provenance categories, as either Present, Absent, or Unknown. Annotation techniques rely on
extensive terminological and clinical knowledge and are outside our scope; as a callable service. Several such
services have been built; for example, one is included in the SAMHSA/VA demonstration at HL7 in September
2012. Secondary users may also find the annotations useful, whether to retrieve on clinical topics or to examine
patient and information flow among institutions. Annotations will be provided for legally mandated categories and a
few more; it is infeasible to annotate for every topic that a patient may someday consider sensitive.
We have identified several ways to configure the above capabilities.
Configuration A (manual): Consider a record holder R who relies on paper records and receives requests by fax or
email. A medical records specialist would enter information about the recipient and request into a web form hosted
by the consent service, and receive a human-readable version of the patient’s preferences. She interprets the
conditions for each item proposed for release. If the evaluation needs ancillary data, she obtains it by accessing
websites or by telephone.
This degree of manual processing is incompatible with extensive exchange. Still, it seems worth demonstrating that
technology-poor environments will not find their work harder. For example, a provider might initially seek only the
simplest benefits, such as distributed editing and retrieval of the latest patient and government preferences. Patients
also get the benefit of simpler and more patient-centric consents, as opposed to the current system in which they
must sign provider-centric consents at each new provider location Processing of actual records remains manual.
Configuration B (fully automated, reasoner at record holder): Here R receives and automatically processes
formatted messages from requestors in their own health provider network. Requests are queries in standards known
8

9. to their EHR, and requestors are known. In this idealized case, either the scope is small (such as just an HL7 C32
message), or else all health records in their institution can be accessed via a single EHR interface. The patient’s
preferences are stored in one Internet-accessible place.
Configuration C (fully automated, distributed): The previous configuration is elaborated to have two reasoners, one
co-located with the Consent database (hosted once, and able to see rule terms that are too sensitive to send to some
record holders), and one located at the record holder to deal with the residual (and able to see sensitive referral
information that the record holder might not disclose to a remote reasoner). Our prototype implements this
configuration. To show use of existing standards, the record holder’s reasoner is implemented by translating first to
XACML, and then evaluating.
Results (Examination of Use Cases)
To illustrate how a consent management system provides our claimed benefits, we consider six use cases. For
generality, the descriptions allow a range of automation in terms of both the record holder’s capabilities and the
collection of ancillary knowledge.
1) A patient establishes his privacy preferences for the first time.
The patient connects to the consent service using a browser or smartphone app (e.g., at home, at the library, on a
mobile phone, or in a kiosk in the waiting room). Because the patient does not have an existing consent account, he
is given a new consent identifier. Next, he is walked through a series of wizards to establish his initial privacy
preferences. We envision wizards tailored to several common situations, for example, treatment by the PCP,
emergency treatment, and specifying with whom the patient has a treatment relationship. Extending the suggestions
from the IHE report discussed earlier [9], we hope that organizations will establish reasonable prepackaged options
for the patient to select from. The system can also express the current style of narrow consents—a rule can include
conjuncts that restrict its applicability to one record holder, one requestor, or one request although we would
discourage such usages.
Our examples below assume that the patient says “anyone referred by my PCP has a treatment relationship”, and
permits release of all information to their PCP, and all except mental health to any provider with whom they have a
treatment relationship. We also assume that some providers make it known that they normally process queries
against a store that excludes all data subject to special legal protections (e.g., originating at a federally funded
substance abuse center).
2) A specialist (Dr. Lee) was unable to obtain the patient’s health information. Via the consent system, she asks
the patient to “fix this”, to modify his existing preferences to allow her the necessary access. The patient is
willing, and does so.
The policy reasoner determines one or more plausible modifications to the patient’s current preferences, and the
consent service contacts the patient for selection and approval. For example, a future UI might determine that the
patient be shown three choices a) to declare a treatment relation with this specialist; b) to approve this single release,
or c) to create a new rule for Dr. Lee or for all specialists. Note that Dr. Lee did need not see the existing
preferences. Once the update is saved, it will apply to all subsequent requests.
3) After the change, and on subsequent visits, Dr. Lee asks for recent records about the patient.
a. Suppose the patient’s consent releases all health information to treating physicians.
b. Suppose the patient’s consent excludes data that is known to relate to mental health.
For case 3a, the consent system receives the request, determines that Lee is an MD, and has a treatment relationship
with the patient. It authorizes release and writes the request and the ancillary knowledge employed to the audit log.
With less automation, the record holder might know that Lee is a doctor, and obtain the remaining ancillary
information manually.
Now the consented request is processed. For the advanced record holder, the request is sent to their EHR and the
results assembled. In configuration A, a medical records person receives the request, manually forwards a message
to the consent system, and receives the preferences she is to enforce. She then formulates requests to the various
systems at her site (possibly including paper) and assembles a response. In either case, the result is then securely
transmitted to the recipient.
For case 3b, the consent system tells the record holder “release is approved except for information that the record
holder knows relate to mental health.” For each item to be released, the rule retrieves the record holder’s annotation.
9

10. (If mental health information is kept in a segregated data store, then items from all other stores is virtually annotated
as Absent). Any data, annotated as mental health Present will be redacted from the response, but data annotated
Absent or Unknown would be released. (A more restrictive patient might write a rule that also excludes
Unknown.)
4) The PCP refers the patient (who is not physically present) to a new provider, Dr. Jones. The record holder
seeks to send information to Dr. Jones before the patient’s visit. All providers are now authorized to send non-
mental health information to Dr. Jones.
The consent system first knowledge from a data aggregator or HMO (if that HMO is the record holder) to verify that
Ms. Jones is a healthcare provider and that the patient’s PCP has referred the patient to her. According to the
patient’s ruleset, referral creates a Treatment relationship. As in case 3a, once this information has been retrieved
(from a source the record holder trusts), the consent system simplifies to prune the ruleset. The remaining rules are
shown to the record holder. The record holder is then responsible for enforcing the remaining constraints. Note that
no further consents were required.
5) A provider with no documented treatment relationship requests the patient’s medication and allergy data, on an
emergency basis.
A nurse in Utah declares a medical emergency to override normal protections and enable her to retrieve a patient’s
medications and allergies from a California record holder. The notional California policy includes conditions for
trusting the claim that this is for a medical emergency, and then allows all Normally-sensitive information to be
released, but requires explicit auditing and that the patient be informed. Here, the notional condition is that the
requestor’s claim to be a doctor has been verified OR the request came from a known Emergency Department and a
check of the requestor’s claim to be a doctor or Nurse returned True or Unknown. (The second condition applies if
California’s software is unable to locate or access Utah credentials registries)
Emergency policies are rules, like any other. In the future, we will allow a motivated patient to impose limitations
that involve minimal medical risk, such as to limit the access for particular individuals or organizations (e.g., an
institution where an ex-spouse works).
6) A researcher wants to screen kidney patients to find ones suitable for a new clinical trial. Many patients have
consented to have their data screened by accredited researchers.
Many patients have stipulated (via a UI option) that they are willing to let their information be employed to match
them to clinical studies; some have even offered to share deidentified data without being contacted. To recruit, the
researcher first asks the consent service to search across all patients to find those who have consented to recruitment
for kidney research; this will include patients who consented to research in general. Second, the EHR performs
eligibility screening based on demographics, dates, diagnoses, and treating clinicians. The eligible candidates may
then be sent invitations to contact the researcher. For the most willing patients, the EHR may be sent a consented
request to send deidentified data directly to the researcher.
Today’s paper-based system offers no effective way for researchers and suitable willing subjects to find each other,
nationwide. Full automation is needed, because record holders have limited desire to process such requests,
especially from outside their institution. The search process need not reach every suitable patient—a small fraction
from a nationwide population may suffice (e.g., type 2 diabetes patients under age 60, taking certain drugs).
Statistical studies do not require the patient’s physical presence; once consent is established, they can be fully
automated and thus much cheaper. An alternative approach is to send queries to the sources
http://wiki.siframework.org/file/view/Distributed+Queries+-+Platt%2C+Elmore%2C+Brown+-+IOM+Digital+Data+Priorities+-
+2012-03-23.pptx. This approach it makes two problematic assumptions, that the local result can be insensitive
enough to export without consent, and that providers will be willing to accept queries coming from outside.
Discussion (Conclusions and Future Work)
We have described a path toward patient-centric consent management. Patients, record holders, and requestors all
benefit, and thus have incentives to participate. A key idea is that all of a patient’s rules (augmented by government
rules, as needed) are stored in one place, accessible to the patient (for updates) and to record holders (for evaluation
requests). Rule terms that reference data from the request or ancillary evidence are evaluated and the ruleset
simplified, so the record holder sees only what is relevant. Metadata is attached to the transmitted record, describing
the data’s topics and provenance, but not the applicable policies (which may change). This metadata can be used for
privacy and also for other applications (e.g., discovery, budget analysis by topic). Throughout, we employ
10

11. generalized capabilities (e.g., rule engines, reusable consents) to minimize complexity, for both software
implementers and patients.
Patients get a single location for expressing their consent preferences, so they do not need to separately notify every
record holder. They gain flexible user interfaces that go beyond provider legalese or HIPAA forms, making it easier
to review and modify their preferences. The UIs are available over the web anytime, anyplace there is Internet
access, not just at the provider’s check-in desk. Relevant federal or state regulations could be visible from the same
interface, allowing patients to see how their preferences interact with legal constraints. UIs can incorporate record
holder idioms, and vendors can compete for patient adoption. As a result of all this, patients get better care because
their providers can better share information.
Record holders will get a reduced consent-enforcement burden, as compared with manually processing requests with
the same patient preferences. They are freed from maintaining a stack of consent documents and can apply the
patient’s generalized preferences without contacting the patient again. They need not pass policies or obligations to
recipients – instead, the recipient can get the latest over the Internet, in machine processable form, not a fax. Logical
simplifications based on elements of the request remove rules and terms irrelevant to the current request.
Requestors benefit because they can seek information from multiple record holders without pair-wise consent
negotiation. By reusing existing generalized consents, they can get the data they need, without waiting for the
patient to sign a new document. The potential benefits are especially big for researchers and other secondary users of
EHRs. The consent system can even give requestors a preview of what it will send the record holder (if that preview
does not contain sensitive information), thus reducing unexpected rejections. Data may also be pushed rather than
pulled, or even be initiated by an untrusted third party. For example, a secretary could phone the home provider and
ask for additional information to be forwarded to a specialist with whom a treatment relationship already exists.
While recipient’s privileges dominate, policy can also give weight to assertions by a trusted requestor or record
holder.
Further research
Additional research is needed to establish a range of user interfaces and pre-written policies, based on a variety of
factors including device (such as paper, desktop computer, or smart phone), level of privacy concern, and degree of
computer sophistication. Patients also need help in understanding terminology (e.g., “mental health”) and to reason
about the impact of their preferences.
Rule languages and UIs need expansion to deal with uncertainty about assertions, e.g., for “doubtful” emergency
requests, or where a topic annotation comes back Unknown. It is unclear how best to mix declarative rule languages
(for inferring properties) with procedural and prioritized rule languages, for dealing with three valued logic, and
with conflicting actions (both Allow/Deny and actions in obligations).
The framework outlined above supports patient specification of privacy preferences. It must be expanded to mix in
rules from organizations plus federal and state governments. The challenge is to support multiple modes: weak
defaults that ordinary patient consent overrides (e.g., HIPAA’s “Deny unless for treatment, payment, or operations
(TPO)”); state requirements (some states say explicit consent is needed even for TPO), emergencies (which might
override topic restrictions), blacklists (e.g., to override emergency requests from an ex-spouse as recipient), and
unconditional mandates (“Release tuberculosis diagnoses to Public Health departments”). We are now designing
such a capability.
Derived information also needs protections. These would cover existence of data (from discovery services, e.g.,
“does ABC Rehab have data on this patient?), notices that data has been redacted, and consent policies themselves
(e.g., “Allow release of my ABC Rehab information to Dr. Freud”). Also, we are exploring how to enforce rules that
cannot be fully revealed to all record holders.
Government and provider policy initiatives can speed progress. Consent services should be certified, and then
providers might be allowed to rely on them, without fear of liability. Government should make its policies available
as machine readable rulesets, which are deemed authoritative. Policy should be developed about what directory
services may reveal. We also need to enable interoperability to allow patients to switch consent service vendors, and
to enable competition and innovation in individual components, such as UIs. Also, a technical facility cannot resolve
issues of data ownership and whether there is an affirmative obligation to share.
Finally, and perhaps most important, one could build a useful consent system today, whose main function was just
to place consents (in machine and human readable form) on record holders’ screens (e.g., for a physical therapist
practicing alone, with minimal software), and to automate the simplest cases (which are pleasantly common). Our
architecture consciously avoided depending on universal participation, employment of data standards, record holder
11

12. automation, or ancillary data completeness. Progress in these areas would permit greater automation, but in the near
term, all tasks can be processed partly manually, with incremental automation.
The system need not be perfect, just good enough to lure participation. Its architecture should be extremely flexible
and extensible, to accommodate changing laws, and stronger desires for patient privacy
Acknowledgements and Conflicts: This work was funded by MITRE’s internal Innovation Program. The software
has been released as open source, and MITRE does not sell either the software (which has been open sourced) or
support. We have no personal financial interests.
References
[1 Gold1] Goldstein, M.M., and Rein, A.L. Consumer Consent Options for Electronic Health Information Exchange:
Policy Considerations and Analysis. [93 pp.]
http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_11673_950145_0_0_18/gwu-data-segmentation-
final.pdf Archived at http://www.webcitation.org/674s808vs
[2 Mark1] Markle Foundation. Americans Overwhelmingly Believe Electronic Personal Health Records Could
Improve Their Health. [Internet] [2008 June 1] http://www.connectingforhealth.org/resources/ResearchBrief-
200806.pdf. Archived at http://www.webcitation.org/674ThDPA0 .
[3 Blum1] Blumenthal, D. Stimulating the Adoption of Health Information Technology. N Engl J Med. 2009: (360):
1477-1479. PMID: 19321856
[4 Mark2] Markle Foundation. Connecting for Health Common Framework, Policy Notice to Consumers Appendix
A. [Internet] [2008 June http://www.markle.org/health/markle-common-framework/connecting-consumers/cp2,
archived at http://www.webcitation.org/674ThDPAQ.
[5 MARK3] Markle Foundation “Linking Health Care Information: Proposed Methods for Improving Care and
Protecting Privacy”, Working Group on Accurately Linking Information for Health Care Quality and Safety,
February 2005. http://www.markle.org/publications/863-linking-health-care-information-proposed-methods-
improving-care-and-protecting-priv, archived at http://www.webcitation.org/674s808w6
[6 HITSP1] HITSP/ISO3. HITSP Consumer Empowerment and Access to Clinical Information via Networks
Interoperability Specification, Version 4.0. [2008 December 18] [cited 2011 April 4] [122 pp.]
http://www.hitsp.org/Handlers/HitspFileServer.aspx?FileGuid=195bf7df-b290-49e4-b47d-29834d32f317 archived at
http://www.webcitation.org/674vaPj5r
[7 ONC1] Consumer Preferences Draft Requirements Document. [2009 October 5] [cited 2011 April 4] [42pp.]
Sponsored by U.S. Department of Health and Human Services Office of the National Coordinator for Health
Information Technology.
http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10779_891071_0_0_18/20091005_Consumer
%20Preferences_Draft_Requirements_Document.pdf archived at http://www.webcitation.org/674wEY0uo
[8 Moehrke1] Moehrke, J. Consumer Privacy using HITSP TP30. [2010 October 20]
http://healthcaresecprivacy.blogspot.com/2010/10/consent-management-using-hitsp-tp30.html archived at
http://www.webcitation.org/674ss2lsZ
[9 IHE1] Integrating the Healthcare Environment (IHE). Basic Patient Privacy Consents. [Internet] [cited 2011 April
4] [about 6 pp.] http://wiki.ihe.net/index.php?title=Basic_Patient_Privacy_Consents. Archived at
http://www.webcitation.org/674ThDPAZ
[10 GSK1] N. Genes, J. Shapiro, G. Kuperman “Health Information Exchange Consent Policy Influences
Emergency Department Patient Data Accessibility”, Proceedings of AMIA Symposium, 2010
[11 HIPAA1] Public Law: Health Insurance Portability and Accountability Act of 1996 (HIPAA), Pub. L. 104-191
(August 21, 1996).
[12 Priv1] Public Law: Privacy Act of 1974, Pub. L. 93-579 (December 31, 1974).
[13 ONC2] ONC Privacy and Security Tiger Team. Consumer Choice Technology Hearing, June 29, 2010. [cited
2011 April 6], Available from:
http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_11673_945904_0_0_18/Consumer-Choice-Technology-
Hearing-062910.txt archived at http://www.webcitation.org/674v3zqAb
[14 Inter1] Michael LaRocca, Intersystems Corporation Written Public Testimony, Consumer Choice Technology
Hearing, June 29, 2010, p. 3
12

13. http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_11673_945904_0_0_18/Consumer-Choice-Technology-Hearing-
062910.txt archived at http://www.webcitation.org/674v3zqAb
[15 Hal1] Halamka, J. Solving Secure Transport.: http://geekdoctor.blogspot.com/2010/01/solving-secure-
transport.html, archived at http://www.webcitation.org/674ThDPAi
[16 PCAST1] President’s Council of Advisors on Science And Technology, “Report to the president: Realizing the
full potential of health information technology to improve healthcare for Americans: The path forward.”, December
2010, p. 46 http://www.scribd.com/doc/44944668/Report-to-the-President-Realizing-the-Full-Potential-of-Health-
Information-Technology-to-Improve-Healthcare-for-Americans-The-Path-Forward
Archived at http://www.webcitation.org/674uBy6rQ
13

14. This was a software effort. There were no human or animal experiments requiring formal trial approval.
There are no conflicts of interest.
The work has not been published; an earlier version is posted on our project pages on the Internet..
14