Need Cross-Organizational Patient-Centered Data Flow Across Legal Silos
Iris sees the patient's data sit in adjacent organizations that legally cannot share it — region vs municipality, primary vs secondary purpose, country vs country — even though all of them care for the same person. She needs a patient-centered data fabric that the law can actually permit.
Take Control Of Your Signals — Become a Naftiko Design Partner Today!
Persona Story:
Iris works in a Swedish region where every hospital, GP, and even private provider runs the same EHR — so a patient’s record is continuous while they’re inside the region. The moment they go home, the municipality picks up the home-care responsibility, and the data wall slams down. The municipal nurse caring for a diabetic foot ulcer can’t see the wound history from the regional hospital. Different Swedish laws govern primary-purpose (treatment) vs secondary-purpose (research) data, and EHDS adds cross-border. Each organization sees a slice of the patient. The patient is the only point they share. Iris needs a data fabric architected around the patient and shaped to fit each legal boundary, not around the org chart.
Problem Context
- The data is digital and the data is there — what’s missing is permission to flow across organizational boundaries
- Different statutes govern primary-purpose vs secondary-purpose data use, with different consent and access rules
- Region/municipality, hospital/home-care, country/country are all separate legal silos with separate data acts
- Patient-centered care fundamentally requires the patient’s record to move with them; today it doesn’t
Problem Impact
- Chronic-condition patients (wounds, diabetes, mental health) get fragmented care across acute and home settings
- Researchers spend months or years navigating ethical and legal pipelines before they can see cohort data
- EHDS and similar regional regulations are about to make cross-border data flow mandatory — most provider stacks aren’t ready
- Multi-organization care coordination is invented per project, mock-up by mock-up, instead of being a reusable platform
Naftiko Today
- Capability YAML defines exactly which fields cross which boundary — auditable, declarative, reviewable by legal counsel
- External bindings for secrets keep per-jurisdiction credentials and policies out of capability source
- MCP exposure (Streamable HTTP, stdio) and REST/Skills exposure mean the same governed capability can serve clinicians, researchers, and partner organizations from one source of truth
- Spectral ruleset (15 rules) catches over-broad data exposure before a capability ships
Naftiko Tomorrow
- Tool annotations (Second Alpha) — annotate which capability operations are primary-purpose vs secondary-purpose so policy-aware clients can route correctly
- MCP auth (Second Alpha) — per-jurisdiction authentication on the same capability surface so a region and a municipality can each authorize their own slice
- Enterprise security with Keycloak and OpenFGA (v1.1) — fine-grained access control mapped to the legal boundaries the capability actually crosses
- Naftiko Shipyard MVP (Fleet Second Alpha) — a per-organization runtime that hosts that organization’s authorized view of a shared capability, so cross-org data flow becomes a deployment pattern rather than a one-off integration project