How to Solidize Medical Dossier-Tool for patients

Together with a smart programmer, Tom Blauwendraat, I have developed MP50, MediPrepare2050. It allows patients through questionnaires with over 1000 questions, to create their own ‘professional medical dossier’ by translating the answers into information in a format that doctors learned in medical school.

This is open-source soon. If contacted I will share the code with you already. View how it works for the patient at https://mediprepare.1systeem.nl/en/questionnaire/guest/1/. It is in all languages, all ages, all media, and for all earthlings. Doctors can create their own questionnaires. The open-source community will help share with all, for all.

Why,? Because it saves more time to doctors then you on average get during appointments, so only by sharing information you have a chance to receive the best care.

Who helps Solidize this project? In my view is this the ultimate use-case for Solid.

More background is available on my [Figshare] and github MP50.

2 Likes

Welcome Hans, and thanks for introducing yourself and your project which I admire.

I’m not sure anyone in the Solid community has talked about this area before at least in any depth. It is an area I’ve come across in similar contexts though. One was a chap planning something very like this using some open source medical practitioner software - GNU Health I think - which he was aiming to port to SAFE Network.

Another is a chap working on decentralised data collection and sharing for anonymous verifiable health and fitness research using mobile apps. He has proof of concept demos on the Ethereum blockchain and I think also produced a demo with SAFE Network.

This isn’t my area, so just saying hello, but I will dig out links to discussions of the above if either is of interest.

Mark

Hi Mark,

I may not understand Solid. I had the impression that this use case would be very simple because the tool would deliver a simple PDF plus JSON-file to the pod of the patient. The patient uploads to his own pod. Quite straight forward I thought.

After that, it is up to the patient to share a link to this PDF and JSON-file with the latest and updated PDF-JSON (containing His Medical Dossier). This may be more complicated. However, I had the impression that exactly that part is what Solid solves.

Am I missing something? After a meeting about Solid at UTwente I talked with someone from MIT. It seemed He did not understand this use-case, while I think it would be the perfect and meaningful use case.

How do you look at this?

Regards, hans

I don’t see any problems with that approach.

I think you might go further, such as provide an app to allow the practitioner to view and update the patients record rather than just download the PDF, but there’s no reason you have to do that.

Hello @hanshendrickx

Nice project !

You can check this thread : Proof of Concept ideas for Generative Objects
I was indeed looking for projects cases to use the low code development platform Generative Objects.

The idea is that with Generative Objects you can model and generate full applications leveraging Solid. It could be a way to solidify your application. I will run an event in the weeks to come to demonstrate how to create a Solid application using Generative Objects, you can attend to have an idea.

The concern I see in your application is that it gathers personnal medical information, so the requirements are pretty high to be allowed to host this type of information. You need a hoster who got the compliance to host medical information, are you aware of it ? Then : can a user host his/her own medical information inside his/her own Solid POD, even if using a POD provider who does not have the medical hosting compliance ? this might be very tricky. You might want to check on this first, if not already done, this might be the biggest stuck point in your project.

Walter

Thanks Walter for your suggestions.

I may be wrong, is not the idea of Solid that the owner, i.c. the patient, shares and controls the content, i.c. his Medical Dossier PDF. I assumed from reading about Solid that it is military-grade protected.
You still need blockchain-like solutions? https://www.cs.ru.nl/~erikpoll/papers/blockchain-alternative2018.pdf.

I am puzzled about what exactly is solved by Solid. My use case may be a unique chance for Solid to demonstrate what it is worth in real life.

1 Like

Hello @hanshendrickx, Yes with Solid the patient would keep ownership and control of his/her data.
However, with Solid the user still relies on a provider to host his data, unless he/she hosts it on his/her own servers, which seems irrelevant for the majority of users.

So in my understanding, the provider hosting the Solid PODs needs to have compliance to host medical data. This is to avoid for instance having security weak providers, vulnerable to attack and access to personal medical data.

But I might be wrong ! This needs to be checked. And I am very interested to have information about this.

What is for sure : any application that collects medical data, even with consent of patient, must be deployed on a medical data compliant host. However, with Solid, the patient owns the data, and give authorization to applications to access or update his/her data. It might be that in this case that what I am sharing is not relevant. But this is a very sensitive topic to be checked.

