triqura-ecd/docs/datamodel/onderzoek/onderzoek-leveranciers.md

Onderzoek: datamodellen en publieke API's van Nederlandse ECD/EPD-leveranciers

Status: onderzoeksrapport t.b.v. datamodel-discovery (input, geen besluiten) Datum: 18 juli 2026 Onderzoeker: research-agent "leveranciers" Relatie tot discovery: dit rapport toetst nergens besluiten uit ../deelmodellen/datamodel-discovery.md terug — het levert vergelijkingsmateriaal per deelgebied (§5-besluiten) en markeert hooguit open vragen.

---

1. Aanpak en betrouwbaarheid per bron

Onderzocht via webresearch (juli 2026): Nedap Ons, Medicore, PinkRoccade Zorg (mijnCaress), Adapcare (Pluriform Zorg), en kort SDB/USER, ZilliZ en Praktijkdata. Betrouwbaarheid verschilt sterk:

Leverancier	Publieke API-docs	Diepgang van dit onderzoek
Nedap Ons	✅ Volledig: ons-api.nl + downloadbare OpenAPI-spec (2,8 MB, 772 paden)	Hoog — spec integraal geanalyseerd
Medicore	❌ Alleen marketingpagina's over "Mint" API-platform	Laag — geen resource-niveau vindbaar
PinkRoccade mijnCaress	❌ Geen publieke documentatie	Laag — alleen persberichten/partnerpagina's
Adapcare Pluriform Zorg	❌ Geen publieke documentatie ("Care Connector")	Laag — alleen productpagina's
SDB USER (ex-Avinty)	❌ Geen publieke documentatie ("Connect Service")	Laag
ZilliZ / Praktijkdata	❌ Geen publieke documentatie	Zeer laag

Belangrijkste methodische bevinding: van de onderzochte leveranciers publiceert alleen Nedap zijn API-model openbaar. Al het onderstaande over de anderen is afgeleid uit marketingmateriaal en derden (integratiepartners) — dat is expliciet gemarkeerd. De Nedap-analyse is daarentegen gebaseerd op de letterlijke OpenAPI-specificatie (ons-api.nl/assets/openapi.json, opgehaald 18-07-2026).

---

2. Nedap Ons — volledige OpenAPI-analyse

Nedap Ons is primair een VVT/GHZ/GGZ-suite. De API (ons-api.nl) is REST, zonder versienummers in URL's (resources worden 6 maanden vóór verwijdering gedeprecate), met certificaat-authenticatie en rate limiting ("4 requests tegelijkertijd per certificaat") — bron: API-eigenschappen. De huidige API's vervingen op 19-11-2025 de oude per-applicatie-API's (API-overzicht).

2.1 Domeinindeling (tags in de spec)

De spec groepeert ~250 resource-typen in modules. Relevant voor het ECD:

