Medical Technology Device Design

Utvikling av et produksjonsklart design for et integrert instrument (benchtop) for mikroflyt-/mikrofluidikkbasert biologisk celleprosessering og motility-imaging. Løsningen skal være MDR-klasse 2A-kompatibel (compliance-test-ready dokumentasjon), testes på bakken med minst to produksjonsprototyper (Rev 1 og Rev 2), og inneholde optisk/optomekanisk, termisk, elektronikk/PCB, firmware, kraft/distribusjon og bruker-/servicegrensesnitt. UiT skal motta design- og test-/compliance-dokumentasjon samt firmware-repositorium; eierskap til produkter i levert/akkreditert tilstand overføres ved milepæler.

• Selskap/teammedlemmer skal ha teknisk erfaring med optikk, optomekanikk, termikk samt elektrisk/elektronikk, firmware/design og prototyping.

  Dokumentasjon: CV for teammedlemmer, og/eller bilder/navn eller annen relevant ikke-konfidensiell dokumentasjon som viser relevante sertifiseringer eller annen generell dokumentasjon.

  Kilde: Appendix 1, Kap. 6 Table of requirements (Priority A)
• Selskap/teammedlemmer skal ha erfaring med utvikling av medtech-enheter/instrumenter (design og prototyping).

  Dokumentasjon: CV og/eller bilder/navn eller relevante ikke-konfidensielle prosjekter, relevante sertifiseringer eller annen generell dokumentasjon.

  Kilde: Appendix 1, Table of requirements (Priority A)
• Selskap/teammedlemmer skal ha erfaring med å lage compliance-dokumentasjon for medtech-enheter med elektriske komponenter.

  Dokumentasjon: CV og/eller bilder/navn og relevante ikke-konfidensielle prosjekter, relevante sertifiseringer/clearances, eksempel på compliance-dokumentasjon eller annen generell dokumentasjon.

  Kilde: Appendix 1, Table of requirements (Priority A)
• Selskap/teammedlemmer skal ha erfaring med usability engineering.

  Dokumentasjon: CV og/eller bilder/navn eller relevant ikke-konfidensiell dokumentasjon, relevante sertifiseringer/clearances og eksempel på compliance-dokumentasjon eller annen generell dokumentasjon.

  Kilde: Appendix 1, Table of requirements (Priority A)
• Leverandøren må kunne levere alle leveransene listet i seksjon 3.4.

  Dokumentasjon: Ikke spesifisert utover bekreftelse/oppfyllelse i tilbudets kravtabell.

  Kilde: Appendix 1, Table of requirements (Priority A)
• Leveringen skal gjennomføres i minst tre milepæler (knyttet til betaling) listet i seksjon 3.

  Dokumentasjon: Beskrives i tilbudets plan/oppfyllelse av kravtabellen.

  Kilde: Appendix 1, Table of requirements (Priority A); samt Appendix 3 Payment plan
• Etter hver milepæl og samtidig betaling av faktura skal UiT få eierskap til produktene i gjeldende tilstand.

  Dokumentasjon: Avklares/oppgis som oppfyllelse i kravtabellen.

  Kilde: Appendix 1, Table of requirements (Priority A)
• Prosjektet finansieres av EIC (Europe Innovations Council); juridiske enheter etablert i Kina er ikke kvalifisert for Horizon Europe Innovation Actions (inkl. deltakelse som beneficiary/tilknyttet/underleverandør el. lign.). Leverandør må bekrefte ikke-involvering.

  Dokumentasjon: Bekreftelse av non-involvement fra juridiske enheter etablert i Kina.

  Kilde: Appendix 1, Table of requirements (Priority A)
• Alt IP (intellectual property) som utvikles som resultat av prosjektet tilhører UiT.

  Dokumentasjon: Oppfyllelseserklæring/avklaring i tilbudets kravtabell (noen ytterligere formkrav ikke angitt i teksten).

  Kilde: Appendix 1, Table of requirements (Priority A)

• Design verification matrix skal inngå i tilbudet (outline over evidens for kravoppfyllelse og kriterier for aksept av verifikasjonsutfall).Kilde: Appendix 1, Kap. 4 Requirements for documentation, information etc.
• Tidsplan med minst tre milepæler (og knyttet til milestone payment) skal inngå i tilbudet.Kilde: Appendix 1, Kap. 4 Requirements for documentation, information etc.
• Dokumenter/leveransene B–E i tillegg til prototyper i leveranse A må leveres som del av kontrakten (omfatter komplett design-dokumentasjon, verifikasjons-/testevidens, compliance-støtte-dokumentasjon og draft labeling/user documentation), samt firmware repository (private GitHub).Kilde: Appendix 1, Kap. 3.4 Deliverables (B–F)

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

30.09.2026

Språk

norsk, English

Elektronisk katalog

Ikke tillatt

