Innspill til veileder og krav til korrekt grunndata versjon 3 Mange av våre medlemmer inngår i store internasjonalt konsern. Det betyr at de ikke «eier» sin egen logistikkløsning og har færre muligheter for lokale tilpassinger enn flere av leverandørene til Helse SørØst. Det vil også gjenspeile deler av innspillene. Utgangspunktet for innspillene er høringsutkastet, samt at det er vedlagt en informasjonsmail som et eksempel på at endringer ofte iverksettes før samarbeidspartnere informeres, og at man ikke forholder seg til malene som er utarbeidet av IBX og som hensyn tar internasjonal praksis. Dette er et vesentlig poeng fordi det største problemet med Sykehuspartner sin løsning for leverandørene, er at de ikke tar hensyn til en av de to viktigste grunndata, nemlig base enhet (salgsenhet). LFH ber også Sykehuspartner være oppmerksomme på følgende: En leverandør kan kun ha en katalog for alle sine avtaler enten det gjelder HSØ forsyningssenter, HSØ eller HF katalog. Det betyr også at alle endringer får tilbakevirkende kraft. Som i praksis betyr masse ekstraarbeid for leverandørene. Helse Sørøst har et overordnet krav om å tilrettelegge for å opprettholde SMB-markedet i Norge. Det betyr at de generelle logistikkbestemmelsene bør hensyn ta det faktum at flertallet av leverandørene ikke har så mange ansatte og har begrensede ressurser tilgjengelig for å levere på de ulike delene av avtalen. Hos de fleste er det de samme ressursene som laster opp bilder, forhandler avtaler og svarer på anbud. Med henblikk på dette vil det være en stor fordel om man også kan ha fokus på rasjonelle løsninger som gir merverdi og data som kan gjenbrukes. Likebehandling av leverandører betyr ikke å sette samme forventninger til en bedrift med 15 ansatte som en med 150 ansatte. Pkt. 4 Det bør innføres praksis for at Sykehuspartner varsler om endringer i de elektroniske testene som ligger i opplastingsfunksjonen hos IBX - det er det ikke i dag. (Eksempel fra 2013; valideringsregelen med at produktbeskrivelse skulle være lenger enn produktnavn ble ikke varslet i forkant. ) Svar SP: Det vil gjennomføres varsling når validering av katalog via IBX endrer seg. Det er ikke alle HF som har etablert en struktur som gjør det mulig å lage kataloger til det enkelte HF. Eksempelvis så vasker OUS alle kataloger i forhold til hva de kjøper fra før grunnet plassmangel på artikkelnivå, og da blir det vanskelig å implementere ny avtale. Svar SP: HSØ kan ikke se at dette er relevant for leverandører. Leverandør plikter å sende inn katalog som ivaretar det avtalemessige eller avtaltesortiment mot hvert enkelt HF. Pkt. 5.1 Generell problemstilling rundt IBX kataloger er at man ikke kan ha samme artikkelnummer i katalogen flere ganger (ref. punkt 5.2). HSØ krever katalogdata på nye avtaler stadig tidligere i prosessen men det blir stopp når en eller flere artikler allerede FORSKNINGSPARKEN Gaustadalleen 21, 0349 Oslo Telefon: +47 23 16 89 20 Foretaksnr.: 971 283 602 e-mail: info@lfh.no www.lfh.no LFH er bransjeorganisasjonen for helse- og velferdsteknologi. LFHs medlemsbedrifter produserer, distribuerer, og selger medisinsk utstyr, forbruksmateriell, og hjelpemidler til personer med funksjonsnedsettelser. Medlemsbedriftene leverer sine produkter og tjenester til både helseforetak, NAV, kommuner, samt det private helsemarkedet i Norge.
ligger på avtale som skal utgå til fordel for ny avtale. Løsning på dette kan være at HSØ/IBX endrer dette kravet slik at man begrenser det til å gjelde innenfor et avtalenummer i stedet for på hele katalogen. Svar SP: punkt 5.1 er knyttet til innsendelse av avtaleinformasjon til SP som ikke skal lastet opp gjennom IBX. Det vil ikke være behov for å oppdatere med gammel og ny avtaleinformasjon på samme artikkel. Hvis punktet er relatert til innsendelse av katalog gjennom IBX (punkt 6.1) er det teknisk begrensinger hos IBX som ikke tillater samme artikkelnummer på flere avtaler. Dette betyr at man må benytte én katalog per avtale. Siste punkt om ledende nuller ol dette er ikke mulig å imøtekomme for mange av leverandørene som er del av store internasjonale selskap med felles artikkelstruktur. Svar SP: Dette er kun en anmodning, og ikke et krav. Det er erfaringsmessig problematisk å håndtere ledende nuller når data transporteres mellom systemer. Pkt. 5.2 Leverandørens artikkelnavn bør ikke røres ettersom dette er unikt og bør være likt i alle systemer, kataloger samt på produktforpakninger. Artikkelnavnet bør være navnet vi leverandører leverer og benytter i alle markedene vi opererer i. Kravene som stilles til artikkelnavn burde heller være en del av produktbeskrivelsen. Svar SP: SP har behov for konsistente artikkeltekster ifm. avtaleinngåelse og sammenlikning av artikler på tvers av leverandører. Praksis rundt navngivning av artikler ifm. anskaffelse har vært praktisert i flere år. Produkttype kan Helse Sørøst selv legge opp til ved å mappe opp vårt artikkelnavn og nummer med eget tekstfelt. Svar SP: Det forventes at leverandørene er produktspesialister på eget sortiment. Dette er viktig informasjon for brukere av artiklene. Kravet om at teksten i katalogen må tilsvare tekst på fakturaen blir urimelig når leverandørene ikke kan bruke egne produktnavn. Svar SP: Dette vil ikke være et absolutt krav, men HSØ jobber for konsistente data gjennom hele forsyningskjeden. Vær også oppmerksom på at de fleste ERP systemer har en begrensning på antall karakterer som er langt lavere enn 160. Svar SP: Dette er vi oppmerksomme på. Leverandørene gis kun anledning til å legge inn merke/modell når dette er nødvendig for sikker identifikasjon, mens disse opplysningene brukes på faktura. På bakgrunn av våre erfaringer og kunnskap om ERP systemer stiller vi spørsmål om dette feltet strengt tatt er påkrevet? Hvis ikke pålegger Helse Sørøst med dette leverandørene å gjøre en stor manuell tilpassing som ingen har særlig nytte av. (Dersom sikker gjenkjenning er viktig vil det kanskje være mer hensiktsmessig å ta hensyn til dyslektikere og fargeblinde. Disse kan ha store problemer med formatet som kreves)
(Elektronisk gjenkjenning av faktura har heller ingenting med navnefeltet å gjøre ettersom den styres av artikkelnummer. ) Vær også oppmerksom på at flere HF ikke laster opp produktbeskrivelsen og de har derfor behov for opplysninger om merke/modell og størrelse for sikker identifisering. Sar SP: Hvis merke/modell ikke er relevant for identifisering av vare, vil nøytral navngivning av artikler gi HSØ en gevinst ved å opprettholde konsistent informasjon på artikler. Store/ små bokstaver: kravet til at samtlige ord skal skrives med store bokstaver medfører mye ekstraarbeid. ( Ikke er det korrekt norsk heller) Svar SP: Det foreligger ikke krav om gjennomgående store bokstaver, kun krav om stor forbokstav på attributt-tekster. Nøkkelinformasjon: Dette punktet bør ikke være et skal krav men et punkt som leverandørene kan fylle ut dersom det er hensiktsmessig. Noen artikler har ikke mange nok punkt til at leverandørene klarer å fylle ut unik informasjon på alle de fire feltene type, modell, nøkkelinformasjon og artikkelnavn. Svar SP: Det er krav om nøkkelinformasjon hvor det er avgjørende ved identifisering av rett produkt f.eks. hvis størrelse er av betydning for produktet. Hvis artikkel ikke har relevant nøkkelinformasjon, vil vi ikke kreve dette. Alt i alt resulterer summen av alle disse kravene i at man ender opp i veldig mange ulike måter å beskrive en artikkel på. Dette vil øke risiko for misforståelser og feilt når man må «finne opp» gode, nye måter å beskrive produktene på. Svar SP: Leverandørene benytter i dag forskjellig struktur og innhold på artikler innfor samme kategori. HSØ sin veileder har til hensikt å oppnå en konsistent tilnærming til navngivning slik at det kun foreligger én metodikk for utferdigelse av tekster. Hensikten er at vi gjennom hele verdikjeden opererer med samme struktur og innhold hos alle parter. 5.4 At dette etterspørres i anbudsprosessen er forståelig men at det skal være katalogdata kan vi ikke forstå bakgrunnen for. Hvordan er dette relevant etter at en kontrakt er inngått? Svar SP: Produksjonsland er ikke et krav ved innsendelse av katalog via IBX. Pkt. 5.6 Pkt. 5.8/5.9 Dette punktet gir ikke merverdi for mange sykehus ettersom de ikke tar inn feltet i det hele tatt f.eks. Ahus. Den elektroniske valideringen som ligger i opplastingsfunksjonaliteten på e-handelsplattformen bør fjernes. Svar SP: Dette er ikke et krav ved innsendelse av katalog via IBX. Enhetsprisen DDP HF Sykehuspartner er konsekvent på sitt valg av enhetspris ned i stykk. For mange skaper dette trøbbel. Base enheten bør være salgsenheten (slik malen fra IBX er bygget opp). Ved å endre enheten til korrekt baseenhet, kan leverandører levere likt til alle HF,
gjenbruk av data som allerede finnes systemet samt bruke korrekte enheter i forhold til bestilling/faktura/kreditnota. Sykehuspartner krever katalogen levert i et utregnet format - det bør de selv kunne ordne opp i. Dersom malen til IBX følges vil alle opplysningene som trengs for å få dette, regnet ned i EA være tilgjengelig og Sykehuspartner kan gjøre dette. (Dette sparer leverandørene for unødig ressursbruk og vil være med på å jevne ut den ulike belastningen for små og mellomstore leverandører.) Svar SP: Punket 5.8 og 5.9 relaterer seg til avtaleinngåelse og prisskjema som benyttes ved etablering av artikler på avtale. Helse Sør Øst inngår avtale på minste enhet, derfor er informasjonen under dette punktet påkrevd. I forhold til IBX må kataloginformasjon være korrekt mht. avtaleinformasjon for å kvalitetssikres. Pkt. 5.13 Pkt 6.1 Pris pr. salgsenhet bør være pris pr. salgsenhet og ikke antall primærenheter * pris pr. primærenhet. Ref regnestykket en ekse fyrstikker til kr. 1,89 med 160 stk (regnevei er viktig for å få riktig antall desimaler) Sar SP: Se punktet over (5.8 og 5.9). Siden avtalen utledes av pris på stykk-nivå, må salgsstørrelse respondere på pris oppgitt. Siste punkt om ledende nuller ol dette er ikke mulig å imøtekomme for mange av leverandørene som er del av store internasjonale selskap med felles artikkelstruktur. Svar SP: Dette er kun en anmodning, og ikke et krav. Det er erfaringsmessig problematisk å håndtere ledende nuller når data transporteres mellom systemer. Pkt. 6.2 Se pkt. 5.2 Pkt. 6.3 Svar SP: Se kommentarer under punkt 5.2 Se pkt. 5.3. I tillegg er det viktig å informere leverandører om at dette ikke implementeres i alle systemer slik at vi ikke legger nøkkelinformasjon her. Svar SP: Vi finner ikke innspill under punkt 5.3. Men vi må ta høyde for at alle systemer ivaretar produktbeskrivelse. Pkt. 6.6. Vi stiller spørsmål ved valg av overgang til versjon 13.( Har ikke denne vært forkastet tidligere?). Internasjonalt er det i bransjen et større fokus på versjon 15 og 16 så det kan være hensiktsmessig å velge en av de versjonene fremfor 13. Svar SP: Dette er en beslutning som ble tatt ifm. etablering av regional ERP-løsning. Det jobbes parallelt med å se på muligheten til å endre versjon. Pkt. 6.7 Her bruker Sykehuspartner feltet til noe helt annet enn det det er tiltenkt. I dette feltet bør det heller stå hvor mange salgsenheter man må bestille for å oppnå den prisen som ligger i den merkantile avtalen. Svar SP: Dette mener HSØ ikke medfører riktighet. HSØ krever at leverandørene benytter salgsenhet i IBX-katalogen under feltet Enhet. Dette betyr at man alltid vil benytte den praksisen som er gjengitt i veilederen. Unntaket kan være hvor avtalen er basert på volumkjøp, men dette håndteres gjennom andre tiltak.
Pkt. 6.8 Se pkt. 6.7 og følg IBX malen Svar SP: Se punkt 6.7 Pkt 6.11 Det bør informeres om tidspunkt for når dette feltet aktiveres i de ulike systemene, og ikke legges inn før den aktuelle datoen. Det er ikke lett å unngå ord som allerede finnes i artikkelnavnet. Svar SP: Her oppfatter vi at leverandøren ikke har forstått hensikten med feltet. Feltet benyttes for å sikre god søkbarhet. Vi vil endre veilederen slik at artikkelnavn kan være en del av synonymer, men poengterer at det ikke vil være et behov å gjenta tekst til synonymer. Hvis man har gode artikkeltekster og beskrivelser, så vil behovet for synonymer reduseres. Pkt. 6.14 Dette feltet er unødvendig da antall pr. salgenhet allerede er opplyst. Hvis oppdragsgiver også ønsker dette i tekst kan de selv lage script som hensyn tar dette ønsket fremfor å belaste leverandørene med ekstrajobben. Svar SP: Dette er et spesifikt krav fra blant annet OUS. Pkt. 6.15 Dette er greit, men det er en snedig detalj at i hstat er det helt i orden å rapportere omsetning på base enhet (salgsenhet) mens det i MDM prosjektet er EA som er enheten. Dette betyr også at sykehusene ikke kan benytte datagrunnlagene for sammenlignbare tall. Svar SP: I MDM opererer vi med minste enhet EA/PR og det som omtales som baseenhet over, altså salgsenhet (type CT,BX,PK etc.). SP ønsker å sikre enhetsinformasjon på artikler mellom systemer og på tvers av plattformer. Dette mener vi at vi for de fleste artikler har i dag, men at det kan være nødvendig med ytterligere presiseringer og krav til omfang av enhetsinformasjon mellom partene sett i takt av behov hos brukere og system. Pkt. 6.17 Det er et urimelig krav at alle produkter skal ha bilder. Vi forstår tanken om at dette kan være hensiktsmessig for de mest vanlig produktene eller på produktgruppe nivå, men i praksis er det slik at de som bestiller som regel kjenner produktet godt (og derfor ikke trenger bilde) eller det er en som uansett ikke vil kunne tyde det avbildete produktet ( slik som merkantilt personale). Dersom målgruppen for fotografiene er andre enn de faglige brukergruppene på sykehus og Forsyningssenteret; er det kanskje et tankekors at de bildene som spesifiseres aldri vil aldri være det de ser? Ref. Forpakninger og enheter. Svar SP: Dette er feil oppfattet og aktuelt for alle brukere, også spesialister. Dette er et tydelig krav fra foretak, og gjelder alle kategorier og artikler. Pkt. 6.18 Kontrakts navn er unødvendig. Dette kan oppdragsgiver gjerne mappe opp selv om de ønsker, leverandørene bør kun levere nummer (som er utfordrende nok når det kommer til lokale avtaler).
Pkt. 6.19 Se pkt. 6.18 Svar SP: Kravet opprettholdes, men HSØ vil se på mulighet for å lempe på kravet. Pkt. 7.1 Svar SP: Kravet opprettholdes ME bør ikke være primærenheten i innkjøpsportalen, men salgsenheten. Svar SP: ME på laveste nivå ivaretar regionale enhetsbehov. Pkt. 7.2 Dersom minste forpakningsenhet opprettholdes i EA så har ikke dette feltet mening (det er heller ikke utfylt i veilederen). Svar SP: For enkelte artikler vil dette ha betydning da nivået for minste enhet kan inneholde mindre forbruksstørrelser. Pkt. 7.3 Igjen, salgsenhet som baseenhet og ikke EA Svar SP: Se overliggende kommentarer Pkt. 7.4 I forrige felt var det fem desimaler og her er det fire. Se igjen eksempelet med fyrstikkesken i pkt. 5.13 (her er det to desimaler). Svar SP: Det er kun tillatt med 4 desimaler for forrige felt. (punkt 7.3)