'. What happens?", opts:["The browser displays the script tag as text","The script executes in the provider's browser, sending their session cookie to the attacker — potentially allowing account takeover","innerHTML automatically sanitizes script tags","This is only a risk on the parent's device, not the provider's"], answer:1,exp:"Using innerHTML with user-supplied data is a direct XSS vulnerability. The script executes in the provider's browser, potentially stealing their session and giving the attacker access to other eCheck reports they've viewed. Always use textContent or output encoding."}, {q:"Which Content Security Policy directive directly prevents clickjacking of the eCheck report page?", opts:["default-src 'self'","frame-ancestors 'none'","script-src 'self'","upgrade-insecure-requests"], answer:1,exp:"frame-ancestors 'none' in CSP (equivalent to X-Frame-Options: DENY) prevents the report page from being embedded in an iframe, blocking clickjacking attacks where an attacker overlays the report under a deceptive interface."}, {q:"A marketing analytics script (Google Tag Manager) is added to the portal for 'performance tracking.' It's installed on all pages including the eCheck report page. What is the risk?", opts:["No risk — Google is HIPAA compliant","The analytics script may capture report content, form data, or user behavior on PHI pages — it requires its own HIPAA BAA and must be excluded from PHI pages","This is fine if the analytics account is marked as 'health data'","Only a risk if the script captures video"], answer:1,exp:"Any third-party script on a page displaying PHI is a potential data leakage risk. Standard Google Tag Manager does not have a HIPAA BAA. Even HIPAA-compliant analytics tools must be carefully configured to exclude PHI pages and require a BAA."}, {q:"The access code submission form does not include a CSRF token. An attacker builds a malicious page that submits the form with a known valid access code when a provider visits. What is the impact?", opts:["No impact — CSRF only affects state-changing operations","The attacker's page can force the provider's browser to submit a valid access code, recording the provider's session accessing the eCheck report — potentially for unauthorized surveillance or audit manipulation","CSRF only works on login forms","The access code prevents CSRF automatically"], answer:1,exp:"CSRF on the access code form allows an attacker to forge a code submission using the provider's browser credentials. This could be used to access eCheck data in the provider's name or to manipulate audit logs. Always protect form submissions with CSRF tokens and SameSite cookies."}, {q:"mamabearhealth.com is accessible via both http:// and https://. What must be implemented?", opts:["Nothing — the secure version is available if users choose it","HTTP must redirect to HTTPS automatically, and HSTS must be set to force HTTPS on all future visits","Only the login page needs HTTPS","Add a browser warning but keep HTTP available for compatibility"], answer:1,exp:"Any HTTP access to a page that handles PHI transmits data unencrypted. HSTS (Strict-Transport-Security) tells browsers to always use HTTPS for this domain, even if the user types 'http://', preventing accidental unencrypted PHI transmission."} ]} }, { id:"web3", name:"Access Control, Authentication & Session Management", brief:"Who can access the portal, how they authenticate, and session lifecycle", lesson:{eyebrow:"Module 3 · Web Developer",title:"Access Control & Session Management",html:``}, quiz:{title:"Access Control & Session Management Quiz",questions:[ {q:"A provider validates an access code and receives a session cookie. They navigate to /review/different-echeck-id in the same browser window. What should happen?", opts:["The portal should show the second eCheck — the session is valid","The session must be tied to the specific eCheck ID — the server should reject the request and require a new access code for the different eCheck","The portal should prompt for the parent's credentials","Sessions should allow access to all eChecks from the same parent"], answer:1,exp:"Sessions issued after access code validation must be scoped to the specific eCheck. A valid session for eCheck A must not grant access to eCheck B. Each access is an independent authentication event tied to a specific record."}, {q:"The same access code is used from 3 different IP addresses within 5 minutes. What should the system do?", opts:["Nothing — providers may access from different devices","Flag the anomaly in the audit log and optionally alert the parent or coordinator — simultaneous multi-IP access may indicate code sharing or compromise","Lock the code immediately — only one IP is ever authorized","Require the provider to re-enter the code from each device"], answer:1,exp:"Simultaneous access from multiple IPs may indicate code sharing or that the code was compromised. Flagging and logging this anomaly supports HIPAA's audit trail requirements and allows the privacy officer to investigate if needed."}, {q:"A parent leaves the web portal open on a shared family tablet for 2 hours. What should have happened after 15 minutes?", opts:["Nothing — the parent is the authorized user","The portal should have timed out after 15 minutes of inactivity, cleared the screen, and required re-authentication","The portal should log out after 30 minutes — same as the provider portal","Session timeout doesn't apply to parent accounts"], answer:1,exp:"HIPAA Technical Safeguards require automatic logoff after inactivity. 15 minutes is the appropriate standard for parent access to a child's PHI — a shared tablet or forgotten open browser would otherwise expose the child's medical record."}, {q:"An access code is sent via SMS to the provider's phone number on file. The provider's SMS is also accessible on their shared work computer via iMessage. What risk does this represent?", opts:["No risk — the provider authorized the phone number","A coworker with access to the shared computer could intercept the SMS-delivered access code and access the child's eCheck report","SMS delivery is not a security risk if HTTPS is used","This is only a risk if the phone number was entered incorrectly"], answer:1,exp:"SMS-delivered access codes are vulnerable to interception on shared devices where SMS is synced (iMessage, Android Messages for Web, etc.). This is a known limitation of SMS-based delivery. It should be documented in the risk assessment and mitigated where possible (e.g., short expiry windows, access logging)."}, {q:"What must happen when a report page session expires due to inactivity?", opts:["Display a generic 404 page","Clear the report data from the DOM and redirect to the access code entry page with a clear expiry message","Keep the page visible but disable further interaction","Log the provider out of all sessions"], answer:1,exp:"On session expiry, the report data must be actively cleared from the DOM (not just hidden) and the user redirected to re-enter their access code. Simply disabling interaction while leaving PHI visible on screen still constitutes a data exposure."} ]} }, { id:"web4", name:"Infrastructure, Hosting & mamabearhealth.com Security", brief:"SSL, DNS, dependency management, and secure deployment for the web portal", lesson:{eyebrow:"Module 4 · Web Developer",title:"Infrastructure & Hosting Security",html:``}, quiz:{title:"Infrastructure & Hosting Security Quiz",questions:[ {q:"You check mamabearhealth.com on SSL Labs and receive a B rating due to support for TLS 1.0. What should you do?", opts:["A B rating is acceptable for a healthcare website","Disable TLS 1.0 and 1.1 on the server configuration — they have known vulnerabilities and must not be used for PHI transport","Add more cipher suites to improve the rating","Accept the rating — users with older browsers need TLS 1.0"], answer:1,exp:"TLS 1.0 and 1.1 have known cryptographic vulnerabilities and must be disabled on all servers handling PHI. The target is TLS 1.2 minimum, TLS 1.3 preferred, with an SSL Labs A+ rating."}, {q:"A Subresource Integrity (SRI) hash is added to an external JavaScript library loaded on the portal. The CDN delivers a modified version of the library. What happens?", opts:["The browser loads the modified library — SRI only generates warnings","The browser refuses to execute the library because its hash doesn't match the expected value — protecting against supply chain attacks","SRI prevents loading but doesn't alert you","SRI only works for CSS, not JavaScript"], answer:1,exp:"SRI causes the browser to cryptographically verify that the loaded resource matches the expected hash. If the CDN delivers a modified (compromised) file, the hash won't match and the browser will refuse to load it, preventing supply chain attacks."}, {q:"npm audit discovers a Critical vulnerability in a dependency used by the portal. The fix is available. When should it be addressed?", opts:["At the next scheduled sprint — follow the change management process","Before the next deployment — Critical vulnerabilities should not be deployed to production","Within 90 days — standard enterprise patch cycle","Only if the vulnerability affects a feature used by the portal"], answer:1,exp:"Critical vulnerabilities in actively deployed web applications must be addressed before the next production deployment. The standard for healthcare web applications is 7 days for actively exploited critical CVEs, 30 days for other critical issues."}, {q:"A developer deploys a portal update directly from their laptop to the production server using FTP. What is the problem?", opts:["FTP is slower than SFTP","Direct deployment from developer machines bypasses security scans, introduces risk of local malware or unauthorized code changes reaching production, and has no audit trail","This is acceptable for small updates","FTP is acceptable if the connection uses SSL"], answer:1,exp:"Direct local-to-production deployment is a security anti-pattern. It bypasses automated security scans, creates no reproducible audit trail, and introduces the risk that local machine malware or unauthorized local changes reach production. Always use a CI/CD pipeline."}, {q:"The staging environment is being populated with real parent and child data from production for testing a new feature. What is wrong with this?", opts:["Staging environments are secure — this is acceptable","Staging environments must never contain real PHI — use synthetic or properly de-identified test data. Real PHI in staging is a HIPAA violation","This is acceptable if staging uses the same security controls as production","Only acceptable if developers sign an NDA"], answer:1,exp:"Staging environments typically have weaker access controls than production, may have more developer access, and may use different (less secure) infrastructure. Real PHI must never be used in staging — always use synthetic test data that looks realistic but contains no actual patient information."} ]} }, { id:"web5", name:"HIPAA Essentials, Breach Recognition & Secure Dev Workflow", brief:"PHI scope, breach reporting, social engineering, and secure development habits", lesson:{eyebrow:"Module 5 · Web Developer + Shared",title:"HIPAA Essentials & Secure Dev Workflow",html:``}, quiz:{title:"HIPAA Essentials & Secure Dev Quiz",questions:[ {q:"A web developer discovers that the portal's access code validation has a bug — expired codes are still rendering eCheck reports. What is the correct response?", opts:["Fix the bug in the next sprint — no immediate action needed","Fix the bug immediately, determine how many expired codes may have been used after expiry, and report to the Security Officer within 24 hours","Only report if you can confirm an unauthorized person accessed a report","Fix the bug and note it in the changelog — no reporting needed"], answer:1,exp:"A validation bug allowing expired codes to access eCheck reports means PHI may have been accessible beyond the authorized time window. This is a potential breach. Fix the exposure (stop the bleeding), assess the scope, and report to the Security Officer within 24 hours."}, {q:"You receive an email from 'security@scala-hosting-alerts.com' saying your SSL certificate for mamabearhealth.com has expired and you must click a link to renew it immediately. What should you do?", opts:["Click the link — SSL expiry is urgent","Check mamabearhealth.com directly in your browser and log into your Scala Hosting account through the known URL — do not click the link in the email","Forward the email to the team Slack","Reply asking for more information"], answer:1,exp:"This is a classic phishing attack using urgency and impersonation of your hosting provider. Verify by navigating directly to mamabearhealth.com (your browser will warn if SSL has expired) and logging into Scala Hosting via the official URL — never via a link in an email."}, {q:"An npm package 'echeck-utils' is added to the portal. It has 12 downloads and was created 3 days ago. What should a developer do?", opts:["Install it — it works as expected","Refuse to install it without thorough vetting — very new packages with minimal downloads are a common vector for supply chain attacks in healthcare applications","Install it in staging first and see if anything breaks","Check if the package name is trademarked"], answer:1,exp:"Typosquatting and supply chain attacks use newly created packages with low download counts that mimic legitimate package names. A 3-day-old package with 12 downloads has not been vetted by the community and should not be added to a healthcare application without extensive review."}, {q:"Which of these data items is rendered by the MamaBear portal and classified as biometric PHI?", opts:["The child's home ZIP code","The 15-second video of the child in supine position","The parent's email address","The child's symptom severity score"], answer:1,exp:"The 15-second respiratory video uniquely identifies the child visually and documents their medical condition. Biometric PHI requires the highest level of protection — encrypted storage, signed URLs, DRM protection, and complete access audit trails."}, {q:"A developer uses real patient eCheck data to test a new portal feature in their local development environment. The data includes child names, DOBs, and videos. What is the problem?", opts:["This is fine as long as the developer doesn't share it","Using real PHI in a development environment is a HIPAA violation — development and testing must use synthetic or properly de-identified data","Only a problem if the developer's computer is not encrypted","Acceptable if the developer is a Loon Medical employee"], answer:1,exp:"Real PHI must never be used in development environments. Development machines have different security controls, may not be encrypted, may use shared networks, and fall outside the HIPAA-controlled production environment. Always use synthetic test data that mimics the structure of real data without using any actual patient information."} ]} } ] }, // ════════════════════════════════════════════════════════════════════ // CLINICAL COORDINATOR // ════════════════════════════════════════════════════════════════════ cc:{ title:"Clinical Coordinator", desc:"HIPAA compliance, help desk security, training responsibilities, and breach recognition for Clinical Coordinators", modules:[ { id:"cc1", name:"Your Role & HIPAA Responsibilities", brief:"What a Clinical Coordinator does — and does not — interact with in MamaBear Health", lesson:{eyebrow:"Module 1 · Clinical Coordinator",title:"Your Role & HIPAA Responsibilities",html:``}, quiz:{title:"Clinical Coordinator Role & HIPAA Quiz",questions:[ {q:"A parent calls and says 'I submitted my child Emma's eCheck yesterday about her cough and retractions — can you tell me if the doctor saw it?' To help, you would need to look up Emma's eCheck. What should you do?", opts:["Look up Emma's eCheck to give the parent accurate information","Explain that you don't have access to eCheck data and escalate to the clinical team or direct the parent to check the app for status updates","Tell the parent to call the doctor directly","Access the system just this once — it's for the parent's benefit"], answer:1,exp:"Viewing a child's eCheck data is outside your role scope regardless of the reason. Accessing PHI you are not authorized to access — even with good intentions — is a HIPAA violation. Direct the parent to the appropriate resource and escalate to the clinical team."}, {q:"A provider emails the help desk: 'I never received my access code for my patient Tommy's eCheck from last Friday.' What information in this email is PHI?", opts:["None — it's just a technical support request","The patient name (Tommy) paired with the health service context (eCheck) makes this incidental PHI — handle it with minimum necessary care","Only if the email includes the diagnosis","Only if Tommy's last name is included"], answer:1,exp:"A patient's name combined with any health service context (like an eCheck) is PHI. This support ticket contains incidental PHI and must be handled with minimum necessary care — don't forward it unnecessarily, and store it only in your HIPAA-compliant ticketing system."}, {q:"You are training a group of providers on the MamaBear portal. You want to show a live example of an eCheck report. What type of data must you use?", opts:["A real but older eCheck from a patient who gave verbal consent","Synthetic (fake) test data that looks realistic but contains no actual patient information","Any eCheck — providers are authorized to see patient data","An anonymized version with only the last name removed"], answer:1,exp:"Training must always use synthetic test data — never real patient PHI, even old records or 'anonymized' versions. Removing only a last name does not constitute proper de-identification. Create realistic-looking fake data for all training purposes."}, {q:"Your help desk coordinator login has admin-level database access that appears to have been provisioned by mistake. What should you do?", opts:["Use it when needed — you may need it someday","Report it to your supervisor immediately — access beyond your role scope must be corrected to maintain least-privilege compliance","Ignore it — having extra access doesn't mean you'll misuse it","Use it only in emergencies"], answer:1,exp:"Excess access beyond your role violates the principle of least privilege and creates a HIPAA audit risk. Report it immediately so it can be corrected. Retaining access you shouldn't have — even if you never use it — is a compliance issue."}, {q:"HIPAA applies to your role as a Clinical Coordinator because:", opts:["It only applies if you directly access patient eCheck records","HIPAA applies to all workforce members of a HIPAA-covered entity, including those who may encounter incidental PHI in help desk tickets, training materials, or support escalations","HIPAA only applies to clinical staff","Only if you sign a HIPAA agreement"], answer:1,exp:"HIPAA's workforce requirements apply to all members of a covered entity's workforce — not just clinicians. As a coordinator who may encounter incidental PHI in support tickets and training, you are subject to HIPAA's privacy and security requirements."} ]} }, { id:"cc2", name:"Help Desk Security & Social Engineering Defense", brief:"Protecting the help desk from social engineering and handling support tickets securely", lesson:{eyebrow:"Module 2 · Clinical Coordinator",title:"Help Desk Security & Social Engineering",html:``}, quiz:{title:"Help Desk Security & Social Engineering Quiz",questions:[ {q:"A caller says 'I'm Dr. Martinez from Children's Hospital — I have a patient in distress and I need you to immediately re-send the access code. There's no time for verification.' What should you do?", opts:["Re-send the code — patient safety is the priority","Do not bypass identity verification regardless of urgency — offer to send a verification link to the email address on file and escalate to a supervisor","Ask for the patient's name and re-send if the names match","Trust the caller — doctors wouldn't lie about patient emergencies"], answer:1,exp:"Urgency is the most common social engineering tactic used against help desks. A real emergency does not eliminate the need for identity verification. Bypassing verification — even with good intentions — creates a PHI exposure risk. Offer the fastest secure alternative (verification link to email on file) and escalate."}, {q:"A support ticket arrives: 'Having trouble accessing the portal — click here to see the screenshot of the error: bit.ly/mamabear-screenshot'. What should you do?", opts:["Click the link — screenshots are helpful for troubleshooting","Do not click the link — shortened URLs in support tickets are a phishing vector. Ask the user to attach a screenshot directly to the ticket","Forward to the development team to investigate","Reply asking for the user's access code"], answer:1,exp:"Shortened URLs (bit.ly, tinyurl, etc.) in support tickets can redirect to malware downloads or phishing pages. Never click links from external ticket submissions — ask users to attach screenshots or files directly to the ticket system."}, {q:"How should you verify the identity of a provider calling about an account issue?", opts:["Ask them to state their name and clinic — if it matches what they said last time, they're verified","Look up the account and verify through information already on file — not information the caller provides","Accept their NPI (National Provider Identifier) as verification — it's a government-issued number","Ask for the access code they received — if they have it, they're the right person"], answer:1,exp:"Identity verification must use information you already have on file, not information the caller provides on the spot. An attacker who has researched a provider can easily state a name and clinic. Verify by checking your records and confirming a pre-established identifier."}, {q:"A support ticket subject line reads: 'Help — Emma Johnson's cough eCheck from March 3rd not loading.' What is the problem with this subject line?", opts:["The subject is too long","The subject line contains PHI (child's full name + health service context) visible in email notifications and ticket system previews that may not be HIPAA-controlled","Subject lines are not visible outside the ticket system","Only a problem if the ticket is sent externally"], answer:1,exp:"Ticket subject lines often appear in email notifications, system logs, and previews that may not be within your HIPAA-controlled environment. PHI in subject lines violates minimum necessary — use generic subjects like 'Portal access issue - Ticket #1234'."}, {q:"You accidentally receive a misdirected email containing a child's full eCheck summary including name, DOB, and symptoms. What should you do?", opts:["Forward it to the correct recipient and delete your copy","Report it to your supervisor or Privacy Officer within 24 hours — this is a potential breach requiring assessment, even if accidental","Delete it and say nothing — the sender will notice and send it to the right person","File it in your records in case it's needed later"], answer:1,exp:"A misdirected email containing PHI is a potential HIPAA breach. Report to your Privacy Officer within 24 hours. Do not forward it (that creates another disclosure), do not keep it, and do not delete it before the Privacy Officer has assessed the situation."} ]} }, { id:"cc3", name:"Training Responsibilities & Platform Demo Security", brief:"Conducting secure training sessions and using only synthetic demo data", lesson:{eyebrow:"Module 3 · Clinical Coordinator",title:"Training Responsibilities & Demo Security",html:``}, quiz:{title:"Training Responsibilities & Demo Security Quiz",questions:[ {q:"You are preparing a training video for new providers. You want to use a real eCheck from 2023 because it has a 'perfect example' of retractions. The child's family gave verbal consent. Can you use it?", opts:["Yes — verbal consent and the age of the data make it acceptable","No — real patient data must never be used in training materials, regardless of consent type or age. Use synthetic data that replicates the clinical scenario","Yes, but only show it briefly","Yes, if you blur the child's name"], answer:1,exp:"Real patient PHI must never appear in training materials under any circumstances. Verbal consent is insufficient (HIPAA requires written authorization for marketing/educational use), the age of data doesn't matter, and blurring a name doesn't fully de-identify a clinical video. Create synthetic data that illustrates the same clinical scenario."}, {q:"During a live training session with 10 providers on a video call, a provider accidentally shares their screen showing a real child's eCheck with the child's name and video visible. What should you do?", opts:["Continue — providers are authorized to see patient data anyway","Ask the provider to stop sharing their screen immediately, pause the training, and report the incident to your Privacy Officer — do not distribute any recording of the session","Continue but turn off the recording","Ask the other providers to look away"], answer:1,exp:"Accidental PHI exposure in a training session must be stopped immediately. The 10 providers on the call were not necessarily authorized to see that specific child's record. Report to the Privacy Officer, who will assess whether this constitutes a breach and what notifications are required."}, {q:"Where should completed training materials (slides, screenshots, recorded demos) be stored?", opts:["On your personal computer for easy access","In a designated, access-controlled, HIPAA-compliant storage system — even if materials only contain synthetic data","In a shared Google Drive folder accessible to all staff","In your personal Google Drive for backup"], answer:1,exp:"Training materials — even those containing only synthetic data — may reveal system structure, workflow, or interface details. They must be stored in access-controlled, HIPAA-compliant storage, not on personal computers or general-purpose cloud storage."}, {q:"A provider asks you to send them a screenshot of their own patient's eCheck to help them understand the portal layout. What should you do?", opts:["Send the screenshot — they are authorized to see their own patient's data","Do not send patient eCheck screenshots — instead, schedule a training session using synthetic demo data to walk them through the portal layout","Send it if they sign a request form","Forward their request to the clinical team"], answer:1,exp:"Even though the provider is authorized to view their patient's eCheck via the portal, you are not authorized to extract and transmit that data via screenshot. Additionally, screenshots of PHI via email create uncontrolled copies. Use synthetic demo data for training."}, {q:"You discover that a training slide deck from 6 months ago is still being forwarded via email and contains a real patient's name in a 'sample' form field that was accidentally not replaced with test data. What should you do?", opts:["Reply to the email chain asking people to disregard that slide","Report to your Privacy Officer immediately — the extent of distribution must be assessed. Work with the team to replace the deck with a corrected version containing synthetic data only","Update the slide and resend the corrected version only","Delete your copy and hope others do the same"], answer:1,exp:"A training document with real PHI being forwarded via email is a breach in progress. Report to the Privacy Officer so the full distribution can be assessed. The Privacy Officer will determine what notifications are required. Provide a corrected version as soon as the assessment is complete."} ]} }, { id:"cc4", name:"Breach Recognition, Reporting & Everyday Security", brief:"Recognizing and reporting HIPAA incidents and maintaining daily security hygiene", lesson:{eyebrow:"Module 4 · Clinical Coordinator + Shared",title:"Breach Recognition & Everyday Security",html:`

Everyday Security Habits

• Lock your screen when stepping away — even for a moment. Support tickets may be visible.
• Use work systems only for work communications — no personal email, personal Slack, or SMS for support tickets.
• MFA on everything — every system you log into for work must use multi-factor authentication.
• Verify before acting — any unusual request via email or phone gets verified through a separate known channel.
• Clean desk policy — no printed materials containing user information left unattended.

When You Are Uncertain

If you are not sure whether something is a breach, whether you should report, or whether a request is legitimate — ask your supervisor or Privacy Officer. There is no penalty for over-reporting. There is significant penalty for under-reporting.