Blog

Author Archive

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 (0) →

Building a Voice Experience for People with Type 2 Diabetes

Recently we were finalists in the Merck-sponsored Alexa Diabetes Challenge, where we built a voice-powered interactive care plan, complemented by a voice-enabled IOT scale and diabetic foot scanner. The scanner uses the existing routine of weighing-in to scan the person’s feet for foot ulcers, a serious but usually preventable complication of Diabetes.

We blogged about our experience testing the device in clinic here

We blogged about feedback from patients here

This was a fun and productive challenge for our team, so we wanted to share some of our lessons learned from implementing the voice interface. This may be of interest to developers working on similar problems.

Voice Experience Design

As a team, we sat down and brainstormed a long list of things we thought a person with diabetes might want to ask, whether they were interacting with the scale and scanner device, or a standalone Amazon Echo. We tried not to be constrained by things we knew our system could do. This was a long list that we then categorized into intents and prioritized.

  • ~60% of the utterances we knew we’d be able to handle well (“My blood sugar is 85.”, “Send a message to my care team”, “Is it ok to drink soda?”)
  • ~20% of the utterances we couldn’t handle fully, but could reasonably redirect (“How many calories are in 8oz of chicken and a half cup of rice?”)
  • ~20% of the utterances we didn’t think we’d be able to get to, but were interesting for our backlog (“I feel like smoking.”)

After some “wizard of oz” testing of our planned voice interactions, we decided that we needed to support both quick-hit interactions, where a user quickly records their blood sugar or weight for example, and guided interactions where we guide the patient through a few tasks on their care plan. The guided interactions were particularly important for our voice-powered scale and foot scanner so that we could harness an existing habit (weighing oneself) and capture additional information at the same time. This allows the interaction to fit seamlessly into someone’s day.

 

Challenge 1: We wanted to integrate the speech hardware into our scale / foot scanner device using the Alexa Voice Service, rather than using an off-the-shelf Echo device.

The Alexa Voice Service is a client SDK and a set of interface standards for how to build Echo-like capabilities into other hardware products. We decided early on to prototype our device around a Raspberry Pi 3 board to have sufficient processing power to:

  • Handle voice interactions (including wake-word detection)
  • Drive the sensors (camera array, thermal imaging, load sensors)
  • Run an image classifier on the device
  • Drive on-device illumination to assist the imaging devices
  • Securely perform network operations both for device control and for sending images to our cloud service

Raspberry Pi in Sugarpod

The device needed built-in illumination in order to capture usable photos of peoples feet to look for ulcers and abnormalities. Since the device needed built-in illumination to perform imaging, one of our team members came up with the idea of dual-purposing the LED lighting as a speech status indicator. In the same way that the Amazon Echo uses blinking cyan and blue to show status on the LED ring, our entire scale bed could do this.

As we started prototyping with basic audio microphones and speakers, we quickly discovered how important the audio-preprocessing system is in our application. In our testing there were many cases of poor transcriptions or unrecognizable utterances, especially when the user was standing any distance from the device. Our physical chassis designs put the microphone height around 2’ from the ground, which is far from the average user’s mouth, and also in real-world deployments would be in echo-filled bathrooms. Clearly, we needed to use a proper far-field mic array. We considered using a mic array dev kit, which we decided was too expensive and added too much complexity for the challenge. We also spent a couple hours investigating whether we could hack an Echo Dot to use it’s audio hardware.

Eventually we decided that it would make the most sense to stick with an off-the-shelf Echo for our prototype. Thus, in addition to being a foot scanner and connected scale, the device is also the world’s most elegant long-armed Echo Dot holder! It was easy to physically include the Echo Dot into our design. We figured out where the speaker was, and adjusted our 3D models to include sound holes. Since the mic array and cue lights are on top, we made sure that this part of the device remained exposed.

We will be revisiting the voice hardware design as we look at moving the prototype towards commercial viability.

 

Challenge 2: We wanted both quick-hit and guided interactions to use the same handlers for clean code organization but hit some speed bumps enabling intent-to-intent handoff

