Only 123,559 electronic patient dossiers had been opened in Switzerland by the end of September 2025.

That represented just 1.37% of the resident population at the time. Bag.admin.ch

Then, on 14 September 2026, Switzerland's National Council approved the proposed new Federal Act on the Electronic Health Dossier by 134 votes to 53, with 10 abstentions.

Under the model currently moving through Parliament, residents would receive an electronic health dossier, the E-GD, automatically and free of charge unless they opt out. The Council of States is the next chamber, which means the legislation is not yet final. BAG says that even if the remaining parliamentary process moves quickly and implementation proceeds as planned, the new system would not become operational before 2030. Swiss Federal Assembly

For HealthTech founders, executives and investors, I think focusing only on the new dossier misses the larger shift.

Switzerland is redesigning the architecture around how health data moves.

And that potentially changes:

who controls access

how software connects

how much integration costs

which workflows become easier to automate

how health data can be reused

and ultimately:

which HealthTech business models become more valuable.

This is bigger than EPD → E-GD

The E-GD and SwissHDS are closely connected, but they are not the same thing.

BAG describes the future E-GD as an integral component of SwissHDS.

Longer term, SwissHDS is intended to become infrastructure for health-data exchange, while the E-GD functions as a secondary system for long-term storage of treatment-relevant information within that wider architecture. Bag.admin.ch

A useful simplification is:

E-GD = DOSSIER

SwissHDS = DATA-EXCHANGE ENVIRONMENT

That means the more useful founder question is no longer:

Can we integrate with Switzerland's electronic health record?

It becomes:

Can our product create value inside an increasingly standardized, interoperable and governed health-data ecosystem?

That is a much harder question.

But commercially, it is also much more interesting.

The SwissHDS architecture changes the strategic picture

SwissHDS is not being designed as one giant centralized health database.

DigiSanté describes it as a federated Data-Mesh architecture.

Health data remains with the responsible organizations. Standardized data products can then be made securely and controllably usable across organizations using shared infrastructure, common governance, interoperability and open standards. DigiSanté

That distinction matters.

The opportunity is not necessarily:

Who owns the most health data?

It may increasingly be:

Who makes distributed health data usable?

That opens several very different commercial layers.

My framework: CONTROL → CONNECT → OPERATE → REUSE

I would analyze the emerging architecture through four layers.

The important point is that each layer has:

a different buyer,

a different proof requirement,

a different implementation burden,

and:

a different ROI story.

1. CONTROL: identity, consent and permissions become infrastructure

Before health data can move, the system needs to answer:

Who is requesting it?

Are they authorized?

What is the patient allowing?

Which information may be accessed?

What gets logged?

Who remains responsible?

Under the current E-GD proposal, residents retain control over access to their information. The National Council also strengthened provisions around data protection and security in its version of the legislation. Swiss Federal Assembly

This makes the trust layer commercially significant.

Existing ecosystem signals

HIN already provides identities, secure access and a healthcare trust environment used for protected applications and secure communication.

HIN describes itself as a standard for secure digital collaboration in Swiss healthcare and is certified as an EPD identity provider. HIN

SwissID currently provides secure authentication for the EPD systems operated by CARA and Mon Dossier Santé. SwissID

That does not mean today's identity infrastructure automatically becomes the final E-GD identity layer.

The architecture is still evolving.

What founders should ask

Do not ask:

Do we support authentication?

Ask:

Can identity, consent and permission become almost invisible to the user while remaining fully auditable?

That is a much stronger product proposition.

2. CONNECT: FHIR becomes much more important

One of the clearest technical signals came in May 2026.

DigiSanté concluded that HL7 FHIR is a suitable foundation for data exchange in SwissHDS.

The federal Data Management expert group has specified FHIR as the basis for health-data exchange, and DigiSanté says it is intended to become binding for interfaces and transactions within SwissHDS. DigiSanté

This creates an obvious opportunity.

But it also creates a trap.

“We support FHIR” will increasingly stop being differentiation.

