FHIR Granular Sensitive Data Segmentation

Abstract

Background  Due to fear of stigma, patients want more control over the sharing of sensitive medical records. The Substance Abuse and Mental Health Administration (SAMHSA) and the Office of the National Coordinator (ONC) supported the development of standards-compliant, consent-respecting medical record exchange technology using metadata labeling (e.g., substance use information). Existing technologies must be updated with newer standards and support more than binary-sensitive categorizations to better align with how physicians categorize sensitive medical records.

Objectives  Our goal was to deploy, pilot test, and share open-source Fast Healthcare Interoperability Resources (FHIR)-based data segmentation technologies. We pilot-tested the technologies using real-world patient electronic health record data in the context of substance use information. We involved physicians in designing a novel decision engine that supports various confidence levels.

Results  We deployed a web-based Patient Portal and Clinical Decision Support (CDS) granular data segmentation Engine to allow patients to make consent-based granular data choices (e.g., not sharing substance use medical records). Compared with previous solutions, the Engine innovates by using the latest Health Level 7 (HL7) standards to support data sensitivity labeling and redaction: FHIR R5 and its Consent resource type and CDS Hooks. It also supports configurable floating point confidence threshold cutoffs as opposed to binary medical record categorizations. Multiple engineering choices were made to simplify software development and maintenance and to improve technology adaptability, reusability, and scalability.

Conclusion  The resulting data segmentation technologies update SAMHSA and ONC software with the newest HL7 standards and better mimic how physicians categorize sensitive medical information with various confidence levels. To support reusability, we shared the resulting open-source code through the HL7 FHIR Foundry.

Background and Significance

The granular control of patient data by patients is often discussed but not generally available. A patient's medical record may contain information perceived as sensitive or private. 1 For individuals with sensitive medical information stigma and discrimination are reasons for not sharing data. 2 3 Soni et al systematic literature review on data sharing willingness and perceptions of data sensitivity found that the type and sensitivity of the health information, the type of data recipient, and the purpose of data use may influence subjects' attitudes toward sharing medical data. 4 Subjects were less willing to share highly personal information, such as sensitive information about sexually transmitted diseases, abortions and infertility, family medical history/genetic disorders, mental illness, drug-/alcohol-related incidents, operations/procedures/dates, and current medications.

Granular control has been proposed to empower patients to decide who has access to what types of medical information and for what purpose. 4 The Office of the National Coordinator for Health Information Technology (ONC) defines granular control as: “… a detailed choice an individual makes to share specific types of health data.” 5 Granular control permits patients to choose categories of health information to share and has been supported by various federal and state laws. 6 For instance, 42 CFR Part 2 is a federal law that allows for confidentiality protection of patient records generated by federally assisted treatment programs for substance use disorders. 7

The 2023 systematic literature review on willingness to share personal information by Benevento et al revealed that both the general population and patients are more willing to share their nonpsychiatric medical information than psychiatric information. 8 Individuals with mental illness have demonstrated a greater willingness to share their medical records, even when it involves revealing their psychiatric condition. Although stigma around mental health may create hesitation, the perceived benefits of sharing information often outweigh the uncertainty for many psychiatric patients. Benevento et al also found that cancer patients are more inclined to share their genetic and medical information, as opposed to personal or identity-related details. This willingness among cancer survivors is often driven by the altruistic belief that sharing their data could help others.

The Consent2Share (C2S) project, sponsored by the Substance Abuse and Mental Health Administration (SAMHSA), supports granular patient control through data segmentation of electronic health records (EHR). 9 C2S is based on the ONC Data Segmentation for Privacy (DS4P) 10 specification. DS4P enables tagging sensitive health information in EHRs to ensure compliance with privacy laws and facilitate secure data exchange. C2S segments sensitive EHR data codified in Health Level 7 (HL7) Fast Healthcare Interoperability Resources (FHIR) Standard for Trial Use (STU) 3. 11 C2S relies on SAMHSA sensitive value sets (e.g., substance use) created in 2016. 12 The value sets are lists of concepts (e.g., opiates screen, urine) codified in terminologies [e.g., code 19301-1 from code system LOINC]) and FHIR security labels (e.g., Substance Use data are highly sensitive). 13

