Version 1.0 August 2012
Kriterierne er følgende for vurdering af den forrentningsmæssige værdi:
- For central offentlig koordinator (her NSI)
- Hvordan det generelle koncept for NSP (serviceaftale, support, version, princip om nærhed, etc) kan bidrage til registrens optag
- Generel cost/benefit vurdering
- Hvor godt et teknologisk match, der er imellem registrer nuværende distribution og NSP tekniske setup.
- For aftagere af registre
- Kan omkostningerne for aftagerne af klassifikationerne reduceres eller holdes på nuværende niveau.
- Kan NSP bidrage til at processen omkring fejlrettelse kan være optimal og dermed sikre høj produktkvalitet
- Kan NSP bidrage til at nye versioner af klassifikationerne implementeres hurtigere
- Kan NSP bidrage til en øget udbredelse klassifikation ved en enklere systemteknisk adgang.
- Mulighed for test af klassifikationsdata før download.
- Oftere opdateringsfrekvens
- For udbydere af registre
- Distribution via NSP må ikke blive dyrere, og ikke kræve væsentligt yderligere indsats
- Kompetencen på indholdsdelen af klassifikationerne forbliver hos nuværende udbyder
- Sikre tillid i forbindelse med distribution af klassifikationen
- For driver af sundhedsfaglig infrastruktur fx Medcom
- At NSP kan bidrage til en yderligere udbredelse af kommunikation på en given standard
- Protokollen der anvendes ved distribution kan blive mere dynamisk med den nye løsning
Benyt vedlagt skabelon: stamdata-bestillings-template.docx.
Følgende felter udfyldes og sendes til Operatøren:
Aspekt | Registerinformation Eksempel | Vejledning |
Dataejer | Statens Serum Institut (SSI). | Angiv hvem der er dataejer og hvem der er / skal indgås en anvender aftale med. |
Dataleverandør | DDV uploader filer via FTP. | Hvem der teknisk leverer registret og hvem der er / skal indgås en leverance aftale. |
Operatør | NSP-operatøren ?? | Hvem der sikrer at aftaler er indgået før de anvendes og eller udstilles. |
Datamodtager | NSI. | Hvem der udstiller server til dataleverandøren, henter fra dataleverandøren eller anvender udstillet datawebservices for at hente registre. |
Anvender af registret og miljø | Anvendes af systemer der skal tilgå DDVs webservice-snitflade. Som udgangspunkt forventes intet behov for begrænsning af anvendere – dette skal afklares. Data skal være tilgængelige fra alle NSP-instanser, både cNSP og dNSP. | Hvem der skal indgås aftaler med for at anvende registret. Anvender skal være i overensstemmelse med aftalen med data ejer. Miljø er hvor data skal være tilgængeligt. cNSP, dNSP og back-office. |
Skemaer ind | AFKLAR: Er i tvivl om hvad i reelt har brug for her? XML-format på inputfiler, eller andet? | Reference til databaseskema for hver tabel i det modtagne register. |
Dataimporter | SDM efter implementering af plugin-arkitektur – har ikke styr på versionering. | Hvilken importer der ønskes anvendt. Nuværende muligheder er SDM 1.0, SDM 2.0 og BRS. |
Udstillingsform og reference | SKRS – hvis det er betegnelsen for kopiregisterservicen | En kombination af: internt SQL, SKRS, Enkeltopslag. Ved enkeltopslag angives nyt komponentnavn og forventet udviklingsorgansation. Evt. kan der angives flere udstillingssteder. |
Forventet dato for udvikling afsluttet | September 2012. | Den dato som der ønskes aftale om leverance af udstillingsformen. Leverancen skal opfylde de almindelige krav til husregler og dokumentationskrav fra Operatøren. |
Ønsket produktionsdato | September 2012. | Dato for hvornår registret ønskes tilgængeligt på NSP |
Særlige forhold omkring data | Ingen særlige forhold. | Indeholder registret personhenførbare eller personfølsomme informationer, og er der særlige vilkår omkring opbevaring (herunder sikring og maks. opbevaringsperiode) |
Anvendelse af produktiondata til testformål internt test eller eksterne begrænsninger. Bliver der udviklet og vedligholdt testdata og af hvem. | Produktionsdata kan anvendes til udviklings- og testformål uden særlige krav. | Kan registrets produktionsdata anvendes til udviklings- og testformål, eller stilles der særlige krav til dette? I givet fald skal det angives hvordan data til test tilvejebringes. |
Test | Produktionsmiljøet kan anvendes til test.
Dette naturligvis under forudsætning af at performance er på plads. | Eksisterer der et testmiljø, hvorfra leverandøren af registret kan levere testdata og kan kalde stamdata import mekanismen? Kan leverandøren validere kopiregister-udtrækket? Udstillingsservicen bliver den udstillet på testsnit. |
Økonomiske forhold | Ingen særlige forhold | Kræves der en særskilt licens til anvendelse og udstilling af data? I givet fald skal den økonomiske ramme angives, samt kontaktinformationer på rettighedshaver. |
Datamængder | Skal afklares præcist. I store træk er datasættets størrelse begrænset, og ændringer forekommer relativt sjældent. | Angiv registrets omfang, både antal records og fysisk plads på disk. Angiv også hvis der er særlige forhold omkring indeksering eller andre database-forhold, der er ud over det sædvanlige. |
Opdatering af stamdataregistret | Der ønskes komplette udtræk med historik. (status indtil videre) | Særlige krav omkring opdatering af stamdataregistret, herunder om der leveres komplette eller partielle udtræk (”delta”), om der ønskes historik, osv. |
Opdateringsfrekvens | Løbende, men i praksis relativt sjældent forekommende. | Hvordan registret opdateres hos kilden, f.eks. løbende opdatering, daglige eller månedlige opdateringer. Dette punkt beskriver registret som det vedligeholdes hos kilden. |
Opsamlingsmekanisme | Registret stilles til rådighed fra SSI via filer der FTPs til en passende lokation på stamdataregisteret. | Hvordan data modtages til stamdataregistret. Muligheder: Webservice, FTP-server, FTP-klient. |
Inputformat til stamdataregistrets import | XML | Hvilket format leveres data i? F.eks. XML, fastfilformat, ”kommasepareret”. |