Kaiser Permanente Administrators barged into my exam room

Kaiser Permanente Administrators barged into my exam room

Executive Summary

I had three hospital administrators barge in on me in an exam room the other day. I feel that this was inappropriate, and that the situation could have been handled in a more professional manner.

I had submitted the following as a complaint to Kaiser, which they claim they respond to within two business days. That was two weeks ago. I was not going to publish this if they had responded even within two weeks. Below is the complaint that I had submitted, as it was written a couple weeks ago.

Actual Complaint Filed

Yesterday, I visited the Kaiser Permanente facility on Homestead and Lawrence in Santa Clara, CA for a doctor’s appointment. I was wearing Google Glass, as I always do, and when I checked in, the receptionist asked me about Glass, and informed me that I was not allowed to take pictures, or record video while in the hospital. I said of course, that’s not something that I would do anyway. Then, I sat down in a chair and was called in about 15 minutes later. I had my basic measurements taken, and was escorted into the exam room, where some information was entered, and I was asked to take off my shirt, and put on a hospital gown.

After waiting a bit for the doctor, I heard a knock on the door, and then three hospital administrators entered. (I don’t remember who they were, or what their titles were, but I’m sure it wouldn’t be hard for you to figure out.) They were polite, but looked uncomfortable, and I couldn’t really figure out why they were there at first. I was not pleased that they were paying me a visit in my exam room in the first place, and immediately started to wonder if this was typical procedure, for hospital administrators to enter patient exam rooms when they are half-dressed to come in for a chat? Then they started asking me about Glass, and I understood why they were there.

That conversation was basically one of the administrators explained that there was a privacy policy at Kaiser, that said that nobody’s allowed to take any photos or videos while there. She asked if the receptionist had explained this to me, and I said that he had mentioned something along those lines. She then asked if they could hold my device until I was done. I declined, and asked if they routinely confiscate patient’s smart phones when they walk in the door, and I noted that she had an iPhone, with a camera on it. I explained that you don’t do that, because you assume that people have some common sense about these sorts of things, that they won’t go around snapping photos in a hospital. I also explained that the current crop of Glass Explorers are all quite sensitive to this issue as well, since we are all very aware of people’s concerns about the device. She seemed to agree, and they left.

I’m not upset about the conversation. It’s totally reasonable for people to raise concerns about new technology. However, I do have a couple of things that I am upset about. First, it seemed inappropriate for the administrators to barge in on me in the exam room when I was half dressed. It made me feel vulnerable and intimidated by your staff. Second, I don’t like it when companies (that I give thousands of dollars to annually) treat me like a potential criminal instead of a paying customer who they care about. I especially don’t like it when there seems to be a basic distrust of me, in that situation, when I am entrusting your organization with my life.

Regarding the first issue, I can see at least two better ways of handling the situation. First, they could have phoned the desk, and had me wait outside until the admins could come down and meet me in the waiting area. This would have been fairly easy to do, how hard is it to make a phone call? Second, they could have waited until my exam was over, and had a nurse come in and inform me that I would need to speak to them on my way out.

I don’t really have a good fix for the second issue, I have big problems with companies that treat their customers like criminals, especially when they attempt to violate those customer’s rights (4th amendment to the Constitution, unreasonable search and seizure). Again, a conversation is fine, asking me to remove Glass while in the hospital would have been reasonable as well (which I’ll be doing from now on anyways). Attempting to confiscate my property using intimidation is not OK.

What I want

I would like an apology.

I would also like to know if it is hospital policy for administrators to enter patients’ exam rooms for things like this, or whether you try to address these sorts of things in a way that doesn’t put your patients in a situation where they’re feeling vulnerable and intimidated by your staff?

As far as Google Glass goes, this is something that your organization is going to need to figure out. This incident occurred in Silicon Valley, where you will start seeing more and more people coming in the doors with wearable devices, some less obvious than Glass. You will also likely have doctors in the near future wearing Glass. You may even issue Glass to your staff, since some of the most interesting Glassware being written about are for medical applications. People are doing truly amazing things in that space, and I’m sure you won’t want to be missing out on that.

Update

Two things. First, I received a letter from Kaiser stating that they would be sending me a letter within 30 days on the issue.

Second, after getting some opinions, and talking to people, I realize that this was probably a situation where I could have shown some more tact while walking into the hospital. I probably should have removed Glass prior to walking in, regardless of what was actually required or enforceable. I do remove Glass whenever I go into a hospital now, again, because it’s the tactful thing to do. I still think that the situation was handled poorly by the administrators, and that they could have found a better way to communicate with me than barging in on me in the exam room.