The federal analysis itself makes clear that choosing FHIR is not enough.

Effective interoperability still depends on:

consistent implementation

common specifications

connecting legacy systems

and:

continued development of existing infrastructure. DigiSanté

So buyers will increasingly move from asking:

Do you have an API?

toward:

Which resources?

Which implementation guides?

Which terminology?

Which data flows?

How much custom integration remains?

How much work does our IT team still have to do?

That creates a much better commercialization proposition:

Do not sell FHIR compatibility. Sell integration burden removed.

DigiSanté's vendor survey reinforces this

DigiSanté surveyed 73 digital-health application providers between 20 May and 1 June 2026.

81% had their headquarters in Switzerland.

DigiSanté explicitly warns that the sample is not a representative market study, so those percentages should not be treated as a complete description of the Swiss HealthTech market.

But the directional finding is still useful:

structured data exchange is becoming central, and interoperability and common standards sit at the heart of future digital-health development. DigiSanté

That is a significant product-strategy signal.

Why standards matter financially

DigiSanté's standards programme does not frame standardization purely as a technical objective.

It identifies expected benefits including:

lower administrative burden

fewer errors caused by broken media handoffs

continuous automated workflows

less double documentation

and:

a more stable technical foundation for IT vendors. DigiSanté

A separate DigiSanté explanation also explicitly links standardization with:

lower IT integration cost

process automation

and:

better data quality. DigiSanté

For a founder, those are not architecture metrics.

They are:

unit-economic variables.

3. OPERATE: connected data is worthless if the workflow remains broken

This is where I think many interoperability startups stop one layer too early.

Hospitals do not buy FHIR.

Clinicians do not want standards.

Patients do not care which API transmitted a medication record.

They care about what happens next.

Does connected data mean:

less duplicate entry?

faster scheduling?

fewer missing records?

better medication workflows?

less reconciliation?

easier referrals?

better patient access?

That is the OPERATE layer.

Compassana-Well is an important signal here

In August 2026, Compassana and Well announced their combination into Compassana-Well AG, with operational launch planned for January 2027, subject to the necessary approvals.

The shareholder ecosystem includes:

Medbase

Hirslanden

Groupe Mutuel

Helsana

SWICA

and:

Trifork

alongside a wider group including CSS, DocMorris, Galenica and Visana.

Compassana says the affiliated insurers represent around 70% of insured people in Switzerland. Compassana

The significance for me is not the corporate structure.

It is that another layer is forming around:

digital patient access

care navigation

provider connectivity

and:

use of relevant medical information across the patient journey.

That is where infrastructure begins turning into workflow.

Other workflow examples

heyPatient describes itself as a patient-experience layer designed to work with existing healthcare IT and currently reports 9+ hospitals and clinics in Switzerland using its platform. heyPatient

docdok.health combines structured patient-data collection, AI-supported summaries, follow-up monitoring and FHIR-ready integration into clinical workflows. Docdok Health

These companies illustrate the distinction nicely.

A national data architecture does not eliminate application companies.

It changes:

what those application companies need to integrate with and what value they need to prove.

4. REUSE: the biggest upside may come after the clinical encounter

The fourth layer may ultimately create the largest new value pool.

Once health data becomes more standardized and discoverable, the next question becomes:

What can safely and lawfully be done with it beyond the original encounter?

Potential use cases include:

clinical research

real-world evidence

population analytics

AI development

AI validation

precision medicine

clinical-trial feasibility

and:

health-system planning.

SwissHDS is explicitly intended to improve data flows not only for treatment processes, but also administrative and secondary-use processes. Health data remains with responsible organizations while standardized data products can be used across organizations through the shared infrastructure. DigiSanté

That matters enormously for research and AI companies.

Tune Insight illustrates one possible model

Tune Insight operates a federated health-data platform designed to let institutions collaborate without centralizing or directly sharing their underlying data.

The company reports collaborative networks across Europe and describes uses around privacy-preserving healthcare analytics and research. Tune Insight

