Data Protection

Archive for Data Protection

Digital Transformation in Pharma: Digital Pharma West

Like the rest of the healthcare industry, the pharma industry is also grappling with lots of data, disconnects from end-users, and shifting to a digital-first experience while grappling with ongoing regulatory and privacy challenges. Actually it’s pretty much what every industry is grappling with, so the good news is that no one is getting left behind in this digital revolution.

In pharma though, the division between commercial and R&D creates both delays and lags in implementing new technology and the regulatory challenges cause specific issues in communication with both providers and patients.

Last week, I was invited to speak at Digital Pharma West about our work in voice-enabling care plans for people with Type 2 diabetes, and also how our participation in the Alexa Diabetes Challenge enabled us to engage with pharma. It was my first ‘pharma-only’ conference, so it was interesting to contrast with the provider and healthcare IT world.

If you think that there are a lot of constituents who care about digital health in provider organizations, pharma rivals that. For example, there was a discussion about the value of patient-facing digital tools in clinical trials. While everyone agreed there could be real value in both efficiencies of collecting data, and engaging patients and keeping them enrolled in trials, a couple of real barriers came up.

First the question of the impact of the digital tools on the trial. Would they create an intended impact on the outcomes, for example a placebo effect? Depending on how the “usual care condition” is delivered in a control group, it might not even be possible to use digital tools in both cohorts, which could definitely impact outcomes.

Another challenge with digital technology in randomized control trials is that technology and interfaces can change much faster than drug clinical trials. Considering that elapsed time between Phase 1 and Phase 3 trials can be years, also consider that the technology that accompanies the drug could change dramatically during that period. Even technology companies that are not “moving fast and breaking things” may do hundreds of updates in that period.

Another challenge is that technology may advance or come on the market after the initial IRB is approved, and while the technology may be a perfect fit for the study, principle investigators are hesitant to mess with study design after IRB approval.

Interestingly, while in the patient-provider world the number of channels of communication are increasing significantly with mobile, texting, web, and voice options, the number of touch points in pharma is decreasing. Pharma’s touchpoints with providers are decreasing 10% per year. While some may say that this is good due to past overreach, it does make it difficult to reach one of their constituents.

At the same time, regulations on approved content for both providers and patients means that when content has had regulatory approval, like what you might find in brochures, on websites, and in commercials, the easiest thing to do is reuse this content. However, new delivery channels like chatbots and voice don’t lend themselves well to static marketing or information content. The costs of developing new experiences may be high but the costs of delivering content that is not context or end-user aware can be even higher.

At the same time, these real-time interactive experiences create new risks and responsibilities for adverse event reporting for organizations. Interestingly, as we talk with pharma companies about delivering interactive content through the new Wellpepper Marketplace, these concerns surface, and yet at the same time, when we ask the difference between a patient calling a 1-800 line with a problem and texting with a problem there doesn’t seem to be a difference. The only possible difference is a potential increase in adverse event reporting due to ease of reporting, which could cause problems in the short term, but in the long term seems both inevitable and like a win. Many of the discussions and sessions at the conference were about social media listening programs for both patient and provider feedback, so there is definitely a desire to get and make sense of more information.

Like everyone in healthcare, digital pharma also seems to be at an inflection point, and creativity thinking about audiences, channels, and how to meet people where they are and when you need them is key.

Posted in: Adherence, Clinical Research, Data Protection, Health Regulations, Healthcare Disruption, Healthcare Policy, Healthcare Research, Healthcare Social Media, Healthcare Technology, HIPAA, M-health, Outcomes, pharma, Voice

Leave a Comment (0) →

4 Reasons Why the Future of Health IT is Serverless (AWS re:Invent 2017 wrap-up)

The big theme at AWS re:Invent 2017 was serverless computing. Whether deploying microservices in containers using ECS, Kubernetes, or Fargate, or building systems using Lambda that connect to serverless relational databases like Serverless Aurora or DynamoDB, Amazon is rapidly moving to remove “undifferentiated heavy lifting” common to building and deploying software applications.

Healthcare has historically been slow to move to the cloud. Some of this stemmed from spotty HIPAA eligibility, and from a desire of health systems not to be the first to break new ground. Today, however, many of the barriers have been cleared away: serverless technologies like Lambda and ECS are already on Amazon’s HIPAA-eligible services list with many more likely to come in the future.

There are many benefits to serverless architectures, including faster time to market, lower operating costs, and lower complexity. Here are 4 compelling reasons why serverless systems are uniquely positioned to thrive in healthcare:

Improved Security

The HIPAA security rule contains a number of requirements for server security. You’d be hard pressed to find a list of security recommendations that doesn’t start with patching your servers. Indeed, over the last year unpatched servers have led to several major security incidents and breaches. There are many (poor) reasons why people don’t patch. Failure to patch machines promptly is a significant risk vector.

With serverless systems, this risk vector goes away.

https://www.csoonline.com/article/3075830/data-protection/zero-days-arent-the-problem-patches-are.html