Additionally, it’s been interesting reading different people’s opinions on Glass in this situation. Some people are railing against me, saying that this is an obvious privacy violation on my part. Others seem to think it’s more similar to a smartphone, and that I shouldn’t have been bothered. I think I’ll hold onto this one as a conversation starter.

Update 2

I had failed to include this detail previously, but when I was called out of the patient area, I removed Glass, and put it in my shirt (just like I do when I use a public restroom). When I was in the area where patients are being interacted with, Glass was not on my head, and the camera was not exposed. When the admins came, Glass was sitting with the rest of my belongings, not on my head.

Soylent: Weekly Recap 10/6

Soylent: Weekly Recap 10/6

http://blog.soylent.me/post/63348494473/weekly-recap-10-6

Looking forward to getting my week’s worth of Soylent in a couple months. Really curious as to whether that will be sufficient for me to switch over most of my meals.

soylentme:

First off, apologies for those who have been checking their emails for Backerkit invites — turns out we needed a few customizations made by the Backerkit team before we could get started. We’ll start rolling out invites on Monday. Now, on to what we worked on this week:

We received a bench…

TiKL on Glass

TiKL on Glass

This weekend, my co-worker, Darrel, and I (we work for TiKL, Inc. - YC W12) attended a Google Glass hackathon a Markerly’s headquarters in Menlo Park. We were working on a version of TiKL, a walkie-talkie app for Android and iOS (with 27 million users!), that works on Glass. We made some good progress. Hopefully over the next week we can carve some time out in the evenings to turn Glass into a walkie-talkie with TiKL.

Update:

It’s pretty barebones right now, but it does work!

Giveaway - Raspberry Pi

Giveaway - Raspberry Pi

I’m giving away my Raspberry Pi. I haven’t used the thing in months, and I’m trying to get rid of all of the things that I have that fall into that category. I would sell it, but it’s simply not worth enough to justify the effort. So, instead, I thought that I might try something a little different. Post a comment on Reddit, telling me why I should give you this RPi. The highest scoring entry will win the device. I’ll even pay for shipping.

The device will come with a power supply, and a blank 8GB SD card.

EDIT: I’ll run this for 24 hours, so it’ll end tomorrow, October 1, 2013 at 10am PT.

UPDATE:

Redditor Jawshee_pdx has won, with 160 upvotes for the following entry:

Jawshee_pdx: My youngest daughter is showing a greater and greater interest in computers and technology. I’d like to get her a raspberry pi to hopefully foster strong STEM learning.

I’ve shipped out the device, and hopefully Jawshee_pdx will confirm at some point that they received it.

UPDATE 2:

Jawshee_pdx confirmed that he received the RPi. Hope he and his daughter enjoy it!

A different kind of app

A different kind of app

The Play Store is an interesting thing, it’s incredibly cheap to have a developer’s account (or two, whoops), there’s no review process to get your app approved in the store, so you could literally get something written, published and delivered within a few hours, if you were motivated to do so. Well, I’ve had this idea for a couple of months now, that I wanted to try out, sort of an experiment, I wanted to make an app for my wife that would take the place of a greeting card. So, I did!

It would be much more personal than a greeting card, since I’d be writing it for her, but it also felt a bit different. One thing about us is that we live across the country from our families. Whenever we’re together and there’s a birthday, or celebration where greeting cards are exchanged, they are usually passed around for everyone to look at. That’s much harder to do when you live ~2,500 miles away. We tend to do our sharing with family on Facebook, greeting cards don’t usually make the cut.

A couple of times, for anniversaries or birthdays, I’ve made greeting cards for her by hand, but this feels a bit different from that too. There’s a lot you can do with the tools that you have at your disposal these days. Sometimes, using them to put a smile on your wife’s face is the best thing that you can spend a couple of hours doing.

I wonder if, in the coming years, we’ll start seeing more of these types of apps pop up. I don’t think that I’ve seen any previously, though I’m sure that this is not a unique idea. I’m curious to know who else has done a project like this, published something that was more experimental than most other apps, or doesn’t really fit into the typical notions of what an app should be.

Here’s the app itself.