Module	Kern-resources
administration	Client, ClientAddress, Bsn, Agbcode, Referral, CareProvider, Practitioner (met AgbCode/BigCode/Profession), ClientContactRelation(+Type), ClientEmployeeRelation(+Type), Location, LocationAssignment (incl. WaitingList), Insurance, Document, Team, ExpertiseProfile/ExpertiseGroup
dossier	Report, ReportType, ReportEntry, SoapReportEntry, CarePlan, CarePlanEntry, CarePlanAgreement, CarePlanSignatureRequirement, Goal/GoalEntry, Demand/DemandEntry, Domain, Action/ActionEntry, ClientNote, MedicalNote, SystemNote, Alert, RestrictiveMeasureRegistration (dwang/vrijheidsbeperking)
dossier.episodes	Episode, SubGoal, Action
dossier.medical	Problem, MedicalSummary, PropensityToAdverseReaction (allergieën), advance_directives, involuntary_care (LegalStatus, Incompetence — Wzd/Wvggz), dsm.Classification / dsm.ClassificationSeries
dossier.omaha	Omaha-classificatie (VVT-verpleegkundig: Problem, InterventionCategory, InterventionTarget)
agenda	AgendaSeries, AgendaOccurrence, ClientAbsenceOccurrence, Label, Unavailability, Reservation
carepath	CarePath, Template, ModuleTemplate, IntentTemplate (zorgpaden als sjablonen)
dbc.ggz	Zorgtraject, Subtraject (DBC's — legacy), DiagnoseToekenning
zpm	CareOrderZpmDetails, ZpmGbggzProfiel, ZpmZorglabel, ZpmSetting (Zorgprestatiemodel)
client_story	Story, Category, Answer ("levensverhaal" van de cliënt)
survey	Survey, SurveyResult (vragenlijsten/ROM)
finance	CareOrder, Invoice, DeclarationRule, FinanceType, VecozoInvoiceRelation
openehr	ArchetypeWrapper, CompositionWrapper — Nedap gebruikt intern deels openEHR-composities
overig	medication, moves (roosteren), payroll, wlz/wmo/jw (Zorglegitimatie per wet!), groupcare, tasque (zorgtaken)

Observatie: de wettelijke kaders zijn bij Nedap aparte modules met elk een eigen "Zorglegitimatie"-resource (wlz.WlzZorglegitimatie, wmo.WmoZorglegitimatie, jw.JwZorglegitimatie) plus finance.FinanceType. Het discovery-besluit "wettelijk kader hoort bij de aanmelding" (§5.0.4) is een schonere generalisatie van hetzelfde principe: financieringskader als expliciet gegeven, niet impliciet.

2.2 Cliënt, persoon en verwijzer

• Client is bij Nedap één platte entiteit (geen persoon/rol-splitsing zoals discovery-besluit §5.1 #1). BSN is een aparte resource (/clients/{id}/bsn, aparte autorisatie) — zelfde gedachte als spelregel 3.1 #6: BSN afgeschermd op need-to-know, los van het gewone cliëntrecord.
• Relaties zijn expliciet getypeerd: ClientContactRelation + ClientContactRelationType (waardelijst als resource!) en ClientEmployeeRelation + type. Contactpersonen hebben eigen adres-resources.
• Referral (verwijzing) heeft: referrer, referrerType, referrerCategory, agbCode, institution, specialism, date, documentId, clientId. Verwijzertype en -categorie zijn strings (waardelijsten), AGB-code en instelling zijn aparte velden, en het verwijsdocument is een losse gekoppelde entiteit. Dit spiegelt de discovery-besluiten §5.1 #2-#3 vrijwel één-op-één (verwijzer ≠ praktijk, AGB op beide, verwijsdocument getypeerd los).
• In de (legacy) DBC-flow zit SoortVerwijzer als NZa-waardelijst met code, omschrijving, begindatum, einddatum — waardelijst-items met geldigheidsperioden. Dat detail (waardelijstwaarden die in de tijd geldig zijn) zit nog niet in de discovery-spelregels en is een aandachtspunt voor de referentietabellen.

2.3 Zorgepisodes en trajecten: twee gescheiden werelden

Nedap kent twee losstaande structuren die beide "episode/traject" heten:

1. dossier.episodes.Episode — klinisch-inhoudelijk: clientId, startDate, endDate, evaluationDate, title, goal, subGoals[], gekoppelde problemIds[] (medische problemen), surveyResults[], documents[]. Plus opvallend: autorisatie op episode-niveau (authorizedExpertiseProfileIds, authorizedExpertiseGroupIds) — wie de episode mag inzien is een eigenschap van de episode.
2. dbc.ggz.Zorgtraject — financieel/declaratie: identificatienummer, begindatum, einddatum ("Set automatically based on the state of the DBCs... If null, open; if non-null, closed"), zorgdomein (NZa-codelijst), primaireDiagnose, subtrajecten[] (DBC's, met regiebehandelaar-AGB, directe/indirecte minuten, grouper-resultaat/prestatiecode). Voor ZPM is er een aparte module (zpm.*) die aan een CareOrder hangt.

Relevantie voor discovery §5.1 #9 (ZORGEPISODE): Nedap bevestigt de scheiding klinische episode ↔ declaratietraject als twee entiteiten die naar elkaar verwijzen, niet als één ding. Ook opvallend: rapportages verwijzen naar episodes via episodeIds[] — many-to-many, één verslag kan bij meerdere episodes horen. De discovery gaat nu impliciet uit van één episode per klinisch record; dit is een beargumenteerde open vraag voor de rapportage-ronde (geen bezwaar tegen genomen besluiten).

Diagnose in de DBC-flow: DiagnoseToekenning heeft primair (boolean), datum, en een diagnoseCode uit een NZa-tabel die per code o.a. icd9cm, icd10, prestatiecode-mappings en selecteerbaar/sorteervolgorde bevat. De mapping diagnose→declaratiecode is dus data in een codetabel, precies het patroon van discovery-besluit §5.4 #1 (DSM-registratie met ICD-10-mapping via tabel).

2.4 DSM-classificatie (GGZ-module)

dossier.medical.dsm.Classification (binnen een ClassificationSeries): classificationDate, beginDate/endDate, status ("status of the classification phase" — vrije string, geen enum in de spec), diagnosisDescription, findings, evaluations, GAF-scores (gafStart/gafCurrent/gafEnd/gafMax), immutable (vergrendeld na vaststelling), axis3weight. Het bredere dossier.medical.Problem kent certainty (≈ werkdiagnose vs. definitief), severity, course, onsetApproximateDate/onsetPeriodOfLife, resolvedApproximateDate, snomedExpressionValue en wederom episode-koppeling + autorisatievelden. De as "zekerheid" (certainty) naast klinische status bevestigt het discovery-patroon van twee status-assen (§5.4 open vraag: verificatiestatus + klinische status) als gangbaar.

2.5 Rapportagemodel

dossier.Report is het centrale verslag-record:

• Typering: reportTypeId verwijst naar ReportType, maar de spec documenteert een hardcoded lijst: 101 Rapportage, 102 Gewicht, 103 Bloeddruk, 104 Temperatuur, 105 Bloedsuiker, 106/107 Vocht in/uit, 108 Defecatie, 109 Medisch, 110 Voortgang, 111 Familie communicatie, 112 Keten communicatie, 309 Stemming, 310 Omaha, 311 Saturatie, 314 Pijnscore, 315 SOEP, 316 Bristol, 317 Klinimetrie. ReportType is wél een resource met enabled-vlag, maar de magic numbers staan letterlijk in de API-beschrijving — het anti-patroon dat spelregel 3.1 #1 (waardelijsten als data, één bron) wil voorkomen, hier zichtbaar bij een marktleider.
• Metingen als rapportage: gewicht, bloeddruk enz. zijn géén aparte observatie-entiteit maar rapportagetypen met reportEntries[] (naam/waarde/unit, bv. systolicPressure, 120, mm[Hg]). Genericiteit boven aparte tabellen per meetwaarde.
• SOEP gestructureerd: soapReportEntries[] met soapPart (Subjective/Objective/...), content, en vertrouwelijkheid + autorisatie per SOEP-deel (confidential, expertiseProfileIds). Een verslag is dus deels afschermbaar per discipline.
• Koppelingen: carePlanEntryId (rapporteren op zorgplan-regel/doel), episodeIds[], restrictiveMeasureId, parent/child (reacties op rapportages), reportActions[] (leesbevestiging/actie door discipline X).
• Auteurschap: basisvelden uit AuditedBase (createdAt/updatedAt/createdBy) plus ReportAuthorType: employee / caren (mantelzorger via Caren-portaal!) / external. Familie kán rapporteren; het auteurstype is expliciet. Dit is een smallere variant van de provenance-spelregel 3.1 #2 (die met mens/AI verder gaat).
• Status: ReportStatus is minimaal: 0=OPENED / 1=CLOSED, alleen gebruikt voor communicatie-draden. Rapportages zelf kennen geen workflow-status — wel flagged, confidential, hidden + hidingReason (soft delete met reden).

2.6 Zorgplan (behandelplan-equivalent)

• CarePlan: clientId, employeeId, beginDate, endDate, status — enum DRAFT / ACTIVE / OLD. Versiebeheer werkt via nieuwe plannen (endpoints by_client/active, by_client/draft, activate, archive): het oude plan wordt OLD, er is er hooguit één ACTIVE. Dit is het "nieuw record per versie"-model uit de open vraag van discovery §5.5.
• Hiërarchie: Domain (leefgebied) → Demand (zorgvraag/probleem) → Goal → Action, elk met een "Entry"-variant (de concrete invulling in dít plan: DemandEntry, GoalEntry, ActionEntry) — sjabloon versus instantie gescheiden. CarePlanEntry bundelt demand+goal+acties en draagt percentageTarget/percentageRealized.
• Cliëntakkoord is een eigen entiteit, geen status: CarePlanAgreement (carePlanId, clientId, employeeId) plus CarePlanSignatureRequirement met required en discussionType: discussed / discussed_later / no_discussion / no_agreement. Dit beantwoordt de open discovery-vraag §5.5 ("is cliëntakkoord een status of los feit?") vanuit de praktijk: los feit, met aparte registratie of/hoe het besproken is.
• carepath.CarePath + Template: zorgpaden als sjablonen met modules, geïnstantieerd per cliënt (activeModules, start/einddatum) — vergelijkbaar met "zorgprogramma" als inhoudelijk aanbod (discovery §5.2 #2), maar dan geoperationaliseerd.

2.7 Wachtlijst

LocationAssignmentWaitingList is een subtype van LocationAssignment (type WAITING_LIST), letterlijk gedocumenteerd als: "Developed as a (temporary) solution to enable (GGZ) customers to indicate a client is on a 'waiting list'". Velden: waitingFor, status ("Wachtstatus (urgentie)"), description, classification (alleen Wlz, ZN-classificatie zoals DREIGENDE_CRISIS_THUIS), closingReason ("Assumed use: BI tooling"). Bij álle waardevelden staat: "Possible values are defined by the care organisation" — volledig instellingsconfigureerbare waardelijsten, niets hardcoded. Voorbeeldwaarden: waitingFor: BESCHIKBARE_PLEK, status: ACTIEF_PLAATSEN, closingReason: GEPLAATST.

Relevantie voor discovery §5.3: zelfs de marktleider heeft wachtlijst als noodoplossing aan locatietoewijzing gehangen. Het discovery-besluit (WACHTLIJSTPLAATSING als eigen entiteit met soort aanmeld/behandel, prioriteit en beëindigingsreden) is structureel sterker dan wat Nedap publiek biedt; de Nedap-les die overblijft is: maak prioriteit, wachtreden én beëindigingsreden instellingsconfigureerbare waardelijsten.

2.8 Agenda

Klassiek series/occurrence-patroon: AgendaSeries (herhaalregels: recurrenceType, weekdagen, cycleInterval, validFrom/To) en AgendaOccurrence (concrete afspraak, met clientPresent, registered, registrationComplete, hourTypeId → koppeling naar tijdregistratie/declaratie, labels, uitnodigingen voor cliënt en medewerkers). Afwezigheid van cliënten (ClientAbsenceOccurrence + ClientAbsenceReason als waardelijst-resource) is een aparte structuur. presence_logs verbinden agenda met aanwezigheidsregistratie (klinisch/verblijf). Les: afspraak-realisatie ("registered") en de afspraak zelf zijn gescheiden assen — relevant voor de agenda-ronde i.c.m. ZPM (planning ≠ geleverde prestatie).

2.9 FHIR/zibs-positie van Nedap

De eigen API is niet FHIR — het is een proprietary REST-model. FHIR/zibs zit in een aparte documentatiesectie (ZIBs en FHIR) als uitwisselingslaag ernaast (o.a. harmony.ZorgdomeinFhirConnector in de spec, nuts.Consent voor het Nuts-netwerk). Dit ondersteunt de discovery-koers (§4): eigen model als kern, FHIR als adapter aan de rand. Zelfde geldt voor Nedaps interne openEHR-gebruik: wrapper-resources, geen leidend API-model.

---

3. Medicore (ECD/EPD, veel gebruikt in GGZ/jeugdzorg)

Niet publiek vindbaar: resource-lijsten, entiteiten, statussen of een developer-portal. Wat wél uit publieke bronnen blijkt:

• Medicore heeft een API-/integratieplatform "Mint" (Medicore Integrated) met "35+ partners"; genoemde integratiedomeinen: medicatie, roosterplanning, speech-to-text, eigen apps. Standaarden: HL7, FHIR, OpenID Connect, Azure. Bron: API-platform, Mint-oplossingenpagina.
• De EPD-pagina noemt als product-onderdelen: Mijn Medicore, Zorgapp, UP (AI-assistent), API-platform, Wellbee-cliëntportaal — geen module- of entiteitenlijst op datamodel-niveau. Bron: EPD-pagina.
• Medicore werkt "al jaren met open standaarden zoals MedMij en HL7 FHIR" (bron: kennisartikel Medicore UP); dat maakt aannemelijk dat externe koppelingen FHIR-resources gebruiken (MedMij-gegevensdiensten zijn per definitie FHIR), maar hoe het interne datamodel eruitziet is niet publiek.
• Toegang tot documentatie loopt via contact/partnerschap; er is geen publieke Swagger/OpenAPI gevonden.

Conclusie: "Medicore = FHIR-based API" (aanname uit de opdracht) is publiek niet verifieerbaar op resource-niveau; verifieerbaar is alleen dat hun koppelplatform FHIR als standaard noemt.

4. PinkRoccade Zorg — mijnCaress

Niet publiek vindbaar: API-referentie, entiteiten, waardelijsten. Wat wél blijkt:

• mijnCaress (VVT/GHZ-ECD, geen GGZ-focus) positioneert zich als "API-based... één platform" en "steeds meer open"; werken met API's wordt genoemd als voorwaarde om data "gestandaardiseerd beschikbaar te stellen voor uitwisseling in de zorgketen". Bronnen: mijnCaress VVT, zoekresultaat "mijnCaress wordt steeds meer Open" (pagina zelf inmiddels 404).
• Concrete koppelingen die publiek beschreven zijn: ZorgDomein ↔ mijnCaress via HL7 FHIR (verwijzingen ontvangen en verwerken in het ECD) — bron: ICT&health, FMT Gezondheidszorg; identity-koppelingen via Tools4ever; zorgapp-koppelingen via CareConnections.
• Het mijnCaress Platform-overzicht noemt modules (Medewerkerportaal, Zorgapp, Cliëntportaal, Financieel, Stuurinformatie, Spraakgestuurd rapporteren) maar nul technische documentatie.

Conclusie: geen bruikbaar datamodel-vergelijkingsmateriaal; alleen het signaal dat verwijzingen-instroom via FHIR (ZorgDomein) sectorbreed de norm wordt — relevant voor de latere adapter/instroomkant van AANMELDING.

5. Adapcare — Pluriform Zorg

Niet publiek vindbaar: API-referentie of entiteitenmodel. Wat wél blijkt van de GGZ-productpagina:

• Pluriform Zorg is een "workflowgestuurd ECD" voor het "complete GGZ-behandeltraject", met als genoemde processtappen: intake en diagnostiek → behandeling → crisis → nazorg, voor ambulante gesprekken én klinische opnames; "ondersteunt alle financieringsvormen binnen de GGZ" (incl. forensisch).
• Integratie via de "Adapcare Care Connector": "integreer je op basis van open standaarden (zoals FHIR, ZIB's en openEHR)" plus CACAO-samenwerkingsplatform. Geen documentatie van wat er achter die connector zit.

Conclusie: het proces-vocabulaire (intake/diagnostiek/behandeling/crisis/nazorg als fasen van één traject) bevestigt de fasering die de discovery in AANMELDING → ZORGEPISODE modelleert, maar op datamodel-niveau valt niets te verifiëren.

6. Kort: USER (SDB), ZilliZ, Praktijkdata

• USER is het GGZ-EPD van Avinty, sinds april 2023 onderdeel van SDB Groep (níet van ZilliZ — de opdrachttekst suggereerde "Zilliz/USER", dat klopt niet). De USER-productpagina noemt: Agenda als "het centrale punt rondom plannen, rapporteren en registreren", multidisciplinair zorgplan waaraan de cliënt meeschrijft, rapportage-overzicht "Voortgang / Decursus" over alle disciplines, Metingen, Zorgviewer, en facturatiestromen "ZPM, WLZ, WMO en FZ". Koppelingen via een "Connect Service" ("fundamenteel open ecosysteem") — geen publieke API-docs. Interessant vocabulaire-detail: GGZ-rapportage heet hier decursus, en de agenda is expliciet de spil tussen plannen, rapporteren en (ZPM-)registreren.
• ZilliZ (zilliz.nl) is een ECD voor kleinschalige zorg (rapportage, geleverde zorg boeken, facturatie, Vecozo/CAK-berichtenverkeer). API-koppelingen bestaan (REST/SOAP, via partners zoals Brixxs) maar zijn niet publiek gedocumenteerd.
• Praktijkdata (Telasoft) is een EPD voor GGZ-praktijken (psychologen/psychiaters/therapeuten) met koppelingen naar o.a. SnelStart, BergOp (ROM) en MyMindspace (eHealth). Documentatie alleen op aanvraag.
• Koppeltaal 2.0 (geen leverancier, wel hét GGZ-koppelvlak voor eHealth): FHIR R4 + zib2020, met verplichte profielen voor Patient, Practitioner, CareTeam, Organization, Task, ActivityDefinition, RelatedPerson — eHealth-modules worden als ActivityDefinition aangeboden en als Task aan een cliënt toegewezen. Bronnen: Simplifier-package, Koppeltaal 2.0 Dev Guide. Relevant zodra het ECD eHealth-interventies aan behandeldoelen koppelt (discovery §5.5, interventies).

---

7. Dwarsdoorsnede: wat dit betekent voor het Triqura-datamodel

Per discovery-deelgebied, zonder besluiten terug te draaien:

1. Waardelijsten (spelregel 3.1 #1) — Nedap laat beide uitersten zien: ReportType met magic numbers ín de API-docs (het anti-patroon) én wachtlijstvelden die volledig "defined by the care organisation" zijn (het gewenste patroon). Extra les: NZa-achtige waardelijsten (SoortVerwijzer, Zorgdomein, diagnosecodes) dragen bij Nedap geldigheidsperioden (begindatum/einddatum per waarde). Overweging voor de referentietabellen: geldig-van/geldig-tot per waarde opnemen.
2. Episode ↔ declaratietraject (besluit §5.1 #9) — bevestigd door Nedap: klinische episode en zorgtraject/DBC/ZPM zijn gescheiden structuren die naar elkaar verwijzen. Open vraag voor de rapportage-ronde: Nedap koppelt verslagen many-to-many aan episodes (episodeIds[]).
3. Verwijzer (besluiten §5.1 #2-#3) — Nedaps Referral (referrerType, referrerCategory, agbCode, institution, specialism, documentId) valideert de gekozen decompositie; niets gevonden dat ertegen pleit.
4. Wachtlijst (besluit §5.3) — geen leverancier heeft dit publiek beter opgelost dan het discovery-besluit; Nedap noemt zijn eigen oplossing letterlijk tijdelijk. Beëindigingsreden ("closingReason... assumed use: BI tooling") als configureerbare waardelijst wordt door de praktijk bevestigd.
5. Diagnose (besluiten §5.4) — twee status-assen (certainty + klinische status) en mappingtabellen met ICD-9/ICD-10-kolommen per diagnosecode zijn bij Nedap staande praktijk; immutable na vaststelling is het equivalent van "definitief vastgesteld". GAF-scores op de classificatie zijn DSM-IV-erfgoed — niet overnemen, wel een waarschuwing over hoe classificatie-historie in een model versteent.
6. Behandelplan (§5.5, open vragen) — Nedap beantwoordt twee open discovery-vragen vanuit de praktijk: statusmachine minimaal (DRAFT/ACTIVE/OLD, één actief plan, versie = nieuw record) en cliëntakkoord als los feit (CarePlanAgreement) met een aparte besprekingsstatus (discussed/discussed_later/no_discussion/no_agreement) — dat laatste dekt de WGBO-realiteit dat een plan besproken-maar-niet-akkoord kan zijn.
7. Rapportage (latere ronde) — Nedap-patronen om mee te nemen: metingen als generiek entry-mechanisme i.p.v. tabel-per-meetsoort; vertrouwelijkheid/autorisatie per verslag-onderdeel (SOEP-deel) en zelfs per episode; auteurstype als enum (medewerker/naaste/extern — bij Triqura komt daar AI bij, spelregel 3.1 #2 gaat verder); verbergen met reden i.p.v. verwijderen.
8. FHIR-positie (§4 discovery) — geen enkele onderzochte leverancier gebruikt FHIR als intern datamodel. Nedap: proprietary REST + FHIR/zibs als rand. Medicore/PinkRoccade/Adapcare: FHIR genoemd als koppelstandaard. De discovery-koers (eigen model, FHIR als adapter) is marktconform.
9. Openheid als onderscheid — alleen Nedap publiceert zijn API volledig. Een publiek gedocumenteerde, semantisch rijke API (uit FCO-IM-feitzinnen afleidbaar) zou voor Triqura een reëel concurrentievoordeel zijn in een markt waar documentatie achter partnercontracten zit.

8. Expliciet: wat NIET publiek vindbaar is

• Interne datamodellen/ERD's van álle leveranciers (ook Nedap publiceert alleen het API-vlak, niet het databaseschema).
• Medicore: elke resource-/entiteitenlijst, statussen, waardelijsten; het bestaan van een FHIR-API is aannemelijk maar niet op resource-niveau verifieerbaar.
• PinkRoccade mijnCaress: elke technische API-documentatie; de "steeds meer open"-pagina is inmiddels offline (404).
• Adapcare: alles achter de "Care Connector"; geen spec, geen resources.
• USER/SDB: alles achter de "Connect Service"; ook GGZ-instroomfunctionaliteit (aanmelding/wachtlijst) is publiek onbeschreven.
• Wachtlijst-/aanmeldstatussen en instroomworkflows: bij geen enkele leverancier publiek gedocumenteerd behalve Nedaps wachtlijst-resource.
• Dit onderzoek heeft geen toegang gehad tot partnerportalen, NDA-documentatie of demo-omgevingen; alles hierboven komt uit openbare bronnen d.d. 18-07-2026.

9. Bronnen

Nedap Ons (primair, hoge betrouwbaarheid):

• ons-api.nl — Wat is Ons API? · API-overzicht · API-eigenschappen · ZIBs en FHIR
• OpenAPI-specificatie (json, geanalyseerd 18-07-2026)
• Nedap Ons support — What is Ons API?

Medicore:

• API-platform · Mint-oplossingen · EPD · Medicore UP / standaarden

PinkRoccade mijnCaress:

• mijnCaress Platform · mijnCaress VVT · ZorgDomein-koppeling via FHIR (ICT&health) · FMT Gezondheidszorg

Adapcare:

• Pluriform Zorg GGZ · Adapcare

USER / ZilliZ / Praktijkdata:

• USER EPD (SDB Zorgt) · SDB EPD GGZ · ZilliZ · Brixxs — API-koppeling ZilliZ · Praktijkdata ↔ SnelStart · BergOp EPD-koppelingen · MyMindspace ↔ Praktijkdata

Koppeltaal (context):

• Koppeltaal 2.0 package (Simplifier) · Koppeltaal 2.0 Dev Guide