Assess a Healthcare AI Vendor

Assess a fictional healthcare AI vendor for PHI, model, and third-party risk.

Introduction

30 Second Summary

When a clinic considers software that listens during patient visits, a polished sales pitch can hide unanswered questions about patient information. A confident decision needs evidence that follows the data from collection to deletion.

In this project, you will assess a fictional AI dental note assistant that handles PHI before producing a draft for clinician review. Your sanitized approval decision will trace directly to the evidence.

What You'll Build

You will open your public GitHub case study to show a reviewer why the evidence supports your final Vendor A decision.

By the end of this project, you'll have:

A completed AI system inventory with a PHI data-flow map that traces visit audio from collection through deletion.
A transparent risk register that separates conventional vendor findings from AI trustworthiness risks. You can filter it across the four NIST AI RMF 1.0 functions to show how each risk is treated.
A sanitized decision memo with a public healthcare AI case study that explains your recommendation. The published files contain no real patient data or private links.
Secret Mission: Reassess Vendor A after a new fairness, privacy, and subcontractor evidence gap changes the risk picture.

Do I need any experience before starting?

An existing Google account, a GitHub account, and basic familiarity with GRC and HIPAA terminology are enough to begin. Everything happens in your browser.

Before We Start

Before the hands-on work begins, lock in the decision this assessment needs to support. You are evaluating a fictional dental clinical-note assistant to decide whether a clinic should approve it with conditions.

Set Up Your Assessment Workspace

A credible healthcare AI vendor assessment needs traceable working papers before any risks are scored.

A separate public location keeps private analysis out of your portfolio. It also keeps real PHI out of anything you publish.

Google Drive will hold your private workspace. GitHub will hold your sanitized case study.

In this step, get ready to:

Create the private assessment folder.
Add both working papers.
Create the public repository with its sanitized README.

Create your private assessment workspace

The Drive folder gives every working paper one traceable home. Google Sheets will hold the assessment workbook.

Google Docs will hold the decision memo. Both files stay empty until their assigned assessment steps.

Keep every file in this project free of real patient information.
Go to Google Drive in your browser.
Sign in to your Google account if prompted.
Click New in the top-left corner.
Select New folder.
Enter Healthcare AI Vendor Assessment in the folder-name field.
Click Create.

You should see Healthcare AI Vendor Assessment in Google Drive. This folder becomes the private home for your assessment evidence.

Open the Healthcare AI Vendor Assessment folder.
Click New.
Select Google Sheets.
Click the document title in the top-left corner.
Replace the current title with Vendor A Assessment Workbook.

The spreadsheet tab should now show Vendor A Assessment Workbook. The workbook is ready for the system inventory you create in the next step.

Why keep the working papers private?

A real vendor review can contain internal evidence. It can also contain unresolved risk decisions.

Keeping the full workbook private lets you publish only sanitized conclusions. That boundary makes the public case study safer to share.

Switch back to the Google Drive tab from earlier.
Click New.
Select Google Docs.
Click the document title in the top-left corner.
Replace the current title with Vendor A Decision Memo.
Switch back to the Google Drive tab from earlier.
Confirm the folder contains both working papers.

Your folder should show Vendor A Assessment Workbook plus Vendor A Decision Memo. Your private working-paper structure is ready.

Create the public repository

The repository is the public side of your workspace. It holds only the sanitized case study that another reviewer can inspect.

Publishing a repository can feel exposed. This one contains only fictional material that is safe to share.

Go to GitHub in your browser.
Sign in to your GitHub account if prompted.
Choose New repository from the GitHub home page.
Enter healthcare-ai-vendor-risk-assessment in the Repository name field.
Enter Fictional healthcare AI GRC vendor assessment in the Description field.
Select Public as the repository visibility.
Click Create repository.

You should land on the new healthcare-ai-vendor-risk-assessment repository. Its description should match the fictional assessment scope.

Can't create the repository?

Check whether a repository named healthcare-ai-vendor-risk-assessment already exists in your account.
Confirm that Public is selected before creating the repository.

Still stuck? Help me create the public GitHub repository for this fictional healthcare AI assessment.

Build the public README

GitHub renders README.md as the repository's front page. Its Markdown headings create a visible structure for the evidence you add later.

Choose Add file in the repository.
Select Create new file.
Enter README.md in the filename box.
Add # Healthcare AI Vendor Risk Assessment as the first line.
Place Fictional educational assessment. No real patient data is used. on the next line.
Add ## Project Purpose below the disclaimer.
Enter This case study evaluates a fictional dental clinical-note assistant for healthcare AI vendor risk. beneath the purpose heading.

The editor now contains the public framing for your assessment. The exact disclaimer makes the fictional-data boundary visible.

Add a ## Final Decision section with Pending assessment. as its placeholder.
Add a ## Top Risks section with Pending assessment. as its placeholder.
Add an ## Artifacts section with Pending assessment. as its placeholder.
Add a ## Sources section with Pending assessment. as its placeholder.
Click Preview.

You should see the project title above the fictional-data disclaimer. The four placeholder headings should appear below the purpose.

Why use visible placeholders?

The placeholders make unfinished analysis easy to spot. Each section becomes a clear destination for evidence from later steps.

GitHub may ask you to confirm the commit details before saving the file.

Click Commit changes....
Keep the default branch choice if GitHub asks where to commit the file.
Complete the confirmation dialog to save README.md.

