Building AI Solutions to Transform Health Care

Most executive education programs teach leaders how to understand, govern, evaluate, or implement AI. This program teaches participants how to build with it. 

Participants do not leave with an idea or presentation alone. They apply a structured AI-native product-development process to define a real problem, test the opportunity, specify the product, build and evaluate an early solution, and plan the pathway toward pilot and scale. 

This is not a survey course and not a traditional coding bootcamp. Participants are not expected to become software engineers in four days. Instead, they develop the practical and technical literacy required to: 

• Build early products with AI-assisted tools 

• Direct coding agents and technical collaborators 

• Evaluate what an AI system has produced 

• Recognize the limitations of rapid prototypes 

• Make informed decisions about product scope, safety, evidence, implementation, and investment 

• Lead a multidisciplinary team from problem definition toward a working solution 

The course is problem-first rather than technology-first. Participants learn not only how to build something quickly, but how to determine whether they are building the right thing

Participants use the Harvard-developed Healthcare AI Studio, an open-access structured environment for AI-enabled product development. 

The Studio supports work across: 

• Problem definition 

• Health-system and stakeholder analysis 

• Product strategy 

• User and workflow definition 

• Product requirements 

• Architecture and design 

• Safety and policy review 

• Implementation planning 

• Structured documentation 

Rather than relying on ad hoc prompting, participants follow a disciplined and repeatable workflow. The Studio helps them turn an initial idea into a product design pack that can be reviewed, refined, and used by coding agents and technical teams. 

The Healthcare AI Studio is complemented by current AI-assisted development environments. The Studio provides the structured product-development method; coding agents and development tools are used to build and test the resulting solution. 

The objective is not only to produce one prototype during the program. It is to give participants a method they can reuse for future initiatives. 

By the end of the program, participants will be able to: 

• Identify and prioritize high-value health care problems that may be suited to AI-enabled intervention 
• Translate complex workflow and service problems into clear product opportunities 
• Distinguish an attractive AI demonstration from a viable product concept 
• Map the users, beneficiaries, buyers, operators, approvers, and risk owners associated with a proposed solution 
• Align value propositions across relevant health care stakeholders 
• Use structured agentic methods to challenge assumptions across clinical, operational, technical, safety, policy, and implementation dimensions 
• Develop a Product Requirements Document covering users, workflows, functions, success metrics, acceptance criteria, risks, and non-goals 
• Develop an initial architecture and design specification 
• Use AI-assisted development environments and coding agents to build and test an early product 
• Organize development work using a central source of truth and structured project-management process 
• Evaluate implementation readiness, governance requirements, evidence needs, and pilot design considerations 
• Communicate the problem, product, evidence requirements, and next-step plan through a concise, decision-ready presentation 

This program is designed for leaders with foundational AI fluency who are responsible for innovation, digital transformation, product development, clinical operations, venture creation, organizational strategy, or public-sector modernization. 

It is especially relevant for: 

• Chief innovation, digital, information, medical, and strategy leaders 
• Clinical and operational leaders redesigning health care workflows 
• Product leaders developing AI-enabled health care products or services 
• Founders and venture builders 
• Health-system transformation teams 
• Payer and benefits leaders 
• Life sciences leaders 
• Public health and government leaders 
• Technology leaders working with health care organizations 
• Investors and innovation leaders who need to evaluate whether products are technically and operationally credible 

Participants may enroll individually or alongside colleagues. During Week 2, all participants join one of the three selected project teams. 

The program is not intended as an advanced software-engineering course, a machine-learning model-development course, or a substitute for clinical, regulatory, security, or engineering review. 

Why AI, Why Now, and How to Start Building

Week 1 introduces the health-system opportunity, explains how generative and agentic AI are changing software development, and moves participants from rapid one-shot prototyping toward a more structured development process. 

9:00–10:00 am — Faculty Lecture: AI for Health Systems Impact (Faculty: Rifat Atun)

This session sets the health-system context for the course. It examines the major challenges facing health systems and where AI-enabled redesign may create meaningful value.

Topics include:

• The current performance challenges facing health systems
• Provider, payer, government, life sciences, patient, and platform perspectives
• Why generative and agentic AI change what health care organizations can build
• The difference between adding an AI feature and redesigning a process
• How to identify health-system problems that are appropriate for AI-enabled intervention
• The leadership required to move from strategic interest to practical action