Karway et al pilot tested C2S with 199 English- and Spanish-speaking patients with behavioral health conditions and patient guardians. 14 All participants desired granular control over the sharing of their health data. Most participants (87%) were highly interested in using a tool that offered granular options for executing data sharing decisions, with over half (55%) indicating that being able to specify the data type, data recipient, and data use purpose made them more willing to share their medical records. The majority (87%) also reported that knowing the purpose of data use made them more comfortable in sharing. Grando et al evaluated the accuracy of C2S to support granular data segmentation using real patient EHR data. They found significant differences between sensitivity classifications by C2S and providers (χ2 (2, N  = 584) = 114.74, p  < 0.0001). 15 Reasons for low accuracy included lack of engagement of physicians in developing the value sets and binary categorizations instead of “maybe” categorizations (e.g., “alcohol screen (negative)” may be substance use information) and obsolete value sets.

The ONC Leading Edge Acceleration Projects (LEAP) Computable Consent Project 16 builds on C2S to support granular data segmentation of FHIR specification of EHRs. The ONC LEAP project is based on SAMHSA value sets, FHIR security labels, the HL7 DS4P standard, and the FHIR R4 Consent resource. The ONC LEAP project incorporates the HL7 FHIR CDS Hooks protocol, 17 a functionality not implemented in all EHRs. The ONC LEAP consent engine was pilot-tested using FHIR synthetic patient data, and it has been released as open-source code.

The ONC LEAP Project informs the 5-year (2023–2028) National Institute on Drug Abuse (NIDA) grant on Substance use Health REcord Sharing (SHARES). 18 SHARES aims to improve care for individuals with substance use disorders while balancing their data privacy needs. This paper describes the SHARES technology stack we developed to support patients' need to control provider's access to their sensitive medical records. The proposed data segment technology innovates by deploying and pilot testing a decision engine that utilizes configurable floating point confidence threshold cutoffs (i.e., indeterminate sensitivity categorizations) as opposed to binary medical record categorizations. The proposed solutions also incorporate the latest HL7 standards: FHIR and its Consent Resource and CDS Hooks. We used deidentified patient EHR data and engaged physicians in pilot testing the technologies. While we selected substance use information as a use case, the proposed technologies make no assumption on the types of sensitive medical records and are generalizable to other sensitive data types.

Materials and Methods

Access to Patient Medical Records

For a previous study, we obtained approval (approval no.: 00006227) from the Arizona State University Review Board to ask 36 adult patients, 21 years old or older, for written consent to access their EHR data for research. 15 The study participants received care from two integrated community-based health clinics (physical and behavioral health) and consented to give access to their deidentified EHR data for research.

We randomly selected a patient from all the study participants who had substance use medical records, to align with the priorities of the NIDA, the funding source. A researcher, supervised by a physician, selected a subset of data items codified in clinical terminologies that comprised allergies, demographics, diagnoses, family history, laboratories, medications, procedures/services, and social history.

Modeling of FHIR Patient Electronic Health Data

We used clinFHIR, 19 an open-source tool that provides an environment for developers to create and visualize FHIR-based resources. The clinFHIR GraphBuilder 2 module was used to map the patient's EHR data items into FHIR R5. ClinFHIR only supports SNOMED CT and LOINC terminologies, which limited our mapping. Following best practices, two independent reviewers (M.K. and A.G.) with clinical informatics and computer science training, respectively, checked the resulting terminology mapping to assess accuracy. These reviewers were different from the ones who created the confidence level rules (D.M. and P.L.). Disagreements were resolved by consensus.