In actuality, the risk is not entirely removed; instead you’re selling it to Amazon. Underneath serverless technologies, there are still servers running operating systems. However, the bet that you’re making is that Amazon has this down to a science across their millions of servers in a way that other IT departments can’t match.

 

Governance and Compliance

HIPAA mandates a set of administrative controls that govern things like access control and auditability. This is another area that is already baked deeply into serverless architectures.

AWS contains a strong policy-driven identity and access framework in AWS IAM. This is a core component of serverless architectures to control access at every step in the architecture. Applying the ‘least privilege’ principle with IAM roles naturally limits the “blast radius” if a service does become compromised. And because policies are all held in one place, it’s easier to see and control which accounts have access to what.

Auditability and robust logging go hand-in-hand, and if serverless architectures do anything, they generate a ton of log data. Each service, from AWS Gateway routing request to VPC delivering network traffic, to Lambda services handling requests, to S3 getting and setting bulk data is heavily logged, with most logs aggregating into either S3 or CloudWatch Logs. Several of the re:Invent sessions this year explored novel ways to report on this data using tools like ElasticSearch (note: the AWS-managed ElasticSearch Service is not yet on the HIPAA eligible list), and even automatically detect anomalous usage patterns using Kinesis Analytics.

Finally, AWS Artifact organizes all of the compliance documentation for Amazon’s part of the shared-responsibility model, including things like your AWS Business Associate Addendum (BAA), and access to SOC2 audits.

All of this stuff is just baked in, and there’s hardly any work needed to make use of it.

 

Availability and Scalability

While the security and encryption parts of HIPAA get most of the attention, it also contains provisions for ensuring availability, business continuity, and emergency mode operations.

Capacity and availability is something that used to be hard to plan in the days of individual server instances. A well-designed serverless architecture, by contrast, encourages robust-by-design implementations that can scale based on actual usage. Deploying across multiple data centers (AZs) is the default. Deploying across multiple regions is easy. This once again removes a common source of error and failure and gives solution builders tools to build “internet scale” systems that deliver three, four, or more 9’s of availability.

And in the unlikely event that there is an outage, backup and restore is also easy. Relational (Aurora) databases automatically perform backups, and backup/restore support for the DynamoDB document database was announced at re:Invent.

 

Increased Interoperability

Healthcare data has often been locked into data silos inside EMRs and other proprietary systems-of-record. Additionally, the quantity of data has meant that health systems need to undertake massive data consolidation and data warehousing projects to begin to recognize the value stored in this data.

At the same time, in recent years, there has been an explosion in patient-generated data. Vast quantities of activity tracking data, medication adherence records, blood glucose measurements, and patient reported outcome data (to name a few examples) sits collected but underused and uncorrelated.

In modern serverless architectures, patient data from inside and outside the four walls of the clinic can be easily collected and stored in large-scale data lakes like S3 where it can be easily aggregated, cleaned, transformed, queried, and reported on. HIPAA regulations are easily fulfilled, with HIPAA-compliant encryption at no additional cost just a button-click away (or sometimes a few buttons if you want to manage your own encryption keys). Control over who can access and use this data are returned to governance groups and clinicians based on business requirements and policy rather than obscure formats, closed databases, and network firewalls.

 

Wrap Up

At Wellpepper, we help healthcare providers deploy interactive care plans to their patients, so we take our data security and compliance responsibilities seriously. We were an early adopter of the AWS cloud back when EC2 and S3 were the only services available under the HIPAA umbrella, but things have changed! Following AWS’ announcement earlier this year that Lambda is now HIPAA-elegible, we’ve been looking more seriously at serverless system design, and we like what we see.

This is the future that anyone building solutions in healthcare IT should be excited about.

 

Relevant Content from AWS re:Invent 2017

Adopting Microservices in Healthcare: Building a Compliant DevOps Pipeline on Amazon ECS

What’s new in AWS Serverless 

Simplifying Healthcare Data Management on AWS 

Building a Secure and Healthcare-Compliant Platform for Adopting a Cloud-First Strategy using AWS 

American Heart Association: Finding Cures to Heart Disease Through the Power of Technology 

 

 

Posted in: Adherence, Data Protection, Healthcare Technology, Interoperability

Leave a Comment (1) →

Using AWS with HIPAA-Protected Data – A Practical Primer

When we started building the Wellpepper platform four years ago, we thought carefully about how to build for privacy and security best practices as well as HIPAA compliance, since we work with customers in the healthcare industry. We chose to build the system entirely on Amazon Web Services (AWS), and learned a few things in the process about building HIPAA compliant applications on AWS. Hopefully this will be helpful to others considering AWS as the home for their healthcare online service, whether you’re a software company hoping to sell to healthcare systems (as a “Business Associate” in HIPAA terminology) or an internal development team at a health system (a “Covered Entity”).

It’s Not Rocket Science