That model fits particularly well with a world where:

data utility increases

but:

institutional control remains important.

SOPHiA GENETICS demonstrates another layer

SOPHiA GENETICS says its platform connects more than 1,000 healthcare institutions across 75+ countries and has analyzed more than 2.6 million genomic profiles.

Its AI-driven precision-medicine platform combines complex health data into clinical and research insights. SOPHiA GENETICS

That business is different from SwissHDS.

But it illustrates the downstream value chain:

STRUCTURED DATA → COMPUTATION → CLINICAL INSIGHT

And that is exactly why the infrastructure layer matters.

RetinAI shows what specialization can look like

RetinAI, operated by Bern-based Ikerian AG, combines imaging-data infrastructure, AI and ophthalmology workflow.

Its Discovery platform is used for:

clinical workflows

research

real-world evidence

clinical studies

and:

multimodal data analysis.

The company reports more than one million patient images processed and launched its CE-marked OCT Atlas for clinical use in June 2026. RetinAI

Again, SwissHDS does not replace specialty intelligence.

A better data environment potentially makes that specialty intelligence:

easier to integrate

easier to validate

and:

easier to scale.

b-rayZ shows a similar pattern in breast imaging

Zurich-based b-rayZ develops AI tools across mammography and breast-imaging workflows.

Its technology is designed to integrate with digital mammography, tomosynthesis and PACS environments, with modules covering imaging quality and AI-supported assessment. b-rayZ

The strategic lesson is important:

The infrastructure may become standardized while clinical specialization remains highly differentiated.

Those two forces can happen at the same time.

The EPD layer is already consolidating

The future architecture is not the only thing changing.

The current EPD market is consolidating too.

In June 2026, Abilis joined CARA.

The Canton of Fribourg reported that the resulting CARA structure represented 85% of healthcare providers participating in the EPD. It also reported 5,247 participating healthcare providers nationally as of 31 May 2026. FR.ch

The wider transition layer referenced in this ecosystem includes:

CARA

emedo

eSANITA

AD Swiss

Abilis

Mon Dossier Santé

and:

Post Sanela

But this list should not be interpreted as a static market.

Post Sanela is a good example of why

Swiss Post announced in June 2026 that the Sanela reference community will be dissolved at the end of 2026.

Swiss Post said demand for the existing EPD had declined and that it intends to focus on the future E-GD. Its current EPD platform continues only through the end of 2026. Swiss Post

That is a useful founder warning:

Do not build your 2027–2030 GTM strategy around today's EPD structure remaining unchanged.

It already isn't.

But there is an important risk founders should not ignore

The policy direction is clearer than it was.

The implementation timetable is not risk-free.

In June 2026, DigiSanté announced significant budget reprioritization.

Its planned 2027 budget was reduced from CHF59 million to CHF31.5 million.

SwissHDS was among the large projects whose scope or timing had to be adjusted, with focus shifting toward core elements related to the E-GD and selected pilots. Work on some secondary-use and semantic-standard projects has also been staged or delayed. DigiSanté

This matters for investors.

The right thesis is not:

Everything on the federal roadmap will happen exactly on time.

A more defensible thesis is:

Does this company become more valuable as Switzerland standardizes, even if individual government milestones move?

That is a much stronger investment test.

The ecosystem map I would use

Here is how I would organize the players from the full visual and analysis.

These are ecosystem examples, not a list of confirmed E-GD or SwissHDS suppliers.

That distinction matters.

Where I think commercial value shifts next

The following is my commercial inference, rather than an official Swiss government forecast.

I see six areas worth watching closely.

1. FHIR implementation

Not another “FHIR-ready” badge.

The opportunity is reducing:

integration engineering

implementation weeks

custom mapping

and:

maintenance cost.

2. Semantic interoperability

This is often overlooked.

Moving data does not guarantee that the receiving system interprets it correctly.

That creates opportunity around:

terminology

coding

value sets

mapping

validation

and:

data quality.

3. Identity + permission orchestration

