did:health

did:health is used to identify Patients, Practitioners, Devices and Orgs in a healthcare ecosystem. Users publish their TSS/MPC encrypted FHIR content in IPFS as services in their DID Document.

Comment 1

Inspiration

In the face of growing concerns over healthcare data privacy and management, 'did:health' was born. Our inspiration comes from the need to empower individuals with control over their health data. did:health also enables a direct exchange of interoperable health information and messages between devices, patients, healthcare practitioners, and healthcare organizations. Recognizing the potential of decentralized identifiers (DIDs) in healthcare, we aimed to create a solution that not only ensures data security and privacy but also enhances the accessibility and autonomy of patients in managing their health information and communicating directly with third parties with no intermediary. We fully support the DIF's mission and desire to make did:health as user friendly

What it does

Certainly, let's incorporate the aspect of 'did:health' being a W3C-compliant DID and its integration into the Digital Identity Foundation ecosystem through the universal resolver driver into the "What it does" section.

  1. What it does 'did:health' represents a significant advancement in digital healthcare, functioning as a W3C-compliant Decentralized Identifier (DID) tailored specifically for the healthcare industry. Its integration into the Digital Identity Foundation ecosystem through the 'did:health' universal resolver driver marks a key milestone in decentralized digital identity and healthcare data management. This alignment with W3C standards ensures that 'did:health' adheres to the highest principles of web decentralization and identity verification, and MIT licensed open source software making it a trustworthy and reliable system for managing sensitive health data. did:health requires FHIR service endpoints to full data. did:health can be linked to a Polygon ID or World ID for further identifier proofing and verified credentials.

The system is designed for flexible registration across Ethereum Layer 1 (L1) and Layer 2 (L2) blockchains (other chain can also be supported in the future), ensuring a secure and immutable record of healthcare data transactions. It uses IPFS for robust, decentralized storage of health data, with each data element intricately linked within the DID's document for secure referencing and access. This is complemented by the integration of Lit Protocol's encryption technology, utilizing Threshold Secret Sharing (TSS) and Multi-Party Computation (MPC) for top-tier data security and controlled access. All data is stored in FHIR format, ensuring interoperability with international health care standards.

Incorporating FHIR Messaging, 'did:health' allows for efficient and secure communication of healthcare information, either through Push or the XMTP Protocol, enhancing interoperability and seamless data exchange across diverse healthcare systems, again in an industry preferred mechanism.

By combining these technologies, 'did:health' offers a robust platform for secure, efficient, and interoperable healthcare data management, meeting the highest standards of privacy and security in the digital healthcare domain.

How we built it

The construction of 'did:health' represents a significant departure from traditional software architectures in the digital health space. Our team developed 'did:health' entirely in TypeScript, focusing on creating a 100% client-side application software that can be run directly in a web browser or through command-line interfaces, eliminating the need for any server or backend infrastructure.

By opting for this architecture, we prioritized accessibility, ease of use, and flexibility. The client-side nature of 'did:health' allows users to interact with the system without the complexities and vulnerabilities often associated with server-based applications. We carefully designed the user interface and functionalities to ensure that, despite running entirely on the client side, the application maintains high performance, robust security, and seamless interoperability.

This development strategy also involved rigorous testing and optimization to ensure that 'did:health' functions efficiently across different browsers and platforms. Our commitment to a decentralized architecture required innovative approaches to data handling and encryption, particularly in implementing FHIR Messaging and the Lit Protocol within the constraints of a client-side environment.

Ultimately, the development of 'did:health' as a TypeScript-based, client-only application represents a forward-thinking approach in healthcare software, offering a secure, portable, and user-friendly solution for decentralized health data management."

Challenges we ran into

Implementation of the Universal Driver was very simple, with a well documented example that was easy to customize. Doing the PR and setting up the docker image for the driver was also simple and well documented process.

We also analyzed the DIF DWN spec as part of this project and noticed while is contained a very similar approach to did:health's architecture's there were a few notable differences. Understanding these differences is key to determining the future of the DWN spec.

  1. did:health uses the international Hl7 FHIR Messaging standard https://www.hl7.org/fhir/messaging.html, and we are still trying to align the concepts of FHIR Messaging with the concept of messaging in DWN's . https://identity.foundation/decentralized-web-node/spec/#messages.

The common ground is both did:health and DWNs. Our DID+ IPFS + LIT is very well aligned to the draft DWN spec until it comes to actual Messgaging. FHIR Messaging can also leverage DID + IPFS + LIT. FHIR Messaging handles all of the signatures, bundling, message headers, contents, attachments etc. However, It does not specify the transport mechanism/protocol. The current proposal is to use various mechanisms for transport including XMTP or Push protocol by simply putting the CID and the Lit Encryption hash on the wire. Client Software encrypt/decrypt using the Lit TSS/MPC scheme that has built in access control. We are thinking we can also support DID Comm using TBD Web 5 library solely for messaging transport without while preserving our FHIR Message Payload . In this case DIDComm would be used in lieu of XMTP or Push. The message would only need contain did:to/from, dataCID, and encryption hash.

Some of the work we did with TBD is here: https://github.com/TBD54566975/web5-js/compare/main...fhirfly:web5-js:main

Accomplishments that we're proud of

What we learned

We still have some development to do to make sure did:health is simple to use and interoperable with emerging web and healthcare standards.

What's next for did:health

Continue to develop, test, and release did:health Dapps, development tools, drivers, and methods. Recruit Users from Web 3 Communities and create additional features, applications, and interfaces driven by users. We also intend to continue establish relationships with medical device manufacturers, hospitals, insurance payers, and the government. did:health will also attempt to align did:health with other DIF specs such as DIDComm/DWN as they mature.

Built With

Share this project:

Updates