We exported the resulting FHIR bundle to a third researcher (D.M.) who verified that the file contained all the patient data resources and imported them into an open-source HAPI FHIR server running in R5 mode. 20 We use this HAPI FHIR server as a stand-in for future real-world EHR systems exposing consent and patient data resources via FHIR.

Creation of Value Sets

Two physicians with addiction medicine specialty independently completed an online survey using Qualtrics. 21 The survey asked them to categorize the 48 data items as (1) Substance use information, (2) Maybe substance use information, or (3) Not substance use information. We provided the National Center for Health Statistics definitions for substance use, including alcohol use and opioid use, in the survey. 22

We exported Qualtrics survey data as an Excel sheet and wrote an algorithm in Python that takes each data item and, for each category, computes a floating point confidence value that the item belongs in that category (such as substance use information) based on the formula confidence =  ( a +  ( b*0.5 ))/ n , where: a is the number of times that the item was categorized as substance use information, b is the number of times it was categorized as may be substance use information, and n is the total number of times the item was presented for categorization.

Creation of Data Segmentation Rules

With a complete set of physician opinion-backed confidence values, we integrated them back into the original spreadsheet to create a master set of code–category–confidence tuples. The JSON 23 rules essentially define the confidence levels for a data item from the patient's EHR to be classified into the data category defined by the tuple.

Neither the rules nor our CDS service prescribe any semantic or restriction on what “confidence” means other than it must be a floating-point number. This permits unmodified use of the entire SHARES stack with a completely different set of confidence values defined by alternate algorithms. In our case, we configured the CDS engine to affirm a given data item classification into a given category if its coded data matches any defined terms with a confidence level of 0.5 or greater. Since many terms apply to a category, the “high water mark” 24 for matching can be hit by any term within that category of sufficient confidence value. The rules can be adjusted to be more sensitive or less depending on the desired sensitivity/specificity characteristics.

Deployment and Testing of the Granular Data Segmentation Technology

We developed granular consent technology using TypeScript. 25 Patients use the tool to provide granular consent and providers manage consent rules to control data segmentation ( Fig. 1 ).

Fig. 1.

Components of the FHIR-based granular consent technology, including Patient Portal, Consent Repository, Clinical Decision Support (CDS) Engine, JSON Decision Rules, and Value Sets. FHIR, Fast Healthcare Interoperability Resources.

Using the standalone web-based SHARES Patient Portal, an individual logs in. The portal allows them to choose whom they share their information with, what they will share, for what purpose, and for how long. We aim to distill most of the complexity of R5 Consent creation to a minimal number of patient-friendly fields while retaining most of the power and flexibility. Regarding what to share, we adopted the following 11 sensitive data categories: demographics, diagnoses, disabilities, genetics, infectious diseases, medications, sexual and reproductive health, social determinants of health, substance use, mental health, and violence. The Eluru et al study reported the result of physicians' recommendations for adapting and refining the existing HL7 sensitivity categories. 26 Regarding whom they can share with, the tool currently supports the options of sharing with an organization as a whole and will be updated to support the search and selection of specific providers within an organization. For data types to be shared, the supported options are sharing all information without exception, sharing no information, and customizing sharing settings to information categorized in 11 sensitive data categories. On-demand educational material, developed by Eluru et al 26 is provided in each category. The tool is set up by default to share data for 1 year, but the user can change the applicable time frame or remove it completely.

When a granular consent is electronically signed, it is automatically converted to a FHIR R5-compliant consent resource and saved to the EHR (HAPI FHIR in our case), where it is stored. With patient-directed consent in the system and under provider management, the EHR—or any other client system, for that matter—may invoke the CDS engine for labeling and/or redaction purposes. We provided a CDS Hook-based entry point via a new “patient-consent-consult” hook, 27 as the ONC LEAP consent engine previously did as an easy invocation pattern familiar to the CDS community. At such time a patient's medical record is to be shared across the organizational trust boundary, the pertinent records are converted into an FHIR bundle and sent (via CDS Hooks protocol) to the SHARES Engine that labels and/or redacts sensitive information from the records based on the patient's consent choices and engine approach.