• Konfidensialitet og NDA: UiT deler IP-sensitiv informasjon først etter signert NDA; kontrakt skal mandatere at informasjon delt etter NDA behandles som IP-sensitiv og konfidensiell som standard, samt at UiT background IP kun brukes for denne kontrakten; leverandørens genererte arbeid/IP skal tilhøre UiT.Kilde: Appendix 1, Kap. 2 Confidentiality
• Data processor agreement (databehandleravtale) skal inngås dersom leverandør behandler personopplysninger på vegne av UiT; avtalen må være på plass før behandling.Kilde: General Contract Terms Services iBOTT Jan 2023, Kap. 3.4 Personal data and information security
• Eierskap/overdragelse: Rettigheter til resultater (ownership/copyright/IP) faller til UiT ved completion/approval; leverandør beholder rett til egne verktøy og metodikkgrunnlag; partene kan bruke ikke-konfidensiell generell know-how.Kilde: General Contract Terms iBOTT Jan 2023, Kap. 7.2 Right of ownership
• Leveransested/Incoterms: varer under avtalen skal leveres DDP Incoterms 2020 (uten VAT for utenlandsk leverandør) med mindre annet avtales.Kilde: General Contract Terms iBOTT Jan 2023, Kap. 4.2 Time and place of delivery
• Dokumentasjonsplikt fra leverandør: levere all påkrevd dokumentasjon for å gjøre bruk av tjenestene (tegninger, rapporter, service-dokumenter m.m.) ved ferdigstillelse med mindre annet avtales.Kilde: General Contract Terms iBOTT Jan 2023, Kap. 4.3 Documentation
• Garanti: 2 år fra completion (med mindre annet avtales); leverandør plikter å rette mangler/defekter for egen regning i garantiperioden.Kilde: General Contract Terms iBOTT Jan 2023, Kap. 4.4 Guarantee
• Leverandørens ansvar for etterlevelse av relevante lover/forskrifter og innhenting/vedlikehold av nødvendige tillatelser/sertifikater/approvaler (med mindre avtalt at kunde leverer).Kilde: General Contract Terms iBOTT Jan 2023, Kap. 4.1 Services
• Sosial ansvar og arbeid/vilkår i Norge samt grunnleggende menneskerettigheter i leverandørkjeden (inkl. klausuler i Special Contract Terms).Kilde: Agreement document, Special Contract Terms (pay and working conditions in Norway; contract performance clauses for safeguarding basic human rights in the supply chain)

• Dokumentet ‘Agreement document’ har flere felter markert ‘Velg et element’ (f.eks. contract type/duration/scope/applies to) og inneholder derfor ikke fullstendig avtalefastsettelse i teksten som er gitt.
• Ingen eksplisitt vekt/scoremodell for tildeling er oppgitt; kun Priority A/B og kvalitativ poengsetting for forståelse/miljø.
• ‘Kvalifikasjonskrav’ og ‘tildelingskriterier’ er slått sammen i kravtabellen med Priority A/B; kategoriseringen her følger Priority A=eligibility og Priority B=preference, men total evalueringsmodell (vekter) mangler.
• Generelle kontraktsvilkår er for ‘Purchase of Services’; denne konkrete anskaffelsen gjelder utvikling/leveranse av et instrumentdesign og prototyper, så koblingen til alle kontraktsvilkår er indirekte basert på dokumentpakken.

Punkter der konkurransedokumentene åpner for tolkning, og der en presisering fra oppdragsgiver kan ha betydning for prising og risiko. Spørsmål kan stilles innen fristene som er angitt i konkurransegrunnlaget.

1. I «Agreement document» står flere felter som «Velg et element» (contract type og duration). Kan dere bekrefte hvilken kontraktstype og hvilken varighet som skal legges til grunn for denne anskaffelsen, og hvor i dokumentpakken dette er spesifisert?

   Hvorfor det er verdt å spørre: Uavklarte kontraktsfelter kan påvirke risiko, forpliktelser og hvordan leveransen og betaling/milepæler forstås.

   Kilde: Agreement document (AGREEMENT DOCUMENT - Velg et element)

2. I kravspesifikasjonen står det at etter hver milepæl og ved sammenfallende betaling «UiT receive ownership over the products in their current state». Kan dere utdype hva som menes med «products»/eiendom ved milepæl (omfatter det kun fysiske prototyper, eller også design-/dokumentasjonsartefakter, PCB/firmware-kode, og/eller alle deler under arbeid)?

   Hvorfor det er verdt å spørre: Dette er avgjørende for prise risiko og for leverandørens rett til å bruke egne resultater videre.

   Kilde: Appendix 1 / Table of requirements: «After each milestone and concurrent payment of invoice, UiT receive ownership over the products in their current state.»

3. I «Appendix 1 – Buyer’s requirement specification» beskrives forventet test på bakke gjennom «at least two production prototypes», og at Rev 1 prototyper leveres ved måned 3 og Rev 2 ved måned 6. Kan dere bekrefte om «two production prototypes» betyr nøyaktig to enheter totalt ved Rev 1, eller om dette kan variere mellom Rev 1 og Rev 2 (f.eks. rework/oppgraderinger av komponenter) slik dere beskriver i leveranse av Rev 2?

   Hvorfor det er verdt å spørre: Leveranseomfang og antall enheter påvirker både kost og plan, og dere ønsker at leverandørene priser riktig.

   Kilde: Appendix 1 / 3.4 Deliverables (A. Prototypes)

