3 ms·

The issue is Accountability. It is more important to know "who/when/why" are people looking at your records that stoping people from accessing them all togethe

• macnix 13y ago
  All successful and failed transactions against any resource gets logged. We haven't exposed it in the API yet, but it's coming.
  • specialist 13y ago
    I'm guessing that you're updating records. So you're resolving what's "truth" during the inbound operation. (For readers: data may be received out of order, so implementers must resolve the single source of truth in near real-time.) Our systems used to do that. My redesign eliminated updates, did only inserts, and resolved the "truth" during the query. Greatly simplified everything. No more "historical" table, where deltas are logged. Determining what was known when (determining liability) queries were simply date bounded. No need to "rerun the data" when a mapping or business rule changed. Etc.
    • macnix 13y ago
      No updates, no real deletes either (only virtual ones). Data about transactions is stored separately from the clinical data, in an optimised store for log data.
• specialist 13y ago
  Exactly. About 5 years ago, I was looking to add tamper evident logging to our systems. At the time, the state of the art was a rolling hashcode chain. Add a SHA field to each log event, which includes the delta, so that you can tell if someone altered any of the log entries. There's now algorithms which factor for untrusted / insecure loggers. I haven't digested those papers yet. But it's just a bandaid. Because I can still root to the OS, database. Tamper evident logging must be done at the lowest levels. (If anyone knows of such a project, please share a link.)