The sensitive labeling is based on the terminology confidence ratings supplied to the CDS engine and the sensitivity threshold provided by the invoking client (or ≥ 0.5 by default). If the item from the patient's EHR matches a particular coded value with a score above 0.5 for a given data category, for example, the engine considers this sensitive for only that specific data category. When the FHIR resource is identified as sensitive based on the value set confidence rules, the SHARES Engine labels each item as sensitive for possible redaction.

The SHARES Engine returns a CDS Hooks-compliant response with a fully redacted data payload—or according to the client application's override parameters—to the invoking client, whether in the patient portal, EHR, or other application.

Results

Patient Medical Records

For the selected patient use case, the main diagnosis was a history of generalized anxiety disorder. This medical record contains 1 procedure/service, 2 demographic data items, 4 allergies, 5 family history data items, 5 social history data items, 8 laboratory results, 8 medications, and 15 diagnoses ( Fig. 2 ). For 40 (83.3%) data items in the patient her, we found a direct mapping to SNOMED CT and LOINC code systems, as required by the ClinFHIR tool. ( Supplementary Appendix 1 , available in the online version) for the list of eight concepts for which concept mapping required finding the closest option. An example of a data item for which no direct mapping was present, and consensus was needed is “domestic altercation.” This item was mapped in SNOMED CT as “domestic violence.”

Fig. 2.

List of 48 data items (concept, resource type, coding standard, and code) from the selected patient's medical records (data presented in the figure are imaginary).

FHIR Patient Medical Records

Supplementary Appendix 2 (available in the online version) provides the FHIR bundle we manually created for the patient use case. 28 It consists of 1 Procedure resource, 3 Patient resources, 4 AllergyIntolerance resources, 5 FamilyMemberHistory resources, 8 MedicationStatement resources, 11 Observation resources, and 16 Condition resources. As an example, Fig. 3 depicts the FHIR specification of the data item corresponding to a positive opioid test result. It was modeled as a FHIR Observation resource of Laboratory type.

Fig. 3.

Visual representation of the FHIR specification of “Opiates screen, urine (positive).” FHIR, Fast Healthcare Interoperability Resources (data presented in the figure are imaginary).

Substance Use Information Value Set

Using the categorizations from two physicians, we automatically assigned an aggregated confidence level to each data item of the patient's medical record ( Fig. 2 ) for being considered substance use information. As Table 1 shows, 10 data items met the default minimum sensitive confidence level (≥0.5), consisting of one item with a confidence level of 1, five items with a confidence level of 0.75, and four items with a confidence level of 0.5 ( Table 1 ).

Table 1. The confidence level of data items that meet the default minimum sensitive confidence level (≥0.5) to be considered substance use information.

Data item	Confidence level	Substance use information	Maybe substance use information	Not substance use information
Methamphetamine intoxication	1	2	0	0
Family history-alcohol abuse	0.75	1	1	0
Family history-drug abuse	0.75	1	1	0
Methadone [presence] in urine by screen method	0.75	1	1	0
Morphine, long lasting other	0.75	1	1	0
Opiates screen, urine (positive)	0.75	1	1	0
Alcohol screening (negative)	0.5	1	0	1
History of domestic altercation	0.5	0	2	0
Hydrocodone bitartrate 5 mg and paracetamol 325 mg oral tablet	0.5	0	2	0
Estazolam 1 mg oral tablet	0.5	0	2	0

Data Segmentation Rules

The outcomes of Table 1 were used to code the corresponding JSON data segmentation rules automatically. For instance, Fig. 4 shows the JSON rule for the data item “Opiates screen, urine (positive)” with a confidence level of 0.75.

Fig. 4.

The rule labels a data item as sensitive and redacts it if its confidence is greater than a given threshold.

