Design Principles

This project operates using a set of design principles developed by the Surveillance Leadership Board's Platform Workgroup. These principles affect how we work with partners, collaborate amongst ourselves, and create useful shared services. While these are developed specifically for CDC projects they draw heavily from United Stated Digital Services Playbook and specifically the USDS TechFAR Handbook.

(without order)

Science drives IT, IT supports science - The scientific and public health needs of CDC programs should set the strategic direction for IT activities and capabilities. For each potential service, ask “does the service address programs data needs?”

Be selective in what is chosen for development, and do it well - Incrementally build small, modular services to demonstrate increasing value. Incremental pieces will work better together than apart. Keep roadmap and list of prioritized services in mind, while designing small units well.

User-centered - Users are engaged throughout the design, building, and use of services on the platform. Customer-services approach that exceeds user experience expectations. For each potential service, ask “Who are the users for this proposed service? How are they involved in service development? Will it meet their needs?”

Data can be integrated, if desired - Data and information used by platform services is able to be integrated (e.g., across programs, across systems, with supplemental data from additional sources). Services and clear documentation make integration easier.

Standards based - Design of platform and services should reuse standards when applicable and appropriate.

Interoperable - Services support interoperability (e.g., using open application programming interfaces (APIs) when applicable and appropriate to reduce barriers for reuse).

Collaborative, transparent, open development, and decision making - Consensus drives decision making with high communication and clear documentation for platform users and participants. Services meet cross-agency needs from at least two different public health programs. Documentation and engagement through all levels of platform.

Commitment to communicate with stakeholders - Part of open development is constant, clear communication for each user type (e.g., executive, program user, partner user, etc.). Stakeholders would need to be defined for each service or activity to ensure complete and effective communication.

Reuse, Buy, Build - Order of preference: (1) reuse a service that exists, (2) buy off the shelf software for a service, (3) build the service

Privacy & Security compliant - Security is integrated at all stages of design and development to protect privacy.

People choose to use (not forced to use) - “Opt in”-Marketplace of services that programs select the appropriate, useful services to connect to their surveillance programmatic work and improve their public health impact.

Tool optionality - Provide the tools and services that users need and request, rather than force users to adjust to a single tool.

Quality - Balance between scope, timeliness, and quality with emphasis on high quality to exceed user expectations.

Sustainability - Having the appropriate resources (financial, human, etc.) to maintain services built as well as to support additional services as they are needed.

Flexibility and scalability - Ability to customize and adjust functionality and performance to meet user expectation and respond to public health emergencies.

No loss of data (Lossless) - All data should be lossless in that complete records sent by one party should be available to the other appropriate parties. This means both having an accurate total count of records as well as having an accurate level of completeness with each record.