README not showing?

Confirm that the filename is exactly README.md.
Check that you completed the commit confirmation after clicking Commit changes....
Return to the file editor if the disclaimer is missing from the preview.

Need help? Help me troubleshoot why my GitHub README is not appearing on the repository page.

✔️ My README is complete

Great. Your repository now has a purpose statement plus visible placeholders for the assessment evidence you add later.

ⓧ I'd like to double check

Compare your rendered README with this content checklist.

The title is Healthcare AI Vendor Risk Assessment.
The disclaimer reads Fictional educational assessment. No real patient data is used..
The Project Purpose section describes the fictional dental clinical-note assistant assessment.
The Final Decision section contains Pending assessment..
The Top Risks section contains Pending assessment..
The Artifacts section contains Pending assessment..
The Sources section contains Pending assessment..

Before you check the repository page, do you think the disclaimer will be visible without opening README.md?

Return to the repository's main page by selecting healthcare-ai-vendor-risk-assessment near the top of the page.

You should see Fictional educational assessment. No real patient data is used. in the rendered README. Your public case study now has a clear publication boundary.

Your workspace boundary is ready. Next, you'll map how Vendor A handles PHI.

Map the AI System and PHI Flow

Your workspace gives the assessment a traceable home. You still cannot assess Vendor A until you know its intended use, the people affected, the data involved, and every party that may handle it.

An AI system inventory defines those boundaries. A PHI data flow traces protected health information from collection through deletion.

In this step, get ready to:

Create the System Inventory tab.
Complete Vendor A's fictional system record.
Map each PHI handoff from collection through deletion.

Create the system inventory structure

A system inventory gives every reviewer the same description of the system under assessment. Its fields capture the business context before risk scoring begins.

Return to the Vendor A Assessment Workbook from the previous step.
Click Add sheet at the bottom of the workbook.

You'll see a blank sheet tab beside the existing tab.

Double-click the new sheet tab's name.
Type System Inventory into the selected tab name.

You'll see System Inventory on the tab at the bottom of the workbook.

Select cell A1.
Enter these headers across A1:L1 in this order: system, vendor, business purpose, intended users, affected people, human oversight, inputs, outputs, owner, deployment status, external dependencies, review date.

You should see twelve inventory fields spanning the first row.

Complete Vendor A's system record

This record defines Vendor A as a fictional dental clinical-note assistant. The clinician remains responsible for reviewing the generated draft before it enters the dental record.

What belongs in the record?

The system value is Fictional dental clinical-note assistant.
The vendor value is Vendor A.
The business purpose value is Generate a draft dental note from a patient visit.
The intended users value is Dental clinicians.
The affected people value is Dental patients.
The human oversight value is Clinician review required before record entry.
The inputs value is Visit audio and patient clinical context.
The outputs value is Draft dental note.
The owner value is Clinic clinical/operations owner.
The deployment status value is Under assessment.
The external dependencies value is Model-provider subcontractor.
The review date value is the date you complete this record.

Use only these fictional scenario details. Real patient information has no place in this workbook.

Select cell A2.
Enter the mapped values across A2:L2.

Good work. Your first working paper now makes the system boundary explicit.

The completed row should show the clinician review requirement before dental-record entry.

Map the PHI data flow

A data-flow map records each sender, recipient, and use of PHI. It also preserves unanswered questions as evidence gaps for later review.

Click Add sheet at the bottom of the workbook.

You'll see another blank sheet tab beside System Inventory.

Double-click the new sheet tab's name.
Type PHI Data Flow into the selected tab name.

You'll see both completed tab names at the bottom of the workbook.

Select cell A1.
Enter these headers across A1:H1 in this order: stage, sender, recipient, data, purpose, storage or retention, control evidence, unknowns.

You should see eight data-flow fields spanning the first row.

How the seven stages connect

Collection from patient visit. Sender: Dental patient. Recipient: Dental clinic. Data: Visit audio and patient clinical context containing PHI. Purpose: Capture the encounter for note drafting. Storage or retention: Temporary clinic capture storage. Control evidence: Clinic collection procedure requested. Unknowns: Patient notice process and local retention period.
Transmission to Vendor A. Sender: Dental clinic. Recipient: Vendor A. Data: Visit audio and patient clinical context containing PHI. Purpose: Submit the encounter for draft-note generation. Storage or retention: Transient transfer storage. Control evidence: Transmission-security evidence requested. Unknowns: Transfer protocol and queued-copy retention.
Vendor A processing. Sender: Vendor A intake. Recipient: Vendor A processing service. Data: Visit audio and patient clinical context containing PHI. Purpose: Prepare the encounter for note generation. Storage or retention: Vendor processing storage with an unknown duration. Control evidence: Processing architecture and access-control evidence requested. Unknowns: Internal access and temporary-copy locations.
Model-provider processing. Sender: Vendor A. Recipient: Model-provider subcontractor. Data: Visit audio and patient clinical context containing PHI. Purpose: Generate draft clinical-note content. Storage or retention: Model-provider retention remains unknown. Control evidence: Subcontractor data-flow and retention evidence requested. Unknowns: Training use and deletion terms.
Draft-note return to clinician. Sender: Vendor A. Recipient: Dental clinician. Data: Draft dental note containing PHI. Purpose: Support clinician review. Storage or retention: Temporary clinician-review interface. Control evidence: Clinician review requirement documented. Unknowns: Draft retention and correction history.
Clinician entry into the dental record. Sender: Dental clinician. Recipient: Dental record. Data: Reviewed dental note containing PHI. Purpose: Store the approved clinical note. Storage or retention: Clinic record-retention schedule. Control evidence: Clinician approval requirement documented. Unknowns: Entry audit-log details.
Deletion. Sender: Vendor A and the model-provider subcontractor. Recipient: Vendor and subcontractor deletion processes. Data: Visit audio, patient context, and draft clinical-note content containing PHI. Purpose: Remove temporary processing copies. Storage or retention: No active copy after confirmed deletion. Control evidence: Deletion schedule and attestation requested. Unknowns: Backup-deletion timing and subcontractor confirmation.