As you probably already know, the Health Insurance Portability and Accountability Act (HIPAA) is made up of several parts. Usually when IT people talk about “HIPAA compliance”, they are talking about the Title II Security Rule which governs privacy and security practices for electronic protected health information (ePHI).

Many of the requirements in the HIPAA Security Rule are simply best practices for security and data privacy that have been written into law. Things like encrypting traffic travelling over a network. Anyone building good, secure software, should be following these principles anyway. You need to be informed of the requirements, and you need to make sure you establish ongoing practices for maintaining security and privacy, but it’s not rocket science. In fact, your health system (or healthcare customers) may actually have more stringent or additional data security requirements to what is required by HIPAA.

Our experience is that HIPAA isn’t a major departure from what we would have built anyway.

Stay Up To Date

HIPAA was established in 1996, with the final Security Rule being published in 2003. In some cases, the guidance has not kept up with current threats and practices in 2017. If you are developing healthcare software, you should be applying industry best practices in combination with the HIPAA requirements. Your ultimate goal needs to be protecting patient data, not just regulatory compliance. Invest in training yourself and your team and staying current. Some resources we found helpful:

Take Responsibility

Compliance usually isn’t at the top of an engineering team’s list of fun things, so it’s tempting to look for solutions that can abstract away the responsibility. There are a few online healthcare platform-as-a-service hosters that make claims in this direction. Be wary of these. No service can remove your responsibility for compliance.

We decided that using AWS infrastructure services was the best level of abstraction. This let us build new services, host data, and install 3rd party applications in our VPC with high confidence that we were living up to our promises to protect patient data.

In addition to thinking about your software solution, compliance also covers your business practices and policies for things like training, background checks, and corporate device security – securing your people. These are often overlooked areas that are really important, since security researchers complain that people are the weakest link in the security chain. As with your software design, the application of commonsense practices and good documentation will go a long way.

There is no single group that certifies systems as HIPAA compliant. However, HHS can audit you at any time, whether you’re a covered entity or a business associate. You should do your own internal assessments against the HIPAA Security Rule both when you are building new capabilities, and on an annual basis. Augment this with external third party reviews. You’ll want to be able to show summarized reports of both your internal process and a stamp of approval from an external auditor.

HHS produces a tool called the SRA tool which you might find useful in performing security rule assessments: https://www.healthit.gov/providers-professionals/security-risk-assessment-tool. We used this for a couple years, but now just use an Excel Spreadsheet to evaluate ourselves. Bonus: this is probably what your auditor will want to see.

This Risk Toolkit from the HIPAA Collaborative of Wisconsin is a good starting point, and looks very similar to the spreadsheet we use: http://hipaacow.org/resources/hipaa-cow-documents/risk-toolkit/ (look at the Risk Assessment Template).

Share the Responsibility

AWS certifies a subset of their services for HIPAA compliance. This includes restrictions on how these services are used, and requires that you enter into a Business Associate Agreement (BAA) with AWS. This agreement establishes the legal relationship needed to handle ePHI, and ensures that you’ll be notified in the unlikely event that there is a data breach.

When you sign a BAA, you enter into a shared responsibility model with AWS to protect ePHI. AWS largely covers physical security for their facilities and networks. You can view their SOC audit results on request. You own the security for your applications and anything else from the OS on up. For example, if you use Elastic Compute Cloud (EC2) instances, it’s your responsibility to keep those instances patched.

AWS occasionally adds new services to their HIPAA-certified services, so you’ll want to check occasionally to see if there are new services you might be able to take advantage of.

Draw a Bright Line Around Your ePHI

At any time, you should be able to quickly say exactly which parts of your system (which servers, which network segments, which databases, which services) have or store ePHI. These systems are inside your bright line defense perimeter, are subject to HIPAA regulations including breach notifications. That means if you lose data on one of these systems, you need to notify your patients (or if you are a Business Associate, notify the Covered Entity so that they can notify the patients).

EC2, Simple Storage System (S3), Elastic Load Balancing (ELB), when used in accordance with guidelines can be HIPAA compliant. Make sure you read the guidelines – there are usually certain restrictions on usage in order to be covered. Many of AWS’ platform-as-a-service offerings are currently not offered under the AWS HIPAA umbrella (for example Kinesis and Lambda). You can still use these services, just not with ePHI.

Many modern systems designs make use of 3rd party framworks and SaaS offerings for things like analytics, monitoring, customer support, etc. When you are holding and conveying ePHI, you will need to be careful about which dependencies you take. For example, in one of our recent product updates we were considering using an external web & mobile analytics platform to better understand our traffic patterns. We walked through our use cases and decided that while none of them required us to send any ePHI to the analytics platform, the risk of accidentally sending some piece of protected data was too high. So we came up with a different plan that allowed us to keep PHI within our safe boundary and under our direct control. Many of your decisions will be grey-area tradeoffs like this.

Secure at Rest and Over the Wire