10:00–10:30 am — Live Discussion and Q&A

10:30-11:00am — Break

11:00am-12:00pm — Guided Lab: How Agentic AI Is Changing Software Development (Faculty: Trishan Panch) 

This large-group demonstration introduces AI-assisted software development and explains why current tools change who can participate in building software. 

The lab covers: 

• The difference between generative AI and agentic AI 
• What an AI agent is 
• What a coding agent does 
• How agents use instructions, context, tools, memory, and feedback 
• What natural-language software development means in practice 
• What non-engineers and small multidisciplinary teams can now prototype 
• The difference between one-shot generation and a structured development process 
• Why AI-generated software still requires human judgment, testing, safety review, and technical oversight 
• How to evaluate whether an impressive-looking prototype actually works 

Faculty will demonstrate how a basic health care problem can be translated into an initial software concept using a current browser-based AI development tool. 

12:00-12:30pm — Guided Lab Debrief and Office Hours 

Participants can ask practical questions about: 

• The tools demonstrated 
• AI and software-development terminology 
• The limits of coding agents 
• Prompt and instruction design 
• Common reasons prototypes fail 
• What participants will need for the build studios 

12:30–1:30 pm — Small-Group Build Studio: From a Health Care Problem to a First Prototype (Faculty: Heather Mattie, Gianluca Mauro, and Trishan Panch)

Participants work in small groups to turn a simple health care workflow problem into an initial AI-generated prototype. 

The studio covers: 

• Selecting and narrowing a simple, non-confidential health care problem 
• Defining the intended user 
• Describing the current problem and desired outcome 
• Identifying the core user workflow 
• Creating a structured natural-language build instruction 
• Using a rapid one-shot approach—sometimes described as vibe coding—to generate a first prototype 
• Testing the main user journey 
• Revising the product through natural-language instructions 
• Identifying what is functional, what is simulated, and what remains incomplete 

• Understanding why an attractive prototype is not yet a reliable product 

1:30–2:00 pm — Faculty Feedback and Next Steps 

Selected groups demonstrate what they built. Faculty discuss: 

• Common strengths 
• Common mistakes 
• Unsupported assumptions 
• Missing functionality 
• Safety and workflow limitations 
• What would need to change before the idea could become a credible product 

Day 1 Outputs — Participants leave Day 1 with: 

• A defined user and problem 
• A simple workflow description 
• A structured build instruction 
• A first rapid prototype 
• Initial test results 
• A limitations and open-questions log 

End-of-Day Milestone 

The project idea submission form opens. 

Participants are invited to propose a health care problem or product opportunity for possible development during Week 2. assisted software development and explains why the current generation of tools represents a significant change in who can build digital products.

Topics include:

• The difference between generative AI and agentic AI
• What a coding agent is and how it works
• How AI agents use instructions, context, tools, and feedback
• What natural-language software development means in practice
• What non-engineers and small cross-functional teams can now prototype
• The difference between one-shot generation and a structured development workflow
• The continuing importance of human judgment, testing, safety, and technical review

Select the Right Problem and Move to Structured Agentic Development

Day 2 focuses on identifying a problem worth solving, aligning value across the relevant stakeholders, and moving from one-shot prototyping toward a disciplined agentic development workflow. 

9:00–10:00 am — Faculty Lecture: Developing Health Care Innovations and Aligning Stakeholder Value (Faculty: Rifat Atun)

This session examines how to identify a meaningful health-system problem and ensure that the proposed solution creates value for the people and organizations required to use, support, approve, fund, or regulate it. 

Topics include:

• Beginning with a health-system problem rather than a technology 
• Understanding the current workflow and service failure 
• Identifying users, beneficiaries, buyers, operators, approvers, and risk owners 
• Understanding how the problem affects different stakeholders 
• Aligning value across clinicians, patients, health systems, payers, governments, and other partners 
• Involving stakeholders in product definition and development 
• Assessing importance, feasibility, adoption potential, and system impact 
• Recognizing conflicting incentives and potential sources of resistance 
• Deciding whether an idea should proceed, be revised, or be rejected 