Our guided workflows are comprised of stacks and queues that hand off between various handlers in our skill, but we found this hard to do when we moved to Alexa Skill Builder. The Alexa Skill Builder (currently in beta) enables skill developers to customize the speech model for each intent and provide better support for common multi-turn interactions like filling slots and verifying intents. This was a big improvement, but also forced us rework some things.

For example, we wanted the same blood sugar handler to run whether you initiated a conversation with “Alexa, tell Sugarpod my blood sugar is 85”, or if the handler was invoked as part of a guided workflow where Alexa asks “You haven’t told me your blood sugar for today. Have you measured it recently?”

We tried a number of ways to have our guided workflow handlers switch intents, but this didn’t seem to be possible to do with the Alexa API. As a workaround we ended up allowing all of our handlers to run in the context of both the quick-hit entry point intent (like BloodSugarTaskIntent) as well as in guided workflows (like RunTasksIntent), and then expanded the guided workflow intent slots to include the union set of all slots needed for any handler that might run in that workflow.

Another challenge was that we wanted to use the standard AMAZON.YesIntent or AMAZON.NoIntent in our skill, however the Alexa Skill Builder does not allow this, presumably because it needs to reserve these intents for slot and intent confirmation. Our workaround for this was to use a fictitious slot (we called ours “ConfirmationSlot”) in basically all of our intents which could be “confirmed”, every time we wanted to ask for Yes/No values. We factored this into a helper library that is used throughout our skill codebase.

if (confirmationSlot.confirmSlotStatus === 'CONFIRMED') {
  confirmationSlot.confirmationStatus = "NONE";
  handler.emitWithState("AMAZON.YesIntent");
  return true;
} else if (confirmationSlot.confirmSlotStatus === 'DENIED') {
  confirmationSlot.confirmationStatus = "NONE";
  handler.emitWithState("AMAZON.NoIntent");
  return true;
}

Challenge 3: The Voice Kit speech recognizer did not always reliably recognize complicated and often-mispronounced pharmaceutical names

One of our intents allows the user to report medication usage, by saying something like “Alexa, tell Sugarpod I took my Metformin.” People are not always able to pronounce drug names clearly, so we wanted to allow for mispronunciation. For the Alexa Diabetes Challenge, we curated a list of the ~200 most common medications associated with diabetes and its frequent co-morbidities, including over-the-counter and prescription medication. These were bound to a custom slot type.

When we tested this, however, we found that Alexa’s speech recognizer sometimes struggled to identify medication from our list. This was especially true when the speaker mispronounced the name of the medication (understandable with an utterance like “Alexa, tell Sugarpod I took my Thiazolidinedion”). We observed this even with reasonably good pronunciation. We particularly liked “Mad foreman” as a transcription when one of us asked about “metformin.” Complex pronunciations are a well-known problem in medical and other specialized vocabularies, so this is a real-world problem that we wanted to invest some time in.

Ideally, we would have been able to take an empirical approach and collect a set of common pronunciations (and mispronunciations) of the medications and train a new model. It may additionally be interesting to use disfluencies such as hesitation and repetition in the recorded utterance as features in a model. However, this is not something that is currently possible using Alexa Skills Kit.

