4 ms·

Proper password files store the salted and hashed key, not the key. The practical downside is that if the user forgets their password, they lose access to thei

Proper password files store the salted and hashed key, not the key. The practical downside is that if the user forgets their password, they lose access to their account. So for medical records, the original key (password) requires offline paper (or equiv) backup.

sidewndr46 3y ago
Medical records are not stored for the patient to access. They are stored for the provider to access and in the event of a legal dispute, for the courts to subpoena.
- specialist 3y ago
  As a patient, do you think that's satisfactory? Have you seen patient portals like (Epic's?) MyChart? Aside: During the mid-aughts, I created a patient portal POC, to compliment our physician portal product. Customers were very interested. Ditto the clinical (vs diagnostic) quality web-based DICOM viewer I made. (Sadly, the 2008 meltdown /dev/null'd all of our work.)
  - nradov 3y ago
    Authorized members of a patient's care team need to be able to directly share clinical data with each other. Trying to route everything through some sort of patient portal isn't practical, and would lead to delays in care or quality problems. Patients should have access to all of their data but the patient portals are spokes, not hubs. Patient portals tied to a single vendor like Epic MyChart aren't great, but they work well enough for patients who receive all of their care through a single integrated health system. Attempts to create universal patient portals not tied to a particular payer or provider organization have generally failed because no one wants to pay for them. Apple is trying this again but they only have interfaces with a limited set of data sources.
    - specialist 3y ago
      Yup. We first shipped a Physician's Portal and merely demoed the Patient Portal POC. Our patient facing product was way too early for the market (late-aughts).
  - sidewndr46 3y ago
    as a patient I'd prefer all my records destroyed the minute the doctor is done looking at them. Almost all of my PII and medical information is in the hands of bad actors because of this needless retention
    - specialist 3y ago
      Ah. In that case, you should employ care givers who accept cash. Like a shaman. Or a doctor whose license has been revoked. Good luck!
jfyi 3y ago
This doesn't seem to be the right way to handle keys for bulk data at rest, even assuming you were doing it to enforce patient approval. A password wouldn't be appropriate for direct use as an encryption key. So I guess you could hash the password and use that for the key for data encryption and then hash it again and store the second hash for authentication. Salting appropriately of course. That feels weird to me, I wouldn't trust I saw every angle on that. Regardless, it would drastically lower the entropy of the key space that way unless you have downright draconian password requirements. How did you implement this in the POC you spoke of?
- specialist 3y ago
  I think I crossed some wires here, confusing encryption key with database (uuid) key. Let me try again. Very briefly, a proper password store must not use plaintext. Rather it must use ( password + salt ) * hash. Similarly, PII (name, MRN, etc) must also be salted and hashed. What Translucent Databases adds is showing how to cleverly use those hashed values for common use cases. Like how to use hashed MRNs as indexes (keys) to other data such as lab results. It takes some getting acquainted, but designing schemas will start being intuitive after a bit.
  - jfyi 3y ago
    I am trying to figure out how hashes being used as indices and password storage has anything to do with the storage and encryption of bulk data at rest. Can you elaborate? Edit: I see you aren't actually encrypting it. So you are as the post said, just throwing away the keys (in a sense). You are talking about storing and indexing metadata.
    - specialist 3y ago
      Translucent Databases applies the design of a properly implemented password store to additional use cases. Such as hiding PII. Sensitive data (passwords, PII) is absolutely encrypted. I apologize for assuming everyone here knows how passwords should be stored. My reference to "hash" is shorthand for "secure one-way hash". Please refer to the Translucent Databases book for any further questions you may have.

sidewndr46 3y ago

Medical records are not stored for the patient to access. They are stored for the provider to access and in the event of a legal dispute, for the courts to subpoena.

specialist 3y ago
As a patient, do you think that's satisfactory? Have you seen patient portals like (Epic's?) MyChart? Aside: During the mid-aughts, I created a patient portal POC, to compliment our physician portal product. Customers were very interested. Ditto the clinical (vs diagnostic) quality web-based DICOM viewer I made. (Sadly, the 2008 meltdown /dev/null'd all of our work.)
- nradov 3y ago
  Authorized members of a patient's care team need to be able to directly share clinical data with each other. Trying to route everything through some sort of patient portal isn't practical, and would lead to delays in care or quality problems. Patients should have access to all of their data but the patient portals are spokes, not hubs. Patient portals tied to a single vendor like Epic MyChart aren't great, but they work well enough for patients who receive all of their care through a single integrated health system. Attempts to create universal patient portals not tied to a particular payer or provider organization have generally failed because no one wants to pay for them. Apple is trying this again but they only have interfaces with a limited set of data sources.
  - specialist 3y ago
    Yup. We first shipped a Physician's Portal and merely demoed the Patient Portal POC. Our patient facing product was way too early for the market (late-aughts).
- sidewndr46 3y ago
  as a patient I'd prefer all my records destroyed the minute the doctor is done looking at them. Almost all of my PII and medical information is in the hands of bad actors because of this needless retention
  - specialist 3y ago
    Ah. In that case, you should employ care givers who accept cash. Like a shaman. Or a doctor whose license has been revoked. Good luck!

jfyi 3y ago

This doesn't seem to be the right way to handle keys for bulk data at rest, even assuming you were doing it to enforce patient approval. A password wouldn't be appropriate for direct use as an encryption key. So I guess you could hash the password and use that for the key for data encryption and then hash it again and store the second hash for authentication. Salting appropriately of course. That feels weird to me, I wouldn't trust I saw every angle on that. Regardless, it would drastically lower the entropy of the key space that way unless you have downright draconian password requirements. How did you implement this in the POC you spoke of?

specialist 3y ago
I think I crossed some wires here, confusing encryption key with database (uuid) key. Let me try again. Very briefly, a proper password store must not use plaintext. Rather it must use ( password + salt ) * hash. Similarly, PII (name, MRN, etc) must also be salted and hashed. What Translucent Databases adds is showing how to cleverly use those hashed values for common use cases. Like how to use hashed MRNs as indexes (keys) to other data such as lab results. It takes some getting acquainted, but designing schemas will start being intuitive after a bit.
- jfyi 3y ago
  I am trying to figure out how hashes being used as indices and password storage has anything to do with the storage and encryption of bulk data at rest. Can you elaborate? Edit: I see you aren't actually encrypting it. So you are as the post said, just throwing away the keys (in a sense). You are talking about storing and indexing metadata.
  - specialist 3y ago
    Translucent Databases applies the design of a properly implemented password store to additional use cases. Such as hiding PII. Sensitive data (passwords, PII) is absolutely encrypted. I apologize for assuming everyone here knows how passwords should be stored. My reference to "hash" is shorthand for "secure one-way hash". Please refer to the Translucent Databases book for any further questions you may have.