Need Multi-Stakeholder Patient-Centered Interoperability
Iris's project pulls in a vendor, a consultancy, a healthcare provider, and a university — each cares about a different slice of the same patient. She needs an interoperability fabric that lets every stakeholder see only what they should and contribute only what they own.
Take Control Of Your Signals — Become a Naftiko Design Partner Today!
Persona Story:
Iris’s chronic-wound-care project has four constituents at the table — a wound-care manufacturer (Mölnlycke), a consultancy (Avenga) building the dashboard prototype, the healthcare provider running real clinical operations, and the university research group. Each cares about a different slice of the same patient. The vendor needs information-model fidelity around its products. The consultancy needs a generic platform that demos cleanly. The provider needs clinical safety. Researchers need cohort-level signal. Today, every project of this shape reinvents the integration scaffolding, and the patient is the only point of intersection. Iris wants this Venn diagram to be a runtime architecture, not a one-off Excel.
Problem Context
- Patient-centered care touches multiple organizations with non-overlapping incentives — vendors, consultancies, providers, researchers, regulators
- Each stakeholder has a legitimate but partial view of the patient’s data, plus its own constraints on what it can see, write, and share
- Interoperability work historically centers on system-to-system pipes; multi-stakeholder coordination centers on who can see what about whom
- Today the coordination is invented per-project (mock-ups, Excel, Slack channels) and dies at the end of the grant or pilot
Problem Impact
- The same integration scaffolding gets rebuilt for every chronic-condition project, every research collaboration, every regulatory pilot
- Vendors pull in too much data because no governed interface gives them a focused slice; researchers pull in too little because the multi-stakeholder access pattern is hard to navigate
- Patients end up the only entity that holds the full picture, often via paper folders they bring to each appointment
- Mock-ups stay mock-ups because productionizing them requires a multi-organization governance layer that doesn’t exist
Naftiko Today
- Capability YAML lets each stakeholder declare exactly which fields it consumes and exposes — no more, no less — and the contract is auditable
- MCP exposure, REST exposure, and Skill exposure on the same capability mean each stakeholder consumes the form that fits their tooling
- External bindings for secrets keep each stakeholder’s credentials and access scope contained
- OutputParameters normalization means each stakeholder sees the patient through a consistent shape, not the source vendor’s quirks
Naftiko Tomorrow
- Tool annotations (Second Alpha) — annotate which parts of a capability are vendor-shareable, researcher-shareable, regulator-shareable
- MCP auth (Second Alpha) — per-stakeholder authentication on the same patient capability, so every party authorizes its own slice
- Naftiko Shipyard MVP (Fleet Second Alpha) — each stakeholder hosts its own slice of the shared capability in its own runtime, with cross-runtime audit
- Fabric capability discovery (v1.1) — multi-stakeholder projects find each other’s capabilities and stitch instead of reinvent
- Enterprise security with Keycloak and OpenFGA (v1.1) — fine-grained policy mapped to the actual stakeholder relationships, not just role-based scopes