As more data becomes exchangeable, access control becomes more important, not less.

The product opportunity is to make:

identity

consent

permission

and:

auditability

work across institutions without adding another cumbersome workflow.

4. Workflow adapters

I think this is particularly attractive.

A product that converts connected data into:

fewer clicks

less duplicate documentation

faster referrals

better patient access

or:

less manual reconciliation

has a much clearer business case than infrastructure alone.

5. Privacy-preserving data collaboration

Federated analytics, research collaboration and secure AI development may become increasingly relevant as data becomes easier to discover but remains institutionally controlled.

6. Portable Swiss reference sites

This one is commercial rather than technical.

Switzerland is a relatively small market.

So the first deployment becomes much more valuable if it creates reusable:

FHIR assets

governance documentation

clinical evidence

workflow proof

ROI

and:

a credible DACH or EU reference.

What may become less defensible

The architecture direction creates the opposite question too.

Which products become more exposed?

My commercial watchlist would include products heavily dependent on:

PDF exchange

manual re-entry

proprietary interfaces

custom site-by-site integrations

closed data models

and:

isolated workflows that cannot exchange structured information.

That does not mean every legacy product disappears.

It means the cost of remaining closed potentially rises.

The calculator: turning architecture into financial exposure

This is why I built the Switzerland Health Data Opportunity Diagnostic.

The architecture itself is interesting.

But founders eventually need to answer:

What does this do to runway?

Consider the default scenario in the tool.

Assumptions

Monthly GTM + integration burn:

CHF40,000

Potential delay:

8 months

One-off implementation / adaptation:

CHF65,000

Expected first-year account value:

CHF220,000

Qualified win probability:

35%

Gross margin:

70%

ROI calculation 1: delay exposure

CHF40,000 × 8 months

=

CHF320,000

Add implementation:

CHF320,000 + CHF65,000

=

CHF385,000 capital exposed before scalable rollout

This is an illustrative founder scenario, not a Swiss market benchmark.

Its purpose is to expose the economics of time.

ROI calculation 2: probability-weighted economics

A CHF220K contract is not economically equivalent to CHF220K if you only have a 35% probability of winning it.

Probability-weighted revenue:

CHF220,000 × 35%

=

CHF77,000

Apply 70% gross margin:

CHF77,000 × 70%

=

CHF53,900 probability-weighted first-year gross profit

Now compare:

CHF385,000 ÷ CHF53,900

=

7.1×

Under those assumptions, commercial exposure is roughly 7.1 times probability-weighted first-year gross profit.

That does not mean the market should be avoided.

It means:

integration time and buyer selection materially affect startup economics.

ROI calculation 3: what if better preparation removes three months?

Suppose stronger architecture preparation and tighter buyer selection reduce the timeline from:

8 months → 5 months

Three months disappear.

At CHF40K/month:

CHF120,000 of runway is preserved

No new market-size assumptions.

No hypothetical valuation.

No extra customer required.

Just less time wasted.

That is why I increasingly think founders should measure interoperability as:

MONTHS REMOVED FROM DEPLOYMENT

not:

number of APIs built.

There is an even more important scaling calculation

The CHF385K exposure looks terrible if every implementation is a one-off project for one customer.

But imagine the same integration, governance and GTM assets become reusable across the 8 genuinely high-fit accounts identified by the calculator.

If shared costs were allocated evenly across eight priority accounts:

CHF385,000 ÷ 8

=

approximately CHF48,000 per priority account

Compare that with the illustrative CHF53.9K probability-weighted first-year gross profit.

Suddenly the economics look very different.

This is not a forecast and real cost allocation will not be perfectly even.

But it demonstrates something strategically important:

Reusable integration turns implementation expense into infrastructure.

That is the difference between:

a services-heavy deployment model,

and:

a scalable HealthTech platform.

Why the 25-buyer calculation matters

Now consider buyer selection.

Suppose you research:

25 Swiss organizations.

After scoring them for:

architecture fit

workflow pain

