Consumer Access to Vaccine Records

As millions of Americans receive vaccinations in the coming months, will there be a consumer demand for vaccine data or “proof of vaccine” on their smartphones?

This NY Times article is a great read.

There is a serious debate on whether health passes, electronic vaccine credentials, proof of vaccine, etc is truly needed. Assuming it does happen, below is a quick summary of some of the puzzle pieces.

Patient Portals

When a provider administers a vaccine, it is entered into their electronic medical record system. Today, people can use apps on their smartphones to connect with the doctor’s electronic medical system called a “Patient Portal”. You setup a username and password with your doctor to login to the Patient Portal website to view your health records such as lab results, immunizations and prescriptions. 

Apps like Apple Health and CommonPass (Android) use common health data standards (HL7 FHIR) and application programming interfaces (APIs) to connect with these patient portals if your doctor has opted to make this available.

Here’s an example from Aaron Miri, CIO UT Austin showing vaccine records from a EHR connected to an iPhone displaying within the Apple Health app.

Immunization Information Systems

Each state, US territory and many large cities have an Immunization Information System (IIS) that is basically a big database that doctors, public health clinics and others have to report every vaccination into.

Vendors like Envision WebIZ and STC Health One that build these IIS systems that governments buy have consumer access portals.

Here’s an example from Nevada.

These portals use name, phone number and date or birth to match records and then the person can print out their vaccination records.

Hopefully, these vendors will introduce APIs that enable consumers connect their immunization records to their smartphones. States rely on these vendors and will likely not build these APIs on their own.

Work and School Safety Apps

There are a bunch of products that now help businesses and schools manage the health and safety of their populations. These tools will have features to track vaccinations.

An open question is whether these tools will be able to directly access vaccine records for their populations from the immunization information systems and in-turn enable consumers to have this data on their smartphones.

Tech stuff

Below is a list of additional reading on the technical topics related to interoperability of immunization data.

Medicaid Blue Button for States

States don’t need their own API sandboxes, code samples or developer support to enable 3rd party developers to adopt the new Medicaid APIs required by the CMS Interoperability and Patient Access Rule.