This is often the first question we see on any healthcare IT security review. How do you protect data at rest and over the wire? Use strong SSL certs with robust SSL termination implementations like ELB. If you terminate your own SSL connections, they need to be well patched due to evolving threats like Heartbleed, POODLE, etc. You may choose to do further application-level encryption in addition to SSL, but SSL should usually be sufficient to satisfy the over-the-wire encryption requirements.

For at-rest storage, there are many options (symmetric/asymmetric) that will depend on what you are trying to do. As a baseline, AWS makes it incredibly easy to encrypt data with AES-256 both in S3 or in the Elastic Block Store (EBS) drives attached to your EC2 instances. There’s almost no reason not to use this, even if you are using additional encryption in other layers of your architecture. AES-256 is usually the “right answer” for IT reviews. Don’t use smaller keys, don’t use outdated algorithms, and especially never try to roll your own encryption.

Good guidance in this area is easy to find:

Logging and Auditing

A key HIPAA requirement is being able to track who accessed and changed patient records and verify the validity of a record. Even if you don’t make this available through a user interface, you need to log these actions and be able to produce a report in the case of an audit or a breach. Keeping these logs in encrypted storage in S3 is a good way to do this. You’ll want to restrict who has access to read/write these audit logs as well.

In addition to automatic audit trails generated by your application-level software systems, remember to carefully keep track of business-process events like granting someone access to a system or revoking access. AWS CloudTrail can help track system changes made to AWS resources like servers, S3 buckets, etc.

Authentication

All healthcare applications will need a way to identify their users and what permissions those users have. HIPAA is not specific about authentication systems beyond being “reasonable and appropriate” (164.308(a)(5)(ii)(D)), but does require that you have good policies in place for this. Here you should follow well-established security best practices.

For starters, you should try not to build your own authentication system. In purpose-built systems, you may be able to integrate into an existing authentication system using oAuth, or SAML (or maybe something more exotic if you’re plugging into some legacy healthcare application). In patient-facing applications, you may be able to integrate with a patient portal for credentials – this is something that will probably show up on your requirements list at some point anyway. If neither of these apply, you may be able to use another identity provider like AWS’ Identity and Access Management (IAM) system to manage user credentials. We briefly tried using consumer-facing oAuth using Facebook, but quickly found that consumers are (rightly) worried about privacy and chose not to use this method.

If you find that you need to build an authentication system, be sure to follow current best practices on things like how to store passwords securely, as well as other tricky areas like password resets.

Since Wellpepper is often deployed standalone before being integrated into other back-end systems, we offer a built-in username + password authentication system. One silver lining to building this ourselves is the ability to build meaningful password complexity rules, especially for patients. Some of the traditional healthcare systems have truly draconian rules that are not only user un-friendly, but actively user-hostile. Thankfully, the best practices in this area are changing. Even the draft NIST password recommendations, updated in August 2016, trade some of the human-unfriendly parts of passwords (multiple character classes) for more easily memorable, but still secure ones (length). Also, consider the difference between health-system password requirements for clinicians with access to thousands of records and those for patients who only access a single record.

Once your users are authenticated, they will need to be authorized to access some set of resources. As with authentication, if you can delegate this responsibility to another established system, this is probably the best approach. If you are adding unique resources with unique access control rules, you will need to make sure that your authorization mechanisms are secure and auditable.

Conclusion

Creating a HIPAA-compliant service doesn’t have to be a big scary problem, but you do want to make sure you have your ducks in a row. If you’re reading this blog post (and hopefully others!), you’re off to a good start. Here are some additional resources that we found handy:

Posted in: Data Protection, Health Regulations, Healthcare Policy, Healthcare Technology, Uncategorized

Leave a Comment (0) →

“How to Hack Healthcare” hosted by HIMSS

“How to Hack Healthcare” presentation by Alluvien Information Security experts:

Aaron Hayden, MBA
Software Development / Ethnics & Compliance

Alex Haslach, GSEC, CEH
System Administration / IT Control Analyst

June 25, 2015

This webcast hosted by HIMSS covered ‘recent’ healthcare entities that have been hacked (Anthem, Premera, CHS, etc.), how the hackers got into their systems and what safeguards (cover risk) could have been put into place to avoid these intrusions. Later in the webcast Alex covered HIPPA requirements; Administrative, Physical, Technical (Access, Audit, Intergrity and Transmission). Thoughtful and useful advice was given to the audience on the best actions for healthcare, etc. to take to avoid hacks.

*Image source: Fox Small Business Center

As mentioned in the slides, over the last decade healthcare providers account for 26.8% of data breaches (about 1200), however not every sector has mandatory reporting, healthcare is overrepresented. Both Anthem (2010) and Premera (2014) were hacked via spear phishing. A fake website was created with very similar web address; an employee went to this website and gave away their credentials. Aaron goes into detail of why hackers preform these ‘mega breaches’, citing the main reason is because there is a huge black market for data, and the suspicion is that hackers assemble a database about individuals and can use this protected information to target same group of people in the future by using better ‘crafted’ phishing emails; federal employees are usually main target. Another hypothesis is that this is illicit market research, used to generate new and better uses of healthcare products. This is the ‘positive’ spin on things, I applaud your efforts Aaron, but I am VERY doubtful! Aaron also talked about the Community Health Systems (CHS) hack of more than 200 healthcare facilities somewhere between April and June 2014. This was a far more sophisticated attack utilizing malformed requests (hackers asked for encrypted sessions with the webserver) and a OpenSSL Heartbleed vulnerability reportedly resulted in a VPN session hijack.

