azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sync: auto-sync from HOWARD-HOME at 2026-06-29 16:55:22

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-29 16:55:22
This commit is contained in:
Howard Enos
2026-06-29 16:55:55 -07:00
parent e692bff2bc
commit 31f2bdb84f
9 changed files with 1271 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
.claude/memory/reference_alis_medtelligent.md Normal file
View File

@@ -0,0 +1,37 @@
---
name: reference_alis_medtelligent
description: ALIS (Medtelligent assisted-living EHR) API + staff-import facts for Cascades Tucson — auth quirk, read-only staff, web-UI import path. Use the `alis` skill.
metadata:
type: reference
---
ALIS = Medtelligent's assisted-living EHR (Cascades of Tucson client). All API traffic
goes to the shared host **`api.alisonline.com`** (the tenant URL `cascadestucson.alisonline.com`
is just the login subdomain), scoped by the user's company + a `communityId`. **Cascades =
communityId 622** (the only community this credential sees). Use the **`alis` skill** — don't
hand-roll the API.
**Auth (verified live 2026-06-29):** `POST /user/tokens` with `{username, password}` → JWT
(`accessToken` ~1h) + `refreshToken`; send `Authorization: Bearer <accessToken>`. The
**username MUST be tenant-qualified**: `howard.enos@cascadestucson` works; bare `howard.enos`
returns HTTP 400. Login creds in vault: `clients/cascades-tucson/alis-api-howard-user`
(Howard's password was exposed in chat 2026-06-29 — flagged to rotate). Other ALIS vault
entries: `alis-api-microsoft-basic` (BasicAuth used by Microsoft), `alis-sso-app-registration`.
Global API security is OR(Bearer|BasicAuth|VendorKey) — a user JWT alone authorizes reads.
**Staff are READ-ONLY via the API** — only GET endpoints exist (`/v1/integration/staff?communityId=622`
etc.); no create/update/delete. **To create/change staff (and their logins) you upload a
13-column .xls in the ALIS web UI: Staff → Import.** That import sets Login Enabled + Password,
so it's also how staff logins are provisioned. The `alis` skill builds that workbook from a
CSV/JSON and infers each new hire's Security Roles from how existing staff of the same Job Role
are set up (job-role → security-role map learned from live data; 23 real security roles, Job
Role is free text). The API *does* allow writes for residents/prospects/billing (not staff).
**Import format (confirmed from a real ALIS export, ALIS_Staff_Update_Import.xls):** two layouts.
CREATE (new staff) has a Password column + NO ALIS ID — rows without an ALIS ID are created.
UPDATE (existing staff) leads with **ALIS ID** (the staffId, the match key) + no Password. So
present-ALIS-ID = update, absent = create. **Dates are MM/DD/YYYY.** Security Roles are
comma-separated multi-values; the `alis` skill infers the full typical combo per job role from
current staff. Still test ONE row first before a bulk run.
Related: [[reference_resource_map]], [[feedback-vault-every-credential]].