10:00–10:30 am — Live Discussion and Q&A

Participants discuss: 

• Who experiences the problem 
• Who benefits if it is solved 
• Who pays 
• Who must approve or operate the solution 
• Who carries the clinical, financial, regulatory, or reputational risk 
• Which assumption, if false, would invalidate the idea 

10:30-11:00am — Break

11:00 am–12:00 pm — Guided Lab: Extending AI Agents with Tools, Skills, and Trusted Knowledge (Faculty: Gianluca Mauro and Luke Piyyapilli)

This large-group demonstration explains how AI agents move beyond general conversation by using tools, defined skills, and external information sources.

The lab covers: 

• How AI agents perform multi-step tasks 
• How agents use defined tools 
• How agents can follow reusable instructions or skills 
• How external context can make an agent more useful and reliable 
• An accessible introduction to the Model Context Protocol, a standard way for agents to connect to tools and information 
• How an agent can retrieve and use research evidence 
• How structured access to trusted information differs from unconstrained prompting 
• A demonstration using the Consensus research platform 
• The implications for building more capable health care applications 
• The limitations and risks of connecting agents to external systems 

12:00–12:30 pm — Guided Lab Debrief and Office Hours

Participants can ask questions about: 

• Agent tools and skills 
• External knowledge sources 
• The Model Context Protocol 
• Evidence retrieval 
• Tool permissions 
• Reliability and trust 
• How these capabilities can be incorporated into a product 

12:30–1:30 pm — Small-Group Build Studio: From One-Shot Prototyping to a Structured Development Workflow (Faculty: Heather Mattie, Gianluca Mauro, and Trishan Panch)

Participants move beyond a single build prompt and learn the common elements of a structured AI-assisted software-development process. 

Faculty may demonstrate different development environments, but every group follows the same underlying principles. 

The studio covers: 

• Comparing different AI-assisted development approaches 
• Giving an agent persistent project context 
• Describing requirements and constraints more precisely 
• Asking the agent to propose a plan before modifying the product 
• Breaking larger requests into controlled, incremental changes 
• Reviewing what the agent has changed 
• Testing each change against a defined requirement 
• Maintaining a central source of truth for the project 
• Introducing version control and structured project management 
• Recording decisions, limitations, and incomplete work 
• Understanding why disciplined development is more reliable than repeated one-shot prompting 

1:30–2:00 pm — Faculty Feedback and Next Steps

Faculty compare the approaches used in the different groups and identify the shared practices that participants will use in Week 2. 

Day 2 Outputs — Participants leave Day 2 with: 

• A clearer understanding of structured agentic development 
• Experience directing an AI agent through multiple steps 
• A basic project source of truth 
• A revised product concept 
• A stronger understanding of stakeholder value and feasibility 
• A candidate project idea, where applicable 

End-of-Day Milestone 

The project idea submission form closes. 

Participants may propose a health care problem or product opportunity for collaborative development during Week 2. The submission form will ask participants to describe: 

• The health care problem 
• Why the problem matters 
• The people or organizations affected by it 
• The current workflow or service failure 
• The proposed user 
• Why AI may be appropriate 
• The value an early solution could create 
• Important operational, technical, data, policy, or safety constraints 
• What a useful prototype might demonstrate during the course 

Faculty will review the submissions and select three projects. Selection criteria include: 

• Importance of the underlying health care problem 
• Clarity of the intended user and workflow 
• Potential value across relevant stakeholders 
• Suitability for an AI-enabled intervention 
• Feasibility of producing a meaningful prototype during the course 
• Ability to work with synthetic and non-confidential information 
• Suitability for a multidisciplinary and international participant team 
• Diversity across health care settings and types of problems 

The selected projects will be presented at the beginning of Day 3. Participants will then join one of three project teams. 

Where possible, the selected project briefs should be shared with participants before Day 3 so that they can review the problem and indicate their preferred team. 

Week 2 focuses on user-centered product development, product requirements, architecture, structured agentic execution, testing, and the pathway from a working prototype to a real pilot. 

Design the Product and Begin the Build

9:00–10:00 am — Faculty Lecture: User-Centered Product Development in Health Care with AI (Faculty: Gianluca Mauro and Alice Lebeau)

