February 22nd, 2013

I am very excited about the Blue Button Plus. For a background on Blue Button, I have written about it here.  Blue Button Plus takes over where Blue Button leaves off –  its provides a blue print for how patient data is structured and how it is securely transmitted.

My new digital health startup is incorporating the Blue Button in the product that I we are working on, so I spent a few hours this week attending Blue Button Plus Webinar and watching videos from the Direct Connect Connect-a-thon.  I applaud all the work that is being put in the transfer of patient health data but I could not help but notice that the way it is being handled eerily sounds familiar to another time when a new concept for securely transferring data were being developed.  Being on the Webinar this week reminded me of my time in the late 90s/early 2000s in sessions in Redmond listening to the architecture of Web Services. It took me back to the time when of UUDI registries, WSDLs, WS-*, WSDL2* generators and all the other alphabet soup. I listened to the presenter talk about the  Trust Communities (groups of organizations that trust each other to exchange data) – a sort of “walled garden” and one could see right away that this has the potential to be messy. It is no surprise that even at this early stage, issues of how to get Trust Communities to talk to each other are already cropping up  i.e. protocols for getting two “walled gardens” to communicate. It reminds me of the time when we were trying to figure out how to push our White, Yellow and Green pages simultaneously to the Microsoft and IBM UDDI registries because we needed to be in both  registries and  the issues of the need for federated UUDI registries that came up just as they are now with Trust Communities

While I am concerned about the architecture of what is taking place today because it sounds like Web Services all over again,  I am most concerned that these complex solutions have the potential to suppress innovation around patient records because I think they are going to keep innovative startups from participating.  Here why I am concerned: How does a small startup get to be part of a trust community?  On the Webinar its was mentioned that organizations need to be accredited  to participate –  by whom and how much will that cost?  Will accreditation be at a cost that small companies can afford?  I think most who have gone through accreditation processes will agree that prepping for accreditation is a extremely costly in terms of time, resources and money – all of which are at a premium in a startup. There is a lot of hope for a coming technology-driven revolution in health care; however, if some of these issues are not addressed to help smaller startups (that are willing to take on risks to innovate) to play, there will not be much innovation in the patient record space.

Going back to my web services analogy; we all know how the web services story played out  - more inclusive approaches to solve data exchange problems, REST and oAuth, were a catalyst for for the innovation and opportunities in the tech industry today while Web Services as they were originally conceived do not play much of a prominent role outside of the enterprise. However, its not all doom and gloom because as soon as I started to think that “there has got to be a better way”, I received an alert on Thursday morning that Humetrix (a San Diego-based digital health startup) had created a new way to share patient records that simply involves the generation and scanning of QR codes.  In my opinion, simpler, inclusive and yet secure ways to exchange data are the way the catalyst for a technology-driven revolution in patient health records.

February 19th, 2013

I have blogged about how my quest for quality life landed me in the digital health space.  In the short time that I have been working in digital health, we have built products that have the potential to change people’s lives and improve their quality of life. One such product is cMove, a product that we developed collaboratively with the team at Children’s Hospital Colorado’s Movement Innovation Labs at the Anschutz Medical Campus at Fitzsimons.  cMove is a cloud-based tele-health physical therapy solution that enables patients to perform guided  physical therapy exercises from the comfort of their homes. We first demo’d cMove in January 2011 and completed it in April 2011 –  it was one of the first, if not the first, commercially-viable Kinect for Physical Therapy product on the market.

The cMove solution uses motion sensor devices, popularly used for gaming (such as the Microsoft Kinect) to create virtual fitness trainers and virtual physical therapists that enable patients to perform guided fitness/wellness/physical therapy exercises from the comfort of their homes. Physical therapists/clinicians customize therapy sessions and exercises for each patient. All compliance and progress data is reported back to the clinician via the the Motion Nexus cloud-based (internet) clinician management system in real time.

The most fulfilling aspect about working on this product is that it is a solution designed by physical therapists for physical therapists. The problem that the solution is solving was described by physical therapits as follows:

When a patient is discharged from the hospital, they are provided a set of papers with instructions for performing physical therapy exercises.  However, when the patient gets home, the physical therapist has no idea whether the patient is performing the exercise correctly or even performing them at all.

Performing exercises incorrectly or not performing them at all, increases the chances for injury, re-injury and readmission. cMove provides the physical therapist up-to-date reports on the physical therapy progress of the patient.  We built algorithms that capture the expertise of physical therapists which are used to guide patients through physical therapy exercises to ensure that they are performing the exercises safely and correctly.

