Advice to Incoming Government CIOs

Image of founder fathers building software

Building the Capacity You’ll Need

As we head into the 2026 midterm cycle, we’ll see dozens of governorships turn over, new mayors sworn in, and a wave of transitions in state and local IT organizations. For the incoming CIOs, CTOs, and digital service leads, this moment brings a rare kind of opportunity. You’ll inherit legacy systems, legacy contracts, and legacy decisions, but you’ll also inherit a public that expects government technology to work as well as the apps in their pocket.

This is written for those stepping into those roles. I hope it offers a practical view of what really matters in your first year, and how you can build the state capacity to deliver for residents.

Make Policy Reform Part of Your Delivery Toolbox

State and local policies shape everything you will be able to do: hiring rules, job classifications, procurement authority, interpretations of federal guidelines, budget structures written for a pre-internet era. In Colorado, when we started the Colorado Digital Service, we couldn’t hire anyone who lived outside the state. Our job descriptions needed updating, and the budget process was geared toward projects with a start and end, not products that need continuous improvement for years. All of these constraints shape delivery far more than any platform decision ever will.

Incoming CIOs have a unique window to push for reform:
• Hiring and HR modernization: Can you hire remote staff? Can you bring in short-term experts? Can you compensate for modern skills?
• Procurement flexibility: Modular contracting, outcome-based solicitations, pilots before full commitments.
• Budget structures: Moving away from multi-year waterfall appropriations toward funding that supports continuous delivery.
• Federal interpretation: Many “rules” are simply norms. States that ask federal partners for flexibility often get it.

As Jen Pahlka said in her discussion with Sam Hammond, “When we burden public servants, we don’t relieve burden on the public.” Fixing the policy scaffolding around delivery is the best way to reduce that burden.

Take the Long View

Government doesn’t build for quarters or for annual OKRs. It builds for decades. The systems you shepherd today may still be running when your children are grown. Someone will inherit them just as you’re inheriting what came before you.

Adopting a long-view mindset changes how you lead:
• Instrument everything. If you can’t measure it, you can’t improve it. Build observability into every service such as uptime, latency, abandon rate, and user pathways/funnels.
• Center the user journey. Residents don’t experience agencies. They experience a life event like applying for childcare, renewing a license, or seeking housing support. Build around that reality.
• Continuously deploy. Policy changes and bugs happen. Focus your delivery teams on the basics like shipping a text change or a line of code. Make sure this is perfect.
• Leave things better documented than you found them. Future teams shouldn’t have to rediscover the map of your systems.

You don’t need to be the CIO who solves everything. You need to be the CIO who ensures the next team can keep building without starting from zero.

Build State Capacity

Real capacity is structural. It comes from three places, none of which involve publishing another strategy document.

Build or strengthen your digital service team

Digital service teams bring modern product, design, and engineering talent into government. They sit close to the work and act as translators between agencies, vendors, and policy staff. They augment your delivery teams ability to understand contractor proposals, guide architecture decisions, and be a smart buyer.

When we built the Colorado Digital Service, we saw firsthand how many people in the region wanted to serve, they just needed an entry point into government that was more familiar. You can create that entry point. Read more about that here.

Work across states — because your problems aren’t unique

Your challenges aren’t new, and they aren’t unique. Whether through health information exchanges, multi-state collaboratives, NASCIO, or informal networks of CIOs sharing what actually works, you can borrow patterns that others have already tested.

The Software Collaborative is one of my favorite concepts.

Partner with organizations already built to help you

Code for America, U.S. Digital Response, Beeck Center, Schmidt Futures, National Governors Association, Recoding America Fund, and academic partners…there’s an entire ecosystem around you. But collaboration only works when it’s structured as real shared work.

Round tables and being on panels at conferences is great, but how can your teams actually roll up their sleeves and collaborate deeply with these orgs? Give your internal team explicit permission and mechanisms to collaborate: shared GitHub repos, co-designed sprints, open technical roadmaps. Don’t just talk about partnership, enable it. We did this during COVID at every level of government and it can be done again.

Modernize HR

