## Status: DRAFT
So for context, I just left a job working for an Australian …practice management software vendor, and during my time there I was involved in a technical working group, which exposed me to some of the industries technical and political issues. What follows is a rough draft of issues and soon to be added to potential solutions.
The medical software industry has many issues, below are a few that I see as critical to the industry to moving forward:
### Technical Issues
- secure, reliable storage of patient data
- consistent implementations of actually interoperable protocols
- historically, very closed (read: proprietary) industry with rampant vendor lock-in
- secure, reliable exchange of information (read: messaging)
- historically, slow to adopt new technology, usually this is due to high development costs, though not always
- secure identity infrastructure that is open usually needs to be provided for free by an 'unbiased', authoritative organization, i.e. government
- protocols and standards are extremely difficult to, firstly, implement, secondly, upgrade and MUST be backward compatible
- large amounts of unversioned almost duplicated patient data
### Ethical Issues
- a patient's data is sharded across the multiple practices and hospitals that they visit in their lifetime, with 'no real' avenue[^1] for the aggregation and distribution as a consistent volume. A patient, with everything that being a human, entails, biased listening, poor recall, etc, is required to be *THE* source of truth, even though they are rarely provided with any *actual* data, only spoken diagnosis. This sharding leads to several issues, i.e. doctor shopping (the bad kind, see [wiki](https://en.wikipedia.org/wiki/Doctor_shopping)) is easier as patients get to choose exactly what they share (read: hide information), doctors are able to make changing doctors difficult by not releasing a patient's charts.
### Political Issues
- There is a mine field of political issues in healthcare, and it is easy to step on people's toes. Just something to be aware of. YMMV.
- Government buy-in can be critical or required for progress to be made.
### Privacy/Security Issues
- A technical solution may need to contend with standards like [HIPAA](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/index.html)
- Several countries require that the personal information of its citizens is stored on servers located in that country. Especially, in the case of health-related information.
## SOLUTIONS
### Multiformats
The medical software industry suffers from an abundance of protocols and standards, both open and proprietary, at different levels of the software stack. Backward compatibility is a significant priority in the industry, and as such adoption of new or updated protocols/standards is historically slow as without easy, cost-effective, upgrade paths most businesses don't see the benefit.
This is where I see multiformats, with its self-describing nature, being of great benefit. Here is a list of reasons/benefits:
- increased interoperability as exact versions/formats can be determined at runtime
- this results in less coordination between organizations beforehand, which is a big win in the health tech space 👍 👍
- easier to define programmatic upgrade and downgrade paths
- the format of stored binary data can always be determined (i.e when data has been retrieved from a REST API and stored, the version of the API, which will usually indicate the format of the payload, isn't usually found in the payload itself)
### Data Ownership + ACLs
The 'cloud' age, according to many in the health tech space is meant to result in patients having greater access to their records and therefore be able to access better healthcare (practitioners will have access to better data), or cheaper healthcare (patients will be able to shop around for cheaper healthcare providers without the difficulty of dragging around their printed out medical records from their previous doctor).
I believe this is false, all the 'cloud' age is doing for patients is moving their data from the server in the backroom of their doctor's practise and into a database owned and operated by some SaaS provider that may or may not go bust (leaving the patient without the records that were entrusted to them). At a [Hacking Health](https://hacking-health.org/) event last year, two-thirds of pitches put forward the concept of a cloud-based patient data consolidation app, which was put simply, a nice UI put over what would need to be a constantly expanding integration engine.
An alternative solution to this is to use IPFS as a data layer that is shared by all healthcare related applications. A patient would have a globally unique ID that linked to their medical records (CRDT??). The technical difficulties involved in this approach relate to how a patient would grant and revoke access to specific 'sub-trees' of their records (i.e. your chiropractor doesn't need access to your blood results, just your spinal x-ray). What identities to recognize (i.e. individual, organizations, organizations representing individuals, services provided by organizations, individuals providing services, etc) and how they are able to interact is a complicated aspect of this approach (though not unique to this approach).
### Identity Scenarios
1. Contracted Service Provider
```
┌────────────────────────────────┐
│ Doctor2 uses a Cloud Practice │
│Management Software (PMS), which│
│means that Doctor2 has entrusted│
│ them to receive messages on │
│their behalf from other doctors │
│ and pathology labs. │
└────────────────────────────────┘
┌────────────┐ ┌─────────────┐ ┌────────────┐
│ │ send msg │ │ │ │
│ Doctor1 │─────────────────────▶│ Cloud PMS │──────▶│ Doctor2 │
│ │ to Doctor2 │ │ │ │
└────────────┘ └─────────────┘ └────────────┘
┌───────────────────────────────────────┐
│How does Doctor1 establish that Doctor2│
│has entrusted Cloud PMS to receive │
│messages on their behalf? │
│ │
│Some constraints on how: │
│ │
│- Doctor2 CANNOT gift their secret key │
│to Cloud PMS │
│ │
│- Doctor2 SHOULD be able to leave Cloud│
│PMS and Cloud PMS SHOULD NOT be able to│
│handle messages of Doctor2 │
└───────────────────────────────────────┘
```
Side note: the Cloud PMS, if they are to stay in business long, will have many customers, in networking terms, they represent a router in the messaging system between doctors but only inbound.
2. Patient gives access to a subtree of their data
//TODO
//TODO: aspects yet to cover: ipfs-cluster + ~some form of geographical scoped tagging or the use of country-specific ipfs networks
[^1]: a patient is allowed to request a doctor to export their records but the doctor has a 'right' (in Australia) to charge the patient a 'processing' fee.