SlideShare a Scribd company logo
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
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
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
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
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
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
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
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
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
(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
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
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
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
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

More Related Content

What's hot

Hit 120 full course latest 2016 december [ all discussion , quizes, course pr...
Hit 120 full course latest 2016 december [ all discussion , quizes, course pr...Hit 120 full course latest 2016 december [ all discussion , quizes, course pr...
Hit 120 full course latest 2016 december [ all discussion , quizes, course pr...
lenasour
 
Confidentiality & privacy
Confidentiality & privacyConfidentiality & privacy
Confidentiality & privacy
kendale
 
Introduction to EMR
Introduction to EMRIntroduction to EMR
Introduction to EMR
Hal Amens
 
Data Reuse Agreements
Data Reuse AgreementsData Reuse Agreements
Data Reuse Agreements
Jeff McCloud
 
Patient Privacy Protections
Patient Privacy ProtectionsPatient Privacy Protections
Patient Privacy Protections
kwittman
 
HIE 101
HIE 101HIE 101
Here’s How Blockchain Can Revolutionize Telemedicine
Here’s How Blockchain Can Revolutionize TelemedicineHere’s How Blockchain Can Revolutionize Telemedicine
Here’s How Blockchain Can Revolutionize Telemedicine
Matthew Doyle
 
Big Data in Healthcare -- What Does it Mean?
Big Data in Healthcare -- What Does it Mean?Big Data in Healthcare -- What Does it Mean?
Big Data in Healthcare -- What Does it Mean?
M2SYS Technology
 
Electronic Medical Record Implementation Roundtable White Paper
Electronic Medical Record Implementation Roundtable White PaperElectronic Medical Record Implementation Roundtable White Paper
Electronic Medical Record Implementation Roundtable White Paper
DATAMARK
 
Personal Health Records - An Overview
Personal Health Records - An OverviewPersonal Health Records - An Overview
Personal Health Records - An Overview
rcostantini
 
Building blockchain based Healthcare infrastructure with beyond block labs
Building blockchain based Healthcare infrastructure with beyond block labsBuilding blockchain based Healthcare infrastructure with beyond block labs
Building blockchain based Healthcare infrastructure with beyond block labs
Beyond Block Labs
 
Speech Understanding Dictation To Clinical Data - TEPR 2009
Speech Understanding   Dictation To Clinical Data - TEPR 2009Speech Understanding   Dictation To Clinical Data - TEPR 2009
Speech Understanding Dictation To Clinical Data - TEPR 2009
Nick van Terheyden
 
U.S. Medical Grid
U.S. Medical GridU.S. Medical Grid
U.S. Medical Grid
Larry Suarez
 
Value-Based Care and Healthcare Consumerism: Opportunities for Health IT and ...
Value-Based Care and Healthcare Consumerism: Opportunities for Health IT and ...Value-Based Care and Healthcare Consumerism: Opportunities for Health IT and ...
Value-Based Care and Healthcare Consumerism: Opportunities for Health IT and ...
Cognizant
 
Cuban American Medical Society Presentation[1]
 Cuban American Medical Society Presentation[1] Cuban American Medical Society Presentation[1]
Cuban American Medical Society Presentation[1]
William Kirsh, DO, MPH
 
Healthcare Interoperability and Standards
Healthcare Interoperability and StandardsHealthcare Interoperability and Standards
Healthcare Interoperability and Standards
Arjei Balandra
 
Data driven Healthcare for Providers
Data driven Healthcare for ProvidersData driven Healthcare for Providers
Data driven Healthcare for Providers
Amit Mishra
 
Kantara uma webinar july 2020
Kantara uma webinar   july 2020Kantara uma webinar   july 2020
Kantara uma webinar july 2020
kantarainitiative
 
WK11HIT
WK11HITWK11HIT

What's hot (19)

Hit 120 full course latest 2016 december [ all discussion , quizes, course pr...
Hit 120 full course latest 2016 december [ all discussion , quizes, course pr...Hit 120 full course latest 2016 december [ all discussion , quizes, course pr...
Hit 120 full course latest 2016 december [ all discussion , quizes, course pr...
 
Confidentiality & privacy
Confidentiality & privacyConfidentiality & privacy
Confidentiality & privacy
 
Introduction to EMR
Introduction to EMRIntroduction to EMR
Introduction to EMR
 
Data Reuse Agreements
Data Reuse AgreementsData Reuse Agreements
Data Reuse Agreements
 
Patient Privacy Protections
Patient Privacy ProtectionsPatient Privacy Protections
Patient Privacy Protections
 
HIE 101
HIE 101HIE 101
HIE 101
 
Here’s How Blockchain Can Revolutionize Telemedicine
Here’s How Blockchain Can Revolutionize TelemedicineHere’s How Blockchain Can Revolutionize Telemedicine
Here’s How Blockchain Can Revolutionize Telemedicine
 
Big Data in Healthcare -- What Does it Mean?
Big Data in Healthcare -- What Does it Mean?Big Data in Healthcare -- What Does it Mean?
Big Data in Healthcare -- What Does it Mean?
 
Electronic Medical Record Implementation Roundtable White Paper
Electronic Medical Record Implementation Roundtable White PaperElectronic Medical Record Implementation Roundtable White Paper
Electronic Medical Record Implementation Roundtable White Paper
 
Personal Health Records - An Overview
Personal Health Records - An OverviewPersonal Health Records - An Overview
Personal Health Records - An Overview
 
Building blockchain based Healthcare infrastructure with beyond block labs
Building blockchain based Healthcare infrastructure with beyond block labsBuilding blockchain based Healthcare infrastructure with beyond block labs
Building blockchain based Healthcare infrastructure with beyond block labs
 
Speech Understanding Dictation To Clinical Data - TEPR 2009
Speech Understanding   Dictation To Clinical Data - TEPR 2009Speech Understanding   Dictation To Clinical Data - TEPR 2009
Speech Understanding Dictation To Clinical Data - TEPR 2009
 
U.S. Medical Grid
U.S. Medical GridU.S. Medical Grid
U.S. Medical Grid
 
Value-Based Care and Healthcare Consumerism: Opportunities for Health IT and ...
Value-Based Care and Healthcare Consumerism: Opportunities for Health IT and ...Value-Based Care and Healthcare Consumerism: Opportunities for Health IT and ...
Value-Based Care and Healthcare Consumerism: Opportunities for Health IT and ...
 
Cuban American Medical Society Presentation[1]
 Cuban American Medical Society Presentation[1] Cuban American Medical Society Presentation[1]
Cuban American Medical Society Presentation[1]
 
Healthcare Interoperability and Standards
Healthcare Interoperability and StandardsHealthcare Interoperability and Standards
Healthcare Interoperability and Standards
 
Data driven Healthcare for Providers
Data driven Healthcare for ProvidersData driven Healthcare for Providers
Data driven Healthcare for Providers
 
Kantara uma webinar july 2020
Kantara uma webinar   july 2020Kantara uma webinar   july 2020
Kantara uma webinar july 2020
 
WK11HIT
WK11HITWK11HIT
WK11HIT
 

Viewers also liked

Nationwide patient centric consent mgmt - v3 approved for public release old
Nationwide patient centric consent mgmt - v3  approved for public release oldNationwide patient centric consent mgmt - v3  approved for public release old
Nationwide patient centric consent mgmt - v3 approved for public release old
Jeff McCloud
 
11 0953 kairon - slide deck for source forge final 2 11
11 0953 kairon - slide deck for source forge  final 2 1111 0953 kairon - slide deck for source forge  final 2 11
11 0953 kairon - slide deck for source forge final 2 11
Jeff McCloud
 
Data Reuse Agreements
Data Reuse Agreements Data Reuse Agreements
Data Reuse Agreements
Jeff McCloud
 
Research issues -usenix-v4 1 final approved for public release 5 11
Research issues -usenix-v4 1 final approved for public release 5 11Research issues -usenix-v4 1 final approved for public release 5 11
Research issues -usenix-v4 1 final approved for public release 5 11
Jeff McCloud
 
Enforceable Specification of Privacy
Enforceable Specification of PrivacyEnforceable Specification of Privacy
Enforceable Specification of Privacy
Jeff McCloud
 
Himss13 patient consent v3 final
Himss13 patient consent v3 finalHimss13 patient consent v3 final
Himss13 patient consent v3 final
Jeff McCloud
 

Viewers also liked (6)

Nationwide patient centric consent mgmt - v3 approved for public release old
Nationwide patient centric consent mgmt - v3  approved for public release oldNationwide patient centric consent mgmt - v3  approved for public release old
Nationwide patient centric consent mgmt - v3 approved for public release old
 
11 0953 kairon - slide deck for source forge final 2 11
11 0953 kairon - slide deck for source forge  final 2 1111 0953 kairon - slide deck for source forge  final 2 11
11 0953 kairon - slide deck for source forge final 2 11
 
Data Reuse Agreements
Data Reuse Agreements Data Reuse Agreements
Data Reuse Agreements
 
Research issues -usenix-v4 1 final approved for public release 5 11
Research issues -usenix-v4 1 final approved for public release 5 11Research issues -usenix-v4 1 final approved for public release 5 11
Research issues -usenix-v4 1 final approved for public release 5 11
 
Enforceable Specification of Privacy
Enforceable Specification of PrivacyEnforceable Specification of Privacy
Enforceable Specification of Privacy
 
Himss13 patient consent v3 final
Himss13 patient consent v3 finalHimss13 patient consent v3 final
Himss13 patient consent v3 final
 

Similar to Kairon overview

What explains why certain services were covered and others were not .docx
 What explains why certain services were covered and others were not .docx What explains why certain services were covered and others were not .docx
What explains why certain services were covered and others were not .docx
ajoy21
 
A Case Study for Blockchain in Healthcare MedR.docx
A Case Study for Blockchain in Healthcare MedR.docxA Case Study for Blockchain in Healthcare MedR.docx
A Case Study for Blockchain in Healthcare MedR.docx
ransayo
 
Discussion for Week 4SubscribeTopic  Explain the data i.docx
Discussion for Week 4SubscribeTopic  Explain the data i.docxDiscussion for Week 4SubscribeTopic  Explain the data i.docx
Discussion for Week 4SubscribeTopic  Explain the data i.docx
madlynplamondon
 
Computer based record
Computer based recordComputer based record
Computer based record
Mahmoud Shaqria
 
Catalyzing coordinationtechnologyswholepersoncare
Catalyzing coordinationtechnologyswholepersoncareCatalyzing coordinationtechnologyswholepersoncare
Catalyzing coordinationtechnologyswholepersoncare
~Eric Principe
 
Confidentiality & privacy
Confidentiality & privacyConfidentiality & privacy
Confidentiality & privacy
kendale
 
21st Century Act and its Impact on Healthcare IT
21st Century Act and its Impact on Healthcare IT21st Century Act and its Impact on Healthcare IT
21st Century Act and its Impact on Healthcare IT
CitiusTech
 
Running Head EVALUATION PLAN FOCUSEVALUATION PLAN FOCUS 1.docx
Running Head EVALUATION PLAN FOCUSEVALUATION PLAN FOCUS 1.docxRunning Head EVALUATION PLAN FOCUSEVALUATION PLAN FOCUS 1.docx
Running Head EVALUATION PLAN FOCUSEVALUATION PLAN FOCUS 1.docx
cowinhelen
 
Electronic Health Records Implementation Roundtable
Electronic Health Records Implementation RoundtableElectronic Health Records Implementation Roundtable
Electronic Health Records Implementation Roundtable
DATAMARK
 
The Electronic Health Record
The Electronic Health RecordThe Electronic Health Record
The Electronic Health Record
Christy Hunt
 
Part ONE-1 page AMA format-due 917 by 1000 pm EST Evaluate m.docx
Part ONE-1 page AMA format-due 917 by 1000 pm EST Evaluate m.docxPart ONE-1 page AMA format-due 917 by 1000 pm EST Evaluate m.docx
Part ONE-1 page AMA format-due 917 by 1000 pm EST Evaluate m.docx
danhaley45372
 
Running Head SHARING CLINICAL DATASHARING CLINICAL DATA.docx
Running Head SHARING CLINICAL DATASHARING CLINICAL DATA.docxRunning Head SHARING CLINICAL DATASHARING CLINICAL DATA.docx
Running Head SHARING CLINICAL DATASHARING CLINICAL DATA.docx
todd521
 
Stark Exceptions 20080325
Stark Exceptions 20080325Stark Exceptions 20080325
Stark Exceptions 20080325
Andy Spooner
 
FACULTY OF HIGHER EDUCATION Individual.docx
FACULTY OF HIGHER EDUCATION         Individual.docxFACULTY OF HIGHER EDUCATION         Individual.docx
FACULTY OF HIGHER EDUCATION Individual.docx
mecklenburgstrelitzh
 
76 CHAPTER 4 Assessing Health and Health Behaviors Objecti.docx
76 CHAPTER 4 Assessing Health and Health Behaviors Objecti.docx76 CHAPTER 4 Assessing Health and Health Behaviors Objecti.docx
76 CHAPTER 4 Assessing Health and Health Behaviors Objecti.docx
priestmanmable
 
Electronic Health Records - Market Landscape
Electronic Health Records - Market LandscapeElectronic Health Records - Market Landscape
Electronic Health Records - Market Landscape
Harrison Hayes, LLC
 
4 hours agoAmy MillerRE Discussion - Week 7CollapseNU.docx
4 hours agoAmy MillerRE Discussion - Week 7CollapseNU.docx4 hours agoAmy MillerRE Discussion - Week 7CollapseNU.docx
4 hours agoAmy MillerRE Discussion - Week 7CollapseNU.docx
rhetttrevannion
 
Health Informatics- Module 3-Chapter 1.pptx
Health Informatics- Module 3-Chapter 1.pptxHealth Informatics- Module 3-Chapter 1.pptx
Health Informatics- Module 3-Chapter 1.pptx
Arti Parab Academics
 
Healthcare by Any Other Name - Centricity Business Whitepaper
Healthcare by Any Other Name - Centricity Business WhitepaperHealthcare by Any Other Name - Centricity Business Whitepaper
Healthcare by Any Other Name - Centricity Business Whitepaper
GE Healthcare - IT
 
Implementation of Consent in Health Information Exchange (HIE)
Implementation of Consent in Health Information Exchange (HIE)Implementation of Consent in Health Information Exchange (HIE)
Implementation of Consent in Health Information Exchange (HIE)
CitiusTech
 

Similar to Kairon overview (20)

What explains why certain services were covered and others were not .docx
 What explains why certain services were covered and others were not .docx What explains why certain services were covered and others were not .docx
What explains why certain services were covered and others were not .docx
 
A Case Study for Blockchain in Healthcare MedR.docx
A Case Study for Blockchain in Healthcare MedR.docxA Case Study for Blockchain in Healthcare MedR.docx
A Case Study for Blockchain in Healthcare MedR.docx
 
Discussion for Week 4SubscribeTopic  Explain the data i.docx
Discussion for Week 4SubscribeTopic  Explain the data i.docxDiscussion for Week 4SubscribeTopic  Explain the data i.docx
Discussion for Week 4SubscribeTopic  Explain the data i.docx
 
Computer based record
Computer based recordComputer based record
Computer based record
 
Catalyzing coordinationtechnologyswholepersoncare
Catalyzing coordinationtechnologyswholepersoncareCatalyzing coordinationtechnologyswholepersoncare
Catalyzing coordinationtechnologyswholepersoncare
 
Confidentiality & privacy
Confidentiality & privacyConfidentiality & privacy
Confidentiality & privacy
 
21st Century Act and its Impact on Healthcare IT
21st Century Act and its Impact on Healthcare IT21st Century Act and its Impact on Healthcare IT
21st Century Act and its Impact on Healthcare IT
 
Running Head EVALUATION PLAN FOCUSEVALUATION PLAN FOCUS 1.docx
Running Head EVALUATION PLAN FOCUSEVALUATION PLAN FOCUS 1.docxRunning Head EVALUATION PLAN FOCUSEVALUATION PLAN FOCUS 1.docx
Running Head EVALUATION PLAN FOCUSEVALUATION PLAN FOCUS 1.docx
 
Electronic Health Records Implementation Roundtable
Electronic Health Records Implementation RoundtableElectronic Health Records Implementation Roundtable
Electronic Health Records Implementation Roundtable
 
The Electronic Health Record
The Electronic Health RecordThe Electronic Health Record
The Electronic Health Record
 
Part ONE-1 page AMA format-due 917 by 1000 pm EST Evaluate m.docx
Part ONE-1 page AMA format-due 917 by 1000 pm EST Evaluate m.docxPart ONE-1 page AMA format-due 917 by 1000 pm EST Evaluate m.docx
Part ONE-1 page AMA format-due 917 by 1000 pm EST Evaluate m.docx
 
Running Head SHARING CLINICAL DATASHARING CLINICAL DATA.docx
Running Head SHARING CLINICAL DATASHARING CLINICAL DATA.docxRunning Head SHARING CLINICAL DATASHARING CLINICAL DATA.docx
Running Head SHARING CLINICAL DATASHARING CLINICAL DATA.docx
 
Stark Exceptions 20080325
Stark Exceptions 20080325Stark Exceptions 20080325
Stark Exceptions 20080325
 
FACULTY OF HIGHER EDUCATION Individual.docx
FACULTY OF HIGHER EDUCATION         Individual.docxFACULTY OF HIGHER EDUCATION         Individual.docx
FACULTY OF HIGHER EDUCATION Individual.docx
 
76 CHAPTER 4 Assessing Health and Health Behaviors Objecti.docx
76 CHAPTER 4 Assessing Health and Health Behaviors Objecti.docx76 CHAPTER 4 Assessing Health and Health Behaviors Objecti.docx
76 CHAPTER 4 Assessing Health and Health Behaviors Objecti.docx
 
Electronic Health Records - Market Landscape
Electronic Health Records - Market LandscapeElectronic Health Records - Market Landscape
Electronic Health Records - Market Landscape
 
4 hours agoAmy MillerRE Discussion - Week 7CollapseNU.docx
4 hours agoAmy MillerRE Discussion - Week 7CollapseNU.docx4 hours agoAmy MillerRE Discussion - Week 7CollapseNU.docx
4 hours agoAmy MillerRE Discussion - Week 7CollapseNU.docx
 
Health Informatics- Module 3-Chapter 1.pptx
Health Informatics- Module 3-Chapter 1.pptxHealth Informatics- Module 3-Chapter 1.pptx
Health Informatics- Module 3-Chapter 1.pptx
 
Healthcare by Any Other Name - Centricity Business Whitepaper
Healthcare by Any Other Name - Centricity Business WhitepaperHealthcare by Any Other Name - Centricity Business Whitepaper
Healthcare by Any Other Name - Centricity Business Whitepaper
 
Implementation of Consent in Health Information Exchange (HIE)
Implementation of Consent in Health Information Exchange (HIE)Implementation of Consent in Health Information Exchange (HIE)
Implementation of Consent in Health Information Exchange (HIE)
 

Recently uploaded

DPBOSS NET SPBOSS SATTA MATKA RESULT KALYAN MATKA GUESSING FREE KALYAN FIX JO...
DPBOSS NET SPBOSS SATTA MATKA RESULT KALYAN MATKA GUESSING FREE KALYAN FIX JO...DPBOSS NET SPBOSS SATTA MATKA RESULT KALYAN MATKA GUESSING FREE KALYAN FIX JO...
DPBOSS NET SPBOSS SATTA MATKA RESULT KALYAN MATKA GUESSING FREE KALYAN FIX JO...
essorprof62
 
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan ChartSatta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results
 
Kirill Klip GEM Royalty TNR Gold Lithium Presentation
Kirill Klip GEM Royalty TNR Gold Lithium PresentationKirill Klip GEM Royalty TNR Gold Lithium Presentation
Kirill Klip GEM Royalty TNR Gold Lithium Presentation
Kirill Klip
 
1Q24_HYUNDAI CAPITAL SERVICES INC. AND SUBSIDIARIES
1Q24_HYUNDAI CAPITAL SERVICES INC. AND SUBSIDIARIES1Q24_HYUNDAI CAPITAL SERVICES INC. AND SUBSIDIARIES
1Q24_HYUNDAI CAPITAL SERVICES INC. AND SUBSIDIARIES
irhcs
 
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan ChartSatta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results
 
Efficient PHP Development Solutions for Dynamic Web Applications
Efficient PHP Development Solutions for Dynamic Web ApplicationsEfficient PHP Development Solutions for Dynamic Web Applications
Efficient PHP Development Solutions for Dynamic Web Applications
Harwinder Singh
 
The Steadfast and Reliable Bull: Taurus Zodiac Sign
The Steadfast and Reliable Bull: Taurus Zodiac SignThe Steadfast and Reliable Bull: Taurus Zodiac Sign
The Steadfast and Reliable Bull: Taurus Zodiac Sign
my Pandit
 
Pitch Deck Teardown: Kinnect's $250k Angel deck
Pitch Deck Teardown: Kinnect's $250k Angel deckPitch Deck Teardown: Kinnect's $250k Angel deck
Pitch Deck Teardown: Kinnect's $250k Angel deck
HajeJanKamps
 
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan ChartSatta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results
 
Call 8867766396 Dpboss Matka Guessing Satta Matta Matka Kalyan Chart Indian M...
Call 8867766396 Dpboss Matka Guessing Satta Matta Matka Kalyan Chart Indian M...Call 8867766396 Dpboss Matka Guessing Satta Matta Matka Kalyan Chart Indian M...
Call 8867766396 Dpboss Matka Guessing Satta Matta Matka Kalyan Chart Indian M...
dpbossdpboss69
 
Sustainable Logistics for Cost Reduction_ IPLTech Electric's Eco-Friendly Tra...
Sustainable Logistics for Cost Reduction_ IPLTech Electric's Eco-Friendly Tra...Sustainable Logistics for Cost Reduction_ IPLTech Electric's Eco-Friendly Tra...
Sustainable Logistics for Cost Reduction_ IPLTech Electric's Eco-Friendly Tra...
IPLTech Electric
 
NIMA2024 | De toegevoegde waarde van DEI en ESG in campagnes | Nathalie Lam |...
NIMA2024 | De toegevoegde waarde van DEI en ESG in campagnes | Nathalie Lam |...NIMA2024 | De toegevoegde waarde van DEI en ESG in campagnes | Nathalie Lam |...
NIMA2024 | De toegevoegde waarde van DEI en ESG in campagnes | Nathalie Lam |...
BBPMedia1
 
Dpboss Matka Guessing Satta Matta Matka Kalyan Chart Indian Matka
Dpboss Matka Guessing Satta Matta Matka Kalyan Chart Indian MatkaDpboss Matka Guessing Satta Matta Matka Kalyan Chart Indian Matka
Dpboss Matka Guessing Satta Matta Matka Kalyan Chart Indian Matka
➒➌➎➏➑➐➋➑➐➐Dpboss Matka Guessing Satta Matka Kalyan Chart Indian Matka
 
The Most Inspiring Entrepreneurs to Follow in 2024.pdf
The Most Inspiring Entrepreneurs to Follow in 2024.pdfThe Most Inspiring Entrepreneurs to Follow in 2024.pdf
The Most Inspiring Entrepreneurs to Follow in 2024.pdf
thesiliconleaders
 
Registered-Establishment-List-in-Uttarakhand-pdf.pdf
Registered-Establishment-List-in-Uttarakhand-pdf.pdfRegistered-Establishment-List-in-Uttarakhand-pdf.pdf
Registered-Establishment-List-in-Uttarakhand-pdf.pdf
dazzjoker
 
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan ChartSatta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results
 
Enhancing Adoption of AI in Agri-food: Introduction
Enhancing Adoption of AI in Agri-food: IntroductionEnhancing Adoption of AI in Agri-food: Introduction
Enhancing Adoption of AI in Agri-food: Introduction
Cor Verdouw
 
The latest Heat Pump Manual from Newentide
The latest Heat Pump Manual from NewentideThe latest Heat Pump Manual from Newentide
The latest Heat Pump Manual from Newentide
JoeYangGreatMachiner
 
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan ChartSatta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results
 
Pro Tips for Effortless Contract Management
Pro Tips for Effortless Contract ManagementPro Tips for Effortless Contract Management
Pro Tips for Effortless Contract Management
Eternity Paralegal Services
 

Recently uploaded (20)

DPBOSS NET SPBOSS SATTA MATKA RESULT KALYAN MATKA GUESSING FREE KALYAN FIX JO...
DPBOSS NET SPBOSS SATTA MATKA RESULT KALYAN MATKA GUESSING FREE KALYAN FIX JO...DPBOSS NET SPBOSS SATTA MATKA RESULT KALYAN MATKA GUESSING FREE KALYAN FIX JO...
DPBOSS NET SPBOSS SATTA MATKA RESULT KALYAN MATKA GUESSING FREE KALYAN FIX JO...
 
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan ChartSatta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
 
Kirill Klip GEM Royalty TNR Gold Lithium Presentation
Kirill Klip GEM Royalty TNR Gold Lithium PresentationKirill Klip GEM Royalty TNR Gold Lithium Presentation
Kirill Klip GEM Royalty TNR Gold Lithium Presentation
 
1Q24_HYUNDAI CAPITAL SERVICES INC. AND SUBSIDIARIES
1Q24_HYUNDAI CAPITAL SERVICES INC. AND SUBSIDIARIES1Q24_HYUNDAI CAPITAL SERVICES INC. AND SUBSIDIARIES
1Q24_HYUNDAI CAPITAL SERVICES INC. AND SUBSIDIARIES
 
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan ChartSatta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
 
Efficient PHP Development Solutions for Dynamic Web Applications
Efficient PHP Development Solutions for Dynamic Web ApplicationsEfficient PHP Development Solutions for Dynamic Web Applications
Efficient PHP Development Solutions for Dynamic Web Applications
 
The Steadfast and Reliable Bull: Taurus Zodiac Sign
The Steadfast and Reliable Bull: Taurus Zodiac SignThe Steadfast and Reliable Bull: Taurus Zodiac Sign
The Steadfast and Reliable Bull: Taurus Zodiac Sign
 
Pitch Deck Teardown: Kinnect's $250k Angel deck
Pitch Deck Teardown: Kinnect's $250k Angel deckPitch Deck Teardown: Kinnect's $250k Angel deck
Pitch Deck Teardown: Kinnect's $250k Angel deck
 
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan ChartSatta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
 
Call 8867766396 Dpboss Matka Guessing Satta Matta Matka Kalyan Chart Indian M...
Call 8867766396 Dpboss Matka Guessing Satta Matta Matka Kalyan Chart Indian M...Call 8867766396 Dpboss Matka Guessing Satta Matta Matka Kalyan Chart Indian M...
Call 8867766396 Dpboss Matka Guessing Satta Matta Matka Kalyan Chart Indian M...
 
Sustainable Logistics for Cost Reduction_ IPLTech Electric's Eco-Friendly Tra...
Sustainable Logistics for Cost Reduction_ IPLTech Electric's Eco-Friendly Tra...Sustainable Logistics for Cost Reduction_ IPLTech Electric's Eco-Friendly Tra...
Sustainable Logistics for Cost Reduction_ IPLTech Electric's Eco-Friendly Tra...
 
NIMA2024 | De toegevoegde waarde van DEI en ESG in campagnes | Nathalie Lam |...
NIMA2024 | De toegevoegde waarde van DEI en ESG in campagnes | Nathalie Lam |...NIMA2024 | De toegevoegde waarde van DEI en ESG in campagnes | Nathalie Lam |...
NIMA2024 | De toegevoegde waarde van DEI en ESG in campagnes | Nathalie Lam |...
 
Dpboss Matka Guessing Satta Matta Matka Kalyan Chart Indian Matka
Dpboss Matka Guessing Satta Matta Matka Kalyan Chart Indian MatkaDpboss Matka Guessing Satta Matta Matka Kalyan Chart Indian Matka
Dpboss Matka Guessing Satta Matta Matka Kalyan Chart Indian Matka
 
The Most Inspiring Entrepreneurs to Follow in 2024.pdf
The Most Inspiring Entrepreneurs to Follow in 2024.pdfThe Most Inspiring Entrepreneurs to Follow in 2024.pdf
The Most Inspiring Entrepreneurs to Follow in 2024.pdf
 
Registered-Establishment-List-in-Uttarakhand-pdf.pdf
Registered-Establishment-List-in-Uttarakhand-pdf.pdfRegistered-Establishment-List-in-Uttarakhand-pdf.pdf
Registered-Establishment-List-in-Uttarakhand-pdf.pdf
 
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan ChartSatta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
 
Enhancing Adoption of AI in Agri-food: Introduction
Enhancing Adoption of AI in Agri-food: IntroductionEnhancing Adoption of AI in Agri-food: Introduction
Enhancing Adoption of AI in Agri-food: Introduction
 
The latest Heat Pump Manual from Newentide
The latest Heat Pump Manual from NewentideThe latest Heat Pump Manual from Newentide
The latest Heat Pump Manual from Newentide
 
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan ChartSatta Matka Dpboss Kalyan Matka Results Kalyan Chart
Satta Matka Dpboss Kalyan Matka Results Kalyan Chart
 
Pro Tips for Effortless Contract Management
Pro Tips for Effortless Contract ManagementPro Tips for Effortless Contract Management
Pro Tips for Effortless Contract Management
 

Kairon overview

  • 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