You can have the best strategy in the world, but if your only hiring path is outdated job descriptions, low salary bands, rigid classifications, and in-state requirements, you won’t be able to hire the talent you need.

Capacity is people. If you want to deliver modern services, you need modern hiring.

Tie Your Work to Resident Outcomes

CIO conversations often drift toward cloud migration strategies, cybersecurity frameworks, shared platforms, and enterprise architecture. All important. None of them matter unless they connect to the experience of real people.

Anchor your work in questions like:
• Did a resident access a benefit faster?
• Did a worker’s administrative burden decrease?
• Did an agency get the ability to release data safely instead of emailing spreadsheets?
• Did dollars move from overhead to direct public service?

This is the language governors, legislators, and agency heads understand. It’s also the language that earns you the political capital to fix deeper structural issues.

Know the Power, and Limits, of Your Role

You won’t fix every legacy system. You won’t solve every procurement bottleneck. You won’t modernize every program in your turn to run with the baton.

But you can fix the conditions that determine whether your teams can deliver:
• You can modernize hiring and classification.
• You can reshape procurement.
• You can create a digital service team with real authority.
• You can standardize modular, iterative delivery.
• You can document the system and leave it better for the next team.
• You can help your government org interpret federal requirements with more flexibility.

If you do those things, you will have built real capacity, not just for your tenure, but for the teams and leaders who follow.

And residents, especially those who rely most on public services, will feel the change.

Good Luck to the new Mayors!

(Originally posted Aug, 2023)

With nine new Mayors taking office this year representing cities with the largest populations and countless others across the country representing smaller towns and mid-sized cities, it’s a good time to think about how these new administrations can approach technology.

With such large technology portfolios that span transportation, permitting, healthcare, public safety, and much more, a new Mayor and their CIO, CTO, and leadership team can create an environment whereby the Government is held accountable for designing and delivering services with a focus on the actual experience of the people whom it is meant to serve.

Within the first 100 days, new Mayors can:

Within the first year, new Mayors can:

  • Invest in user experience design and research talent and processes that will contribute to better service design
  • Create agile vendor pools that will lower costs and increase competition for the technology products and services the city purchases
  • Build a talent pipeline of technologists, junior and senior, specifically product managers, UX practitioners, and cybersecurity experts
  • Invest in a zero-trust security model and evangelize for security best practices across all horizons of the application development lifecycle

To succeed in service delivery, new Mayors and their teams must consider the customer journey of the people they serve. For example, in Colorado, nearly 20% of residents are covered by Medicaid. Medicaid is a Federally-funded program with a diverse ecosystem of local partners that deliver services to City and County of Denver residents. The City must take an active role to ensure appropriate health data information is being shared across various levels of government as needed and foster a culture of listening, user research, and service design that can best support the work of all of our government and non-profit partners.

To understand if the delivery of a service is working for the people, instrumentation, monitoring, and observability are critical. Teams in charge of services should have a deep background in audience metrics, funnel analysis, conversions, and more. Using quantitative product metrics combined with qualitative user research is how delivery teams build empathy for their users and iterate toward the product/market fit needed to serve residents best.

Building a culture focused on impact and outcomes is incredibly important for a new Mayor, especially within their technology portfolio. Formal techniques can be helpful such as OKRs to guide teams or prompt product managers to use the phrase “as measured by” after describing the impact a feature or change will have on users. I have seen both approaches work well.

I wish this new class of Mayors the best of luck and know there is a community of technologists at all levels of government, non-profits, and tech companies that are always there to help improve the delivery of services in the communities they love. Please don’t hesitate to reach out to us!

Keep Reading:

City of Boston’s Five-Year Strategic Plan

US Digital Response – helps local governments with service delivery

Launching a Digital Service

Future of Infrastructure podcast

Recoding America by Jennifer Pahlka – required reading for government CIOs and delivery teams

Environmental Permitting

On April 15th 2025, this Updating Permitting Technology for the 21st Century Executive Order was signed.

The new directive pushes agencies to ditch paper forms, speed things up with better tech, and make the whole process more transparent. It also asks the Council on Environmental Quality to create a tech roadmap for a shared system across agencies. The goal? Cut red tape, make smarter decisions, and keep projects moving without sacrificing environmental protections.