In addition, we created data segmentation rules to identify all the active consents and to resolve conflicts between consent choices within the same consent or multiple active consents. By defect, the data segmentation rules maximize data privacy. For instance, if an individual chooses to share mental health information but not violence information, then the data item “Encounter for mental health services for victim of spousal or partner abuse” (listed under both mental health and violence value sets) will not be shared.

Granular Data Segmentation Technology

Fig. 5 shows the resulting Patient Portal interface. In this proof of concept, the patient chooses not to share their substance use information for treatment and care for 1 year with a health care organization and, therefore, all the providers working at that organization. In the process of providing consent, the patient can request on-demand educational material on what constitutes substance use information and preview what substance use information would be removed from their medical record. Finally, an electronic signature is provided.

Fig. 5.

SHARES Patient Portal, which allows selecting which medical records to share, with whom, for what purpose, and for how long. A preview of the medical records that will not be shared is available on demand (data presented in the figure are imaginary). SHARES, Substance use Health REcord Sharing.

Then, the Patient Portal, future EHR system, or other client-requiring data labeling triggers the CDS Hook “patient-consent-consult” with the patient's EHR codified as an FHIR bundle. Fig. 6 depicts part of a patient bundle submitted to the CDS Hook. After the SHARES Engine executes, the CDS Hook returns the segmented FHIR bundle where the data items considered substance use information ( Table 1 ) have been removed ( Supplementary Appendix 3 (available in the online version) 28 ). The data item “Opiates screen, urine (positive)” was labeled as substance use information and redacted.

Fig. 6.

Visual representation of the CDS Hook being sent to the CDS engine. CDS, Clinical Decision Support.

Discussion

The main outcome of this study was the deployment and pilot testing of a granular consent technology to segment sensitive medical records in compliance with patient's data privacy preferences. Below, we discuss the proposed technology's strengths and limitations, future areas of research, and policy impact.

Strengths

SHARES technological approach operates several steps ahead of 2024 technology (see Table 2 for a comparison with SAMHSA and ONC solutions). Significant differences and innovations include:

Table 2. Comparison of technology and features supported by open-source granular consent technologies.

	SAMHSA Consent2Share	ONC LEAP Computable Consent Project	NIDA SHARES
Newer FHIR version	STU3	R4	R5/R6 (target), some R4
Software simplification	Java, JavaScript	Java, JavaScript	TypeScript (JavaScript) for both server and client
Invocation and integration	Heavyweight Backend, UI,	CDS Hooks only	CDS Hooks, UI clients, reusable core library
Software sharing	GitHub, Docker Hub	GitHub	GitHub, Docker Hub, HL7 FHIR Foundry, NPMjs
Segmentation rules	Binary	Binary	Confidence-based floating point

Abbreviations: FHIR, Fast Healthcare Interoperability Resources; LEAP, Leading Edge Acceleration Projects; NIDA, National Institute on Drug Abuse; ONC, Office of the National Coordinator; SAMHSA, Substance Abuse and Mental Health Administration.

• Major focus on the future of US FHIR: at project initiation, we made a difficult but practical long-term decision to use FHIR R5, as opposed to R4, for several significant reasons. First, the consent model in FHIR R4 is very immature and makes simplifying assumptions poorly aligned with use cases of Consent directives affecting multiple providers and organizations, among other major issues. Second, the more generalized consent model in FHIR R5 and the current R6 draft is likely to resemble the to-be-balloted (and much more robust) final model in R6. R6 is far more aligned with the 42 CFR Part 2 final rule taking effect in 2026, and broadly expected to trickle into U.S. regulatory policy in the subsequent. 7 We are focusing on what is likely to be necessary to meet critical-path regulatory and practical requirements, as opposed to operating under the constraints of what was available at the time R4 was published in 2019. We are further being mindful to align with the HL7 Consent Management implementation guide, as well as broader updates to the United States Core Data for Interoperability 29 and U.S. Core profiles.