4. I «Appendix 1» fremgår det at supplier skal utarbeide dokumentasjon for CE-applikasjon for MDR Class 2A, samtidig som kontraktens samsvarsmatrise forutsetter «Interface and communication with the regulatory contractor ... after signing the contract». Kan dere presisere hvilke konkrete samsvarsdokumenter UiT-regulator (3rd party) vil utarbeide vs. hva leverandøren skal levere, og hvordan grensesnittet mot design verification matrix skal se ut?

   Hvorfor det er verdt å spørre: Uten klar ansvarsdeling kan leverandøren feilprise arbeid og «evidence»-krav mot regulator.

   Kilde: Appendix 1 / 1 Purpose of the procurement; 3.3 Compliance needs; 3.4 Deliverables (B-D)

5. Kravtabellen skiller Priority A (eligibility) og Priority B (preference), men uten eksplisitt evalueringsvekter. Kan dere beskrive total evalueringsmodell (vekting/innbyrdes betydning) for kriteriene knyttet til: (i) forståelse av prosjektet (Priority B), (ii) compliance-/dokumentasjonskvalitet som del av forståelsen, og (iii) miljøkriterier, slik at leverandøren kan prise og prioritere innholdet riktig?

   Hvorfor det er verdt å spørre: Når vekter/scoremodell mangler, blir det vanskelig å utforme tilbudet optimalt og risikostyrt.

   Kilde: Appendix 1 / 6 Table of requirements; Appendix 2 / Supplier’s solution description

6. I «Appendix 1» står det at «Design Verification Matrix (to be included in the proposal)» skal inkludere kriterier for aksept av verifikasjonsutfall. Kan dere gi en mal eller minimumskrav til hva som skal inngå i akseptkriteriene (for eksempel terskelverdier for repeatability/focus/thermal stability/EMC test-readiness), og om akseptkriteriene må være i ferdige «ready-to-execute» testprosedyrer eller kun en oppsummering?

   Hvorfor det er verdt å spørre: Akseptkriteriene påvirker arbeidsomfanget i verifikasjonsbevis og hvor mye detaljer som må produseres før leveranse.

   Kilde: Appendix 1 / 4 Requirements for documentation, information etc. (Design Verification Matrix)

7. I «Appendix 1» er det spesifisert flere maskin- og grensesnittsfunksjoner (Ubuntu-kompatibel compute, camera data path, USB/RS-485/Ethernet for kontroll, RFID/barcode til cartridge). Kan dere bekrefte hvilke konkrete grensesnitt/protokoller og ytelseskrav dere forventer for: (a) kamerastream (f.eks. oppløsning, frame rate, bit depth), (b) compute-to-control link, og (c) RFID/barcode-teknologi (type/format) — eller angi hvor i dokumentpakken dette er spesifisert for «UiT software access»?

   Hvorfor det er verdt å spørre: Spesifikke grensesnitt- og ytelseskrav er nødvendige for riktig arkitekturvalg og kost-/risikoprising.

   Kilde: Appendix 1 / 3.1 General description (optisk/compute); 3.2 detaljer (kamera/grensesnitt); 3.2 «RFID/barcode scanner»

8. Kravet om IP-tilhørighet («All IP resulting from the project belongs to UiT») er også i konfliktpotensial med leverandørens «background IP» og «tools and methodological basis». Kan dere bekrefte hvordan dette skal praktiseres i lys av «General Contract Terms» punkt 7.2 (supplier beholder rettigheter til tools/methods, men kunden får resultatrater/ITP)?

   Hvorfor det er verdt å spørre: Det er viktig å avklare hva som anses som «resultater» vs. bakgrunn/metode/egen generisk programvare for å unngå urimelig IP-avgivelse.

   Kilde: Appendix 1 / Table of requirements (Priority A: «All IP ... belongs to UiT»); General Contract Terms / 7.2 Right of ownership, etc.

9. I «General Contract Terms» er det krav om at «completion is deemed to have taken place ... when ... approved by the Customer» og at dagbøter (0.15 % per dag, min NOK 1,000) kan utløses ved forsinkelse. Kan dere presisere hvilke leveranser som utløser «completion» ved hver milepæl (Milestone 1/2/3), og hvordan dere håndterer forsinkelser som skyldes sen input fra UiT (som det fremgår at UiT skal levere relevante tekniske innspill)?

   Hvorfor det er verdt å spørre: Slik kan leverandøren vurdere og redusere forsinkelsesrisiko og prisbehov for avhengigheter mot UiT.

   Kilde: Appendix 1 / 4 Requirements for documentation, information etc. (milestones); General Contract Terms / 7.1 Time of completion; 9.8 Daily penalties; 5.1 Contribution