Select cell A2.
Enter the seven mapped stages across A2:H8.

Your map should now show seven stages. Every stage records retention, control evidence, and unknowns.

Before you compare the tabs, which handoffs do you expect to contain the most unknowns?

Select the System Inventory tab.

You should see twelve fields with one complete Vendor A record.

Select the PHI Data Flow tab.

You should see eight columns with seven connected stages from patient-visit collection through deletion.

✔️ Both tabs are complete

Your workbook now defines Vendor A's system boundary and traces every fictional PHI handoff.

ⓧ I'd like to double check the workbook

Compare your workbook against these required details.

The System Inventory tab contains twelve fields and one complete Vendor A record.
The inventory identifies dental clinicians as the intended users and dental patients as the affected people.
The inventory requires clinician review before record entry.
The inventory records visit audio and patient clinical context as inputs.
The inventory records a draft dental note as the output.
The inventory names a model-provider subcontractor as an external dependency.
The PHI Data Flow tab contains eight columns and seven stages.
The flow covers collection, transmission, Vendor A processing, model-provider processing, draft return, dental-record entry, and deletion.
Every flow stage records storage or retention, control evidence, and unknowns.

You have a solid assessment boundary now. Next, you'll run a traditional vendor review and expose the AI-specific questions it cannot answer.

Run a Traditional Vendor Review

The system inventory now defines Vendor A's intended use. Your PHI flow shows every place sensitive clinical data moves.

A conventional security checklist can look complete while AI model behavior remains untested. Human oversight can remain untested too.

You will first review familiar vendor controls. You will then build a scored risk register.

Finally, you will test whether those working papers answer five AI-assurance questions. This test exposes the limit of a traditional review.

In this step, get ready to:

Assess six traditional security and privacy control areas.
Build an initial risk register with a transparent scoring method.
Test the review against five AI-assurance questions to expose its evidence gap.

Assess traditional vendor controls

A vendor review separates control claims from evidence. Each review area receives one of three statuses based on the material available today.

What do the three statuses mean?

Use Supported when supplied evidence demonstrates that the control exists.
Use Not supported when supplied evidence demonstrates that the control is absent.
Use Evidence missing when the available material cannot support either conclusion.

Switch back to the Vendor A Assessment Workbook in Google Sheets.
Click the plus icon beside the existing sheet tabs to add a blank tab.

You should see a new blank tab beside System Inventory and PHI Data Flow.

Rename the blank tab Traditional Review.
Enter these headers across the first row: Review area, Assessment question, Status, Available evidence, and Follow-up.

You should see five labeled columns ready for the control assessment.

Complete the access control row. The question is who can access patient data or draft notes. The status is Evidence missing. The available evidence is No vendor access-control evidence supplied. The follow-up is Request user-role and access-review evidence.
Complete the encryption row. The question is whether PHI is encrypted during transmission or storage. The status is Evidence missing. The available evidence is No vendor encryption evidence supplied. The follow-up is Request encryption design and configuration evidence.

The first two rows now separate essential control questions from unsupported assumptions.

Complete the retention and deletion row. The question is how long visit audio or clinical context remains stored. The status is Evidence missing. The available evidence is No retention schedule or deletion evidence supplied. The follow-up is Request retention periods and deletion procedures.
Complete the security-incident handling row. The question is how security incidents are detected or communicated. The status is Evidence missing. The available evidence is No incident-response evidence supplied. The follow-up is Request the incident-response process and notification commitments.

Your review now covers data lifecycle controls plus the response expected after a security event.

Complete the BAA status row. The question is whether Vendor A provides a business associate agreement for its handling of PHI. The status is Evidence missing. The available evidence is No BAA supplied. The follow-up is Request a proposed BAA for legal review.
Complete the subcontractor coverage row. The question is whether the model-provider subcontractor is covered by appropriate commitments. The status is Evidence missing. The available evidence is Model-provider dependency identified without coverage evidence. The follow-up is Request the subcontractor list and contractual coverage evidence.

You should now see six populated control rows. That gives you a traceable baseline without treating an unanswered question as a working control.

Why does the BAA matter?

A business associate agreement records written assurances for a business associate's handling of PHI. Vendor A's use of a model-provider subcontractor makes contractual coverage part of the evidence trail.

Build the initial risk register

A risk register turns each control gap into a scenario with an owner. A visible score helps another reviewer follow your prioritization.

How does the scoring work?

This project uses a defined 1-to-3 scale. The method is a project convention for transparent prioritization.

Likelihood 1 means unlikely. Likelihood 2 means possible. Likelihood 3 means likely.
Impact 1 means limited harm. Impact 2 means serious harm. Impact 3 means severe harm.
Multiply likelihood by impact to calculate the score. Possible values range from 1 through 9.

