1

Ønsket register navn

Angiv det navn der ønskes anvendt til servicen

2

Projektleder

Angiv hvem er projektleder på register samt kontaktdata på person og/eller funktion (email og telefon nr)

3

Formål med service

Angiv kort formål med servicen, herunder hvad servicen må bruges til og evt. begrænsninger

4

Sammenhæng til service og registre

Angiv navne på service (ny elle eksisterende) eller registre, der er sammenhæng til eller en forudsætning for registeret. Angiv også om det er en forudsætning, at registret er i drift før eller samtidig med servicen.

5

Finansiering

Angiv hvem har givet commitment til projektet og finansierer udviklingen, test, idriftsættelse og drift af service

6

Budget

Angiv budget afsat til hhv. udvikling, test og idriftsættelse og drift

7

Ønsket dato for udstilling til ekstern test

Angiv den ønskede dato for en aftale for den gældende leverance med den angivet udstillingsform. Leverancen skal opfylde de almindelige krav til husregler og dokumentationskrav fra operatøren.

Det skal anføres hvis der er en sammenhæng med en udviklingsorganisation eller -plan.

8

Ønsket produktionsdato

Angiv dato for hvornår registret ønskes tilgængeligt til hhv. test og produktion på NSP

9

Dataejer og kontaktdata

Angiv hvem der er dataejer (juridisk) og kontaktdata på person og/eller funktion (email og telefon nr) på hvem der er / skal indgås en databehandler aftale med.

10

Dataleverandør og kontaktdata

Hvem der teknisk leverer registret og kontaktdata på person og/eller funktion (email og telefon nr) på hvem der er / skal indgås en tilslutningsaftale med.

11

Support og kontaktdata

Hvem supporterer register indhold og kontaktdata på person og/eller funktion (email og telefon nr) og åbningstid og responstid på support

12

Målgrupper / Anvendere af registret

Specificer hvem der er målgruppe for register fx regioner, kommuner, praktiserende læger, privathospitaler mv.

Angiv hvis det skal være åben for alle.

Angiv andre systemer/services/komponenter og hvilken sammenhæng og/eller forudsætninger, der er

Angiv andre eks. partnere, systemleverandører.

Angiv hvem der skal indgås aftaler med for at anvende registret. Anvender skal være i overensstemmelse med aftalen med data ejer.

13

Forretningsmæssigt rationale

Kriterierne er følgende for vurdering af den forrentningsmæssige værdi:

1. For central offentlig koordinator (her SDS)
1. Hvordan det generelle koncept for NSP (serviceaftale, support, version, princip om nærhed, etc) kan bidrage til registrens optag
2. Generel cost/benefit vurdering
3. Hvor godt et teknologisk match, der er imellem registrer nuværende distribution og NSP tekniske setup.
2. For aftagere af registre 
1. Kan omkostningerne for aftagerne af registret reduceres eller holdes på nuværende niveau.
2. Kan NSP bidrage til at processen omkring fejlrettelse kan være optimal og dermed sikre høj produktkvalitet
3. Kan NSP bidrage til at nye versioner af registeret implementeres hurtigere
4. Kan NSP bidrage til en øget udbredelse registeret ved en enklere systemteknisk adgang.
5. Mulighed for test af registerdata før download.
6. Oftere opdateringsfrekvens
3. For udbydere af registre 
1. Distribution via NSP må ikke blive dyrere, og ikke kræve væsentligt yderligere indsats
2. Kompetencen på indholdsdelen af registre forbliver hos nuværende udbyder
3. Sikre tillid i forbindelse med distribution af registret
4. For driver af sundhedsfaglig infrastruktur fx Medcom
   
   1. At NSP kan bidrage til en yderligere udbredelse af kommunikation på en given standard
   2. Protokollen der anvendes ved distribution kan blive mere dynamisk med den nye løsning        

14

Behov for ekstra service NSP organisation

Skal NSP organisationen foretage aktiv promovering af service, aktiv indgåelse af serviceaftaler, teknisk kom i gang støtte? Specificer hvilken form der ønskes.

15

Skemaer ind

Reference til databaseskema for hver tabel i det modtagne register. Hvis der henvises til andet materiale SKAL dette være vedhæftet bestillingsarket. Hvis der refereres til et link skal dette link være permanent ellers angives i hvilken perioden referancen er gyldig.

Der angives både databaseformat og filformat fra datakilden fx XML, fastfilformat, ”kommasepareret”.

16

Udstillingsform og reference

En kombination af: internt SQL, SKRS, Enkeltopslag. Ved enkeltopslag angives nyt komponentnavn og forventet udviklingsorgansation. Hvis SQL angive hvilken komponent der skal tilgå registreret.

Evt. kan der angives flere udstillingssteder.

Hvis inddata skal placeres i to registre skal hvert register have en specifik beskrivelse med reference til databaseskemaet for inddata.

17

Særlige forhold omkring data og opbevaring

Indeholder registret personhenførbare eller personfølsomme informationer, og er der særlige vilkår omkring opbevaring (herunder sikring og maks. opbevaringsperiode/sletningsfrister m.v.). Der skal også tages stilling til evt. backup datas levetid.

Man kan IKKE angive "ingen særlige forhold" da der skal bruges en aftale.

18

Anvendelse af produktiondata til testformål internt test eller eksterne begrænsninger. Bliver der udviklet og vedligholdt testdata og af hvem.

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.

19

Test

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.

20

Licens

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.

21

Datamængder

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.

22

Opdatering af stamdataregistret

Særlige krav omkring opdatering af stamdataregistret, herunder om der leveres komplette eller partielle udtræk (”delta”), om der ønskes historik, osv.

23

Opdateringsfrekvens

Dette punkt beskriver registret som det vedligeholdes hos kilden.

Hvordan registret opdateres hos kilden, fx løbende opdatering, daglige, ugentlige eller månedlige opdateringer. Angiv tidspunkt på dagen for opdatering

Angiv hvilken forretningsmæssig værdi/betydning opdateringshyppigheden har

24

Opsamlingsmekanisme

Fortages aktiv upload af data til NSP eller skal data hentes af NSP fra dataleverandøren. Tilslutningsaftalen skal definerer passwords og adresser på upload af data.

Hvordan data modtages til stamdataregistret. Muligheder: Webservice, FTP-server, FTP-klient.