Search all 478 artefacts by title, document ID or content.
Disclosure | Family 14, Jurisdiction Variant Sets
The statutory duties below fall on the dataansvarlig (the hospital) in every deployment model. What varies is only how much of the evidence Pensieve Labs supplies.
This document is the source of truth for: norway-health-record-statute-position
Those surfaces render this text from here. They do not keep their own copy, so they cannot drift from it.
Artefacts this one references or cannot be issued without.
Artefacts that would be blocked if this one were missing or out of date.
DIS-NO-003 v1.0.0, Last Modified On 01 August 2026, Tier: Public
| DM-1 Dedicated | DM-2 Shared | DM-3 Customer Cloud | DM-4 On-Premise |
|---|---|---|---|
| Yes | Yes | Yes | Yes |
The statutory duties below fall on the dataansvarlig (the hospital) in every deployment model.
What varies is only how much of the evidence Pensieve Labs supplies.
Norwegian health records sit under three instruments above the GDPR layer:
| Instrument | What it governs | Relevance to Pensieve Labs |
|---|---|---|
pasientjournalloven, the patient record act |
Processing of health data for the provision of healthcare. Its section 7 sets requirements on the record system itself | Direct. It is why the system, not just the hospital, is assessed |
pasientjournalforskriften, the patient record regulation |
The operative rules. Section 12 carries the general system requirements; section 13 covers access control | Direct, and Section 2 below is the whole reason Norwegian security reviews go deeper than elsewhere |
helseregisterloven, the health registry act |
Health registries and secondary use | Indirect, through the mandatory reporting duty referenced by the regulation. Section 5 |
[VERIFY: the regulation was amended with effect in mid-2026. The existence and commencement of the amendment are established; the substance of the delta was not resolved in the research pass and must be before any Norwegian written claim. no/README.md Section 6 item 3.]
Section 12 of the regulation requires, in substance:
the
dataansvarligmust have control and overview of all processing of health information for which it is responsible, including the making available of information to other undertakings.
That third paragraph is a statutory hook. In most jurisdictions a hospital asking a vendor for a complete data-flow map and a full sub-processor register is exercising good practice. In Norway it is discharging a statutory duty, and a vendor that supplies a partial answer has left the hospital in breach of its own regulation rather than merely under-informed.
Pensieve Labs's response is to supply the answer before it is asked:
| What the duty requires the hospital to have | What Pensieve Labs supplies |
Where |
|---|---|---|
| Control and overview of all processing it is responsible for | The complete description of processing: categories, purposes, locations, durations, per deployment model | DPA-EU-001 Annex I |
| Overview of making information available to other undertakings | The full sub-processor chain with role, country and safeguard, plus a change feed the hospital can subscribe to | DIS-GL-009, DIS-GL-010 |
| A data-flow map it can put in its own documentation | The sanitised network and data-flow diagram, and the detailed version under non-disclosure | DIS-GL-006, DIS-GL-007 |
| Evidence that the overview stays current | A thirty-day change notice with an objection right, and an obligation to update the annexes on change | DPA-EU-001 clauses 7.3, 7.4 |
| Overview of onward disclosure the hospital itself configures | The integration boundary: systems the hospital connects under its own credentials are the hospital's disclosures, not Pensieve Labs's |
DIS-GL-024, DIS-GL-025 |
The regulation's access-control requirements are met by the authentication and authorisation model in
DIS-GL-012, with the entitlements themselves configured by the hospital. The division is deliberate and
is stated so nobody assumes the other party did it:
| Item | Pensieve Labs |
Hospital |
|---|---|---|
| Authentication mechanism, including multi-factor | Yes | Configures its own identity provider where federated |
| Role model and the ability to express least privilege | Yes | Defines the roles and assigns them |
| Enforcement of role-based restrictions on record access | Yes | None |
| Justification-of-access prompt where a record is outside the user's ordinary treatment relationship | Yes | Configures when it applies |
| Access review tooling | Yes | Performs the review |
| Revocation on a user leaving | mechanism | Triggers it |
| Log of every access, immutable and hospital-visible | Yes | Inspects it |
The hospital inspects its own log without Pensieve Labs's cooperation. That is a design commitment
in DIS-GL-013, and in Norway it is the practical answer to the fact sheet on logging and log inspection.
| Requirement | Position |
|---|---|
| Electronic record as the primary form | The Platform is the record. Paper capture is an exception path with a documented reconciliation |
| Author identification | Every entry carries an authenticated author identity and a system-set timestamp the author cannot alter |
| Correction without erasure | A correction is an append-only amendment; the original entry is preserved and both are visible with their authors and times |
| Deletion | Only on a lawful instruction from the dataansvarlig, recorded, and never silently |
| Completeness on handover | A complete, readable, self-describing export in a format that is a contractual term. DIS-GL-023, MSA-EU-001 clause 11.3 |
| Retention | The hospital's obligation, under the applicable Norwegian rules. The Platform's retention configuration supports a per-record clock as well as a fixed term, because Nordic retention rules are commonly measured from the last entry rather than from creation |
Section 12 requires records to be organised so that statutory reporting duties are discharged. Those duties route to the national health registries under the standards in the national catalogue.
Consequence, stated plainly: a Norwegian production hospital deployment is not complete without
registry reporting integrations. That is engineering Pensieve Labs does not have today and cannot
buy, and it must be budgeted as market-entry work.
This is the point on which Norway differs materially from Denmark. In Denmark, national reporting has a
manual portal escape hatch that lets a hospital go live and integrate later. In Norway the reporting duty
is statutory and there is no equivalent supplier-side comfort, so the Norwegian phased offer is narrower
and shorter than the Danish one. STM-NO-002 Section 9 states the boundary and warns against overselling it.
Pensieve Labs's status: not built.
Norwegian interoperability work is governed by the national HL7 affiliate's national basis profiles for FHIR R4, described as the fundamental adaptation of the international resources for interaction in the Norwegian health sector, usable directly or profiled further. Approved profiles are published with an active status on the national profile registry, and the normalisation process is documented publicly.
What Pensieve Labs should publish, and has not yet: a conformance statement naming the profiles
implemented: patient, practitioner, organisation, encounter, condition, observation and medication
statement at minimum, with canonical URLs so it is machine-checkable.
This is a free, verifiable, engineering-only credibility artefact. It costs a few engineer-weeks and it buys standing in every Norwegian technical conversation. It is worth more than any narrative claim about interoperability, and unlike a certificate it can be checked by the reader in thirty seconds.
DIS-GL-029 is the global interoperability disclosure and will carry the Norwegian section.
| Use | Not |
|---|---|
dataansvarlig |
behandlingsansvarlig: the health statutes use the former, and using the latter signals the author has not read them |
databehandler |
processor is correct in English; use the Norwegian term in Norwegian-language material |
databehandleravtale |
data processing agreement is correct in English |
pasientjournal |
patient file, chart |
helsetjenesteyter |
provider, vendor |
DPA-EU-001 Annex IV-2 uses these terms, and the Norwegian-language assurance pack follows them
throughout.
| Claim not made | Why |
|---|---|
| That the Platform is approved or certified under Norwegian health record law | There is no such approval. The statute imposes duties on the dataansvarlig and requirements on the system; it does not confer a certificate |
| That using the Platform discharges the hospital's statutory duties | It does not. The duties are the hospital's; Pensieve Labs supplies the evidence and the capability |
| That registry reporting is delivered | It is not built. Section 5 |
| That national service integrations are delivered | They are not. STM-NO-002 Section 10 |
That Pensieve Labs has assessed the mid-2026 amendment |
It has not. Section 1 |
| # | Item | Owner |
|---|---|---|
| 1 | Define the role model and assign entitlements | Hospital |
| 2 | Perform the periodic access review and record it | Hospital |
| 3 | Inspect the access log, and act on anomalies | Hospital |
| 4 | Maintain its own record of processing and its control-and-overview documentation, using the artefacts in Section 2 | Hospital |
| 5 | Hold the retention decision and configure the period | Hospital |
| 6 | Retain a route for statutory registry reporting until Pensieve Labs delivers the integration |
Hospital, and this must be agreed in writing before go-live |
| 7 | Notify Pensieve Labs of any regulatory change that alters the requirements |
Hospital |
10.1 The mid-2026 amendment is unassessed. Section 1.
10.2 Registry reporting is not built, and no date is offered here. A date belongs in a statement of work against a named customer, not in a disclosure.
10.3 The national profile conformance statement is not published. Section 6.
10.4 Norwegian-language documentation and support are not available, and both are market-entry costs.
10.5 This is not Norwegian legal advice. A Norwegian dataansvarlig carries its own assessment.
| ID | Artefact |
|---|---|
DPA-EU-001 |
Data Processing Agreement: EU/EEA, Annex IV-2 |
STM-NO-001 |
Normen Supplier Conformance Statement |
STM-NO-002 |
Norsk Helsenett and HelseID: Supplier Status |
DIS-GL-006, DIS-GL-007 |
Network and data-flow diagrams |
DIS-GL-009, DIS-GL-010 |
Subprocessor Register and change feed |
DIS-GL-012, DIS-GL-013 |
Access control; audit logging |
DIS-GL-023 |
Data Deletion & Return Disclosure |
DIS-GL-024, DIS-GL-025 |
Integration boundary; credential custody |
DIS-GL-029 |
Interoperability & Standards Disclosure |
| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0.0 | 01 August 2026 |
Privacy | First issue. The control-and-overview duty identified as the statutory hook behind Norwegian security reviews and answered artefact by artefact; the access-control division of responsibility; registry reporting stated as a statutory gate with no manual escape hatch, and the consequent narrowing of the Norwegian phased offer. |