• Software Simplification: unlike prior ONC LEAP and C2S projects, we have developed all major components using TypeScript 25 : a statically typed language that compiles to JavaScript and works for both server-side and client-side applications. This major unifying simplification eliminates the need in prior projects to redundantly write code necessary for backend written with Java and a frontend constrained to support JavaScript: a completely different language. This greatly improves the ease of programming and debugging with statically typed frontend user interface (UI) applications and enables the extraction of common code to a core library reusable in all SHARES tools that do not need to be maintained in multiple languages simultaneously.

• Invocation and integration: the SHARES CDS engine uses a pluggable concept sensitivity configuration file format that may be updated dynamically—even while running—via either Application Programming Interface (API) or with the web-based, optional SHARES rules editor. Unlike LEAP, this approach enables less technical users to tweak concept sensitivity configurations and FHIR value set matching behavior using a web UI, as well as modify the DS4P security labels that are applied to work in operating environments different from SHARES. Additionally, we designed our CDS engine to support custom HTTP request headers that the invoking client may optionally set to override default engine behaviors ( Table 3 ) on a per-request basis. To provide a path forward for those familiar with LEAP, we built our implementation of the CDS Hooks “patient-consent-consult” type, which may be integrated with existing CDS Hooks clients that support extension to new hook types.

• Segmentation rules: one of the biggest functional differences of the SHARES engine is the philosophical change from binary classification to confidence-based determinations based on rule-provided floating-point values and client-provided cutoffs. The rules engine generates FHIR security labels with determinations of relative certainty, as opposed to strict is/is not classifications. This method allows clients to provide their cutoff values at the per-invocation level based on the desired degree of sensitivity or specificity. This flexibility more closely aligns with our clinician observations that, in our research, typically do not express classification views with absolute certainty.

• Software sharing: we developed all software components openly under the Apache 2.0 license. Our code is available through GitHub repositories. 30 This includes the CDS Hooks-based reference implementation, all UI projects, and the common code library used across SHARES tools. To entice future collaboration, particularly with agencies and the standards community, we have further deployed a fully automated continuous integration (CI) build system using the open-source DroneCI 31 software to create and publish prebuilt containerized multiarchitecture software images for x64 and ARM64 CPU architectures. These turnkey images may be run directly using popular container runtimes such as Docker 32 and Podman 33 and deployed using Docker or any Kubernetes 34 variant to local computers or cloud environments without compiling from source. In collaboration with HL7, SHARES was featured at FHIR DevDays 2024 as the first CDS Hooks-based solution to be published and distributed through the HL7 FHIR Foundry. 35 The FHIR Foundry is an open ecosystem platform for discovering, testing, trying, and installing working reference implementations of the HL7 specifications. The goal of this platform is to support community engagement and adoption. We are now working with the HL7 FHIR at Scale Taskforce (FAST) to maximize this impact and continue directly impacting the FHIR specification and have further shared the deidentified patient records as FHIR R5 resource bundles, sample rule sets, and invocation examples as open-source code through the HL7 FHIR Foundry platform.

Table 3. HTTP request headers to support for overriding Substance use Health REcord Sharing Clinical Decision Support engine behaviors.

Header	Default value	Purpose
CDS-confidence-threshold	0.5	Allows the client to specify a more/less sensitive confidence value for sensitive labeling classifications. Must be a floating point value, but the semantic of the value is dependent on the rules files loaded by the engine
CDS-redaction-enabled	True	Causes resources with sensitivity labeling to be removed from the resultant patient data. Set to false to return labeled data without redaction

Abbreviation: CDS, Clinical Decision Support.

