Background and Significance
We have entered a digital age in which electronic protected health information (ePHI)
is becoming accessible and shareable for all patients. Increased patient access to
ePHI promotes health care autonomy, improved access to providers, control over personal
health information, and is now mandated by the U.S. federal 21st Century Cures Act Final Rule.[1] However, this access to health information raises unique privacy concerns for adolescent
patients.[2]
Age of Adolescence
Adolescence is a time of exploration and discovering a sense of self apart from parental
influence. Adolescence is also a time of increased needs for reproductive, mental,
and behavioral health.[3]
[4]
[5] Multiple studies have found that adolescents will not seek needed health care for
issues such as mental health, reproductive health, and intimate partner violence if
they fear that related sensitive information will be shared with parents or guardians.[6]
[7]
[8]
[9]
[10]
[11]
It is essential that adolescents are ensured a private, protected relationship with
health care providers, a relationship secured by law in most states. The beliefs and
attitudes an adolescent develops during this time regarding one's ability to trust
clinicians and the health care system may follow them for the rest of their life.
Also, recent state and federal policies have created exigency on the protection of
sensitive health data in the electronic health record (her), including legislation
related to reproductive and gender-affirming care.
Adolescent Privacy Protection in the Electronic Health Record
Protecting adolescent privacy in therEHR has unique challenges.[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24] Varying privacy and confidentiality laws add complexity to interstate health information
exchange (HIE). These laws vary by minors' age, type of care, and context. It is imperative
to communicate limitations in privacy protection to adolescents and their parents,
who are often unaware of the implications of shared sensitive health information.[17]
[25]
[26]
[27]
[28]
[29]
[30] Health care providers encourage adolescents to share sensitive information and thus
must find ways to prevent unintended information disclosures. Strategies, such as
separate adolescent and parental proxy portal accounts, have been established to help
protect this information.[31] However, portal privacy policies vary widely and have limited protection against
parental access to adolescent accounts.[32]
[33]
[34]
[35]
[36]
[37] Research across three children's hospitals reported that 64% of adolescent accounts
had been accessed by a parent, presenting an additional barrier to privacy protection.[32]
All 50 states afford varying degrees of adolescent confidentiality for certain types
of care (usually substance use, reproductive, and mental health), though there is
significant variability in confidentiality limitations and portal policies.[38] At the onset of adolescence, many health systems provide portal access to the patient
and move the parent/guardian to a proxy account. When provisioning proxy access, some
health systems limit proxy account information to a small subset of health information
and allow full access to the adolescent. Other institutions avoid the risk of inadvertent
disclosure by allowing the patient and proxy account to access only limited nonsensitive
health information. At the age of majority, young adults gain full access and the
proxy access must be removed.
These portal access shifts present a challenging workflow for most health IT platforms.
With significant effort and clinical informatics resourcing, health systems may be
able to structure limited granular segmentation of data that cross to different portal
users. However, this is institution-specific and cannot be leveraged for interoperability.
The limitation of standards and lack of implementation guidance render this build
complex and resource-intensive, so it remains a limited alternative.[39] Similar considerations exist for digital health platforms targeted to teens.
Sensitive Data
What is “sensitive” to one individual may not be sensitive to another. Based on federal
and state law, information related to reproductive health (sexually transmitted infections,
pregnancy, and genetic information), sexual orientation, behavioral health, and substance
use are commonly considered “sensitive.” However, other data may be considered sensitive
in certain contexts (e.g., an injury for a serious athlete). Some do not regard certain
health data as sensitive and may be offended when others consider it so (for instance,
a proudly gay individual or an advocate for the destigmatization of mental health
conditions). Furthermore, patients may face implicit and explicit biases basheron
EHR information.[40]
[41]
[42]
[43]
[44]
[45]
[46]
[47] Patients may wish to block certain data from being shared, but due to limitations
in segmentation abilities, must share data in an all or none fashion regardless of
platform. Furthermore, requesting that data not be shared through the HIE and the
health system requires a savvy patient and institutional compliance.
Even if agreement is reached around sensitive data elements and deployment of the
necessary technical capabilities, unaddressed usability questions such as how patients
request withholding of data, what informed consent would involve and how it would
apply to adolescents, and how clinical systems would operate under redaction or obfuscation
and interact with other systems (e.g., decision support) remain. For the portal, in
particular, questions exist about whether and how proxies would know (or not know)
that data are present but redacted.
Equitable Interoperability
The ability to share medical records seamlessly among health care providers has been
a goal over the past decade. However, as health information becomes more readily shared
between health care systems and clinicians, numerous complexities arise. For example,
a patient may not want sensitive information, such as a prior abortion, readily shared
with their allergist. However, there are concerns about potential safety issues if
data redaction blocks view of a patient's full medical history.
Lack of mature standards prevents reliable, consistent granular protection of sensitive
data, leading to information blocking of larger segments of ePHI and inequitable patient
access to health information.[39] This differentially affects vulnerable patient groups with increased needs for sensitive
data protection, such as LGBTQ youth and victims of abuse. Currently, patients without
sensitive data can fully benefit from interoperability, whereas those with sensitive
data may fear doing so, resulting in health inequities. Some organizations resort
to blunt algorithms or manual processes to withhold data sharing for broad populations,
which may result in care inequities and potential information blocking, as patients
with stigmatized conditions may decline to consent to data sharing. As some sensitive
conditions are more prevalent in vulnerable populations (including adolescents) and
historically disenfranchised populations, such concerns contribute to disparities
in care.
Information Blocking
The 21st Century Cures Act Information Blocking Final Rule and the Dobbs v. Jackson Women's Health Organization Supreme Court decision intensified the need to segment and protect sensitive data.[1]
[48] Information blocking is “a practice that is likely to interfere with the access,
exchange or use of electronic health information, except as required by law or specified
in an information blocking exception.”[49]
[50]
[51]
[52] The Dobbs decision heightens the urgency for development of functionality enabling granular
segmentation of reproductive health and pregnancy outcomes data from a broad range
of health care stakeholders, particularly for interstate data sharing.[40]
[41] Lack of granular segmentation standards that accommodate information blocking exceptions
may ultimately result in less information sharing. Implementation of functionality
to comply with information blocking provisions has made privacy concerns a lived reality
for clinical staff, patients, and technology vendors alike.
Methods
Shift
There have been efforts to address these challenges involving the granular segmentation
of sensitive data, but current technical standards to identify and protect sensitive
health data are immature and inconsistent. Although value sets for sensitive terminologies
exist, they are neither comprehensive nor maintained, and fail to identify all sensitive
adolescent health information. Health care providers need more sophisticated functionality
to identify, segment, and protect sensitive ePHI while complying with regulations
and improving general access to ePHI. Other populations besides adolescents (e.g.,
racial, ethnic, and sexual minorities) may experience medical mistrust and implicit
biases if sensitive health information is shared without their knowledge, explicit
consent, and ability to withhold certain data.
Shift, an independent task force for equitable interoperability, was formalized in
2020 to address challenges arising from the need to segment data. The Governing Board
for Shift includes representation from the American Academy of Pediatrics, American
Medical Association, Electronic Health Records Association, Integrating the Healthcare
Enterprise, Drummond Group, AARP, and the Office of the National Coordinator for Health
IT (ONC) as an ex officio member. The Drummond group has been a stakeholder and supporter
of the work of Shift; in this capacity, they are one of several Governing Board organizations
who guide Shift's mission, vision, and deliverables. Also in this capacity, they have
provided in-kind services such as Web site hosting, project management services, and
personnel. Shift (http://www.shiftinterop.org) brings together more than 200 expert stakeholders to tackle these questions through
a consensus-driven approach to advance standards development, implement guidance,
and drive policy.
Brief Review of Existing Work
Shift first explored the work that had already been done in this space to understand
the challenges and opportunities of where existing work could be leveraged and where
new development was needed. To address the need for a national standard to support
tagging of sensitive data for interoperable data sharing, the Data Segmentation for
Privacy (DS4P) HL7 Clinical Document Architecture (CDA) Implementation Guide (IG)
standard was developed in 2011 and accredited by the American National Standards Institute
in 2014.[53(p7)] This IG was primarily developed around data exchange subject to 42 Code of Federal
Regulations (CFR) Part 2 restrictions related to federally funded substance use treatment
programs. The original standard allowed for tagging of Consolidated Clinical Document
Architecture (C-CDA) metadata at the document, section, or entry level to indicate
that the data contained therein was restricted and subject to redisclosure restrictions.
A handful of pilot implementations are described in [Supplementary Table S1] (available in the online version).
Since then, DS4P HL7 version 2.9 and DS4P Fast Healthcare Interoperability Resources
(FHIR) IGs have been developed. DS4P FHIR allows direct labeling of data elements
as sensitive without the dependency of sending the C-CDA document. DS4P has also provided
the data segmentation underpinnings then supported by several consent management platform
tools, which allow a patient or organization to define how they would designate their
data to be shared. Since May 2020, the HL7 Security Work Group has been developing
an evolving FHIR DS4P IG leveraging the HL7 Healthcare Privacy and Security Classification
System for security labeling. Further development of DS4P FHIR implementation guidance
for the use of FHIR security labels based on an expanded set of use cases is needed.
Some EHR vendors have, and continue to, develop vendor-specific functionality that
supports tagging of sensitive data, specifically for release to the portal. These
development efforts accelerated in response to the 21st Century Information Blocking
Final Rule. While this work may benefit some users, some vendor-specific approaches
do not promote interoperability or the ability to share data with established exceptions
across the health care ecosystem.[54]
While DS4P allows for tagging of data to specify its sensitivity, a consent management
platform is then needed to capture patient sharing preferences. Several these have
been developed and piloted, including Consent2Share, an open-source tool developed
by the Substance and Mental Health Services Administration (SAMHSA), which utilized
DS4P CDA. More recently the San Diego Regional HIE Leading Edge Acceleration Projects
(LEAP) project focused on implementation of the FHIR Consent Resource to manage consent
for privacy, medical consent, advance directives, and research, as well as using a
security labeling service.[55]
Although DS4P and various consent management platforms have had successful individual
pilots within a single regional system, implementation of granular segmentation and
consent management to support individual privacy preferences and equitable interoperability
has not scaled nationwide.
Shifting the Approach
After understanding the existing landscape of data segmentation efforts, Shift developed
an approach that was not only narrowly focused on technical standards alone but also
simultaneously considered the usability, implementation, ethics, legal, policy, provider,
and patient considerations as key pillars. Shift identified key leaders and stakeholders
passionate about all of these aspects of the work and then created subworkgroups that
scoped out these challenges described in detail below. The first step involved creating
high-priority use cases that were based on real-world needs that cut across different
age groups, sensitive conditions, and types of data exchange. The adolescent use case
with fictional patient Maritza is depicted in [Fig. 1] with the other use cases summarized in [Fig. 2].
Fig. 1 (Top) Maritza a 16-year-old female visits her primary care physician for a visit
where she and her mother discuss Maritza's worsening asthma for which she is prescribed
an inhaler and referred to a pulmonologist. (Bottom) While Maritza and the primary
care physician talk alone, she shares that she plans to be sexually active and an
oral contraceptive pill (OCP; ethinyl–estradiol–norethindrone) is prescribed. This
order and documentation about it are highlighted in yellow in the diagram (data presented
in this figure are imaginary). EHR, electronic health record.
Fig. 2 Shift use cases. EHR, electronic health record; HIE, health information exchange.
Standards, Terminology, and Technical Challenges
One challenge to moving beyond blunt “all-or-none” information-sharing policies and
toward granular data segmentation is to define specifically which data need to be
segmented. Such effort often begins with legal guidance around broad categories such
as reproductive or mental health, followed by the translation of those concepts into
medical terminology and structured codes needed to automate this work in a standardized
fashion. As a result, individual institutions must create their own list of sensitive
diagnoses, procedures, laboratory results, and vital sign codes that must be regularly
updated. Such efforts require a significant amount of informatics resources that many
institutions lack. Laws defining protected categories of data exist at the broad level
of reproductive health or behavioral health and provide no translation into specific
diagnostic (e.g., the International Classification of Diseases Tenth Revision), procedure
(e.g., Current Procedural Terminology), laboratory (Logical Observation Identifier
Names and Codes), or medication (RxNorm) codes, which has resulted in a patchwork
of nonstandardized lists. The variation in lists of sensitive conditions may render
a condition treated as sensitive at one institution to be treated as not sensitive
at a second institution posttransmission.
This may impact adolescent practitioners when addressing reproductive health concerns
such as contraception. In the adolescent Maritza use case, EHR managers at the primary
care physician's (PCP) health care system would have defined a list of sensitive medications
and included the oral contraceptive pill (OCP) on that list and also defined where
that information would and would not show up in the EHR and portal. However, the EHR
used by the pulmonologist's health system—even if from the same vendor—might be configured
differently, including without a list of sensitive medications ([Fig. 3]).
Fig. 3 The complex interplay of systems and data across multiple electronic health record
systems. While health system 1 (green circle) may have particular policies around
sensitive medications, that information will travel to other systems such as a specialist
provider, pharmacy, or payor who all may have different rules with handling classifications
of sensitivity. EHR, electronic health record; PCP, primary care physician.
Another challenge is to use standardized condition lists to tag sections of the EHR
with the appropriate sensitivity label. This has been done at the time of data transmission
through the C-CDA, but there is increasing exploration of security labeling using
FHIR resources, which would allow tagging of individual data elements within the chart
itself and even potentially the tagging of free text via natural language processing.
Many settings specialized in caring for adolescents may be attuned to the privacy
protection needs of this population and their specific relevant state legislation.
They may set up vendor-specific functionality and train their staff in workflows to
support these protections. However, when an adolescent's data leave the confines of
these settings, protecting their privacy may become more challenging. In the use case,
the PCP's EHR may have defined the OCP as a sensitive medication and may prevent any
sensitive medications from being listed in the medication list of the proxy portal
account. When Maritza's medication list is sent to the pulmonologist's EHR system,
the OCP on the medication list may no longer be marked as sensitive, thereby showing
the OCP in Maritza's medication list on the pulmonologist's portal, where her mother
has proxy access. This issue is partly a technical challenge of EHR structure and
becomes much more of an implementation and usability challenge based on how institutions
build and train clinicians to use EHRs.
Usability and Implementation Challenges
While the technical challenges are myriad, solving them is only part of the work.
Usability, which covers everything from the way patients request sensitive data segmentation
to how clinicians view and interact with segmented data in EHRs, must be taken into
account. This conversation usually starts when patients are first given information
about a health care practice's notice of privacy policy (NPP) and documentation about
the Health Insurance Portability and Accountability Act (HIPAA) and are asked to sign
a document describing how their information will be used and shared. Some of this
process takes place face-to-face, and some preferences may be captured digitally such
as through an eConsent mechanism. The examples discussed here largely focus on provider-based
care, but patients may use self-selected digital health services, which have their
own protocols and usability considerations. When Maritza and her mother first sought
care at the PCP and pulmonologist's office, they would have been asked to review and
agree to the NPP and HIPAA policies, and in the current state would not have had the
ability to make specific data segmentation requests.
On the clinician side, usability questions such as how redacted data show up in EHRs
and whether there are alerts to clinicians suggesting that the record contains data
they cannot see. EHRs use data such as diagnosis to inform clinical decision support
and other functionality, and if the data powering such systems are obfuscated the
function of downstream processes must be managed. For instance, if in the future Maritza
requires treatment such as an antiepileptic medication, a drug–drug interaction checker
may find potential adverse reactions between the antiepileptic and the OCP through
functionality that providers rely on as a safety check.
Beyond the usability challenges, variation may result from EHR vendors' technology,
variation in institutional IT resources, and the ability to implement more complex
workflows. Institutions have their own legal and policy mandates around granular data
segmentation, and these challenges affect other stakeholders such as pharmacies and
payors. When Maritza's PCP ordered both the new inhaler medication and the OCP, the
orders were both sent to the same pharmacy, where Maritza's mother might be listed
as the primary contact. The pharmacy information systems would also need to know that
the OCP is a sensitive medication and that the pharmacy should not inform Maritza's
mother that there are two medications. Similarly, when the claim goes to the insurance
company, the details of the visit are shared with the primary guarantor (who is usually
not the adolescent) in an explanation of benefits (EOB) form, and again the OCP as
a sensitive medication should not appear ([Fig. 4]). As an aside, this raises a complex ethical and legal question around whether information
can be obfuscated from the person paying the health insurance premium and/or copay.
Fig. 4 The primary care physician's EHR system and patient portal is configured so that
the oral contraceptive pill (ethinyl–estradiol–norethindrone) is identified as a sensitive
medication and not shared with Maritza's mother through the proxy portal access. However,
when this medication information is exchanged to the pulmonologist's EHR system (part
of a separate health care system), the medication is not identified as sensitive and
furthermore is revealed to Maritza's mother in the second proxy portal account, indicated
with the red outline. EHR, electronic health record.
Ethical, Legal, Administrative, and Policy Challenges
There are complex ethical and legal considerations to address. For example, categories
of sensitive data need to be identified and codified. However, due to broad legal
variability across state lines with nuanced gray areas of interpretation, differing
institutional interpretations leads to differing policy development. Ethical questions
remain around patients' rights to redact data they do not want to share and whether
such rights supersede a clinician's belief that a complete medical record is essential
for safe medical decision-making.
More recently, the legal risks for patients and providers alike have been escalating,
particularly around the criminalization of reproductive care and gender-affirming
care. If a patient crossed state lines to receive such care in a state where care
is legal, details about this care could follow them back to states where such care
is illegal and thereby expose patient and provider to legal risk. Even when such care
is lawful, data redaction could prevent the stigma and bias experienced by some patients
when providers are aware of the care.[40]
[42]
[43]
[44]
[45]
[46]
[47]
Existing Work
Some EHR vendors have, and continue to, develop vendor-specific functionality that
supports tagging of sensitive data, specifically for release to the portal. These
development efforts accelerated in response to the 21st Century Information Blocking
Final Rule. While this work may benefit some users, vendor-specific approaches do
not promote interoperability or the ability to share data with established exceptions
across the health care ecosystem.[54]
While DS4P allows for tagging of data to specify its sensitivity, a consent management
platform is then needed to capture patient sharing preferences. Several these have
been developed and piloted, including Consent2Share, an open-source tool developed
by the SAMHSA, which utilized DS4P CDA. More recently the San Diego Regional HIE LEAP
project focused on implementation of the FHIR Consent Resource to manage consent for
privacy, medical consent, advance directives, and research, as well as using a security
labeling service.[55]
Although DS4P and various consent management platforms have had successful individual
pilots within a single regional system, implementation of granular segmentation and
consent management to support individual privacy preferences and equitable interoperability
has not scaled nationwide. DS4P and consent management tools do not adequately address
other high-value clinical use cases such as Maritza's, and as a result, granular segmentation
of data leveraging these tools has not been prioritized.
Results
The pilot implementations of the DS4P standard advanced the notion and technical possibility
of granularly segmenting data within a narrow clinical and technical scope. Shift's
approach introduces additional high-value real-world clinical use cases, develops
a reusable methodology, and builds on pilot implementations and standards development
work already underway.
Clinical Use Cases
Shift has developed four high-priority clinical use cases to be addressed in two phases,
as depicted in [Fig. 2].
Clinicians with subject matter expertise developed these use cases in an iterative
process along with other Shift stakeholders who provided feedback on informatics,
data, and ethical considerations. The range of topics that were determined to be important
were divided across the use cases. The Pareto principle was used to create comprehensive,
representative use cases that are detailed but not overly complex to ensure that initial
implementation would be feasible. The use cases include a patient narrative followed
by discrete data elements, the specification of specific methods of exchange, and
privacy concerns including harms. Shift's clinical use cases have also been leveraged
in other related stakeholder work such as that featured in the Stewards of Change
Institute report, the OpenID Heart Working Group, and the Gravity Project on the social
determinants of health use cases.[56]
[57]
[58]
Standards and Terminology
Standards development work, in alignment with the HL7 Security Workgroup, is focused
on formulating a framework methodology that can:
-
Identify use case data elements harmonized using the U.S. Core Data for Interoperability.
-
Use a decision-tree process to better standardize the translation of broad categories
(i.e., reproductive health) to subcategories (i.e., sexually transmitted infections)
to specific code sets.
-
Curate value sets for the data elements, which includes defining a nationally available,
steward-maintained Value Set Authority Center (VSAC) terminology value set for sensitive
conditions.
-
Leverage DS4P FHIR work for designing and implementing computer consumable HL7 data
tags.
-
Define privacy policies and identify patient consent preferences through an existing
consent management engine to develop sandbox demonstrations of increasing complexity.
The National Library of Medicine maintains the VSAC Web site, which acts as a central
database of value sets developed by various organizations for clinical, operations,
and research purposes. SAMHSA developed a C2S VSAC Value Set of sensitive conditions,
largely focused on the 42 CFR Part 2 use case, but this was not comprehensive around
other conditions and has not been maintained since 2016, so is now outdated. Shift
is bringing together organizations that can be stewards of a Shift-guided value set
that can become a de facto standard.
Implementation
Implementation guidance is needed to address several challenges and controversial
issues. If a single site or system has the resources to invest in a pilot, it can
determine how to manage such challenges within its own system, but for granular segmentation
of data to scale nationally, such recommendations are needed on a broader level.
Shift is engaging expert stakeholders in a modified Delphi process to develop consensus-driven
guidance around areas identified as specific barriers to implementation, including
those outlined above. At a high level, this will involve determining how to achieve
the appropriate balance between patient safety and privacy considerations as well
as the balance between allowing specificity while limiting provider burden. Once drafted,
Shift will seek feedback and ultimately endorsement of this implementation guidance
from clinical and industry professional societies.
Ethical, Legal, and Policy
Shift is developing a foundational legal framework, including a specific adolescent
roadmap, to help implementers navigate compliance and jurisdictional considerations.
This work will facilitate the required standards revision and implementation guidance
with a scalable methodology needed to drive widespread adoption. Future work will
include advocacy for and sponsorship of governmental policy to promote equitable interoperability
across the health care ecosystem.
Stakeholders are unlikely to adopt new standards without a financial or policy driver.
ONC has introduced DS4P as an optional standard, as in the past industry regarded
required standards with unease due to the effort and cost of development and implementation.
Shift's goal is to work across the industry to mature the standard and implementation
guidance while working closely with ONC to advance policy that drives widespread adoption.