Zapier and Google Glass I’m just getting around to checking out Zapier’s Glass support, and it is more compelling than I expected. While it would be nice if there were simply more apps available for Glass, Zapier sort of fills in the gaps, and allows you to do some interesting things. For one thing, I can now get notified on my two other gmail accounts on Glass. Since I use my work email way more than my personal, this is going to be a very useful feature. I’ve also got it set up to allow me to share photos to Dropbox, which is nice, my phone does this automatically, but until now, if I wanted a photo from Glass on Dropbox, I would have needed to download the photo on my laptop, and upload it to Dropbox manually. I am trying out the Trello integration as well, since my wife and I use that for the grocery list, though I’m not sure how useful that one will be for me. The interesting thing about this is that it greatly extends what you can do with Glass, for very little effort. It does feel like more of a temporary solution, as opposed to a long-term one, where the long-term solution would be these services rolling out their own Glass support, and Glass supporting multiple Gmail accounts (which I’m sure it will at some point). For the time being, I’m quite happy to have Zapier available.

Zapier and Google Glass

I’m just getting around to checking out Zapier’s Glass support, and it is more compelling than I expected. While it would be nice if there were simply more apps available for Glass, Zapier sort of fills in the gaps, and allows you to do some interesting things. For one thing, I can now get notified on my two other gmail accounts on Glass. Since I use my work email way more than my personal, this is going to be a very useful feature. I’ve also got it set up to allow me to share photos to Dropbox, which is nice, my phone does this automatically, but until now, if I wanted a photo from Glass on Dropbox, I would have needed to download the photo on my laptop, and upload it to Dropbox manually. I am trying out the Trello integration as well, since my wife and I use that for the grocery list, though I’m not sure how useful that one will be for me.

The interesting thing about this is that it greatly extends what you can do with Glass, for very little effort. It does feel like more of a temporary solution, as opposed to a long-term one, where the long-term solution would be these services rolling out their own Glass support, and Glass supporting multiple Gmail accounts (which I’m sure it will at some point). For the time being, I’m quite happy to have Zapier available.

Very simple example of a Loader and LoaderManager in Android

Very simple example of a Loader and LoaderManager in Android

Loaders in Android are great, they allow you to asynchronously load data to be used in Adapters. I have found CursorLoaders very useful for getting data from a database to the UI in a way that minimizes blocking calls on the UI thread.

Alex Lockwood has posted a great, and detailed four part discussion of the Loader pattern on his blog. If you don’t know much about Loaders, or the LoaderManager, or why you might want to use them, go read that series. This is the nickle tour. My goal here is to show you just what you need to get you up and running with this.

Loaders are simple

All you really need to do is move your query into the loadInBackground method, and the rest is boilerplate.

Something to call back to

You’ll need to put the LoaderCallbacks somewhere, you can put it where you like, in an Activity or Fragment, or in a separate class. They just need to go somewhere.

Call it!

Now that you’ve got the Loader and the LoaderCallbacks defined, you can call it, and start benefiting from painless asynchronous loading of your data.

Sample

I added a Loader to the same sample project that I blogged about in my previous post. Here’s the source.

AndroidSerialSQL - solving some problems with SQLite in Android

AndroidSerialSQL - solving some problems with SQLite in Android

I created an Android project library that intends to solve the problem of concurrent write attempts from different threads to an Android SQLite database. Get the project here.

Quick Edit

This solution is intended to solve a specific problem, not to be used in the general case. In a larger, more complex application, you might have data coming in from different sources asynchronously (on different threads), being written to different tables, at random times. In such an application, there is the possibility for two simultaneous writes, where one may silently fail due to a database lock. This solution aims to prevent that from happening. This is not intended for the small application with infrequent database writes, or in cases where you think that being locked out on writes is extremely unlikely, in those cases, it would be better to bundle your writes in batches and transactions, which you should try to do within this framework as well.

The Problem

Here’s a blog post explaining the issue, along with a choice quote:

If you try to write to the database from actual distinct connections at the same time, one will fail. It will not wait till the first is done and then write. It will simply not write your change. Worse, if you don’t call the right version of insert/update on the SQLiteDatabase, you won’t get an exception. You’ll just get a message in your LogCat, and that will be it.

This goes farther than the singleton pattern of only getting one database object (or one writable database object) and implements a blocking queue with a thread pool executor, where the thread pool has a max size of one. This means that there will be a single thread that handles database write operations, and it will work through the backlog of requests that exists in the queue.

In order to accomplish this, we cut off access to a writable version of the database outside of a couple abstract runnables, which are intended to be added to the queue. WriterTask and UpgradeRunnable are those specialized runnables, both of them hold a reference to a database, and have ways of grabbing a reference to the writable db. There are a couple of data structures dedicated to handling the database (or databases), and these special runnables.