The session begins with a short introduction to the three selected projects and the formation of the project teams. Faculty then introduce the principles of user-centered product development and examine how AI can accelerate—but not replace—sound product judgment. 

Topics include: 

• Beginning with the user, workflow, and intended outcome 
• Understanding user needs and current behavior 
• Distinguishing a product from a collection of features 
• Defining the core user journey 
• Identifying the minimum valuable product 
• Prioritizing essential functions 
• Establishing explicit non-goals 
• Avoiding uncontrolled scope expansion 
• Using feedback and testing to improve a product 
• How AI can support research, synthesis, specification, and iteration 
• Where human product judgment remains essential 

10:00–10:30 am — Live Discussion And Q&A

Participants discuss: 

• The primary user for each selected project 
• The most important user outcome 
• What the product must do 
• What the first version should not attempt to do 
• Which assumptions require testing 
• How to define a sufficiently narrow but useful MVP 

10:30-11:00am — Break

11:00 am–12:00 pm — Guided Lab: Developing a Product Requirements Document with AI (Faculty: Gianluca Mauro and Trishan Panch)

Faculty demonstrate how to use AI iteratively to produce a strong Product Requirements Document rather than accepting the first generated response. 

The lab covers: 

• The purpose of a Product Requirements Document 
• The core questions a PRD must answer 
• Defining the problem and product objective 
• Describing the primary user and user journey 
• Identifying functional requirements 
• Identifying non-functional requirements 
• Defining success measures and acceptance criteria 
• Recording assumptions, risks, dependencies, and exclusions 
• Asking AI to identify ambiguity and challenge unsupported requirements 
• Reviewing, correcting, and refining AI-generated content 
• Maintaining the PRD as a durable source of truth 
• Preparing the PRD for use by coding agents and technical collaborators 

Participants will see how the Healthcare AI Studio can support the iterative development and review of the product design pack. 

12:00–12:30 pm — Guided Lab Debrief and Office Hours

Participants can ask questions about: 

• Product scope 
• User journeys 
• Requirements 
• Acceptance criteria 
• Architecture 
• Using AI to challenge rather than merely generate a PRD 
• Moving from product specification to development 

12:30–1:30 pm — Small-Group Build Studio: From PRD to Architecture, Work Plan, and First Build (Faculty: Heather Mattie, Gianluca Mauro, and Trishan Panch)

Each of the three project teams develops its selected idea into a buildable product plan and begins implementation.

The studio covers:

• Developing and refining the team’s PRD 
• Creating an architecture and design document 
• Defining the product’s main components 
• Describing important data and control flows 
• Recording safety, privacy, security, and implementation constraints 
• Establishing a central source of truth 
• Breaking the product into manageable development tasks 
• Prioritizing the highest-value tasks 
• Organizing work using GitHub Projects, GitHub Issues, or an equivalent structured method 
• Assigning team roles 
• Starting the first product build using a coding agent 
• Reviewing and testing the first implementation steps 

Different teams may use different AI-assisted development environments. All teams will use the same underlying principles: explicit requirements, visible tasks, incremental development, human review, and testing. 

1:30–2:00 pm — Faculty Feedback and Next Steps

Each team reports: 

• The product problem and intended user 
• The agreed MVP scope 
• The structure of its PRD 
• The proposed architecture 
• The development plan 
• Initial progress 
• The main risk or blocker 

Faculty help the teams narrow their priorities for the final day. 

Day 3 Team Outputs — Each team should leave Day 3 with: 

• A Product Requirements Document 
• An architecture and design document 
• A defined source of truth 
• A prioritized development plan or backlog 
• Defined team roles 
• Initial working product components 
• Prototype v1 or an end-to-end first workflow 
• A list of unresolved issues and priorities for Day 4 

Complete the Prototype and Plan for Pilot and Scale

9:00–10:00 am — Faculty Lecture: From Prototype to Pilot and Scale
Faculty: Rifat Atun and Trishan Panch

This session explains what is required to move from a promising prototype toward safe implementation and sustainable use. 

Topics include: 

