Electronic Health Network - Case Study Consent2Share Share with Confidence

Transcription

1 Electronic Health Network - Case Study Consent2Share Share with Confidence Jan 2015

2 About Consent2Share Complying with privacy regulations in an electronic environment is a very complex process. The Consent2Share (C2S) pilot for Prince George s County Health Department implemented by the EHN team in accordance with FEi needed to demonstrate that privacy consent and data segmentation software tools and standards, developed through HHS initiatives, can be used to allow patient health record sharing in an environment. The pilot also demonstrated how privacy consent and data segmentation software tools and standards allow patients receiving behavioral health treatment to share their health information while providing improved protection of their privacy. Objectives In order to meet these goals the team needs to achieve the following objectives: (1) Integrate a production-grade version of privacy and consent management system (C2S) which is capable of supporting a pilot implementation which demonstrates that patient health record sharing can be successful within the privacy constraints of a 42-CFR, Part 2 environment. (2) Interface with a behavioral health electronic medical record and primary care physician medical record. (3) Allow all clinical transactions to be managed and executed via the community health information exchange. Significance The significance to treatment is that now a patient has the ability to choose what to share and not to share based on their privacy preferences so that they don t have the fear of becoming stigmatized due to a particular illness or condition. We understand that integrated care is very important to providing the best care possible, and this requires harmonizing communication as well as medical information. What we must consider is the patients comfort level with wanting to share all data so that they are able to receive care. They may elect to not participate at all because they feel the right protections in regards to privacy and security are in place and without participation the road to recovery isn t possible. We must also consider the legal requirements that drive the sharing and access to this level of protected health information. 42CFR part 2 mandates that patients must consent to having their information shared. The process can be managed through non-technical paper based approaches however inefficiencies created in such systems lead to problems. Electronic health systems hold allot of valuable information such as history of alcohol and drug use disorders which can assist with managing better care, and reduce adverse events related to medication interactions. However 42CFR mandates that the patient consent to sharing this information with a specific individual for a designated purpose of use. Although technology has changed and 1

3 advanced the law has not been amended since The technical interoperability and clinical workflow challenges that were overcome to deliver a very sophisticated and technically complex health information exchange platform that has the ability to manage consent and data segmentation via a patient facing application. The result was the ability to communicate both technical and contractual patient consent policy in real-time to the HIE. Then have the HIE translate the policy and share specific elements of clinical data at the request of the patient. Now a patient is able to choose to not share the fact they are receiving treatment for alcoholism with their primary care physician and only share that sensitive information with the treatment team that requires the data. The Technology The goal of the project was to produce a replicable process that would easily scale to other providers and their systems. Using IHE Integrating the Healthcare Enterprise interoperability framework we implemented / deployed: PIX Patient Identity Management XDS Cross document sharing repository and registry Policy Repository XACML policies XUA Cross enterprise user assertion Query-based Exchange using IHE profiles and webservices ACS Access control services CDA C32 structured documents Data segmentation services Figure 1. System Architecture 2

4 System Architecture Patient Identity Management PGCHD has implemented a full HIE Stack in accordance with the IHE Framework. The C2S application, Behavioral Health EMR and PCP EMR have PIX Feeds established with the HIE. The system leverages the existing Patient Index (PIX) / Patient Identity Feed / Patient Identity Management deployed in the PGCHD HIE. With this approach the Patient Identity Feed communicates patient information, including corroborating demographic data, after a patient s identity is established, modified or merged or after the key corroborating demographic data has been modified. Patient Identity Management registers or updates a patient record and their associated demographic information. The Patient Demographics Query (PDQ) transactions allows the applications to query a central patient information server, based on user defined search criteria, for a list of patients and retrieve a patient s demographic information. Provider Identity Management The PGCHD HIE supports a Healthcare Provider Directory (HPD) profile for management of healthcare provider information in a directory structure. The Directory houses demographics, address, credentials, National Provider Identifier (NPI), specialty, and organization. The Index is able to identify an individual provider as well as an organization to include Counseling Organizations (e.g., Drug, Alcohol) Healthcare Information Exchanges (HIEs), Managed Care, Integrated Delivery Networks (IDNs), and Associations. Electronic Medical Record Integration The Project integrated (3) Systems / End Point Applications. SMART Behavioral Health Electronic Health Record (Webservices) MIE WebCharts Electronic Medical Record (IHE) Consent2Share Patient Consent Management Application (Webservices) The three systems were written with different software languages, (1) use d interoperability standards and the other (2) were not built to standards. We identified (2) approaches for connectivity. 1. Webservices using SOAP XML messages that converted non-standardized transactions to IHE compliant transactions 2. Standard IHE transactions Storage of 42 CFR Part 2 documents We created an XDS domain specifically for C2S Addictions and Mental Health to serve as a Document Registry. The Registry will have attributes of namespace, the universal ID and 3