I had a chance to spend a year with the Council on Environmental Quality (CEQ) to better understand the technology landscape and bureaucratic hurdles that cause so many of the delays on our large infrastructure projects in the United States.

This explainer video from the WSJ details the SunZia wind farm project, a $11B renewable energy initiative that will deliver 3.5 GW of wind power from New Mexico to Arizona and California via a 550-mile transmission line. Set to finish in 2026, it will power 3 million homes and boost clean energy access across the western U.S.

I love this problem space because it combines emerging technologies such as drones, sensors, AI, and satellite imagery with decades-old problems of federal, state, and local government collaboration (think case management and document sharing).

If you want to go deeper, check out “Abundance” by Ezra Klein and Derek Thompson, and “Why Nothing Works” by Mark J. Dunkelman. These books cite numerous examples of infrastructure projects that take forever or fail, and will help you understand how we have reached this moment in the United States.

Keep reading:

What is NEPA? NEPA stands for the National Environmental Policy Act, a U.S. environmental law enacted in 1970. It mandates that federal agencies assess the environmental impact of their actions and decisions before making them.

The “Permitting Dashboard” displays a list of large infrastructure projects in the United States.

Arrow Canyon Solar Project – an example of a public comment form.

AI in all levels of Government

OpenAI generated image of government IT workers in future setting

There are 3,144 counties and 55 states and territories in the United States, encompassing 19,500 incorporated cities, towns, and villages. Of those, 14,768 have populations below 5,000. Only ten have populations above one million, and none are above 10 million. 310 cities are considered at least medium cities with populations of 100,000 or more.

127 million people, about 40% of the U.S. population, lived in cities with 50,000 or more residents.

There are 574 federally recognized tribal governments and 326 Indian reservations in the United States, and Native Americans have a population of approximately 10M or 2.9% of the total U.S. population.

In addition to state and local governments (SLED), there are 438 federal agencies and subagencies.

We all want the same outcomes: a thriving and safe community, the happiness of our neighbors, and responsible, competent management from our government.

By applying AI to certain problems, governments can lower costs through automation, provide more valuable information to residents, reduce fraud, enhance public safety, and so much more.

To do this, governments must procure off-the-shelf solutions or build custom software. These teams will comprise AI ethicists, policy wonks, product managers, user experience designers, and software engineers.

To understand how federal agencies think about AI, you can dig deeper into this inventory of thousands of use cases aggregated from most agencies.

Federal AI Use Case Inventory

Legislation + Product Management

It’s been five years since I first scrubbed in and started working on government problems. One of my early impactful experiences after moving to DC for a year in 2017 was taking a walk next to the White House with my friend Natalie and talking about the 21st Century Cures Act. In that huge piece of legislation, the words “Application Programming Interfaces (APIs)” are referenced a handful of times, a very important signal for government agencies and the healthcare industry to progress into a more interoperable existence. At that time, I didn’t have a clue about policy-making, the legislative process or regulation but soon came to understand the intersection of policy and product management is a fascinating place to work for a product manager and a core product muscle to develop.

In this space where policy and product meet, a product manager can find themselves helping write policy, implement policy or being subject to policy.

Examples:

  • Writing policy – helping advise policymakers at a Federal agency, Congress or State Legislature on specific technical things or approaches. Ex: CMS Interoperability and Patient Access Rule
  • Implementing policy – building software, websites and new teams to help a government agency implement some new legislation or regulation. Ex: Medicaid member experience, Paid Family and Medical Leave, Unemployment Insurance, the Bipartisan Infrastructure Bill, etc.
  • Subject to policy – designing new product features for your business based on opportunities or requirements policy creates. Health data interoperability, privacy, crypto regulation, grant funding opportunities, etc.

For this post, let’s focus on Implementing policy.

How a Product Manager should think about Implementing Policy

Today, big pieces are legislation are treated as requirements documents in which different requirements are usually delegated out to various government agencies to implement. For example, in the recently enacted Infrastructure Investment and Jobs Act (IIJA), there are approximately 14 agencies responsible for 375 programs that will carry out provisions of the bill.