So are governmental mandates enough to help prevent such attacks? If an organization is compliant with HIPPA, it “…does not mean it is secure in any way”. One huge downfall that was a common theme with Premera, Anthem and other attacks, was the length of time hackers had access to data before it was even noticed by anyone due to the lack of monitoring and the strong compliance beyond just HIPPA. Protection systems like Intrusion Detective System (IDS), Intrusion Prevention System (IPS) and Security information and event management (SIEM) System need to be in place. A useful source mentioned was a non-profit cooperative research and education organization called SANS that has a comprehensive list of top 20 Critical Security Controls that mitigate and prevent security breach; organizations that have implemented these security controls have an 85% less likely chance of a breach.

The slides that go into HIPPA are in the link below for your reading pleasure! I don’t want this to become a blog about the subject (easily done due to the vastness), but please read their slides because they do a wonderful job of summing it up. Instead I want my next point to be about my question asked. I wrote in asking Aaron and Alex their opinion on utilizing Amazon Web Services (what Wellpepper uses), to store PHI data etc. and what they believed the pros and cons to be. Aarons opinion was the bigger the company the better… they have solid safeguards to protect PHI data and can easily present their policies to clients, but as a customer if you have a security request that is in conflict with their efficiently organized architecture, they are not going accommodate. Alex agreed adding that it is a matter risk of transference; will Amazon do a better job of protecting our data by taking the risk for us? Yes, because Amazon maintains class one data centers all around the world that have very good security controls, they have resources to invest in the highest level of protection available with an entire team to do so. With that coming from Alluvien security professionals, it is nice to be reassured that PHI data that Wellpepper utilizes is well protected.

The webcast is available here after a short ‘registration’ process. The on demand webcast expires at the end of July.

Posted in: Data Protection

Leave a Comment (0) →

Helping Patients Protect Their Own Personal Health Information

Last week I was leaving a meeting at a large hospital when I saw a patient record sitting on top of the payment machine in the parking garage. Incredibly this is the second time that I’ve seen documents left here. People put them down when they pull out their wallets to pay for parking and then walk away.

Patient Record on ParkingThe information the patients left behind included treatment plan instructions – so you can be pretty sure they are not doing their follow up home care – but worse than that it contained a schedule of future appointments with the patient’s name, date of birth, and social security number. Yes, you read that right: a perfect package for anyone practicing identity theft. This was all on a page that was printed directly from the EMR. The DOB and SSN were probably included on the record to verify that the information was for the correct patient, but this could be verified by asking the patient without printing it on a schedule of appointments.

So – first things first – I took the paper records back into the hospital. But afterwards it got me thinking about information protection and privacy, and in particular about the many people who still think that a paper print out is more secure than the cloud.

Although concerns about information protection and privacy are valid, many of the major HIPAA breaches of the last few years have had nothing to do with the cloud and usually are related to human error and not great security practices.

A few examples:

Good protection of patient information is important whether that information is in the cloud, on an internal computer or system, or on paper. HIPAA regulations encourage building good encrypted software, however we also need to have safeguards to protect against human error.

If patient information were in the cloud, the patient would either access the information through a secure portal, email, or application on their mobile device. He or she would then authenticate themselves to receive the information, and would not need to worry about accidentally forgetting their treatment plans sitting on a parking payment machine.

While patients expect to be able to interact with their healthcare providers through portals and mobile applications in the same way they interact with their banks, many healthcare CIOs we’ve encountered are still extremely wary of cloud-based systems. Financial services is another heavily regulated industry that has been able to successfully move to the cloud to better serve its customers.

Wellpepper is a cloud-based application, which in the healthcare world, makes us a business associate and on the hook for any breaches of patient health information. On the hook means that we need to sign a HIPAA agreement with any organization and we have liability for breaches of information. This is a job we take very seriously and we do our utmost to protect all information that flows through Wellpepper. This includes encrypting information at rest and in transit, ensuring strong passwords, and conducting audits of our system as well as making sure we are well-insured.

With Wellpepper, we provide the same level of encryption and safeguards to the patient’s own device as we do on the clinical devices. Information is not stored locally so if a device is lost or stolen there is much lower risk than in the laptop examples. Patient can do whatever they like with their own data. If I want to post my x-rays on the lamppost in-front of my house I can do that. However, that doesn’t mean that a healthcare organization should facilitate me in sharing my personal health information, which is actually significantly easier with paper-based systems than cloud based.