• The difference between a prototype, pilot, deployed product, and scaled service 
• Why success at one stage does not demonstrate readiness for the next 
• The evidence required at different stages 
• Technical, user, workflow, clinical, operational, and economic evaluation 
• Workflow integration and organizational adoption 
• Governance, privacy, security, safety, and accountability 
• Human oversight, escalation, and exception handling 
• Operating models and product ownership 
• The technical, product, implementation, and operational roles required 
• Funding, procurement, partnership, and commercialization pathways 
• Maintenance, monitoring, and continuous improvement 
• Conditions under which an organization should proceed, revise, pause, or stop 

10:00–10:30 am — Live Discussion and Q&A

Participants discuss: 

• What evidence would be required before a pilot 
• What would remain insufficient for wider deployment 
• Who should own and operate the product 
• What governance must be in place 
• What could cause a pilot to be stopped 
• What decision each team wants from its intended audience 

10:30-11:00am — Break

11:00 am–12:00 pm — Guided Lab: Planning the Build — Final Build and Demonstration Clinic

Technical faculty then demonstrate how to: 

• Freeze the product scope 
• Identify the single user journey that must work 
• Separate blocking defects from future enhancements 
• Test normal and failure scenarios 
• Document known limitations 
• Prioritize final development work 
• Prepare a stable product demonstration 
• Convert unresolved requirements into a next-step roadmap 

12:00–12:30 pm — Guided Lab Debrief and Office Hours

Teams can ask practical questions about: 

• Their prototype 
• Technical blockers 
• Testing 
• Infrastructure requirements 
• Product limitations 
• Pilot planning 
• Final demonstrations 

12:30–1:30 pm — Small-Group Build Studio: Final Build, Testing, and Demo Preparation
Faculty: Heather Mattie, Gianluca Mauro, and Trishan Panch

The three teams complete and prepare their products for presentation.

The studio covers:

• Continuing development of the core user workflow
• Testing the primary use case 
• Testing at least one failure or edge case 
• Correcting blocking defects
• Reviewing the product against the PRD 
• Documenting assumptions and limitations 
• Recording what remains simulated or incomplete 
• Preparing a short pilot or implementation roadmap 
• Identifying the evidence required for the next stage 
• Agreeing presentation roles 
• Using AI to create pitch materials  
• Rehearsing the live product demonstration 
• Defining the specific decision or support the team is requesting 

1:30–2:30 pm — Final Prototype Showcase, Faculty Feedback, and Recognition

Each of the three teams presents:

• The health care problem
• The intended user and value proposition
• The product design
• A live demonstration of the prototype
• Important limitations and risks
• What would be required to move toward a pilot
• The next decision or support required

Faculty provide structured feedback on: 

• Importance of the problem 
• Quality of the product definition 
• User and stakeholder value 
• Prototype coherence 
• Technical and operational credibility 
• Recognition of limitations and risks 
• Pilot readiness 
• Quality of the final decision request 

Faculty will identify a featured project. Subject to participant agreement, intellectual-property review, appropriate quality and safety review, and Harvard Chan communications approval, the featured project may be highlighted through Harvard Chan communications or social media. 

The program concludes by reflecting on what participants have built and how they can apply the same method to problems in their own organizations. 

Day 4 Team Outputs 

Each team should leave with: 

• A functional prototype or early MVP 
• A completed Product Requirements Document 
• An architecture and design document 
• A development backlog or next-step work plan 
• Test results 
• A limitations and risk summary 
• A pilot or implementation roadmap 
• A concise decision-ready presentation 
• A live product demonstration 

Current faculty, subject to change

The course is particularly well suited to digital products, workflows, and services where the user, current process, and intended value can be clearly defined. Examples include: 

• Clinician and administrative copilots 
• Documentation and information-synthesis tools 
• Care navigation and referral coordination 
• Operational workflow automation 
• Patient or member engagement 
• Research and evidence-synthesis tools 
• Population health and public health services 
• Payer or benefits-management workflows 
• Life sciences and medical-affairs processes 
• Internal knowledge and decision-support systems 

Projects involving direct diagnosis or treatment recommendations may require additional safeguards, specialist review, and evidence beyond what can be completed during the course. 

This course also contributes to the AI in Health Care Certificate of Specialization, among others. While each program can be taken independently, completing three healthcare AI courses in our portfolio earns the Certificate of Specialization.