But…before going into implementing legislation as a product manager, a quick primer on the structure of legislation like the Infrastructure Investment and Jobs Act (IIJA).

The Structure of Legislation

The legislation is called an “Act”. Within the Act, there are divisions, titles and subtitles that have many sections.

Each of these sections can have highly prescriptive or super vague direction. For example, on page 1182 of the Infrastructure Investment and Jobs Act (IIJA) you’ll find a specific definition of “reliable broadband service”.

Often times, legislation is prescriptive as to how it should be implemented once passed. For example, the Colorado Paid Family and Medical Leave Insurance Act defines a new division be created within the Colorado Department of Labor and Employment to run the new program. 

For the Infrastructure Investment and Jobs Act (IIJA), an Executive Order immediately followed the passage of the bill which established a Task Force.

The process sometimes feels more like art than science and can vary widely across levels of government and the type of policy being created. For example, in both Federal and state governments, the legislature (Congress) makes laws but federal and state agencies can create regulation. To further codify how a piece of legislation should be implemented, the Office of Management and Budget (OMB) may issue guidance to agencies that have “statutory responsibilities”. As you can see from this IIJA guidance from OMB, it further defines how everyone should coordinate with each other across government.

Products created by Legislation

Ok, now that you have a sense of the structure of a big piece of legislation, let’s talk about the products the signing of a new bill or publishing of a new regulation may hatch.

Imagine you are a product manager in the government tapped to work on implementing a new policy. Not unlike most products you’ve likely worked on, there is some type of vision or high-level goals (probably spelled out in the legislative text) and will likely need a website, community building, customer success and internal dashboards.

Website(s)

A piece of legislation and accompanying guidance will likely have a lifespan of a decade or longer. During these many years, state and local governments, territories, Tribal nations, non-profits, businesses, media and others will be learning about the bill. It is important to establish a source of truth for ongoing communication about the bill as the legislative text, once passed, is static on congress.gov.

For example, for Infrastructure Investment and Jobs Act (IIJA), the website Build.gov was created to provide a home for information about the programs that span infrastructure themes such as broadband, water and transportation. A PDF guidebook was also created that summarizes each of the programs. This website is just one web property in an ecosystem that includes:

  • Build.gov – summarizes the Infrastructure Investment and Jobs Act (IIJA), PDF guidebook, searchable program inventory.
  • Grants.gov – the application process for many of the grant programs funded by IIJA.
  • Agency Program webpages – program specific information including application eligibility, notice of funding opportunities (NOFOs) and technical assistance. Ex: Bus and Bus Facilities Program from the Federal Transit Administration (FTA).
  • Sam.gov – detailed information about each program (call an “assistance listing” in grant-speak).

Along with websites, as a PM you’ll be engaging with secondary sources of information, typically local and national media coverage as well as webinars, infographics and white papers put out by hundreds of associations and consulting or lobbying firms.

OKRs and Dashboards

A variety of data products such as dashboards, shared datasets and more are required to coordinate across agencies and manage a large piece of legislation effectively.

Usually, in artifacts that support the legislation or in the bill text itself, you’ll find some type of guidance or direction about how outcomes and impact should be measured. For example, in the IIJA Executive Order, priorities were defined. This means there also needs to be a way to measure and report on these priorities…which means data and dashboards.

Beyond using data to inform decision-making of the policy implementation, oversight needs to be considered from day one.  Reports to Congress and readouts with stakeholders are important for PMs to consider.

(Map showing bipartisan infrastructure bill funding)

Web apps

For legislation that directs funding, usually to state, local, territorial and Tribal governments or non-profits, some type of reporting from those entities back to the Federal government is required, which means you’re likely building a web app. As conditions change, these reporting and compliance requirements also evolve. As a PM, you need to be thinking about a reporting and compliance user experience that is easy for funding recipients. As I’ve talked with folks in all levels of government about grant funding specifically, reporting and compliance burden is always a complaint, especially for small governments without big teams to handle this.

Web apps to support legislation are tricky because many of them have been built in the past to support a variety of different types of legislation and the user experiences have been less than great. So, as a PM, you need to embrace the learnings from these teams and try and avoid building the next web app that most users don’t really like.

