There was a question two or three weeks ago about HIPAA, and
making R:Base applications "HIPAA-compliant." HIPAA is the Health
Insurance Portability and Accountability Act.
I picked up many excellent links, details, and resources at a
conference this week, and had promised to share them with the list.
Here are two web links that are among the best:
Health Privacy Project
www.healthprivacy.org
This website provides a lot of plain English explanations of the issues
involved in complying with HIPAA.
Workgroup for Electronic Data Interchange
WEDI (pronounced WEE-dee)
www.wedi.org
SNIP
Strategic National Implementation Process
(part of WEDI)
And this web address:
Claredi
www.claredi.com
connects you to a third-party HIPAA transaction certifier. If you need
to prove to a client that your software generates medical insurance EDI
transactions that are "certified" HIPAA compatible, this is one way to
do it.
======================================
I am not an insurer, nor a medical provider. My client is not a medical
provider nor an insurer. But my client provides services to insurers that
involve handling PHI ("Protected Health Information"). That means my
client has Business Associates contract language with insurers, and
that I have similar contractual language with my client, making us all
accountable for protecting the privacy of all the individuals whose
records pass through our control. PHI data include anything that could
be used to connect an individual to private medical information. For
example, name, address, birthdate, telephone, SSN, email address,
and many other items.
Among the most important impacts this soon-to-be-effective legislation
will have on my R:Base/R:Tango applications are these:
1) Patients will always have a right to see who has accessed their file.
That means that the R:Base/R:Tango application should keep a log of
every time a user views confidential information. (right before the EDIT
USING or BROWSE command, e.g., have an INSERT command into
the log table.) And there should be a way to report all access of a
given individual's records.
2) Everyone with access to the system will have to be identified by the
application program, probably through a login process (so that the log
mentioned in (1) can work) Individuals, not shared groups with shared
logins/passwords.
3) For testing, training, and demonstration purposes, there will have to
be a way to "de-identify" all records in a database. We have a utility
that goes through all identifiable tables (like "insureds") in a copy of
the production database and generates new and bogus (or XXX'd out )
names, addresses, phones, social security, email addresses, next of
kins (nexts of kin?), beneficiaries, employers, etc.
And of course, we and our clients also are accountable for
administrative procedures, physical safeguards, and technical security
systems that prevent the same information from being disclosed
through mischief, malice, or accident.
============================================
I'm also planning to nag RBTI a little on a long-standing request for a
new R:Base command:
UNLOAD DATA FOR tableView AS FORMATTED USING column x y,
column2 x y, etc.
It would be the outgoing counterpart to the existing LOAD ... AS
FORMATTED command. This could be extremely efficient for
developers to quickly generate EDI transactions and data sets.
Bill