Click the plus icon beside the workbook tabs to add another blank tab.
Rename the new tab Risk Register.

You should now see Risk Register beside the three existing tabs.

Enter these headers across the first row: Risk ID, Category, Scenario, Affected asset or person, Current control, Evidence, Likelihood, Impact, Score, Response, Owner, Residual risk, and Status.

You should see thirteen columns covering the scenario through its unresolved risk.

Complete risk R-01 for unauthorized access. Use category Privacy. The scenario is unauthorized access to visit audio or patient context. The affected person is the dental patient. The current control is None confirmed. The evidence is Evidence missing. Use likelihood 2 with impact 3. Use response Mitigate with owner Security lead. Record residual risk as High until access-control evidence is reviewed. Set the status to Open.
Complete risk R-02 for exposed transmissions. Use category Security. The scenario is exposure of PHI during transmission to Vendor A or its model provider. The affected asset is transmitted PHI. The current control is None confirmed. The evidence is Evidence missing. Use likelihood 2 with impact 3. Use response Mitigate with owner Security lead. Record residual risk as High until encryption evidence is reviewed. Set the status to Open.

The first two risks connect missing controls to patient data exposure scenarios.

Complete risk R-03 for excessive retention. Use category Privacy. The scenario is retention of visit audio beyond the clinic-approved period. The affected asset is patient visit audio. The current control is None confirmed. The evidence is Evidence missing. Use likelihood 2 with impact 2. Use response Mitigate with owner Privacy lead. Record residual risk as Medium until retention and deletion evidence is reviewed. Set the status to Open.
Complete risk R-04 for unconfirmed subcontractor coverage. Use category Privacy and third-party risk. The scenario is model-provider handling of PHI without confirmed contractual coverage. The affected people are dental patients. The current control is Model-provider dependency recorded. The evidence is Evidence missing. Use likelihood 2 with impact 3. Use response Mitigate with owner Vendor risk lead. Record residual risk as High until subcontractor coverage is confirmed. Set the status to Open.

All four initial risks now have a scenario plus an accountable owner.

Calculate every score by multiplying its likelihood by its impact.

You should see scores of 6 for R-01, R-02, and R-04. You should see a score of 4 for R-03.

Scores look wrong?

Check that likelihood and impact contain only the scale values 1, 2, or 3. Recalculate each score as likelihood multiplied by impact.

Still stuck? Help me check the scoring in my healthcare vendor risk register.

Expose the AI-assurance gap

A risk assessment earns trust by answering the questions a decision-maker will ask. You will now test the current working papers against five questions about the AI-enabled workflow.

Before you test the review, do you think the existing control rows provide a supported answer to all five questions?

Test whether the current evidence demonstrates that Vendor A's draft output is valid for its intended clinical use.
Test whether the current evidence explains how Vendor A fails safely during missing input or unreliable output.
Test whether the current evidence demonstrates consistent performance across relevant patient groups.
Test whether the current evidence defines post-deployment monitoring for model performance.
Test whether the current evidence demonstrates how a clinician rejects or overrides a draft.

You should find no supplied evidence that answers these questions. That visible shortfall is the intended result of the test.

What does the gap prove?

The Evidence missing status records uncertainty. A supported conclusion requires evidence that addresses the question directly.

Your traditional review covers familiar vendor controls. Its current structure leaves model behavior plus operational oversight unresolved.

Add an output-validity row to Traditional Review. The question asks what evidence demonstrates valid draft-note output for the intended clinical use. Set the status to Evidence missing. Record No validation study or acceptance criteria supplied as the available evidence.
Add a safe-failure row to Traditional Review. The question asks how Vendor A responds to missing input or unreliable output. Set the status to Evidence missing. Record No failure-mode testing or escalation procedure supplied as the available evidence.

The first two AI-assurance rows now make output quality plus failure handling visible as unresolved questions.

Add a subgroup-effects row to Traditional Review. The question asks whether performance is consistent across relevant patient groups. Set the status to Evidence missing. Record No subgroup performance results supplied as the available evidence.
Add a post-deployment monitoring row to Traditional Review. The question asks how model performance is monitored after deployment. Set the status to Evidence missing. Record No monitoring measures or review thresholds supplied as the available evidence.

The review now shows that patient-group performance plus ongoing monitoring need separate evidence.

Add a clinician-override row to Traditional Review. The question asks how a clinician rejects or overrides a draft note. Set the status to Evidence missing. Record Clinician review is required but override evidence was not supplied as the available evidence.

You should now see five AI-assurance rows marked Evidence missing beneath the six traditional control rows.

Add risk R-05 to the Risk Register for invalid draft output. Use category AI assurance. The current control is Clinician review required. The evidence is Evidence missing. Use likelihood 2 with impact 3. Assign the Clinical lead as owner.
Add risk R-06 for unsafe failure. Use category AI assurance. The current control is None confirmed. The evidence is Evidence missing. Use likelihood 2 with impact 3. Assign the Patient safety lead as owner.

Two new register rows now connect the assurance gap to clinical-output risk.

Add risk R-07 for unknown subgroup effects. Use category AI assurance. The current control is None confirmed. The evidence is Evidence missing. Use likelihood 2 with impact 3. Assign the Clinical governance lead as owner.
Add risk R-08 for missing post-deployment monitoring. Use category AI assurance. The current control is None confirmed. The evidence is Evidence missing. Use likelihood 2 with impact 2. Assign the Vendor manager as owner.