Another category of web apps you may find yourself building as a PM helping to launch new legislation are web apps that support some type of functionality required by the policy. In this example, the Quality Payments Program from the Centers for Medicare and Medicaid Services (CMS) supports regulation that requires healthcare providers to upload information via a website or integrate with an API.

Delivery Teams

New policy usually means new delivery teams are needed to build the websites, dashboards and web apps to support the policy. Depending on which government agency or agencies are tasked with implementing legislation, they may not have an operating budget to procure a software delivery team, purchase cloud infrastructure, run sophisticated digital marketing campaigns, and so on. For example, the White House and State Governor’s Offices are examples of structures that don’t have a ton of capacity to ship software versus Federal or state agencies who have a huge portfolio of software products, existing devops processes and cloud infrastructure, cyber security policies, etc etc. In most cases, having the delivery live within an agency of a shared services group like the Office of Information Technology is the preferred path.

As you get started as a PM on a new policy, regulation or legislation, work hard to get clarity on how the delivery teams will be structured. This will be hard as there’s a lot at stake and a ton of pressure to move fast.

Conclusion

Over these five years in government, one of the things that caused me to fall in love with this work is the sheer reach of it all. New legislation, policy or regulation has the potential to change an industry or impact millions of people.

This is also a space where I’ve seen firsthand the impact of “software is eating government” (a remix of the phrase coined by Marc Andreessen, the founder of Netscape). Software has begun to permeate every aspect of our lives and is fundamentally changing business models. We cannot afford to ignore technology as we deliver government services, this includes upstream in the policy-making process.

It’s a really good sign if you, the product manager, are part of the team tasked with implementing a new policy. When done right, your expertise in user experience, software development and product design combined with the brilliance and experience of the policy wonks and government experts has the potential to delivery something truly special.

Wrap Up: My “digital tour of service” with the State of Colorado

Every morning I wake up to the local NPR station (KUNC) playing on my Alexa, grab a cup of coffee, lay back down and listen. It’s a preview of the weeks ahead. Working in state government puts you at the intersection of federal policy and local service delivery. Sometimes things state government builds directly impacts people, and sometimes it enables those in county and local government to serve residents and citizens in a better way.

The Colorado Digital Service (CDS), a team I co-founded with Matthew McAllister, is two years old now and I am wrapping up my “digital tour of service.” CDS is a diverse, cross-functional team of senior engineers, human-centered design specialists, product managers and procurement specialists within the Governor’s Office of Information Technology (OIT). We partner with state agencies to develop and improve human-centered solutions to Colorado’s most pressing technical challenges (and we are hiring).

Over the past two years, I’ve been incredibly proud of the work we’ve done on the COVID-19 response, with the child welfare team, and the new Paid Family and Medical Leave division. I can’t wait to see what the team delivers next.

A few lessons learned

A digital service can be an important tool for governments.

The original vision for the Colorado Digital Service was to create a small team of senior product managers, designers and engineers that would work on the Governor’s priorities and plug-in tightly with the Office of Information Technology. This has mostly played out as expected.

Why is a digital service important for your state government?
1. A digital service creates momentum for new ideas on hiring, software delivery and problem solving that can be leveraged government-wide. Publishing the Modern Software Delivery Index, creating an agile vendor pool and finding new ways to connect Colorado tech talent to government are examples of ways the Colorado Digital Service has done this here in Colorado.

2. For agency initiatives that are emerging, a digital service can be leveraged to prototype, build, ship and continuously improve upon these initiatives until the sunset or transfer into an agency program. Bug Bounty, Digital Vaccine Credentials, Exposure Notifications and Developer Evangelism are examples from the Colorado Digital Service just this year.

3. When brand new agency programs or offices are created, a digital service can help with human-centered design, rapid prototyping, product management and vendor procurements in the early stages of formation. In Colorado, we have seen a new Paid Family and Medical Leave program, Office of Early Childhood Education, and Office of Behavioral Health launch just this year.

A lot of progress has been made to improve the delivery of government services, but we still have work to do.