Yes this information would have been transferred over the Internet which could leave it open for hacking but a secure cloud system is no less, and sometimes more secure than internal IT systems which are also vulnerable. The key is to ensure that everyone in the chain, from internal IT to external partners, and finally to the providers and the patients understands the importance of protecting health data, and has the tools they need to do so, whether that’s on paper, online, or in the cloud.

Posted in: Data Protection, Health Regulations, Healthcare Technology, Healthcare transformation, M-health

Leave a Comment (0) →

Just Because You Can, Does That Mean You Should?

Facebook’s recent experiments in social media mood contagion got us thinking about user-based testing in general and especially how that applies in healthcare technology that is intended to influence behavior.

The Experiment

happyFor one week in January 2012, Facebook manipulated the feeds of users to show content that was either positive or negative and then looked at whether this had an influence on users. The main point of contention or dissention is that this was human subject research without consent from the subjects and without the oversight of a review board as would be expected for university research. If the research hadn’t been published in a scientific journal then there might not have been so much controversy. What is the difference between A/B testing and what Facebook did? In A/B testing, marketers test different landing pages or campaigns and see which one works the best for their desired goal. Consumers don’t know that they are part of an experiment to test messages. However, consumers did freely follow a link that brought them to the content. The difference with Facebook is probably first, that they have significant power due to the volume of users and more importantly what they know about those users, and second although Facebook lawyers will tell you their terms of use covered it, Facebook users probably did not sign up with the expectation that Facebook itself would actively attempt to make them happy or sad.

How Do You Test Behavior Change?

It’s an interesting question for those involved in healthcare, and in particular trying to help people modify their behavior. In our case, at Wellpepper we are helping people be more adherent to home treatment programs. To do that we use a number of motivating factors including personalization and notifications. As part of building our application we test which features are effective in motivating people. We continually improve and change the application based on what we learn. Is this testing on human subjects? Yes. Did we get permission? Yes. This is part of our terms of use and it is also an essential part of how the industry builds software that people will use: by testing that software with real users. When people start using our software they use it to help them with a specific problem and they are happy when we make improvements to make it more effective to solve that problem. We encourage user feedback and implement new features based on it. So while, we may test new features, it is part of the implicit agreement of delivering software to users. (If you’ve ever used software that was not tested with real end-users, you’ll know the difference.)

When we test and add features that help improve user experience and become more adherent to their treatment program users are happy because we have helped them with their goals for using our software and the implicit contract with them. If we started testing and adding features that made them less adherent or changed some other type of behavior that they weren’t trying to change using our application we would have broken that contract and they might vote with their feet or in this case fingers and stop using the application.

What’s Your Implied User Contract?

The same thing could happen with Facebook, and it stems back to what their intention is with this research. The unfortunate thing is that they probably have enough data to have figured out that positive newfeeds make you happy and negative newsfeeds make you unhappy without actually manipulating the feeds. The fact that they did this, and did this without consent, brings up a bigger question of what their intention is, and what exactly is the implicit contract you have with Facebook. What exactly is their motive in trying to manipulate your emotions? For marketing experiments of this type the motive is pretty clear: consume more of their product. For Facebook it might be the same, but the fact that they tested negative messages does cause some alarm. Let’s hope they use their power for good.

Wellpepper2-1216aFor software developers that aim at healthcare behavior change there is an additional challenge as we think about testing features with real users. In order to help someone change behavior you need to test what works and that does need to be with real users. In general software development there are industry best-practices, for example, where you test different designs to find out which is most effective. This may be considered “experimentation” as users will not see the same features and some of the features they do see may not make it into the final version of the product. When you are doing this type of testing, you are looking for what is most effective in helping users achieve their goals. However, this testing must be done while protecting personal health information and not providing any harmful impact to the patient. Software developers can partner with research organizations whose internal review board will ensure that research on human subjects is conducted in the right way. To prove out efficacy of an entire application, this is often the best way to go but not practical for feature testing.

Guidelines for User Testing in Consumer Healthcare Applications

