For Alaska clinics, tribal health & behavioral health organizations
Alaska healthcare runs long referral chains, itinerant providers, and administrative load that pulls clinical staff away from patients. We build agents for the paperwork, we require a signed business associate agreement before touching protected health information, and we stay out of clinical decisions entirely.
Built in Anchorage · we publish our source code · no long-term lock-in
Written by Kristian Baer, Northtek · Anchorage, Alaska · Updated 2026-08-21
The short answer
On the administrative side of care, under a signed business associate agreement, and nowhere near a clinical decision. The highest-value targets are referral intake completeness, prior authorization packet assembly, recall and no-show outreach, and credentialing document chase. All four are repetitive, rule-bound, and currently performed by staff who are scarce in Alaska and expensive to replace. The boundary that matters is that protected health information does not go anywhere without a signed BAA and an architecture that supports it, which frequently means running inside your own tenant rather than on a general-purpose service. Any vendor willing to skip that conversation is a vendor whose contract you should read very carefully.
The operating reality
Care in Alaska often means a referral chain from a village clinic to a regional hub to Anchorage, coordinated by people who are also doing three other jobs.
A referral from a village clinic to a specialist in Anchorage passes through multiple hands. An incomplete packet does not cause a delay of days, it can cost a patient an entire travel cycle.
The people best equipped to assemble a clinical justification are the people you least want doing paperwork. It is the most common complaint we hear and one of the most automatable.
Recruiting and retaining administrative staff in Alaska is difficult and expensive. Reducing the administrative load is often more achievable than filling the position.
When a specialist visits a community once a quarter, a no-show is not a rescheduled appointment, it is a three-month delay. Recall outreach matters more here than almost anywhere.
Six workflows we build
Administrative only. Nothing on this list touches diagnosis, treatment, or triage of clinical acuity.
01
02
03
04
05
06
First 30 days
It is the workflow where administrative burden most directly converts into less patient care, and the payer criteria are documented, which makes it automatable.
Nothing touches protected health information before a signed BAA and an architecture that supports it. If your environment cannot support one, we will tell you what would need to change before we quote the work.
We build against authorizations you have already submitted, including denials, so we can measure whether the assembled packet matches what was actually approved.
Every packet is reviewed and signed by clinical staff before submission. The agent assembles and drafts. A clinician approves, always.
What you own at day 30
A prior authorization assembly agent inside your compliant environment, an executed BAA, a measured comparison against your own historical submissions, the repository and configuration, and a written scope stating that no clinical decision is automated.
What we built, in the open
The fast way to build clinical tooling is to put a chart in front of a general-purpose model and let it write. That is also how a summary acquires a finding no note contains. Refusing that shortcut requires infrastructure, not just a policy, so we built it.
A verification gate that requires every statement in a generated summary to be supported by a specific note, and reports where the record is silent rather than inferring. We publish how often it lets an unsupported statement through.
Our own memory server, including an offline mode. It is why protected health information can stay inside an environment that supports a business associate agreement instead of transiting a service that was never authorized to hold it.
A language built so an agent's steps are auditable - the property your compliance officer will ask about, and the one most tools cannot demonstrate.
Published with commit history. A vendor telling you their system does not hallucinate is telling you they have not measured it.
Scope, stated up front
The boundaries here are not preferences, they are the reason the rest of it is safe to deploy. Three of them, in the scope document.
No clinical decision support
No diagnosis, no treatment recommendation, no acuity triage. Those are regulated activities and we do not build them, regardless of how the request is framed.
No PHI without a signed BAA
Protected health information moves only inside an architecture that supports a business associate agreement. When an off-the-shelf tool cannot meet that bar, we build one that does rather than routing your PHI through something that was never authorized to hold it.
It does not fix a broken schedule
If your no-show rate is driven by transportation or cost rather than reminders, outreach will not move it. We will tell you when the real problem is not a communication problem.
Where your data goes
Protected health information sets the architecture, and the architecture comes before the feature list. Five commitments, in the agreement.
Compliance is a property of the whole arrangement, not a badge on a tool, so the honest answer is that we build architectures that support your compliance program. That means an executed BAA, PHI confined to an environment that supports it, access logging, minimum necessary access, and a named boundary for what the system may touch. Any vendor who answers this question with a single word has not read your obligations.
No, and we decline that work. It assembles documentation, drafts administrative narratives from what the chart already states, and routes clinical questions to clinicians. Every output is reviewed by a person before it leaves your organization. That boundary is written into the scope document, not just implied.
Through the interfaces they expose, yes. In practice much of the value sits alongside the electronic health record rather than inside it, because the burden lives in payer portals, fax queues, and referral packets rather than in the chart itself.
It adds a governance layer. Tribal data policies and agreements govern where records may reside and who may access them, and those requirements come before ours. See the Alaska Native corporations playbook and the tribal governments playbook for how we handle data sovereignty.
The administrative workflows apply directly - intake completeness, authorization, recall, credentialing. The confidentiality bar is higher, particularly for substance use disorder records under 42 CFR Part 2, and we scope those constraints explicitly before building rather than treating them as a variant of HIPAA.
Overflow handling is usually the fastest visible win, and it is also where we are most careful. Scheduling logistics, hours, directions, and forms can be handled automatically. Anything clinical or urgent goes to a person immediately, without the system attempting an answer first, because the failure mode there is not an inconvenience.
We will map exactly what your environment can support, then build the architecture that makes the rest of it possible. Sixty minutes, no cost, and you leave with the compliance picture in writing.
Anchorage, Alaska · info@northtek.io · (907) 903-4353