#Danish National Health Infrastructure: Integration Status and Gate Analysis

STM-DK-002 v1.0.0, Last Modified On 01 August 2026, Tier: Public

Pensieve Labs holds no Danish national health infrastructure certification, connection or trust agreement as at 01 August 2026. This statement says so on the first page, states exactly what each gate is, classifies which of them actually block a deployment and which do not, and sets out the phased offer that follows. A hospital that has been told the truth about a manual interim is a hospital that trusts the next thing Pensieve Labs says.

---

#Applicability

---

#1. The chain, in three lines

Everything in this document hangs off one dependency chain, and reading it in order removes most of the confusion in a Danish technical review:

FMK certification → NSP agreement → SDN connection. No SDN, no NSP. No NSP, no FMK. No FMK, no prescribing.

MedCom certification sits alongside it and governs message exchange rather than the national service platform. LPR3 reporting sits alongside both and has its own escape hatch.

---

#2. Gate classification: the table that decides the Danish offer

Hard = a deployment cannot lawfully or practically operate without it. Phase 2 = required for full clinical scope, not for an operating-substrate deployment. Soft = expected, costs credibility, survivable.

The structural point. Gates 2, 3, 4 and 9 are contractual and functional gates, not statutory ones. Nothing in Danish health statute compels a private hospital to connect to the national service platform. What compels it is (a) the agreement under which it treats publicly referred patients, and (b) the fact that a hospital which prescribes cannot avoid the shared medication record. Because the gate is contractual rather than statutory, it can be phased, and that is the whole basis of the Danish offer.

---

#3. MedCom: the interoperability gatekeeper

What it is. A publicly funded national organisation that owns Denmark's healthcare messaging standards and that tests and certifies suppliers' implementations of them, under a quality management system for test and certification. The certification result is published on a public monthly list, which means a certified supplier is checkable by any Danish buyer in ten seconds.

For a company with no ISO certificate, a public national certification listing is the most credible Danish credential available, and it is state-published rather than self-asserted. It is also free or near-free to the supplier. Pensieve Labs treats it as the highest-value Danish credential to acquire, ahead of any general-purpose security certificate.

The process, in the organisation's own four stages:

Which standards a Danish private hospital actually needs. Not the whole catalogue. The obligatory subset is defined by the agreement between the regions and the private-hospital body, and comprises in substance:

Scoping. A first Danish deployment needs on the order of six to twelve standards certified. At the published four-stage process, run in parallel, that is four to eight months of interoperability engineering plus certification calendar for a team that has not written one before. [ESTIMATE: the research marks the fee, the queue time from order form to live test slot, and whether a supplier without a Danish CVR can be certified as [UNVERIFIED]. None of these figures may be quoted to a customer until resolved from source. dk/README.md Section 5 items 1 and 2.]

Migration to FHIR. The organisation is mid-migration from the legacy syntaxes to HL7 FHIR, with a conversion service bridging the transition. For FHIR standards, certification requires an approved test protocol plus a run-through of the published test material, validated against the implementation guides. Test-script tooling has been made optional for some standards, with test examples accepted instead, which lowers the engineering barrier meaningfully. FHIR messaging implementations must be able to wrap messages in the national transport envelope; FHIR document implementations must demonstrate sharing via the national document-sharing infrastructure.

---

#4. SDN: the network, and who signs for it

What it is. The closed network that carries Danish health data between regions, municipalities, general practice, pharmacies and private providers. It is operated under the messaging organisation's system management with a commercial network supplier. Physical access to the national service platform is via this network. That is the dependency at the top of Section 1.

What connecting requires:

1. an initial consultation with the messaging organisation covering intended use, the services to be consumed and the availability profile required;
2. two signed agreements: a connection agreement, and a processing agreement in one of two versions depending on whether the connecting party acts as controller or as processor;
3. technical onboarding: named contacts, technical information, coordination with the network supplier, local network competence available during installation, and configuration of the software-defined wide-area network equipment terminated in a device installed locally at the connecting party's site.

Cost. Funded principally through the economic agreements between the state, the regions and the municipalities, with a connection fee levied under special rules on private IT suppliers and other connected parties, indexed annually. [UNVERIFIED: the current fee schedule was not retrievable in the research pass. It must be obtained from the messaging organisation before any Danish pricing commitment. dk/README.md Section 5 item 3.]

#4.1 Who holds the connection, per deployment model

This is the structural question and it must be answered per model, not in general.

#4.2 The boundary, stated affirmatively

