Stream: blockchain
Topic: FHIR on IPFS (Interplanetary FileSystem)
Abbie Watson (May 15 2017 at 18:43):
Anybody else researching FHIR over IPFS?
Sunanda Veeraganti (May 24 2017 at 13:05):
@Abigail Watson IPFS is often used with Ethereum. Do you see FHIR over IPFS using Ethereum as a use case?
Abbie Watson (May 24 2017 at 13:10):
I see FHIR over IPFS using Hyperledger as a use case, sure. And even FHIR over plain IPFS with no security. While the Ethereum community is having a big rally right now, culturally I find them very immature and unready for the healthcare sector. They're up-and-coming fintech players simply trying to displace existing fintech players. They don't have a fundamental interest in the complexities of the healthcare market. It will require a dedicated blockchain that is devoted 100% to healthcare usecases for it to succeed in the healthcare industry. So, Hyperledger, DokChain, etc.
Doug Bulleit (May 27 2017 at 16:46):
Abigail, while I don't have as much insight into the Ethereum community as you, I agree with your overall assertion. Conversely, it goes both ways--i.e., I find it remarkable how little interest and insight many within the EHR community (members of this board of course excluded;-) have into blockchains, IAM, IRM, UMA, etc [as well as vice versa]. Anyway, FWIW at least within the FHIRBlocks Project, we don't see much need of IPFS. FHIR Resources, in our architecture at least, remain within the orthodox EHR (and/or transiently within FHIR certified App's). The FHIRBlockChain is used merely as a permissioned repository of assertions, attestations, permissions, etc. `knid of like the out-of band Signalling System in a pubic telecom network and or, more specifically, a distributed DLS/DNS server.
Abbie Watson (May 27 2017 at 22:09):
Fair that.
As for IPFS usecases, I'm not sure that IPFS lends itself particularly well for PII. But everything else? You bet. Example: the ProviderDirectory Argonaut sprint. It includes the Patient, Organization, and Location resources. Those are exactly the kinds of things that putting on a swarm filesystem like bit-torrent would be great for. It gets autoreplicated to all the watchers, and no worries about things getting out of sync. As long as you're subscribed to the correct ProviderDirectory, it will always be up to date with the latest contact info, the latest list of providers, etc. It would also be great for synchronizing quality control measures, device configuration files, data dictionaries, careplan templates, financial resources, etc. etc. It also has a much lower barrier to entry than blockchain; and is significantly easier to implement.
Doug Bulleit (May 27 2017 at 22:59):
Makes sense
But why do these kinds of resources need to be in a distributed/replicated-state system in the first place? I suspect there's a good reason (I just don't know what it is;-)
Abbie Watson (May 28 2017 at 18:18):
Because they get out of sync! :)
Why would yellowpage phonebooks get distributed to millions of people each year? So everybody would have a roughly synchronized copy of important contact info, business info, etc. Same exact use case. Only, with distributed/swarm system, the yellowpages are always auto-synchronized and up-to-date.
Even with digital technologies, people wind up with config files that are out of date. Changing networks, misconfigured systems, lack of funding, lack of staff knowledge, and legal constraints can all conspire to leave an organization with billing codes or diagnostic codes that are years out of date. So it's mostly a matter of making sure that people aren't using last year's billing codes, phone addresses, provider directories, etc.
It may not seem like a huge issue, but it's on the order of billions of dollars of waste and friction that occur because of these things being out of sync. IPFS doesn't solve all healthcare problems; but it can solve that part of the problem.
Doug Bulleit (May 31 2017 at 11:23):
Got it; though it's still not obvious to me why, in this case, a central registry (or just a community wiki, github, etc) wouldn't work. All that said, IMHO there's still a natural use case for a permissioned blockchain at the root of self-sovereign identities and App's. `more on that shortly...
Adrian Lanzafame (Oct 20 2017 at 03:35):
@Abigail Watson I think the most compelling use case for IPFS for myself is References no longer require an internal/external distinction and resolving references becomes much simpler and more robust, especially with the concept of FHIR (API) versions.
Abbie Watson (Jan 21 2018 at 03:29):
Happy to say that we got a FHIR on IPFS network up and running. We're only just now loading up hospitals from the Chicagoland area; but so far its working great. We're tentatively announcing that Symptomatic is now providing a subscription service via IPFS for teams who are using Meteor on FHIR to get data dictionaries, datasets, and other configuration data for their apps and websites.
We're going to try to get any JSON data we can from https://data.cityofchicago.org/ and Medicare/Medicaid, convert them to FHIR and then put them on IPFS. The Meteor on FHIR server has a configuration file that points to an IPFS endpoint; which will let us manage and do synchronized upgrades across the entire mesh network.
Grahame Grieve (Jan 21 2018 at 03:33):
what does FHIR on IPFS mean?
Abbie Watson (Jan 21 2018 at 03:34):
It's sort of like FHIR on BitTorrent. Swarm filesystem. It uses JSON as it's native exchange and storage format; so we just used FHIR schemas, and et voila. Works great.
Grahame Grieve (Jan 21 2018 at 03:37):
well, I have some feeling for what that is, but not complete. what services do you get? a file system gives you a heirarchical storage container system, with the ability to create, read, and write files or directories. is that what IPFS does? or is FHIR on IPFS different to FHIR-on-a-filesystem?
Abbie Watson (Jan 21 2018 at 03:39):
Basically, yes. Since it's a swarm filesystem, it's not so hierarchical. Flatter; most like an object store, with good support for metadata. And, yes... similar to FHIR-on-a-filesystem, except that everything is accessed via REST endpoints.
Grahame Grieve (Jan 21 2018 at 03:40):
so you must have some patterns of use.... indexing...?
Abbie Watson (Jan 21 2018 at 03:45):
It has a pretty rich metadata which people can search. Patterns of use are basically data-dictionary publications. We'd like to see RxNorm, ICD-10, DSM, and any other sort of annually released national data dictionary eventually wind up on something like IPFS in FHIR format. RxNorm available as a big file of Medication resources; ICD-10 as a giant file of Conditions; etc. Synchronize your local app with the IPFS network to load up your data-dictionary; then select a record as a record and mutate it into an actual record. Yup, yup, yup. That's the ticket.
Lloyd McKenzie (Jan 22 2018 at 15:59):
Conditions are patient-specific. We could look into a ConditionDefinition resource, but (unlike medications), that's not something I've commonly seen coming from knowledge-bases.
Abbie Watson (Jan 22 2018 at 16:48):
Within the Meteor ecosystem, we have a more lax interpretation of R! fields. We interpret R! fields as being required when served up on outbound REST interfaces to external systems, but not required for forms, database schemas, templates, and other internal usages.
Abbie Watson (Jan 22 2018 at 16:54):
ConditionDefinition could work, but seems a bit of overkill. The Condition works fine as-is for plenty of epidemiology, public-health, and chronic care management use-cases. Why require that it be patient-specific?
Lloyd McKenzie (Jan 22 2018 at 17:12):
Because the systems that deal with definitions of conditions and the systems that deal with patient-specific conditions are different and even if a system supports both, it's not typically going to put both in the same place or have the same rules around access, etc.
Lloyd McKenzie (Jan 22 2018 at 17:14):
Condition does support the subject being a Group for epidemiologic/public health, etc. But it still has a subject. If you're talking about a definition of what a condition is, a lot of the data elements you'd capture would be different.
Abbie Watson (Jan 22 2018 at 20:49):
Hmmm.... well, it sounds like Symptomatic is going to be a case-study of having them in the same place with same rules. :)
We've certainly thought about having an extension for Condition to handle the extra data elements. But the way our data pipelining works, it makes sense to use a decorator pattern: start with a small base resource (with extension fields; sans patient), which gets copied into a resource with patient (and extensions removed), and then extra fields decorated on as it passes through the system(s).
Adrian Lanzafame (Apr 20 2018 at 02:09):
@Abigail Watson @Grahame Grieve Just a heads up that I left Genie Solutions earlier this year and am now working for Protocol Labs the company behind IPFS as such I would love to hear any feedback or ideas about how to take IPFS forward in a way that caters for the FHIR use. Grahame not sure if you remember but Hacking Health last year in Brisbane, I pitched a distributed data layer for the healthcare industry, I was basing that project on the technology provided by IPFS and a few associated projects.
Abbie Watson (Apr 24 2018 at 21:08):
Congrats on the new job, Adrian!
We have a half dozen developers at our weekly Chicago hacknight/connectathon, who have all gotten Meteor on FHIR up and running, and are now settin up an IPFS swarm. It makes sense to exchange configuration info, so we'll probably start by loading up Chicago area hospitals and medical homes on IPFS as a Bundle of Organizations.
Based on my prototypes, the big questions I have right now about using IPFS have to do with endpoint discovery and record expiration. We load up the IPFS endpoint via a configuration file that's ran at application startup. Which works well, but requires us emailing around the file /record/object pointers. My hunch s that IPFS needs something akin to a /metadata route.
Do you know if IPFS records have expiry options? Or pointers to other files? The issue is when record A1 gets outdated, and record A2 becomes authoritative. A /metadata route on an account basis tracking the pointers to each file is one way to solve the problem. Or having the noption of a folder (I.e. tag), and looking for the most recently created record in that folder.
Not an IPFS expert, and only did the one dive, so this functionality may already exist. $0.02
Adrian Lanzafame (Apr 25 2018 at 00:22):
(deleted)
Adrian Lanzafame (Apr 25 2018 at 01:10):
Thanks :D
Based on my prototypes, the big questions I have right now about using IPFS have to do with endpoint discovery and record expiration.
So, if I understand correctly, what you are looking for is IPNS for endpoint discovery and a new experimental feature IPNS pubsub, which would allow you to receive updates of new records that have been published to IPFS. IPNS records can have expiry options. For the moment, using something like dns to point to the new authoritative record (https://gkbrk.com/2017/10/putting-my-blog-on-ipfs/) is the best option but once the IPNS pubsub system becomes more stable it will be far better. Regarding the dns option, there is this tool to make it simpler: https://github.com/ipfs/dnslink-deploy.
Don't worry, I am also not an IPFS expert but I am hope that helps. Also feel free to drop into the #ipfs irc channel on freenode or https://discuss.ipfs.io/.
Adrian Lanzafame (Apr 25 2018 at 01:20):
An example that I just whipped together is at ipfs.skapa.xyz. It is using a dns record to point to /ipfs/QmPWrBwCLW7X6CLN8hS4mfSuYuMoQtmyXtDFpCo9wHE3wM, which if you go to ipfs.io/ipfs/QmPWrBwCLW7X6CLN8hS4mfSuYuMoQtmyXtDFpCo9wHE3wM you will get the same page. But if I want to update the authoritative page, i.e. ipfs.skapa.xyz, I would publish the new page to IPFS and put the returned hash in the dns record.
Cory Martin (Aug 20 2018 at 17:42):
Please forgive my inexperience. What does IPFS give you that blockchain doesn't? Impermanence? Capacity?
In my elementary thinking on the matter, if you're passing (presumably encrypted) PHI over IPFS, you have to assume that encryption will one day be broken. And thus any data that have been publicly exposed using that encryption is now publicly known, or at least exposed.
Am I thinking about that correctly?
Abbie Watson (Aug 21 2018 at 02:53):
Please forgive my inexperience. What does IPFS give you that blockchain doesn't? Impermanence? Capacity?
In my elementary thinking on the matter, if you're passing (presumably encrypted) PHI over IPFS, you have to assume that encryption will one day be broken. And thus any data that have been publicly exposed using that encryption is now publicly known, or at least exposed.
Am I thinking about that correctly?
FHIR encompasses many data types that aren't strictly PHI, or which are only PHI in certain contexts. A Medication might be part of a Patient's CarePlan, but a Medication might also be simply a part of the Pharmacy's inventory. Knowing that a Patient goes to a particular clinic will make that Organization PHI in context, but that Organization listed in a Bundle of Health Service Areas wouldn't be PHI.
So, we see IPFS as having a role in synchronizing non-PHI datasets and data dictionaries. Think in terms of updating CPT and ICD-X annual supplements. What is the authoritative list of Hospitals in the United States? There were 5174 hospitals last year. Is there the same number, or did any of them close; and were any new ones built? What list of Medications does the AMA recommend belong in a crash cart? And so on and so on.
tl;dr - Without smart contracts and all the other advanced functionalities, IPFS's primary use case is in configuration management. Which... is a totally huge problem unto itself, that has all sorts of downstream ramifications.
Cory Martin (Aug 21 2018 at 16:00):
Thanks for the explanation, @Abigail Watson
Adrian Lanzafame (Sep 18 2018 at 03:19):
@Cory Martin This article goes through the aspects of IPFS that make it different to a blockchain and how they are useful for healthcare: https://medium.com/@PeterBNichol/an-ipfs-addressable-storage-model-for-healthcare-with-blockchain-740fabc1a062
Cory Martin (Sep 18 2018 at 13:34):
Thanks @Adrian Lanzafame ! I will check it out
Rein Zustand (Dec 08 2018 at 18:28):
Versioning of your medical records
Note: while the protocol uses merkle DAG, in which versioning can be built on top of, it doesn't have a versioning in itself yet. There is another content-addressed p2p system, Dat, which also has versioning.
The 2 protocols might converge via IPLD though.
Grahame Grieve (Dec 08 2018 at 23:21):
that all looked like word salad to me
Adrian Lanzafame (Dec 17 2018 at 13:14):
@Rein Zustand technically IPFS is versioned but doesn't have versioning. For example, you make a change to a file it will get a new hash which can be thought of as a new version, but there is automatic linking of that new version to previous versions. Though as you say it can be built on top.
Adrian Lanzafame (Dec 17 2018 at 13:19):
Also, IPFS already uses IPLD and bringing Dat on to IPFS is possible already, I doubt they will converge.
Adrian Lanzafame (Jun 06 2019 at 05:25):
An interesting paper on the use of Ethereum and IPFS to host EHRs: https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8717579
Grahame Grieve (Jun 06 2019 at 05:33):
hah from the Data61 blockhain everywhere guys
Dan Connolly (Jun 12 2019 at 21:35):
data61? the seL4 guys?
Dan Connolly (Jun 12 2019 at 21:38):
color me interested: "Traditional access control approaches [14]–[16] for EHRs
sharing assume that cloud servers are fully trusted by data
owners and enable the servers to perform all access control and authentication rights on data usage. ... To improve security of EHRs sharing,
we develop a trustworthy access control mechanism
using smart contracts."
Abbie Watson (Sep 16 2019 at 02:08):
Eh, I find IPFS far more interesting than Ethereum.
Was talking with the AMA regarding the Integrated Health Model Initiative (IHMI) regarding remote blood pressure monitoring, and they're publishing a Validated Device List (VDL) of 501k validated blood pressure devices. I suggested that they make the VDL available via FHIR, and they expressed interest.
What I'd be interested in doing is publishing the VDL on IPFS. Then, anybody who subscribes to the IPFS channel gets the latest copy to configure their application with.
Grahame Grieve (Sep 16 2019 at 09:26):
how would they be represented? just plain Device? Or is that data more complicated than that ?
Grahame Grieve (Sep 16 2019 at 09:48):
and you should talk to the devices work group about this
Abbie Watson (Sep 16 2019 at 18:03):
Yeah, I think that just putting the Devices in a Bundle (or List) would suffice. There are no required fields for attaching an Organization, Patient, or any patient/context specific info. Devices can sort of be contextless. Might want to round it out with a Provenance record and Organization to represent the AMA though.
Connor Smith (Jun 10 2020 at 14:06):
Hey guys, any updates on this project? We are doing some similar stuff for a project from the NIH, but using the Factom blockchain to track the sharing/modification of FHIR resources for population health data exchange. Originally we were thinking data housed within health systems own servers/cloud but I think the idea of using IPFS or something like that for file storage could be pretty powerful
Abbie Watson (Jun 10 2020 at 16:21):
I've been piecing together the user interface for an administrative node and client nodes for a web-torrent like system. We have UI for CRUD operations for Endpoint, Bundle, and ValueSet, as well as data import/export UI, as well as a chord diagram for all the participating nodes. That's almost enough to put together something similar to WebTorrent.
Blocker is that we need 3 or more interested parties to run independent nodes to launch the IPFS network.
If anybody else feels comfortable with the protocol and wants to experiment with FHIR on IPFS, let me know and we can do an impromptu connectathon. Or better yet, petition for an official FHIR on IPFS connectathon track.
Connor Smith (Jun 10 2020 at 17:34):
We haven't done anything with IPFS yet, but we have a lot of experience running nodes for different blockchain networks. We have commercially supported 12 different networks over the last year in addition to building out this product. Would love to set up a call/chat to learn more about the project and see if there are ways we can help out or integrate the work we have done with the NIH
Abbie Watson (Jun 10 2020 at 17:40):
Oh, you're in South Bend. I'm in Chicago and Evansville, IN. Cool. Yeah, let's do a call.
Brian Kaney (Jun 16 2020 at 23:37):
+add me for a FHIR on IPFS experiment!
Josh Mandel (Jun 17 2020 at 00:51):
I'd like to follow along too. (Would also encourage folks to have a look at https://github.com/decentralized-identity/secure-data-store/ -- an emerging standards effort between W3C and the decentralized identity foundation. Not a blockchain thing, but neither is ipfs... and in any case, will appeal for many of the same reasons; basically the standards path for the ideas in Timbl's Solid.)
Abbie Watson (Jul 02 2020 at 19:09):
Just a quick update: it appears we're moving forward and beginning to provision servers for a public IPFS network. Big thank you and shout out to Conner and team.
I have some ValueSets and other data dictionaries that I'm going to seed it with.... Covid19 ValueSets with LOINC and SNOMED codes, maybe some SANER reports, Gravity questionnaires, etc. All non-PHI stuff.
Could be available as early as next week, as it seems this may be shaping up into a sort of impromptu 4th of July hackathon/connectathon.
Abbie Watson (Jul 02 2020 at 19:41):
@Josh Mandel - Thanks for the link share, and yes, +1 for Solid as being worth its own thread and discussion.
Kenneth Myhra (Jul 06 2020 at 13:47):
I would like to participate with a node, where can I find information on how to set it up?
Abbie Watson (Jul 06 2020 at 16:37):
We'll be publishing that config info as soon as we can. We'll be starting with a public network, that much I know. So, once we generate the URL and a few public keys, that should be enough to get people started. Hopefully will have something later this week or next week, and will post here.
Abbie Watson (Jul 29 2020 at 19:42):
@Connor Smith - Any updates on the IPFS servers?
Josh Mandel (Mar 25 2021 at 23:51):
On this general subject: has anyone hit issues creating FHIR Bundles where resources have ipfs:// fullUrls (and with inter-resource references between entries in the same bundle)? There's some open question about whether FHIR allows this (FHIR-31422).
John Moehrke (Mar 26 2021 at 12:04):
@Abigail Watson ?
Abbie Watson (Mar 26 2021 at 14:06):
Not during our initial prototype. IPFS allows storing raw JSON files. So from an App perspective, it behaves like most any other readable data source, and the driver spits out a JSON payload just like a REST interface or reading it from normal file system. We were never working at scale enough to test name collisions and such.
FYI, once I submit this Vaccine Wallet to the App Store, I'll probably be turning my attention to both IPFS and BigChain again (Hyperledger also, but meh). I feel like we should be running an IPFS or BigChain track at the connectathons.
Re: FHIR-31422 - My initial reaction is very much in favor of making the proposed clarification.
Brian Kaney (Apr 05 2021 at 02:48):
This is worth a read when thinking about access control on IPFS: https://blog.textile.io/the-5-steps-to-end-to-end-encrypted-photo-storage-and-sharing/ and https://blog.textile.io/introducing-textiles-threads-protocol/
Josh Mandel (Apr 05 2021 at 14:03):
Reminder that today 3pET is the FHIR Infrastructure call where we'll bring up FHIR-31422. Telecon: https://hl7-org.zoom.us/j/8583747934?pwd=VnZiWFZsNm1TSk5QWmZlbVJyQVZGdz09
Joshua Kelly (Jul 23 2021 at 15:50):
Curious where this thread is at today. Do folks have any public prototypes?
I have experience writing APIs against the IPFS daemon, and deploying orchestrated clusters + pinsets (https://cluster.ipfs.io/), which IMO is an ideal use case for public Bundles. I could obtain sponsored infrastructure for further prototype development.
Does FHIR-31422 need a different resolution beyond the last comment in the thread, which argues the spec already would permit use of IPFS in Bundle.fullUrls? Would some example implementations help progress that?
Josh Mandel (Jul 23 2021 at 15:52):
The comments on FHIR-31422 are just comments; the resolution is
- Bundle.entry.fullUrl: Add "e.g.," in the short definition to clarify that these are examples
- Bundle.entry.fullUrl: Update the full definition to clarify that Bundle.entry.fullUrl can be an arbitrary URI (is not limited to urn:uuid, urn:oid, http, and https, as suggested by the short definition) – per https://jira.hl7.org/browse/FHIR-29271
- Reference.value could use any URI scheme (in addition to using relative values like "Patient/123")
Josh Mandel (Jul 23 2021 at 15:52):
This should be sufficient to support IPFS URLs, etc.
Last updated: Apr 12 2022 at 19:14 UTC
