Search all 478 artefacts by title, document ID or content.
Disclosure | Family 14, Jurisdiction Variant Sets
Applies to DM-1, DM-2, DM-3 and DM-4 identically. The same application code and the same standards support ship in all four models. What differs by model is where the integration endpoint sits, which is DIS-AE-008, and whether the hospital or Pensieve Labs operates the network path.
This document is the source of truth for: ae-health-information-exchange-position, ae-claims-integration-position, ae-terminology-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.
Position as at 01 August 2026. DIS-GL-029 is the global standards disclosure and states
which standards Pensieve implements, at which version and with what conformance status. This
document is the UAE fork and states what this market additionally requires, who is responsible for each part
of it, and what Pensieve Labs does and does not hold today.
Applies to DM-1, DM-2, DM-3 and DM-4 identically. The same application code and the same standards
support ship in all four models. What differs by model is where the integration endpoint sits, which is
DIS-AE-008, and whether the hospital or Pensieve Labs operates the network path.
To state Pensieve Labs's position on the three health information exchanges of the United Arab
Emirates, on the electronic claims platform, and on the terminology and identity requirements that attach to
them, honestly, including the vendor-level assessment Pensieve Labs has not yet obtained.
There is no single "UAE integration". There are three, and which ones apply is decided by where the Customer's facility is licensed.
| Regulator | Territory | Health information exchange | Licensing system |
|---|---|---|---|
| Dubai Health Authority (DHA) | The Emirate of Dubai, excluding the Dubai Healthcare City free zone, which has its own regulator | NABIDH | Sheryan |
| Department of Health, Abu Dhabi (DoH) | The Emirate of Abu Dhabi | Malaffi | DoH licensing |
| Ministry of Health and Prevention (MoHAP) | The Northern Emirates, and the federal umbrella | Riayati | MoHAP licensing |
Electronic claims run through eClaimLink, the DHA platform, for Dubai-licensed facilities.
Do not treat "the UAE" as one integration. A hospital group with facilities in Dubai, Abu Dhabi and Sharjah has three onboardings, three sets of credentials and three sets of conformance testing, and each is scoped separately in the Statement of Work.
For a DHA-licensed facility, connection to NABIDH is understood to be a condition of the facility licence itself: a new facility licence is issued inactive and is activated only once compliance requirements are met, and failure to connect is understood to attract regulatory action up to suspension of operations or non-renewal of the licence.
[VERIFY] The specific DHA circular that mandates connection was not resolved to a full reference in the
research behind this document. Its existence is well attested by market sources; its number should be
pulled from the DHA circulars portal before it is cited to a customer.
The commercial consequence, stated for the record because it changes how this market is sold: a Dubai
hospital does not replace a hospital information system because it wants better software. It does so because
its operating licence depends on the system talking to NABIDH. Pensieve Labs sells licence continuity
in this market, and prices accordingly under ADD-GL-019.
There are two things, and both must exist:
| Gate | What it is | Who clears it | Frequency |
|---|---|---|---|
| Vendor-level assessment | The product is assessed as capable of exchanging with NABIDH to the current implementation guide and minimum data set | Pensieve Labs |
Once, then maintained |
| Facility-level onboarding | The specific licensed facility is scheduled into an onboarding batch, exchanges test data against the authority's sandbox, passes system integration testing and receives production confirmation | The Customer, with Pensieve Labs's engineering support |
Per facility, per licence |
A vendor holding the first does not make a facility compliant. Any vendor claiming that its
certification makes the customer compliant is describing the wrong gate. Pensieve Labs states the
distinction at qualification because a group buying for eight facilities is buying eight onboardings.
Pensieve Labs's status, stated without softening
Edsol Edtech Pvt. Ltd.does not hold NABIDH vendor-level assessment status. It has not applied for one. It does not represent thatPensieveis a NABIDH-certified system.
This is a genuine gap, not an architectural boundary, and Pensieve Labs does not dress it as one. It is
the single largest item on the UAE market-entry path and it is tracked in CHK-AE-001 Section 2 as gate U2.
Planning figures from the research behind this document, marked as planning figures rather than commitments:
| Milestone | Indicative elapsed |
|---|---|
| First vendor-level integration, from a standing start | 90 to 150 days |
| Each subsequent facility onboarding, once vendor status exists | 30 to 60 days |
Pensieve Labs will not quote a go-live date to a Dubai hospital that assumes vendor status it does not
have. Where a Customer contracts before that status exists, the Order Form records it as a dependency with a
named owner and the go-live plan is built around it.
The facility onboarding runs in six stages. Pensieve Labs publishes them because a hospital that
understands the sequence plans for it, and a hospital that does not blames the vendor for the authority's
batch schedule.
| Stage | What happens | Owner |
|---|---|---|
| 1. Preparation | Management, IT and clinical leads aligned; a facility project owner named to coordinate with Pensieve Labs and the authority; the authority's circulars and the exchange's guidelines on data sharing, consent and single sign-on reviewed |
Customer, with Pensieve Labs |
| 2. System compatibility | Confirmation that the Platform generates and receives the required message set; confirmation of vendor assessment status | Pensieve Labs |
| 3. Onboarding request | Submission through the exchange's portal of the facility licence details and the system information. The authority reviews and schedules the facility into an onboarding batch | Customer |
| 4. System integration testing | Test messages exchanged against the authority's sandbox covering registration, encounters, prescriptions, laboratory and imaging; defects resolved | Pensieve Labs with the authority |
| 5. User acceptance and sign-off | Testing against the authority's scenarios; secure connectivity and IP allow-listing configured; single sign-on configured where required; compliance approval issued | Pensieve Labs with the authority |
| 6. Go-live and audit readiness | Live transmission; message delivery and error monitoring; consent recording; staff training; periodic compliance audits thereafter | Customer, with Pensieve Labs |
Stage 3 is the schedule risk and it is not Pensieve Labs's to control. The batch wait is set by the
authority. It is on the Customer's side of the responsibility matrix and it belongs in the mutual action
plan (FRM-GL-015) with the Customer's name against it.
| Requirement | Position |
|---|---|
| Exchange format | HL7 FHIR is the stated standard, submitted against the exchange's implementation guide. [VERIFY] Whether the current implementation guide accepts HL7 v2.x messaging in addition to FHIR, and which FHIR release it specifies, was not resolved. This is a material engineering scoping question and the guide must be retrieved from the authority's developer environment before an estimate is committed |
| Minimum data set | Conformance with the exchange's minimum data set is required for facility licensing and renewal. Mapping the Customer's data to it is implementation work and is scoped in the Statement of Work |
| Patient identity | The Emirates ID is the patient identifier and identity matching is performed against it. This is a schema-level requirement, not a field to add later: it changes registration, merge and duplicate-resolution behaviour |
| Terminologies | ICD-10 for diagnoses, CPT for procedures, SNOMED CT for clinical terms, LOINC for laboratory observations (Section 6) |
| Data classes in scope | Demographics, encounters, diagnoses, procedures, prescriptions, laboratory results, radiology reports, vaccinations and discharge summaries |
| Connectivity | IP allow-listing at production, and optionally single sign-on |
| Hosting | A UAE-hosted environment. This is an independent confirmation of DIS-AE-008 from the interoperability side, and it means a residency failure is also an interoperability failure |
There is no authority registration fee. The cost is implementation cost: connector build, minimum data set mapping, and the system integration and acceptance testing cycle. Indicative connector figures circulating in this market are clinic-scale and materially understate a hospital-scale integration; they are useful only as evidence that the authority does not monetise the gate. The real cost is the mapping and the test cycle, and it is quoted per engagement, not from a price list.
eClaimLink is the DHA electronic claims platform and the authority for the DHA-approved coding lists. Registration connects the facility licence, the facility information and the licensed healthcare professionals to the central system, enabling electronic claim submission from the hospital's own systems.
For a hospital operating system in this market, revenue cycle is the product. A large share of a UAE
private hospital's revenue is insurance-funded. A system that cannot produce a clean claim submission is
unsellable regardless of the quality of its clinical modules, and Pensieve Labs treats claims
integration as a first-class scope item and not as a phase-two extra.
| Element | Position |
|---|---|
| Transaction set | Claim, Remittance Advice and Prior Authorisation |
| Coding | The DHA-approved coding lists published through the platform, applied as the source of truth for claim coding |
| Sequencing | Do the exchange and the claims integration as one programme, not two. They are two integrations against the same regulator with overlapping identity and coding requirements, and separating them duplicates the mapping work |
| Abu Dhabi | The Abu Dhabi equivalent applies where the facility is DoH-licensed and is scoped separately |
Pensieve Labs's status |
No integration exists today. It is gate U5 in CHK-AE-001 Section 2 |
| Exchange | Applies when | Position |
|---|---|---|
| Malaffi (DoH Abu Dhabi) | The facility is DoH-licensed. Connection is mandatory for DoH-licensed facilities, with a published list of facilities required to connect and an exemption pathway. Non-compliance is stated to attract warnings, notices and licensing impacts | No integration exists today. Abu Dhabi additionally requires demonstrated conformance with the emirate's healthcare information and cyber security standard before integration (STM-AE-001 Section 4). Abu Dhabi is therefore a stricter market than Dubai, and clearing it clears Dubai |
| Riayati (MoHAP) | The facility is MoHAP-licensed (the Northern Emirates) and as the federal umbrella that integrates the emirate-level exchanges | No integration exists today. A third, separate onboarding with its own criteria. Relevant where the target is a Sharjah, Ajman, Umm Al Quwain, Ras Al Khaimah or Fujairah facility, where several hospitals of the right size operate |
The competitive bar in this market is a vendor connected to all three. At least one vendor markets
exactly that position. Pensieve Labs is not there, and says so. Dubai-only entry is nevertheless the
right first move: one regulator, one gate, and the largest single concentration of private beds.
Pensieve Labs's position: the boundary, restated for this marketThis section is the same boundary DIS-GL-024 states globally, applied here. It is stated affirmatively
because it is a deliberate architectural decision, and it is stated precisely because this market has one
element that the Indian equivalent does not.
5.1 The hospital is the participant. The Customer holds its own facility licence, its own exchange
credentials, its own claims-platform registration and its own professional licences. The Customer is the
regulated participant in every one of these programmes. Pensieve Labs is not, and does not represent
that it is.
5.2 Pensieve connects as the hospital, on the hospital's authority. Credentials, client
identifiers, secrets and certificates are supplied by the Customer, held encrypted in a per-tenant key
vault, and used only for the purposes the Customer authorises. Custody, rotation, revocation, scope and
what happens on offboarding are DIS-GL-025. The addendum is ADD-GL-007.
5.3 The one place this market differs from the Indian model. In India, Pensieve Labs seeks no
vendor-level certification and that is a complete and defensible position. In Dubai a vendor-level
assessment genuinely exists and genuinely applies to the product. Pensieve Labs does not use the
BYOK/BYOC boundary to avoid it or to imply it does not apply.
The boundary is about participation and credentials. It is not a reason to avoid a product assessment that the regulator directs at the product.
Pensieve Labsmust obtain the vendor-level assessment, has not obtained it, and treats it as a market-entry cost rather than an architectural question.
5.4 Responsibility matrix. The allocation between the Customer and Pensieve Labs for each stage of
each onboarding is recorded in a per-engagement responsibility matrix, built to the same structure as the
Indian equivalent at DIS-GL-026, with rows for each exchange in scope and for the claims platform. It is
completed and countersigned before implementation begins, so that no Customer discovers at stage 3 that the
batch request was theirs to make.
| System | Use in this market | Position |
|---|---|---|
| ICD-10 | Diagnoses | Implemented: DIS-GL-029 Section 2 |
| CPT | Procedures, and claim coding | A licence is required. [UNVERIFIED] The licensing route for use in a commercial product in this market was not resolved and must be confirmed before CPT content ships. Cost is a real line item, unlike the WHO classifications |
| SNOMED CT | Clinical terms | An Affiliate Licence is required. [UNVERIFIED] Whether a national member licence covers vendor use in this market was not resolved. Free is not the same as unlicensed (DIS-GL-029 Section 2) |
| LOINC | Laboratory observations | Free under the publisher's licence, with registration (DIS-GL-029 Section 2) |
| DHA coding lists | Claim coding | Taken from the claims platform as the source of truth, versioned in the terminology register with the date they were retrieved |
| Emirates ID | Patient identity | Schema-level. Section 2.5 |
Arabic. A UAE deployment requires Arabic language support and right-to-left presentation for
patient-facing and staff-facing surfaces. Pensieve does not ship this today. It is a
market-entry engineering item, it is on the gating table at CHK-AE-001 Section 2, and it is not represented as a
configuration option.
7.1 No integration to any UAE exchange or claims platform exists today. Sections 2, 3 and 4 describe what is required, not what is built. Every status statement in this document is negative and is meant to be.
7.2 The implementation guide has not been read. [VERIFY] The current NABIDH implementation guide and
policy manual were not retrievable in the research behind this document; the portal is a client-rendered
application that does not yield to automated retrieval. Until they are read, every engineering estimate in
this market carries an unquantified error bar, and Pensieve Labs will say so rather than quote a
number that looks confident.
7.3 No certification of standards conformance is held or claimed, in this market or any other,
DIS-GL-029 Section 6.1 and WPR-GL-005.
7.4 Standards support is necessary and not sufficient. Two systems that both implement FHIR still need a
profile agreement, an identifier strategy and a test cycle. Pensieve Labs issues an interface
specification per integration for exactly this reason (DIS-GL-029 Section 5).
7.5 The exchange schedule is not Pensieve Labs's to control. Section 2.4 stage 3.
| Question | Document |
|---|---|
Which standards Pensieve implements globally, at which version |
DIS-GL-029 |
What Pensieve connects to, on whose authority, and who fixes what |
DIS-GL-024 |
| How the Customer's credentials are held, rotated and returned | DIS-GL-025, ADD-GL-007 |
| The stage-by-stage responsibility matrix | DIS-GL-026 |
| Where the integration endpoint physically sits | DIS-AE-008 |
| The security-standard position, including the Abu Dhabi standard | STM-AE-001 |
Why Pensieve does not interpret clinical data |
DIS-AE-028, DIS-GL-028 |
| The gating table with owners and days | CHK-AE-001 Section 2 |
| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0.0 | 01 August 2026 |
Pensieve Labs Engineering |
First issue. Three exchanges and the claims platform mapped to the three regulators. The vendor-assessment and facility-onboarding gates distinguished. Pensieve Labs's absence of vendor status stated without softening, and distinguished from the participation boundary. |