<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Architecture on Notes from the Health Informatics Architect</title><link>https://vedprakash.vamihealth.in/tags/architecture/</link><description>Recent content in Architecture on Notes from the Health Informatics Architect</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 01 Nov 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://vedprakash.vamihealth.in/tags/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Why We Run a Dual FHIR + openEHR Architecture (And What It Actually Costs)</title><link>https://vedprakash.vamihealth.in/posts/dual-model-fhir-openehr-architecture/</link><pubDate>Sun, 01 Nov 2026 00:00:00 +0000</pubDate><guid>https://vedprakash.vamihealth.in/posts/dual-model-fhir-openehr-architecture/</guid><description>&lt;p&gt;On paper, the pitch for a dual-model clinical data architecture is clean: use &lt;strong&gt;openEHR&lt;/strong&gt; archetypes for structured, meaning-preserving clinical documentation, and &lt;strong&gt;HL7 FHIR&lt;/strong&gt; resources for interoperable exchange. Two models, each doing what it&amp;rsquo;s best at. I&amp;rsquo;ve built this pattern more than once now — across an open-source Patient Management System and EMR, a health information exchange platform, and a national Hospital Information System — and it&amp;rsquo;s worth being honest about what it buys you and what it costs.&lt;/p&gt;</description></item></channel></rss>