These combined qualities have resulted in a highly innovative and modular data segmentation platform stack. A preconfiguration of the “SHARES Full Stack” software was the CDS use case presented by Dr. Preston Lee for the 2024 Agency for Healthcare Research and Quality (AHRQ) Clinical Decision Support (CDS) Connect Challenge, 36 which was selected as the award winner for Most Innovative Solution. The AHRQ two-phase selection process included a report submission and a 60-minute live presentation and Q&A session. The evaluation process included an assessment of how the proposed solutions would: (1) facilitate widespread incorporation of interoperable CDS into practice, (2) bring value to clinicians, patients, and CDS developers, (3) support and grow CDS innovation, and (4) facilitate collaboration to allow future sustainability and evolution ( Tables 2 and 3 ).

Limitations

The pilot validation of the consent engine is limited to the medical record data from one patient. While this is a limited dataset and therefore conclusive inferences cannot be made. Nevertheless, valuable lessons were learned in terms of mapping to the FHIR specification and physician's data sensitivity perceptions.

While functional, SHARES CDS engine's default internal sensitivity classification algorithm is currently naive in its ability to apply category-code-confidence determinations. Namely, the engine does not consider contextual knowledge surrounding the external purpose of its invocation. Although there is evidence that the presence or absence of internal correlations may affect a human's assessment of whether a concept should or should not be deemed “sensitive,” the engine does not consider them. 15 30 The rules are further applied regardless of extenuating circumstances such as “break the glass” contexts; however, the engine's ability to disable bundle redaction via HTTP request headers supports this use case with a single flag.

The default algorithm is further limited to only supporting extensional value sets. That is, the engine can only process structured data coded to concepts that explicitly appear in the engine's rules file under one or more categories and confidence values. While the pros/cons of this approach are debatable, the engine does not currently attempt to expand coded concepts in the file within its native code system, nor does it attempt to perform subsumptive or inferential operations on concepts present in the provided patient data payload. This would need to be performantly addressed in real-world use by accounting for the natively hierarchical nature of some code systems such as SNOMED CT in rule set management via caching, static value set expansion, or other mechanisms.

Our engine's invocation mechanism relies on the CDS Hooks protocol as the ONC LEAP consent project previously demonstrated; we intentionally use the same “patient-consent-consult” hook type to retain semantic coherence with that prior work. The “patient-consent-consult” hook type is not, however, recognized via any formal specification and, thus, extremely unlikely to be implemented by EHR vendors as-is. It is, however, referenced in Supplementary Appendix 3 (available in the online version) of the “HL7 Service Functional Model: Consent Management Service, Release 1” STU. 35

Our method is highly oriented around coded data; we do not currently support unstructured or semi-structured data, such as clinical notes, unless preprocessed through a natural language processing (NLP), artificial intelligence (AI)/machine learning (ML), or another workflow to codify identifiable elements to the code systems recognized by the SHARES Engine's active rules file.

The proposed solution assumes the adoption of the FHIR standards. As of 2019, 84% of hospitals and 61% of clinicians adopted and implemented 2015 Edition certified API technology enabled with FHIR. 36 Financial investment is a challenge in FHIR adoption and may limit the applicability of the proposed solution in low-resource clinical environments.

Future Work

Addressing limitations of our extensional value set data will be key in improving real-world engine performance, as is establishing an objective baseline performance measure for the use cases related to substance use medical data. Ongoing refinement of the underlying value sets established in the rules file used by the CDS engine, accommodation of intentional-style algorithmic behavior, and expansion of code systems beyond those currently implemented are critical to supporting more accurate classification of data element sensitivities. AI methods, as opposed to the manual technique used by SAMHSA and in this study to create sensitivity value sets, offer the promise to automatically or semi-automatically determine the sensitivity of health data with levels of confidence. The technology that we proposed will be able to accommodate nonbinary categorizations resulting from AI methods. 31 Incremental formal evaluation and establishment of quantified accuracy benchmarks will be key activities underpinning future phases of our investigation and method effectiveness.