Our fallback was to use some basic algorithmic methods to try to find better matches. We had reasonable success with simple fuzzy matching schemes like Soundex and NYIIS, which gave us a good improvement over the raw Alexa ASR results. We also started to evaluate whether an edit-distance approach would work better (for example, comparing phonetic representations of the search term against the corpus of expected pharmaceutical names using a Levenshtein edit distance), but we eventually decided that a Fuzzy Soundex match was sufficient for the purposes of the challenge (Fuzzy Soundex: David Holmes & M. Catherine McCabe http://ieeexplore.ieee.org/document/1000354/).

Even though our current implementation provides good performance, this remains an area for further investigation, particularly as we continue to work on larger lists of pharmaceuticals associated with other disease or intervention types.

 

Conclusion

This challenge helped us stretch our thinking about the voice experience, and gave us the opportunity to solve some important problems along the way. The work we’ve done is beneficial not just for Diabetes care plans, but also for all of our other care plans too.

While the Alexa voice pipeline is not yet a HIPAA-eligible service, we’re looking forward to being able to use our voice experience with patients as soon as it is!

Posted in: Healthcare Technology, Voice

Leave a Comment (0) →

Wellpepper Security Bulletin April 14, 2017: Unplanned Critical Maintenance

Update 4/16/17: Issues have been mitigated, maintenance is now complete.


On April 14, a batch of Windows-targeting exploits, including several suspected 0-day exploits, were released by Shadow Brokers. We have no reason to believe that any Wellpepper systems were targeted or affected. Most of the exploits target the SMB file sharing protocol, which our firewalls block. Additionally, most of Wellpepper’s infrastructure is Linux-based, and is unaffected. However, we do have some Windows systems (fully patched) in our environment that support non-critical functions. Out of an abundance of caution, we are temporarily suspending these systems until the risks are better understood and properly mitigated as needed. 

As a result, the following features will be offline until further notice:

  1. Uploading images or videos attached to secure messages
  2. PDF Export in the iPad Clinic App

We are working hard to deploy workarounds for these issues where possible. All other Wellpepper functions, including sending/receiving secure messages, and image/video upload for tasks are operating as expected.

Currently, there is not comprehensive information on these exploits. We will be monitoring news sources and updating as information is available.

  

We will update this blog entry by April 17th with additional information on any impact. If you have any questions about your Wellpepper deployment, please contact Wellpepper Support.

 

Mike Van Snellenberg, Wellpepper CTO

Posted in: Security, Wellpepper Support

Leave a Comment (0) →

APTA Combined Sections Meeting Wrap Up

Walking the floor at APTA CSM 2016 Anaheim, CA

Last week, I attended the American Physical Therapy Association Combined Sections Meeting (APTA CSM) in Anaheim, CA. The show was well attended by about 18,000 Physical Therapists and professionals in related roles. The packed house meant lots of energy, a few full sessions, and long lines for coffee at the two overwhelmed Starbucks kiosks in the nearby hotels. Wellpepper started out in physical rehabilitation, so it was great to be back in the company of many talented ‘movement system experts’ and associates working together to gain knowledge in order to achieve best practices for healthcare systems, patients and/or caregivers.

I attended a number of sessions, mostly focused on the shift to value-based payment, and outcome measurement. The healthcare value equation has penetrated deep in this community. I saw the same basic slide in at least 3 talks:

* This formula has been widely discussed by Michael Porter and others.

I attended two presentations on outcome measurements by Beth Israel Deaconess Medical Center (BIDMC) and Johns Hopkins. Both organizations spoke about the task of adopting outcome measurements in an acute settingand their thoughtful deliberate steps to take research-based measurement techniques and apply them into clinical practice;BIDMC’s applied the Knowledge Translation framework, and Hopkins’ applied the Translating Knowledge Into Practice (TRIP) initiative. There were many similarities that both organizations encapsulated in their task of adopting outcome measurements; both organizations had to fight against “don’t give me more documentation work” attitudes, worked cross-functionally with PTs, nurses, physicians and administrators to gain support for their plans. And both adopted process measurements to observe the rollout of outcome measurement tools and practices. Furthermore both had some crossover in the specific measurement tools they used (e.g. AM-PAC / 6 clicks).Another common thread I believe important to note was the development of practical tips and tricks for how to make it easy to capture data into their EMRs that weren’t always designed to capture this kind of data (real nuts-and-bolts stuff like how to copy and paste boilerplate text).

Finally, armed with data on patient functional outcomes, Johns Hopkins shared some of the work they were doing on risk-stratifying patients to help control costs. In a world where Post-Acute Care costs represent one of the largest and most variable cost centers for many procedures, this is critical. The quantity and richness of this data is something I hadn’t seen presented at this conference before. Here is real objective data on how real patients progress through their care journeys that can be used to at the individual level to have an informed conversation with the patient and provides fantastic optics into the most important work product of the healthcare system: making people better.

I was struck that both presentations concluded that measuring outcomes was less of a technical feat than an organizational one. It is, as Michael Friedman a presenter from Johns Hopkins articulated, “About culture change more than anything.”

Throughout the conference, there were also mentions of Patient-Reported Outcomes (Oswestry, HOOS, KOOS were frequently mentioned – thankfully ones that Wellpepper supports!) My sense was that these are still not as widely deployed and not as consistently measured to have made their way into any of the mainstream presentations. As Wellpepper and other companies keep pushing to measure (and improve!) the patient journey with patient reported outcomes, I expect this will change in the coming years.

The one disappointment I had from the conference was that the excellent session on the Patient Experience was not better attended. Jerry Durham (a minor celebrity in the PT world!) introduced a panel of 2 patients to present on their experiences and lamented that often the Triple-Aim objectives are reduced to a Double Aim, ignoring the patient experience. So we had the excellent chance to learn and hear real patients talk. Both patients were both doing great thanks to their Physical Therapists, but both talked about the significant failings they’d seen in their medical practitioners (of all stripes). In a string of wrenching, quotable sound bites, one said “I couldn’t have gotten this bad without the help of PT”. It’s a shame that despite the healthcare rhetoric about putting patients first that more attendees didn’t put this into practice and take the opportunity to learn from some honest patient-driven conversation.

All told, this was a good conference, notable for the increasing use of patient data to measure and improve. If the attendance for CSM 2017 in San Antonio is anything like this one, let’s hope for more coffee and more chairs!

Posted in: Adherence, Healthcare Disruption, Healthcare Technology, M-health, Telemedicine

Leave a Comment (0) →

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

Wellpepper Security Update: Shellshock Vulnerability Patch

On Sep 24, a critical security advisory was posted about CVE-2014-7169 (a.k.a “shellshock”), a vulnerability in bash shell which affects many unix-variant systems including Linux and MacOS. Wellpepper uses linux systems as part of our cloud service. As of 10:00 AM PDT this morning (Sep 25), we have validated that all of Wellpepper’s systems have been patched against this vulnerability. We are unaware of any current network exploits that affect our systems (we do not use cgi-bin, for example), and we see no evidence of any unauthorized access attempts to our systems. There is no action required for Wellpepper customers – your data is safe and secure.

For others working on patching systems, the Register has posted some good background information and guidance here: http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/

For your own personal devices and computers running Mac OSX, do not connect to public networks until Apple issues a patch.

Mike

CTO, Wellpepper

Posted in: Wellpepper Support

Leave a Comment (0) →

Adopting Technology in Healthcare for the Right Reasons

Regulations, process, and records keeping are all important parts of managing health IT; however, when implemented without a strategy focused on patient and business value, they can create headaches for CIOs, not to mention patients and healthcare providers. This was an emerging theme Institute for Health Technology Transformation Conference held in Seattle at the end of August.

IHT2 Summit in SeattleThe conference featured speakers from across major healthcare organizations. Mayo Clinic CIO Chris Ross gave the final keynote which summarized many themes of the conference and provided direction for the future. He described Mayo’s tradition of using industrial and process engineering to deliver on Mayo’s promise of team-based integrated care. Viewed through this lens, imperatives to integrate EMRs, adopt ICD-10 and attest to Meaningful Use became opportunities that aided the business, and enhanced patient care. However, he was clear that while these projects were necessary, they were not sufficient by themselves to achieve Mayo’s vision. He went on to describe projects underway to optimize the workflow for their clinicians, in one instance reducing the amount of time doctors spent using IT tools from 30 minutes to 5 minutes per patient. He also described the vision of having hundreds-of-millions of lives under Mayo’s care, and the patient-centric model that they were following to achieve this. This included projects like delivering the Mayo app deeply integrated with Apple’s HealthKit technology.

Ross also asked his peers to consider the move to electronic records keeping to be a move to digitizing the healthcare industry to keep pace with the innovation available in other industries instead of a regulatory requirement. He envisions a system where a unified data platform provides digital care and knowledge management and recording keeping is a by-product of that system.

Focusing on the right strategy was also a theme in a talk by Dr. Nick Wolter of the Billings Clinic. Wolter described a 1993 merger with Deaconess that nearly bankrupted the organization. The merger was focused on regulatory and process integration while ignoring the vision for the new organization. In 1997, with financial losses posted, they hired turnaround experts who focused on physician leadership development. By 2005 they had established a vision to be best in the nation for patient safety, quality, and service. In 2010 Billings Clinic added value to their mandate and are looking closely at ACO metrics to make sure they are delivering on these promises.

Throughout the two-day conference, panelists called out EMRs as a significant driver of physician dissatisfaction. While meaningful use requirements have increased the focus on moving to electronic records, in many cases this is apparently happening without a vision that leverages these transformations to improve physician efficacy and patient care, which is unfortunate as these two areas if provided with appropriate electronic tools could see some of the biggest benefits.

Although there is was definitely a dissatisfaction expressed with the current state of health IT, it was promising to see shifts towards tools that are more focused on provider workflow and patient engagement. Even more promising was the general understanding at this conference that digital healthcare can and should be better delivered. At Wellpepper we’re excited to support this shift to a patient- and value-centered system.

Posted in: Health Regulations, Healthcare Disruption, Healthcare Technology, Seattle

Leave a Comment (0) →

10 Reasons Why Running a Relay Race is Like Running a Startup 

This weekend was Ragnar Northwest Passage, a 196-mile relay race here in the beautiful Pacific Northwest. It’s painful, it’s exhausting, and it’s great fun. Kind of like founding a startup. Here are 10 similarities:

1. You don’t get much sleep

sleeping under the steps

Team member Todd catches an hour of quality shut-eye in the dirt with the rats after running the second of three legs.

 

2. It’s a small team. Each person is critical. And they smell bad.

honey buckets in a row

It ain’t all honey

 

3. You push hard to reach the goal, and then someone faster overtakes you

Runner getting passed.

Getting passed in the last hundred yards sucks. Unless you catch them back. He did.

 

4. You meet a lot of great people along the way

The CRAWLERS at the finish line

Team CRAWLERS. Our finish time was 29:16:55.

 

5. Vanity Metrics

Road kill tally chalked on van window.

Our BI system for tracking how many runners we passed.

 

6. It’s not a straight route to the end of the race

indirect route on a map

At least with a relay race, you have a map.

 

7. You’re a volunteer

Mike wearing a volunteer shirt

Unpaid labor. The backbone of startups and relay races.

 

8. Print marketing is hard.

Car door: "We Suck"

There’s a reason PR and marketing firms charge big bucks.

 

9. You can’t do it without an understanding spouse at home

Mom getting tackled by 3 year old

She has a harder job than I do, whether I’m building patient engagement software, or running grueling races.

 

10. You take a beating, and keep coming back for more

Ragnar finishing medals

Perseverance produces results. In this case, bottle opener medals.

Posted in: Uncategorized

Leave a Comment (2) →

CVE-2014-0160 aka “The Heartbleed Bug”

As you may have heard, on Monday a major security vulnerability was discovered in OpenSSL (CVE-2014-0160, also called the “heartbleed” bug), a software component that encrypts a substantial amount of internet network traffic. We want to be transparent on how this has affected us, what we have done to remediate, and how this affects you as a Wellpepper customer.

How Wellpepper Was Impacted, and Our Response

Our production systems are hosted on Windows Server, and neither the default services nor any application components are vulnerable to this issue.

  • We take data security seriously: In addition to using on SSL to protect data in transit, Wellpepper also uses field-level AES encryption to protect identifiable patient data end-to-end (e.g.  applies over-the-wire and at-rest), and drive-level AES encryption (which applies to data at-rest).
  • We have beta Linux infrastructure which was affected by this issue, however, no customers are using this infrastructure:
    • We patched the affected servers on Monday (within hours of the vulnerability disclosure)
    • The affected servers use a shared SSL certificate to encrypt traffic.
    • While it is very unlikely that our beta infrastructure would be the target of an attack (and we see no log activity to indicate this), in the interest of thoroughness we have re-keyed the *.wellpepper.com SSL certificate, and redeployed the updated certificates across our infrastructure.
  • In addition to our own infrastructure, we have also validated that all other infrastructure that we take dependencies have been appropriately remediated.

How This Affects You

  • No customer data or security credentials were compromised
  • There is no need to reset your password, however if you wish to, you may do this in the Settings screen within the WP Clinic app
  • Feel free to reach out to us at support@wellpepper.com if you have any questions or concerns

Posted in: Uncategorized

Leave a Comment (4) →
Google+