While looking at specific feature testing, these guidelines can help make sure you respect your end-user testers:

  • Unless you have explicit consent, all user testing must be anonymous. This is because if you are dealing with PHI and have signed a HIPAA BAA you have agreed to only access PHI when absolutely necessary. If you need to know demographics of your users for user testing, then you should err on the side of getting their explicit consent. This could be either via a form, or simply a non-anonymous feedback form on your application or website. By providing you with direct feedback the user has agreed to not be anonymous. (The good thing here is that patients can do whatever they want with their own data, so if they give you consent, to look at it, you have it.) That said, if you are working with healthcare organizations you will also have an agreement with them about contacting their patients: you need to make sure they have agreed to this as well. When possible err on the side of making data anonymous before analyzing it.
  • Think about the implicit contract you have with the user. If you are providing them with an application that does one thing, but you discover it may have applications for something else, don’t test features for that something else without getting consent. That is breaking the contract you have with them. Let’s look purely hypothetical example: at Wellpepper we have an application that increases patient adherence to home treatment programs for those undergoing physical rehabilitation. Let’s say we found out that people in physical rehabilitation are also often fighting with their spouses and started adding features or asking questions about the user’s relationship with his or her spouse, users would find this both unnerving and intrusive because that was not their expectation that we would help them with marital issues when they signed up for the application. Obviously this is a bit far-fetched, but you get the point.
  • Don’t get in the middle of human-to-human communication. This is essentially where Facebook broke the implicit contract with users by dis-intermediating the newsfeed. Your expectation with Facebook is that it’s a way for you to communicate with people (and sometimes organizations) you like. By changing what showed up in your feed, Facebook got in the middle of this. In healthcare this is even more important: don’t get between healthcare professionals and their patients. Make sure it’s clear when it’s you (the application, the company) talking and when it’s the caregiver and patient.
  • Consider where you’d get more value by partnering with a research organization. Sure it will take longer and may require more effort, but you will be able learn a lot more about why or how people are using your features by getting explicit research consent. I am not sure if it’s a coincidence or not but about a month ago I noticed that my Facebook newsfeed was full of extremely depressing stories. I remember wondering what was going on both with Facebook and the world in general and I remember wanting to post something depressing but then thought, “No I don’t want to add to this. I will only post positive things.” It’s possible that I was part of another study by Facebook and if so, they didn’t get the full picture that they would have if they’d been upfront about it, got my consent, and were able to ask me questions later about my thought process.

There is no doubt that we will see more discussions of ethics and consent in the space of user testing, especially as it relates to consumer-facing health applications. Having no regulation or guidelines is not good for consumer. However, only doing research with IRB and third party researchers is also not good for the consumer as innovation that could really help them can be slowed dramatically. Most people, whether healthcare practitioners or entrepreneurs got into the space because they wanted to help people. If we remember this, and we consider the ethical implications of our actions, we should be able to balance the two worlds.

For more reading on this topic as it applies to the software industry, see:

http://en.wikipedia.org/wiki/A/B_testing

http://ai.stanford.edu/~ronnyk/2009controlledExperimentsOnTheWebSurvey.pdf

http://www.exp-platform.com/Pages/expMicrosoft.aspx

Posted in: Behavior Change, Data Protection, Health Regulations, Healthcare motivation, Healthcare Social Media, Healthcare Technology, M-health

Leave a Comment (0) →

Health 2.0 Seattle Meetup: How to Build Solutions in Healthcare

This was the second Seattle health meetup we attended in March, the previous was the Health Innovators Meetup. Health 2.0 is a global organization (we demoed at a Health 2.0 event in London back in November 2013) but the Seattle group is quite new. They are valiantly trying to help build a community of healthcare industry and startups, and those just interested in healthtech issues in Seattle.

The meetup was hosted and moderated by Tory Kelso of GenieMD, and formerly Microsoft HealthVault and Cerner, and panelists were:
Anand Gaddum, Director, Health & Life Sciences at iLink Systems.
Howard Mahran, CEO & Founder Deep Domain, Inc
Sailesh Chutan, CEO and co-Founder at Mobisante, Inc.

Each talked about the drivers for their participation in healthcare. For Howard Mahran, like many entrepreneurs we’ve met, ourselves included, it was frustration born from a personal experience. When Howard’s father was diagnosed with prostate cancer, he was amazed at the lack of information and data available about the diagnosis and prognosis. Sailesh Chutan was driven by a passion for accessibility to technology on a global basis. Anand Gadddum cited the opportunity for applying resources to the wealth of health data out there to make a difference.

When asked how to pinpoint the right problem to solve in healthcare, panelists discussed how to find the pain point by looking at something that doesn’t work today, and how to spot the disruption by seeing how a market or technology change could become amplified when applied to another industry. Sailesh used the example that the computing power in a smartphone today is more than enough to do complex image processing, and recalled his ‘aha’ moment when he realized to reduce cost and improve access, move access to services closest to the patient and find the lowest cost person to deliver the care. (We’ve written about this before. It’s often called “operating at the top of your license”, that is, making sure that if a lower licensed person can perform a task, enabling them to do it.)

Howard talked about the pain of trying to make sense of the “dumptruck” of data that the over 1100 non-standardized EMRs produce, an acute pain for smaller hospitals and clinics that do not have a large IT staff. Also related to the proliferation of non-standard EMRs, Anand talked about customers that are stuck with old technology that is siloed and not easily integrated. Services companies like iLink can help integrate and unlock this information.

Networking at Health 2.0 Seattle

Networking at Health 2.0 Seattle

At this point Tory pointed out that all three solutions had started with the technology, as technologists often do, and asked how to translate a technical solution to a customer focus. Howard readily agreed with the need to translate, saying that his customers don’t care about the technology at all, they care about the problem they have which is not being able to get information. He talked about how Deep Domain had completely changed their sales process to focus on customer pain rather than how great their technology is, and shared the enviable example of a sale that closed in 4 days after they took this approach.