One of the big takeaways from the past few years in government is that some decades old rules combined with perverse incentives hamper government’s ability to deliver. Everyone wants to make government work better for the people, from tech talent who are curious about working in government, to the career civil servants that have been chipping away at problems for years.

Here are a few things that are gradually improving but need to be better.

Hiring – In Colorado, we can’t hire anyone that lives outside of Colorado, we have outdated position classifications and our product, design and engineering salaries continue to be non-competitive with the private sector.  We continue to attract great talent despite these constraints thanks to the tireless work from Colorado’s HR folks and agency directors that find creative ways to staff teams. Refactoring hiring is happening but more needs to be done such as improving how funding is allocated to these positions and competing on salary (read Tips for Finding Ways into Public Sector Work).

Delivery teams – Funding for enterprise applications can be sporadic based on a change in legislative priorities, economic climate or specifics of policy which makes it hard for government teams to hire full-time employees so outsourcing to contractors and vendors is the norm. This perpetuates a “project” instead of “product” mentality of “When will it be done?” and “We have to spend the money now.” In government, many of the technology applications that serve programs like Medicaid, child welfare and public safety are never “done”. Delivery teams need full-time government employees that can focus on delivery with a consistent funding stream over time in partnership with vendors.

Procurement – Governments can have hundreds of enterprise applications and initiatives. How government teams decide to work with contractors and vendors is a huge factor in their success. Although there has been a powerful movement in procurement reform across governments at all levels, moving to a modular, agile way of working is still new in government (watch Waldo’s talk on this). When an program team insists on developing a massive list of requirements to be delivered by a certain date for a certain price and then adds additional constraints such as a vendor having to take on substantial liability for the “system as a whole” or having a certain number of employees onsite, they think they are doing the right thing by “guaranteeing success” and reducing risk. Time after time this approach has been shown to fail (read Government tech projects fail by default. It doesn’t have to be this way).

What’s coming next for government teams is pretty easy to envision

The delivery of digital services across the government is maturing. In some Federal and State Agencies as well as local governments, you will see teams working in an agile way, using human-centered design to better understand the problems they are solving and shipping software that works on mobile devices.

Looking ahead, here are a few things that are either a growing part of a government’s portfolio or coming soon.

APIs – Interoperability between agencies, counties and community partners, open data and giving residents/citizens/patients access to their personal data is a growing piece of the puzzle for government service delivery.  We are already seeing states subject to regulation by the Federal government to provide Medicaid patients access to their health information and more of this type of regulation will come. There is also a strong demand from the private sector to access open data sets and have ways to transact with governments.

Layers of Government – For programs that span multiple agencies (CDC and CMS for example) or multiple levels of government (Federal to State to Local), a digital service can help break down silos and glue efforts together. There is already collaboration between states happening formally in monthly working groups and informally across networks of peers. Governments at all levels should be working as a portfolio in many of the large enterprise applications like unemployment insurance, Medicaid and paid family and medical leave sharing open source projects and reusing composable building blocks instead of paying the same vendors to duplicate software applications over and over for each state.

Machine Learning – Fraud detection, robotic process automation, public health outbreak prediction and so much more is coming to the government. Understanding how to manage ML pipelines, train models, and incorporate all of the ethical considerations that this technology will raise for a government into the product management process will be critical. Digital service experts that have experience training and deploying models or designing product features that leverage these models will be important. [read Digital Services to APIs to ML]

Onward!

After 20 years building software in bootstrapped small businesses, venture-backed startups and large enterprises, I feel incredibly lucky to have stumbled into government and fallen in love with the work. My work-life has never had more purpose that it does now and I’m excited to continue chipping away at these problems.

Thanks to my Colorado Digital Service teammates, Governor Polis and his team, and all of my colleagues in the Office of Information Technology and within the agencies for helping the Colorado Digital Service get off the ground and become an important part of service delivery to Coloradans. I am grateful to you for giving this idea a chance.As for me, I’m boomeranging back to the US Digital Service to serve another digital tour of service taking my learnings and inspiration from Colorado to the Federal government.

Medicaid Blue Button API Use Cases

This post is simply a list of use cases that helps all of us understand why the Medicaid Blue Button API is super important to Medicaid members.

