There are three projects this semester. Each project will result in a written report that must conform to the 8.5" x 11", Two-Column IEEE Conference Proceedings Format IEEE CS publication standards. The Ethics Project will be done either individually or in pairs chosen by the students. The other two projects will be done in groups assigned based in part on student responses to the survey conducted on the first day of class. The Final Exam for this class will be replaced by an oral presentation of the Re-Identification project.
BrightWhistle is a social patient acquisition company. It seeks to accurately identify potential patients and match them with high-quality doctors capable of meeting their needs. To do this, BrightWhistle uses technologies to target individuals with advertising and marketing materials as well as manage this lead until the individual becomes a patient. This service has clear benefits for both hospitals and patients needing care. However, the ethical use of targeted advertising technologies is currently being debated by numerous regulatory agencies across the globe, including the U.S. Federal Trade Comission. Students are expected to produce a report describing the ethical tradeoffs of technologies used in social patient acquisition. BrightWhistle is interested in this analysis both to make ethical business decisions as well as assure customers that they genuinely care about patient health and safety.
The project consists of a five page report detailing the ethical tradeoffs involved in online marketing with a focus on the specific tools and techniques used by BrightWhistle. This report must include guidelines or recommendations for BrightWhistle to use in determining their levels of targeting. Students should consider themselves to be third party auditors preparing a report for BrightWhistle that may eventually be used by the FTC to audit BrightWhistle’s business practices. Since BrightWhistle works extensively on the Facebook platform, the report should reference Facebook’s Terms of Service, Facebook’s custom audience targeting tools, and potential opt-out mechanisms Facebook users have.
This project will be due January 29, 2013.
The Health Insurance Portability and Accountability Act (HIPAA) became law in 1996, before much of the modern Internet was developed. The Health Information Technology for Economic and Clinical Health Act (HITECH) updated HIPAA to address some of these limitations, but many aspects of cloud computing are not directly addressed by HIPAA or any amendments to HIPAA. Students choosing this project will examine Brightwhistle’s use of several cloud-based services, including Amazon Web Services and Facebook’s APIs, for HIPAA compliance. Their analysis must include discussion of both the BrightWhistle architecture as well as the legal implications of using cloud computing service for healthcare data.
Students are expected to identify potential areas of concern and to make specific recommendations for addressing those concerns. For example, HIPAA defines protected health information (PHI) explicitly and further defines additional security measures required when handling PHI. Is it possible to identify or access PHI using only BrightWhistle’s non-PHI data stores and protocols? HIPAA also proscribes explicit use of encryption for healthcare data. Does BrightWhistle’s source code and architecture meet these requirements, particularly with their use of third-party cloud-based APIs? If so, how can BrightWhistle demonstrate that they have met these legal obligations?
Research reports in this project should seriously consider addressing many, if not all, of the following additional concerns:
Does BrightWhistle’s local storage of data meet HIPAA/HITECH requirements? The HIPAA/HITECH regulations also apply to local data storage.
Encryption in the cloud is a hot topic. It is, however, rather complicated. Amazon has released specific information for meeting HIPAA requirements while using Amazon’s web services. Does BrightWhistle meet the HIPAA/HITECH requirements in its use of the Amazon web services API? Does BrightWhistle meet Amazon’s recommendations as well? Are there other security concerns BrightWhistle should address based on their use of cloud-based APIs for storing or accessing data? Are there other features of the Amazon API that BrightWhistle should consider using?
BrightWhistle aspires to separate possible PHI from other business data. They adopted this goal in part because they believe that co-mingling of data may lead to HIPAA/HITECH violations. Does this ￼goal meet or exceed the HIPAA/HITECH requiments? How has BrightWhistle done in their efforts to achieve this goal?
BrightWhistle understands that legal compliance is not a one-time concern. They want to build-in au- diting and assessment of their practices to ensure that HIPAA/HITECH compliance becomes a part of their company culture. What recommended improvements can you make to their software development process based on their current source code, system architecture, and use of cloud services?
The deliverable for this project is a six page report to be completed in groups assigned by the instructors. The project will be due on March 6th, 2013.
HIPAA explicitly defines what it means for protected health information (PHI) to be de-identified. However, previous researchers have determined that de-identifying data is challenging. Numerous researchers have re-identified supposedly anonymous datasets. In this project, students will take a set of data that’s been de-identified according to HIPAA regulatory guidelines and attempt to re-identify individuals in the dataset specifically for marketing purposes. Determining the ease with which this data can be re-identified will improve BrightWhistle’s ability to perform accurate risk assessments of and security assessments for the data.
Re-identification, particularly re-identification for marketing, can occur at many levels. Groups of individuals that share similar demographics and tastes or have similar resources at their disposal are extremely attractive and efficient marketing targets even none of them are known by name. In addition, BrightWhistle could learn more about actual and prospective patients using public datasets. In an era of individually-targeted advertising, it may be even more attractive and efficient to be able to distinguish between each individual. In this project, students are encouraged to create a methodology for re-identifying individuals from the HIPAA de-identified dataset as specifically as possible for two purposes:
Students must attempt to discover the real-world identities of individuals for the purpose of exploring the limits of re-identification efforts using HIPAA de-identified data. If it is possible to re-identify individuals that have been de-identified in compliance with HIPAA guidelines, then there are serious ethical and policy concerns to address before using this data for marketing purposes. Can BrightWhistle determine exactly who sees their ads?
Students must attempt to discover the most specific marketing groups possible using the HIPAA de-identified data. BrightWhistle seeks to market to as many different, specific groups as possible. What are the limits of targeting groups based on HIPAA de-identified data? How likely are individuals from the HIPAA de-identified dataset to fit into pre-defined marketing groups? Can BrightWhistle ensure their ads are only served to relevant groups of people?
The deliverable for this project is a report consisting of a minimum of eight pages and a maximum of ten pages, excluding appendicies. The project is due on April 18, 2013.
During the final examination period, each student will give a presentation in which they describe their practical project. Length of presentations will depend upon course enrollment. Slides for each presentation must be submitted by 6:00 pm on the day prior to the presentations on T-Square.