existing infrastructure

buyer ownership

integration burden

procurement

and:

timing

only 32% look genuinely attractive.

That gives:

8 priority accounts

Now suppose warm senior access exists at only 25% of those accounts.

That gives:

2 warm priority buyers

The actual commercial problem is therefore not:

We need more Swiss healthcare leads.

It is:

We have six high-fit accounts where we still need the right relationship and buyer route.

That is much more actionable.

How founders should use the diagnostic

I would interpret the score approximately like this.

Below 45 / 100

Do not scale broad outreach.

There is too much uncertainty around:

integration,

workflow,

governance,

or architecture.

Fix the weakest layer first.

45–64 / 100

The opportunity is plausible.

But one or two major gaps are still likely to lengthen deployment and consume runway.

Narrow the ICP aggressively.

65–81 / 100

The architecture case is increasingly credible.

The commercial bottleneck now moves toward:

buyer selection

budget ownership

procurement

and:

timing.

82+ / 100

The technical and architectural proposition is relatively strong.

At that point, I would spend less time creating additional market reports and more time building a concentrated buyer pipeline.

What founders should do in the next 30 days

I would use the transition to run five practical exercises:

1. Audit every integration. Label it structured API, standardized exchange, custom connector, document transfer or manual process.
2. Identify the two data flows that actually determine customer ROI. Do not FHIR-enable everything simply because FHIR exists.
3. Map CONTROL → CONNECT → OPERATE → REUSE. Know exactly where your product creates value and which upstream dependencies you require.
4. Design buyer #1 so buyer #2 gets cheaper. Capture reusable architecture, security, workflow and evidence assets.
5. Score the actual Swiss buyers before outreach. Architecture readiness without account selection still creates wasted GTM spend.

What healthcare executives should ask vendors

The same shift changes vendor diligence.

I would ask:

Which interfaces are standardized today?

Which remain custom?

Which workflow disappears after implementation?

What happens to our existing systems?

How are identity and permissions managed?

Which semantic standards are used?

Can the product coexist with E-GD and SwissHDS?

Which implementation work would have to be repeated at another institution?

Can the data create secondary value later?

And one particularly useful question:

Does this vendor reduce fragmentation, or simply create a better-looking silo?

What investors should diligence

For investors, I would add an explicit architecture-risk section to Swiss digital-health diligence.

Integration debt

What percentage of deployment revenue depends on bespoke engineering?

Standardization readiness

Can implementations increasingly use reusable FHIR and semantic assets?

Governance

Can the company satisfy identity, permission, security and audit requirements without bespoke reinvention?

Workflow ownership

Does interoperability increase product usage, or does the product remain peripheral?

Data utility

Can connected data generate new research, analytics or AI value?

Reference portability

Does Switzerland create a reference for the next market?

Platform risk

Does national infrastructure make the company more valuable, or does it absorb part of the functionality the company currently sells?

That last question may be the most important.

Standardization expands some markets while commoditizing others.

The key investor question

If I were evaluating a Swiss HealthTech company now, I would ask:

WHEN HEALTH DATA BECOMES EASIER TO EXCHANGE, DOES THIS COMPANY BECOME MORE VALUABLE OR LESS NECESSARY?

If easier interoperability makes deployment faster and increases the usefulness of the product:

that is potentially attractive.

If most of the company's moat exists because Switzerland is currently fragmented:

the architecture reset may eventually reduce that moat.

Where I can help

I do not see my role here as replacing:

FHIR engineers,

Swiss regulatory specialists,

security teams,

hospital architects,

or legal counsel.

The commercial gap is different.

It sits between:

TECHNICAL READINESS → BUYER PRIORITY → REVENUE

A startup can be technically excellent and still spend nine months pursuing an organization that:

has no budget,

already has an incumbent,

requires the wrong evidence,

or cannot buy on the timeline the startup needs.

That is where market intelligence becomes commercially useful.

Step 1: locate the product in the architecture

I first ask where it really sits.

CONTROL