Block-chain like solution is for another topic, around ensuring the truth of data, making sure data cannot be tempered with. It might or might not be useful for your project depending on the use cases.

Please tell me if you find more about this compliance topic. If you are willing to launch this project, I can help you, especially with low code technology that would help to build your application on top of Solid very fast, so let’s keep in touch !

https://www.nytimes.com/2020/03/09/technology/medical-app-patients-data-privacy.html

  • As a doctor, I always tell privacy lawyer: No data, no care!
  • The patient has the right to do with his data whatever he wants. That is his business. If he does not want to share, he may die.
  • My understanding was that Solid works as linked data: One POD share One Data Unit and if changed at source, all shared locations would be updated automatically, all under the control of the POD-owner. The POD owner could always retract the sharing. My understanding now is that this is naive. Problem then: What exactly is Solid solving?

My question to all: What exactly is solved by Solid, if it does not control shared-from-POD data. Maybe you could edit the question so it is eye catching to the community?

1 Like

The beauty is that there is actually no data copy (unless the app does so, but it is not supposed to do that!), so no shared location to update. Data is always accessed directly from the user POD, (and therefore always up to date) so that if the user forbid access to an application to his data, the application has immediatly no more access to the data.

What Solid brings is that not only the user has ownership at all time on his data, but this data can then be used by several applications. The user can decide to give access on his medical data to your application, but could also give access to any other application that would make use of the data. The data is no more stored directly in your application (old centralized way), it is your application that makes use of the patient data. And all patient data is stored in the patient pod, so that any application that would need to access to this data, have access to a single unit of data, and there is no more multiple, potentially outdated information stored in each separate application.

What Solid does technically is one thing. What is legally possible to do, especially when medical data is involved, is another subject. I let others answer if they have any clues or pointers on this legal question.

I would advise that you contact legal expert on that matter, they will be the one to help and tell you more. This topic on the governance adn confidentiality of data is always a subject whatever the technology used.

1 Like

Hi Walter,

I believe this use case shows exactly what needs to be solved before Solid could ever become successful. I did receive a mail from John Bruce and want to share that mail. You can read he does not mind sharing his PII. I spoke with a lawyer in EU and he told me that the patient can do whatever he wants with his data. Important issues are: can he revoke the sharing?: YES he can I understand; is transport of the data safe?: use VPN or scrambled data? need authentication first? Is blokchain needed? I have no clue about that.
I spoke with someone half a year ago at UTwente in Holland from MIT. He did not take the challenge to help me and show how to bring this use case as an introduction case. Everybody could understand the significance. I am puzzled what the problem is. I do not believe that that is the privacy issue.

Reply to communication at interupt:

Regarding your questions. You could enroll patients who would then complete your questionnaire and securely store that data in their PODs. They can then share that data with whoever they consider appropriate, such as their doctor.

The technology is currently best used by software developers who are familiar with working on early stage projects. It’ll be a little while before it’s ready for more general consumption. If you have technical staff involved in your effort, please point them our way and we’d be happy to steer them appropriately.

Yes he can revoke the sharing. Transport of the data safe => secured https connexion, so as safe https is. The people you are sharing with need to authenticate first before being allowed to see your data. I don’t see why blockchain would be needed : the patient owns his data, so no-one can tamper with it for malicious reasons.

So what is you exact use case ? I understand that you have a tool called MP50 already existing. Are you keeping this tool, exporting a PDF from it and this is this PDF that is shared using Solid? Where is this MP50 hosted ? Since the patient is already entering data in MP50, and somehow trusting MP50, why can’t you share directly the PDF from MP50 ? It does not seem logical to me to have a mixed approach with data stored and duplicated in a server application (MP50) and in Solid, because then you lose all the interest of being in Solid. For me it is either all the patient data is in MP50 or all the patient data is in Solid. So you would have to either rewrite all in Solid, or evolve your MP50 application so that the questions/answers mecanism stays in MP50 but no patient data is ever saved in MP50 but directly in Solid. Does that make sense for you ?

Walter, spot on. I am retired doc, worked over 50 years in healthcare. MP50 is my pet.