Sailesh also talked about how they had adapted their sales strategy and focus based on what they’d learned in the field. In particular, they found that their mobile-phone based ultrasound offered new billing opportunities to small and particularly rural communities. Rather than providing a referral to a hospital for an ultrasound these clinics could perform ultrasounds themselves for a fraction of the cost resulting in a new revenue stream for the clinic and much higher convenience for the patient. He also realized in selling to these smaller customers, Mobisante had to provide a complete solution including training and image management.

The next topic was on healthcare’s slow embrace of platform, and perhaps the best quote of the night that the current crop of EMRs are why healthcare doesn’t understand platform. Certainly the lack of openness and data interoperability as well as the late adoption of many now standard enterprise IT practices pointed out by Anand are the key reasons behind this.
Some other reasons that healthcare has been slow to embrace platform and cloud technology is the very real fines for HIPAA breaches, although the panel pointed out that most breaches are not due to technology vendors but human error like losing laptops that have PHI on them.

Upcoming Health 2.0 Talks

Upcoming Health 2.0 Seattle Events

To conclude the session, Tory asked for some tips for anyone wanting to get into healthcare technology. Howard jokingly responded “don’t” but the underlying truth is that with long sales cycles, lack of standardization, and many regulations, health technology is not for the faint of heart. He also recommended to “look down not up”, that is don’t ignore the smaller hospitals that can implement more quickly or where your solution offers value they might not normally afford, like Deep Domain’s reporting or Mobisante’s ultrasound. Would-be entrepreneurs were also advised to seek out the early adopters in customers, those people who have passion, understand your value proposition, and are mission driven. These people will help you succeed.

Posted in: Data Protection, Health Regulations, Healthcare Disruption, Healthcare Technology, M-health

Leave a Comment (0) →

Call the (NHS) Midwife!

I’ve been watching the BBC Series “Call the Midwife” on Netflix. It’s set in the late 1950’s and focuses on a group of young nurses working in London’s east end, riding their bicycles through the streets to deliver babies and running health clinics out of a gymnasium. If a situation becomes more than a nurse can handle, she’ll call in a doctor and sometimes expectant mothers are sent to the hospital but for most it’s home births. The series is sweet and fun to watch although doctors often spout slogans like “without the National Health Service this baby would have died” in the middle of a delivery. It’s a rosy commercial to reinforce a matter of national identity and pride in the UK.

Call the Midwife. Source PBS.org

Call the Midwife. Source PBS.org

The NHS is the largest health system in the world, serving over 65M patients. Every person in the UK has basic health services covered, and some, like pregnant women also receive dental services. It’s based on a model of Trusts that run their own organizations supported by some centralized services. I learned more about this system on my recent trip to attend Health 2.0 Europe, which was in London and had a large focus on how to engage with the NHS.

As the CEO of a m-Health and Health IT startup, my interest was largely in how information is managed across this vast system. Interestingly some areas are highly advanced while others are still paper-based.  For example, BT (British Telecom) implemented “The Spine” almost 10 years ago to deliver one system that has basic patient demographics that can be accessed from any health institution. The Spine authenticates patients using their health card and provides their health ID number, age, and basic demographics to any healthcare organization. This means, that say you are from London but are vacationing in Cornwall, over 250 miles away, you can walk into any clinic and get care. Alternatively, 80% of patient records are on paper, and while there are 65M patients there are 85M records suggesting that there is some potential error in the system. Some hospitals in Central London are moving to electronic records and saving millions of pounds annually just by not having to store the records in extremely expensive London real estate. This is quite impressive considering that many EMRs cost hundreds of millions of dollars to implement. 😉

While so many records are still paper-based in many areas,  digital technologies are being implemented for innovative uses. I learned about hospitals deploying hundreds of iPads to staff, as well as tele-health in use for cognitive behavioral therapy. Patients were able to record their therapy sessions and replay them later when they needed a refresher on the advice or what was said. Patient centered care was the reason for adopting these new technologies, however the 18-month waiting list for cognitive behavior therapy may also be driving new models of care.

Private hospitals have cropped up catering to the “worried wealthy” who want to access more frequent care or avoid waiting lists for surgery, MRI, or other popular treatments. I heard mixed feedback about whether these waiting lists were real. Some people said that they were exaggerated while others pointed to the popularity of private care as proof.

Another areas of contrasts was around portability and protection of health information. On the one hand, an NHS representative said that a major issue was consent: sharing of patient records across trusts or hospitals or even with someone not directly involved in the patient’s care. On the other hand personal health information regulations while important did not seem to be as big an emphasis as in the US. As for the portability of health data, patients often are given their paper file to carry directly to a specialist. While it would be great if they were able to do this on their mobile device, it’s great to see this level of access to information for patients.

As I’ve written before, there does not seem to be a magic bullet between private and public systems. Private can deliver a much higher level of service however, the right to healthcare seems like it should be universal. The trip provided an interesting peek into another model that has its share of advancements and opportunities to get even better.

Now, back to seeing what the girls are up to on Call The Midwife.

Posted in: Data Protection, Health Regulations

Leave a Comment (0) →
Google+