When we completed this product a year ago, we had to argue with some health care organizations with respect to the value of lowering readmissions. However, now re-admissions are potentially very costly for hospitals and we don’t have to argue this point anymore. The Affordable Care Act (ACA), Hospital Readmissions Reduction Program,  introduced penalties for readmissions within 30days of discharge on certain conditions. The penalties kicked in starting in October 2012. In October 2012, more than 2,000 hospitals were penalized (forfeit) for a total of $280million in Medicaid funds for excess readmissions. This is just the beginning, the penalties are set to increase in the coming years.

I am very proud of the work we did with Children’s Hospital Colorado.  I think we successfully validated a digital health innovation model for how experts can colloborate at the intresection of healthcare and technology to create innovative, exciting and ground breaking products.

Check out the video below showing the cMove product, that I have described above, in action.


January 23rd, 2013

I meet many people in the health care industry who are not aware of the Blue Button initiative for personal health record ownership and portability. While the Veterans Administration (VA) played a significant role in designing the Blue Button solution and in pioneering its implementation, the Blue Button is now receiving considerable attention outside of the VA.  In my opinion, it is important to understand the Blue Button initiative because of its immense potential to solve the challenges of access to personal health records for all.


The following is the “Blue Button simplified” to help you get a basic understanding:



How do we provide people with easy access to their personal health information?



Provide people with a link to download their personal health information from the secure website of a doctor, insurer, pharmacy or other health organizations at any time.


How does it work?

Step 1: Person visits doctor’s website to download their health record

Step 2: Person logs in to their secure account on doctor’s website

Step 3: Person clicks on a clearly visible and accessible button to download their health record

Step 4: Person’s health record is downloaded as a file to the computer they are using to access the website

Step 5: Person opens the file and views their personal health record in a human readable format like this

Blue Button Sample Personal Health Record


Why is this a big idea?

The value of the Blue Button idea lies in its simplicity. It is a very simple consistent way to enable people to gain access to their personal health information. Regardless of the doctor, insurer, pharmacist or health care organization, the method for downloading personal health information is the same (you see a Blue Button on a web page and you click on it) and the format for the health record is the same (when you open the file, it is human readable).


Where can I get more information?

VA Blue Button Home

Robert Wood Johnson Blue Button Data 

Medicare’s Blue Button





January 22nd, 2013

(Hope this article gets me out of my blogging hiatus)

For those who do not know yet, I am working on a startup in the emerging digital health sector. A number of people have asked me how I ended up in digital health.  While I wish I had a reason like the proverbial “it’s an industry ripe for disruption”, the real reason why I ended up in the digital health sector was my quest for an improved of quality of life in the startup lane.

While working on my last startup, Filtrbox, I commuted from Denver to Boulder daily. I spent a considerable amount of time on the bus or the train (at one time I had a 100 mile round trip commute). Initially, it was exciting to go back and forth between Denver and Boulder to pursue my passion, however, the commute progressively wore me down. The most frustrating aspect of the commute is that it was getting harder and harder to “get into a zone” and when you are a software developer, the inability to “get in a zone” is a not a good thing (to put it lightly). I constantly felt like I was either on the bus, getting ready to be on the bus or missing a bus. Commute time took up huge chunks of my family time.  Quality of life diminished progressively over time.

Fast forward to post-Filtrbox acquisition. At the time that I was deciding on what I would work on after Filtrbox, my only criteria was that it had to be within walking or biking distance. My choice of what I would do next was going to be based primarily on quality of life factors (as relating to commute times). I drew a three mile radius a round my house and looked for things that interest me.  The one thing that caught my eye was the fairly new University of Colorado Anschutz Medical Campus at Fitzsimons Life Science District. So I HOPPED ON MY BIKE and headed to Fitzsimons to seek opportunities to “develop software at the intersection of life science and technology” (yes, that was my pitch).  After several weeks of building relationships at Fitzsimons and trying to convince people that I was serious when I said that the only reason I was looking to work at Fitzsimons is because it was in my neighborhood, I was finally able to land a fascinating project to work on.  While working on that project (collaborating with potential users and speaking with potential customers) out of the Fitzsimons Bioscience Park Center incubator/accelerator space, I quickly identified opportunities for a startup to solve a problem “at the intersection of technology and health care”.  An intersection that over the last year has come to be called “digital health”. I love to start things and starting a new venture, in a new market, within walking/biking distance from my house…..PRICELESS.

