> I don't want to sound too critical here, since you are probably way ahead
of the
> field in implementation terms, but there is a problem with this. Clinical
> information is like any other non-trivial information - complex and
> interrelated. If I ask for the fact that I have HIV to be supressed, what
column
> is this in, and what else gets suppressed? And someone has to remember to
> suppress the AZT and/or other indicative medication entries. But
presumably, we
> can't just suppress "current medications" column(s), since that would wipe
out a
> lot of things.
>
> To selectively encrypt information will require something quite smart,
which
> operates at the level of clinical concepts such as "problems", not
database
> columns or object fields.
Implementation is straightforward. Every single attribute in a Postgres
table has a unique OID (this OID is unique within the whole system). There
is a table "crypt" with indexed "crypt_OID"s - unique identifiers for
ancrypted attributes.. It is up to the client software to flag any attribute
as "encrypted" and set the attributes in the "crypt" table regarding
algorithm and passphrases. The implemetation is that a right-click on any
entry field gives you the encryption option.
Whenever a table is updated, a trigger function checks whether this atribute
should be encrypted and if so, how. The trigger looks up the passphrase
cache and prompts the user if necessary.
Whenever an attribute is selected in a query, a trigger will check whether
the attribute is encrypted etc.
If the passphrase is cached (and this is optional), cryption happens
completely transparent and without perceivable delay (unless you select
thousands of records at once).
Horst