5 type, mime types, format codes, class codes, and confidentiality codes. Registry Actor will maintain metadata about each registered document in the C2S document entry and link to the Document in the Repository where it will be stored. The XDS Registry will be configured with the associated Domain and the corresponding URLs for the XDS.a-Registry and XDS.b-Registry for secure connections. HL7 PatientID will always be running in real-time operation in connection with a PIX to ensure the verification of the PatientID in the patient index Integration Points for C2S Services (ACS) Access Control Access Controls C2S Policy Enforcement - In the underlying notion of access control each resource can be paired with one or more policies, namely XML documents expressing the capabilities that a requestor needs to have in order to access the resource. The Policy Administration Points (PAPs) in the case of the PGCHD C2S Pilot the Patient writes and sets the policy. The policy is then made available to the Policy Decision Point (PDP), which is on duty to decide whether to give access to resources or not. The communications between PAPs and the PDP may be facilitated by a policy repository; however, the XACML specification does not require it. The policies and policy sets stored by the PDP represent the complete policy for the specified resources. The request to access a resource is created by a Policy Enforcement Point (PEP), which reuses claims exposed with the service invocation made by the access requester. Therefore, the requests and responses handled by the PDP must be converted in a canonical form, i.e. the so-called XACML context. The obvious benefit of this approach is that policies may be written and analyzed independently of the specific environment in which they have to be enforced. Allowing access controls to be granted on a granule level for the Primary Care Physician (MIE WC) and Behavioral Health Provider (SMART). Thus, once the PEP receives an access request, it instantiates a new context for handling the corresponding XACML request, which contains the capabilities of the requestor encoded using the language defined by the standard. Then, the context handler sends the XACML request to the PDP. The authorization decision is made by the PDP by checking the matching between values of the request and values from the stored policies. To carry out the decision request evaluation, the PDP can combine the evaluation results of more policies or requests for new attributes to the Policy Information Point. These requests are performed by using SAML attribute queries. Attributes are related to the subjects (e.g., additional information on the entity based on the context) to the resource, and to the environment (e.g., the current date time). Attributes are collected by the context handler and sent back to the PDP. Then, the decision is encoded into a XACML decision statement and sent to the context handler that, in its own turn, converts it into the native response format of the PEP and sends the resulting response to it. The decision taken by the PDP can be one among permit, deny, not applicable and indeterminate. The objective once more will be to enforce Policy written by a Patient and enforced at the Point of care during the retrieval of C32 / CCD identifying specific data segments to be included or excluded from the overall structured C32 document. 4

6 Implementation of the C2S Patient Consents The patients will only have their clinical data shared via the HIE, if they consent to have their data shared. Then, if the document is needed, an authorized office will be able to query the document repository to retrieve their structured C32 document. The Client actor indicates to the Server actor the usage of an access control policy (an XACML Policy ID) that gives permission for accessing the resource specified in the SOAP message containing the NHIN-defined SAML assertion. This procedure would require that the policy IDs must be harmonized through the entire affinity domain/community. The Server actor may take additional access control decisions: the authorization decision statement has to be considered as an indication given from the Client to the Server actor. This would specify that a document indicating the patient s consent be stored in the XDS repository. This document includes a Patient Policy Identifier that indicates the consent policy the patient has selected. Consent Document can be published with the C32 allowing for the Patient Policy Identifier contained in the Consent Document to be used to reference the XACML policy representing the technical representation of the patient's consent. The Consent Document CDA document has a field that can contain a list of policy-ids that the patient endorsed in the C2S Application. Lessons Learned Technology serves as a benefit to the healthcare community however it must fit within either already established workflows or with slightly modified workflows so that the technology is not a hindrance to users. The Health Department has care teams that are responsible for the treatment of an individual, and the path to care begins with the behavioral health treatment facility. The individual may have to see a behavioral health specialist two to three times to collect all required information prior to a referral to a Primary Care Provider. Therefore the completed clinical document that was made available for segmentation and sharing should be made available upon proper review of the specialist after a period of time. The care providers that are able to access this document are a team that shares in the care not just a single provider. We had to adjust our plans for deployment in accordance with the treatment methodology followed by Prince George s County Health Department. We as a team readjusted the technology to best fit what happens in a real world scenario by remaining agile in our approach, keeping in constant communication with our client, and having the right stakeholder and decision makers at the table when needed. Moving Forward The Consent2Share application is currently running in production at Prince George s County Health Department. The Health Department is 5

7 participating in an initiative called Health Enterprise Zone (HEZ). The HEZ is a four year program with a budget of 4 million dollars administered by the Community Health Resources (CHRC) and Maryland Department of Mental Hygiene (DHMH). The purpose of the programs is to Reduce health disparities among racial and ethnic minority populations and among geographic areas Improve health care access and health outcomes in underserved communities Reduce health care costs and hospital admissions and re-admissions Our immediate next steps are to expand the C2S pilot to healthcare organization involved within this initiative. We ensured our technology was both scalable and cost effectively so that cost and complexity were not a barrier to adoption. We are now in the process of connecting Providers to the C2S driven infrastructure for those Providers working with sensitive health information. We will also continue to gather feedback from all user types to enhance user experience and make necessary improvements. 6

8 7 Special Thanks: Consent2Share Prince George County Health Department Electronic Health Network Inc.