Kairon overview


Published on

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

Kairon overview

  1. 1. Architectures and Processes for Nationwide Patient-Centric Consent ManagementP. Mork, A. Rosenthal, and J. StanfordThe MITRE Corporation AbstractBackground: 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 introducedgradually, in a manner compatible with an exceedingly complex system: multiple professions, islands of partialstandardization, radical differences in automation and technical sophistication, autonomous players with differingmotivations, refusals to participate, external data sources, an evolving and unpredictable legal landscape, andpressure groups from privacy advocates, researchers, and health providers.Objective: We propose pragmatic requirements and a highly patient-centric, Internet-based consent managementarchitecture .Methods: We examine requirements for serving a wide variety of patients and providers, including their diverseincentives. 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 theirpersonal health information in one virtual document; emergencies and research can be included. Record holders canretrieve the patient’s privacy policies, reconcile with what they are willing to enforce, and mix in governmentdefaults and mandates as additional rules. Then, we describe how a record holder uses the consent service todetermine just the privacy constraints that need to be enforced for a particular request. With today’s systems, manyof these constraints need to be verified manually; our architecture enables incremental automation. We illustratehow our architecture can support a wide variety of use cases, and examine the independent stakeholders’ incentivesto participate. The approach was found able to handle an extremely wide range of requirements, but not all. Openproblems 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 thescope of current Data Segmentation standards initiatives. .Introduction and Background1.1 IntroductionAs the world moves towards widespread adoption of electronic health records (EHRs), one of the most frustratingproblems is how to meet legal/regulatory requirements to obtain and apply patients’ consent to share data with otherparties. 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 healthinformation to third parties and consider the ability to control the use of their data to be critically important. Thispaper proposes a technical approach to meet many of the consent management desiderata established by the Officeof the National Coordinator for Health Information Technology (ONC) [1 Gold1, 2 Mark1]. We also discuss thepolicy issues that arise when sharing health information on a nationwide scale, such as the U.S. Nationwide HealthInformation Network.Providers currently supply consent forms, explain them to patients and bear the burden of enforcement, so theirconcerns tend to be favored over the patients’ concerns. To minimize burdens, they rarely provide the ability toexpress nuanced consent preferences [4 Mark2]. Instead, a typical provider institution creates its own form, usuallynotifying patients of the institution’s HIPAA data sharing policies, but not allowing patients to express their ownprivacy preferences. Also, its stack of paper consent forms cover a narrow range of anticipated data sharing. If apatient needs to have his records forwarded to another physician or to be screened for research protocols, he often
  2. 2. has to complete additional paper forms for each request. When the patient wishes to revoke consent, providersholding consent forms that enable them to disclose data need to be identified and those forms updated. (It seemsinfeasible to “claw back” data that has been released, because data from an imported document may percolate tomany 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 compliancerequirements of many jurisdictions, both internationally and among the 50 US states. Elegance and flexibility arerequired, rather than a mass of idiosyncratic features. The architecture is intended to be flexible enough to adapt tolegal 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, reducecosts, and make it feasible to document the patient’s wishes in a form that is readily accessible, understandable andup-to-date. This paper describes one part in detail -- handling the patient’s preferences. The Future Work sectionbriefly explains how we will mix in government and record holder preferences, reconcile with a record holder’senforcement ability, and provide an integrated ruleset, so patients and others can understand how the combinedsystem will behave.In our “Kairon” prototype, a patient manages one preferences document (a ruleset) that is used for all requests to allrecord holders. This allows patients to guide data sharing by independent laboratories and health informationexchanges (HIEs) with whom they have no direct relationship. By providing nationwide access to up to date consentpreferences, we enable patients to update their preferences in one place, without contacting every potential recordholder. 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 begreatest in jurisdictions where laws permit generalized rules such as “release to any clinician known to be treatingme”. Patients can establish their privacy preferences just once, and update in one place with effect on all recordholders. Record holders do not need to elicit a new document (possibly with counseling) for each new exchange ofhealth information, nor worry whether their consent is current. Enforcement may be more palatable when bundledwith a capability record holders want, such as enforcement of government and organizational rules. These factorssomewhat mitigate disadvantages, such as lower record holder autonomy and the need to counsel patients for whomautomated help does not suffice. Requestors will not need to solicit consent for every request, nor do it in terms ofthe record holder’s consent form. Such a simplification might encourage dentists and chiropractors to push data tothe primary care provider (PCP), or the PCP to share data with any researcher they approve. This would beespecially important for recruiting to research studies or for analyses that need many patients’ data. (Some patientswill be willing to consent to have their data referenced for research, especially after “lite” deidentification and forapproved researchers). Recipients need not separately track privacy constraints that apply to the health informationthey receive, but instead just check the patient’s current preference. All are spared paper forms, saving a majoradministrative burden [1 Gold1, page ES-2].We focus in particular on consent management challenges, relying on other services for generic data sharingcapabilities, such as: message handling (e.g., request submission and interception, transport, encryption), identityservices (authentication and matching, for patients and for health system entities), and reconciliation of semanticheterogeneity.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 aconsent management system. Section 3 demonstrates efficacy by showing how our proposed architecture handles2
  3. 3. several common use cases, with varying degrees of automation. Section 4 summarizes the benefits of patient-centricconsent management as realized by our architecture, and comments on future work. 1.2 BackgroundThough it offers little flexibility, paper-based consent management is still a burden for all concerned. Some recordholders insist on signed paper, due to regulations or because they do not trust that an easily forged fax sufficientlyprotects them. When a consortium of New York City hospitals agreed to upload all data to their Health InformationExchange (HIE) and then rely on each other’s claim to have an authentic consent, sharing increased fourfold. [10GSK1]Several efforts have explored ways to transition to electronic management of patient consent. Integrating theHealthcare Enterprise (IHE) has developed a conceptual model for consent management [9 IHE1] to be integratedwith EHRs. Storage can be provider-centric or patient-centric. Providers can specify interfaces through whichpatients can state preferences. As provider constructs become standardized, some could be incorporated into userinterfaces, to promote easy enforcement.Goldstein, ET al. [1 Gold1] discuss the privacy options patients are typically given: none, opt-in, opt-out, opt-in withrestrictions and opt-out with restrictions. This paper notes that patients perceive a need for more granular options torestrict access to their health information based on such aspects as diagnosis, source, recipient, etc. However, few (ifany) 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 tospecify 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 transferredto another system, so they must be respecified, and updates are not propagated. [HITSP]. Current efforts includestandardization of consent metadata, funding experimental prototypes, and a “Segmentation” initiative that includesstandards for both data annotation and consent.The President’s Council of Science and Technology Advisors (PCAST) report [16 PCAST1] recommended thatprimary care providers explain consent policies and capture patient preferences face to face, but that patients shouldalso have access to a helpful web interface. Though we began this work two years before the PCAST report waspublished, the consent system we describe here can ease these tasks with its intuitive presentation of preferences andby storing and presenting educational materials.Halamka [15 Hal1] would like to encourage patients to delegate authority to clinicians, to share their data asdesired. Such delegation is useful, but expresses only the clinician’s wish to receive data, not the patient’s wish tosend.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]. TheHITSP Privacy Consent Directive Working Group presents key questions regarding the “cross validation andverification 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 publichealth.The Data Segmentation effort of ONC’s Standards and Interoperability Framework has developed standards forsimple 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’ productshttp://www.jerichosystems.com/solutions/patientprivacy.html both provide Internet-based repositories for suchpreferences, and enforcement at record holders. Neither the standard nor the products supports general, multi-useconsents (e.g., based on known treatment relationships), nor extensibility to other topics. Some state HIEs (e.g.,Texas) also provide consent capabilities.3
  4. 4. Existing security technologies provide several useful capabilities but do not suffice for consent systems. The basicsecurity 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 DecisionPoint (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. Weneed the ability to split rule evaluation into multiple stages, initially just substituting attributes from the request andproducing a simplified the ruleset by eliminating rules whose conditions fail for this request’s purpose orparticipants. The simplified ruleset may be displayed as part of a “what if” facility, used by a person who enforcesmanually, or passed to the next stage of evaluation.The best known access control language, XACML, is an OASIS standard, and can conveniently encode Booleanlogic; the XPSD profile defines a vocabulary of information to be used in consent policies. However, XACML hasseveral shortcomings for our purposes. It cannot exploit taxonomies, nor use variables (akin to relational databasejoin) to test relationships and affiliations, so these must be done by add-on systems. It requires an extraadministration level -- targets to identify relevant rules. The supported actions are just Allow/Deny; other actions arepushed into an opaque obligation facility, with no conflict management. Academic researchers have proposed todeconflict based on rule strengths [Jajodia et. al.] and XACML supports that. However, researchers have notproposed a plausible way to manage strengths in a scenario that is as complex as Consent’s mix of defaults andmandates 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 viause cases in Section 4.Consent Service CapabilitiesThe consent service associates each patient with a set of rules that identify circumstances where health informationcan be released. A rule may reference attributes of the request (e.g., requestor, recipient, and purpose), the topicscovered in the item to be released, and additional knowledge (such as affiliations and referrals). Most rules specifythe action “Allow release”, subject to a condition. In our basic language, Allow is the only action, so there is noneed 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 asways to derive a relationship Treats(patient, clinician) based on explicit patient assertions plus referrals, on-callsubstitution, and affiliations.Upon a request, the record holder creates an answer to the requestor’s query as a set of candidate items and thentests consent on each item and releases only those that pass the test; the effect may be, for example, to release asubset of an XML structure, based ono the topics it contains, and their provenance. Under future work, we discussways to accommodate the awkward likelihood topic detection will never be highly accurate for all data.Establishing Privacy PreferencesEach 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 serviceproviders 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 purposeand a set of recipients,, and with predicates specified on metadata attributes. These attributes indicate type ofinformation (e.g., Allergies) plus presence of sensitive topics (such as mental health). However, a full specificationof an appropriate policy would involve more detail than patients can manage, to handle issues like strength of therequestor’s authentication, or uncertainty when saying a record does not reveal a sensitive topic.4
  5. 5. We are now exploring a higher level interface, in which experts write detailed rules, while patients merely expresswhere they want the balance point between protection and sharing. Currently, a slider is used to express eachbalance points, both globally and on specific topics such as mental health or pregnancy. The slider values areis thenused 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 recordThe patient’s preference may include tests on items’ topics and provenance, but that information may be unavailablefor some data (e.g., pdfs). Today, the patient must negotiate explicitly with each record holder, creating a separateruleset (called a directive) that the record holder is confident they can enforce, driven by the low water mark ofrecord holder’s capabilities. Our approach instead tells the record holder to do their best on each item, returningUnknown in the worst case and actual topics and provenance in the best. The rule then specifies how to deal withUnknown attribute values. Our three-valued rule logic (which can return Unknown) allows patients (through theirUIs) to specify rules whose terms that use either forgiving or strict interpretation of Unknown; future extensionswill 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 providerorganization could give its patients a UI that produces rules that execute easily in its EHR; advocacy groups coulddevelop UIs designed to address their concerns. These UIs can gradually be tailored for the gamut of patients, withpatient-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 behalfof the patient (e.g., if the patient is uncomfortable with electronic consent management or is a minor). A patientmight even identify a trusted physician as a proxy (assuming the physician is willing), with partial rights toauthorize individual releases or to make permanent changes.Managing RequestsA request for patient data typically describes the data requested, plus values for purpose, individual andorganization ID for requestor, recipient, record holder, and the patient’s consent ID (Section 2.2). The requestorand 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. USlaw today can require specific verbiage to be inserted into the record for substance abuse data; this text is strictly forhuman readers.When the consent service receives the request, it retrieves the patient’s preferences, and forwards them to the recordholder. Drawing on information in the request message and from other available evidence, it can simplify beforeforwarding, to exclude rules that are inapplicable (e.g., Treatment rules are inapplicable to Research requests; PCPpermissions are irrelevant if the recipient is known not to be the patient’s PCP?). Sometimes this process will sufficeto generate a decision (increasingly, as standards and evidence sources improve). The consent service then sends adecision, or else (simplified) constraints for the record holder to evaluate, in both human friendly form and machinefriendly 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 ruleterms may require manual help. We expect record holders to be conservative: if a patient rule includes a term therecord holder is unable or unwilling to evaluate, Unknown is returned. Distributed query optimizing techniquesmight 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 therequest message; any additional factors that influence the decision-making process (e.g., the patient told the consentsystem that Dr. Jones is her PCP); endorsement of this request from the patient or proxies, and the constraints sent tothe record holder.The patient can interact with the audit subsystem to see the history of requests, or to define alerts that notify him ofrequests that meet specific criteria (e.g., a request to access the results of an HIV test). The consent service offloads5
  6. 6. this IT burden from the record holder, who may need to cope with patient questions. As with any security system, itwill be important to avoid trivial alerts.To manage consent on a large scale, additional capabilities are needed, to make the system trustworthy, and toobtain ancillary information that belongs in external sources, not in EHRs. These are addressed in the next twosubsections.Patient Identity and the Consent SystemsThis section addresses the consent system’s need to ensure that a patient’s records are released based on their ownconsents, rather than an inadvertent mismatch or malicious spoofer. The first step, as in eCommerce, is for thepatient to open a consent account and obtain a consent account ID, hereafter called a “consent ID.” Then, to securelytie this account to a record holder’s records, the patient must authenticate with the record holder (in person or bysecurely 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 requiringlinks to individual records. Once this is established, the record holder knows that the preferences sent by the consentservice correspond to this patient. (We examined other approaches to attaching a consent identity, but the oneswithout user login seemed insecure – a malicious referral could attach the wrong ID to the recipient’s master patientrecord. One could attach the consent ID to the data sent, but then must carry it along as that data is shredded andinserted into databases.)The consent service will give a patient voluntary digital IDs on demand; the patient decides which ID to give eachprovider. A privacy purist patient might give a distinct identifier to each record holder; another person might givethe same identity to most providers (for its error-reducing benefits) but give distinct identifiers at a substance abuseclinic and a reproductive health center. Extra IDs make it possible to attach Consent IDs without creating anunwanted global identifier [Roop, Mark3]. (US laws currently prohibit government funding of creation of suchidentifiers, even when voluntary.)When a record holder receives a request, they are responsible for identifying the appropriate patient. If a requestorattaches the consentID he uses for the desired patient, it can be part of the identity-matching process, to reduceerrors.Ancillary Knowledge SourcesThe consent service may rely on “ancillary” evidence not in the candidate release or the request message. Examplesinclude the identity of a patient’s PCP, the PCP’s referrals, and clinician attributes (specialty, and hospitalaffiliations). While originating at many provider and state sources, they might be made available 7x24 through asingle interface via an HIE or data aggregator. For example, Health Management Sciences aggregates certificationand 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 thepatient’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, staffassignments), 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 logicThe patient preference consists of rules submitted through the patient’s consent specification user interface. Weanticipate that wizards and defaults will do much of the work, being customized by the patient’s expressed level ofprivacy concern and topics of particular sensitivity. Our prototype evaluates only the patient preferences. We areexploring ways to include Allow and Deny rules, especially from organizational and government preferences, toproduce an integrated ruleset.6
  7. 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 ReasonerRules determine their own scope of applicability, by including explicit predicates on metadata available from therequest, the health record, or ancillary sources. Each rule has a condition; if that evaluates to false, the rule isignored. If true, then the rule is applicable and a result is created (either an Allow decision or a table that feeds intolater rules; Deny rules will be added soon). Since applicability is handled within each rule, there is no need toconstruct 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, suchas 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 conjunctsto deal with Unknown, and more generally, to support confidence thresholds. We are also investigating semanticweb 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, itsubstitutes values from the request message, from ancillary sources, or from the health record, and then does logicalsimplifications. Because simplify (rather than evaluate) is our primitive, we can leave a residue for automatedprocessing 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 ArchitectureFigure 1: Configuration C for giving record holder an enforceable consent. The record holder (R) forwards the requestto the consent service (C), which uses a policy reasoner to determine the residual policy to be enforced on the healthrecord. Our prototype translates the residual policy to XACML and places an efficient XACML engine at the recordholder to make access decisions. The capabilities described above can be combined in multiple ways to instantiate aconsent management system. In this section, we present a high-level architecture and data flow (Figure 1). We thendiscuss 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 auditlogs in a consent database. Patients create and modify these privacy preferences via a consent specification GUI. Toavoid liability risk and reduce storage, C receives no EHR data. The record holder sends C the consent identityregistered for the patient, finds the proper consent account (resolving aliases), and connects with external sources to7
  8. 8. obtain ancillary knowledge. This is the architecture we prototyped, as a natural extension to today’s practice. Itdistributes conventional functionality into several components. One Policy Enforcement Point (PEP) intercepts therequest and sends it to our policy reasoner (acting as a partial Policy Decision Point -- PEP), which in some casesmay provide an answer for the entire request. If not, the reasoner produces a simplified policy (also called residualpolicy), as the response is constructed. The relevant policy will (eventually) be constructed at run time as the PIPmixes 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 oftopics and provenance categories, as either Present, Absent, or Unknown. Annotation techniques rely onextensive terminological and clinical knowledge and are outside our scope; as a callable service. Several suchservices have been built; for example, one is included in the SAMHSA/VA demonstration at HL7 in September2012. Secondary users may also find the annotations useful, whether to retrieve on clinical topics or to examinepatient and information flow among institutions. Annotations will be provided for legally mandated categories and afew 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 oremail. A medical records specialist would enter information about the recipient and request into a web form hostedby the consent service, and receive a human-readable version of the patient’s preferences. She interprets theconditions for each item proposed for release. If the evaluation needs ancillary data, she obtains it by accessingwebsites or by telephone.This degree of manual processing is incompatible with extensive exchange. Still, it seems worth demonstrating thattechnology-poor environments will not find their work harder. For example, a provider might initially seek only thesimplest benefits, such as distributed editing and retrieval of the latest patient and government preferences. Patientsalso get the benefit of simpler and more patient-centric consents, as opposed to the current system in which theymust 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 processesformatted messages from requestors in their own health provider network. Requests are queries in standards known8
  9. 9. to their EHR, and requestors are known. In this idealized case, either the scope is small (such as just an HL7 C32message), or else all health records in their institution can be accessed via a single EHR interface. The patient’spreferences are stored in one Internet-accessible place.Configuration C (fully automated, distributed): The previous configuration is elaborated to have two reasoners, oneco-located with the Consent database (hosted once, and able to see rule terms that are too sensitive to send to somerecord holders), and one located at the record holder to deal with the residual (and able to see sensitive referralinformation that the record holder might not disclose to a remote reasoner). Our prototype implements thisconfiguration. To show use of existing standards, the record holder’s reasoner is implemented by translating first toXACML, and then evaluating.Results (Examination of Use Cases)To illustrate how a consent management system provides our claimed benefits, we consider six use cases. Forgenerality, the descriptions allow a range of automation in terms of both the record holder’s capabilities and thecollection 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 amobile phone, or in a kiosk in the waiting room). Because the patient does not have an existing consent account, heis given a new consent identifier. Next, he is walked through a series of wizards to establish his initial privacypreferences. 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 suggestionsfrom the IHE report discussed earlier [9], we hope that organizations will establish reasonable prepackaged optionsfor the patient to select from. The system can also express the current style of narrow consents—a rule can includeconjuncts that restrict its applicability to one record holder, one requestor, or one request although we woulddiscourage such usages.Our examples below assume that the patient says “anyone referred by my PCP has a treatment relationship”, andpermits release of all information to their PCP, and all except mental health to any provider with whom they have atreatment relationship. We also assume that some providers make it known that they normally process queriesagainst a store that excludes all data subject to special legal protections (e.g., originating at a federally fundedsubstance 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 theconsent service contacts the patient for selection and approval. For example, a future UI might determine that thepatient 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 existingpreferences. 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 relationshipwith 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 ancillaryinformation manually.Now the consented request is processed. For the advanced record holder, the request is sent to their EHR and theresults assembled. In configuration A, a medical records person receives the request, manually forwards a messageto the consent system, and receives the preferences she is to enforce. She then formulates requests to the varioussystems at her site (possibly including paper) and assembles a response. In either case, the result is then securelytransmitted to the recipient.For case 3b, the consent system tells the record holder “release is approved except for information that the recordholder knows relate to mental health.” For each item to be released, the rule retrieves the record holder’s annotation.9
  10. 10. (If mental health information is kept in a segregated data store, then items from all other stores is virtually annotatedas Absent). Any data, annotated as mental health Present will be redacted from the response, but data annotatedAbsent or Unknown would be released. (A more restrictive patient might write a rule that also excludesUnknown.)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 thatMs. Jones is a healthcare provider and that the patient’s PCP has referred the patient to her. According to thepatient’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 areshown to the record holder. The record holder is then responsible for enforcing the remaining constraints. Note thatno 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’smedications and allergies from a California record holder. The notional California policy includes conditions fortrusting the claim that this is for a medical emergency, and then allows all Normally-sensitive information to bereleased, but requires explicit auditing and that the patient be informed. Here, the notional condition is that therequestor’s claim to be a doctor has been verified OR the request came from a known Emergency Department and acheck of the requestor’s claim to be a doctor or Nurse returned True or Unknown. (The second condition applies ifCalifornia’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 limitationsthat involve minimal medical risk, such as to limit the access for particular individuals or organizations (e.g., aninstitution 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 matchthem to clinical studies; some have even offered to share deidentified data without being contacted. To recruit, theresearcher first asks the consent service to search across all patients to find those who have consented to recruitmentfor kidney research; this will include patients who consented to research in general. Second, the EHR performseligibility screening based on demographics, dates, diagnoses, and treating clinicians. The eligible candidates maythen be sent invitations to contact the researcher. For the most willing patients, the EHR may be sent a consentedrequest 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 fractionfrom 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 fullyautomated and thus much cheaper. An alternative approach is to send queries to the sourceshttp://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 insensitiveenough 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 allbenefit, and thus have incentives to participate. A key idea is that all of a patient’s rules (augmented by governmentrules, as needed) are stored in one place, accessible to the patient (for updates) and to record holders (for evaluationrequests). Rule terms that reference data from the request or ancillary evidence are evaluated and the rulesetsimplified, so the record holder sees only what is relevant. Metadata is attached to the transmitted record, describingthe data’s topics and provenance, but not the applicable policies (which may change). This metadata can be used forprivacy and also for other applications (e.g., discovery, budget analysis by topic). Throughout, we employ10
  11. 11. generalized capabilities (e.g., rule engines, reusable consents) to minimize complexity, for both softwareimplementers and patients.Patients get a single location for expressing their consent preferences, so they do not need to separately notify everyrecord holder. They gain flexible user interfaces that go beyond provider legalese or HIPAA forms, making it easierto review and modify their preferences. The UIs are available over the web anytime, anyplace there is Internetaccess, not just at the provider’s check-in desk. Relevant federal or state regulations could be visible from the sameinterface, allowing patients to see how their preferences interact with legal constraints. UIs can incorporate recordholder idioms, and vendors can compete for patient adoption. As a result of all this, patients get better care becausetheir providers can better share information.Record holders will get a reduced consent-enforcement burden, as compared with manually processing requests withthe same patient preferences. They are freed from maintaining a stack of consent documents and can apply thepatient’s generalized preferences without contacting the patient again. They need not pass policies or obligations torecipients – instead, the recipient can get the latest over the Internet, in machine processable form, not a fax. Logicalsimplifications 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 consentnegotiation. By reusing existing generalized consents, they can get the data they need, without waiting for thepatient to sign a new document. The potential benefits are especially big for researchers and other secondary users ofEHRs. The consent system can even give requestors a preview of what it will send the record holder (if that previewdoes not contain sensitive information), thus reducing unexpected rejections. Data may also be pushed rather thanpulled, or even be initiated by an untrusted third party. For example, a secretary could phone the home provider andask 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 recordholder.Further researchAdditional research is needed to establish a range of user interfaces and pre-written policies, based on a variety offactors including device (such as paper, desktop computer, or smart phone), level of privacy concern, and degree ofcomputer sophistication. Patients also need help in understanding terminology (e.g., “mental health”) and to reasonabout the impact of their preferences.Rule languages and UIs need expansion to deal with uncertainty about assertions, e.g., for “doubtful” emergencyrequests, 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, andwith 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 inrules from organizations plus federal and state governments. The challenge is to support multiple modes: weakdefaults 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 mightoverride topic restrictions), blacklists (e.g., to override emergency requests from an ex-spouse as recipient), andunconditional mandates (“Release tuberculosis diagnoses to Public Health departments”). We are now designingsuch 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 thatcannot be fully revealed to all record holders.Government and provider policy initiatives can speed progress. Consent services should be certified, and thenproviders might be allowed to rely on them, without fear of liability. Government should make its policies availableas machine readable rulesets, which are deemed authoritative. Policy should be developed about what directoryservices may reveal. We also need to enable interoperability to allow patients to switch consent service vendors, andto enable competition and innovation in individual components, such as UIs. Also, a technical facility cannot resolveissues 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 justto place consents (in machine and human readable form) on record holders’ screens (e.g., for a physical therapistpracticing alone, with minimal software), and to automate the simplest cases (which are pleasantly common). Ourarchitecture consciously avoided depending on universal participation, employment of data standards, record holder11
  12. 12. automation, or ancillary data completeness. Progress in these areas would permit greater automation, but in the nearterm, 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 flexibleand extensible, to accommodate changing laws, and stronger desires for patient privacyAcknowledgements and Conflicts: This work was funded by MITRE’s internal Innovation Program. The softwarehas been released as open source, and MITRE does not sell either the software (which has been open sourced) orsupport. 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 CouldImprove 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 AppendixA. [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 andProtecting 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 NetworksInteroperability 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 athttp://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 HealthInformation 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 athttp://www.webcitation.org/674ss2lsZ[9 IHE1] Integrating the Healthcare Environment (IHE). Basic Patient Privacy Consents. [Internet] [cited 2011 April4] [about 6 pp.] http://wiki.ihe.net/index.php?title=Basic_Patient_Privacy_Consents. Archived athttp://www.webcitation.org/674ThDPAZ[10 GSK1] N. Genes, J. Shapiro, G. Kuperman “Health Information Exchange Consent Policy InfluencesEmergency 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. [cited2011 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 TechnologyHearing, June 29, 2010, p. 312
  13. 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 thefull potential of health information technology to improve healthcare for Americans: The path forward.”, December2010, 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-ForwardArchived at http://www.webcitation.org/674uBy6rQ13
  14. 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