Using this lib

This is a standard Android library project, so if you’re using Eclipse, or are familiar with using Android library projects, just do what you normally do. I should probably turn this into a jar at some point, but I’m lazy, and may not get around to it. Plus, if I did that, I’d want to make sure that it was polished enough to submit to Maven Central and all that jazz, but that’s not where things are right now.

Use at your own risk! Right now, this is more of a good starting point, and something to look at as a reference. Don’t pull it into your project unless you plan on forking it and fixing problems as they appear.

If you’re using Gradle, you can do the following in the parent directory, or wherever you want to put your libraries:

git submodule add git@github.com:emil10001/AndroidSerialSQL.git

In your project parent’s settings.gradle:

include ':YourApp', ':AndroidSerialSQL'

In your app’s build.gradle:

dependencies {
    compile project(':AndroidSerialSQL')
}

Usage

There are a few steps to get this up and running. It should all be fairly straght-forward.

1

Create a defenition of your database.

DefineDB myDB = new DefineDB("myDB", 1);
myDB.setTableDefenition("items", 
  "create table items "
  + "( _id integer primary key autoincrement, "
  + "item text);");

2

Use the defenition to open/create the database, and store it in a data structure for use.

AccessDB.addDB(context, myDB);

3

Insert an item into your database.

AccessDB.addWriteTask(new WriterTask("myDB", callback) {
@Override
    public void run() {
        db.beginTransaction();
        try {
            ContentValues values = new ContentValues();
            values.put("item", "five");
            db.insert(ITEMS, null, values);
            db.setTransactionSuccessful();
        } catch (Exception ex) {
            Log.e(TAG, "failed to insert", ex);
        } finally {
            db.endTransaction();
        }
        callback.run();
    }
});

4

Retrieve things from the database.

AccessDB.getReadableDB("myDB").query("items", null, 
  null, null, null, null, null);

5

Handle upgrades by adding to the database defenition.

myDB.setVersionUpgrade(2, new UpgradeRunnable() {
    @Override
    public void run() {
        db.execSQL("create table two"
        + "( _id integer primary key autoincrement, "
        + "different_thing text);");
    }
});

Sample implementation

Check out the sample branch for a working app that implements this library.

Get the project

Here’s the repo on GitHub.

Android Sqlite Locking

Android Sqlite Locking

touchlabblog:

Recently I’ve been doing quite a bit of work with the Android Sqlite database.  Mostly with the android piece of ormlite.

The Android examples cover some basic Sqlite usage, but they really don’t go into depth with regards to proper usage patters, and more importantly, improper usage patters.  Most examples and documentation is slated towards using very basic database queries, and beyond that, creating a ContentProvider.  What never really seems to be covered is stuff like:

• Where do you create and store your SQLiteOpenHelper instances?
• How many should you have?
• Are there any concerns when accessing the database from multiple threads?

If you look around for information you’ll find a lot of partial or incorrect info.  A great example was forwarded to me by Gray yesterday (he runs the ormlite project).  It was on stackexchange…

http://stackoverflow.com/questions/2493331/what-is-best-practice-with-sqlite-and-android/2493839

Read More

This is a great post on Android SQLite, and definitely worth taking the time to read. I first found it a year ago on a different blog, the post seems to move around once in a while, so grab an offline copy for safe-keeping.

Trying SlidingPaneLayout with Fragments (in Android)

Trying SlidingPaneLayout with Fragments (in Android)

Building on my last few posts, I wanted to try out the new SlidingPaneLayout that’s being offered in the support library. For the uninitiated, here’s a Google I/O presentation that presents SlidingPaneLayout along with a few other new UI concepts for Android:

This was super simple to do, so I’m going to go fairly quickly again.

Instructions

0

My last few posts, are prerequisites for this one. So, make sure that you’re up to speed on those.

1

Add a SlidingPaneLayout section to your activity, it should contain a couple views that you can attach things to later. Since we’re attaching fragments, these needed to be some sort of ViewGroup, and FrameLayout implements that.

2

In the MainActivity, we want to grab a reference to the SlidingPane, start it as open by default, and attach our content to it. Our content happens to be fragments, but you can attach whatever views you feel like here.

3

The fragments are pretty simple, we simply inflate the layout. I also decided to put some text and a color in there.

4

This is the layout file used by the fragments.

Conclusion

This whole thing took less time than it did to install the 0.2.6 upgrade for Android Studio, so if you’re thinking about using a SlidingPaneLayout, it’s incredibly simple, so just go for it!

Github repo here.