The register now records subgroup uncertainty plus the lack of ongoing performance monitoring.

Add risk R-09 for an unverified clinician-override mechanism. Use category AI assurance. The current control is Clinician review required. The evidence is Evidence missing. Use likelihood 2 with impact 3. Assign the Clinical lead as owner.
Calculate the five new scores by multiplying each likelihood by its impact.

You should see scores of 6 for R-05, R-06, R-07, and R-09. You should see a score of 4 for R-08.

Before you complete the final check, which five questions do you expect to still show Evidence missing?

Return to Traditional Review to confirm that output validity, safe failure, subgroup effects, post-deployment monitoring, and clinician override are marked Evidence missing.
Return to Risk Register to confirm that the likelihood scale plus impact scale use values from 1 through 3.

You should see four scored privacy or security risks plus five documented AI-assurance gaps. You have now demonstrated exactly where a conventional review stops providing answers.

Your traditional review is complete. Next, you will add the AI-specific structure needed to turn these unanswered questions into evidence requests and treatments.

Add AI-Specific Risk Analysis

Your traditional review exposed five unanswered questions about model behavior. That visible gap is useful because it shows where a security checklist stops supporting the acquisition decision.

The NIST AI RMF 1.0 framework gives those questions a consistent structure. Its four functions cover governance, context, measurement, and risk treatment.

You will expand the register in Google Sheets with AI-specific scenarios. Each scenario will end with evidence to request and a decision impact to consider.

In this step, get ready to:

Extend the Risk Register with NIST AI RMF fields.
Add AI-specific risks with targeted evidence requests.
Prioritize every risk with a response. Document its treatment ownership and residual risk.

Extend the risk register

The existing register scores privacy and security scenarios. Five additional fields will connect those scenarios to an AI framework and show how missing evidence affects the decision.

Why NIST AI RMF 1.0?

NIST AI RMF 1.0 is a voluntary framework for managing AI risk across sectors. It fits this assessment because Vendor A combines clinical use, human oversight, and a third-party model provider.

The framework organizes your reasoning and evidence requests. This educational workbook does not claim certification or future-version conformity.

Switch back to the Vendor A Assessment Workbook from earlier.
Select the Risk Register tab.
Insert five blank columns immediately after status.
Enter framework function, trustworthiness characteristic, evidence request, treatment deadline, and decision impact as the five new headers.
Scroll to the right edge of the register.

You should see the five new headers beside status. Your register now has dedicated space for framework mapping and acquisition reasoning.

What Do the Four Functions Cover?

GOVERN captures policies, accountability, roles, and third-party responsibilities.
MAP connects each risk to its intended use, affected people, operating context, and human oversight.
MEASURE covers testing, evaluation, performance evidence, and risk tracking.
MANAGE turns identified risks into prioritized responses, monitoring, and documented residual risk.

Add AI risk scenarios and evidence requests

This part is detailed. You will add the scenarios in two batches so you can check the register after each batch.

First Six AI Risk Scenarios

Valid and reliable output. A draft contains an incorrect clinical detail that a clinician could approve. Map it to MEASURE with the characteristic valid and reliable. Request the validation method, acceptance thresholds, error rates, and representative test results.
Safety. The service produces a low-quality draft without a clear safe-failure signal. Map it to MAP with the characteristic safe. Request safe-failure test results and the workflow used when output quality is uncertain.
Security and resilience. Malicious input or a service outage disrupts note generation or exposes PHI. Map it to MEASURE with the characteristic secure and resilient. Request security testing and service-recovery evidence.
Accountability and transparency. Responsibility for model changes or harmful output is unclear. Map it to GOVERN with the characteristic accountable and transparent. Request assigned roles and a change-history sample.
Explainability and interpretability. A clinician cannot determine why a statement appears in the draft. Map it to MAP with the characteristic explainable and interpretable. Request clinician-facing guidance and usability-test results.
Privacy enhancement. Vendor A or its model provider keeps more patient data than the workflow needs. Map it to GOVERN with the characteristic privacy-enhanced. Request data-minimization controls and verified retention terms.

Add six uniquely identified rows to the Risk Register using the first batch of scenario definitions.
Count the six new rows in the register.

You should now see six new AI-risk rows. Each row should have a framework function, a trustworthiness characteristic, and an evidence request.

Next Five AI Risk Scenarios

Fairness. Output quality differs across relevant patient groups. Map it to MEASURE with the characteristic fair with harmful bias managed. Request subgroup performance results and the vendor's harmful-bias evaluation method.
Clinician oversight. A clinician cannot override a draft or the service does not record the override. Map it to MAP with the characteristic accountable and transparent. Request an override demonstration and an audit-log sample.
Model-provider dependencies. The subcontractor changes its model or retention terms without enough notice. Map it to GOVERN with the characteristic secure and resilient. Request subcontractor terms and the model-change notification process.
Monitoring. Performance drift or rising clinician corrections remain undetected after deployment. Map it to MANAGE with the characteristic valid and reliable. Request monitoring thresholds and a sample performance report.
Incident response. Vendor A delays notifying the clinic about an AI safety or security incident. Map it to MANAGE with the characteristic safe. Request the incident-response procedure and notification commitments.