Btw – here is the list of apps that are built using the CMS Medicare Blue Button API and another list of apps that have agreed to the CARIN code of conduct.

Providers

Claims data is one component of a patient’s complete, longitudinal digital health record adding cost, coverage and adherence.

These are ways in which Medicaid members having access to their claims information or sharing this data with their Provider can have an impact.

  • Providers can share data with each other given a patients consent
  • Patients can download their claims data into a personal health record like Apple Health and show information to their provider during the visit
  • Patients receive Infrequent procedure reminders (ex: annual exam, colonoscopy every 5 years, etc)
  • Easy way for family member/caregiver to access medical information in emergency (important for authorization access not to time out too quickly). Apple is also working on this (emerging).
  • Improving care coordination by sharing information with all members of a Medicaid member’s care team
  • Decreases printing of records a provider needs to do
  • An at-risk provider having difficulty accessing a patient’s longitudinal claims record (like we heard re: the Oncology Care Model – which shares such data up to six months after the initial trigger event) could gain more timely access to this data via Medicaid member granting permission.
  • Comparing & reconciling patient-level payor EOBs vs provider bills
  • Automatic pre-population of initial visit forms (save time, increase accuracy)

Example: Did Jane have a Cervical Cancer screening at her last OB/GYN visit?

  • Jane, a 55 yr old female Medicaid member visits her PCP. She is handed an iPad to checkin and sees “Login to your Medicaid account to share data with Dr. Smith.”
  • She logs with her Medicaid username and password
  • She sees a spinning wheel and reads “Your Medicaid claims data has been downloaded and is up-to-date!”
  • Her claims data from Medicaid is synced to Dr. Smith’s EMR
  • Dr. Smith pulls up her chart during the visit and sees that she’s had the recommended Cervical Cancer screening
  • The Provider is complying with this screening CMS quality measure

Research