I am looking at possibilities to give the patient charge of all data, make him the CEO of his health care. Some info about MP50: I want it to become open source (this month), working on that with Sosaro.com. It is designed so doctors-non-programmers can create dynamic questionnaires and built-in their expert knowledge. My vision is to develop a system like Overleaf.com which allows to adjust/copy paste code and immediately view the client-UI. https://plnkr.co/ has something like that as well. Unique to MP50 is that the patient is asked 250-1500+ questions in understandable language, and that the answers are compiled into a 1-2 page PDF, 3-second review, for the doctor, in all languages. See how it works at https://mediprepare.1systeem.nl/en/questionnaire/guest/ to view a sample PDF click button. The JSON-db can be reused by importing by the use of token. My dream is to store the PDF and DB in Solid.

Reusing the Solid POD lifelong: after creation of a PDF, the patient could login, get his latest PDF, update, create a new timestamped PDF that replaces the old PDF. That way every doctor always could view the updated Medical History and latest complaint. Each PDF can be translated into each language (we now have 2 languages in our MVP). I am working with MD’s on improving and expanding questionnaires for 130+ specialties, 100,000 diseases and 20,000 signa and symptoms.

MP50 does NOT deliver diagnoses except the known diagnoses (at source, the patient). However, interaction during appointments will improve the PDF by instructions by doctors to add say the Pacemaker number.

This save tremendous appointment-times. See my blog at https://figshare.com/authors/Hans_Hendrickx/6880208
Best-Care=Function of (time) and (information).

In short: How to use Solid PODs in this model, and NOT store any data on our server. We believe each clinic could use their own server in cloud or on premises. This is modeled by f.e. Divio.com. I would like to focus on the medical content, IT-company focus on the servers and programming. To maintain the open source I need some recurrent income from the best questionnaires and translations. MP50 should become available to each patient in the world. That way patients can help their providers at the on average 500 care-contacts during their life. The Medical History is available by linked-data/information model: one source, one owner.

Any further suggestions? I appreciate your analysis.

3 Likes

@hanshendrickx sorry for my late answer, I was busy on other matters….

I understand there different type of data :

The questionnaires, today for 130+ specialties, 100,000 diseases and 20,000 signa and symptoms. This feels like an expert, domain specific database, that needs to be stored somewhere. It is not personal data, but expert data. It can be stored on a central location.

However, the questionnaires being created by doctors, we can imagine that the questionnaires are stored on the Solid POD of the doctor who created it. All the existing ones could be on your POD, and the new ones on whoever is creating them.

Then personal data are the answers to the questionnaires for every patient. It makes sense that this data is stored on the patient Solid POD, with linked reference to the questionnaire(s) for which the answers are.

By the way, comes also the point of versioning the questionnaires, because if the questionnaire evolves, then a given set of answers might not correspond anymore to the latest version of the questionnaire, and we need to still be able to refer to a previous version of the questionnaire.

The generated PDF is from the patient answers, it is also personal data, also stored on the patient POD.

The doctor can add precisions to the patient PDF, for example pacemaker number. This extra information can be stored in patient POD with linked reference to the doctor who created this data.

For the rest, it is a matter of evolving your existing application to connect to the data in this decentralized stores instead of your existing database. You can put me in contact with the developer who is working on MP50, I am open sourcing my technology (Generative Objects), which is now connected to Solid and can be used to very fast model data to be stored to Solid and generate the code for you. It can generate full applications, including front end, but in your case you could only generate the part that connects to Solid and integrate it in your existing MP50 through the generated API you will get. Warning : it is still experimental, but I am fully dedicated to make it work, so if you are ok with this, I am happy to help.

Also comes the point to connect patients and doctors. I guess that from his application, the patient could find the name / address / identification of his doctor so that he/she can explicitely authorize the doctor to access his/her data. There must be some doctors directory to list all the doctors connected to MP50, and same the other way round : a way for a doctor to find a patient, so a directory listing all patients. Not so sure about this part though, but there may be other ways to do (exemple : when you meet your doctor, you let him scan your qrcode integrated in your app, so that the connection can be made very easy)

By the way, this is the announcement of the open sourcing of my technology : https://modeling-languages.com/low-code-open-source-platform-generative-objects/

Hope it helps.