Add five uniquely identified rows to the Risk Register using the second batch of scenario definitions.
Count all eleven new AI-risk rows in the register.

You should now see all eleven AI-risk scenarios. The collection covers model behavior, clinical oversight, third-party dependencies, and operational response.

Complete the inherited context fields for the eleven rows using the System Inventory and PHI Data Flow tabs.
Scan the new rows for empty scenario or affected-person cells.

Every new row should now identify a concrete scenario and the person or asset that could be affected. The register has enough context to support prioritization.

Prioritize treatment and verify coverage

Framework labels organize the risks. Scores, owners, treatments, and residual risk turn that organization into an accountable decision process.

How to Choose a Response

mitigate reduces likelihood or impact through controls such as mandatory clinician review or a restricted pilot.
transfer assigns defined obligations through contracts or insurance while the clinic retains oversight.
avoid stops the risky activity when the exposure remains outside the clinic's tolerance.
accept records an informed decision to retain a low residual risk with accountable approval.

Enter a likelihood value from 1 to 3 for every new risk using the existing scale.
Enter an impact value from 1 to 3 for every new risk using the existing scale.

You should now see likelihood and impact values on all eleven rows. Base likelihood on known exposure and available evidence.

Extend the existing likelihood multiplied by impact calculation into every new score cell.

Every new score should contain a value from 1 through 9. The highest values now identify the scenarios that need the strongest decision conditions.

Missing vendor evidence creates uncertainty about a control. That uncertainty belongs in the register until the requested material is reviewed.

Enter Evidence missing in each evidence cell where the vendor has supplied no support.
Describe the matching residual risk as Uncertain pending vendor evidence.

The evidence gaps should now remain visible beside the scores. Their presence prevents unsupported control assumptions from lowering the recorded risk.

Treatment and Ownership Guide

The clinic clinical/operations owner fits validity, safety, explainability, and clinician-oversight risks.
The clinic privacy/security owner fits privacy, security, resilience, and incident-response risks.
The vendor-management owner fits accountability and model-provider dependency risks.
Fairness and monitoring treatments can use a restricted pilot with defined review thresholds.
High-impact evidence gaps can block approval until the vendor supplies acceptable support.

Select mitigate, transfer, avoid, or accept in the response field for every risk.
Assign one accountable role to every risk using the ownership guide.

Every row should now show who owns the response. The response should match the risk's score and available evidence.

Add a concrete treatment action after the progress state in every status cell.
Enter a treatment deadline for every risk.

Use Before approval for evidence that determines whether the clinic can proceed. Use Before pilot launch for controls required before use.

Classify each decision impact as an approval blocker, approval condition, pilot limitation, or monitoring requirement.
Document the expected risk remaining after treatment in every residual risk cell.

Your register should now connect each AI risk to evidence, treatment, ownership, timing, and a decision consequence. Every score has a visible path into the acquisition decision.

Before you filter the register, which of the four framework functions do you expect to contain the most evidence gaps?

Filter the framework function column to show only GOVERN.
Change the framework filter to show only MAP.
Change the framework filter to show only MEASURE.
Change the framework filter to show only MANAGE.

Each filtered view should show at least one risk. Every view should include an evidence request and a treatment recorded in status.

✔️ All four functions appear

Strong work. Your register now covers all four NIST AI RMF functions with evidence requests and accountable treatments.

ⓧ I'd like to double check the register

Confirm that framework function appears after status.
Confirm that trustworthiness characteristic, evidence request, treatment deadline, and decision impact appear beside it.
Confirm that valid output, safety, security, resilience, accountability, transparency, and explainability appear in the scenarios.
Confirm that privacy enhancement, fairness, clinician oversight, model-provider dependencies, monitoring, and incident response appear in the scenarios.
Confirm that GOVERN, MAP, MEASURE, and MANAGE each have an evidence request.
Confirm that every risk has a score, response, owner, treatment, deadline, decision impact, and residual risk.
Confirm that missing vendor support is recorded as uncertainty.

You have turned the traditional-review gap into a scored AI-risk treatment plan. Next, you will use that plan to make and publish a defensible vendor decision.

Make and Publish an Evidence-Based Decision

The expanded risk register now explains the clinic's exposure through NIST AI RMF 1.0. That analysis only becomes useful when a reviewer can trace it to an accountable decision.

This step turns those working papers into a conditional-approval memo. You will publish a sanitized case study that another reviewer can inspect.

In this step, get ready to:

Complete a sanitized decision memo with a conditional-approval recommendation.
Export the decision memo as a PDF.
Publish the sanitized case study in your public repository.

Draft the decision memo

The blank Vendor A Decision Memo in Google Docs becomes the bridge between your detailed register and the acquisition decision. Every claim should point back to evidence already recorded in the workbook.

What makes the decision defensible?

A defensible memo connects its recommendation to the documented evidence. It also identifies uncertainty where evidence is missing.

Conditional approval means defined controls must be completed before broad use. Each condition needs an accountable owner plus a deadline.

Residual risk records what remains after those treatments. The next review point gives the clinic a clear moment to reassess the decision.

Switch back to the blank Vendor A Decision Memo from the earlier workspace.
Add Vendor A Decision Memo as the document title.
Add an opening disclaimer that identifies the work as a fictional educational assessment with no claim of HIPAA certification.