Of the various components of the SHARES stack, the patient portal is the most directly meaningful to patient stakeholders. We intend to extend our formal evaluations into the user experience (UX) realm via UX studies and expect to iterate extensively to produce the most usable patient-facing means of Consent declaration and management. The Patient Portal, as C2S and the ONC LEAP engine, allows the selection of health care organizations and individual health care providers. While R5′s Consent allows for multiple providers to be selected, it is ambiguous how a tool such as the Patient Portal should find those providers since their FHIR Practitioner records are likely not present in the same FHIR server being used for Consent management. We are investigating the possible use of the FAST National Healthcare Directory IG 32 as a practical solution for discovering external providers unaffiliated with the organization stewarding patient Consent directives.

For the Patient Portal, we represent each of the supported 11 data sensitivity categories as an existing FHIR ActCode, 33 such as “ETH” for the “Substance Use” category internally. Note that categories such as substance use have multiple other possibly more appropriate codes, such as “42CFRPart2,” so additional precoordination across trust boundaries will be required in future iterations.

We plan to conduct the formal evaluation of the granular data segmentation engine with a large set of synthetic FHIR medical records created with Synthea. 34 Manual mapping of patient medical records to ClinFHIR, as it was done for this study, will not be needed. On the other hand, a substance use information value set will need to be created to segment this information.

Policy Impact

Research to inform substance use disorder data sharing is needed. 29 Between 2012 and 2015, 114 interviews with Oregon stakeholders probed the behavioral health integration processes into primary care settings and assessed substance use data sharing issues. A follow-up study reported the outcomes from 27 semi-structured interviews with stakeholders from 14 integrated health care organizations within the National Drug Abuse Treatment Clinical Trials Network. 37 Both studies concluded substance use data sharing policies and laws, including 42 CFR Part 2, were a source of legal confusion and inhibited communication and information sharing in integrated care environments. Substance use health data segmenting was mostly done manually, making it time-consuming and error-prone. Integrated health plans used workarounds to manage intrainstitutional communications, care coordination, and varied interpretations of substance use data sharing policies.

The standard-based, granular data segmentation technology that we proposed has the potential to address the identified issues by providing automatic, physician-validated, uniformly interpretable, and EHR-vendor agnostic strategies to support substance health data segmentation.

Conclusion

Building on previous open-source and standard-based work supported by SAMHSA and ONC to segment sensitive medical records, we deployed a more up-to-date (e.g., FHIR R5), deployable (e.g., DroneCI/Docker), and flexible (e.g., pluggable rules files supporting different concept sensitivity category confidence levels) granular consent engine. Most importantly, we used real patient data and involved physicians to demonstrate segmentation of substance use information. The proposed technology framework has the potential to support substance health data segmentation compliant with federal policies and laws including the 42 CFR Part 2 final rule.

Clinical Relevance Statement

Health care organizations can apply the shared open-source, standards-based code to implement patient-controlled granular medical record sharing.

Multiple-Choice Questions

1. Which federal organizations have funded the previous technologies to support patient-control granular medical record sharing? Select all that apply

   1. Substance Abuse and Mental Health Services Administration (SAMHSA)

   2. Office of the National Coordinator for Health Information Technology (ONC)

   3. National Library of Medicine (NLP)

   Correct Answer : The correct answer is options a and b. SAMHSA has funded the development of the Consent2Share tool and ONC has supported the development of the Leading Edge Acceleration Projects (LEAP) Computable Consent Project

2. Which HL7 standards is the new granular consent technology built on? Select all that apply

   1. Clinical Document Architecture (CDA)

   2. Fast Healthcare Interoperability Resources (FHIR)

   3. CDS Hooks

   4. United States Core Data for Interoperability (USCDI)

   Correct Answer : The correct answer is options b, c, and d. The SHARES Consent Engine uses FHIR R5 and CDS Hooks to support granular sensitive data segmentation, and the engine itself is generally compatible with the R4-based FHIR resources of US Core: HL7's Implementation Guide providing compliance with USCDI.

Funding Statement

Funding This research was funded by the National Institute on Drug Abuse, through the Substance Use HeAlth REcords Sharing (SHARES) grant (grant no.: 9R01DA056984-06A1).