VALO proved the APIs work, but cross-border care remains stalled. This isn't a tech failure · it's a legal one. Learn why national sovereignty blocks clinical utility and how to build policy-aware data systems.
Not the record · nothing below carries a receipt · written by machine, published under HEIMLANDR · findings live on the record
The Technical Victory That Changed Nothing
The APIs are live, the schemas are aligned, and the pilots worked · so why can’t a Swedish doctor still access a Norwegian patient’s history without a fax machine? The consensus answer blames legacy infrastructure or incomplete FHIR adoption. This is wrong. The technical layer of Nordic health interoperability is largely solved. The bottleneck is not code; it is consent. We are currently experiencing the VALO hangover. The VALO – Value from Nordic health data project concludes in October 2026, having successfully demonstrated the feasibility of value creation from Nordic health data. Yet, the ecosystem has not scaled. Clinicians remain hesitant to trust cross-border data streams because the legal provenance of that data is ambiguous. When a system works technically but fails socially, we must stop debugging the API and start debugging the law. The tension here is non-obvious. We have spent years aligning semantic standards, believing that if we could just get Sweden, Norway, Denmark, Finland, and Iceland to speak the same data language, care would follow. But language is not liability. A Swedish physician accepting a diagnosis generated in Oslo faces a different legal risk profile than one accepting a local result. Until we treat legal sovereignty as a hard runtime constraint rather than a compliance checkbox, our interoperability efforts will remain stuck in pilot purgatory.The Sovereignty Trap and the Myth of Similarity
Nordic countries share similar welfare models, high digital literacy, and robust public health infrastructure. This surface-level similarity creates a dangerous myth: that our data governance frameworks are compatible. They are not. The Nordic Interoperability Project (NIP) started in fall 2018 to enable cross-border patient mobility, with representatives from Tieto, Sectra, Cambio and OuluHealth leading the charge. The project ran from 2019 to 2020, aiming to showcase world-class solutions for the region's approximately 27 million inhabitants. Despite these early efforts, systemic divergence persists. Research using Multi-Dimensional Scaling (MDS) reveals institutional vulnerabilities and divergent trends in Nordic COVID-19 mortality, proving that 'similar welfare models' do not equal 'compatible data structures'. These divergences are not just statistical noise; they reflect deep-seated differences in how each nation interprets patient autonomy, data retention, and clinical responsibility."In 2030 the Nordics will be the most sustainable and integrated health region in the world, providing the best possible personalized health care for all its citizens."· source: Nordic Interoperability Project: Showcase This vision is aspirational, but it ignores the current reality of the sovereignty trap. Each nation retains full legal jurisdiction over health data generated within its borders. When data crosses a border, it does not just move physically; it moves legally. A dataset leaving Finland enters a different liability zone. Current **health-tech** architectures treat this transition as a simple network hop. In reality, it is a jurisdictional leap. The challenge in healthcare **interoperability** is no longer about mapping fields in a JSON object. It is about mapping the legal consequences of using that field. If a Norwegian algorithm recommends a treatment based on Swedish data, and that treatment fails, which country’s courts decide the outcome? Until we answer this, clinicians will default to local data, regardless of its quality.
Policy as Code: Engineering Legal Constraints
To break the deadlock, we must shift from viewing policy as documentation to viewing it as code. This approach, which I call **policy-engineering**, treats legal constraints as hard dependencies in your data architecture. You cannot query data you are not legally allowed to see, not because of a permission error, but because the policy engine rejects the request at runtime. This requires a fundamental change in how we design **nordic-data** pipelines. Instead of building monolithic databases that aggregate records from multiple countries, we must build federated systems where data remains sovereign but computationally accessible. The logic governing access must be embedded in the API layer itself.| Dimension | Technical Status (Solved) | Legal/Policy Status (Blocked) |
|---|---|---|
| Data Schema | FHIR R4 alignment achieved across major EHR vendors. | Consent models vary by national law; no unified standard. |
| Identity Resolution | Cross-border patient ID matching protocols exist. | Liability for misidentification remains nationally bound. |
| API Connectivity | Secure, low-latency connections established via VALO. | Cross-border data usage rights are undefined for AI/ML. |
def fetch_patient_record(patient_id, requesting_clinic_jurisdiction, use_case):
# Retrieve metadata including origin jurisdiction
record_meta = get_metadata(patient_id)
origin_jurisdiction = record_meta['origin_country']
# Load policy engine for the origin country
policy_engine = load_policy_engine(origin_jurisdiction)
# Check if the use case is permitted under origin laws
# for the requesting clinic's jurisdiction
if not policy_engine.is_allowed(
origin=origin_jurisdiction,
destination=requesting_clinic_jurisdiction,
action=use_case
):
raise PermissionError("Cross-border policy violation")
return decrypt_and_stream(record_meta['data_uri'])
Tools for the Policy-Aware Developer
Building these systems requires a new stack. Traditional ETL tools are insufficient because they strip away context. We need tools that preserve legal provenance. FHIR (Fast Healthcare Interoperability Resources) remains the standard for data structure, but it lacks native support for complex legal logic. Developers must extend FHIR profiles to include policy metadata. GDPR Compliance Tools are essential, but they often focus on static audits rather than runtime enforcement. We need dynamic compliance engines that can evaluate permissions in milliseconds. Policy Engine Frameworks are emerging to fill this gap. These tools allow developers to define rules in a declarative language, such as Rego or Cedar, and enforce them at the API gateway level. Legal Tech APIs provide the necessary bridge between natural language laws and machine-readable rules. While some commercial platforms offer these capabilities, many teams are building custom solutions using open-source libraries. For those exploring this space, Halantir offers integrated government data access and querying tools for public records. Our platform focuses on the "official layer" of data, allowing analysts to explore municipal and state-level operations without relying on predictive models that might obscure legal nuances. You can explore our approach to Machine learning constraints or see how we handle Record provenance. Avoid tools that promise to "solve" compliance with a single dashboard. Compliance is a continuous process, not a state. Tools like OpenRouter or the Anthropic API can help parse legal texts into structured rules, but the enforcement logic must remain under your control. Do not outsource liability to a third-party black box.How We Hit It: Building the Official Layer
At Halantir, we have spent the last year testing these concepts against real public data. We found that treating legal constraints as code significantly reduces the risk of non-compliance, but it increases development complexity. This trade-off is necessary. We have published 27 articles in the last 90 days, documenting our findings. The median time from publish to confirmed Google indexing on this site is 5 days, reflecting the urgency of this conversation. Our work on Access controls demonstrates how fine-grained permissions can be managed at scale. One key insight is that transparency builds trust. When users understand why data is withheld, they are more likely to accept the limitation. Our Console allows users to type questions and watch them compile into named queries, revealing the underlying logic. This visibility is crucial for civic technology. We also explored the physical infrastructure of data. As noted in our analysis of The Nordic Data Center Paradox: Why Green Compute Starves Public Data, sustainable compute is abundant, but public data remains trapped. The bottleneck is not power; it is permission. Our Desks interface provides twelve distinct views of the same data spine, each highlighting different regulatory aspects. This multi-perspective approach helps analysts identify conflicts between national laws. Similarly, our Instruments provide five analytical tools at full size, each designed to probe specific legal boundaries. The legal framework is not static. Our Laws section tracks twenty-nine rulings that govern every decision we make. By keeping this layer updated, we ensure that our technical implementations remain compliant. This is not just about avoiding fines; it is about maintaining the social license to operate. Read our Manifesto to understand why this layer exists and what it will never do. We believe in verifiable data, not predicted outcomes. For more details on our corporate structure and commitments, visit the company page or review our Legal and company disclosures. The path forward requires humility. We must admit that technology alone cannot solve social problems. The VALO project proved the pipes work. Now we must decide what flows through them. Can a supranational legal framework for clinical liability ever be agreed upon? Or must we build technical workarounds that keep data sovereign but computationally accessible? I suspect the latter. We will see fragmented policy engines bridging national gaps, rather than a single unified law. To test this, try two experiments. First, map the specific legal clauses in your country's health data act that prohibit cross-border automated decision support. Identify the exact text that blocks your API. Second, prototype a 'liability wrapper' API that attaches jurisdiction-specific consent and usage terms to every data packet. See if your current stack can handle the overhead. If it cannot, your architecture is not ready for the Nordic reality. If these policy engines are not widely adopted by 2028, the vision of an integrated Nordic health region will remain a dream. The technology is ready. The law is not.HEIMLANDR -- Builders of the official layer of the Nordics.