Wat Medipim is
Medipim is een productdatabase voor de apotheekretail. Fabrikanten leveren er hun productinformatie aan, en apotheken, webshops en groothandels halen die er gestandaardiseerd weer uit: packshots, sfeerbeelden, samenstelling, indicatie, gebruiksinformatie en logistieke gegevens.
De database werkt per land. Voor Belgie gaat het om ruim 220.000 actieve producten en 280.000 afbeeldingen, gekoppeld aan referentiecodes als CNK, EAN en GTIN. Er zijn aparte platformen voor onder meer Frankrijk, Duitsland en Spanje; een aparte Nederlandse database is er niet. Voor een Belgische apotheekwebshop is Medipim daarmee in de praktijk de standaardbron.
Wat een koppeling technisch inhoudt
Medipim biedt een REST-API die JSON teruggeeft, met een sandbox om tegenaan te ontwikkelen en een downloadbare specificatie waarmee je client-code kunt genereren. Er is gedocumenteerde throttling, dus een koppeling moet zich aan een tempo houden en netjes omgaan met wachttijden.
Daarmee is het technische deel voor een ervaren bouwer overzichtelijk: ophalen, vertalen naar de structuur van je webshop, en periodiek bijwerken. De vragen die het project bepalen zijn geen van alle technisch.
De selectie is het eigenlijke werk
Een koppeling die alles importeert wat de database bevat, levert een onbruikbare webshop op. De catalogus is een marktbrede database, geen assortiment: er staan producten in die je niet verkoopt, niet mag verkopen, of die niet meer leverbaar zijn.
Het echte werk zit in de regels die bepalen wat er doorkomt. Welke productgroepen horen bij jouw apotheek, welke prijsondergrens hanteer je, wat doe je met producten zonder foto, en wat met producten die je alleen op bestelling levert. Die regels moeten in de koppeling zitten en niet in iemands hoofd, want ze worden bij elke synchronisatie opnieuw toegepast.
Niet alles mag online, en dat is geen keuze
Voor een apotheek gelden regels over wat je online mag tonen en verkopen. Receptplichtige geneesmiddelen horen sowieso niet in een publieke webshop. Voor voorschriftvrije geneesmiddelen gelden aparte voorwaarden, waaronder een meldingsplicht bij de bevoegde instantie, en er zijn productgroepen zoals grondstoffen die een eigen behandeling vragen.
De database bevat de velden waarmee je die groepen kunt herkennen, bijvoorbeeld de categorie- en de wettelijke status van een product. Een goede koppeling gebruikt die velden als filter dat standaard dicht staat: wat niet aantoonbaar mag, komt niet online. Zet je dat andersom op, dan is een verkeerd ingevuld veld bij de fabrikant genoeg om een probleem te krijgen.
Beschikbaarheid zit er niet in
Dit is de kwestie waar de meeste projecten op stuklopen. Medipim beschrijft welke producten bestaan en hoe ze eruitzien, maar het is geen voorraadsysteem. Of een product vandaag bij je groothandel op de plank ligt, staat er niet in.
Dat betekent dat je een tweede bron nodig hebt als je leverbaarheid wilt tonen: gegevens van je groothandel of uit je apotheeksoftware. Kun je die niet krijgen, wees dan eerlijk op de productpagina. Een label als "op bestelling, onder voorbehoud van beschikbaarheid" bij de producten die je niet op voorraad houdt, kost minder dan een reeks bestellingen die je moet annuleren.
In de database staan is iets anders dan op de markt zijn
Producten verdwijnen uit de handel zonder dat ze uit een productdatabase verdwijnen. Het gevolg is een webshop die artikelen aanbiedt die niemand meer kan leveren, en dat merk je pas als er besteld wordt.
In Belgie bestaat daarvoor een aparte bron: een bestand met de producten die daadwerkelijk op de markt zijn. Door dat naast je catalogus te leggen kun je artikelen die er niet in voorkomen automatisch offline zetten. Dat is een controle die je periodiek moet herhalen, want het bestand wordt regelmatig ververst.
Foto's: bruikbaar, maar controleer ze
Beeld is de belangrijkste reden om een productdatabase te gebruiken: zelf fotograferen is voor een assortiment van deze omvang geen optie. De kwaliteit is over het algemeen goed.
Let wel op twee dingen. Bronfouten bestaan: het komt voor dat bij een variant de verpakking van een andere maat is afgebeeld, en dat is met het blote oog te zien maar niet automatisch te detecteren. En als je een foto handmatig corrigeert, moet je koppeling die correctie herkennen en niet bij de volgende synchronisatie terugzetten naar de bron. Zonder die bescherming doe je hetzelfde werk elke maand opnieuw.
Varianten samenvoegen tot een product
Een lenzenvloeistof in drie formaten of een steunkous in tien maten staat in de database als evenveel losse producten. Zet je die een op een over, dan krijgt je bezoeker tien vrijwel identieke zoekresultaten en moet hij zelf uitzoeken welke maat hij nodig heeft.
Het alternatief is ze groeperen tot een product met een keuzemenu. Dat vraagt een analyse van de productnamen om te bepalen wat de variabele eigenschap is, en die analyse moet voorzichtig zijn: twee producten die alleen in artikelnummer verschillen, zijn soms echt twee verschillende lijnen van dezelfde fabrikant. Bij twijfel is los laten staan beter dan verkeerd samenvoegen.
Onderhoud: een koppeling is nooit klaar
De catalogus verandert dagelijks. Nieuwe producten, gewijzigde teksten, vervangen foto's, artikelen die van de markt gaan. Een koppeling die eenmalig heeft gedraaid, is binnen een paar maanden een verouderde momentopname.
Daarom hoort een synchronisatie herhaalbaar te zijn en alleen te schrijven wat werkelijk verandert. Dat scheelt belasting en het maakt de logboeken leesbaar: als er honderd wijzigingen zijn, wil je die honderd zien en niet verstopt tussen tienduizenden onveranderde regels. Reken bij een catalogus van deze omvang bovendien op een volledige ronde die uren duurt, en plan die buiten je drukste uren.
Per platform
Op Magento is dit het meest natuurlijke thuis: de catalogusstructuur, klantgroepen en varianten zijn erop gebouwd, en een koppeling van deze omvang draait er stabiel. WooCommerce kan het ook, mits je het aantal producten realistisch houdt en de import buiten de webserver om laat lopen. Bij Shopify loop je eerder tegen grenzen aan, omdat je gebonden bent aan wat het platform aan productvelden en importsnelheid toestaat.
Welk platform het beste past, hangt af van de omvang van je assortiment en van wat er verder gekoppeld moet worden. Dat is een gesprek dat vooraf hoort, niet nadat de shop is gebouwd.
Veelgestelde vragen
Wat kost een Medipim koppeling?
Dat hangt af van het platform, de omvang van je assortiment en welke regels er nodig zijn voor wat wel en niet online mag. De koppeling zelf is te overzien; de selectielogica en de compliance-kant bepalen de omvang. We maken een voorstel op basis van wat er werkelijk moet gebeuren, en niet op basis van een standaardpakket.
Heb ik een abonnement bij Medipim nodig?
Ja, de toegang tot de database en de API regel je bij Medipim zelf. Wij bouwen de koppeling met de gegevens die jij daar krijgt; wij verkopen de data niet door.
Krijg ik ook de voorraad van mijn groothandel binnen?
Niet via Medipim: die database beschrijft producten, geen beschikbaarheid. Wil je leverbaarheid tonen, dan is daar een tweede bron voor nodig, bijvoorbeeld vanuit je groothandel of je apotheeksoftware. Kan dat niet, dan werken we met een duidelijk voorbehoud op de productpagina.
Werkt dit ook voor een Nederlandse apotheek?
Medipim heeft platformen per land en voor Nederland is er geen aparte database. Voor een Nederlandse webshop kijken we dus naar een andere bron voor productinformatie. De aanpak blijft hetzelfde: bepalen wat er online hoort, en dat automatisch bijhouden.
Hoe vaak wordt mijn webshop bijgewerkt?
In de praktijk dagelijks, met een volledige ronde die minder vaak draait omdat die bij een grote catalogus uren kost. Wat het beste ritme is, hangt af van hoe snel jouw assortiment verandert; dat spreken we vooraf af.
Kunnen jullie een bestaande koppeling overnemen?
Ja. We beginnen met een inventarisatie: welke producten staan er nu online, op basis van welke regels, en wat gaat er mis. Bij overnames blijkt vaak dat de selectie ooit handmatig is gemaakt en sindsdien niet meer is bijgewerkt.