Identity, consent, access, trust.

CONNECT

FHIR, interoperability, data exchange.

OPERATE

Clinical workflow, patient access, care coordination.

REUSE

Research, analytics, AI.

That alone changes the buyer map.

A privacy-preserving analytics platform should not target the same organizations and stakeholders as:

a patient app,

an interoperability vendor,

a clinical AI company,

or:

a care-navigation product.

Step 2: identify the actual buyer

A hospital is not a buyer.

A logo does not sign a contract.

Depending on the product, the relevant stakeholder could be:

CIO

CMIO

Chief Digital Officer

Head of Data

clinical service-line lead

innovation leader

operations

research leadership

payer transformation

or:

procurement.

That is why I prefer a concentrated buyer map over another giant contact database.

Step 3: prioritize accounts around commercial fit

I would score potential Swiss accounts across:

architecture fit

workflow pain

existing vendor environment

budget ownership

integration effort

evidence requirement

procurement

timing

and:

reference-account value.

The end result should not be:

Here are 250 Swiss healthcare organizations.

It should be:

Here are the 6–10 accounts where this product has the strongest combination of pain, fit, timing and strategic value.

Step 4: turn interoperability into an ROI message

The ROI story also changes by architecture layer.

CONNECT company

Sell:

integration hours removed

custom interfaces avoided

implementation time reduced

maintenance burden lowered

OPERATE company

Sell:

staff hours saved

duplicate documentation removed

patient-access improvement

faster workflow

REUSE company

Sell:

faster study feasibility

lower data-preparation cost

more institutions connected

faster AI validation

new real-world evidence

That makes the commercial story much more defensible than:

We improve interoperability.

Step 5: choose the Swiss reference strategically

The largest institution is not necessarily the best first customer.

I would prefer the account that gives the startup the strongest combination of:

credible brand

usable evidence

portable integration

measurable ROI

repeatable workflow

and:

access to market #2.

That can materially increase the lifetime value of the first contract.

Where the HealthTech Buyer Pipeline Sprint fits

Once the diagnostic shows the company is sufficiently ready, another generic Swiss market report is unlikely to be the highest-value next step.

The problem becomes execution.

The HealthTech Buyer Pipeline Sprint is designed to move from:

architecture opportunity

→ buyer universe

→ priority accounts

→ relevant decision-makers

→ buyer-specific commercial thesis

→ outreach around measurable value

The deliverable focuses on:

25 PRIORITY HEALTHCARE BUYERS + 15 RELEVANT DECISION-MAKERS

rather than hundreds of generic contacts.

That could include, depending on the product:

hospitals,

care networks,

insurers,

patient platforms,

data partners,

research organizations,

or:

strategic implementation partners.

The purpose is not more leads.

It is:

fewer wrong buyers and less commercial time wasted.

HealthTech Buyer Pipeline Sprint: 25 Buyers + 15 Decision-Makers

Final takeaway

The Swiss story is not simply:

EPD → E-GD

Several changes are happening at once.

The National Council has backed a much broader opt-out dossier model, although the legislation remains unfinished. Swiss Federal Assembly

SwissHDS is already in MVP implementation. DigiSanté

FHIR has been selected as the technical foundation for SwissHDS exchange. DigiSanté

Swiss digital-health vendors themselves are highlighting structured exchange and common standards as central requirements. DigiSanté

The current EPD provider landscape is consolidating. FR.ch

And the wider SwissHDS architecture is explicitly designed to support treatment, administrative and secondary-use data flows through a federated model. DigiSanté

So my commercial thesis is:

CONTROL → CONNECT → OPERATE → REUSE

But for founders, that still is not enough.

The business model only closes when it becomes:

CONTROL → CONNECT → OPERATE → REUSE → BUYER → ROI → REPEATABLE DEPLOYMENT

The strongest opportunity may therefore not belong to the company that stores the most data.

It may belong to the company that can make distributed Swiss health data:

trusted

interoperable

usable

valuable

and:

commercially repeatable.