Blog

Posts Tagged cloud

ResearchKit: The Tip of the Iceberg

In March, during the much-anticipated Apple Watch keynote, Apple carved out a few minutes to announce ResearchKit, a system to enable faster and easier healthcare research. The announcement was received positively, some even saying that the announcement was bigger news than the Apple Watch itself! Within a week, one of the early apps, MyHeart Counts, had enrolled 11,000-patients, an enrollment pace and efficiency unheard of in the healthcare community. Without a doubt, Apple has the opportunity to bring the power of numbers to healthcare.

What It Is

ResearchKit is an SDK (Software Development Kit) containing presentation logic and user interface components for gathering healthcare research data on an iPhone. It can gain informed patient consent, present surveys (whether existing clinically-validated surveys, or novel surveys for a particular study), and also use the sensors on the device to do things like measure vocal tremor, conduct a 6-minute talk test, and measure motor reaction time.

Building a new research app with ResearchKit-powered is a fairly standard mobile app development project. The ResearchKit components certainly accelerate the process, however you will still need an iOS developer, and you will need to follow all the usual software development steps of requirements gathering, design, implementation, stabilization, and then releasing through the App Store. The SDK was recently open-sourced on GitHub. Since most of the SDK relates to the user interface, ResearchKit really only helps with iPhone app development, which some have pointed out may give rise to a sample bias.

Image of an Iceberg

(Original source: National Ocean Service Image Gallery)

 

What It Is Not

More important than the development of the mobile app, though, it all of the infrastructure behind the app that allows the data to be securely transmitted, stored, aggregated, and analyzed by researchers. In systems of this kind, the scale and complexity of the underlying data service layer is usually considerably larger than the user-facing data collection app. This is especially true in healthcare, given the compliance overhead imposed by regulations like HIPAA.

On this dimension, ResearchKit has no immediate answer. Given Apple’s privacy-centric stance on data collection and aggregation and the sensitivity of the data, they are unlikely to build a cloud service offering for ResearchKit. As such, it will be up to individual researchers to build their own systems, at least until other software vendors move in to fill this need.

 

The Iceberg

Much like the proverbial iceberg where only 10% of the whole is visible, Apple’s ResearchKit is a beautiful, if small, slice of user interface that hides a large and complex underlying platform needed to actually deploy healthcare research apps.

 

 

 

Posted in: Healthcare Disruption, Healthcare Technology

Leave a Comment (0) →

Breaking Bad Healthcare: The Story of Healthcare.gov

It’s generally a good principle to not criticize something if you’re not willing to help fix it. That’s what former Microsoft exec Kurt DelBene learned, when he offered feedback on the Healthcare.gov website after its release in 2013, and instead of just providing feedback, he ended up taking the reins to fix the site. At a recent event sponsored by University of Washington’s Foster School of Business, DelBene provided a mini-business case on what went wrong with the project and how his team fixed it. With clarity, modesty, and wit DelBene both highlighted some major flaws in the process and encouraged attendees to consider a stint themselves helping out the government with major technological and business issues.

One of the first problems stemmed from an issue that is far too common in government and business: saying yes to a project before fully understanding the scope. In this case, and internal Whitehouse IT team, essentially signed up to deliver a website with requirements of something like Amazon.com without ever having built something that big. While most of us think of the consumer interface of Healthcare.gov, and the trouble that happened on that end, the actual site is extremely complex in needing to connect to hundreds of insurance plans among the major payers, and also to the IRS to verify income levels. Any facet of the site’s interface, up-time requirements, and integration needs was a daunting prospect, and the original architects didn’t have the full requirements set, and possibly the experience to know what was missing when they signed up.

Next, they chose two inappropriate technologies. One was a semi-structured database No-SQL database called MarkLogic, which they had always wanted to try out. The database choice itself was not necessarily the problem, but trying a new technology where the team did not have prior expertise for a project of this scale is risky and they chose the database without understanding the project specs. The second, was trying to use a flow-charting application that automatically generated screens to design the website. This type of application might be appropriate for an internal process application used by a small number of technical users, but it is not appropriate for a large scale consumer facing website that is intended to reach the general population, including those whose first language is not English or with a wide range of education. Software has not gotten to the point where it can design user-friendly versions of itself no matter what you read about artificial intelligence.

Another major, and widely publicized failure was delegating different parts of the project to at least 6 different contracting firms. No one took responsibility for the overall integration, and the contractors continued to point fingers about whose technology was failing.

These were only some of the problems that DelBene inherited with a hard deadline to launch the site. Other issues in site design included no failover system, no beta testing, and no instrumentation or telemetry to understand where the site might be failing. Within the development process there were also failings, for example no tracking of bugs and how much work was left to do.

DelBene started by listening, and this included to all team members not just senior leaders. Although he had to hit the ground running: briefing the President two days into the job, and famously, exiting a meeting into a closet instead of the hallway.

He then had the team prioritize what could be fixed for launch and what couldn’t.

While the site wasn’t conceived as cloud-based (in fact the original team expected the insurers to install servers in their datacenters to connect with the Healhtcare.gov site), DelBene says it was an excellent candidate for the cloud which would have been more secure and more scalable. The team did rebuild many consumer-facing parts of the site on Amazon Web Services and continued to iterate and test capabilities as the site was deployed by sending some groups of users to the new interfaces.

While DelBene was extremely modest, always citing the team, which included recruits from Google and Facebook but strangely not Microsoft, he did have some very specific advice for how to successfully run this type of government project in the first place.

The recommendations can be summed up as “run any consumer-facing government IT project the way you’d run a commercial software project.” Hire the right team, plan, test, and iterate, hold people accountable, and encourage honesty.

Solutions for Government IT Projects

So much of this project’s initial issues were due to a lack of coherent team, and a lack of experience. Developing internal IT infrastructure and commercial software that is used by millions of people is very different, and requires a different skill set. As well, it requires humility as end-users outside your organization will let you know if something doesn’t work as evidenced by the negative press the original roll-out received.

Opportunties

DelBene, who used to run the $11B Office business for Microsoft, described this experience and work as the most important he’s done, and he ended the session by encouraging the audience of MBA candidates and alumni to consider how they could help the country. New programs like the White House Digital Services and 18F Organizations are specifically designed for people from private sector to be able to lend their expertise to government organizations for short periods of time. Considering that the future of all government transactions is digital, this is more important than ever.

Posted in: Health Regulations, Lean Healthcare

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) →
Google+