Comments in text.
Regards!
-Thomas Clark
HO,ANDREW wrote:
Quoting "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
...
withoutInformation archiving, retrieval and update cannot be completed
holdthe Patients active participation. The Payer and Provider can each
The Patient or the Patient's representative holds a key. The representative can be aa key that individually and together cannot create access to theSounds very interesting.
information and join the constituent parts.
What do you mean by "active participation"? Does the patient hold/present a key too?
legal representative, a family member or a private security agent. Both the Patient
and the representative should have a tool to audit requests for access.
The key is in turn limited/restricted, i.e., you can access records related to a
specific condition my not other non-related conditions. It would also be
in part
declarative, e.g., the Patient can withhold permission to use their DNA.
The Patient's key would have a structure compatible with their records
hence
their would be a Patient-specific format that supported general
information,
e.g., date-of-birth.
This sounds good and very useful.
Typically in a key-based system, the most difficult part is key management - from the moment of key creation. In your design, who creates these keys and how does the system assure the security of that process?
...
The keys CAN be generated automatically however it is interesting that the Patient could supply
additional personal information that would be included, e.g., some information from their past
that would be difficult to obtain otherwise, such as the color of their first automobile.
The repository of the Patient's records, assuming archival functions, could generate keys for the
Patient on a periodic basis and where new records are received. Important is the ability to
update the key the Patient carries. It would still remain 'active' until the Patient updated their
key.
What if the patient loses his/her key?Patient keys can be re-generated from Records-based information (similar to fault-recoverable file systems).
What prevents non-Patients (e.g. evil government agents) from re-generating patient keys?
To regenerate the keys non-Patients would have to have access to the records, and key-generating
algorithms that use them, the Patient's personal information, the current key, and the Patient.
The repository can be placed outside the jurisdiction, e.g., in multiple, dispersed,
redundant, cooperating jurisdictions, e.g., Bermuda.
Yes. A quick way of determining that the records base has changed is required. ThisSince the key is not saddled with a fixed format, additions and modifications will modify the key.
Do you mean changing information in patient records always lead to a modified key?
should initiate other supporting activities. An underlying presumption/requirement is that the
records base is redundant. How redundant is an issue but for sure one would not want to
lose this information (Kaiser should be listening).
New records translate into change. Access using an old key provides an opportunity to
look closer at the requestor. Notification to the Patient may be proper. What response
the Patient desires may be pre-loaded.
There are many other unresolved issues that touch areas that affect the Patients and supportThe Patient provides information and updates rules.
That sounds good.
The physical format of a key is simple. 256 MBytes in the volume occupied by a 25 cent coin leaves some room for other things. You might inject it like my dog's ID,
I agree. We can store keys on portable devices. However, there may still be unresolved issues relating to key-regeneration and key-updating.
groups but are well beyond the scope here.
Appreciate your interest.!
Best regards,
Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