The rule basically says each state Medicaid plan (and many other types of plans) needs to “build their own Blue Button API” as many state health IT people say.`

I was part of the team that built the CMS Blue Button API. We had to do a few things:

  1. Map claims data to FHIR, setup a FHIR server, build an auth service, setup an API gateway
  2. Build a developer portal with a sandbox, docs, sample apps, production API access process and more.
  3. Procure the project in a way there was long-term investment in continuous improvement to the infrastructure, APIs and developer experience.

My friend Sam’s blog post Building your own Claims API from 2018 is a great read to better understand what our CMS team did and you’ll have to do for your state.

Because all states will be using the FHIR and OAuth standards, all of their APIs should be pretty much the same. This is super important because it means that states shouldn’t build their own sandboxes, docs or sample apps.

Let’s build a coalition

A group of states and organizations should get together and build an API sandbox. This will give developers a chance to play around with the APIs and prototype them into their own apps.

There should be a github site with a bunch of sample apps or build on CMS’s github along with more tutorials like Install an Angular Client App.

I’m looking forward to seeing what thought-leaders like the CARIN Alliance, CMS, vendors and states will do to bring people together here. Sharing things like a Blue Button sandbox will save taxpayer dollars and accelerate time-to-market for most states.

Happy Building!

Discoverability of COVID-19 testing sites

There is a national emphasis on COVID-19 testing now which makes the discoverability of local COVID-19 testing sites super important.

Schema.org has published new COVID-19 related tags including a CovidTestingFacility tag.

The White House has published general guidance for Federal and State CIOs

The City of Chicago’s Public Health Order 2020-6 Executive Order on April 29th mandates testing sites use these tags to publish machine-readable test site location data on their websites.

Apple Maps has these instructions on how to upload test site location data as well.

A typical discovery experience may look something like this (kinda obvious but worth noting):

  1. Person is told to get a test or thinks they need a test, searches for COVID-19 testing sites

2. After clicking “Coronavirus testing centers” they see results and a map

3. Then they click on “Website” to go to the testing location’s website

How a Civil Servant ends up building APIs

One of my favorite stories from my time in Washington, D.C. came from a dedicated civil servant who became one of my closest friends and colleagues at the Centers for Medicare and Medicaid.

With a background in public health and a passion to help people, she joined CMS 25 years ago. Over time, the policies and programs she was working on needed websites. As she took on more and more responsibility and began managing these programs, the websites now needed to allow people to login…and be discoverable on Google…and have web analytics…and conform to design guidelines…etc etc. She found herself learning about agile software development and using github.

Today, these same policies and programs now have APIs and all of the complexities that come along with building and operating APIs such as developer portals, key management, new security risks and developer evangelism to drive the adoption of these APIs.

When I asked my friend what her proudest moment has been at CMS she told me a story about helping get lead paint out of houses with kids in Baltimore. It is the impact that drives her, not the tech. She didn’t grow up coding in her parents’ basement or have fond memories of the first app she built. As Marc Andreesson says “software is eating the world” and this is so very true for government programs and the dedicated civil servants that run them.

By the way, the US Digital Service is always hiring.

The “Tim” story

I had the chance to work on a discovery sprint recently. During this two-week sprint, I revisited a bunch of agile delivery fundamentals in a way I haven’t in a long time. The project was suffering from some of the great, classic mistakes of software delivery we all know and love such as working in silos, internal politics, inability to deliver anything into production, finger pointing, comments like “we tried agile and it didn’t work” and so on.

Our discovery sprint team started using an example we called the “Tim” story. Tim is one of the executives in charge of the project.

After doing twenty user interviews, looking at code and reading a business case and other artificacts, one of our findings was the project was using a waterfall approach to manage a project with complex business rules, an ERP system. The team would talk about insufficient requirements and failing tests. Everyone was blaming each other.

Our recommendation was for Tim to be migrated out of the old system into the simpliest version of the new system that could be deployed to production. Because the team were working in silos, they had accomplished a great deal in their own silo but nothing worked together thus zero business value had been delivered in two years of working on the project.

Tim would receive his paycheck from the new system and if that failed, he could receive a handwritten paper check, bugs would be fixed and we’d try again two weeks later. Because Tim as an employee is one of the simplest payroll scenarios, the salaried employee with no special circumstances, we described this to the team as “the happy path”. Once Tim was being successfully paid by the new system, the entire management team working on parts of this project would be migrated. This is a way to deliver small iterative value while also demonstrating how committed the executives and team members are to the effort.

Now, a lot needs to happen before Tim can get his first paycheck. The system needs to be deployed to production, how a single employee is migrated from the old system to the new system needs to be understood, there needs to be confidence in the basic security of the production system and more.

As additional groups are migrated, the complexity will increase. For example, an employee that is working two different jobs with overtime and several dependents. They split their paycheck into several bank accounts and had previously worked at the company, quit and has now returned to their old job.

The team should take these complex use cases that the new system needs to support, focus on them as a team one-by-one and see success. They should continue in this “continuous improvement” phase of the project as new groups of employees are onboarded.

Contrast

Now, contrast the “Tim” story with the project team’s current way of working. For over two years the team has been assembling a complex list of never-ending requirements aspiring to a place where “we have all the requirements” (unrealistic) and “we have confidence the system works for all HR and payroll complexities” (impossible) and “then we can do a big bang cutover to the new system” (dangerous).

When our discovery sprint team talked about the happy path versus waterfall big bang approach in our readout it resonated with the whole team. You saw head nods from non-technical folks, agreement and understanding from Tim and validation from others saying things like “We tried 5 test cases six months ago and they all failed but they were our most complex payroll scenarios involving overtime pay, employees working two jobs and more. We never thought to start simple. This totally makes sense.”

In past products I’ve worked on, I’d tell a very similar story about “how we can take the first $1.” Executives would often scoff at this and talk about how we need to support millons of dollars of revenue and get inpatient. However, it’s powerful. Understanding the first simple flow, the happy path, the MVP, etc is still a great thing to lean on if you are trying to help unstick a giant enterprise project or working on your next small startup.

2018 Reading List: Healthcare, Politics and Algorithms

2018 began as 2017 ended, my wife, kids and I were happily living in Washington, D.C. surrounded by current events in both work and life.  

I began the year by reading Automating Inequality: How High-Tech Tools Profile, Police, and Punish the Poor by Virginia Eubanks.  This book helps you understand how bias is introduced into systems and is super relevant for folks working on or thinking about building prediction or filtering systems.

James Comey’s book gave me a better understanding of the FBI, it’s culture and relationship with the White House and DOJ. I liked the examples of empathy and reading people that he used throughout the book. Paying attention matters.

Artificial Unintelligence: How Computers Misunderstand the World by Meredith Broussard was excellent and I’ve recommended it to many of my teammates.  She talks a lot about algorithm accountability, ethics and bias.  Her simple “Titanic” data science example is fantastic.  

The President Is Missing: A Novel by James Patterson and Bill Clinton was a mystery thriller based on cybersecurity threats.  My wife and I had fun going to hear Clinton and Patterson speak during their book tour stop in D.C.  

Yes We (Still) Can: Politics in the Age of Obama, Twitter, and Trump by Dan Pfeiffer was “candy” for me as Chris Matthews describes it.  I love books like this that tell stories in an easy-to-read, funny style about the inside baseball of politics and White House goings-on.  I’m a huge Pod Save America fan and got a chance to see Dan talk with Alyssa Mastromonaco in DC during his book tour which was awesome.

The Devil in the White City: Murder, Magic, and Madness at the Fair That Changed America by Erik Larson was a really fun read for me since I rarely dig into non-fiction that reads like fiction.  I combined audible with the paperback and took a while to get through it.  Coincidentally, I finished the book on the Blue Line train into downtown Chicago.  I really want to visit Jackson Park now and see some of the old buildings.  A big takeaway was learning about all of the things that were introduced in the World’s Fair like the Ferris Wheel.

The Red and the Blue: The 1990s and the Birth of Political Tribalism by Steve Kornacki is a must-read for people interested in the current political climate and divide in this country.  It chronicles events from 1984 through 2000 talking about Clinton, Bush and the Gingrich Republicans.  Every chapter I was thinking “oh wow, so that’s what caused that thing we struggle with today.”

Medicare and Medicaid at 50: America’s Entitlement Programs in the Age of Affordable Care by Alan B. Cohen, David C. Colby, Keith A. Wailoo and Julian E. Zelizer is a very wonky read by helpful to understand the history of Medicare policy.  Since this directly impacts my work, it was super interesting for me.  The biggest story I’ve been telling from the book is about the role Medicare played in the Civil Rights Movement.  In healthcare, money drives so much of the behavior.  That was true then and is true now.


I started at least ten books in 2018 that I haven’t finished. This stressed me out for a bit then I read a quote about how having books laying around is good for you because it spurs thought, even if you don’t read every word. I loved this.

Now that 2018 is in the books (pun intended) and we are back in our hometown of Denver, CO, I still maintain my Politics & Prose membership and have added a Tattered Cover membership. Books, bookstores, reading and just being around books gives me so much mental energy, even if I don’t read every word 😉

Creating Momentum in Product Management

As a Product Manager, shipping and launching are always on my mind. Here are a few techniques I’ve used over the years to create momentum and keep the team excited about making progress and aligned on our ship dates and goals.

The big conference launch
I don’t love the “hit a date” tactics in product management but have used a big conference launch to generate steam successfully a few times. We did this with the launch of the CMS Blue Button API last year. When you have a big opportunity to generate press, attention and a bunch of new users / customers, it’s worth it. If you take this approach, make sure it’s a team decision and be ready to compromise a lot to get things shipped so you hit the date. You need to fundamentally appreciate how much teams hate having a date dictated to them and be an equal member in the quest. You are in this together. Also, be ready for tons of other non-software type work like doing press, building conference materials and being in a bunch of meetings making the various executives and stakeholders feel comfortable that the launch is on track.

Iterating towards the big vision
I know agile development is all about shipping working software, incremental pieces of the big vision. Sometimes it’s hard to get this train rolling. One of the approaches I’ve used a lot is getting the basic deployment pipeline setup early to deploy “hello world”. Once this is going, don’t be afraid to deploy tiny pieces. It will gradually build momentum.

If your product is stuck in some frustrating planning or architecture phase, try to find a way to keep moving forward. Can’t decide on a complex architecture? Try shipping a super simple user survey you can circulate around. How about shipping a basic piece of plumbing you are sure will be used in the product. Especially in the enterprise, my experience has been this really matters. Go a few cycles without shipping anything and the team will slow down to a crawl and morale drops. You’ll be having conference calls to plan the next conference call.

Intrinsic motivation meets good product goals
Luckily, most of the teams I’ve worked on over the years have a common understanding of the product goals and are motivated as hell to see the vision realized. In this environment, a PM needs to clearly articulate the goals and talk about how they are realized over time to give the team a good sense of the road ahead. If the team stalls, it’s usually the PM’s fault. Some decision is not being made and the path forward is not clear for the team to execute.

Summary
Good luck in 2019, I hope you build amazing things for people. As a PM, you know when the momentum isn’t there. Maybe you feel it yourself, the passion is gone and you aren’t obsessing about the product you’re building. Maybe the team feels broken and there are a million reasons why you can’t make progress. Hopefully if you find yourself in this state, you can use some of the techniques above to create momentum and ship!

Additional reading

The definition of “going live” – lessons from PivotDesk in 2012

Featured image from Undraw.

Glenmont to Farragut North

Beautiful, sad, newspaper, phone
Looking down, looking around, tall, short, fat
Hurting inside, motivated, exhausted, music
Glasses, hat, old, new, style, healthy, loving
Depressed, arms open, arms crossed
Friends bump into eachother and hug
Guy with a ponytail stares mindlessly at his phone
Girl with sad eyes daydreams

Launching Your State Digital Service

A Digital Service team with a one or two year “digital tour of duty” model  is a way for the top engineers, designers and product managers in your city or state to work full-time on the civic tech problems that make a difference for your citizens.

Most of the best tech talent in your State is not working for the Government.  They have probably never considered a career in public service or have no idea where to plugin.  A Digital Service creates that pathway.

The United States Digital Service

The U.S. Digital Service was founded in 2014.  Technologists from around the country move to Washington, D.C. for a one or two year term.  Most of the 180 or so USDSers are assigned to an agency like HHS, DHS, DoD or the VA.  Some work on longer-term projects at a single agency and others will work on many varying projects across multiple agencies.  The USDS is paid for out of a part of the OMB budget called ITOR.  Because the USDS has found technology solutions that save millions of dollars and executed on projects yielding very positive results for the American people, their funding and work continues.

Setting up your State Digital Service

In a State Digital Service model, the keys are funding and air cover.  It needs support from the top, either from the Governor or Mayor.  A big decision that needs to be made is where the Digital Service lives in your State’s Government structure.  Often, the initial thinking is for the Digital Service to report into the Office of Information Technology (OIT) because “it’s a technology thing”.  If OIT works across agencies and has great leadership, this could work well.  If not, your Digital Service could simply be viewed as staff augmentation and likely will fail.

You’ll need a charter, funding and the first cohort of awesome designers, engineers and product managers from your State ready to serve.  If the right structure is put in place, the talent in your region will seek out opportunities to be involved.

Once you’re setup and have your inaugural team on board, now the real work begins.  Picking the right projects is key.

The Work

In my year with the U.S. Digital Service I have seen a few scenarios where our USDS team was uniquely positioned to make a big impact.

Cross-team Projects

At CMS, the Blue Button 2.0 project required many different teams align on a shared product vision.  As anyone that has worked in a large enterprise knows, this is very complicated and hard to pull off in the best of circumstances.  Because the USDS had the air cover from CMS leadership, we were able to recommend and execute on a path forward that brought together several teams across divisions within CMS and shipped Blue Button 2.0 within a few months.

Procurement

The USDS brings great engineers to the table alongside an agency team to assist with procurement process and technology decisions.  The USDS helped design an Agile BPA and various processes to evaluate vendor proposals that included submitting code samples to Github and more.  This is such an important part of the success of USDS, the team even has a nickname, the Procuremenati!

Design Sprints

A design sprint is a process in which a small, cross-discipline team goes really deep on a problem for a short amount of time, typically 2-4 weeks (Ex: Defense Digital Service design sprint).  The nimble structure of a Digital Service team uniquely positions it for this type of work whereas normal agency constraints may hinder a successful design sprint.

Is your State ready?

To drive innovation, find new sources of talent and generally improve the quality of the software they are building for their citizens, State and Local Governments leverage many types of structures such as University Partnerships, Bloomberg I-Team Grants, Code for America and 18F, and more.  In my home state of Colorado for example, there’s a thriving open data challenge called Go Code Colorado, a Code for Denver brigade, over 1,300 datasets in the Open Colorado data portal and learnings from work with Code for America and more.  This is the type of CivicTech energy you want as you ready for your State’s Digital Service.  It shows a strong demand to engage in Government from your local tech community.

Each team begins differently.  The US Digital Service was born out of the technical problems during the launch of healthcare.gov and is four years old now.  The Canadian Digital Service launched less than a year ago and has added GovTech leaders like Aaron Snow to the team.  The UK Digital Service began in 2010 out of a “Digital by Default” mandate and has paved the way for other Digital Service teams.

Summary

The Digital Service magic happens when you combine the private sector design, engineering, and product management talent with Government talent that has the policy knowledge, deep subject matter expertise and understands how to navigate bureaucracy.

More Reading…

Digital Service Teams

Working alongside Digital Service Teams

Playbooks and Reports

Articles

CivicTech in Colorado

Screencasts for Product Managers

Screencasts are easy to build and a great way to convey information.  As a Product Manager, being awesome at communication is a big part of your job.  Can you tell a great story to customers?  Are you articulating the product roadmap to your company?

I have used screencasts to:

  • Demo a “Getting Started” experience on the website
  • Show off the product at a conference booth
  • Give product updates at Board Meetings
  • Describe the customer journey for a new product to team members
  • Help sales reps communicate with beta customers
  • Announce new product features on blog posts
My setup is:
My workflow to build a screencast is:
  1. Open Byword, type out a 1/2 page script (5 min)
  2. Grab scrap paper and pen, sketch a storyboard of the screencast (2 min)
  3. Plugin USB mic, open Quicktime Player and record the audio a few times to get the pace and tone of your voice sounding right (5 min)
  4. Open Screenflow, import the audio track. (1 min)
  5. In Screenflow, click record and capture video of your screen following along with the storyboard you sketched.  Do this a few times to get it perfect.  (5 min)
  6. In Screenflow, edit your screencast adding call outs, transitions and titles. (15 min)
  7. In Vimeo, go to Create / Music Store and search for an instrumental background track.  One you find one, download it and import into Screenflow.  Adjust volume levels of your voice track and the instrumental track. (10 min)
  8. Export your screencast to Vimeo (2 min)

Total time: 45 min

Tips

In Vimeo, there are a few helpful settings under “Privacy”:
  • password protect your video to share with a select group of people
  • set “where can this video be embedded” to “only on sites I choose” if you only want the video available within your app for example

I’ve used my iPhone to record a few seconds of people around the office, people in front of a whiteboard or monitor, etc.   If you are building a screencast to tell a customer story this can work well.  Plug your iPhone into your laptop and import the clip into Screenflow.

Examples

Further Reading