University of Colorado Anschutz Medical Campus at Fitzsimons

University of Colorado Anschutz Medical Campus at Fitzsimons

As a result of my desire to satisfy my quality of life needs, I am now building products that seek to improve people’s quality of life through the creation of new technologies that deliver innovative care models in the exciting and vibrant emerging digital health sector.  While I am very excited that through technology, I have an opportunity to change people’s lives in very meaningful ways, my own work life has changed in very profound ways. I work within walking distance from my office. I come back home for lunch. I don’t have to constantly worry about missing the last bus.  I am not wasting hours of my life (that I will never get back) on an RTD bus. I am spending all the hours that I have reclaimed with my family. I am not living in constant state of fatigue.  I have regained the vigor and energy that had begun to taper off during the tail end of my Boulder days. I feel like I am constantly “in the zone” again.

That is simply how my quest for better quality of life has taken me to the world of digital health startups.


September 22nd, 2011

Whats does your internal collaboration enterprise social graph look like?

Let’s cut to the chase, this is how it should NOT look like:

Internal Collaboration Enterprise Social Graph of US Senate in 2009 by Slate (Credit: Slate.com)

Fig 1: Internal Collaboration Enterprise Social Graph of the US Senate – 2009  (Source: Slate.com)

The graph you are seeing above is a visual representation of internal collaboration enterprise social graph of the US Senate [This force directed graph from Slate is based on votes in 2009 (I will be working on a 2011 graph). Each blue dot represents a Democratic senator, each red dot represents a Republican senator. A line connects two senators when they voted the same way on 65 percent of the votes]. The force directed graph clusters dots with the most connections to each other, pushing away dots with the least connections and as a result we can visually identify the people who collaborate with each the most and those who collaborate the least.

In my engagements with various companies, I have observed that many people draw an enterprise social graph as dots connected by lines, some even go as far as drawing pretty clusters of dots connected by lines as shown in the US Senate graph above. While such a graph is not incorrect, it is not what you want your internal collaboration enterprise social graph to look like if you are to have effective internal collaboration. An effective internal collaboration enterprise social graph looks like this:

Internal Collaboration Enterprise Social Graph