From Apple’s Research Kit to Verily’s Project Baseline, making it easy for a patient to contribute health data to a clinical trial or research study is powerful.

  • A Contract Research Organization (CRO) can incorporate Medicaid claims data to improve the accuracy of monitoring during a Clinical Trial.
  • Apps like Verily’s Project Baseline enable participants to connect a variety of personal health data sources to better inform the researchers.
  • Clinical Trial enrollment – A research organization can pre-populate a medication list for a patient during clinical trial enrollment.
  • Donate data to research (ex: precision medicine, “All of Us” research cohort/Sync for Science, Health eHeart Study (UCSF)

Prescriptions

  • Medication adherence
  • Navigating affordable care options (eg brand vs generic medication)

Example: Signup for home delivery of medication 

XYZ Pharma is a full-service pharmacy that sorts your medication by the dose and delivers it to your door.  They would use Medicaid claims history to reduce the Patient’s burden during the signup process, to better understand their prior billing cadence and to build a better profile of their medication history.

Health and Fitness

Example: Personal Health Record

A 59 year old woman from Cleveland, OH named Bettie has an iPhone 8 and a Fitbit her son bought her for Christmas.  Her friend told her about an iPhone app that lets her see all of her medical records on her phone called “MedView”.  She searches for it in the app store and downloads it.  Her favorite apps on the iPhone are Weather.com and Facebook.  She opens the app and it asks her to login with her Medicaid account.  She enters her username and password and sees a “welcome message” display on the app.  Success!  The app shows her some personally identifiable information and tells her it’s downloading her entire record from Medicaid.  She sees a status bar going to 100%.  A few seconds later she sees a timeline view of her information.

Financial

  • Forecasting & planning a personal health care budget (based on previous year information)
  • Connect your Medicaid data to health insurance shopping app or an accounting app like Quicken for tax deductions.

Brainstorming list

Below is a list of terms and concepts to trigger more ideas about how patient access to claims data can help make an impact on people’s lives and health.

  • Folks moving from Medicaid to Medicare or from private health insurance on to Medicaid or vice-versa 
  • eLTSS examples
  • Home Health Care
  • Assisted Living
  • Primary Care
  • Senior Social Networks
  • Wearables
  • Transportation
  • Patient Portals
  • Chronic Disease Management
  • Social Isolation
  • Preventative Care
  • Medication Adherence
  • Digital Therapeutics 
  • EHR interoperability
  • Longitudinal Patient record
  • Patient education
  • Preference-sensitive care
  • Medication reconciliation & adherence tools
  • Care team indexing & name/ID sharing with other providers
  • Evidence-based clinical decision support
  • Quality-related application & services for Accountable Care Organizations (ACOs)
  • Chronic disease management (including personal health tracking – eg for patients with diabetes)

Good Articles

Use of the Blue Button Online Tool for Sharing Health Information: Qualitative Interviews With Patients and Providers (PubMed 2015)

New iPhone Health app feature gives doctors easier access to data (The Verge, June 2021)

Digital Services to APIs to ML

Hanging out with Brandon Williams and Lilo Santos on the Public Sector Community’s Coffee

#CivicTech is having a moment. As government gets better at delivering digital services to residents, they face challenges ahead from building APIs to wrestling with machine learning.

Digital Services

The delivery of digital services across government is maturing.  In some Federal and State Agencies as well as local governments, you will see teams working in an agile way, using human-centered design to better understand the problems they are solving and shipping software that works fine on mobile devices. Organizations like 18F, United States Digital Service, Code for America and many more are driving the conversion on building good government using technology. There is still much work to be done for government to evolve into high-performing software delivery teams and to use agile budgeting to better align team funding with how teams want to work, strengthening product management across all layers of government, modernizing legacy systems and so much more.

Open Data and APIs

We have also seen the rise of open data published by cities, counties, and state and federal agencies. This drives innovation and transparency, keys to good government.  Open datasets are typically aggregated data that do not include personal information.

Next, we will see governments making APIs available so residents, citizens, patients, taxpayers, etc can have an option to easy share the information their government holds with the apps, services, businesses and other government agencies they choose.

For example, a Medicaid patient can share their insurance claims history with a home-delivery prescription drug service or a parent can share their children’s immunization history with a summer camp that requires this information to register a child.

Offering these types of APIs will be a big challenge for most governments as they have never built information services that software developers are consuming to then provide a service to the constituent. With open data, governments mostly took a “build it and they will come” approach in which they simply made the data available and let the market figure out what to do with it. However, when building APIs on top of protected, personal information, governments will need to play an important role in helping developers successful adopt the APIs.

With API delivery, value is only realized when the developer is able to leverage the API to deliver something meaningful to the constituent.

In parallel with delivering APIs for 3rd party software developers to consume, governments will also get more sophisticated on how to exchange data within government itself. Should a State Medicaid agency be able to exchange personal health information about a patient with the State Human Services agency that offers mental health benefits that patient could leverage? Where do you draw the line and when must the constituent give their consent? These are big challenges and need people working for government that understand both the technology and business of APIs as well as policy related to data sharing.

Machine Learning

Fraud detection, robotic process automation, public health outbreak prediction and so much more is coming to government. Understanding how to manage ML pipelines, train models, and incorporate all of the ethical considerations that this technology will raise for a government into the product management process will be critical.

Books like Automating Inequality: How High-Tech Tools Profile, Police, and Punish the Poor by Virginia Eubanks demonstrates how bias is introduced into systems and is super relevant for government leaders working on or thinking about building prediction or filtering systems.

Whereas vendors can offer off-the-shelf solutions like chatbots that introduce some AI into government systems without the government agency teams needing any understanding of the underlying technology, the government teams building enterprise applications will need ML engineers and experienced product managers. Government will once again need to compete with the incredible demand for this type of technologist as well as the high salaries their skills command.

If government teams still struggle with web apps, mobile experiences and stability of systems, how will they possible handle the sophistication of ML pipelines?

In government, the ROI is social impact. Residents leveraging easy-to-use digital services to pay their taxes, register a car or access a benefit helps them focus on what matters, their daily life. APIs and machine learning enable these digital services to get that much better.

We are living in an era where trust in government is low and the demand for competency and transparency in government is high. As government continues to deliver for the people, this trust improves over the long-run. We must keep working, all of us.

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!