How Scoring Works
| Metric | What It Measures | How It's Calculated |
|---|---|---|
| Score (0-10) | Movement quality | min() of 3s and 5s window scores. Each window: slide through data, find best q-diff range, map to 0–10 via knot curve. Capped at 7 unless 7s data exists (see 7s Bonus below). |
| Q-Diff | Raw quaternion rotation range | The q_diff_range from each window (max−min of q-diff values in best window). Explorer shows QD 3s, QD 5s, and QD 7s columns. |
| Risk | Clinical risk level | From worst score across all 4 test types: Critical <4, High 4–6, Moderate 6–8, Low ≥8 |
| Stability % | How still overall | % of all data samples where q-diff < 0.005 threshold. Uses the entire test, not just a window. |
| Max Duration | Longest stable stretch | Longest continuous run of samples below threshold (in seconds). |
Why Score and Stability Can Differ
Score and stability measure different things:
- Score = best window's q-diff range (peak-to-valley), mapped through a curve. It asks: "In your best stretch, how much did you move?"
- Stability % = fraction of all samples below threshold. It asks: "Across the whole test, how often were you still?"
A patient can be stable 95% of the time (high stability) but have one brief spike in their best window (lower score). Or they can have a very calm 7s window (high score) but be shaky for the rest of the test (low stability).
Note: The base score uses min() of 3s and 5s window scores. The 7s window is used separately for the bonus cap (see below).
Test Types
lbeo | Left Balance Eyes Open |
rbeo | Right Balance Eyes Open |
lbec | Left Balance Eyes Closed |
rbec | Right Balance Eyes Closed |
Balance/Difference
Absolute difference between average left scores and average right scores. Highlights asymmetry between sides.
Color: <1 green, 1–3 yellow, >3 red
Duration Penalty
Short tests are penalized:
- Only 3s window exists (no 5s) → subtract 3 points
7-Second Bonus
Maximum score is capped at 7 unless the test has 7-second q-diff data. If 7s data exists, the cap is raised based on the q-diff range:
| 7s Q-Diff Range | Max Score |
|---|---|
| ≤ 0.0015 | 10 |
| 0.0015 – 0.002 | 9 |
| 0.002 – 0.003 | 8 |
| > 0.003 or no 7s data | 7 |
Fatigue Patterns
| fatigues | Good short-term (≥7) but drops >3 by 7s |
| consistent | Good short-term (≥7) and stays within 3 |
| unstable | Poor short-term (<7) with small drop |
| declining | Poor short-term (<7) and drops >2 |
Multi-Practice Architecture
Kinometric uses practice-level PHI isolation. Each practice (clinic/organization) is a separate data boundary with its own patients, test results, and questionnaire data.
Data Model
| Table | Purpose |
|---|---|
practices | Practice/clinic records. Each can have its own athenaOne API credentials. |
user_practices | Many-to-many: users belong to 1+ practices with a role (admin, clinician, readonly). |
patients.practice_id | Every patient belongs to exactly one practice. |
test_results.practice_id | Every test result scoped to one practice. |
questions.practice_id | Every questionnaire scoped to one practice. |
Roles
| admin | Full access: manage users, providers, patients, view all data within practice |
| clinician | Standard access: manage patients, run tests, view results |
| readonly | View-only: can see patients and results but cannot modify |
| superadmin | Cross-practice access (is_admin=true). Bypasses all filters. |
Patient Types
| Athena Patient | Linked to athenaOne EMR via athena_patient_id. PDF upload to EMR available. |
| Non-Athena Patient | Standalone in Kinometric. Same test/score/PDF workflow. No EMR upload. Used for test/demo or practices without EMR. |
How Isolation Works
- Every API request resolves an active practice: explicit
active_practice_idparam → session → user's default → first membership addPracticeFilter()appendsAND practice_id = :idto all PHI queries- New patients, tests, and questions are stamped with the active
practice_id - 31 PHP endpoints enforce practice scoping via
practice_filter.php - Superadmins bypass all filters for administrative oversight
Patient Search
| ID | First Name | Last Name | Patient ID |
|---|
Patient Rankings
0 patients
Loading rankings...
| Name ▲ | Last Test ▲ | Best ▲ | Worst ▲ | Bal/Diff ▲ | Max Dur ▲ | Q-Diff ▲ | Risk ▲ | AI |
|---|
Risk Explorer
0 patients
Loading data...
| Name ▲ | Last Test ▲ | Best ▲ | Worst ▲ | Bal/Diff ▲ | Max Dur ▲ | QD 3s ▲ | QD 5s ▲ | QD 7s ▲ | Stability ▲ | Risk ▲ | AI |
|---|
Parameter Tuning Guide
click to expand
This tool lets you experiment with how balance scores are calculated without affecting production data. Adjust parameters, re-analyze all ~800 CSV files, and see how score distributions change.
The scoring curve maps q-diff range (sensor movement variability) to a raw score (0-10). Lower q-diff = more stable = higher score.
- Drag points on the chart to adjust the curve visually
- Edit exact values in the knot table below the chart
- Add/remove points to change curve complexity
- Between points, scores are linearly interpolated
- Values outside the curve range are clamped to the nearest endpoint
Production uses 6 knot points. Fewer points = smoother curve, more points = finer control.
After the curve produces a raw score, the rescale function maps it to the final 0-10 range. This controls score distribution shape.
- Linear (default) — even spread between low and high bounds
- Power — power >1 compresses high scores, <1 compresses low scores
- Sigmoid — S-curve that clusters scores near the midpoint
- Exponential — emphasizes differences at the high end
- None — use raw score directly (no rescaling)
Low/High Bounds define the raw score range that maps to 0-10. Scores outside bounds are clamped.
- Start Row — skip initial sensor samples (warmup period). Default 200 (~2 seconds at 100Hz)
- Stable Threshold — q-diff below this is considered perfectly stable. Lower = stricter
- Outlier Percentile — use this percentile of q-diff to ignore spikes. 98 = ignore top 2%
- Aggregation — how to combine multiple time windows into one score: Min (worst window, strictest), Max (best window, most lenient), Mean, or Median
- Target Windows — time windows in seconds to analyze. Each window is scored independently, then aggregated
Production defaults: start=200, threshold=0.02, percentile=98, aggregation=min, windows=3,5,7
- Save/Load presets to keep parameter configurations you want to compare
- Import/Export as JSON files to share configurations
- Run Analysis processes all ~800 cached CSV files (~40 seconds)
- Score Calculator lets you test a single q-diff value against current settings instantly
- Rebuild Cache re-extracts data from CSV files (only needed if new test files are added)
Typical workflow: load production preset, adjust one parameter, run analysis, compare distributions. Nothing writes to the database.
Scoring Curve (drag points to adjust)
| Point | Q-diff Range (X) | Raw Score (Y) | Final Score | Tests in Range | Target |
|---|
Score Calculator
Raw: -
Rescaled: -
Scoring Mode
Score from q-diff range across windows
Score from longest stable stretch. Map seconds to 0-10 score.
Duration Penalty
Penalty subtracted from score when test recording is too short for all analysis windows. Set to 0 to disable.
0 penalized
Rescale Function
Analysis Parameters
Patient Summary
| Patient | Overall | Left Q-diff | Right Q-diff | LBEO | RBEO | LBEC | RBEC |
|---|
Score Distribution
0 files
Individual Results
| File ▲ | Patient ▲ | Type ▲ | Date ▲ | Score ▼ | Risk ▲ | 3s ▲ | 5s ▲ | 7s ▲ | Worst Q-diff ▲ | Worst Bal ▲ | Stable% ▲ | Penalty ▲ |
|---|
Running analysis...
Patients in Range
0| Name | Type | Date | Score | Risk | Worst Q-diff | 3s | 5s | 7s | Stable% | Penalty |
|---|
Connection Health
API Ping
Unknown
Token
Unknown
Environment
Unknown
Practice ID
Unknown
athenaOne Developer Portal
— view app settings, API logs, and uploaded documents in the sandbox patient chart.
Patient Verification
| Name | Real ID |
|---|
Kinometric
-
athenaOne
-
Upload Test
Documents in Chart
| ID | Note | Date | Status | |
|---|---|---|---|---|
| Verify a patient to see documents | ||||
To view/download uploaded PDFs, open the patient chart in the
athenaOne portal.
Department Browser
click to expand
| ID | Name | Address | Phone | State |
|---|---|---|---|---|
| Loading... | ||||
Upload Log
click to expand
No log loaded yet.
User Accounts
| ID | Username | Admin | 2FA | Provider | Actions | |
|---|---|---|---|---|---|---|
| Loading... | ||||||
Add User
Reset Password —
Patients
| ID | First Name | Last Name | Patient ID | Actions |
|---|---|---|---|---|
| Loading... | ||||
Add Patient
Kinometric Video
Security & HIPAA Compliance
Server-side security controls protecting credentials, config files, and infrastructure.
Loading audit...
Authentication mechanisms and access control for API and web interfaces.
athenaOne integration security — OAuth, data flow, input validation, and access controls.
HIPAA Security Rule compliance checklist with specific CFR references. Last audited: February 2026.
Operational Readiness — Production Athena Go-Live Gates
The HIPAA Security Rule checklist below shows policy & technical controls as Done. The items here are operational pre-conditions documented in the Incident Response Plan that must be cleared before production athena go-live. Source of truth: docs/incident_response_plan.md §2 NEEDS VERIFICATION callout, §9, and §12.
| Gate | What's missing | Status | Evidence |
|---|---|---|---|
| Practice BAA Critical | No executed BAA with the deploying practice (Pain and Spine Specialists of MD). IRP §9 commits Kinometric to BA→CE breach notification within 24h, but that timeline is unenforceable without a signed BAA — the practice could deny the BA relationship entirely. Hard go-live gate: no production PHI flows before executed BAA. Surfaced as Finding 9 in tabletop_record_2026-05-23.md. (Distinct from the Linode/Akamai cloud BAA, which is tracked separately below.) | Pending | |
| Managing Member contact | Steve Johnson: steve@kinometric.com / (41) 599-4425 confirmed 2026-05-22. Open: area code appears truncated — verify "(41)" should be "(410)" or similar; backup contact not yet provided. | Partial | |
| First tabletop exercise | Completed 2026-05-23 — record: docs/tabletop_record_2026-05-23.md. 18 findings; 2 mitigated during the exercise, 16 in the pre-go-live backlog. Procedural note: solo-SO chat format; a second exercise with full §12 quorum is recommended before go-live but the §12 production gate is satisfied by the existing record. | Done |
When all gates are cleared, this card can be removed (or kept as a historical "Pre-Production Readiness" log).
Administrative Safeguards (45 CFR 164.308)
| Requirement | CFR | Implementation | Status | Evidence |
|---|---|---|---|---|
| Risk Analysis | §308(a)(1)(ii)(A) | Annual risk assessment covering all PHI, threats, and safeguards | Done | |
| Risk Management | §308(a)(1)(ii)(B) | Controls implemented per risk assessment findings; gap remediation tracked | Done | |
| Sanction Policy | §308(a)(1)(ii)(C) | Confidentiality agreement includes consequences for violation (termination, penalties) | Done | |
| Information System Activity Review | §308(a)(1)(ii)(D) | HIPAA audit log reviewed; monthly manual audit + automated detection cron every 30 min (R1/R2/R3/R7 rules → dev@kinometric.com) | Done | |
| Security Officer | §308(a)(2) | Anant Johnson designated HIPAA Security Officer (effective 2026-05-20) | Done | |
| Workforce Security | §308(a)(3) | Multi-practice isolation via practice_filter.php. Roles: admin, clinician, readonly per practice. Superadmin bypasses for oversight. 31 endpoints enforced. | Done | |
| Access Management | §308(a)(4) | 3 active users, unique accounts, no shared credentials, admin-managed | Done | |
| Security Awareness Training | §308(a)(5) | Confidentiality agreement signed before access; 6-module training program and materials (slide decks) developed; mandatory workforce rollout in progress | In Progress | |
| Security Incident Procedures | §308(a)(6) + §§164.400-414 | Incident Response Plan v1.0 (docs/incident_response_plan.md): roles, detection sources, severity levels, notification matrix (individual/urgent/substitute), Appendix A/D/F templates, Appendix E logs | Done | |
| Contingency Plan | §308(a)(7) | Written backup policy (BACKUP_PLAN.md r6); automated nightly restic backups to a local repo + off-site NAS over WireGuard VPN; integrity-checked (restic check); restic restore drilled & verified end-to-end 2026-05-20, plus the 2026-05-11 migration restore | Done | |
| Evaluation | §308(a)(8) | Annual risk assessment; automated security audits; 225 automated API tests + 75 Python unit tests | Done | |
| Business Associate Agreements — cloud provider | §308(b)(1) | Linode/Akamai BAA in progress (ticket 26375232). AI analysis feature disabled in production — no Anthropic BAA needed. | In Progress | |
| Business Associate Agreement — deploying practice | §308(b)(1) | Practice BAA with Pain and Spine Specialists of MD not yet executed. IRP §9 BA→CE notification timeline is contractually unenforceable without it. Hard production-gating item — no production PHI flows before signed BAA. See tabletop record 2026-05-23, Finding 9. | Not Started |
Physical Safeguards (45 CFR 164.310)
| Requirement | CFR | Implementation | Status | Evidence |
|---|---|---|---|---|
| Facility Access Controls | §310(a)(1) | Hosted in Linode/Akamai data center (SOC 2 certified, physical access controls) | Done | |
| Workstation Use | §310(b) | SSH key authentication only; no shared accounts; UFW firewall | Done | |
| Workstation Security | §310(c) | Server: SSH/HTTP/HTTPS only (UFW). No physical access except via Linode. | Done | |
| Device & Media Controls | §310(d) | No PHI cached on mobile devices (in-memory only); CSV files server-side; patient delete cascades to files | Done |
Technical Safeguards (45 CFR 164.312)
| Requirement | CFR | Implementation | Status | Evidence |
|---|---|---|---|---|
| Unique User Identification | §312(a)(2)(i) | Each user has unique username + user_id; no shared accounts | Done | |
| Emergency Access | §312(a)(2)(ii) | Superadmin account + direct database access available | Done | |
| Automatic Logoff | §312(a)(2)(iii) | 15-minute idle timeout: PHP server-side + JS client-side | Done | |
| Encryption at Rest | §312(a)(2)(iv) | Server disk encrypted at rest (Linode Disk Encryption, AES-256); backups encrypted client-side with restic (AES-256) | Done | |
| Audit Controls | §312(b) | HIPAA audit log (JSON, who/what/when/IP); auth logs; error logs; auto-pruned | Done | |
| Integrity Controls | §312(c)(1) | Parameterized SQL, input validation, base64 validation, path traversal prevention | Done | |
| Authentication | §312(d) | bcrypt password hashing; 64-char random session tokens; per-request verification | Done | |
| Transmission Security | §312(e)(1) | TLS 1.2/1.3 on all connections; HTTPS enforced; OAuth2 for athenaOne | Done |
Organizational & Policy Requirements
| Requirement | CFR | Implementation | Status | Evidence |
|---|---|---|---|---|
| Risk Assessment Document | §308(a)(1) | PHI inventory, 14 threats rated, safeguard checklist, gap analysis | Done | |
| Breach Response Plan | §308(a)(6) + §§164.400-414 | Incident Response Plan v1.0 — full notification matrix, urgent & substitute notice procedures, address-of-record workflow, automated detection | Done | |
| Staff Confidentiality Agreement | §308(a)(3) | PHI handling, device security, reporting obligations, consequences; signed before access | Done | |
| Password Policy | §312(d) | 8+ chars, uppercase + lowercase + number, cannot match username; enforced on all entry points | Done | |
| Backup & Recovery | §308(a)(7) | Nightly restic backup (pg_dump + CSV + logs + secrets, client-side AES-256) → local repo + off-site NAS over WireGuard VPN. HIPAA retention (14d/8w/24m/7yr). Integrity-checked nightly (restic check); restic restore drilled end-to-end and verified 2026-05-20. | Done | |
| Data Disposal | §310(d)(2) | Patient delete cascades to test_results, questions (FK), and CSV files on disk | Done | |
| Email PHI Protection | §312(e)(1) | Email-PDF retired for real patients 2026-05-20; re-enabled 2026-05-21 for synthetic test-fixture patients only — no real patient PHI is emailed | Done | |
| API Key Management | §312(a)(1) | Keys in /etc/ with 640 permissions; excluded from git; rotated Feb 2026 | Done |
Open Items
| Item | Description | Status | Target |
|---|---|---|---|
| BAA — Linode/Akamai | BAA requested (ticket 26375232), business info submitted. Awaiting agreement from Linode. | In Progress | Q2 2026 |
| Server Disk Encryption | Linode Disk Encryption (AES-256) enabled on the production instance | Done | 2026-05-20 |
| 2FA for Admin Accounts | TOTP 2FA built end-to-end (web + mobile, trusted devices, backup codes, encrypted secrets); enrollment campaign and enforcement (Phase 3) still pending | In Progress | Q2 2026 |
| Security Officer Designation | Anant Johnson designated as HIPAA Security Officer | Done | 2026-05-20 |
| Formal Training Program | 6-module curriculum and training materials (slide decks) developed; mandatory workforce completion and tracking in progress | In Progress | Q2 2026 |
| Run tmp_secure.sh | Server hardening script (8 sections): requires sudo bash tmp_secure.sh | Pending | Q1 2026 |
Compliance Documents
| # | Document | Description | Date | Path |
|---|---|---|---|---|
| HIPAA Policy Documents | ||||
| 1 | Risk Assessment | PHI inventory, 14 threats analyzed, safeguard checklist, gap analysis with remediation targets | Feb 2026 | |
| 2 | Incident Response Plan | v1.0 — roles, detection (manual + automated cron), notification matrix (individual/urgent/substitute), Appendices A/D/E/F (letter, web notice, logs, phone scripts) | May 2026 | |
| 3 | Staff Confidentiality Agreement | Workforce agreement: PHI rules, device security, reporting obligations, consequences. Sign before access. | Feb 2026 | |
| athenaOne Integration | ||||
| 4 | API Technical Specification | Full athenahealth submission document: security questions, 5 use cases, workflow, API summary, compliance | Feb 2026 | |
| 5 | Validation Plan | 5-phase go-live plan: sandbox testing (11 cases), tech spec submission, production credentials, validation, go-live | Feb 2026 | |
| 6 | Workflow Graphic Prompt | Mermaid diagram + ChatGPT prompt for generating polished architecture diagram for tech spec | Feb 2026 | |
| 7 | App Upload Button Spec | Implementation spec for Flutter Athena upload: endpoint, request/response, guard rails, error handling | Feb 2026 | |
| 8 | App Upload Field Mapping | Field-by-field mapping: FFAppState → JSON request body, pattern to follow (same as Email PDF) | Feb 2026 | |
| Infrastructure | ||||
| 9 | Backup Script | systemd-timed nightly restic backup (DB + CSV + logs + secrets, AES-256) to a local repo + off-site NAS over WireGuard VPN; nightly integrity check; HIPAA retention. | May 2026 | _backup/runner/backup_kinometric.sh |
| 10 | Password Policy | Shared PHP validation: 8+ chars, upper+lower+number, no username match. Enforced on all 3 entry points. | Feb 2026 | password_policy.php |
| 11 | Session Timeout | 15-min idle timeout (PHP server-side + JS client-side). Shared include for 12 legacy pages + SPA. | Feb 2026 | session_timeout.php |
| 12 | Patient Data Cleanup | Cascade delete: FK on questions, CSV file deletion on patient remove. All 3 delete handlers updated. | Feb 2026 | patient_cleanup.php |
| 13 | Server Hardening Script | 8-section hardening: tmp permissions, log rotation, file permissions, firewall verification. Requires sudo. | Feb 2026 | tmp_secure.sh |
| Multi-Practice System | ||||
| 14 | Practice Filter Module | Core multi-practice PHI isolation: getUserPractices, getActivePracticeId, addPracticeFilter, canAccessPatient, canAccessTest, isSuperAdmin. 31 endpoints enforced. | Feb 2026 | practice_filter.php |
| 15 | Migration Script | Creates practices + user_practices tables, adds practice_id to patients/test_results/questions, migrates all data, enforces NOT NULL. | Feb 2026 | |
| 16 | athenaOne Tech Spec (Updated) | Updated with multi-practice data model, per-practice Athena credentials, non-Athena patient support. | Feb 2026 | |
Audit Trail: This checklist is maintained in source control. Policy documents are in
/var/www/kinometric/docs/.
Automated tests: 283/283 API + 75/75 Python passing. Multi-practice isolation: 31 endpoints enforced. Last audit: February 19, 2026.
Document
Android app security — HIPAA-compliant data handling, authentication, and device protection.
1. Data Protection
Encryption in Transit
| Protocol | Details | Status |
|---|---|---|
| TLS Version | TLS 1.2 and TLS 1.3 supported | Active |
| Cipher Suites | AES-256-GCM, ChaCha20-Poly1305 | Active |
| Key Exchange | ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) | Active |
| Certificate | 2048-bit RSA with SHA-256 signature | Active |
Encryption at Rest (Device)
| Storage Type | Encryption Method | Status |
|---|---|---|
| Login Credentials | AES-256 via Android EncryptedSharedPreferences (FlutterSecureStorage) | Active |
| Session Tokens | Hardware-backed secure storage (Android Keystore) | Active |
| Test Data Files | App-level AES-256-CBC — CSV encrypted on test-stop, decrypted only for upload, then deleted; Android File-Based Encryption underneath | Active |
| Cached Data | Encrypted application sandbox | Active |
Data Minimization
| Data Type | What We Collect | What We DON'T Collect |
|---|---|---|
| Patient Identity | Internal ID number only | Full SSN, insurance numbers |
| Test Results | Balance measurements, timestamps | GPS location, device identifiers |
| File Names | Anonymized ID {id}-{type}-{d}-{m}-{y}.csv | Patient name, DOB in filename |
| Error Logs | Technical errors only | Patient data, test results |
2. Authentication & Access Control
Password Authentication
| Feature | Implementation | Status |
|---|---|---|
| Transmission | Passwords sent over TLS, never in plain text | Active |
| Server Storage | bcrypt hashed with unique salt per user | Active |
| Password Policy | Minimum 8 characters, requires uppercase + lowercase + number, cannot match username | Active |
| Session Tokens | 64-char hex key regenerated on each login, invalidates previous | Active |
| Practice Isolation | practice_filter.php multi-practice PHI isolation (31 endpoints). Roles: admin, clinician, readonly per practice. | Active |
Biometric Authentication
| Platform | Technology | Security Level | Status |
|---|---|---|---|
| iOS | Not supported — Kinometric ships an Android app only | — | Not Supported |
| Android | Fingerprint / Face Unlock via BiometricPrompt API; PIN/pattern fallback (biometricOnly: false) | TEE (Trusted Execution Environment); credentials in Android Keystore via FlutterSecureStorage | Active |
How biometric login works: On first login, authenticate with username/password. If biometric is enabled, encrypted credentials are stored in the device's secure hardware. Subsequent logins use fingerprint/face to unlock the secure storage. Your biometric data never leaves your device.
Session Security
| Feature | Setting | Purpose | Status |
|---|---|---|---|
| Inactivity Timeout | 15 minutes | Locks session after no user activity | Active |
| Activity Detection | Touch, pointer movement | Resets timeout on any interaction | Active |
| Session Lock | Requires re-authentication | Biometric or PIN/pattern to resume | Active |
| Token Expiration | Server-enforced | New key on each login invalidates previous | Active |
Role-Based Access (Multi-Practice)
| Role | Scope | Capabilities |
|---|---|---|
| readonly | Single practice | View patients and results within practice (no modifications) |
| clinician | Single practice | Manage patients, run tests, view results within practice |
| admin | Practice management | User management, audit logs, all patients in practice |
| superadmin | Cross-practice | All patients across all practices. Security dashboard, infrastructure. |
Multi-practice: Users can belong to multiple practices with different roles in each. A user might be admin in one practice and clinician in another. The active practice determines which data is visible.
3. Application Security
Tamper Protection
| Check | What It Detects | Action Taken | Status |
|---|---|---|---|
| Debug Mode Detection | App running in development mode (kDebugMode) | Warning logged, restricted in production | Active |
| Jailbreak/Root Detection | Compromised device OS — su binaries, test-keys build tags, Magisk/SuperSU packages | User warned, may restrict PHI access | Active |
| App Signature Verification (runtime) | Repackaged / re-signed APK installed via sideloading | App computes SHA-256 of its signing certificate and compares it to the expected hash; blocks execution if invalid. The expected hash (EXPECTED_SIGNATURE_HASH) must be populated from the first signed release build — logs-and-passes until then. (Install-time APK signing is already enforced by Android.) | Pending Config |
| Debugger Detection | Attached debugging tools (Debug.isDebuggerConnected()) | Prevents runtime inspection | Active |
| No Hardcoded Credentials | Secrets in source code | Dev backdoor removed, REST API replaces SFTP | Active |
Code Protection
| Technique | Tool | Purpose | Status |
|---|---|---|---|
| Code Shrinking | R8/ProGuard | Removes unused code, reduces attack surface | Active |
| Obfuscation | R8/ProGuard | Renames classes/methods to meaningless names | Active |
| Dart Obfuscation | Flutter --obfuscate | Obfuscates Dart/Flutter code — wired into the release deploy command, applied on every build | Active |
| Debug Symbol Removal | --split-debug-info | Strips debug symbols from the release build; symbols archived server-side per version for later flutter symbolize of crash reports | Active |
OWASP Mobile Top 10 Coverage
| Risk | Mitigation |
|---|---|
| M1: Improper Platform Usage | Proper use of the Android Keystore and platform security APIs |
| M2: Insecure Data Storage | Encrypted storage, no sensitive data in logs |
| M3: Insecure Communication | TLS 1.2+, certificate validation |
| M4: Insecure Authentication | Biometrics, session timeout, strong passwords |
| M5: Insufficient Cryptography | AES-256, industry-standard algorithms |
| M6: Insecure Authorization | Server-side access control, role-based access |
| M7: Client Code Quality | Code review, static analysis, testing |
| M8: Code Tampering | Integrity checks, obfuscation, signature verification |
| M9: Reverse Engineering | Obfuscation, no hardcoded secrets |
| M10: Extraneous Functionality | No debug endpoints in production |
4. Privacy by Design
Anonymization
| Data Element | Privacy Approach |
|---|---|
| File Names | Internal ID instead of patient name (e.g., 437-lb-eo-16-2-2026.csv) |
| Internal IDs | System-generated numbers, not SSN or MRN |
| Test Results | Associated with internal ID only, no PII in data files |
| Error Logs | Scrubbed of all patient identifiers before collection |
| Crash Reports | Technical data only, no PHI included |
Data Retention
| Data Type | Retention Period | Deletion Method |
|---|---|---|
| Test Results | Per practice policy (typically 7 years) | Secure overwrite |
| Audit Logs | 6 years minimum (HIPAA requirement) | Archived, then destroyed |
| Session Data | Until logout or timeout | Memory cleared |
| Local Test Files | Deleted after successful upload | Secure file deletion |
Third-Party Data Sharing
| Vendor | Data Shared | BAA Required |
|---|---|---|
| Anthropic (AI Analysis) | None — feature disabled in production deployment | No |
| athenaOne (EHR) | PDF reports via authenticated API | Yes |
| Microsoft Graph (Email) | Backup-failure alerts only — no PHI | No |
| Hosting Provider | Server infrastructure | Yes |
5. Technical Summary (IT/Compliance)
Mobile Application Security Features (Android)
| Feature | Android |
|---|---|
| Biometric Auth | BiometricPrompt API |
| Secure Storage | EncryptedSharedPreferences (AES-256-GCM) |
| Session Timeout | 15-min inactivity timeout with touch event monitoring |
| Code Obfuscation | ProGuard/R8 and Dart --obfuscate, both applied on every release build |
| Certificate Validation | OkHttp with certificate transparency |
| Integrity Check | Release APKs are signed — Android verifies the signature at install time. Runtime root, debug-mode, and debugger detection active; signing-certificate self-check pending hash configuration |
| Network Security | Network Security Config (cleartext blocked) |
| Data at Rest | File-Based Encryption (FBE) |
Cryptographic Standards
| Purpose | Algorithm | Key Size | Standard |
|---|---|---|---|
| Data Encryption | AES-GCM | 256-bit | NIST SP 800-38D |
| Password Hashing | bcrypt | Cost factor 12 | OWASP recommendation |
| TLS | TLS 1.2/1.3 | ECDHE-256 | RFC 8446 |
| Random Generation | SecureRandom | N/A | Platform CSPRNG |
Compliance Standards
| Standard | Coverage | Notes |
|---|---|---|
| HIPAA Security Rule | Full | 45 CFR Part 164, all safeguards |
| HIPAA Privacy Rule | Full | 45 CFR Part 160 and 164 |
| HITECH Act | Full | Breach notification, penalties |
| NIST CSF | Aligned | Identify, Protect, Detect, Respond, Recover |
| OWASP MASVS | Level 2 | Mobile Application Security Verification |
| OWASP ASVS | Level 2 | Application Security Verification (API) |
Overall Security Status
| Security Feature | Technology | Compliance | Status |
|---|---|---|---|
| Encryption in transit | TLS 1.2/1.3 (HTTPS) | 164.312(e)(1) | Active |
| Encryption at rest (device) | Android Keystore | 164.312(a)(2)(iv) | Active |
| Encryption at rest (server) | Linode Disk Encryption (AES-256) | 164.312(a)(2)(iv) | Active |
| Authentication | bcrypt + 64-char tokens | 164.312(d) | Active |
| Access control | practice_filter.php (30+ endpoints) | 164.312(a)(1) | Active |
| Audit logging | JSON Lines (who/what/when/IP) | 164.312(b) | Active |
| Secure upload | REST API (back_upload_csv.php) | 164.312(e)(1) | Active |
| Input validation | Parameterized SQL, ID checks | OWASP Top 10 | Active |
| Biometric auth | Fingerprint / Face Unlock (BiometricPrompt) | 164.312(d) | Active |
| Session timeout | 15-min idle timeout (PHP + JS) | 164.312(a)(2)(iii) | Active |
| Tamper detection | Integrity + root/jailbreak | 164.312(c)(1) | Active |
| Code obfuscation | R8 + Flutter --obfuscate | Best Practice | Active |
| Firewall | ufw (22/80/443 only) | 164.312(e)(1) | Ready |
| DB localhost binding | PostgreSQL localhost only | 164.312(e)(1) | Ready |
Security questions: security@kinometric.com |
Vulnerability reports: security@kinometric.com |
BAA requests: legal@kinometric.com
Last updated: February 2026
Last updated: February 2026
HIPAA-required access audit log — every patient data access is recorded.
HIPAA Incident Response Plan — 45 CFR 164.308(a)(6) & 164.408
Training & Meeting Records
Tabletop Exercise — May 2026
Workforce Training Roster
Who must be on this roster?
Any of: (1) a system user with PHI access, (2) anyone who receives exported PHI (PDFs/CSVs),
(3) operators with infra/DB/backup access, (4) anyone listed on IRP §2 response team,
(5) Business Associate personnel with direct PHI access.
HIPAA workforce training is required annually for everyone listed;
tabletop training is additionally required for IRP §2 response team.
Active Workforce
| Name | Role & Rationale | Workforce HIPAA |
Tabletop IRP §2 |
Actions |
|---|---|---|---|---|
| Loading… | ||||
Deactivated workforce members (retained for HIPAA 6-yr audit)
| Name | Role | Deactivated | Reason | |
|---|---|---|---|---|
| — | ||||
Add Workforce Member
If they have a Kinometric login, link it so self-service attestation works.
Mark Training Complete
Upload the signed attestation PDF. Stored outside the web root and audit-logged.
Deactivate Workforce Member
Deactivate ? Training rows remain in the database for HIPAA's 6-year retention.
New Incident Report
Incident Log
No incidents reported. Use the button above to report a security incident.
Incident Response Process
HIPAA requires covered entities to identify, respond to, and mitigate security incidents. 45 CFR 164.308(a)(6)(ii)
Phase 1: Detection & Reporting
0-1 hours
- Identify the incident — unauthorized access, data breach, system compromise, credential leak
- Document immediately — what, when, who discovered, what systems/data affected
- Report — notify the Security Officer (Anant Johnson) and the Managing Member (Steve Johnson)
- Preserve evidence — do NOT delete logs, do NOT reboot servers. Screenshot/export the HIPAA audit log
- Check audit log — review
athena_hipaa_audit.logfor unauthorized patient access patterns
Phase 2: Containment
1-4 hours
- Isolate affected systems — disable compromised user accounts, revoke encryption keys
- Rotate credentials — Athena OAuth keys, DB password, API keys, user passwords
- Block access — update firewall, change SSH keys, disable unnecessary accounts
- Preserve the HIPAA audit log — copy
test/logs/athena_hipaa_audit.logto secure backup - Check Athena — review what patient data was accessed via the audit log
Phase 3: Investigation
1-7 days
- Determine scope — which patients' data was accessed? How many records?
- Run audit scripts:
php monthlyAuditScripts/security_audit.php
php monthlyAuditScripts/athena_access_audit.php - Review server logs — Apache access logs, auth logs, syslog
- Determine root cause — how did the breach occur?
- Assess if PHI was actually viewed/exfiltrated — breach vs. security incident
Phase 4: Notification
Within 60 days
HIPAA Breach Notification Rule — 45 CFR 164.400-414
- Determine if breach notification is required — was unsecured PHI accessed by unauthorized person?
- Notify affected individuals within 60 days of discovery (164.404)
- Notify HHS — if <500 individuals: annual report. If 500+: within 60 days (164.408)
- Notify media — if 500+ individuals in a single state (164.406)
- Notify Athena Health — as business associate, per BAA terms
Phase 5: Remediation & Documentation
Ongoing
Remediation:
- Fix the vulnerability that caused the incident
- Run full security audit to check for related issues
- Update security controls (firewall rules, access policies)
- Re-run credential rotation check
- Implement additional monitoring if needed
Documentation (retain 6 years — 164.530(j)):
- Incident report (date, description, scope)
- Investigation findings and root cause
- List of affected individuals
- Notifications sent (copies)
- Remediation actions taken
- HIPAA audit log exports for the incident period
Key Contacts
HHS Breach Portal: https://ocrportal.hhs.gov/ocr/breach/wizard_breach.jsf
Security Officer:
Anant Johnson
anant@johnsonconsultingllc.com
Anant Johnson
anant@johnsonconsultingllc.com
Managing Member:
Steve Johnson
rdksteve@gmail.com
Steve Johnson
rdksteve@gmail.com
Athena Contact:
Jake Millhausen
jake@johnsonconsultingllc.com
Jake Millhausen
jake@johnsonconsultingllc.com
Practice Contact:
Laura Cossick
lcossick@painandspinespecialists.com
Laura Cossick
lcossick@painandspinespecialists.com
HHS Breach Portal: https://ocrportal.hhs.gov/ocr/breach/wizard_breach.jsf
Tabletop exercise to test the Incident Response Plan. Required before production athena go-live (Plan §12), annually thereafter, and after any material Plan change. Completed records retained for 6 years per §164.316.
Status
Loading…
Exercise format (~1 hour)
- Quorum: Security/Privacy Officer, Managing Member, and at least one workforce member with PHI access.
- Facilitator presents the scenario (default: IR Plan §12 reference scenario — "athena audit log shows 50 patient lookups from an unfamiliar IP overnight").
- Team walks through the Plan: detection → triage → containment → investigation → notification → post-incident.
- Findings, ambiguities, and missing contacts are recorded.
- Exercise record written to
docs/tabletop_record_YYYY-MM-DD.md; the Operational Readiness gate flips to Done.
Materials
| Document | File | Action |
|---|---|---|
| Loading… | ||
Past exercise records
| Date | File | Action |
|---|---|---|
| Loading… | ||
Register completed exercise
Use this after the exercise has been run. It writes a stub record file to docs/ and flips the Operational Readiness gate. The detailed exercise notes are added to the record file manually using the template from tabletop_exercise_2026-05.md.
Security awareness training program for all workforce members handling PHI. Required by 45 CFR 164.308(a)(5).
Current Status
Partial
Staff confidentiality agreement is signed before access is granted. Formal recurring training program is proposed below.
Reference: docs/hipaa_staff_confidentiality.md —
Proposed Security Training Program
The following training modules address HIPAA Security Rule requirements. Each module should be completed by all workforce members upon hire and annually thereafter. Completion must be documented and retained for 6 years per 45 CFR 164.530(j).
| # | Module | Topics Covered | Duration | Frequency | CFR Reference |
|---|---|---|---|---|---|
| 1 | HIPAA Fundamentals |
|
30 min | Annual | §164.530(b) |
| 2 | Password & Authentication Security |
|
20 min | Annual | §164.308(a)(5)(ii)(D) |
| 3 | PHI Handling & Data Security |
|
20 min | Annual | §164.312(a)(1) |
| 4 | Mobile Device & App Security |
|
15 min | Annual | §164.310(d)(1) |
| 5 | Incident Reporting & Breach Response |
|
15 min | Annual | §164.308(a)(6) |
| 6 | Practice Isolation & Access Controls |
|
15 min | Annual | §164.312(a)(1) |
| Total Training Time | ~2 hours | ||||
Implementation Plan
| Phase | Target | Actions | Status |
|---|---|---|---|
| Phase 1: Foundation | Completed | Staff confidentiality agreement created and signed by all current users before access | Done |
| Phase 2: Program Design | Completed | Training materials (slide decks) developed for all 6 modules; completion tracker created (build_training_tracker_xlsx.py) |
Done |
| Phase 3: Initial Rollout | Q2 2026 | All current workforce members complete training; document completion dates; address any knowledge gaps | In Progress |
| Phase 4: Ongoing | Annual | Annual refresher training; update materials for new threats; train new hires within 30 days of access | Planned |
Workforce Training Status
| Name | Role | Confidentiality Agreement | Training Completed | Next Due | Status |
|---|---|---|---|---|---|
| steve | Admin | Signed | — | Q2 2026 | Agreement Only |
| Dan | User | Signed | — | Q2 2026 | Agreement Only |
| System Administrator | Superadmin | Signed | — | Q2 2026 | Agreement Only |
Policy: New workforce members must complete all 6 modules within 30 days of being granted PHI access. Annual refresher training is due on the anniversary of initial completion. Records retained for 6 years per 45 CFR 164.530(j).
Required Training Records
Per HIPAA, the following must be documented and retained for each training event:
- Date of training and modules completed
- Names of attendees and their roles
- Training materials used (version and content summary)
- Assessment results (if knowledge check is administered)
- Signature or electronic acknowledgment of completion
- Trainer name and qualifications
Centralized view of automated monitors and on-demand verification checks. Run a single check or fire the whole suite.
Card 1 — Continuous Monitors
Cron jobs and systemd timers running automatically. "Stuck" means the job hasn't run in 2.5× its expected interval.
Loading…
Card 2 — On-Demand Verification Suite
Click "Run" on any card to refresh it. Last-run timestamp is cached server-side.
Card 3 — Pen Test Scanners (Layer 1)
Automated security scanners. Run individually or kick off the whole layer with "Run All Pen Tests".
Deferred scanners (not yet wired)
- OWASP ZAP baseline — needs Docker (~500 MB install). Highest-signal active scan; defer until we decide on the install.
- nikto — apt install. Older signal, mostly low-value findings.
- semgrep (PHP/OWASP rulesets) — static analysis. Heavy, false-positive-prone for PHP. Better suited to manual code review than continuous scan.
- nmap external — Layer 2 work; runs from a separate host, not from the Kinometric server.
Card 4 — Quarterly Pen-Test Status
Cadence, scanner-box baseline, and reminder-cron health — the §164.308(a)(8) operational record.
Loading…
Generate a comprehensive HIPAA compliance report for auditors. Includes every safeguard requirement, implementation details, status, and evidence.
HIPAA Compliance Report
This report compiles all compliance details from the HIPAA checklist into a single downloadable document. It covers Administrative, Physical, and Technical Safeguards plus Organizational Policies — 32 line items total with specific implementation evidence for each.
Report Contents
- Cover Page — Title, date, prepared for/by, organization
- Executive Summary — Overall compliance posture, counts by status
- System Description — Architecture, PHI inventory, data flow
- Administrative Safeguards (45 CFR 164.308) — 12 requirements
- Physical Safeguards (45 CFR 164.310) — 4 requirements
- Technical Safeguards (45 CFR 164.312) — 8 requirements
- Organizational & Policy Requirements — 8 requirements
- Gap Analysis & Remediation Plan — Open items with target dates
- Document Inventory — All policy documents with descriptions
Executive Summary
Worst Score
Accelerometer Data (accMag)
Questionnaire Responses
Changes from Previous Test
Analysis
This analysis is AI-generated and intended to support clinical interpretation. It is not a standalone diagnosis and should not replace professional medical judgment.