Edsol Edtech Pvt. Ltd. does not become a Danish health-sector data-sharing participant in its own name. The hospital holds the network connection agreement, the service-platform terms, the medication-record trust agreement and the credentials. Pensieve Labs stores them encrypted in a per-tenant vault and calls the national services as the hospital, on the hospital's own authority. Pensieve Labs's own obligation is the system certification, which attaches to the software rather than to the operator.

This is the same boundary Pensieve Labs asserts everywhere it meets a national digital health scheme, and it is stated as a deliberate architectural position rather than as an apology. DIS-GL-024 states the integration boundary and DIS-GL-025 the credential custody, rotation, revocation and offboarding model.

Caution One caveat that must be verified before this is asserted to a Danish customer. System certification attaches to the software; the trust agreement and the network and service-platform access attach to the organisation. Whether the national authorities will certify a system supplied by a vendor with no Danish legal entity, and whether the messaging organisation will connect a foreign supplier, are both [UNVERIFIED]. dk/README.md Section 5 item 1 and REG-DK-004 Section 2.

---

#5. DM-2: national-service credential isolation

A shared multi-tenant platform reaching national services for several hospitals will attract a question Pensieve Labs must be able to answer in writing before the platform touches those services:

Pensieve Labs does not offer DM-2 into Denmark for a national-service deployment until this statement is executed against the specific tenancy design and is current. DM-1 is the recommendation, and it is also the fastest to go-live.

---

#6. DK Core FHIR conformance

Three profiling layers, and they are not the same thing. Conflating them is the most common error in a Danish technical response.

The identifier model is where naive implementations break. The Danish core patient profile reflects the CPR number together with nationally issued replacement identifiers and regionally issued local identifiers for people who do not hold a CPR number. A hospital operating system built on one national identifier per patient fails on the first tourist, the first newborn and the first unidentified emergency admission, and retrofitting a second identifier namespace into a live patient index is one of the more expensive mistakes available.

Pensieve Labs's position: the patient index supports multiple identifier namespaces natively, with one designated primary per deployment and an explicit merge and unmerge history. What is not yet done is the published conformance statement, naming the DK Core version, the profiles supported, the identifier systems handled and the implementation guides implemented, with canonical URLs so it is machine-checkable. That statement is a market-entry deliverable and is worth more than any narrative claim about interoperability. DIS-GL-029 is the global interoperability disclosure and will carry the Danish section.

---

#7. Journalføring: the gate that is a product requirement

The Danish record-keeping regulation is the one Phase-1 gate that cannot be phased, and it is the one vendors most often quote from a superseded instrument.

The retention obligation outlives the contract, and it is the hospital's, not Pensieve Labs's. On termination the hospital holds the statutory duty; Pensieve Labs's obligation is to hand over an export good enough that the hospital can meet it. Danish counterparties ask what format. The answer is in the Order Form.

---

#8. LPR3 reporting, and the escape hatch that unblocks go-live

Reporting of contacts to the national patient register is mandatory and private hospitals and clinics are within scope. Reporting may be made either through the authority's own reporting portal or from the hospital's own IT system via the reporting service on the national service platform.

Verdict: a hard gate with a manual escape hatch. A Danish private hospital can run Pensieve and report by hand through the portal from day one. That is genuinely useful: LPR3 does not block go-live, it only makes the first months clerically expensive. System integration is a phase-two deliverable.

Say this openly in the proposal. A hospital that discovers a manual interim at acceptance testing has been misled; a hospital told about it at proposal has been given a planning input.

---

#9. MitID, NemLog-in and clinician authentication

---

#10. The phased offer, and how to price it

Sell Phase 1. Win the reference. Then build Phase 2 with a paying customer beside you, which also means certification is done against a real hospital's traffic, which is faster and is better evidence than a synthetic test.

---

#11. Current status: the honest table

Nothing in this table is aspirational and nothing in it is hidden. A vendor whose national-integration status page says "in progress" for every row has told the buyer nothing.

---

#12. Limitations

12.1 Several figures are unverified. Certification fees, queue times, the network connection fee schedule, and whether the national bodies will contract with a supplier lacking a Danish company registration are all [UNVERIFIED] and are listed in dk/README.md Section 5. None may be quoted to a customer.

12.2 The Phase-2 scope is defined by a document Pensieve Labs has not read. The technical annex of the agreement between the regions and the private-hospital body is the Phase-2 requirement set. Obtaining it is the highest-value single piece of Danish fieldwork available.

12.3 Standards move. The national FHIR migration is in progress, and both the core profiles and the implementation guides version. This statement is reviewed on 31 January 2027 and on any certification event.

12.4 This statement claims no certification. Every row of Section 11 that says "none" means none.

---

#13. Related documents

---

#14. Signature

---

#15. Change history