CDC Enterprise Data Exchange

When I joined DEX, significant foundational work had already been completed. Product teams had established a vision for modernizing public health data exchange, and multiple capabilities were already underway.

DEX was not one product. It included DEX Portal, Upload API, HL7v2 Services, FHIR Services, processing observability, routing, metadata management, onboarding experiences, support, permissions, and self-service interactions. Programs submitted data through ingestion services. Data moved through routing and validation capabilities. Metadata governed how information flowed downstream. Portal experiences provided operational visibility. Internal teams managed onboarding, support, permissions, and ongoing service delivery. Viewed independently, each capability made sense. Viewed together, they formed a service ecosystem that was still difficult for teams to see clearly.

My work focused on helping teams create visibility into those relationships. Through ecosystem mapping, stakeholder modeling, systems diagrams, and collaborative workshops, I helped connect previously separate product visions and operational concepts into a shared view of the DEX ecosystem.

Understanding the DEX ecosystem created visibility, but visibility alone was not enough. As the service matured, new questions emerged: How do programs enter the service? How is onboarding supported? How does the service continue functioning after launch?

The answers rarely existed within a single product. They existed in the operational systems surrounding it. Onboarding became one of the clearest examples. What initially appeared to be a straightforward implementation activity revealed itself as a service experience involving program readiness, technical requirements, metadata, access, support, ownership, and continuous coordination. Service blueprinting helped make that operational work visible. By mapping frontstage experiences, backstage processes, supporting systems, ownership models, and dependencies, teams could see how onboarding requests moved through the organization, where support needs emerged, and where operational friction accumulated.

Metadata management introduced another layer of operational structure. Organizations, programs, data streams, routing destinations, permissions, and users all needed to be represented consistently for onboarding, routing, governance, and operational visibility to scale.

As DEX approached broader adoption, operational readiness raised a new question: how would the service continue learning after launch?

Supporting a service required more than products, processes, and documentation. It required structures that enabled continuous alignment, feedback, planning, and stewardship across the ecosystem. The DEX Community of Practice became one of those structures. It created a recurring forum for sharing onboarding findings, product updates, service blueprints, research insights, roadmap discussions, and operational considerations across teams.

Feedback also became part of the service architecture. Usability findings, onboarding observations, support interactions, and operational realities informed portal capabilities, support processes, documentation needs, and future roadmap decisions. Measurement and planning structures helped teams define what good looked like. Success expanded beyond delivery milestones into adoption, readiness, service maturity, operational effectiveness, and long-term service health.

The service design challenges emerging from DEX began appearing across other OCIO initiatives: onboarding, governance, service ownership, stakeholder alignment, operational visibility, and service improvement.

A federal sponsor recognized the need for a more consistent way to understand and improve services across the organization. In support of that ambition, and in partnership with a UX research lead, I helped develop the service design structures, methods, and artifacts that became the foundation for a shared framework across OCIO. Instead of starting with individual projects, the work focused on creating common language, shared methods, and repeatable structures. Teams needed a way to describe services, ecosystems, capabilities, customer journeys, blueprints, governance structures, and operational relationships consistently.

The goal was not to prescribe a single methodology. It was to create enough structure that teams could analyze and discuss services consistently while adapting methods to each initiative.

Applying the framework required moving from theory into active service environments. These environments involved multiple stakeholders, competing priorities, operational dependencies, governance checkpoints, and evolving customer needs. Cloud modernization revealed how complex these service experiences could become. Customers navigated consultations, architecture reviews, governance checkpoints, onboarding activities, funding discussions, implementation support, and ongoing operational engagement. Service blueprinting helped show how those touchpoints connected across teams and operational domains.

Across OCIO initiatives, ecosystem mapping revealed that customers rarely experienced services in isolation. They moved between consultations, governance processes, shared platforms, onboarding pathways, support models, and operational teams. The focus shifted from improving individual touchpoints toward improving the relationships between services.

Workshops, executive briefings, and action planning activities helped turn service understanding into decision support. Rather than delivering static artifacts, the work focused on helping stakeholders identify where friction existed, where dependencies mattered, where governance was required, and where services should evolve.