The top of the memo now establishes a clear boundary for every reader. It presents educational analysis without implying a certification or legal conclusion.

Write an Executive Summary section that recommends Conditional approval for Vendor A.
Write a Scope section covering the fictional dental clinical-note assistant.

Your opening sections should now tell a reviewer what decision is being made. They should also identify the fictional system being assessed.

Write a PHI-flow summary that traces PHI from collection through deletion.
Write a Top five risks section using the highest-scoring risks with the greatest decision impact.

The memo now connects the proposed use to the information flow. It also brings the most important decision drivers to the front.

Write a Missing evidence section using the unresolved evidence requests from the risk register.
Write an Approval conditions section using the treatments plus deadlines from those risks.

A reviewer should now see why the vendor cannot receive unconditional approval. Each evidence gap should lead to a specific condition.

Add an Accountable owners section naming the owner for every approval condition.
Add a Residual risks section explaining what remains after the planned treatments.

The memo now shows who must act. It also shows what exposure remains after that work.

Add a Next review point section tied to the treatment deadlines in the register.
Copy a sanitized AI system inventory excerpt from the System Inventory tab into the memo.

The decision now has a reassessment point. The inventory excerpt gives readers enough system context to understand the recommendation.

Copy the same five risk rows from the Risk Register tab into the memo.
Review the copied rows for fictional labels only.

You should now see a compact evidence appendix containing one inventory excerpt plus five risk rows. The evidence should match the reasoning in the memo.

Keep the evidence sanitized

This memo is headed for a public repository. Keep the full working papers private in Drive.

The public memo should contain fictional scenario details only. Real names, patient details, secrets, and private Google links must stay out.

Remove any real names from the memo.
Remove any patient details from the memo.
Remove any secrets from the memo.
Remove any private Google links from the memo.
Review the completed memo from the title through the five risk rows.

You should see a conditional-approval recommendation supported by the PHI flow, top risks, evidence gaps, approval conditions, owners, residual risks, and next review point.

Does the recommendation feel unsupported?

Check that every approval condition corresponds to a risk or evidence request in the register. Remove claims that cannot be traced to the workbook.

If the top risks do not explain the recommendation, revisit their decision impact before finalizing the memo. Help me connect my risk register to a conditional-approval decision.

Export the sanitized PDF

A PDF preserves the memo as a reviewable artifact. You will store the exported copy beside the working papers before publishing it.

In Vendor A Decision Memo, click File in the top menu.
Select Download.
Choose PDF Document (.pdf).

Your browser downloads a PDF copy of the completed memo. The editable Google Doc remains unchanged.

Confirm the downloaded file is named Vendor A Decision Memo.pdf.
Switch back to the Healthcare AI Vendor Assessment folder in Google Drive.
Click New in the upper-left corner.
Select File upload.
Choose Vendor A Decision Memo.pdf from your downloads.

The Drive folder should now contain the workbook, the editable decision memo, and Vendor A Decision Memo.pdf.

Open Vendor A Decision Memo.pdf from the Drive folder.
Inspect the PDF from the title through the five risk rows.

You should see the complete sanitized memo without clipped tables or missing sections. This is the exact artifact you will publish.

Does the PDF look incomplete?

Return to the Google Doc if a table is clipped. Reduce the table width before downloading a fresh PDF.

Upload the replacement PDF to the Drive folder after confirming every required section appears. Help me fix the layout of my exported decision memo PDF.

Publish the public case study

Publishing to a public GitHub repository is the sensitive point. You stay in control by uploading only the sanitized PDF plus the public README.

The repository should let a signed-out reviewer understand the decision. It should also let them inspect the supporting memo without requesting private Drive access.

Switch back to the healthcare-ai-vendor-risk-assessment repository from earlier.
Click Add file above the repository file list.
Select Upload files.
Choose Vendor A Decision Memo.pdf from your computer.
Enter Add sanitized decision memo as the commit message.
Click Commit changes to complete the upload.

Strong work. The repository now contains a public copy of your sanitized decision memo.

Open Vendor A Decision Memo.pdf from the repository file list.
Store the current page URL here: your public PDF URL.

You now have a public artifact URL that the README can use. The link opens the uploaded repository file without exposing Drive.

Return to the repository file list.
Open README.md.
Choose the file-editing control above the README.
Keep Fictional educational assessment. No real patient data is used. unchanged at the top.
Replace the final-decision placeholder with Conditional approval.
Replace the top-risks placeholder with a short summary of the five risks used in the memo.
Select Preview above the editor.

The preview should now show the original disclaimer, the final decision, and a readable summary of the five decision-driving risks.

Return to the README editing view.
Add a Portfolio skills demonstrated section covering system inventory, PHI-flow mapping, vendor review, AI-risk analysis, evidence requests, and decision writing.
Use the editor's link control to link Decision memo PDF to your public PDF URL.
Select Preview above the editor.

The preview should now show the skills section plus a clickable artifact link. The link should point to the PDF stored in GitHub.

Return to the README editing view.
Add a Methodology section covering the system inventory, PHI data flow, traditional review, NIST AI RMF 1.0 analysis, and 1-to-3 scoring method.
Add a Limitations section covering the fictional evidence, missing vendor evidence, project-defined scoring method, and absence of a HIPAA certification claim.
Select Preview above the editor.

The README should now explain how you reached the decision. It should also state the boundaries that prevent readers from overinterpreting the work.

Official sources to cite

