On January 17, HHS released the Final Rule entitled: Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules under the Health Information Technology for Economic and Clinical Health Act and the Genetic Information Nondiscrimination Act; Other Modifications to the HIPAA Rules
It's 563 pages long and contains 7 themes:
Covered entities must ensure that they obtain satisfactory assurances required by the rules from their business associates, and business associates must do the same with regard to subcontractors, no matter how far 'down the chain' the information flow
Increases penalties to $1.5 million per year
Tightens limitations on the use of patient records for marketing
Prohibits the sale of patient information without a patient's consent.
Provides patients with a right to insist that a provider not share their patient-care records with their insurance company if that care is paid for by the patient out-of-pocket in full.
Requires entities with patient record breaches to assess the likelihood that the information could be accessed in determining whether they must notify individuals of the breach.
Adds patient-safety organizations, health information exchange organizations and e-prescribing gateways to a specific list of HIPAA business associates liable under the rule. It also includes as business associates certain vendors of personal health records, those that provide a PHR to patients “on behalf of a covered entity,” but excludes other PHR providers, such as those working on behalf of consumers.
Much of the final rule is a restatement of requirements in ARRA/HITECH and GINA. Generally the recommendations are very reasonable. One challenging aspect of the final rule is the provision that provides patients with a right to insist that a provider not share their patient-care records with their insurance company if that care is paid for by the patient out-of-pocket in full. At present this will be technically challenging to implement. For example, if a patient pays for their outpatient treatment in cash and an e-prescription is generated, how do we flag the prescription to ensure it does not flow into a Pharmacy Benefit Management database? If an inpatient hospitalization is paid in cash, how do we prevent a nurse case manager working for a payer from seeing any data related to that care episode? Such data segmentation needs metadata around each data element so that data flows can be selectively restricted. A great goal but definitely a work in process for which no products nor standards exist.
In the workplan for FY13 that I presented at the January HIT Standards Committee meeting, I highlighted the need for our workgroups to study standards supporting data segmentation for privacy, so hopefully we'll close this gap in the next year and have products in the marketplace which support such controls by 2014.
I know that many groups are hard at work analyzing the new rule, so I look forward to their wisdom. The rule's 563 pages are rich with detail.
On SELF-PAY. The challenges in hiding data *derived* from "self pay" are indeed challenging. The difficulties shown may be best understood as instances of more general problems: Provenance and Derivation. The solutions should be general, contributing to a variety of capabilities.
Obligations based on provenance require mechanisms to describe provenance, to attach the description, and to write predicates that reference the provenance. Provenance (e.g., self pay for privacy, institution covered by 42CFR restrictions) is just another kind of metadata that can be referenced in making decisions. Like most metadata, the provenance should be sticky as data is forwarded, so that when reforwarding occurs, policies applicable to that metadata tag will be applied. (That is, control over reforwarding is best handled by data properties, rather than including policy with the forwarded item).
As you point out, derived products introduce other complications. Technically, it seems desirable to treat derived data as additional objects, that need to be tagged with appropriate provenance. But now the mechanism for attaching tags sometimes needs to be granular, for example for individual items in a medication list, not just for whole documents. Such an attachment capability is easy in principle, but not easy with legacy software.
A tricky aspect is whether to let creators of a derived product decide if it retains the confidentiality level of the original. An encounter description reveals a great deal, while a count of number of encounters (also a derived product) reveals little, and there are many points along the spectrum.
For both issues, while the law may require such support only in specific cases today, we want eventually to support whatever is most appropriate for each patient. Rather than repeatedly extend special data structures like D4SP, generality will require general languages that support taxonomies and relationships, such as OWL.