Fig 2: Effective Internal Collaboration Enterprise Social Graph (Source: Tom Chikoore -http://tomchikoore.com)

It’s not pretty, it’s messy but it’s effective. Each dot represents an employee and each line represents two employees who follow each other on an internal social enterprise collaboration community. This means each line represents a “bi-directional” follow between two employees. A bidirectional follow represents an open communication channel for effective collaboration. The color of each dot represents department in the organization. The following is a legend for some of the organizational departments shown in the graph:

BLUE – Sales
RED – Engineering
SALMON – Product Marketing
FLUORESCNET GREEEN – Product Management
ORANGE – Marketing
BLACK – Professional Services
ACQUA – Support

From this graph, you can see that the departments that one would expect to collaborate with each other are collaborating with each other. This is a beautiful visualization: Notice how the Support team is positioned between Engineering and Professional Services; and Professional Service is positioned between Support and Sales. This is the type of relationship you would expect to see is the majority of product development organizations. QA is positioned right next to Engineering and Product Management is nestled between Engineering Product Marketing, and Sales. This is what you would expect in most organizations, this is what your internal collaboration enterprise social graph should look like.

You can think of graph depicted above as a depiction of the “internal collaboration DNA” of your organization. Using this graph and the right algorithms, an assessment of the health of your community is possible. The right tools can help you identify collaboration problems and suggest solutions to fix the problems to enable effective internal collaboration.

For more information on the social graph and community health assessment tools send me an email at tom AT tomchikoore.com

August 26th, 2011

After writing the “It’s a “Service” stupid” article, I have been asked to talk about SaaS to engineering teams at companies that are making the transition to a SaaS delivery model. I have posted my intro presentation on Slideshare:

March 23rd, 2011

RE: Trending Topics

Dear Twitter,

You have an opportunity to become the system of record for historical events by re-thinking trending topics.

I love the Twitter trending topics because they reflect the pulse OF THE PLANET on any given day. To date, the trending topics have worked very well for providing insights into most popular topics on any day going back several weeks (using the Twitter APIs). The fact that I can use a Twitter API (for example, http://dev.twitter.com/doc/get/trends/daily) to access the trending topics for a given day, makes Twitter a form of a system of record for the most important topics of conversation on any given day. However, trending topics are not without their shortcomings. Now and again we see that certain hashtag memes and other Twitter memes tend to displace topics related to events of historical importance from the list of trending topics. Because Twitter APIs only return a maximum of 20 trending topics per day, some topics of historical importance that do not make it into the top 20 are essentially lost. In order to preserve trending topics of historical importance and establish Twitter as a reliable system of record for topics of historical importance, there is a need to improve the sophistication of the trending topics. In addition to the current trending topics, I would like to propose the contextualization of trending topics into Trending Topic Categories. Categorizing trending topics into categories such as People, Politics, Sports, Entertainment, Technology, Memes, Finance etc gives the opportunity for trending topics that do not make it into the Top 20 to make it into the Top 20 of their respective categories. Today, we are losing a significant historical record as memes crowd out other historically significant trending topics and potentially depriving future historians, researchers and school kids alike from getting accurate information when they search for answers to the following: “What were the major topics of discussion in technology 50 years ago on March 23, 2011″. I do not think the trending topic “#100factsaboutme” will be very helpful at all.

Given your donation of the Twitter stream to the Library of Congress, my assumption is that you do indeed recognize that you are a system of record of one kind or another. Your meta-data, such as trending topics, has the potential to be used for public good. It has the potential to help future generations understand our generation at a much finer granularity than we have been able to understand previous generations. As I ask you to make this enhancement to trending topics, I do recognize that you are a business and that contextualized trending topics may not be part of your business objectives; that is why I would like to suggest that you work with volunteers (open source-type of collaboration model) who are passionate about putting a taxonomy on the world’s conversations for the purposes of posterity. I, for one, would love to partake and many others will. Putting the categorization of trending topics in the hands of volunteers will guarantee that categorized trending topics are free to the public in the same way trending topics are today.

By re-thinking your approach to trending topics as suggested, you have an opportunity to become an invaluable true system of record that stands to benefit future generations.


Tom Chikoore

PS: If this is not the first time you have heard this request, I hope this letter finally tips the scale for you :)

March 12th, 2011

I am loving the new features in the new Foursquare 3.0 release. Being the big believer in the wisdom of the crowds that I am, I often rely on the Foursquare tips to help me navigate menus to find the best entrees each time I visit a restaurant. That is why I have been looking forward to using the new social recommendation feature in Fourquare 3.0 which is based is based on tips, to-dos and volume of check-ins. The recommendation feature is described in this excerpt from this Foursquare blog post:

For many, foursquare has been a great way to find out about the places your friends frequent (through check-ins) and learn about specific experiences to seek out (through tips and to-dos). For years we’ve wanted to build a recommendation engine for the real world by turning all the check-ins and tips we’ve seen from you, your friends, and the larger foursquare community into personalized recommendations.

This morning I was playing around with the social recommendation feature and observed that the recommendations are based on the popularity of a place. It looks like “popularity” is determined by the number of check-ins and tips. Unfortunately, Foursquare is not parsing the tips to determine content and context. Check out the following screen-shots for a Walgreens Pharmacy that Foursquare recommended:

Foursquare 3.0 Walgreens "recommendation"

Here is a Walgreens recommendation that came up as part of my search results. The tip below it caught my eye so I checked out the rest of the tips. See below.

Foursquare 3.0 Walgreens "recommendation" tips

Both tips for this Walgreens are negative.

For a recommendations, I would suggest that Foursquare parse the tips for sentiment. As a Foursquare recommendation service user, I would like the places that are recommended to me to be not only places that have a high volume of check-ins and tips but also a high volument of positive sentiment tips. If the algorithm is enhancement to include some sentiment analysis, then this Walgreens store would not have been recommended to me.

March 9th, 2011

Had a recent conversation with @arinewman about our SaaS experience during the Filtrbox days and it reminded of this blog post that I wrote last year after I counseled a local company on the SaaS delivery problems it was experiencing (unfortunately, like most posts, I started writing the post and it has remained the “Drafts” folder ever since)

As CTO of Filtrbox, I found myself primarily responsible for service delivery and customer experience instead of the traditional CTO responsibilities. That was as a result of a progressive lessons that I learned along the way about running a SaaS company. With the help of mentors, @slcaruso and @sether, I grew to appreciate good practices of running a successful SaaS offering (we were not always successful in reaching reach our goals but we a made a concerted effort to run the company using the the best SaaS practices). Many a blog posts have been written about SaaS from a technology and architecture point of view; in this blog post, I would like to share some fundamental aspects of SaaS that are often overlooked and often lead to unsuccessful SaaS implementations regardless of a solid technology or architecture.

Its a “Service” stupid
The following is a screen-shot of the description of the “Service Delivery” responsibility for my role as the CTO of Filtrbox:

Screen shot 2011-03-09 at 2.50.57 PM

The most important part of delivering “Software-as-as Service” is not the “Software” but the “Service”. In order to deliver SaaS successfully you have to first recognize that your service is essential to someone (if it was not, they would not be your customer). To your customer, you are just like the telephone, power or water company. There is a level of expectation that we have for the services delivered by these companies (disclaimer: this example may not be relevant in all parts of the world). When we turn on the faucet we “expect” water to come out regardless of the time day or holiday, we do not expect to check Twitter for service “updates” or explanations and in the event that there is service interruption, it is of the highest priority to the service company and is quickly resolved. When you analogize your company with these tried and true old school service companies and when you think of yourself that as a service company first, then the notion of “service first” becomes ingrained in the DNA of your company, your team, your products and your processes.

Customer Experience
If you are a SaaS company and the goals of your offering do not include the words “customer” or “service”, then you should not be delivering a SaaS offering. I would even go as far as saying that if the the description of roles on your team do not include the word “customer” and, “service” or “experience” , you are headed for the Deadpool. Understanding customer experience is of fundamental importance to SaaS delivery. Before you embark on a SaaS offering, go through the exercise of mapping the the experience that you want your customer to have when they use your service. What do you want the customer’s experience to be at every touchpoint with your company? While some touch-points are not necessarily directly tied to SaaS, it is important to account for them as well if you are to get the notion of “service first” ingrained in your company’s DNA. Out of this will come your service warranties (availability, service response times, customer response time, security etc)

Always On
If your service was not valuable to a customer, they would not be using it. Therefore deliver it like its valuable to someone. Users of a SaaS offering expect it to be “always on” (think of the phone, lights and water). Frankly I don’t really care about the technology and efficiency of how the water company gets the water into the pipe, they could be using a bunch of people pouring buckets into the pipe for all I care, my expectations is that when I turn on the faucet, water comes out. Your SaaS users have the same expectation. As an engineer, it pains me to say this, but SaaS users don’t really care about the beauty of your code, its cyclomatic complexity or any of that engineering stuff; they just want your product to work and meet their needs when they use it. That is all they expect. This is not say, you can get away with crappy code, in fact recognizing this has the opposite effect, it leads to better software, hardware, hosting and operations choices.

You are a “Service Delivery” Company
In order to deliver a “service” that is “always on”, the whole company from the top down has to have buy in into the the notion that you are actually a “Service Company” more so than a “Software Company”. The buy in is important because it leads to structuring the organization for service delivery right from the beginning. Recognizing that you are a service delivery company forces the company to provide adequate resources to service delivery related functions. It forces resource planning that values customer service, product development, hosting/operations resource equally.

Because most companies do not see themselves as “service delivery” companies, they often find themselves well staffed in engineering but severely understaffed in hosting/operations and customer service – a recipe for a short-lived SaaS operation. Once a SaaS offering is operational, if your company has engineers only, there is going to be very little engineering and innovation to be done because you engineers are going to spend their time supporting the system and the customers (I say this from experience). I’d recommend hiring a service administrator or service support person instead of an additional engineer because that they free up the engineering team to innovate and make progress on the product. Balance your resources accordingly, you are service company now.

Rather than be obsessed about the “software” aspects of SaaS, I strongly recommend that companies thinking of delivering SaaS offering undergo a midshift and think of themselves as “service” companies first. The above-mentioned aspects allow you to build the “service first” mentality into you company’s DNA. When you do that all the other software aspects will fall into place.

January 23rd, 2011

In my last blog post, I talked about managing my signal overload problem. Since then, I have been looking for a tool to help manage my signal overload problem. I have tried several tools and Summify is the one tool that I am using now. I have setup up my Summify account to aggregate the most important content items from my Twitter stream. Each day Summify send me a digest of the most important content items from Twitter stream. From what I can tell, Summify is using a combination of retweets and shares to figure out the most the top ranking content items in my social graph. I have verified whether the content items it suggest are really the most important and it all cases Summify was correct. However, the the results tend to be skewed towards high trending news items. I have not found any “nuggets” yet. While this is not a simple problem to solve, the guys at Summify have started on a good note. On days that I cannot go through my Twiter stream, I turn to Summify to catch up on the most important content items of the day.