OpenFHIR adapter for profile-driven FHIR mapping
Build a FHIR adapter that can connect with OpenFHIR Sandbox
AI assistant that drafts workflows and Lua scripts from a description
Let me describe an interface in a sentence and have Linkiir draft the workflow, so building a new integration starts from something working instead of an empty canvas. For example: "receive HL7 ADT over LLP, map to a FHIR Patient, POST it to a JSON API" should produce the nodes already wired together, a starting Lua transformation written against the documented scripting API, and a reasonable default for error handling. What would make this trustworthy rather than a gimmick: - Reuse our existing templates and catalog entries instead of inventing new structures, so generated work matches our house conventions. - Generated Lua must be normal editable script, not a black box. We need to read it, review it, and own it. - Show a diff and require confirmation before anything is applied, and never deploy to production automatically. - Make templates first-class saveable objects, so a good generated workflow becomes the starting point for the next one. The goal is cutting the boilerplate on the twentieth similar interface, not replacing the integration engineer.
High availability for Linkiir Grid with automatic failover
We need to run Linkiir Grid on more than one host so a single machine failure does not stop message flow, with failover that happens without an operator being paged at 3am. What matters to us: - Inbound LLP listeners are the hard part. Only one node can hold a TCP port, so we need a documented story for how a sending system keeps delivering during a switchover rather than getting connection refused. - No lost or silently duplicated messages across a failover. If the guarantee is at-least-once, say so plainly so we can make our downstream handlers idempotent. - A stated recovery time we can put in our own uptime commitments to clinical stakeholders.