Use the NIST AI Risk Management Framework page for the framework status and purpose.
Use the HHS Security Rule Risk Analysis guidance for the healthcare risk-analysis context.
Use the HHS Business Associates guidance for vendor plus subcontractor context.

Return to the README editing view.
Replace the sources placeholder with the three official references above.
Remove any real names, patient details, secrets, or private Google links from the README.
Select Preview above the editor.

The final preview should show the disclaimer, decision, top risks, skills, PDF link, methodology, limitations, and official sources. Every link should be safe for a public reader.

Return to the README editing view.
Enter Publish final vendor assessment as the commit message.
Click Commit changes to publish the README update.
Store the current repository URL here: your public repository URL.

Before you test the signed-out view, do you expect every public artifact to open without access to your Google account?

Open a private browser window that is signed out of GitHub.
Paste your public repository URL into the address bar.
Press Enter to load the public repository.

You should see the fictional-data disclaimer, the conditional-approval decision, and the official sources in the README. This proves the case study is publicly viewable.

Select the Decision memo PDF link in the README.
Inspect the opened PDF for sensitive information.

The PDF should open without a sign-in request. It should contain no real names, patient details, secrets, or private Google links.

Does the public check fail?

If the repository does not load while signed out, confirm that healthcare-ai-vendor-risk-assessment is public. If the PDF link requests Google access, point it to the uploaded GitHub file.

If the README still shows placeholders, return to its editing view. Replace the missing section before committing again.

Still stuck? Help me troubleshoot my public healthcare AI vendor assessment.

Secret mission

Handle a Vendor Evidence Gap

Vendor A cannot provide subgroup performance results before launch. Its model-provider subcontractor also has unconfirmed retention terms. Reassess the affected risks while preserving a clear trail from your original decision to a tightly limited conditional pilot.

Clean Up Your Resources

Your assessment resources in Google Drive and GitHub cost $0 with your existing accounts and the GitHub Free plan. Choose whether to keep them available, pause sharing, or delete them.

Resources you used:

Google Drive folder Healthcare AI Vendor Assessment.
Google Sheet Vendor A Assessment Workbook inside the Drive folder.
Google Doc Vendor A Decision Memo inside the Drive folder.
Revised PDF Vendor A Decision Memo.pdf inside the Drive folder.
Public GitHub repository healthcare-ai-vendor-risk-assessment.
Sanitized README.md inside the public repository.
Uploaded copy of Vendor A Decision Memo.pdf inside the public repository.

Keep everything running

No action is needed. Choose this option if you want the assessment resources to remain available.

Keep Healthcare AI Vendor Assessment restricted to people authorized to view the working papers.
Keep healthcare-ai-vendor-risk-assessment public while its contents remain sanitized.
Confirm that README.md still displays Fictional educational assessment. No real patient data is used..
Confirm that the public PDF contains no patient details or private Google links.

Pause - I'll come back to this later

This option preserves every assessment artifact while you pause public sharing. Your files remain ready for another review.

Leave Healthcare AI Vendor Assessment in Google Drive.
Leave healthcare-ai-vendor-risk-assessment in GitHub.
Remove links to the repository from applications until the writing has been proofread.
Proofread README.md before sharing the repository again.
Review Vendor A Decision Memo.pdf before sharing the repository again.

Delete - I don't want to use this again

Deleting the repository removes its sanitized files from public access. Moving the Drive folder to trash removes the working papers from your active Drive.

Download the Google Drive files you want to retain before deleting the folder.
Download the repository files you want to retain before deleting the repository.

Return to Google Drive from earlier.
Locate Healthcare AI Vendor Assessment.
Move Healthcare AI Vendor Assessment to trash.
Check Google Drive trash for Healthcare AI Vendor Assessment.

You should see the folder in trash. The workbook moves with the folder. The memo moves with the folder.

The Drive copy of Vendor A Decision Memo.pdf also moves with the folder.

Return to healthcare-ai-vendor-risk-assessment in GitHub.
Open the repository settings page.
Use the repository deletion controls to delete healthcare-ai-vendor-risk-assessment.
Complete the on-screen confirmation for healthcare-ai-vendor-risk-assessment.

The repository deletion removes README.md from public access. It also removes the uploaded copy of Vendor A Decision Memo.pdf.

Return to the former repository URL.

You should see that the repository is no longer available.

Nice Work!

You did it! You completed a sanitized healthcare AI vendor assessment for a fictional dental note assistant. Your evidence trail supports a tightly limited conditional pilot without exposing real patient data.

You've learned how to:

Built an AI system inventory for Vendor A's fictional dental note assistant. Mapped PHI from patient collection through vendor processing, clinician review, record entry, and deletion.
Ran a traditional vendor review that exposed unanswered questions about model behavior and clinician oversight. Applied NIST AI RMF 1.0 to turn those gaps into evidence requests. Assigned an accountable owner to every treatment. Documented the residual risk for the final decision.
Authored a sanitized decision memo that recommends a tightly limited conditional pilot. Published the supporting PDF and README in a public GitHub case study. Documented the methodology. Stated the limitations. Linked the official sources.
Completed the Secret Mission by reassessing the newly disclosed subgroup-performance and model-provider-retention gaps. Preserved the original conditional-approval decision in a decision log. Revised the recommendation to a tightly limited conditional pilot with accountable compensating controls.

Ready to quiz yourself?