DISCUSSION
Victor Dods and Ben Taylor*
LedgerDomain, Las Vegas, NV, USA
The twin forces of privacy law and data breaches have fundamentally challenged how we collect, store, and share sensitive information. Within this landscape, healthcare information is sacrosanct – and intimately tied to identity and data ownership. Building on prior work with UCLA Health, Genentech (a member of the Roche Group), Sanofi, Amgen, Biogen, and others, we offer this opinion piece to promote the development of a standard for decentralized Verifiable Credentials (VCs). This will empower Authorized Trading Partners (ATPs) in the pharmaceutical supply chain to trade and exchange information in compliance with the US federal law. Starting with credentialing and interoperability for the ATP community, our ultimate goal was to chart a path to a global standard for all health care VCs – providing individuals and health-care professionals control over their own data. By sharing our results and releasing essential components of the work to the public domain, we hope to align and connect with other foundational efforts, thus evolving standards within a truly open framework with broad stakeholder involvement.
Keywords: verifiable credentials; identity; DSCSA; pharmaceutical supply chain; interoperability
Citation: Blockchain in Healthcare Today 2021, 4: 175 - http://dx.doi.org/10.30953/bhty.v4.175
Copyright: © 2021 The Authors. This is an Open Access article distributed under the terms of the Creative Commons Attribution-NonCommercial 4.0 International License (https://creativecommons.org/licenses/by-nc/4.0/), allowing third parties to copy and redistribute the material in any medium or format and to remix, transform, and build upon the material for any purpose, even commercially, provided the original work is properly cited and states its license.
Received: 23 February 2021; Accepted: 18 March 2021; Published: 28 April 2021
Competing interests and funding: The authors declare no potential conflicts of interest. This proposed study represents the views of the authors and has no external funding.
*Correspondence: Ben Taylor. Email: ben.taylor@ledgerdomain.com
The rise of COVID-19 and the Solarwinds hack have exposed deep and systemic vulnerabilities in our health-care system (1).1 As the world converges around solutions to the pandemic, ‘the largest and most sophisticated [cyber]attack the world has ever seen’ remains largely unresolved. Both have far-reaching implications on how we prevent and mitigate future crises.
Back in our school days, the janitor had a big key ring that provided access to any office or drawer. If that key ring was held by somebody with bad intentions, bad things could happen. This is the case today with any system that manages your identity on your behalf, including government systems and technology enterprises. The administrator always has a backdoor (3, 4). By contrast, in a decentralized system you decide who holds your private key.2
While governments, privacy advocates, and security professionals redraw the lines around anonymity and data protection (5), personal health care information remains sacrosanct. Just as the Solarwinds hack provoked important questions about information security practices, so we must ask whether there is any rationale to centrally administer personal health care information. We assert the answer is No.
The time has come for self-sovereign health-care privacy, in which individuals and health-care professionals have some measure of control over their data and identities with their own private credentials (6). This provides the bedrock for stakeholders to carry only their own data and leverage authenticated identities, interacting safely with select parties of their interest. This would impact everything from drug supply assurance to cell and gene therapies and clinical studies, not to mention the needs of underserved communities.
While health care is an enormously diverse and complex ecosystem, the secure and interoperable management of identity and private data is a common challenge.3 The starting point in our effort to address this lies in an emergent class of identities with relatively clear boundaries and a strong motivating use case: Authorized Trading Partners (ATPs) as defined by statute in the US pharmaceutical supply chain.
The Drug Supply Chain Security Act (DSCSA) imposes particular requirements on five groups (‘entity types’) of stakeholders: manufacturers, repackagers, wholesale distributors, third-party logistics providers (3PLs), and dispensers (e.g. pharmacies) (11). One such requirement is an extended ‘know your customer’ rule, according to which each ATP is required to confirm that their trading partners are also authorized. In many cases, the law requires interactions between entities without any direct business relationship.4
To enable near-real-time interoperability within the ATP community, stakeholders have identified the value5 of decentralized ledger technologies (DLTs), such as blockchain and decentralized identifiers (DIDs). Together they provide all parties with a ‘single source of truth’ to address challenges, such as master data management and counterfeit detection.6 At a more fundamental level, ATPs must be able to identify other ATPs using VCs for compliant transactions and information disclosures; the same necessity motivated the development of the eXtended Authorized Trading Partner (XATP) framework (16, 17).
Any framework addressing this challenge must satisfy the following two requirements:
To realize this mission, a coalition of stakeholders must come together to provide interoperable tooling.
Our vision is an interoperable system employing cryptographic schemes, which allow for the selective disclosure of credential elements. There is also a need for interoperability regarding workflows mandated by law.7 The W3C VC Data Model (17) presents a flexible and extensible credential scheme leveraging decentralized identifiers (DIDs),8 which meet the needs of ATPs.9,10 In this case, we propose an ATP-specific scheme anchored in W3C standards, which would allow interoperation between all ATP software solutions.11
To chart the path of an ATP VC standard, several key questions must be addressed by stakeholders.12 These, in turn, provoke further questions around implementation, which can be broadly divided into software and non-software domains.
For a standard to be adopted, the VC should not be a ‘black box’. There should be sufficient transparency for understanding how issuance and verification work, the context necessary for VC usage and a path to including a possible human in the loop.25
Within the ATP context, many of the key questions raised by this paper have already been partially resolved by stakeholders joining together to define a trust framework and governance structure (35, 36).26
This proposed solution is a complete, fully transparent, open-source reference implementation that satisfies the requirement for interoperability across all ATP types. We are looking to work with a coalition of the willing to design and contribute key components of this effort, including an initial implementation that should be adequate for everyday use and upgradeable over time.
Much as a driver’s license has become a standard form of physical identification outside its original use case, so a VC schema grounded in the ATP community would address a stipulated need within the US pharmaceutical supply chain, while also having far-reaching implications for other health care domains. We aim for a future in which the VC schema developed for ATPs could be seamlessly extended to other open-source credentials to serve patients, caregivers, and all participants in the health-care system.
In the same world, patients could then share VC-backed laboratory results and prescriptions with pharmacies and clinics.30 Due care would be needed in adherence to best practices as promulgated by HIPAA, GDPR, and CalPrivacy, so that patients carry only their own data31 and disclose it to select parties of their choice. A secure, interoperable, and privacy-preserving world would mean lower costs, better care outcomes, greater rate of clinical innovation, and an abundance of opportunity for private companies to add value by leveraging the schema.
Over the coming weeks and months, we will be working with stakeholders in the health care and identity space to chart the best path forward for ATP W3C VCs, and beyond. In the interest of public and transparent conversation, specific schemas, supporting documentation, and updates to this effort will be published at Zoogma.org.
Authors would like to personally thank Mike Lodder for his insights regarding DIDs and cryptographic schema. The authors would also like to thank Brian Behlendorf (Linux Foundation); Connie Jung, RPh, PhD (FDA’s Center for Drug Evaluation and Research); Melanie Nuce, Gena Morgan, and Peter Sturtevant (GS1); Eric Marshall (Partnership for DSCSA Governance); Bob Celeste (Center for Supply Chain Studies); and Max Sills, JD.
The authors would also like to acknowledge the XATP Working Group for their contributions to the framework that informed this proposal. These include Ghada L. Ashkar, Pharm, Kalpan S. Patel, PharmD, MBA, and Josenor de Jesus, PharmD, MBA, FACHE (UCLA Health); Vidya Rajaram, Mark Karhoff, Nirmal Annamreddy, and Kathy Daniusis (Genentech, a member of the Roche Group); Nikkhil Vinnakota, Natalie Helms, and Alina Grigorian (Amgen); Arthi Nagaraj (Sanofi); Greg Plante (IQVIA); Todd Barrett, RPh (Providence Health); and Ben Nichols, Will Jack, and Will Chien, PharmD, MBA (LedgerDomain). The foregoing acknowledgements do not imply consensus nor endorsement.
Both authors contributed to the conception, development, and writing of the proposal. Victor Dods led the technical considerations and recommendations around DIDs and cryptographic schema.
1 For instance, as the COVID-19 Credentials Initiative wrote in its hello world, ‘without a holistic perspective from the onset, many COVID-19 technology solutions may introduce unintended results (e.g. surveillance, abuse of personal data, social inequalities). In order to avoid such outcomes, we have committed ourselves to open collaboration with a diverse range of experts, embracing open standards, and protecting the fundamental privacy and personal data rights of all stakeholders’ (2).
2 With Bitcoin, you can hold your own wallet, or you can hire and fire Coinbase. Either way, you are in control.
3 Other foundational efforts to develop and deploy credentials for health care include the Vaccination Credential Initiative (7), Decentralized Identity Foundation (8), CommonPass by The Commons Project and The World Economic Forum (9), and the SMART Health Cards Framework (10). Our aim is to bring together stakeholders to address an ATP-specific W3C VC scheme, and look towards interoperability and expansion.
4 Under certain circumstances, drug packages are required to be verified with the manufacturer or repackager in order for transactions to proceed. One such circumstance is the saleable returns process, in which dispensers with surplus drug return the drug to their wholesaler, or sell it to another ATP. This process represents 2–3% of the overall volume of the US pharmaceutical supply chain, or 59 million units annually (12). Manufacturers and dispensers typically have no former business relationship; yet, there must be a framework for these parties to interact within the broader requirements of the ‘fully electronic, interoperable system’ (13) mandated by the law.
5 ‘Data-informed technologies, such as distributed ledger solutions like blockchain, will be critical to support FDA’s track-and-trace priorities’ (14).
6 Much of this effort would not be possible without the near-universal adoption of the GS1 DSCSA standard (15) within the US pharmaceutical supply chain. While there are many hurdles in standards development and adoption, we believe that alignment can be more rapidly achieved in well-defined communities with clear and present needs.
7 By its nature, interoperation implies authentication and the corresponding need for a mutually understood credential scheme, which allows each ATP’s software to verify the validity of transactors within the ecosystem.
8 A portable URL-based identifier associated with an entity, most often used in VCs. They allow VCs to be easily ported from one repository to another without the need for reissuing the credential (18, 19).
9 The extensibility of the W3C VC data model comes in the form of allowing context-specific credential definitions, a natural complement to DIDs.
10 Beyond the healthcare ecosystem, W3C DIDs have also seen adoption by the international technology standards organization Object Management Group (20) and the Sovrin Foundation (21).
11 These ideas may justifiably be termed ‘old wine in new bottles’, but collective security and interoperability always improve as more parties adopt and then adhere to best security practices. At the same time, we are certainly not discouraging any ongoing efforts to bolt W3C credentials onto identity systems that are anchored in traditional centralized registries. These efforts can certainly enhance interoperability, but it should nonetheless be noted that they neither support privacy nor address those systems’ inherent single points of failure. (Painting spots on a house cat doesn’t make it a leopard!)
12 As different ATP entities will have a stake in different parts of the standard, participation in the standard development should reflect those roles.
13 The FDA is a key indirect stakeholder, but best practice is for regulators to work through ATPs to avoid creating a single point of failure.
14 The XATP application framework incorporates one potential workflow for an enhanced verification. Because this involves interaction between dispensers and manufacturers, particular emphasis has been placed on credentialing for those entity types (16, 17). A credentialing model for dispensers is currently in place, with manufacturer credentialing on the roadmap.
15 Given the need for protecting PII and minimizing its disclosure, we recommend that the ATP VC use a cryptographic scheme, which allows zero-knowledge proofs and selective disclosure. In particular, we recommend the use of BBS+ signatures, which allow a flexible and minimal disclosure of information in credentials (22), thus enabling compliance with data privacy laws and best practices, while still providing powerful and meaningful credentials. BBS+ is a cryptographic signature across multiple messages that also support selectively disclosing any subset of messages, while the remainder are withheld when presented to a relying party. The implementation is written in Rust in Hyperledger Ursa, which supports compiling to mobile devices, servers, and WebAssembly (23).
16 ‘An authoritative entity represented by a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative” (25).
17 A precedent for this is Mozilla’s approach (26).
18 For example, drug receipt, returns, and master data access.
19 ‘A verifiable claim is a qualification, achievement, quality, or piece of information about an entity’s background, such as a name, government ID, payment provider, home address, or university degree. Such a claim describes a quality or qualities, property or properties of an entity which establish its existence and uniqueness’ (27). Claims can be grouped into ‘bundles’. For example, a pharmacist requesting drug verification from a manufacturer would present a bundle, indicating that they are a currently licensed pharmacist and a pharmacist in charge at a particular pharmacy. Together, the DID and the bundle of claims constitute a VC. We may assume that the higher the stakes, the more claims must be revealed in the presentation of the VC.
20 In the case of XATP, identity information is held on the user’s mobile device instead of the service, and control over the identity lies with the keys stored in the device (16, 17).
21 JSON has emerged as a widely used data format, including JWT-based VCs used by Spherity’s ATP VCs (28), and JSON-LD-based VCs, which are generally recommended by the W3C VC data model and employed by the COVID-19 Credentials Initiative hosted by Linux Foundation Public Health (29). Alternatively, a compact, binary encoding scheme (such as protobufs [30]) might be preferred in many machine-to-machine workflows, with JWT/JSON-LD employed for interoperability between organizations (29).
22 The schema for W3C VCs (32) specifies four digital signature schemes. For the purpose of minimizing PII revelations, we are exploring the use of ZKPs and selective disclosure. It should be noted that ZKP imposes certain restraints on the data structure of attributes, requiring mapping nested content to a list (31).
23 There is only some high-level guidance in the VCs’ Data Model.
24 For example, each ATP VC vendor could provide their own ‘test network’ (or instructions for how to run one locally, in the case of open source implementation) against which denizens of the ATP software-verse can test their code.
25 For instance, easy discovery of the ATP’s website or other relevant contact information. JSON-LD is a good candidate for this purpose as it enables clients to uncover linked data based on a principle known as Follow Your Nose (33).
26 These include the Internet Identity Workshop headed by Doc Searls, Phil Windley, and Kaliya Young (34), and more recently Sovrin Foundation, Spherity, the Center for Supply Chain Studies, and the FDA’s DSCSA Pilot Project Program.
27 Note that for much of this article, we discuss VCs for ATP entities, which may be distinguished from a personal VC that specifically relates to a person’s identity (e.g. equivalent to their driver’s license and containing their personal information). A pharmacist might have an ATP pharmacist credential that attests to his or her pharmacist license number, validity date, and other details that would not contain unrelated identity information, such as their home address. There are also VCs for entities meant for automated systems, such as authentication systems and server backends.
28 WebAssembly (Wasm) is an assembly-like language with a compact binary format that runs with near-native performance and provides languages, such as C/C++, C#, and Rust with a compilation target, so that they can run on the web (37). In 2019, the specification became a W3C recommendation (38), and as such, may have particular applicability to interoperability. Given that WebAssembly is the avenue for compiled code to run within the browser, at the very minimum, a WebAssembly port of the open-source solution should provide a means to easily verify VCs from within the browser. However, with regard to holding and issuing credentials, the browser is inherently less secure than non-browser platforms, and thus, poses additional challenges.
29 Within a trust framework model, the governance layer establishes business, legal, and technical policies, and manages membership and participation. Governance is typically handled by organizations created by constituent members to administer the activities associated with operating an identity federation. They may be government programs, corporate entities, not-for-profit membership organizations, or industry associations (38, 40).
30 This change simply digitizes the information movement currently achieved by paper. Paper versions of credentials can still be given simultaneously until on-the-ground workflows adapt to the new VCs.
31 For principles concerning the use of biometrics within a self-sovereign identity solution, see Callahan et al. (41).