PIELIKUMS

SATURS

1. NODAĻA.

DNS datu apmaiņa

1.	Kriminālistikas jautājumi, sakritības noteikumi un algoritmi saistībā ar DNS

1.1.	DNS profilu pazīmes

1.2.	Sakritības noteikumi

1.3.	Ziņojumu sastādīšanas noteikumi

2.	Dalībvalstu kodu tabula

3.	Funkcionāla analīze

3.1.	Sistēmas pieejamība

3.2.	Nākamais solis

4.	DNS saskarņu kontroles dokuments

4.1.

Ievads

4.2.	XML struktūras definējums

5.	Programmatūras, drošības un sakaru arhitektūra

5.1.

Pārskats

5.2.	Augstākā līmeņa arhitektūra (Upper Level Architecture)

5.3.	Drošības standarti un datu aizsardzība

5.4.	Šifrēšanas mehānismā izmantotie protokoli un standarti: s/MIME un saistītas pakotnes (packages)

5.5.	Lietojumprogrammas arhitektūra

5.6.	Lietojumprogrammas arhitektūrā izmantotie protokoli un standarti

5.7.	Sakaru sistēmas

2. NODAĻA.

Daktiloskopijas datu apmaiņa (saskarņu kontroles dokuments – interface control document)

1.	Datņu satura pārskats

2.	Ierakstu forma

3.	1. tipa loģiski dati – datnes galvene

4.	2. tipa loģiski dati – ieraksts

5.	4. tipa loģiski dati – melnbalti tonāli attēli ar lielu izšķirtspēju

6.	9. tipa loģiski dati – papilārlīniju detaļu ieraksts

7.	13. tips – latentu attēlu ieraksti ar maināmu izšķirtspēju

8.	15. tips – plaukstu nospiedumu attēli ar maināmu izšķirtspēju

9.	2. nodaļas papildinājumi (daktiloskopijas datu apmaiņa)

9.1.	ASCII nošķīrēji kodi

9.2.	Burtu vai ciparu pārbaudes zīmju aprēķini

9.3.	Zīmju kodi

9.4.	Darbību kopsavilkums

9.5.	1. tipa ierakstu definīcijas

9.6.	2. tipa ierakstu definīcijas

9.7.	Melnbaltu tonālu attēlu saspiešanas kodi

9.8.	Sūtījumu parametri

3. NODAĻA.

Transportlīdzekļu reģistrācijas datu apmaiņa

1.	Kopējs datu kopums automatizētai transportlīdzekļu reģistrācijas datu meklēšanai

1.1.	Definīcijas

1.2.	Transportlīdzekļu īpašnieku vai turētāju meklēšana

2.	Datu drošība

2.1.

Pārskats

2.2.	Sūtījumu apmaiņas drošības iezīmes

2.3.	Ar sūtījumu apmaiņu nesaistītas drošības iezīmes

3.	Datu apmaiņas tehniskie nosacījumi

3.1.	Vispārējs Eucaris lietojumprogrammas apraksts

3.2.	Funkcionālas prasības un nefunkcionālas prasības

4. NODAĻA.

Izvērtējums

1.	Izvērtējuma procedūra saskaņā ar 20. pantu (Lēmumu gatavošana saskaņā ar Lēmuma 2008/615/TI 25. panta 2. punktu)

1.1.

Anketa

1.2.	Izmēģinājums

1.3.	Izvērtējuma inspekcija

1.4.	Ziņojums Padomei

2.	Izvērtējuma procedūra saskaņā ar 21. pantu

2.1.	Statistika un ziņojumi

2.2.	Pārskatīšana

3.	Ekspertu sanāksmes

1. NODAĻA. DNS datu apmaiņa

1.   Kriminālistikas jautājumi, sakritības noteikumi un algoritmi saistībā ar DNS

1.1.   DNS profilu pazīmes

DNS profilā var būt 24 ciparu pāri, kas atbilst 24 lokusu alēlēm, ko izmanto arī Interpola DNS procedūrās. Lokusu (loci) nosaukumi ir doti šajā tabulā:

VWA	TH01	D21S11	FGA	D8S1179	D3S1358	D18S51	Amelogenin
TPOX	CSF1P0	D13S317	D7S820	D5S818	D16S539	D2S1338	D19S433
Penta D	Penta E	FES	F13A1	F13B	SE33	CD4	GABA

Septiņi pelēki iekrāsotie lokusi augšējā rindā ir iekļauti gan Eiropas lokusu standartkompleksā (European Standard Set – ESS), gan arī Interpola lokusu standartkompleksā (Interpol Standard Set of Loci – ISSOL).

Lietošanas noteikumi:

DNS profilos, ko dalībvalstis dara pieejamus meklēšanai un salīdzināšanai, kā arī DNS profilos, ko nosūta meklēšanas un salīdzināšanas vajadzībām, ir jābūt vismaz sešiem pilnīgiem (1) lokusiem, turklāt tajos – atkarībā no pieejamības – var būt arī papildu lokusi vai atstātas tukšas vietas. Atsauces DNS profilos ir jābūt vismaz sešiem no septiņiem Eiropas standartu kompleksa (ESS) lokusiem. Lai celtu meklēšanas rezultātu sakritību precizitāti, visas pieejamās alēles glabā indeksētā DNS profilu datubāzē un izmanto meklējumos un salīdzinājumos. Katrai dalībvalstij tik drīz, cik vien tas praktiski iespējams, būtu jāīsteno jebkurš jauns Eiropas Savienībā pieņemts ESS.

Jaukti profili (mixed profiles) nav atļauti, jo tad katra lokusa alēles vērtība būs tikai divi cipari, kas var būt tādi paši, ja attiecīgais lokuss ir homozigots.

Aizstājējzīmes funkciju (wild-cards) un mikrovariantus (micro-variants) izmanto saskaņā ar šādiem noteikumiem:

—	jebkura neskaitliska vērtība (piemēram, “o”, “f”, “r”, “na”, “nr” vai “un”), izņemot profilā iekļautu amelogenīnu, ir automātiski jākonvertē, lai to lietotu ar aizstājējzīmes (*) funkciju, un meklēšana būtu jāveic, salīdzinājumos izmantojot visus meklēšanas kritērijus,

—	profilā iekļautas skaitliskas vērtības “0”, “1” vai “99” ir automātiski jākonvertē, lai tās lietotu ar aizstājējzīmes (*) funkciju, un meklēšana būtu jāveic, salīdzinājumos izmantojot visus meklēšanas kritērijus,

—	ja vienam lokusam ir dotas trīs alēles, tad pieņem tikai pirmo alēli, bet pārējās divas alēles automātiski jākonvertē, lai tās lietotu ar aizstājējzīmes (*) funkciju, un meklēšana būtu jāveic, salīdzinājumos izmantojot visus meklēšanas kritērijus,

—	ja aizstājējzīmes vērtības (wild card values) ir dotas 1. vai 2. alēlei, tad meklēs abas attiecīgās lokusa skaitliskās vērtības permutācijas (piemēram, 12, * varētu sakrist ar 12,14 vai 9,12),

—	pentanukleotīdu (Penta D, Penta E & CD4) mikrovariantu sakritību nosaka saskaņā ar šādu formulu: — x.1 = x, x.1, x.2 — x.2 = x.1, x.2, x.3 — x.3 = x.2, x.3, x.4 — x.4 = x.3, x.4, x + 1

—	tetranukleotīdu (pārējie lokusi datubāzē ir tetranukleotīdi) mikrovariantu sakritību nosaka saskaņā ar šādu formulu: — x.1 = x, x.1, x.2 — x.2 = x.1, x.2, x.3 — x.3 = x.2, x.3, x + 1

1.2.   Sakritības noteikumi (Matching rules)

Divu DNS profilu salīdzināšanu veiks, pamatojoties uz lokusiem, kuriem abos DNS profilos ir pieejams alēles vērtību pāris. Abos DNS profilos ir jāsakrīt vismaz sešiem pilnīgiem lokusiem (izņemot amelogenīnu), pirms dot atbildi par konstatētu sakritību.

Pilnīga sakritība (1. ticamības pakāpe) ir sakritība, kurā ir vienādas visas salīdzināto to lokusu alēļu vērtības, kas atrodas abos salīdzinātajos DNS profila paraugos. Daļēja sakritība ir sakritība, kurā divos DNS profilos atšķiras tikai viena no visu salīdzināto lokusu alēļu vērtībām (2., 3. un 4. ticamības pakāpe). Daļēju sakritību akceptē tikai tad, ja ir reģistrēta sakritība vismaz sešas pilnīgos abu salīdzināto DNS profilu lokusos.

Daļējas sakritības iemesls var būt:

—	ir pieļauta pārrakstīšanās kļūda, ievadot vienu DNS profilu meklēšanas funkcijā vai DNS datubāzē,

—	izstrādājot DNS profilu, ir pieļauta alēles noteikšanas (allele-determination) vai alēlēs identifikācijas (allele-calling) kļūda.

1.3.   Ziņojumu sastādīšanas noteikumi

Ziņojumus sastāda gan par pilnīgām sakritībām, gan daļējām sakritībām, gan par to, ka sakritības nav konstatētas.

Sakritības ziņojumu nosūta valsts kontaktpunktam, kas iesniedzis pieprasījumu, kā arī to dara pieejamu tās valsts kontaktpunktam, kurā pieprasījums ir iesniegts (lai dotu iespēju tam novērtēt iespējamus turpmākus pieprasījumus par citiem pieejamiem personas datiem vai citu informāciju saistībā ar DNS profilu, kura saistīta ar atbilsmi saskaņā ar Lēmuma 2008/615/TI 5. un 10. pantu).

2.   Dalībvalstu kodu tabula

Saskaņā ar Lēmumu 2008/615/TI, lai izveidotu domēnu nosaukumus un citus Prīmes Līgumā paredzētus konfigurācijas parametrus, ko slēgtā tīklā lietot DNS datu apmaiņas programmatūrās, izmanto ISO kodu 3166-1 alpha-2.

ISO 3166-1 alpha-2 kodi ir šādi dalībvalstu kodi, kas sastāv no diviem burtiem.

Dalībvalsts nosaukums	Kods	Dalībvalsts nosaukums	Kods
Beļģija	BE	Luksemburga	LU
Bulgārija	BG	Ungārija	HU
Čehija	CZ	Malta	MT
Dānija	DK	Nīderlande	NL
Vācija	DE	Austrija	AT
Igaunija	EE	Polija	PL
Grieķija	EL	Portugāle	PT
Spānija	ES	Rumānija	RO
Francija	FR	Slovākija	SK
Īrija	IE	Slovēnija	SI
Itālija	IT	Somija	FI
Kipra	CY	Zviedrija	SE
Latvija	LV	Apvienotā Karaliste	UK
Lietuva	LT

3.   Funkcionāla analīze

3.1.   Sistēmas pieejamība

Pieprasījumiem saskaņā ar Lēmuma 2008/615/TI 3. pantu būtu attiecīgā datubāzē jānonāk hronoloģiskā pieprasījumu izsūtīšanas secībā, savukārt atbildēm pieprasījuma iesniedzējā dalībvalstī būtu jānonāk 15 minūtēs pēc pieprasījumu pienākšanas.

3.2.   Nākamais solis

Ja dalībvalsts saņem ziņojumu par sakritību, tās kontaktpunkts ir atbildīgs par attiecīgā iesniegtā profila vērtības un atbildē saņemtā profila(-u) vērtības salīdzināšanu, lai apstiprinātu un pārbaudītu profila iespējamo vērtību. Valstu kontaktpunkti apstiprināšanas sakarā var tieši sazināties cits ar citu.

Pēc divu profilu sakritības apstiprinājuma sākas tiesiskās palīdzības procedūras, pamatojoties uz “pilnīgu sakritību” (full match) vai “daļēju sakritību” (near match), kas ir iegūta automatizēto konsultāciju fāzē.

4.   DNS saskarņu kontroles dokuments

4.1.   Ievads

4.1.1.   Mērķi

Šajā nodaļā ir definētas prasības, lai veiktu DNS profilu informāciju apmaiņu starp visu dalībvalstu datubāzu sistēmām. Galvenes laukumi ir definēti īpaši Prīmes DNS datu apmaiņas vajadzībām, savukārt datu daļas pamatojumā ir izmantota XML shēmas DNS profila datu daļa, kas noteikta Interpola DNS datu apmaiņas vārtejas (Interpol DNA exchange gateway) vajadzībām.

Datu apmaiņa notiek ar SMTP protokolu (Simple Mail Transfer Protocol – vienkāršais pasta pārsūtīšanas protokols) un citu modernu tehnoloģiju starpniecību, izmantojot centrālā releja pasta serveri (central relay mail server), ko nodrošina tīkla pakalpojumu sniedzējs. XML valodā izstrādātu datni pārsūta kā e-pasta pamattekstu.

4.1.2.   Darbības joma

Saskarņu kontroles dokumentā (ICD) ir definēts tikai sūtījuma (e-pasta) saturs. Visi ar tīkla darbību un e-pastiem saistītie jautājumi ir definēti vienotā formātā, lai varētu izveidot vienotu DNS datu apmaiņas tehnisko bāzi.

Tas ietver:

—	sūtījuma temata formātu, lai dotu iespēju veikt sūtījuma automatizētu apstrādi,

—	vai ir vajadzīga satura šifrēšana un, ja jā, kāda metode būtu jāizvēlas,

—	sūtījuma maksimālais garums.

4.1.3.    XML struktūra un principi

XML sūtījums ir strukturēts šādi:

—	galvenes daļa, kurā ir iekļauta informācija par pārsūtījumu, un

—	datu daļa, kurā ir iekļauta konkrēta profila informācija, kā arī pats profils.

Tādu pašu XML shēmu izmanto pieprasījumos un atbildēs.

Lai veiktu pilnīgas pārbaudes par neidentificētiem DNS profiliem (Lēmuma 2008/615/TI 4. pants), jāparedz iespēja, ka vienā sūtījumā iekļauj vairākus profilus. Jānosaka maksimālais vienā sūtījumā iekļaujamo profilu skaits. Skaits ir atkarīgs no maksimāli pieļaujamā e-pasta lieluma, un tas būtu jānosaka pēc tam, kad ir notikusi pasta servera izvēle.

XML piemērs:

<?version=“1.0” standalone=“yes”?>

<PRUEMDNAx xmlns:msxsl=“urn:schemas-microsoft-com:xslt”

xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”>

<header>

(…)

</header>

<datas>

(…)

</datas>

[<datas> datu struktūra ir atkārtota, ja vienā SMTP sūtījumā

(....) ir nosūtīti vairāki profili; tas atļauts tikai lietās, uz ko attiecas 4. pants

</datas>]

</PRUEMDNA>

4.2.   XML struktūras definējums

Šis definējums ir paredzēts dokumentācijas un labākas salasāmības nolūkos, savukārt informācija, kas uzliek saistības, ir paredzēta XML shēmas datnē (PRUEM DNA.xsd).

4.2.1.    PRUEMDNAx shēma

Tā ietver šādus laukus:

Fields	Type	Description
header	PRUEM_header	Occurs: 1
datas	PRUEM_datas	Occurs: 1 ... 500

4.2.2.   Galvenes struktūras saturs

4.2.2.1.

PRUEM galvene Šajā struktūrā ir aprakstīta XML galvene. Tā ietver šādus laukus: Fields Type Description direction PRUEM_header_dir Direction of message flow ref String Reference of the XML file generator String Generator of XML file schema_version String Version number of schema to use requesting PRUEM_header_info Requesting Member State info requested PRUEM_header_info Requested Member State info

4.2.2.2.

PRUEM_header dir Sūtījumā iekļauto datu tips, kuru vērtība var būt: Value Description R Request A Answer

4.2.2.3.

PRUEM galvenes informācija Struktūra, lai aprakstītu dalībvalsti, kā arī sūtījuma datumu/laiku. Tā ietver šādus laukus: Fields Type Description source_isocode String ISO 3166-2 code of the requesting Member State destination_isocode String ISO 3166-2 code of the requested Member State request_id String unique Identifier for a request date Date Date of creation of message time Time Time of creation of message

4.2.3.    PRUEM profilu datu saturs

4.2.3.1.

PRUEM_datas Šajā struktūrā ir aprakstīta XML profila datu daļa. Tā ietver šādus laukus: Fields Type Description reqtype PRUEM request type Type of request (Article 3 or 4) date Date Date profile stored type PRUEM_datas_type Type of profile result PRUEM_datas_result Result of request agency String Name of corresponding unit responsible for the profile profile_ident String Unique Member State profile ID message String Error Message, if result = E profile IPSG_DNA_profile If direction = A (Answer) AND result ≠ H (Hit) empty match_id String In case of a HIT PROFILE_ID of the requesting profile quality PRUEM_hitquality_type Quality of Hit hitcount Integer Count of matched Alleles rescount Integer Count of matched profiles. If direction = R (Request), then empty. If quality! = 0 (the original requested profile), then empty.

4.2.3.2.

PRUEM_request_type Sūtījumā iekļauto datu tips, kuru vērtība var būt: Value Description 3 Requests pursuant to Article 3 of Decision 2008/615/JHA 4 Requests pursuant to Article 4 of Decision 2008/615/JHA

4.2.3.3.

PRUEM_hitquality_type Value Description 0 Referring original requesting profile: Case “No Hit”: original requesting profile sent back only; Case “Hit”: original requesting profile and matched profiles sent back. 1 Equal in all available alleles without wildcards 2 Equal in all available alleles with wildcards 3 Hit with Deviation (Microvariant) 4 Hit with mismatch

4.2.3.4.

PRUEM_data_type Sūtījumā iekļauto datu tips, kuru vērtība var būt: Value Description P Person profile S Stain

4.2.2.5.

PRUEM_data_result Sūtījumā iekļauto datu tips, kuru vērtība var būt: Value Description U Undefined, If direction = R (request) H Hit N No Hit E Error

4.2.3.6.

IPSG_DNA_profile DNS profila apraksta struktūra. Tā ietver šādus laukus: Fields Type Description ess_issol IPSG_DNA_ISSOL Group of loci corresponding to the ISSOL (standard group of Loci of Interpol) additional_loci IPSG_DNA_additional_loci Other loci marker String Method used to generate of DNA profile_id String Unique identifier for DNA profile

4.2.3.7.

IPSG_DNA_ISSOL Struktūra, kurā iekļauti ISSOL lokusi (Interpola lokusu standarta komplekss). Tā ietver šādus laukus: Fields Type Description vwa IPSG_DNA_locus Locus vwa th01 IPSG_DNA_locus Locus th01 d21s11 IPSG_DNA_locus Locus d21s11 fga IPSG_DNA_locus Locus fga d8s1179 IPSG_DNA_locus Locus d8s1179 d3s1358 IPSG_DNA_locus Locus d3s1358 d18s51 IPSG_DNA_locus Locus d18s51 amelogenin IPSG_DNA_locus Locus amelogin

4.2.3.8.

IPSG_DNA_additional_loci Struktūra, kurā iekļauti citi lokusi. Tā ietver šādus laukus: Fields Type Description tpox IPSG_DNA_locus Locus tpox csf1po IPSG_DNA_locus Locus csf1po d13s317 IPSG_DNA_locus Locus d13s317 d7s820 IPSG_DNA_locus Locus d7s820 d5s818 IPSG_DNA_locus Locus d5s818 d16s539 IPSG_DNA_locus Locus d16s539 d2s1338 IPSG_DNA_locus Locus d2s1338 d19s433 IPSG_DNA_locus Locus d19s433 penta_d IPSG_DNA_locus Locus penta_d penta_e IPSG_DNA_locus Locus penta_e fes IPSG_DNA_locus Locus fes f13a1 IPSG_DNA_locus Locus f13a1 f13b IPSG_DNA_locus Locus f13b se33 IPSG_DNA_locus Locus se33 cd4 IPSG_DNA_locus Locus cd4 gaba IPSG_DNA_locus Locus gaba

4.2.3.9.

IPSG_DNA_locus Lokusa apraksta struktūra. Tā ietver šādus laukus: Fields Type Description low_allele String Lowest value of an allele high_allele String Highest value of an allele

5.   Programmatūras, drošības un sakaru arhitektūra

5.1.   Pārskats

Īstenojot lietojumprogrammu, lai veiktu DNS datu apmaiņu saistībā ar Lēmumu 2008/615/TI, izmanto kopēju saziņas tīklu, ko loģiski saslēgs dalībvalstu starpā. Lai kopējo saziņas infrastruktūru efektīvāk izmantotu pieprasījumu nosūtīšanai un atbilžu saņemšanai, ir izstrādāts asinhrons mehānisms, ar ko DNS un daktiloskopijas datu pieprasījumus konvertē par SMTP e-pasta sūtījumiem. Ņemot vērā drošības apsvērumus, kā SMTP protokola paplašinājumu izmantos s/MIME mehānismu, lai tīklā nodrošinātu drošu datu pārraidi visā sakaru tuneļa garumā (true end-to-end secure tunnel).

Operatīvo TESTA (Trans European Services for Telematics between Administrations – Eiropas pārvaldes iestāžu saziņas tīkls) dalībvalstis izmanto kā sakaru tīklu, lai apmainītos ar datiem. Par TESTA darbību ir atbildīga Eiropas Komisija. Ņemot vērā valstu DNS datubāzes un to, ka pašreizējie valstu piekļuves punkti TESTA var atrasties dažādās dalībvalstu vietās, piekļuvi TESTA var izstrādāt:

1)	izmantojot pašreizējo valsts piekļuves punktu vai izveidojot jaunu valsts TESTA piekļuves punktu, vai

2)	izveidojot drošu vietēju saiti no vietnes, kurā atrodas kompetentas valsts aģentūras pārvaldītā DNS datubāze, līdz pastāvošajam valsts TESTA piekļuves punktam.

Protokoli un standarti, ko izmanto, lai īstenotu Lēmumu 2008/615/TI, ir saskaņā ar atvērtiem standartiem (open standards) un prasībām, ko paredzējuši dalībvalstu valsts drošības politikas veidotāji.

5.2.   Augstākā līmeņa arhitektūra (Upper Level Architecture)

Lēmuma 2008/615/TI darbības jomā paredzēts, ka katra dalībvalsts darīs pieejamus DNS datus, lai veiktu to apmaiņu ar citām dalībvalstīm un/vai lai citas dalībvalstis varētu datus izmantot meklēšanā saskaņā ar standartizētu un kopēju datu formātu. Arhitektūra ir veidota tā, lai būtu iespējama jebkura tīkla dalībnieka komunikācija ar jebkuru citu tīkla dalībnieku. Tādējādi nav nedz centrāla datora servera, nedz centralizētas datubāzes, kurā uzglabā DNS profilus.

1.attēls. DNS datu apmaiņas topoloģija

Papildus tam, ka dalībvalstu vietnēs ievēro valstu juridiskos ierobežojumus, katra dalībvalsts var nolemt, kāda tipa aparatūra un programmatūra būtu jāizmanto, lai tās vietnē veiktu konfigurāciju saskaņā ar Lēmumā 2008/615/TI paredzētajām prasībām.

5.3.   Drošības standarti un datu aizsardzība

Ir apsvērti un ieviesti trīs drošības līmeņi.

5.3.1.   Datu līmenis

DNS profilu datus, ko iesniegusi katra dalībvalsts, paredzēts sagatavot saskaņā ar kopējiem datu aizsardzības standartiem, lai pieprasījuma iesniedzējas dalībvalstis saņemtu atbildi, kurā galvenokārt būtu norādīts vai IR vai NAV konstatēta ATBILSME, kā arī – ja ir konstatēta ATBILSME – norāda identifikācijas numuru, kurā nav iekļauti nekādi personas dati. Pēc tam, kad saņemts paziņojums par ATBILSMI, turpmāku izmeklēšanu veiks divpusēji saskaņā ar spēkā esošiem juridiskiem un organizatoriskiem noteikumiem par attiecīgo dalībvalstu piekļuves punktu izmantošanu.

5.3.2.   Sakaru līmenis

DNS profila informācijas sūtījumus (pieprasījumus un atbildes) pirms pārsūtīšanas citām dalībvalstīm šifrēs, izmantojot modernu mehānismu, kas ir saskaņā ar atvērtiem standartiem, piemēram, s/MIME.

5.3.3.   Pārsūtīšanas līmenis

Visus šifrētos DNS profila informācijas sūtījumus pārsūtīs citām dalībvalstīm, starptautiskā mērogā izmantojot virtuālu privātu tunelēšanas sistēmu (tunneling system), ko apsaimnieko uzticams tīkla pakalpojumu sniedzējs, valstu mērogā savukārt nodrošinot drošas saites ar tunelēšanas sistēmu, par kurām ir atbildīgas attiecīgās valstis. Tādai virtuālai privātai tunelēšanas sistēmai nav savienojuma punktu ar atklātībā pieejamo internetu.

5.4.   Šifrēšanas mehānisma protokoli un standarti: s/MIME un saistītas pakotnes (packages)

Lai šifrētu DNS profila informācijas sūtījumus, izmantos atvērtā standarta protokola s/MIME paplašinājumu, ko pievienos e-pasta standartam SMTP. Protokols s/MIME (V3) ļauj izmantot parakstītus sūtījumus, drošības iezīmes (security labels) un drošus e-pastu sarakstus, turklāt tas ir papildu slānis (layer) CMS sintaksei (Cryptographic Message Syntax – CMS), kas ir Interneta tehniskās uzdevumgrupas (IETF) specifikācija, lai nodrošinātu sūtījumu kriptogrāfisku aizsardzību. To var izmantot, lai digitāli parakstītu, apstrādātu (digest), autentificētu vai šifrētu jebkuru digitālu datu formu.

s/MIME mehānisma pamatā esošajam un tajā izmantotajam sertifikātam (certificate) ir jāatbilst X.509 standartam. Lai nodrošinātu ar citām Prīmes lietojumprogrammām kopējus standartus un procedūras, s/MIME šifrēšanas darbībām vai darbībām, ko paredzēts veikt dažādās komercializētās, publiski pieejamās sistēmās (COTS – Commercial Product of the Shelves) piemēro šādus noteikumus:

—	darbību secība ir šāda: no sākuma šifrē, pēc tam paraksta,

—	šifrēšanas algoritmu AES (Advanced Encryption Standard) ar 256 bitu atslēgas garumu (key length) un RSA ar 1 024 bitu atslēgas garumu attiecīgi piemēro simetriskai un asimetriskai šifrēšanai,

—	piemēro jaucējfunkcijas algoritmu (“hash algorithm”) SHA-1.

s/MIME funkcionalitāte ir integrēta ļoti daudzās modernās e-pasta programmatūras pakotnēs, tostarp Outlook, Mozilla Mail, kā arī Netscape Communicator 4.x, turklāt to izmanto savstarpējā komunikācijā visās galvenās e-pastu programmatūru pakotnēs.

Tā kā s/MIME standartu ir vienkārši integrēt visu valstu vietņu IT infrastruktūrā, tas ir izvēlēts kā lietderīgs mehānisms, lai nodrošinātu saziņas drošības līmeni. Lai efektīvāk sasniegtu mērķi “Koncepcijas pierādījums” (“Proof of Concept”) un lai mazinātu izmaksas, DNS datu apmaiņas prototipa pamatā savukārt ir izvēlēts atvērtais standarts JavaMail API. JavaMail API nodrošina vienkāršas e-pastu šifrēšanas un atšifrēšanas funkcijas, izmantojot s/MIME un/vai OpenPGP. Iecere ir sniegt vienu viegli izmantojamu API saskarni tiem e-pasta klientiem, kas vēlas sūtīt un saņemt šifrētus e-pastus, izmantojot vienu no abiem populārākajiem e-pastu šifrēšanas formātiem. Tāpēc jebkāds moderns JavaMail API īstenojums būs pietiekams, lai izpildītu Lēmumā 2008/615/TI izvirzītās prasības, piemēram, Bouncy Castle JCE (Java Cryptographic Extension) izstrādājums, ko izmantos, lai īstenotu s/MIME standartu, kas būtu visu dalībvalstu starpā veidotās DNS datu apmaiņas sistēmas prototipa pamatā.

5.5.   Lietojumprogrammu arhitektūra

Katra dalībvalsts citām dalībvalstīm iesniedz standartizētus DNS profilu datus, kas saskan ar pašreizējo kopējo ICD. To var izdarīt, sniedzot loģisku pārskatu par konkrētu valstu datubāzēm vai nodrošinot fiziski eksportētu datubāzi (indeksētu datubāzi).

Lietojumprogrammas darbības loģiku neatkarīgi no izmantotā izstrādājuma īsteno četri šādi galvenie komponenti: e-pasta serveris/s/MIME, lietojumprogrammas serveris, datu struktūras protokols (Data Structure Area), lai veiktu datu ienesi (fetching) un ievadīšanu (feeding) un reģistrētu saņemtos un nosūtītos sūtījumus, kā arī sakritību apstrādes sistēma (Match Engine).

Lai visām dalībvalstīm atvieglotu komponentu integrāciju to attiecīgajās valstu vietnēs, ir īstenota īpaša kopēja funkcionalitāte, izmantojot atvērto avotu komponentus, ko katra dalībvalsts var izvēlēties saskaņā ar savu IT politiku un noteikumiem. Tā kā ir paredzēts īstenot neatkarīgas iezīmes, lai gūtu piekļuvi indeksētām datubāzēm, kurās iekļauti ar Lēmumu 2008/615/TI reglamentētie DNS profili, katra dalībvalsts var brīvi izraudzīties aparatūras un programmatūras platformu, tostarp datubāzi un operētājsistēmas.

Ir izstrādāts un pastāvošajā kopējā tīklā sekmīgi pārbaudīts DNS datu apmaiņas prototips. Versija 1.0 jau darbojas reāla darba apstākļos, un to izmanto, veicot ikdienas darbības. Dalībvalstis var izmantot kopīgi izstrādātus IT izstrādājumus, tomēr tās var arī attīstīt savus izstrādājumus. Kopējā izstrādājuma komponentus uzturēs, piemēros un turpinās attīstīt saskaņā ar izmaiņām IT tehnoloģijās, kriminālistikā un/vai saskaņā ar funkcionālām policijas vajadzībām.

2.attēls. Lietojumprogrammas topoloģijas pārskats

5.6.   Lietojumprogrammas arhitektūrā izmantotie protokoli un standarti:

5.6.1.    XML

DNS datu apmaiņā kā pielikumu SMTP e-pasta sūtījumiem pilnībā izmantos XML shēmu. Paplašināmās iezīmēšanas valoda (eXtensible Markup Language – XML) ir Pasaules tīmekļa konsorcija (W3C) ieteikta vispārēja iezīmēšanas valoda (markup language), lai izstrādātu īpašas iezīmēšanas valodas, kas ļautu aprakstīt daudzus dažādu tipu datus. DNS profila apraksts, kas ir piemērots, lai visas dalībvalstis apmainītos ar datiem, ir izstrādāts, ICD dokumentos izmantojot XML valodu un XML shēmu.

5.6.2.    ODBC

Atvērto datubāzu savienojamība (Open DataBase Connectivity) dod iespēju izmantot standarta programmatūras API saskarnes metodi, lai piekļūtu datubāzu pārvaldības sistēmām (database management systems), turklāt tā darbojas neatkarīgi no programmēšanas valodām, datubāzes un operētājsistēmām. Tomēr ODBC ir arī savi trūkumi. Liela skaita klientu aparatūras administrēšana var būt saistīta ar daudziem draiveriem un DLLs. Šī sarežģītība var palielināt sistēmas administrēšanas izmaksas.

5.6.3.    JDBC

Java datubāzes savienojamība (Java DataBase Connectivity – JDBC) ir API saskarne ar Java programmēšanas valodu, ar ko nosaka, kā klients piekļūst datubāzei. Pretstatā ODBC, lietojot JDBC, darbvirsmā (desktop) nav vajadzīgs lietot konkrētu lokālu DLLs kopumu.

Šajā diagrammā ir parādīta katras dalībvalsts vietnē veiktās DNS profilu pieprasījumu un atbilžu apstrādes darbību loģika. Gan pieprasījumu, gan atbilžu datu plūsma ir mijiedarbībā ar neitrāliem datiem (neutral data), kas aptver dažādu datu kopumus ar kopēju struktūru.

3. attēls. Pārskats par katrā dalībvalsts vietnē notiekošo lietojumprogrammu datu plūsmu

5.7.   Saziņas sistēmas

5.7.1.   Kopējais saziņas tīkls: TESTA un ar to saistīta infrastruktūra

Lai dalībvalstis savstarpēji nosūtītu pieprasījumus un saņemtu atbildes, lietojumprogrammās DNS datu apmaiņai izmantos e-pastu, kas ir asinhrons mehānisms. Tā kā katrai dalībvalstij ir vismaz viens valsts piekļuves punkts TESTA tīklam, DNS datu apmaiņu veiks, izmantojot TESTA tīklu. TESTA tīklā e-pasta releja serveris dod iespēju izmantot vairākus papildu pakalpojumus. Papildus tam, ka TESTA tīklā uztur īpašas e-pasta sistēmas, tās infrastruktūra var īstenot e-pasta sarakstu izsūtīšanu un maršrutēšanas principus. Tas ļauj TESTA tīklu izmantot par datu sadales sistēmu (clearing house) tām iestādēm adresētiem sūtījumiem, kuras ir savienotas ar ES domēniem. Var uzstādīt arī vīrusu apkarošanas mehānismus.

TESTA e-pasta releja pamatā ir augstas pieejamības aparatūras platforma (high availability hardware platform), kura ir izvietota centrālajā TESTA lietojumprogrammas objektā un kuru aizsargā ar ugunssienu. TESTA tīkla domēna vārdu sistēma (Domain Name Services – DNS) pārveidos resursu norādes IP adresēs un slēps adresēto informāciju no lietotāja un no lietojumprogrammas.

5.7.2.   Drošības apsvērumi

TESTA sistēma ir īstenota saskaņā ar virtuāla privāta tīkla (Virtual Private Network – VPN) koncepciju. VPN tīklu izveidē izmantoto marķējumu komutācijas tehnoloģiju (Tag Switching Technology) attīstīs, lai tā strādātu ar vairākprotokolu iezīmju komutāciju (Multi-Protocol Label Switching – MPLS) standartu, ko ir izstrādājusi Interneta tehniskā uzdevumgrupa (IETF).

MPLS ir IETF standarta tehnoloģija, ar ko paātrina tīklā notiekošās datu plūsmas ātrumu, izvairoties no starpnieku maršrutētāju (intermediate routers (hops)) veiktas pakešu analīzes. To dara, pamatojoties uz tā sauktajām iezīmēm (labels), ko paketei pievieno pamatsistēmas malas maršrutētāji (edge routers of the backbone), pamatojoties uz pārsūtīšanas informācijas bāzē (forwarding information base – FIB) iekļauto informāciju. Iezīmes izmanto arī, lai īstenotu virtuālus privātus tīklus (VPN).

MPLS ļauj gūt labumu gan no 3. slāņa maršrutēšanas (layer 3 routing), gan izmantot 2. slāņa komutāciju (layer 2 switching) priekšrocības. Tā kā IP adresēm pārsūtot caur pamatsistēmu (backbone), nenotiek to izvērtējums, MPLS neuzliek nekādus ierobežojumus IP adresēšanai.

Turklāt e-pastu sūtījumiem TESTA tīklā piemēro s/MIME šifrēšanas mehānismu. Nezinot atslēgu un bez pareiza sertifikāta, šajā tīklā nav iespējams atšifrēt sūtījumus.

5.7.3.   Saziņas tīklā izmantotie protokoli un standarti

5.7.3.1.

SMTP Vienkāršo pasta pārsūtīšanas protokolu (Simple Mail Transfer Protocol) faktiski internetā izmanto kā e-pasta pārsūtīšanas standartu. SMTP standarts ir samērā vienkāršs teksta protokols, kurā ir precizēts viens vai vairāki sūtījuma saņēmēji un pēc tam notiek sūtījuma teksta pārsūtīšana. SMTP standarts saskaņā ar IETF norādēm izmanto TCP protokola 25. pieslēgvietu (port). Lai attiecīgam domēna vārdam noteiktu SMTP serveri, izmanto MX (Mail eXchange) DNS (Domain Name Systems) sistēmas ierakstu. Tā kā šis protokols sākotnēji bija teksta formāta ASCII standartkods, pastāvēja bināru datņu apstrāde sproblēmas. Tādus standartus kā MIME izstrādāja, lai varētu kodēt bināras datnes to pārsūtīšanai, izmantojot SMTP. Pašlaik vairums SMTP serveru darbojas ar 8BITMIME un s/MIME paplašinājumu, kas ļauj bināras datnes pārsūtīt gandrīz tikpat viegli kā parastu tekstu. s/MIME apstrādes noteikumi ir aprakstīti iedaļā s/MIME (skatīt 5.4. nodaļu). SMTP ir stūmējtehnoloģijas protokols (“push” protocol), kas nedod iespēju no attālas piekļuves servera izmantot vilcējtehnoloģijas un pēc pieprasījuma lejupielādēt (“pull”) sūtījumus. Lai to darītu, pasta klientam ir jāizmanto POP3 vai IMAP. Lai veiktu DNS datu apmaiņu, ir pieņemts lēmums izmantot POP3 protokolu.

5.7.3.2.

POP Vietēji e-pasta klienti izmanto pasta nodaļas protokola 3. versiju (Post Office Protocol version 3 – POP3), kas ir lietojumslāņa (application-layer) interneta standarta protokols, lai e-pastam piekļūtu no attāla servera, izmantojot TCP/IP savienojumu. Ar SMTP protokola SMTP Submit profilu, e-pasta klienti sūta sūtījumus internetā vai privātā tīklā (corporate network). MIME izmanto kā standartu pielikumiem un e-pastu tekstam, kas nav ASCII standartkodā. Kaut gan, izmantojot gan POP3, gan SMTP protokolu nav vajadzīgs, lai e-pasti būtu MIME standartā, tomēr MIME parasti izmanto interneta e-pastos, tāpēc POP klientiem arī ir jāsaprot un jāizmanto MIME standarts. Tāpēc Lēmumā 2008/615/TI paredzētajās saziņas darbībās iekļaus POP komponentus.

5.7.4.   Tīkla adrešu piešķire

Darbības vide

Eiropas IP reģistrācijas iestāde (European IP registration authority – RIPE) pašlaik TESTA vajadzībām ir atvēlējusi īpašu C klases apakštīkla adrešu kopumu (C class subnet). Vajadzības gadījumā TESTA tīklam turpmāk var piešķirt papildu adrešu kopumus. IP adreses dalībvalstīm piešķir, pamatojoties uz ģeogrāfisku Eiropas shēmu. Datu apmaiņa dalībvalstu starpā saistībā ar Lēmumu 2008/615/TI notiek Eiropas mēroga loģiski slēgtā IP tīklā.

Testēšanas vide

Lai ikdienā visām dalībvalstīm, kas pieslēgušās tīklam, nodrošinātu efektīvus darbības apstākļus, slēgtā tīklā jāizveido testēšanas sistēma, kurai pieslēgtos dalībvalstis, kas gatavojas pievienoties tīklam. Attiecīgo dalībvalstu vietnēs būtu jādara pieejams precizētu parametru saraksts, tostarp IP adreses, tīkla iestatījumi, e-pasta domēni, kā arī lietojuma lietotāja konti. Turklāt testēšanas nolūkos ir izveidots DNS pseidoprofilu kopums.

5.7.5.   Konfigurācijas parametri

Ir izveidota droša e-pastu sistēma, izmantojot domēnu eu-admin.net. Šis domēns un tā adreses nebūs pieejamas no adresēm, kas neatrodas ES TESTA tīkla domēnā, jo vārdus atpazītu tikai TESTA centrālais DNS serveris, kas nav pieslēgts internetam.

TESTA vietņu adrešu (resursdatora vārdu) kartēšanu (mapping) attiecībā uz to IP adresēm veic TESTA DNS sistēma. Attiecībā uz katru lokālo domēnu šim TESTA centrālam DNS serverim pievienos e-pasta ierakstu, kas visus TESTA lokāliem domēniem sūtītos e-pasta sūtījumus pārsūtīs TESTA centrālajam pasta relejam. Šis TESTA centrālais pasta relejs pēc tam tos pārsūtīs konkrētiem lokālā domēna e-pasta serveriem, izmantojot lokālā domēna e-pasta adreses. Šādi pārsūtot e-pastu, tajos iekļautā nozīmīgā informācija būs nosūtīta, izmantojot tikai Eiropas mēroga slēgto tīkla infrastruktūru un apejot nedrošo internetu.

Visu dalībvalstu vietnēs jāizveido apakšdomēni ( kursīvā treknrakstā ) saskaņā ar šādu sintaksi:

“ application-type.pruem. Member State-code.eu-admin.net”, kur

“ Member State-code”(dalībvalsts kods) ir dalībvalstu divu burtu kods (t. i., AT, BE u. c.);

savukārt “ application-type ” (lietojuma tips) ir viena no vienībām – DNA un FP.

Minētās sintakses piemērošanai vajadzīgie dalībvalstu apakšdomēni ir parādīti šajā tabulā:

MS	Sub Domains	Comments
BE	dna.pruem.be.eu-admin.net	Setting up a secure local link to the existing TESTA II access point
	fp.pruem.be.eu-admin.net
BG	dna.pruem.bg.eu-admin.net
	fp.pruem.bg.eu-admin.net
CZ	dna.pruem.cz.eu-admin.net
	fp.pruem.cz.eu-admin.net
DK	dna.pruem.dk.eu-admin.net
	fp.pruem.dk.eu-admin.net
DE	dna.pruem.de.eu-admin.net	Using the existing TESTA II national access points
	fp.pruem.de.eu-admin.net
EE	dna.pruem.ee.eu-admin.net
	fp.pruem.ee.eu-admin.net
IE	dna.pruem.ie.eu-admin.net
	fp.pruem.ie.eu-admin.net
EL	dna.pruem.el.eu-admin.net
	fp.pruem.el.eu-admin.net
ES	dna.pruem.es.eu-admin.net	Using the existing TESTA II national access point
	fp.pruem.es.eu-admin.net
FR	dna.pruem.fr.eu-admin.net	Using the existing TESTA II national access point
	fp.pruem.fr.eu-admin.net
IT	dna.pruem.it.eu-admin.net
	fp.pruem.it.eu-admin.net
CY	dna.pruem.cy.eu-admin.net
	fp.pruem.cy.eu-admin.net
LV	dna.pruem.lv.eu-admin.net
	fp.pruem.lv.eu-admin.net
LT	dna.pruem.lt.eu-admin.net
	fp.pruem.lt.eu-admin.net
LU	dna.pruem.lu.eu-admin.net	Using the existing TESTA II national access point
	fp.pruem.lu.eu-admin.net
HU	dna.pruem.hu.eu-admin.net
	fp.pruem.hu.eu-admin.net
MT	dna.pruem.mt.eu-admin.net
	fp.pruem.mt.eu-admin.net
NL	dna.pruem.nl.eu-admin.net	Intending to establish a new TESTA II access point at the NFI
	fp.pruem.nl.eu-admin.net
AT	dna.pruem.at.eu-admin.net	Using the existing TESTA II national access point
	fp.pruem.at.eu-admin.net
PL	dna.pruem.pl.eu-admin.net
	fp.pruem.pl.eu-admin.net
PT	dna.pruem.pt.eu-admin.net	......
	fp.pruem.pt.eu-admin.net	......
RO	dna.pruem.ro.eu-admin.net
	fp.pruem.ro.eu-admin.net
SI	dna.pruem.si.eu-admin.net	......
	fp.pruem.si.eu-admin.net	.......
SK	dna.pruem.sk.eu-admin.net
	fp.pruem.sk.eu-admin.net
FI	dna.pruem.fi.eu-admin.net	[To be inserted]
	fp.pruem.fi.eu-admin.net
SE	dna.pruem.se.eu-admin.net
	fp.pruem.se.eu-admin.net
UK	dna.pruem.uk.eu-admin.net
	fp.pruem.uk.eu-admin.net

2. NODAĻA. Daktiloskopijas datu apmaiņa (saskarņu kontroles dokuments – interface control document)

Dokumentu saskarne “Control Document (dokumentu kontrole)” ir izstrādāta, lai noteiktu prasības, ka jāievēro, dalībvalstīm savstarpēji veicot daktiloskopijas informācijas apmaiņu, izmantojot automatizētas pirkstu nospiedumu identifikācijas sistēmas (Automated Fingerprint Identification Systems – AFIS). Tajā ir izmantots Interpola īstenotais ANSI/NIST-ITL 1-2000 (INT-I, Version 4.22b).

Šī versija attiecas uz visām 1. tipa, 2. tipa, 4. tipa, 9. tipa, 13. tipa un 15. tipa loģisku ierakstu pamatdefinīcijām, kuras ir vajadzīgas daktiloskopijas apstrādei, kurā izmanto attēlus un papilārlīniju detaļas.

1.   Datņu satura pārskats

Vienā daktiloskopijas datnē ir vairāki loģiski elementi. Oriģinālajā ANSI/NIST-ITL 1-2000 standartā ir sešpadsmit dažādu tipu elementu. Attiecīgas ASCII nošķīrējzīmes lieto, nodalot katru ierakstu, un ierakstos – laukus un pakārtotus laukus.

Tikai sešu tipu ierakstus lieto, lai datu izcelsmes aģentūra dalītos informācijā ar datu saņēmēju aģentūru:

1. tips	→	informācija par darbību
2. tips	→	burtu un skaitļu dati par personām un attiecīgām lietām
4. tips	→	melnbalti tonāli daktiloskopiski attēli ar lielu izšķirtspēju
9. tips	→	papilārlīniju detaļu uzskaitījums
13. tips	→	ierakstīti latenti attēli ar maināmu izšķirtspēju
15. tips	→	ierakstīti plaukstu nospiedumu attēli ar maināmu izšķirtspēju

1.1.   1. tips – datnes galvene

Šajos ierakstos ir maršrutēšanas informācija un informācija par pārējo datnes struktūru. Šajos ierakstos ir noteikti arī darbību tipi, kas atbilst šādām plašām kategorijām.

1.2.   2. tips – apraksts

Šajos ierakstos ir tekstuāla informācija, kas attiecas gan uz sūtītāju, gan uz saņēmēju aģentūru.

1.3.   4. tips – ierakstīti melnbalti tonāli attēli ar lielu izšķirtspēju

Tādus ierakstus izmanto, lai dalītos ar melnbaltiem tonāliem daktiloskopijas attēliem, kas ir nolasīti ar lielu (astoņu bitu) izšķirtspēju, 500 pikseļiem collā. Daktiloskopijas attēlus saspiež, izmantojot WSQ algoritmu, ar koeficientu līdz 15:1. Nedrīkst lietot citus saspiešanas algoritmus vai nesaspiestus attēlus.

1.4.   9. tips – ierakstītas papilārlīniju detaļas

9. tipa ierakstus izmanto, lai veiktu apmaiņu ar papilārlīniju parametriem vai papilārlīniju detaļu datiem. Viens iemesls to izmantojumam ir izvairīties no nevajadzīgas AFIS kodēšanas procesu atkārtošanās un daļēji – lai varētu pārraidīt AFIS kodus, kuros ir mazāk datu nekā atbilstošos attēlos.

1.5.   13. tips – ierakstīti latenti attēli ar maināmu izšķirtspēju

Tādus ierakstus izmanto, lai apmainītos ar ierakstītiem latentiem attēliem ar maināmu izšķirtspēju un latentiem plaukstu nospieduma attēliem, kā arī ar tekstuālu burtu un skaitļu informāciju. Attēlu skenējuma izšķirtspējai ir jābūt 500 pikseļiem collā ar 256 toņu pelēkumu. Ja latentā attēla kvalitāte ir pietiekama, to saspiež, izmantojot WSQ algoritmu. Vajadzības gadījumā attēlu izšķirtspēju var atspiest vairāk nekā līdz 500 pikseļiem collā un vairāk nekā līdz 256 toņu pelēkumam saskaņā ar divpusēju vienošanos. Šādos gadījumos ļoti ieteicams lietot JPEG 2000 (sk. 7. papildinājumu).

1.6.   Ierakstīti plaukstu nospiedumu attēli ar maināmu izšķirtspēju

15. tipa marķētus lauka attēlu ierakstus izmanto, lai veiktu apmaiņu ar plaukstu nospiedumu attēliem ar maināmu izšķirtspēju, kā arī ar tekstuālu burtu un skaitļu informāciju. Skenēto attēlu izšķirtspējai ir jābūt 500 pikseļiem collā ar 256 toņu pelēkumu. Lai mazinātu visu plaukstu nospiedumu attēlu datu apjomu, tie jāsaspiež, izmantojot WSQ algoritmu. Vajadzības gadījumā attēlu izšķirtspēju var atspiest vairāk nekā līdz 500 pikseļiem collā un vairāk nekā līdz 256 toņu pelēkumam saskaņā ar divpusēju vienošanos. Šādos gadījumos ļoti ieteicams ir lietot JPEG 2000 (sk. 7. papildinājumu).

2.   Ierakstu forma

Vienā darbību datnē ir viens vai vairāki loģiski ieraksti. Katram loģiskam ierakstam datnē ir vairāki informācijas lauki, kas ir piemēroti attiecīga tipa ierakstiem. Katrā informācijas laukā var būt viens vai vairāki elementāri vienvērtīgi informācijas elementi. Kopumā minētos elementus izmanto, lai atklātu dažādus attiecīgā lauka datu aspektus. Informācijas laukā var būt arī viens vai vairāki sagrupēti informācijas elementi, kas laukā atkārtojas vairākkārt. Tādas informācijas elementu grupas dēvē par pakārtotiem laukiem. Tādējādi informācijas laukā var būt viens vai vairāki pakārtoti informācijas elementu lauki.

2.1.   Informācijas nošķīrēji

Marķētu lauku loģiskos ierakstos liek lietā informācijas norobežošanas mehānismus, izmantojot četrus ASCII informācijas nošķīrējus. Norobežota informācija var būt elementi kādā laukā vai pakārtotā laukā, laukos, kas atrodas loģiskos ierakstos, vai arī daudzkārtējos pakārtotos laukos. Informācijas nošķīrējus nosaka pēc standarta ANSI X3.4. Tādas zīmes izmanto, lai nošķirtu un klasificētu informāciju loģiskā nozīmē. Hierarhiski datnes nošķīrēja (File Separator – “FS”) zīme aptver visvairāk informācijas, nākamā ir grupu nošķīrēja (Group Separator – “GS”), ierakstu nošķīrēja (Record Separator – “RS”) un visbeidzot vienību nošķīrēja (Unit Separator – “US”) zīme. 1. tabulā ir uzskaitīti minētie ASCII nošķīrēji un aprakstīts to lietojums saskaņā ar minēto standartu.

Informācijas nošķīrēji no funkciju viedokļa būtu jāuzskata par norādēm, kāda tipa dati tām seko. Zīme “US” nošķir atsevišķus informācijas elementus kādā laukā vai pakārtotā laukā. Tas nozīmē, ka nākamais informācijas elements ir attiecīga lauka vai pakārtota lauka datu fragments. Vairāki pakārtoti lauki vienā laukā, kas ir nošķirts ar “RS” zīmi, liecina, ka sākas nākamā atkārtota(-u) informācijas elementa(-u) grupa. Nošķīrējzīme “GS”, ko lieto starp informācijas laukiem, liecina, ka sākas jauns lauks – pirms lauka identifikācijas numura, kas tai tūdaļ seko. Līdzīgi – par jauna loģiska ieraksta sākumu liecina “FS” zīme.

Šīm četrām zīmēm ir nozīme tikai tad, ja tās ASCII teksta ierakstu laukos lieto kā datu elementu nošķīrējas. Šīm zīmēm, kas ir sastopamas bināros attēlu ierakstos un bināros laukos, nav patstāvīgas nozīmes – tās tikai pieder pie datiem, ar kuriem veic apmaiņu.

Parastos apstākļos nevajadzētu būt tukšiem laukiem vai informācijas elementiem, tāpēc starp katriem diviem datu elementiem būtu jābūt tikai vienai nošķīrējzīmei. Šim likumam izņēmums ir gadījumos, ja kādā darbībā dati laukos vai informācijas elementos nav pieejami, to nav vai tie nav obligāti, un darbības apstrāde nav atkarīga no tā, vai attiecīgie dati ir pieejami. Tādos gadījumos vairākas un blakus esošas nošķīrējzīmes parādīsies kopā, un nošķīrējzīmju starpā nevajadzēs iespraust butaforiskus datus.

Uz tādu lauku definīciju, kuri sastāv no trijiem informācijas elementiem, attiecas šādi noteikumi. Ja otrajā informācijas elementā nav informācijas, tad divas blakus esošas “US” informācijas nošķīrējzīmes atradīsies starp pirmo un trešo informācijas elementu. Ja nav informācijas nedz otrajā, nedz trešajā informācijas elementā, būtu jālieto trīs nošķīrējzīmes – divas “US” zīmes, kas papildina beigu lauka vai pakārtota lauka nošķīrējzīmi. Īsumā – ja viens vai vairāki obligāti vai fakultatīvi lauka vai pakārtota lauka informācijas elementi nav pieejami, būtu jāiesprauž attiecīgs skaits nošķīrējzīmju.

Ir iespējams, ka blakus atrodas divas vai vairākas no četrām izmantojamām nošķīrējzīmēm. Ja trūkst datu vai tādu nav informācijas elementos, pakārtotos laukos vai laukos, ir jābūt par vienu nošķīrējzīmi mazāk nekā ir datu elementu, pakārtotu lauku vai prasītu lauku.

1. tabula. Izmantotie nošķīrēji

Code	Type	Description	Hexadecimal Value	Decimal Value
US	Unit Separator	Separates information items	1F	31
RS	Record Separator	Separates subfields	1E	30
GS	Group Separator	Separates fields	1D	29
FS	File Separator	Separates logical records	1C	28

2.2.   Ierakstu izkārtojums

Loģiskos ierakstos ar marķētiem laukiem katru izmantoto informācijas lauku numurē saskaņā ar šo standartu. Katra lauka formā ir loģiskā ieraksta tipa numurs, kam seko punkts “.”, lauka numurs, kam seko kols “:”, kam savukārt seko informācija, kas piederas attiecīgā laukā. Marķētu lauku numurs var būt jebkurš skaitlis no viens līdz deviņi, ko raksta starp punktu “.” un kolu “:”. To interpretē kā lauka numuru nenegatīvos skaitļos. Tas nozīmē, ka lauks numur “2.123:” ir līdzvērtīgs laukam numur “2.000000123:”, un tas ir jāinterpretē tāpat.

Visā šajā dokumentā skaidrojumam trīsciparu skaitļi ir lietoti tādu lauku numurēšanai, kas atrodas katrā šeit aprakstītā marķētu lauku loģiskā ierakstā. Lauku numuri būs doti šādā formā – “TT.xxx:”, un “TT” apzīmē vienzīmes vai divzīmju tipa ierakstus, kam seko punkts. Nākamās trīs zīmes ir attiecīgā lauka numurs, kam seko kols. Kolam seko informatīvs ASCII apraksts vai attēla dati.

1. tipa un 2. tipa loģiskos ierakstos ir tikai ASCII teksta datu lauki. Katrā šā tipa ierakstā kā pirmo ASCII lauku ieraksta visu ierakstu pilnībā (arī lauku numurus, kolus un nošķīrējzīmes). ASCII datņu nošķīrēja “ASCII File Separator – FS” zīme (ar ko apzīmē loģisku ierakstu vai darbību beigas) seko pēdējam ASCII informācijas baitam, un to iekļauj ierakstā.

Pretstatā marķētu lauku jēdzienam 4. tipa ierakstos ir tikai bināri dati, ko ieraksta kā sakārtotus fiksēta garuma binārus laukus. Ierakstu visā garumā ieraksta pirmajā katra ieraksta četru baitu binārā laukā. Tādiem bināriem ierakstiem nepieraksta ne ieraksta numuru līdz ar punktu, ne lauka identifikācijas numuru līdz ar sekojošu kolu. Turklāt, tā kā tādu ierakstu lauku garumi ir vai nu fiksēti, vai konkrēti noteikti, nevienu no četrām nošķīrējzīmēm (“US”, “RS”, “GS” vai “FS”) neinterpretē citādi kā vien binārus datus. Bināros ierakstos “FS” zīmi nelieto kā ierakstu nošķīrēju vai darbības beigu zīmi.

3.   1. tipa loģiski dati – datnes galvene

Šajā ierakstā ir aprakstīta datnes struktūra, datnes tips un dota cita svarīga informācija. Zīmju kompleksā, ko izmanto 1. tipa laukos, ir tikai 7 bitu ANSI kods savstarpējai informācijas apmaiņai.

3.1.   1. tipa loģisku datu lauki

3.1.1.   1.001. lauks – loģiskā ieraksta garums (Logical Record Length – LEN)

Šajā laukā ir visa 1. tipa loģiskā ieraksta baitu kopskaits. Lauks sākas ar “1.001:”, kam seko ieraksta kopgarums, kurā ietverta katra zīme, kas atrodas katrā laukā, un informācijas nošķīrēji.

3.1.2.   1.002. lauks – versijas numurs (Version Number – VER)

Lai lietotāji zinātu, kādu ANSI/NIST standarta versiju lieto programmatūra vai sistēma, kas izstrādā datni, šajā četru baitu laukā ir konkrēti norādīts īstenotā standarta versijas numurs. Pirmie divi baiti norāda uz pamatversijas atsauces numuru, nākamie divi – uz mazāk būtisku uzlabojumu numuru. Piemēram, oriģinālais 1986. gada standarts būtu uzskatāms par pirmo versiju, un to apzīmētu ar “0100”, bet pašreizējais ANSI/NIST-ITL 1-2000 standarts ir “0300”.

3.1.3.   1.003. lauks – datnes saturs (File Content – CNT)

Šajā laukā ir uzskaitīts katrs datnes ieraksts pēc ieraksta tipa un secība, kādā ieraksti ir fiksēti loģiskā datnē. Tajā ir viens vai vairāki pakārtoti lauki, un katrā no tiem savukārt ir divi informācijas elementi, kuros ir aprakstīts vienīgais loģiskais ieraksts, kas atrodas aplūkojamā datnē. Pakārtotos laukus aizpilda tādā pašā secībā, kā ieraksta un pārraida ierakstus.

Pirmais informācijas elements pirmajā pakārtotajā laukā ir “1”, lai dotu atsauci uz 1. tipa ierakstu. Tam seko otrs informācijas elements, kurā ir pārējo datnes ierakstu skaits. Turklāt skaits ir vienāds ar 1.003. lauka atlikušo pakārtoto lauku skaitu.

Katrs no atlikušajiem pakārtotajiem laukiem ir saistīts ar vienu ierakstu datnē, un pakārtoto lauku secība atbilst ierakstu secībai. Katrā pakārtotā laukā ir divi informācijas elementi. Ar pirmo identificē ieraksta tipu. Otrais ir ieraksta IDC. “US” zīmi lieto, lai nošķirtu abus informācijas elementus.

3.1.4.   1.004. lauks – darbību tips (Type of Transaction – TOT)

Šajā laukā ir mnemonisks kods (piekļuves atslēga) no trijiem burtiem, kurš apzīmē darbības tipu. Kodi var atšķirties no tiem kodiem, ko lieto citos ANSI/NIST standartu īstenojumos.

CPS (Criminal Print-to-Print Search) – meklējumi, salīdzinot kriminālnoziedznieku atstātos nospiedumus. Šī darbība ir pieprasījums nospiedumu datubāzē meklēt ierakstus, kas attiecas uz kādu kriminālnoziegumu. Attiecīgās personas atstātie nospiedumi ir jāiekļauj datnē kā ar WSQ saspiesti attēli.

Ja dati nebūs atrasti (No-HIT), atbildē būs šādi loģiski ieraksti:

—	1 1. tipa ieraksts,

—	1 2. tipa ieraksts.

Ja dati būs atrasti (HIT), atbildē būs šādi loģiski ieraksti:

—	1 1. tipa ieraksts,

—	1 2. tipa ieraksts,

—	1-14 4. tipa ieraksti.

CPS TOT ir apkopoti A.6.1. tabulā (6. papildinājums).

PMS (Print-to-Latent Search) – datu meklējumi neidentificētu latentu nospiedumu datubāzē. Šādu darbību izmanto, ja kādu nospiedumu kompleksa atbilsme ir jāmeklē neidentificētu latentu nospiedumu datubāzē (Unidentified Latent database). Atbildē būs AFIS meklējumā iegūts lēmums “dati ir atrasti/dati nav atrasti” (Hit/No-Hit). Ja ir vairāki neidentificēti latenti nospiedumi, būs vairākas atbildes par SRE darbībām un katrā darbībā būs apstrādāts viens latentais nospiedums. Attiecīgās personas atstātie nospiedumi ir jāiekļauj datnē kā ar WSQ saspiesti attēli.

Ja dati nebūs atrasti (No-HIT), atbildē būs šādi loģiski ieraksti:

—	1 1. tipa ieraksts,

—	1 2. tipa ieraksts.

Ja dati būs atrasti (HIT), atbildē būs šādi loģiski ieraksti:

—	1 1. tipa ieraksts,

—	1 2. tipa ieraksts,

—	1 13. tipa ieraksts.

PMS TOT ir apkopoti A.6.1. tabulā (6. papildinājums).

MPS (Latent-to-Print Search) – latentu nospiedumu datu meklējumi nospiedumu datubāzē. Šādu darbību izmanto, ja latenti nospiedumi ir jāmeklē nospiedumu datubāzē. Datnē ir jāiekļauj informācija par latentām papilārlīniju detaļām un attēls (saspiests ar WSQ).

Ja dati nebūs atrasti (No-HIT), atbildē būs šādi loģiski ieraksti:

—	1 1. tipa ieraksts,

—	1 2. tipa ieraksts.

Ja dati būs atrasti (HIT), atbildē būs šādi loģiski ieraksti:

—	1 1. tipa ieraksts,

—	1 2. tipa ieraksts,

—	1 4. tipa vai 15. tipa ieraksts.

MPS TOT ir apkopoti A.6.4. tabulā (6. papildinājums).

MMS (Latent-to-Latent Search) – latentu nospiedumu salīdzinājums savā starpā. Veicot šo darbību, datnē ir latents nospiedums, kas jāsalīdzina ar neidentificētu latentu nospiedumu datubāzē (Unidentified Latent database) glabātiem datiem, lai noskaidrotu dažādu noziegumu vietu savstarpējo saistību. Datnē ir jāiekļauj informācija par latentām papilārlīniju detaļām un attēls (saspiests ar WSQ).

Ja dati nebūs atrasti (No-HIT), atbildē būs šādi loģiski ieraksti:

—	1 1. tipa ieraksts,

—	1 2. tipa ieraksts.

Ja dati būs atrasti (HIT), atbildē būs šādi loģiski ieraksti:

—	1 1. tipa ieraksts,

—	1 2. tipa ieraksts,

—	1 13. tipa ieraksts.

MMS TOT ir apkopoti A.6.4. tabulā (6. papildinājums).

SRE – šo darbību datu saņēmēja aģentūra sūta atpakaļ kā atbildi uz iesūtītiem daktiloskopijas datiem. Atbildē būs AFIS meklējumā iegūts lēmums “dati ir atrasti/dati nav atrasti” (Hit/No-Hit). Ja kandidātu ir vairāki, atpakaļ sūtīs vairākas SRE darbības un katram kandidātam būs veltīta viena darbība.

SRE TOT ir apkopoti A.6.2. tabulā (6. papildinājums).

ERR – šo darbību datu saņēmēja AFIS sūta atpakaļ kā atbildi, lai norādītu uz kļūdu darbībā. Tajā ir vēstījuma lauks (message field – ERM), kurā ir norādīta konstatētā kļūda. Atbildē būs šādi loģiski ieraksti:

—	1 1. tipa ieraksts,

—	1 2. tipa ieraksts.

ERR TOT ir apkopoti A.6.3. tabulā (6. papildinājums).

2. tabula. Pieļaujami darbību kodi

Transaction Type	Logical Record Type
	1	2	4	9	13	15
CPS	M	M	M	—	—	—
SRE	M	M	C	— (C in case of latent hits)	C	C
MPS	M	M	—	M (1*)	M	—
MMS	M	M	—	M (1*)	M	—
PMS	M	M	M*	—	—	M*
ERR	M	M	—	—	—	—

Atšifrējums:

M	=	obligāts (Mandatory)
M*	=	var iekļaut tikai vienu no abu tipu ierakstiem
O	=	fakultatīvs (Optional)
C	=	ar nosacījumu, ka dati ir pieejami (Conditional)
—	=	nav piekļuves
1*	=	ar nosacījumu – atkarībā no tā, kādas uzstādītas sistēmas izmanto darbā

3.1.5.   1.005. lauks – darbības datums (Date of Transaction – DAT)

Šajā laukā ir norādīts datums, kad darbība ir sākta, un tam ir jāatbilst ISO standartapzīmējumam –YYYYMMDD,

kur YYYY ir gads, MM ir mēnesis un DD ir mēneša diena. Viencipara skaitļu priekšā liek nulles. Piemēram, “19931004” nozīmē 1993. gada 4. oktobri.

3.1.6.   1.006. lauks – prioritāte (Priority – PRY)

Šajā fakultatīvajā laukā ir uzrādīta pieprasījuma prioritāte pakāpēs no 1 līdz 9. “1” ir lielākā prioritāte, un “9” – mazākā. “1. prioritātes” darbības apstrādā uzreiz.

3.1.7.   1.007. lauks – pieprasījuma saņēmējas aģentūras identifikators (Destination Agency Identifie – DAI)

Šajā laukā ir konkrēti norādīta darbības veicēja aģentūra.

Tajā ir divi informācijas elementi šādā formā – valsts kods un aģentūra (CC/agency).

Pirmajā informācijas elementā ir valsts kods (Country Code), ko definē, izmantojot ISO 3166 – tajā ir divas burtu vai ciparu zīmes. Otrs elements, aģentūra (agency), ir līdz 32 burtu vai ciparu zīmes garš brīvs teksts, un ar to identificē aģentūru.

3.1.8.   1.008. lauks – pieprasījuma iesniedzējas aģentūras identifikators (Originating Agency Identifier – ORI)

Šajā laukā ir konkrēti norādīta datnes izcelsmes aģentūra, un tā forma ir tāda pati kā DAI (1.007. lauks).

3.1.9.   1.009. lauks – darbības kontrolnumurs (Transaction Control Number TCN)

Kontrolnumurs ir domāts atsaucēm. Tam būtu jābūt datora ģenerētam un šādā formā –YYSSSSSSSSA,

kur YY ir darbības gads, SSSSSSSS ir astoņciparu sērijas numurs un A ir pārbaudes zīme, kas ģenerēta, ievērojot 2. papildinājumā paredzēto procedūru.

Ja TCN nav pieejams, lauku YYSSSSSSSS aizpilda ar nullēm un pārbaudes zīmi ģenerē, kā iepriekš norādīts.

3.1.10.   1.010. lauks – darbības atbildes kontrolnumurs (Transaction Control Response – TCR)

Ja ir izsūtīts pieprasījums, uz ko saņemta šāda atbilde, šajā fakultatīvajā laukā būs pieprasījuma atbildes darbības kontrolnumurs. Tālab tam ir tāda pati forma kā TCN (1.009. lauks).

3.1.11.   1.011. lauks – oriģinālā skenējuma izšķirtspēja (Native Scanning Resolution – NSR)

Šajā laukā ir uzrādīta normālā skenējuma izšķirtspēja sistēmai, ko izmanto darbības veicējs. Izšķirtspēju raksturo ar diviem cipariem, kam seko decimāldaļas punkts un pēc tā – vēl divi skaitļi.

Visām darbībām saskaņā ar Lēmumu 2008/615/TI nolasījumu koeficients ir 500 pikseļi collā jeb 19,68 pikseļi milimetrā.

3.1.12.   1.012. lauks – nominālā pārraides izšķirtspēja (Nominal Transmitting Resolution – NTR)

Šajā piecu baitu laukā ir konkrēti norādīta nominālā pārraides izšķirtspēja attēliem, ko pārraida. Izšķirtspēju izsaka pikseļos milimetrā – tādā pašā formā kā NSR (1.011. lauks).

3.1.13.   1.013. lauks – domēna nosaukums (Domain name – DOM)

Šajā obligātajā laukā ir identificēts domēna nosaukums lietotāja noteiktai 2. tipa loģiska ieraksta īstenošanai. Tajā ir divi informācijas elementi, un tie ir “INT-I{US}4.22{GS}”.

3.1.14.   1.014. lauks – Griničas laiks (Greenwich mean time – GMT)

Šis obligātais lauks nodrošina mehānismu, kā izteikt datumu un pulksteņa laiku Griničas laika (Greenwich Mean Time – GMT) vienībās. GMT laukā, ja to lieto, ir vispārējs datums, kas papildinās vietējo datumu, kas ir dots 1.005. laukā (DAT). GMT lauka lietojums likvidē vietējā laika nekonsekvences, kas izpaužas, ja darbību un atbildi pārraida starp divām vietām, ko šķir vairākas laika zonas. GMT laukā ir vispārpiemērojams datums un 24 stundu pulkstenis, kas nav atkarīgs no laika zonām. To atveido “CCYYMMDDHHMMSSZ” – kā 15 zīmju virkni, kurā datums ir sasaistīts ar GMT un kas beidzas ar “Z”. Zīmes “CCYY” rāda darbības gadu, zīmes “MM” rāda mēnešus, un zīmes “DD” rāda mēneša dienas, zīmes “HH” rāda stundas, “MM” rāda minūtes, un “SS” – sekundes. Pilnais datums nav lielāks par attiecīgās dienas datumu.

4.   2. tipa loģiski dati – ieraksts

Tādu ierakstu struktūras lielāko daļu nedefinē ar oriģinālo ANSI/NIST standartu. Šajos ierakstos ir informācija, kas rada īpašu ieinteresētību aģentūrām, kas sūta vai saņem attiecīgo datni. Lai nodrošinātu to, ka daktiloskopijas sistēmas, kas savā starpā sazinās, būtu saderīgas, ierakstā ir jābūt tikai šeit turpmāk uzskaitītiem laukiem. Šajā dokumentā ir konkrēti norādīts, kuri lauki ir obligāti, kuri fakultatīvi, un arī definēta atsevišķu lauku struktūra.

4.1.   2. tipa loģisku datu lauki

4.1.1.   2.001. lauks – loģiska ieraksta garums (Logical Record Length – LEN)

Šajā obligātajā laukā ir fiksēts attiecīgā 2. tipa ieraksta garums un konkrēti norādīts baitu kopskaits, ietverot katru ieraksta lauka zīmi un informācijas nošķīrējus.

4.1.2.   2.002. lauks – attēla raksturotāja zīme (Image Designation Character – IDC)

IDC, kas atrodas šajā obligātajā laukā, ASCII izteiksmē pārstāv IDC, kas ir definēta 1. tipa ieraksta datņu satura laukā (File Content field – CNT) (1.003. lauks).

4.1.3.   2.003. lauks – sistēmas informācija (System Information – SYS)

Šis lauks ir obligāts, un tajā ir četri baiti, kas rāda, kurai INT-I versijai atbilst konkrētais 2. tipa ieraksts.

Pirmie divi baiti norāda uz pamatversijas numuru, nākamie divi – uz mazāk būtisku uzlabojumu numuru. Piemēram, šajā īstenojumā ir izmantota INT-I 4. versija 22. pārskatījumā, un to atveido “0422”.

4.1.4.   2.007. lauks – lietas numurs (Case Number – CNO)

Šis ir numurs, ko vietējais daktiloskopijas birojs ir piešķīris nozieguma vietā savāktajiem latentajiem nospiedumiem. Izmanto šādu formu – CC/numurs (CC/number),

kur “CC” ir interpola valsts kods (Interpol Country Code) no divām burtu vai ciparu zīmēm, bet numurs atbilst attiecīgām vietējām pamatnorādēm, un tajā var būt līdz 32 burtu vai ciparu zīmes.

Šis lauks ļauj sistēmai identificēt latentos nospiedumus, kas ir saistīti ar konkrētu noziegumu.

4.1.5.   2.008. lauks – secības numurs (Sequence Number – SQN)

Tajā ir norādīta visu lietas latento nospiedumu secība. Tajā var būt līdz četras ciparu zīmes. Secība ir latentu nospiedumu attēls vai latentu nospiedumu attēlu sērija, kas sagrupēta uzskaites un/vai meklēšanas vajadzībām. Šī definīcija paredz, ka pat atsevišķiem latentiem nospiedumu attēliem būs jāpiešķir secības numurs.

Šo lauku līdz ar MID (2.009. lauks) var iekļaut, lai identificētu konkrētu latentu attēlu kādas secīgā virknē.

4.1.6.   2.009. lauks – latento nospiedumu identifikators (Latent Identifier – MID)

Ar šo ir konkrēti norādīts konkrēts latents nospiedums kādā secīgā virknē. Vērtība ir viens vai divi burti, un ar burtu “A” apzīmē pirmo latento attēlu, ar “B” – otro, un tā tālāk – līdz robežlielumam “ZZ”. Lauku izmanto analogi latento attēlu secības numuram, par ko ir runāts, aprakstot SQN (2.008. lauks).

4.1.7.   2.010. lauks – noziedznieka atsauces numurs (Criminal Reference Number – CRN)

Šis ir unikāls atsauces numurs, ko attiecīgas valsts aģentūra piešķir indivīdam, kas pirmo reizi ir notiesāts par izdarītu noziegumu. Vienā valstī nevienam indivīdam nekad nav vairāk par vienu CRN, un tas viņam nav kopīgs ne ar vienu citu cilvēku. Vienam un tam pašam cilvēkam gan var būt noziedznieka atsauces numurs vairākās valstīs, un to varēs atšķirt pēc valsts koda.

CRN laukam ir izstrādāta šāda forma – CC/numurs (CC/number),

kur “CC” ir valsts kods (Country Code), kas noteikts saskaņā ar ISO 3166, kurā ir divas burtu vai ciparu zīmes, un numurs atbilst attiecīgas valsts pieprasījuma izdevējas aģentūras pamatnorādēm, un tajā var būt līdz 32 burtu vai ciparu zīmes.

Darbībām saskaņā ar Lēmumu 2008/615/TI šo lauku izmantos attiecīgas valsts pieprasījuma izdevējas aģentūras nozieguma atsauces numuram, kas ir saistīts ar 4. tipa vai 15. tipa ierakstu attēliem.

4.1.8.   2.012. lauks – identifikācijas numurs dažādām vajadzībām (Miscellaneous Identification Number – MN1)

Šajā laukā ir CRN (2.010. lauks), ko pārraida, izmantojot CPS vai PMS darbības – bez iepriekš uzrādīta valsts koda.

4.1.9.   2.013. lauks – identifikācijas numurs dažādām vajadzībām (Miscellaneous Identification Number – MN2)

Šajā laukā ir CNO (2.007. lauks), ko pārraida, izmantojot MPS vai MMS darbības – bez iepriekš uzrādīta valsts koda.

4.1.10.   2.014. lauks – identifikācijas numurs dažādām vajadzībām (Miscellaneous Identification Number – MN3)

Šajā laukā ir SQN (2.008. lauks), ko pārraida, izmantojot MPS vai MMS darbības.

4.1.11.   2.015. lauks – identifikācijas numurs dažādām vajadzībām (Miscellaneous Identification Number – MN4)

Šajā laukā ir MID (2.009. lauks), ko pārraida, izmantojot MPS vai MMS darbības.

4.1.12.   2.063. lauks – papildu informācija (Additional Information – INF)

Ja notiek SRE darbība, atbildot uz PMS pieprasījumu, šajā laukā dod informāciju par pirkstu, kura parametri devuši iespējamu pozitīvu dokumentu atrašanas rezultātu (HIT). Lauka forma ir:

NN, kur NN ir 5. tabulā dotais pirksta novietojuma kods no diviem cipariem.

Citos gadījumos lauku izmantot nav obligāti. Tajā ir līdz 32 burtu vai ciparu zīmes, un tas var dot papildu informāciju par pieprasījumu.

4.1.13.   2.064. lauks – atbildētāju saraksts (Respondents List – RLS)

Šajā laukā ir vismaz divi pakārtoti lauki. Pirmajā pakārtotajā laukā ir aprakstīts veiktā meklējuma tips, izmantojot mnemonisku kodu no trijiem burtiem, kurš norāda uz darbības tipu TOT laukā (1.004. lauks). Otrajā pakārtotajā laukā ir viena zīme. Zīmi “I” lieto, lai norādītu, ka dati ir atrasti (HIT), un zīmi “N” lieto, lai norādītu, ka sakritīgi dati nav atrasti (NOHIT). Trešajā pakārtotajā laukā ir secības identifikators, kas attiecas uz kandidāta rezultātu un kandidātu kopskaitu, ko vienu no otra atdala slīpsvītra. Ja kandidāti ir vairāki, arī atbildes būs vairākas.

Iespējamā datu atrašanas gadījumā (HIT) ceturtā pakārtotā laukā būs rezultāts – līdz sešiem cipariem. Ja datu atrašana (HIT) ir apstiprināta, šā pakārtotā lauka vērtība ir definēta kā “999999”.

Piemērs – “CPS{RS}I{RS}001/001{RS}999999{GS}”.

Ja attālinātā AFIS nedod datus par rezultātiem, attiecīgā punktā būtu jādod rezultāts nulle.

4.1.14.   2.074. lauks – statusa lauks/lauks ar paziņojumu par kļūdu (Status/Error Message – ERM)

Šajā laukā ir paziņojumi par kļūdām, kas radušās darbībās un ko sūtīs atpakaļ pieprasījuma iesniedzējam kā piederīgu pie kļūdainas darbības (Error Transaction).

3. tabula. Paziņojumi par kļūdām

Numeric Code (1-3)	Meaning (5-128)
003	ERROR: UNAUTHORISED ACCESS
101	Mandatory field missing
102	Invalid record type
103	Undefined field
104	Exceed the maximum occurrence
105	Invalid number of subfields
106	Field length too short
107	Field length too long
108	Field is not a number as expected
109	Field number value too small
110	Field number value too big
111	Invalid character
112	Invalid date
115	Invalid item value
116	Invalid type of transaction
117	Invalid record data
201	ERROR: INVALID TCN
501	ERROR: INSUFFICIENT FINGERPRINT QUALITY
502	ERROR: MISSING FINGERPRINTS
503	ERROR: FINGERPRINT SEQUENCE CHECK FAILED
999	ERROR: ANY OTHER ERROR. FOR FURTHER DETAILS CALL DESTINATION AGENCY

Paziņojumi par kļūdām diapazonā no 100 līdz 199:

Paziņojumi par kļūdām ir saistīti ar ANSI/NIST ierakstu apstiprināšanu, un tos definē šādi:

<error_code 1>: IDC <idc_number 1> FIELD <field_id 1> <dynamic text 1> LF

<error_code 2>: IDC <idc_number 2> FIELD <field_id 2> <dynamic text 2>...

kur:

—	“error_code” ir kods, kas ir saistīts tikai ar konkrētu iemeslu (sk. 3. tabulu),

—	“field_id” ir nepareiza ANSI/NIST lauka numurs (piem., 1.001, 2.001, ...) šādā formā – “<record_type>.<field_id>.<sub_field_id>”,

—	dinamisks teksts (dynamic text) ir sīkāks, dinamisks kļūdas apraksts,

—	LF (Line Feed) ir rindas pārnesums, kas atdala kļūdas, ja ir sastapta vairāk nekā viena kļūda,

—	1. tipa ierakstiem ICD ir definēts kā “-1”.

Piemērs:

201: IDC - 1 FIELD 1009 WRONG CONTROL CHARACTER {LF} 115: IDC 0 FIELD 2003 INVALID SYSTEM INFORMATION

Šis lauks ir obligāts kļūdainu darbību gadījumā.

4.1.15.   2.320. lauks – paredzamais kandidātu skaits (Expected Number of Candidates – ENC)

Šajā laukā ir dots lielākais iespējamais kandidātu skaits pārbaudei, ko pieprasījuma iesniedzēja aģentūra var paredzēt. ENC vērtība nevar būt lielāka par 11. tabulā noteiktajām vērtībām.

5.   4. tipa loģiski dati – melnbalti tonāli attēli ar lielu izšķirtspēju

Būtu jāņem vērā, ka 4. tipa ieraksti būtībā ir bināri, nevis ASCII. Tālab katram laukam ierakstā atvēl īpašu vietu, un tas nozīmē, ka visi lauki ir obligāti.

Standarts ļauj ierakstā konkrēti uzrādīt gan attēla lielumu, gan izšķirtspēju. Ir vajadzīgi 4. tipa loģiski ieraksti, lai varētu glabāt daktiloskopijas attēlu datus, ko pārraida ar nominālu pikseļu blīvumu – 500 līdz 520 pikseļu collā. Ieteicamais jaunu izstrādņu koeficients ir paredzēt pikseļu blīvumu – 500 pikseļu collā jeb 19,68 pikseļu milimetrā. 500 pikseļu collā ir blīvums, kas ir paredzēts ar INT-I, izņemot to, ka līdzīgas sistēmas var savā starpā sazināties, neizmantojot ieteicamo koeficientu un izmantojot ieteicamo robežlielumu – 500 līdz 520 pikseļiem collā.

5.1.   4. tipa loģisku datu lauki

5.1.1.   4.001. lauks – loģisku ierakstu garums (Logical Record Length – LEN)

Šajā četru baitu laukā ir fiksēts minētā 4. tipa ieraksta garums un konkrēti norādīts baitu kopskaits, aptverot katru baitu katrā ieraksta laukā.

5.1.2.   4.002. lauks – attēla zīme (Image Designation Character – IDC)

Šis ir datnes galvenē dotā IDC numura binārs atveidojums vienā baitā.

5.1.3.   4.003. lauks – nospieduma tips (Impression Type – IMP)

Nospieduma tips ir viena baita lauks, kas aizņem ieraksta sesto baitu.

4. tabula. Pirkstu nospiedumu tipi

Code	Description
0	Live-scan of plain fingerprint
1	Live-scan of rolled fingerprint
2	Non-live scan impression of plain fingerprint captured from paper
3	Non-live scan impression of rolled fingerprint captured from paper
4	Latent impression captured directly
5	Latent tracing
6	Latent photo
7	Latent lift
8	Swipe
9	Unknown

5.1.4.   4.004. lauks – pirksta novietojums (Finger Position – FGP)

Šis fiksēta garuma 6 baitu lauks aizņem no septītā līdz divpadsmitajam baitam 4. tipa ierakstā. Tajā ir uzrādīti iespējamie pirkstu novietojumi, sākot no baita, kas atrodas vistālāk pa kreisi (ieraksta 7. baits). Zināms vai visticamākais pirksta novietojums ir ņemts no 5. tabulas. Var dot atsauces vēl līdz pat pieciem citiem pirkstiem, ierakstot citu pirkstu novietojumus atlikušos piecos baitos – tādā pašā formā. Ja ir paredzams izmantot mazāk nekā piecu pirkstu novietojumu atsauces, neizmantotos baitus aizpilda ar bināriem “255”. Lai dotu atsauci uz visiem pirkstu novietojumiem, lieto kodu “0” – “nav zināms”.

5. tabula. Pirkstu novietojuma kodi un maksimāli iespējamie lielumi

Finger position	Finger code	Width (mm)	Length (mm)
Unknown	0	40,0	40,0
Right thumb	1	45,0	40,0
Right index finger	2	40,0	40,0
Right middle finger	3	40,0	40,0
Right ring finger	4	40,0	40,0
Right little finger	5	33,0	40,0
Left thumb	6	45,0	40,0
Left index finger	7	40,0	40,0
Left middle finger	8	40,0	40,0
Left ring finger	9	40,0	40,0
Left little finger	10	33,0	40,0
Plain right thumb	11	30,0	55,0
Plain left thumb	12	30,0	55,0
Plain right four fingers	13	70,0	65,0
Plain left four fingers	14	70,0	65,0

Apzīmējot noziegumu vietās atrastus latentus nospiedumus, būtu jāizmanto tikai kodi no “0” līdz “10”.

5.1.5.   4.005. lauks – attēla skenējuma izšķirtspēja (Image Scanning Resolution – ISR)

Šis viena baita lauks 4. tipa ierakstā aizņem 13. baitu. Ja tajā ir “0”, tad attēls ir nolasīts ar ieteicamo skenējuma koeficientu – 19,68 pikseļi milimetrā (500 pikseļu collā). Ja tajā ir “1”, tad attēls ir nolasīts ar citu skenējuma koeficientu, kas ir konkrēti norādīts 1. tipa ierakstā.

5.1.6.   4.006. lauks – horizontālu līniju garums (Horizontal Line Length – HLL)

Šis lauks 4. tipa ierakstā atrodas pie 14. un 15. baita. Tajā ir norādīts katras skenējuma līnijas pikseļu skaits. Pirmais baits būs pats svarīgākais.

5.1.7.   4.007. lauks – vertikālu līniju garums (Vertical Line Length – VLL)

Šā lauka 16. un 17. baitā ir fiksēts attēla skenējuma līniju skaits. Pirmais baits ir pats svarīgākais.

5.1.8.   4.008. lauks – melnbaltu tonālu attēlu saspiešanas algoritms (Gray-scale Compression Algorithm – GCA)

Šajā viena baita laukā norāda melnbaltu tonālu attēlu saspiešanas algoritmu, ko izmanto, lai kodētu attēla datus. Šādā īstenojumā binārs kods “1” norāda, ka ir lietota WSQ saspiešana (7. papildinājums).

5.1.9.   4.009. lauks – attēls

Šajā laukā ir attēla atveidotāju baitu straume. Tās struktūra acīmredzot būs atkarīga no izmantotā saspiešanas algoritma.

6.   9. tipa loģiski dati – papilārlīniju detaļu ieraksts

9. tipa ierakstos ir ASCII teksts, kurā ir aprakstītas papilārlīniju detaļas un saistīta informācija, kas ir kodēta no latenta nospieduma. Latentu nospiedumu meklēšanas darbībās tādiem 9. tipa ierakstiem datnē nav nekādu ierobežojumu, jo katrs no tiem būs citā leņķī – vai cits latents nospiedums.

6.1.   Papilārlīniju detaļu konstatācija

6.1.1.   Papilārlīniju detaļu tipa identifikācija

Šajā standartā ir definēti trīs identifikācijas numuri, ko lieto, lai raksturotu papilārlīniju detaļu tipu. Tie ir uzskaitīti 6. tabulā. Papilārlīniju nobeigumu dēvē par 1. tipu. Bifurkāciju dēvē par 2. tipu. Ja papilārlīniju detaļas nevar skaidri klasificēt kā vienu no abiem iepriekš minētajiem tipiem, to dēvē par “citu (other)”, 0. tipu.

6. tabula. Papilārlīniju detaļu tipi

Type	Description
0	Other
1	Ridge ending
2	Bifurcation

6.1.2.   Papilārlīniju detaļu atrašanās vieta un tips

Lai paraugi būtu saderīgi ar ANSI INCITS 378-2004 standarta 5. iedaļu, atsevišķu papilārlīniju detaļu atrašanās vietas (vietas un novietojuma leņķa) noteikšanai izmanto šādu metodi, kas papildina pašlaik spēkā esošo INCITS 378-2004 standartu.

Papilārlīniju detaļu, t. i., papilārlīnijas gals ir viduspunkts, kurā tieši pirms papilārlīnijas gala sazarojas starplīniju iedobes. Ja trīs starplīniju iedobju atzarlīnijas sašaurina līdz viena pikseļa platai līnijai, krustpunkts ir papilārlīniju detaļu atrašanās vieta. Līdzīgi bifurkāciju papilārlīniju detaļu atrašanās vieta ir punkts, kur sazarojas papilārlīniju viduslīnija. Ja papilārlīniju trīs atzarlīnijas sašaurina līdz viena pikseļa platai līnijai, punkts, kur trīs atzarlīnijas šķērso cita citu, ir papilārlīniju detaļu atrašanās vieta.

Kad visi papilārlīniju gali ir pārvērsti bifurkācijās, visas daktiloskopijas attēla papilārlīniju detaļas parādās kā bifurkācijas. Pikseļu X un Y koordināšu līnijas katru papilārlīniju detaļu triju atzarlīniju krustpunktā var formatēt tieši. Papilārlīniju detaļu virzienu var atvasināt pēc katras līnijas bifurkācijas. Katras līnijas bifurkācijas trīs atzarlīnijas ir jāanalizē, un jānosaka katras atzarlīnijas gals. 6.1.2. attēlā ir rādītas trīs metodes, ko izmanto, lai noteiktu atzarlīniju galu, izmantojot skenējuma izšķirtspēju 500. punkti collā.

Atzarlīniju galu nosaka atkarībā no tā, kas ir pirmais. Pikseļu skaitu nosaka pēc skenējuma ar izšķirtspēju 500. punkti collā. Dažādu skenējumu izšķirtspēja nozīmētu dažādu pikseļu skaitu.

—	Attālums – .064” (32. pikselis),

—	gala līniju atzarlīnijas, kas sākas attālumā no .02” līdz .064” (no 10. līdz 32. pikselim ieskaitot); īsākas atzarlīnijas neņem vērā,

—	konstatēta otra bifurkācija .064” attālumā (pirms 32. pikseļa).

6.1.2. zīmējums

Papilārlīniju detaļu leņķi nosaka, konstruējot trīs iedomātas līnijas no bifurkācijas punkta un velkot tās līdz katras atzarlīnijas galam. Mazāko no trijiem līniju veidotajiem leņķiem sadala uz pusēm, lai rādītu papilārlīniju detaļu virzienu.

6.1.3.   Koordinātu sistēma

Koordinātu sistēma, ko izmanto, lai raksturotu pirkstu nospiedumu papilārlīniju detaļas, ir Dekarta koordinātu sistēma. Papilārlīniju detaļu atrašanās vietu raksturo to x un y koordinātes. Koordinātu sistēmas sākumpunkts ir oriģinālā attēla kreisais augšējais stūris, no kā x virzās pa labi un y virzās lejup. Gan papilārlīniju detaļu x, gan y koordinātes atveido pikseļu vienībās, sākot no sākumpunkta. Būtu jāņem vērā, ka sākumpunkta vieta un mērvienības neatbilst parastajām, ko izmanto 9. tipa definīcijās, kas dotas standartā ANSI/NIST-ITL 1-2000.

6.1.4.   Papilārlīniju detaļu virziens

Leņķus izsaka parastā matemātiskā formā, ar nulli grādu labajā pusē un leņķiem, kas palielinās pretēji pulksteņa rādītāja virzienam. Papilārlīniju galu leņķus fiksē atpakaļvirzienā gar papilārlīnijām un bifurkāciju leņķus – virzienā uz iedobes vidu. Tas ir 180 grādus pretī 9. tipa standartā ANSI/NIST-ITL 1-2000 aprakstītajiem leņķiem.

6.2.   Lauki 9. tipa loģiskiem ierakstiem INCITS-378 formā

Visos 9. tipa ierakstu laukos tekstu raksta ASCII formā. Šajos marķētu lauku ierakstos nav pieļaujami bināri lauki.

6.2.1.   9.001. lauks – loģisku ierakstu garums (Logical record length – LEN)

Šajā obligātajā ASCII laukā ir loģisku ierakstu garums, konkrēti norādot baitu kopskaitu, ietverot katru ieraksta lauka zīmi.

6.2.2.   9.002. lauks – attēla raksturotāja zīme (Image designation character – IDC)

Šo obligāto divu baitu lauku izmanto papilārlīniju detaļu datu identifikācijai un atrašanās vietas norādei. Šajā laukā dotais IDC saskan ar IDC, kas atrodas 1. tipa ieraksta datnes satura laukā.

6.2.3.   9.003. lauks – nospieduma tips (Impression type – IMP)

Šajā obligātajā viena baita laukā ir aprakstīts, kā iegūta daktiloskopijas attēla informācija. Atbilstošā 4. tabulā izvēlētā koda ASCII vērtību ieraksta šajā laukā, lai raksturotu nospieduma tipu.

6.2.4.   9.004. lauks – papilārlīniju detaļu forma (Minutiæ format – FMT)

Šajā laukā ir “U”, kas norāda, ka papilārlīniju detaļas ir formatētas saskaņā ar M1-378. Kaut arī informācija var būt kodēta saskaņā ar standartu M1-378, visiem 9. tipa ieraksta datu laukiem ir jāpaliek ASCII teksta laukiem.

6.2.5.   9.126. lauks – CBEFF informācija

Šajā laukā ir trīs informācijas elementi. Pirmajā informācijas elementā ir vērtība “27” (0x1B). Tā identificē CBEFF formu (CBEFF Format Owner), ko Starptautiskā Biometrijas nozares apvienība (International Biometric Industry Association – IBIA) piešķīrusi INCITS tehniskai komitejai M1 (INCITS Technical Committee M1). Zīme <US> norobežo šo elementu no CBEFF formas tipa (CBEFF Format Type), kam ir piešķirta vērtība“513” (0x0201), lai norādītu, ka šajā ierakstā ir tikai atrašanās vietas un virziena leņķa dati bez kādas paplašinātas datu bloku informācijas (Extended Data Block information). Zīme <US> norobežo šo elementu no CBEFF ražojuma identifikatora (Product Identifier – PID), kas identificē kodēšanas iekārtas nosacīto īpašnieku. Šo vērtību nosaka iekārtas pārdevējs. To var saņemt IBIA tīkla lapā (www.ibia.org), ja tā ir paredzēts.

6.2.6.   9.127. lauks – fiksācijas iekārtu identifikācija

Šajā laukā ir divi informācijas elementi, ko nošķir <US> zīme. Pirmajā ir “APPF”, ja attēla ieguvei lietotā iekārta ir sertificēta kā atbilstoša Federālā izmeklēšanas biroja elektroniskas pirkstu nospiedumu pārsūtīšanas parametru CJIS-RS-0010 (Federal Bureau of Investigation ’ s Electronic Fingerprint Transmission Specification) F papildinājumam (IAFIS Image Quality Specification, January 29, 1999). Ja iekārta tam neatbilst, laukā būs vērtība “NONE”. Otrā informācijas elementā ir fiksācijas iekārtas identifikācija (Capture Equipment ID), fiksācijas iekārtas pārdevēja piešķirts ražojuma numurs. Vērtība “0” rāda, ka fiksācijas iekārtas identifikācija (ID) nav darīta zināma.

6.2.7.   9.128. lauks – horizontālu līniju garums (Horizontal line length – HLL)

Šajā obligātajā ASCII laukā ir vienā horizontālā pārraidītā attēla līnijā esošo pikseļu skaits. Maksimālais pieļaujamais horizontālais lielums ir 65 534 pikseļi.

6.2.8.   9.129. lauks – vertikālo līniju garums (Vertical line length – VLL)

Šajā obligātajā ASCII laukā ir pārraidītā attēla horizontālo līniju skaits. Maksimālais pieļaujamais vertikālais lielums ir 65 534 pikseļi.

6.2.9.   9.130. lauks – mērogi (Scale units – SLC)

Šajā obligātajā ASCII laukā ir norādītas vienības, ko izmanto, lai aprakstītu attēla nolasīšanas frekvenci (pikseļu blīvumu). Cipars “1” šajā laukā rāda pikseļus collā, savukārt “2” rāda pikseļus centimetrā. Cipars “0” šajā laukā rāda, ka mērogs nav uzrādīts. Tādos gadījumos HPS/VPS dalījums dod pikseļu attiecības koeficientu.

6.2.10.   9.131. lauks – horizontāls pikseļu mērogs (Horizontal pixel scale – HPS)

Šajā obligātajā ASCII laukā konkrēti norāda horizontālā virzienā izmantoto pikseļu blīvumu veselos skaitļos, ja SLC ir ar “1” vai “2”. Ja tā nav, tas rāda pikseļu attiecības koeficienta horizontālo komponentu.

6.2.11.   9.132. lauks – vertikāls pikseļu mērogs (Vertical pixel scale – VPS)

Šajā obligātajā ASCII laukā konkrēti norāda vertikālā virzienā izmantoto pikseļu blīvumu veselos skaitļos, ja SLC ir ar “1” vai “2”. Ja tā nav, tas rāda pikseļu attiecības koeficienta vertikālo komponentu.

6.2.12.   9.133. lauks – pirksta attēls

Šajā obligātajā laukā ir ar ieraksta datiem saistītā pirksta attēls. Attēlu kārtas skaitlis sākas ar “0”, un mainās pa vienam līdz “15”.

6.2.13.   9.134. lauks – pirksta novietojums (Finger position – FGP)

Šajā laukā ir kods, kas apzīmē pirksta novietojumu, kādā ir iegūta šā 9. tipa ieraksta informācija. Kodu no 1 līdz 10, ņemtu no 5. tabulas vai attiecīgi 10. plaukstu koda tabulas, izmanto, lai norādītu pirksta vai plaukstas novietojumu.

6.2.14.   9.135. lauks – pirksta kvalitāte

Laukā ir visu pirksta papilārlīniju detaļu datu kvalitāte, un to raksturo skaitlis no 0 līdz 100. Šis skaitlis kopumā raksturo pirksta attēla ieraksta kvalitāti, kā arī rāda iegūtā attēla kvalitāti, iespēju nošķirt papilārlīniju detaļas un veikt visas papildu darbības, kas var iespaidot papilārlīniju detaļu ierakstus.

6.2.15.   9.136. lauks – papilārlīniju detaļu skaits

Šajā obligātajā laukā ir attiecīgajā loģiskajā ierakstā fiksēts papilārlīniju detaļu skaits.

6.2.16.   9.137. lauks – pirkstu papilārlīniju detaļu dati

Šajā obligātajā laukā ir seši informācijas elementi, nošķirti ar <US> zīmi. Tajā ir vairāki pakārtoti lauki, un katrā no tiem ir kādas papilārlīnijas sīkākas detaļas. Papilārlīniju detaļu pakārtoto lauku kopskaitam jāsaskan ar 136. laukā doto skaitu. Pirmais informācijas elements ir papilārlīniju detaļu kārtas numurs, ko raksta kā pirmo “1” un palielina par “1” katrai papildu papilārlīniju detaļai pirksta nospiedumā. Otrais un trešais informācijas elements ir papilārlīniju detaļu “x” un “y” koordinātes pikseļu vienībās. Ceturtais informācijas elements ir papilārlīniju detaļu leņķis, fiksēts divu grādu vienībās. Tā vērtība ir nenegatīva, no 0 līdz 179. Piektais informācijas elements ir papilārlīniju detaļu tips. Vērtību “0” lieto, lai raksturotu “OTHER” tipa papilārlīniju detaļas, vērtība “1” papilārlīniju galiem un vērtība “2” – papilārlīniju bifurkācijām. Sestais informācijas elements raksturo katras papilārlīniju detaļas kvalitāti. Tā vērtība sākas no 1 – sliktākās – līdz 100 – labākajai. Vērtība “0” rāda, ka kvalitātes vērtība nav zināma. Katru pakārtoto lauku nošķir no nākamā ar <RS> nošķīrējzīmi.

6.2.17.   9.138. lauks – papilārlīniju skaita informācija

Šajā laukā ir vairāki pakārtoti lauki, no kuriem katrā ir trīs informācijas elementi. Pirmā pakārtotā lauka pirmais informācijas elements rāda papilārlīniju skaitīšanas metodi. “0” rāda, ka par papilārlīniju skaitīšanas metodi vai par to kārtību ierakstā neizdara nekādus pieņēmumus. “1” rāda, ka dati par visām centra papilārlīniju detaļām, papilārlīniju skaitu ir iegūti līdz tuvākajai blakus esošajai papilārlīniju detaļai četros kvadrantos un visu centra papilārlīniju detaļu papilārlīniju skaits ir apkopots. “2” rāda, ka visām centra papilārlīniju detaļām papilārlīniju skaita dati ir iegūti līdz tuvākajai blakus esošajai papilārlīniju detaļai astoņos oktantos un visu centra papilārlīniju detaļu papilārlīniju skaits ir apkopots. Atlikušajos divos pirmā pakārtotā lauka informācijas elementos ir “0”. Informācijas elementus nošķir ar <US> nošķīrējzīmi. Pārējos pakārtotos laukos tāpat kā pirmajā informācijas elementā būs centra papilārlīniju detaļu kārtas numurs, blakus esošo papilārlīniju detaļu kārtas numurs kā otrs informācijas elements un šķērsotu papilārlīniju skaits kā trešais informācijas elements. Pakārtotos laukus nošķir ar <RS> nošķīrējzīmi.

6.2.18.   9.139. lauks – informācija par centriem

Šajā laukā būs viens pakārtots lauks katram attēlā redzamajam centram. Katrā pakārtotajā laukā ir trīs informācijas elementi. Pirmie divi elementi ir “x” un “y” koordinātes pikseļu vienībās. Trešajā informācijas elementā ir centra leņķis, fiksēts 2 grādu vienībās. Tā vērtība ir nenegatīva, no 0 līdz 179. Vairākus centrus nošķir ar <RS> nošķīrējzīmi.

6.2.19.   9.140. lauks – informācija par deltām

Šajā laukā ir viens pakārtots lauks katrai attēlā redzamajai deltai. Katrā pakārtotajā laukā ir trīs informācijas elementi. Pirmie divi elementi ir “x” un “y” koordinātes pikseļu vienībās. Trešajā informācijas elementā ir deltas leņķis, fiksēts 2 grādu vienībās. Tā vērtība ir nenegatīva, no 0 līdz 179. Vairākus centrus nošķir ar <RS> nošķīrējzīmi.

7.   13. tips – latentu attēlu ieraksti ar maināmu izšķirtspēju

13. tipa marķētu lauku loģiskos ierakstos ir no latentiem attēliem iegūti dati. Minētie attēli ir domāti pārraidīšanai aģentūrām, kas automatizēti iegūs vai ar cilvēku iejaukšanos un apstrādi iegūs vajadzīgo elementu informāciju no attēliem.

Informācija par izmantoto skenējuma izšķirtspēju, attēla lielumu un citiem parametriem, kas vajadzīgi, lai apstrādātu attēlu, ierakstā ir fiksēta kā marķēti lauki.

7. tabula. 13. tipa latenti attēli ar maināmu izšķirtspēju – ierakstu izkārtojums

Ident	Cond. code	Field Number	Field Name	Char type	Field size per occurrence		Occur count		Max byte count
					min.	max.	min	max
LEN	M	13.001	LOGICAL RECORD LENGTH	N	4	8	1	1	15
IDC	M	13.002	IMAGE DESIGNATION CHARACTER	N	2	5	1	1	12
IMP	M	13.003	IMPRESSION TYPE	A	2	2	1	1	9
SRC	M	13.004	SOURCE AGENCY/ORI	AN	6	35	1	1	42
LCD	M	13.005	LATENT CAPTURE DATE	N	9	9	1	1	16
HLL	M	13.006	HORIZONTAL LINE LENGTH	N	4	5	1	1	12
VLL	M	13.007	VERTICAL LINE LENGTH	N	4	5	1	1	12
SLC	M	13.008	SCALE UNITS	N	2	2	1	1	9
HPS	M	13.009	HORIZONTAL PIXEL SCALE	N	2	5	1	1	12
VPS	M	13.010	VERTICAL PIXEL SCALE	N	2	5	1	1	12
CGA	M	13.011	COMPRESSION ALGORITHM	A	5	7	1	1	14
BPX	M	13.012	BITS PER PIXEL	N	2	3	1	1	10
FGP	M	13.013	FINGER POSITION	N	2	3	1	6	25
RSV		13.014 13.019	RESERVED FOR FUTURE DEFINITION	—	—	—	—	—	—
COM	O	13.020	COMMENT	A	2	128	0	1	135
RSV		13.021 13.199	RESERVED FOR FUTURE DEFINITION	—	—	—	—	—	—
UDF	O	13.200 13.998	USER-DEFINED FIELDS	—	—	—	—	—	—
DAT	M	13.999	IMAGE DATA	B	2	—	1	1	—

Simbolu atšifrējums: N = ciparu; A = burtu; AN = ciparu un burtu; B = binārs.

7.1.   13. tipa loģisku datu lauki

Šajos punktos ir aprakstīti dati, kas atrodas katrā 13. tipa loģisku ierakstu laukā.

13. tipa loģiskos ierakstos ierakstu lauki ir numurēti. Pirmajiem diviem ieraksta laukiem noteikti jābūt sakārtotiem, un lauks ar attēla datiem ir ieraksta pēdējais fiziskais lauks. Katram 13. tipa ieraksta laukam 7. tabulā ir uzskaitīts “nosacījumu kods” – obligāts “M” vai fakultatīvs “O”, lauka numurs, lauka nosaukums, zīmes tips, lauka lielums un sastopamības robežlielumi. Izmantojot trīsciparu lauka numuru, lielākais iespējamais baitu skaits laukā ir dots pēdējā ailē. Ja vairāk ciparu lieto lauka numura apzīmēšanai, attiecīgi pieaugs arī lielākais iespējamais baitu skaits. Divos ierakstos “lauka lielums katrā sastopamības gadījumā” ir visas nošķīrējzīmes, kas izmantotas laukā. “Lielākais iespējamais baitu skaits” ietver lauka numuru, informāciju un visas nošķīrējzīmes, arī “GS” zīmi.

7.1.1.   13.001. lauks – loģisku ierakstu garums (Logical record length – LEN)

Šajā obligātajā ASCII laukā ir 13. tipa loģiskā ieraksta baitu kopskaits. 13.001. laukā konkrēti norāda ieraksta garumu, ietverot katru ieraksta lauka zīmi un informācijas nošķīrējus.

7.1.2.   13.002. lauks – attēla raksturotāja zīme (Image designation character – IDC)

Šo obligāto ASCII lauku izmanto, lai identificētu latentā attēla datus ierakstā. Šis IDC atbilst IDC, kas atrodas 1. tipa ieraksta datnes satura (CNT) laukā.

7.1.3.   13.003. lauks – nospieduma tips (Impression type – IMP)

Šis obligātais viena vai divu baitu ASCII lauks rāda, kā iegūta latentā attēla informācija. Šajā laukā ieraksta attiecīgi izvēlētu latento attēlu kodu no 4. tabulas (pirksti) vai 9. tabulas (plaukstas).

7.1.4.   13.004. lauks – attēla ieguvēja aģentūra (Source agency/ORI – SRC)

Šajā obligātajā ASCII laukā ir identificēta pārvalde vai organizācija, kas ieguvusi ierakstā ietverto sejas attēlu. Parastos apstākļos šajā laukā uzrāda izcelsmes aģentūras identifikatoru (Originating Agency Identifier – ORI) – kura aģentūra ir ieguvusi attēlu. Tajā ir divi informācijas elementi šādā formā – CC/aģentūra (CC/agency).

Pirmajā informācijas elementā ir Interpola izstrādātais valsts kods (Country Code), divas burtu vai ciparu zīmes. Otrs elements, aģentūra (agency), ir līdz 32 burtu vai ciparu zīmes garš brīvs teksts, un ar to identificē aģentūru.

7.1.5.   13.005. lauks – latentā attēla fiksācijas datums (Latent capture date – LCD)

Šajā obligātajā ASCII laukā ir datums – kad fiksēts ierakstā dotais latentais attēls. Datumam no astoņiem cipariem ir šāda forma “CCYYMMDD”. Zīmes “CCYY” rāda gadu, kad attēls ir fiksēts, zīmes “MM” rāda mēnešus, un zīmes “DD” rāda mēneša dienas. Piemēram, 20000229 nozīmē 2000. gada 29. februāri. Pilnam datumam ir jābūt likumīgam datumam.

7.1.6.   13.006. lauks – horizontālu līniju garums (Horizontal line length – HLL)

Šajā obligātajā ASCII laukā pikseļu skaits vienā horizontālā pārraidītā attēla līnijā.

7.1.7.   13.007. lauks – vertikālu līniju garums (Vertical line length – VLL)

Šajā obligātajā ASCII laukā ir pārraidītā attēla horizontālo līniju skaits.

7.1.8.   13.008. lauks – mēroga mērvienības (SLC)

Šajā obligātajā ASCII laukā ir norādītas vienības, ko izmanto, lai aprakstītu attēla nolasīšanas frekvenci (pikseļu blīvumu). Cipars “1” šajā laukā rāda pikseļus collā, savukārt “2” rāda pikseļus centimetrā. Cipars “0” šajā laukā nozīmē, ka mērogs nav uzrādīts. Tādos gadījumos HPS/VPS dalījums dod pikseļu attiecības koeficientu.

7.1.9.   13.009. lauks – horizontāls pikseļu mērogs (Horizontal pixel scale – HPS)

Šajā obligātajā ASCII laukā konkrēti norāda horizontālā virzienā izmantoto pikseļu blīvumu veselos skaitļos, ja SLC ir ar “1” vai “2”. Ja tā nav, tas rāda pikseļu attiecības koeficienta horizontālo komponentu.

7.1.10.   13.010. lauks – vertikāls pikseļu mērogs (Vertical pixel scale – VPS)

Šajā obligātajā ASCII laukā konkrēti norāda vertikālā virzienā izmantoto pikseļu blīvumu veselos skaitļos, ja SLC ir ar “1” vai “2”. Ja tā nav, tas rāda pikseļu attiecības koeficienta vertikālo komponentu.

7.1.11.   13.011. lauks – saspiešanas algoritms (Compression algorithm – CGA)

Šajā obligātajā ASCII laukā konkrēti norāda algoritmu, ko lieto, lai saspiestu melnbaltus tonālus attēlus. Saspiešanas kodus sk. 7. papildinājumā.

7.1.12.   13.012. lauks – biti pikselī (Bits per pixel – BPX)

Šajā obligātajā ASCII laukā ir bitu skaits, kas izmantots, lai izveidotu pikseli. Šajā laukā ir cipars “8” normālu melnbaltu tonālu attēlu vērtībām no “0” līdz “255”. Jebkurš ieraksts šajā laukā, lielāks par “8”, raksturo melnbaltu tonālu attēlu pikseli, kam ir palielināta precizitāte.

7.1.13.   13.013. lauks – pirkstu/plaukstu atrašanās vieta (Finger/palm position – FGP)

Šajā obligātajā marķētajā laukā ir viena vai vairākas iespējamas pirkstu vai plaukstu atrašanās vietas, kas var atbilst latentajam attēlam. Decimālciparu koda numuru, kas atbilst zināmam vai visiespējamākam pirksta novietojumam, atrod 5. tabulā – vai visiespējamākajam plaukstas novietojumam – 10. tabulā, un ieraksta kā vienu vai divas zīmes pakārtotā ASCII laukā. Atsauces par papildu pirkstu un/vai plaukstu atrašanās vietām var ierakstīt, izmantojot citu atrašanās vietu kodus kā pakārtotus laukus, ko nošķir ar “RS” nošķīrējzīmi. Kodu “0”, lai apzīmētu “nezināmu pirkstu (Unknown Finger)”, izmanto, lai dotu atsauci par katru pirksta novietojumu no viena līdz desmit. Kodu “20”, lai apzīmētu “nezināmu plaukstu (Unknown Palm)”, izmanto, lai dotu atsauci par katru uzskaitītu plaukstas nospieduma atrašanās vietu.

7.1.14.   13.014–019. lauks – rezervēts nākotnē iespējamām vajadzībām (Reserved for future definition – RSV)

Šie lauki ir atstāti tukši, lai tajos varētu nākotnē ierakstīt šā standarta pārstrādājumus. Neviens no šiem laukiem nav jālieto pašreizējā izstrādes līmenī. Ja kāds no šiem laukiem parādās, tas jāignorē.

7.1.15.   13.020. lauks – piebildes (Comment – COM)

Šajā fakultatīvajā laukā var ierakstīt piebildes vai citu ASCII teksta informāciju par latentā attēla datiem.

7.1.16.   13.021–199. lauks – rezervēts nākotnē iespējamām vajadzībām (Reserved for future definition – RSV)

Šie lauki ir atstāti tukši, lai tajos varētu nākotnē ierakstīt šā standarta pārstrādājumus. Neviens no šiem laukiem nav jālieto pašreizējā izstrādes līmenī. Ja kāds no šiem laukiem parādās, tas jāignorē.

7.1.17.   13.200–998. lauks – lietotāju definēti lauki (User-defined fields – UDF)

Šos laukus var savām vajadzībām piemērot paši lietotāji, un tos lietos nākotnē. To lielumu un saturu definē paši lietotāji saskaņā ar saņēmēju aģentūru. Ja tādi parādās, tajos ir ASCII teksta informācija.

7.1.18.   13.999. lauks – attēla dati (Image data – DAT)

Šajā laukā ir visi fiksētā latentā attēla dati. Tam vienmēr piešķir lauka numuru 999, un tam jābūt pēdējam fiziskam laukam ierakstā. Piemēram, pēc “13.999:” ir doti attēla dati binārā formā.

Katru nesaspiestu melnbaltu tonālu attēlu datu pikseli parasti kvantē par astoņiem bitiem (256 toņu pelēkumu) vienā baitā. Ja ieraksts 13.012. (BPX) laukā ir lielāks vai mazāks par “8”, baitu skaits, kas vajadzīgs vienam pikselim, būs citāds. Ja lieto saspiešanu, pikseļu dati ir saspiesti saskaņā ar GCA laukā norādīto saspiešanas paņēmienu.

7.2.   13. tips – latents attēls ar maināmu izšķirtspēju – beigas

Konsekvences labad tūlīt pēc pēdēja datu baita 13.999. laukā lieto “FS” nošķīrēju, lai nošķirtu to no nākamā loģiskā ieraksta. Šis nošķīrējs ir jāiekļauj 13. tipa ieraksta garuma laukā.

8.   15. tips – plaukstu nospiedumu attēli ar maināmu izšķirtspēju

15. tipa marķētu lauku loģiskos ierakstos ir – un tos lieto apmainoties ar – plaukstu nospiedumu attēlu dati līdz ar fiksētiem un lietotāju definētiem teksta informācijas laukiem, kas atbilst digitalizētiem attēliem. Informācija par lietoto skenējuma izšķirtspēju, attēla lielumu un citiem parametriem vai piebildēm, kas vajadzīgas, lai apstrādātu ierakstus, ierakstā ir fiksēta kā marķēti lauki. Plaukstu nospiedumu attēlus, ko pārraida citām aģentūrām, apstrādās saņēmējas aģentūras, lai iegūtu vajadzīgo informāciju, kas vajadzīga salīdzināšanai.

Attēlu datus iegūst tieši no subjekta, izmantojot daktiloskopijas skenerus, vai arī no plaukstu nospiedumu kartēm vai citiem informācijas nesējiem, uz kā ir subjektu plaukstu nospiedumi.

Jebkura metode, ko izmanto, lai iegūtu plaukstu nospiedumu attēlus, spēj fiksēt katras rokas nospiedumu attēlu kompleksus. Kompleksā ietilpst rakstīšanai savilkta plauksta kā viens skenēts attēls, un visas, izplestas plaukstas laukums no plaukstas locītavas līdz pirkstu galiem – kā viens vai divi skenēti attēli. Ja izmanto divus attēlus, lai atveidotu visu plaukstu, zemākais attēls sākas no plaukstas locītavas un sniedzas līdz starppirkstu joslas augšai (trešā pirksta locītavai), un tajā ietver plaukstas tenāra un hipotenāra apgabalu. Augstākais attēls sākas no starppirkstu joslas apakšas un sniedzas līdz pirkstu galiem. Tas nodrošina pietiekamu pārklāšanos abiem attēliem, kas abi sniedzas tālāk par plaukstas starppirkstu joslu. Salāgojot papilārlīniju struktūru un detaļas, kas atrodas attēlu kopīgajā joslā, eksperts var droši konstatēt, ka abi attēli ir iegūti no vienas plaukstas.

Tā kā darbības ar plaukstu nospiedumiem var izmantot dažādām vajadzībām, tajās var būt viena vai vairākas unikālas attēla joslas, fiksētas no plaukstas vai rokas. Pilnīgā viena cilvēka plaukstas nospiedumu ierakstu kompleksā parasti ietilpst rakstīšanai savilkta katras rokas plauksta un izplestas(-u) plaukstas(-u) attēli. Loģiska attēla ieraksta marķētos laukos var būt tikai viens binārs lauks, viens 15. tipa ieraksts būs vajadzīgs katrai rakstīšanai savilktai plaukstai un viens vai divi 15. tipa ieraksti – katrai izplestai plaukstai. Tādējādi būs vajadzīgi četri līdz seši 15. tipa ieraksti, lai atveidotu subjekta plaukstu nospiedumus vienā parastā plaukstas nospiedumu darbībā.

8.1.   15. tipa loģisku datu lauki

Šajos punktos aprakstīti dati katrā 15. tipa loģisku ierakstu laukā.

15. tipa loģiskos ierakstus veic numurētos laukos. Ir prasība, lai pirmie divi ieraksta lauki būtu sakārtoti, un lauks ar attēla datiem ir ieraksta pēdējais fiziskais lauks. Katram 15. tipa ierakstu laukam 8. tabulā ir dots “nosacījumu kods” – obligāts “M” vai fakultatīvs “O”, lauka numurs, lauka nosaukums, zīmes tips, lauka lielums un sastopamības robežlielumi. Izmantojot trīsciparu lauka numuru, lielākais iespējamais lauka baitu skaits ir dots pēdējā ailē. Jo vairāk ciparu ir izmantots lauka numurā, jo vairāk palielinās arī lielākais iespējamais baitu skaits. Divos ierakstos “lauka lielums katrā konkrētā gadījumā” ir ietverti visi zīmju nošķīrēji, kas laukā ir izmantoti. “Lielākais iespējamais baitu skaits” ietver lauka numuru, informāciju un visus zīmju nošķīrējus, arī “GS” zīmi.

8.1.1.   15.001. lauks – loģiskā ieraksta garums (Logical record length – LEN)

Šajā obligātajā ASCII laukā ir 15. tipa loģiska ieraksta baitu kopskaits. 15.001. laukā ir dots ieraksta garums, ietverot katru ieraksta lauka zīmi visos laukos un informācijas nošķīrējus.

8.1.2.   15.002. lauks – attēla raksturotāja zīme (Image designation character – IDC)

Šo obligāto ASCII lauku izmanto, lai identificētu ieraksta plaukstas nospieduma attēlu. Šis IDC atbilst IDC, kas atrodas 1. tipa ieraksta datnes satura (CNT) laukā.

8.1.3.   15.003. lauks – nospieduma tips (Impression type – IMP)

Šajā obligātā viena baita ASCII laukā norāda, kā iegūta plaukstas nospieduma attēla informācija. Šajā laukā ieraksta attiecīgus kodus no 9. tabulas.

8.1.4.   15.004. lauks – aģentūra, kas ir ieguvusi attēlu (Source agency/ORI – SRC)

Šajā obligātajā ASCII laukā ir identificēta pārvalde vai organizācija, kas ieguvusi ierakstā doto sejas attēlu. Parastos apstākļos šajā laukā uzrāda izcelsmes aģentūras identifikatoru (Originating Agency Identifier – ORI) – kura aģentūra ir ieguvusi attēlu. Tajā ir divi informācijas elementi šādā formā – CC/aģentūra (CC/agency).

Pirmajā informācijas elementā ir Interpola izstrādātais valsts kods (Country Code), divas burtu vai ciparu zīmes. Otrs elements, aģentūra (agency), ir līdz 32 burtu vai ciparu zīmes garš brīvs teksts, un ar to identificē aģentūru.

8.1.5.   15.005. lauks – plaukstas nospieduma fiksācijas datums (Palmprint capture date – PCD)

Šajā obligātajā ASCII laukā ir datums, kad ir fiksēts plaukstas nospieduma attēls. Datumam no astoņiem cipariem ir šāda forma “CCYYMMDD”. Zīmes “CCYY” rāda gadu, kad fiksēts attēls, zīmes “MM” rāda mēnešus, un zīmes “DD” rāda mēneša dienas. Piemēram, 20000229 nozīmē 2000. gada 29. februāri. Pilnam datumam ir jābūt likumīgam datumam.

8.1.6.   15.006. lauks – horizontālu līniju garums (Horizontal line length – HLL)

Šajā obligātajā ASCII laukā ir vienā horizontālā pārraidītā attēla līnijā esošo pikseļu skaits.

8.1.7.   15.007. lauks – vertikālu līniju garums (Vertical line length – VLL)

Šajā obligātajā ASCII laukā ir pārraidītā attēla horizontālo līniju skaits.

8.1.8.   15.008. lauks – mēroga mērvienības (Scale units – SLC)

Šajā obligātajā ASCII laukā ir norādītas vienības, ko izmanto, lai aprakstītu attēla nolasīšanas frekvenci (pikseļu blīvumu). Cipars “1” šajā laukā rāda pikseļus collā, savukārt “2” rāda pikseļus centimetrā. Cipars “0” šajā laukā nozīmē, ka mērogs nav uzrādīts. Tādos gadījumos HPS/VPS dalījums dod pikseļu attiecības koeficientu.

8.1.9.   15.009. lauks – horizontāls pikseļu mērogs (Horizontal pixel scale – HPS)

Šajā obligātajā ASCII laukā konkrēti norāda horizontālā virzienā izmantoto pikseļu blīvumu veselos skaitļos, ja SLC ir ar “1” vai “2”. Ja tā nav, tas rāda pikseļu attiecības koeficienta horizontālo komponentu.

8.1.10.   15.010. lauks – vertikāls pikseļu mērogs (Vertical pixel scale – VPS)

Šajā obligātajā ASCII laukā konkrēti norāda vertikālā virzienā izmantoto pikseļu blīvumu veselos skaitļos, ja SLC ir ar “1” vai “2”. Ja tā nav, tas rāda pikseļu attiecības koeficienta vertikālo komponentu.

8. tabula. 15. tipa plaukstu nospiedumu attēli ar maināmu izšķirtspēju – ierakstu izkārtojums

Ident	Cond. code	Field Number	Field Name	Char type	Field size per occurrence		Occur count		Max byte count
					min.	max.	min	max
LEN	M	15.001	LOGICAL RECORD LENGTH	N	4	8	1	1	15
IDC	M	15.002	IMAGE DESIGNATION CHARACTER	N	2	5	1	1	12
IMP	M	15.003	IMPRESSION TYPE	N	2	2	1	1	9
SRC	M	15.004	SOURCE AGENCY/ORI	AN	6	35	1	1	42
PCD	M	15.005	PALMPRINT CAPTURE DATE	N	9	9	1	1	16
HLL	M	15.006	HORIZONTAL LINE LENGTH	N	4	5	1	1	12
VLL	M	15.007	VERTICAL LINE LENGTH	N	4	5	1	1	12
SLC	M	15.008	SCALE UNITS	N	2	2	1	1	9
HPS	M	15.009	HORIZONTAL PIXEL SCALE	N	2	5	1	1	12
VPS	M	15.010	VERTICAL PIXEL SCALE	N	2	5	1	1	12
CGA	M	15.011	COMPRESSION ALGORITHM	AN	5	7	1	1	14
BPX	M	15.012	BITS PER PIXEL	N	2	3	1	1	10
PLP	M	15.013	PALMPRINT POSITION	N	2	3	1	1	10
RSV		15.014 15.019	RESERVED FOR FUTURE INCLUSION	—	—	—	—	—	—
COM	O	15.020	COMMENT	AN	2	128	0	1	128
RSV		15.021 15.199	RESERVED FOR FUTURE INCLUSION	—	—	—	—	—	—
UDF	O	15.200 15.998	USER-DEFINED FIELDS	—	—	—	—	—	—
DAT	M	15.999	IMAGE DATA	B	2	—	1	1	—

9. tabula. Plaukstu nospiedumu tipi

Description	Code
Live-scan palm	10
Nonlive-scan palm	11
Latent palm impression	12
Latent palm tracing	13
Latent palm photo	14
Latent palm lift	15

8.1.11.   15.011. lauks – saspiešanas algoritms (Compression algorithm – CGA)

Šajā obligātajā ASCII laukā konkrēti norāda algoritmu, ko lieto, lai saspiestu melnbaltus tonālus attēlus. Ieraksts “NONE” šajā laukā norāda, ka dati ierakstā nav saspiesti. Attēliem, ko paredzēts saspiest, šajā laukā ir dota ieteicamā desmit pirkstu nospiedumu attēlu saspiešanas metode. Izmantojami saspiešanas kodi ir definēti 7. papildinājumā.

8.1.12.   15.012. lauks – biti pikselī (Bits per pixel – BPX)

Šajā obligātajā ASCII laukā ir bitu skaits, kas izmantots, lai izveidotu pikseli. Šajā laukā ir cipars “8” normālu melnbaltu tonālu attēlu vērtībām no “0” līdz “255”. Jebkurš ieraksts šajā laukā, lielāks par “8”, raksturo melnbaltu tonālu attēlu pikseli, kam ir palielināta precizitāte.

10. tabula. Plaukstu kodi, laukumi un lielumi

Palm Position	Palm code	Image area (mm2)	Width (mm)	Height (mm)
Unknown Palm	20	28 387	139,7	203,2
Right Full Palm	21	28 387	139,7	203,2
Right Writer s Palm	22	5 645	44,5	127,0
Left Full Palm	23	28 387	139,7	203,2
Left Writer s Palm	24	5 645	44,5	127,0
Right Lower Palm	25	19 516	139,7	139,7
Right Upper Palm	26	19 516	139,7	139,7
Left Lower Palm	27	19 516	139,7	139,7
Left Upper Palm	28	19 516	139,7	139,7
Right Other	29	28 387	139,7	203,2
Left Other	30	28 387	139,7	203,2

8.1.13.   15.013. lauks – plaukstas nospieduma vieta (Palmprint position – PLP)

Šajā obligātajā marķētajā laukā ir plaukstas nospieduma vieta, kas atbilst plaukstas nospieduma attēlam. Decimālciparu koda numuru, kas atbilst zināmai vai visiespējamākai plaukstas nospieduma vietai ņem no 10. tabulas un ieraksta kā pakārtotu ASCII lauku. 10. tabulā arī ir uzskaitīti lielākie iespējamie katra iespējamā plaukstas novietojuma nospieduma laukumi un izmēri.

8.1.14.   15.014–019. lauks – rezervēts turpmākām vajadzībām (Reserved for future definition – RSV)

Šie lauki ir atstāti tukši, lai tajos varētu nākotnē ierakstīt šā standarta pārstrādājumus. Neviens no šiem laukiem nav jālieto pašreizējā izstrādes līmenī. Ja kāds no šiem laukiem parādās, tas jāignorē.

8.1.15.   15.020. lauks – piebildes (Comment – COM)

Šo fakultatīvo lauku var izmantot piebildēm vai citai ASCII teksta informācijai par plaukstas nospieduma attēla datiem.

8.1.16.   15.021–199. lauks – rezervēts turpmākām vajadzībām (Reserved for future definition – RSV)

Šie lauki ir atstāti tukši, lai tajos varētu nākotnē ierakstīt šā standarta pārstrādājumus. Neviens no šiem laukiem nav jālieto pašreizējā izstrādes līmenī. Ja kāds no šiem laukiem parādās, tas jāignorē.

8.1.17.   15.200–998. lauks – lietotāju definēti lauki (User-defined fields – UDF)

Šos laukus var savām vajadzībām piemērot paši lietotāji, un tos lietos nākotnē. To lielumu un saturu definē paši lietotāji saskaņā ar saņēmēju aģentūru. Ja tādi parādās, tajos ir ASCII teksta informācija.

8.1.18.   15.999. lauks – attēlu dati (Image data – DAT)

Šajā laukā ir visi fiksēta plaukstas nospieduma attēla dati. Tam vienmēr piešķir lauka numuru 999, un tam jābūt pēdējam fiziskam laukam ierakstā. Piemēram, pēc “15.999:” ir doti attēla dati binārā formā. Katru nesaspiestu melnbaltu tonālu attēlu datu pikseli parasti kvantē par astoņiem bitiem (256 toņu pelēkumu) vienā baitā. Ja ieraksts BPX laukā 15.012 ir lielāks vai mazāks par 8, baitu skaits, kas vajadzīgs, lai fiksētu pikseli, būs citāds. Ja izmanto saspiešanu, pikseļu datus saspiež saskaņā ar CGA laukā norādīto saspiešanas paņēmienu.

8.2.   15. tips – plaukstu nospiedumu attēli ar maināmu izšķirtspēju – beigas

Konsekvences labad tūlīt pēc pēdējā datu baita 15.999. laukā lieto nošķīrēju “FS”, lai to nošķirtu no nākamā loģiskā ieraksta. Tāds nošķīrējs ir jāiekļauj 15. tipa lauka garuma ierakstā.

8.3.   Papildu 15. tipa plaukstu nospiedumu attēlu ieraksti ar maināmu izšķirtspēju

Datnē var iekļaut papildu 15. tipa ierakstus. Katram papildu plaukstas nospieduma attēlam ir vajadzīgs pilnīgs 15. tipa loģisks ieraksts līdz ar “FS” nošķīrēju.

11. tabula. Lielākais iespējamais kandidātu skaits, ko pieņem pārbaudei vienā datu pārsūtīšanas reizē

Type of AFIS Search	TP/TP	LT/TP	LP/PP	TP/UL	LT/UL	PP/ULP	LP/ULP
Maximum Number of Candidates	1	10	5	5	5	5	5

Meklējumu tipi:

TP/TP (ten-print against ten-print): desmit pirkstu nospiedumu salīdzināšana ar desmit pirkstu nospiedumiem

LT/TP (fingerprint latent against ten-print): latentu pirkstu nospiedumu salīdzināšana ar desmit pirkstu nospiedumiem

LP/PP (palmprint latent against palmprint): latentu plaukstu nospiedumu salīdzināšana ar plaukstu nospiedumiem

TP/UL (ten-print against unsolved fingerprint latent): desmit pirkstu nospiedumu salīdzināšana ar neatrisinātiem latentiem pirkstu nospiedumiem

LT/UL (fingerprint latent against unsolved fingerprint latent): latentu pirkstu nospiedumu salīdzināšana ar neatrisinātiem latentiem pirkstu nospiedumiem

PP/ULP (palmprint against unsolved palmprint latent): plaukstu nospiedumu salīdzināšana ar neatrisinātiem latentiem plaukstu nospiedumiem

LP/ULP (palmprint latent against unsolved palmprint latent): latentu plaukstu nospiedumu salīdzināšana ar neatrisinātiem latentiem plaukstu nospiedumiem

9.   2. nodaļas papildinājumi (daktiloskopijas datu apmaiņa)

9.1.   1. papildinājums – ASCII nošķīrēji kodi

ASCII	Position (2)	Description
LF	1/10	Separates error codes in field 2.074
FS	1/12	Separates logical records of a file
GS	1/13	Separates fields of a logical record
RS	1/14	Separates the subfields of a record field
US	1/15	Separates individual information items of the field or subfield

9.2.   2. papildinājums – Burtu vai ciparu pārbaudes zīmju aprēķini

TCN un TCR aprēķiniem (1.09. un 1.10. lauks):

Skaitli, kas atbilst pārbaudes zīmei, ģenerē, izmantojot šādu formulu:

(YY * 108 + SSSSSSSS) modulis 23

Kur YY un SSSSSSSS attiecīgi ir gada divu pēdējo ciparu skaitliskās vērtības un sērijas numurs.

Pārbaudes zīmi ģenerē no šeit turpmāk dotās salīdzinājumu tabulas.

CRO aprēķiniem (2.010. lauks)

Skaitli, kas atbilst pārbaudes zīmei, ģenerē, izmantojot šādu formulu:

(YY * 106 + NNNNNN) modulis 23

Kur YY un NNNNNN attiecīgi ir gada divu pēdējo ciparu skaitliskās vērtības un sērijas numurs.

Pārbaudes zīmi ģenerē no šeit turpmāk dotās salīdzinājumu tabulas.

Pārbaudes zīmju tabula

1-A	9-J	17-T
2-B	10-K	18-U
3-C	11-L	19-V
4-D	12-M	20-W
5-E	13-N	21-X
6-F	14-P	22-Y
7-G	15-Q	0-Z
8-H	16-R

9.3.   3. papildinājums – Zīmju kodi

7 bitu ANSI kods savstarpējai informācijas apmaiņai

ASCII Character Set
+	0	1	2	3	4	5	6	7	8	9
30				!	”	#	$	%	&	'
40	(	)	*	+	,	-	.	/	0	1
50	2	3	4	5	6	7	8	9	:	;
60	<	=	>	?	@	A	B	C	D	E
70	F	G	H	I	J	K	L	M	N	O
80	P	Q	R	S	T	U	V	W	X	Y
90	Z	[	\	]	^	_	`	a	b	c
100	d	e	f	g	h	i	j	k	l	m
110	n	o	p	q	r	s	t	u	v	w
120	x	y	z	{	|	}	~

9.4.   4. papildinājums – Darbību kopsavilkums

1. tipa ieraksti (obligāti)

Identifier	Field Number	Field Name	CPS/PMS	SRE	ERR
LEN	1.001	Logical Record Length	M	M	M
VER	1.002	Version Number	M	M	M
CNT	1.003	File Content	M	M	M
TOT	1.004	Type of Transaction	M	M	M
DAT	1.005	Date	M	M	M
PRY	1.006	Priority	M	M	M
DAI	1.007	Destination Agency	M	M	M
ORI	1.008	Originating Agency	M	M	M
TCN	1.009	Transaction Control Number	M	M	M
TCR	1.010	Transaction Control Reference	C	M	M
NSR	1.011	Native Scanning Resolution	M	M	M
NTR	1.012	Nominal Transmitting Resolution	M	M	M
DOM	1.013	Domain name	M	M	M
GMT	1.014	Greenwich mean time	M	M	M

Nosacījumu ailē:

O = fakultatīvi (optional); M = obligāti (mandatory); C = ar nosacījumu (conditional), ka darbība ir atbilde attēla ieguvējai aģentūrai.

2. tipa ieraksti (obligāti)

Identifier	Field Number	Field Name	CPS/PMS	MPS/MMS	SRE	ERR
LEN	2.001	Logical Record Length	M	M	M	M
IDC	2.002	Image Designation Character	M	M	M	M
SYS	2.003	System Information	M	M	M	M
CNO	2.007	Case Number	—	M	C	—
SQN	2.008	Sequence Number	—	C	C	—
MID	2.009	Latent Identifier	—	C	C	—
CRN	2.010	Criminal Reference Number	M	—	C	—
MN1	2.012	Miscellaneous Identification Number	—	—	C	C
MN2	2.013	Miscellaneous Identification Number	—	—	C	C
MN3	2.014	Miscellaneous Identification Number	—	—	C	C
MN4	2.015	Miscellaneous Identification Number	—	—	C	C
INF	2.063	Additional Information	O	O	O	O
RLS	2.064	Respondents List	—	—	M	—
ERM	2.074	Status/Error Message Field	—	—	—	M
ENC	2.320	Expected Number of Candidates	M	M	—	—

Nosacījumu ailē:

O = fakultatīvi (optional); M = obligāti (mandatory); C = ar nosacījumu (conditional), ka dati ir pieejami,

*

=

ja datu pārraide saskan ar attiecīgās valsts tiesībām (uz ko neattiecas Lēmums 2008/615/TI).

9.5.   5. papildinājums – 1. tipa ierakstu definīcijas

Identifier	Condition	Field Number	Field Name	Character Type	Example Data
LEN	M	1.001	Logical Record Length	N	1.001:230{GS}
VER	M	1.002	Version Number	N	1.002:0300{GS}
CNT	M	1.003	File Content	N	1.003:1{US}15{RS}2{US}00{RS}4{US}01{RS}4{US}02{RS}4{US}03{RS}4{US}04{RS}4{US}05{RS}4{US}06{RS}4{US}07{RS}4{US}08{RS}4{US}09{RS}4{US}10{RS}4{US}11{RS}4{US}12{RS}4{US}13{RS}4{US}14{GS}
TOT	M	1.004	Type of Transaction	A	1.004:CPS{GS}
DAT	M	1.005	Date	N	1.005:20050101{GS}
PRY	M	1.006	Priority	N	1.006:4{GS}
DAI	M	1.007	Destination Agency	1*	1.007:DE/BKA{GS}
ORI	M	1.008	Originating Agency	1*	1.008:NL/NAFIS{GS}
TCN	M	1.009	Transaction Control Number	AN	1.009:0200000004F{GS}
TCR	C	1.010	Transaction Control Reference	AN	1.010:0200000004F{GS}
NSR	M	1.011	Native Scanning Resolution	AN	1.011:19.68{GS}
NTR	M	1.012	Nominal Transmitting Resolution	AN	1.012:19.68{GS}
DOM	M	1.013	Domain Name	AN	1.013: INT-I{US}4.22{GS}
GMT	M	1.014	Greenwich Mean Time	AN	1.014:20050101125959Z

Nosacījumu ailē: O = fakultatīvi (optional); M = obligāti (mandatory); C = ar nosacījumiem (conditional).

Zīmju tipa ailē: A = burtu; N = ciparu; B = bināri.

1* pieļaujamās aģentūras nosaukuma zīmes ir [“0..9”, “A..Z”, “a..z”, “_”, ”.”, ““, “-”].

9.6.   6. papildinājums – 2. tipa ierakstu definīcijas

A.6.1. tabula. CPS un PMS darbības

Identifier	Condition	Field Number	Field Name	Character Type	Example Data
LEN	M	2.001	Logical Record Length	N	2.001:909{GS}
IDC	M	2.002	Image Designation Character	N	2.002:00{GS}
SYS	M	2.003	System Information	N	2.003:0422{GS}
CRN	M	2.010	Criminal Reference Number	AN	2.010:DE/E999999999{GS}
INF	O	2.063	Additional Information	1*	2.063:Additional Information 123{GS}
ENC	M	2.320	Expected Number of Candidates	N	2.320:1{GS}

A.6.2. tabula. SRE darbības

Identifier	Condition	Field Number	Field Name	Character Type	Example Data
LEN	M	2.001	Logical Record Length	N	2.001:909{GS}
IDC	M	2.002	Image Designation Character	N	2.002:00{GS}
SYS	M	2.003	System Information	N	2.003:0422{GS}
CRN	C	2.010	Criminal Reference Number	AN	2.010:NL/2222222222{GS}
MN1	C	2.012	Miscellaneous Identification Number	AN	2.012:E999999999{GS}
MN2	C	2.013	Miscellaneous Identification Number	AN	2.013:E999999999{GS}
MN3	C	2.014	Miscellaneous Identification Number	N	2.014:0001{GS}
MN4	C	2.015	Miscellaneous Identification Number	A	2.015:A{GS}
INF	O	2.063	Additional Information	1*	2.063:Additional Information 123{GS}
RLS	M	2.064	Respondents List	AN	2.064:CPS{RS}I{RS}001/001{RS}999999{GS}

A.6.3. tabula. ERR darbības

Identifier	Condition	Field Number	Field Name	Character Type	Example Data
LEN	M	2.001	Logical Record Length	N	2.001:909{GS}
IDC	M	2.002	Image Designation Character	N	2.002:00{GS}
SYS	M	2.003	System Information	N	2.003:0422{GS}
MN1	M	2.012	Miscellaneous Identification Number	AN	2.012:E999999999{GS}
MN2	C	2.013	Miscellaneous Identification Number	AN	2.013:E999999999{GS}
MN3	C	2.014	Miscellaneous Identification Number	N	2.014:0001{GS}
MN4	C	2.015	Miscellaneous Identification Number	A	2.015:A{GS}
INF	O	2.063	Additional Information	1*	2.063:Additional Information 123{GS}
ERM	M	2.074	Status/Error Message Field	AN	2.074: 201: IDC - 1 FIELD 1009 WRONG CONTROL CHARACTER {LF} 115: IDC 0 FIELD 2.003 INVALID SYSTEM INFORMATION {GS}

A.6.4. tabula. MPS un MMS darbības

Identifier	Condition	Field Number	Field Name	Character Type	Example Data
LEN	M	2.001	Logical Record Length	N	2.001:909{GS}
IDC	M	2.002	Image Designation Character	N	2.002:00{GS}
SYS	M	2.003	System Information	N	2.003:0422{GS}
CNO	M	2.007	Case Number	AN	2.007:E999999999{GS}
SQN	C	2.008	Sequence Number	N	2.008:0001{GS}
MID	C	2.009	Latent Identifier	A	2.009:A{GS}
INF	O	2.063	Additional Information	1*	2.063:Additional Information 123{GS}
ENC	M	2.320	Expected Number of Candidates	N	2.320:1{GS}

Nosacījumu ailē: O = fakultatīvi (optional); M = obligāti (mandatory); C = ar nosacījumiem (conditional).

Zīmju tipa ailē: A = burtu; N = ciparu; B = bināri.

1* pieļaujamās zīmes ir [“0..9”, “A..Z”, “a..z”, “_”,“.”, ““, “-”].

9.7.   7. papildinājums – Melnbaltu tonālu attēlu saspiešanas kodi

Saspiešanas kodi

Compression	Value	Remarks
Wavelet Scalar Quantization Grayscale Fingerprint Image Compression Specification IAFIS-IC-0010(V3), dated December 19, 1997	WSQ	Algorithm to be used for the compression of grayscale images in Type-4, Type-7 and Type-13 to Type-15 records. Shall not be used for resolutions > 500 dpi.
JPEG 2000 [ISO 15444/ITU T.800]	J2K	To be used for lossy and losslessly compression of grayscale images in Type-13 to Type-15 records. Strongly recommended for resolutions > 500 dpi

9.8.   8. papildinājums – Sūtījumu parametri

Lai uzlabotu sūtījumu saņēmēju iekšējo darba plūsmu, PRUEM darbībās ir jāieraksta tās dalībvalsts kods (country code – CC), kura ir sūtījusi ziņu, un darbības tips (TOT, 1.004. lauks).

Forma – CC/darbības tips

Piemēram, “DE/CPS”.

Sūtījuma satura lauks var būt tukšs.

3. NODAĻA. Transportlīdzekļu reģistrācijas datu apmaiņa

1.   Kopējs datu kopums automatizētai transportlīdzekļu reģistrācijas datu meklēšanai

1.1.   Definīcijas

Lēmuma 16. panta 4. punktā izklāstīto obligāto un fakultatīvo datu elementu definīcijas ir šādas:

Obligāts (M – mandatory):

Šie datu elementi ir jādara zināmi, ja šāda informācija ir pieejama dalībvalsts reģistrā. Tādējādi ir obligāti jāapmainās ar informāciju, ja tāda ir pieejama.

Fakultatīvs (O – optional):

Šos datu elementus var darīt zināmus, ja šāda informācija ir pieejama dalībvalsts reģistrā. Tādējādi nav obligāti apmainīties ar informāciju, pat ja tāda ir pieejama.

Katram datu kopuma elementam dod norādi (Y), ja šis elements ir īpaši apzināts kā tāds, kas ir nozīmīgs saistībā ar Lēmumu 2008/615/TI.

1.2.   Transportlīdzekļa īpašnieka vai turētāja meklēšana

1.2.1.   Meklēšanas parametri

Ir divi dažādi paņēmieni, kā veikt nākamajā punktā minētās informācijas meklēšanu:

—	izmantojot šasijas numuru (VIN), atsauces datumu un laiku (fakultatīvs),

—	izmantojot numura zīmi reģistrācijas numurā, šasijas numuru (VIN) (fakultatīvs), atsauces datumu un laiku (fakultatīvs).

Izmantojot šos meklēšanas kritērijus, var atrast informāciju par vienu vai dažkārt vairākiem transportlīdzekļiem. Ja ir jāsniedz informācija tikai par vienu transportlīdzekli, tad visus datus nosūta vienā atbildē. Ja ir atrasts vairāk nekā viens transportlīdzeklis, pieprasījuma saņēmēja dalībvalsts pati var izlemt, kurus datus nosūtīt; vai būtu jānosūta visi dati vai tikai dati, kas dotu iespēju sīkāk ierobežot meklēšanu (piemēram, jo ņem vērā personas datu aizsardzību vai efektivitātes apsvērumus).

1.2.2.1. punktā ir uzskaitīti dati, kas vajadzīgi, lai sīkāk ierobežotu meklēšanas kritērijus. 1.2.2.2. punktā ir aprakstīts viss informācijas datu kopums.

Ja meklēšanu veic, izmantojot šasijas numuru, atsauces datumu un laiku, to var veikt vienā vai visās dalībvalstīs, kas ir pieslēgušās sistēmai.

Ja meklēšanu veic, izmantojot apliecības numuru, atsauces datumu un laiku, to var veikt vienā konkrētā dalībvalstī.

Parasti, lai veiktu meklēšanu, izmanto faktisku datumu un laiku, tomēr to ir iespējams veikt izmantojot agrāku atsauces datumu un laiku. Ja meklēšanu veic, izmantojot agrāku atsauces datumu un laiku un attiecīgās dalībvalsts reģistrā šī senākā informācija nav pieejama, jo šāda informācija nav reģistrēta, faktisko informāciju var nosūtīt atpakaļ ar norādi, ka tā ir faktiska informācija.

1.2.2.   Datu kopa

1.2.2.1.

Sīkākai meklēšanas kritēriju ierobežošanai nosūtāmi dati Item M/O (3) Remarks Prüm Y/N (4) Data relating to vehicles       Licence number M   Y Chassis number/VIN M   Y Country of registration M   Y Make M (D.1) (5) e.g. Ford, Opel, Renault etc. Y Commercial type of the vehicle M (D.3) e.g. Focus, Astra, Megane Y EU Category Code M J) mopeds, motorbikes, cars etc. Y

1.2.2.2.

Pilnīgs datu kopums Item M/O (6) Remarks Prüm Y/N Data relating to holders of the vehicle   (C.1) (7) The data refer to the holder of the specific registration certificate.   Registration holders’ (company) name M (C.1.1.) separate fields will be used for surname, infixes, titles etc., and the name in printable format will be communicated Y First name M (C.1.2) separate fields for first name(s) and initials will be used, and the name in printable format will be communicated Y Address M (C.1.3) separate fields will be used for Street, House number and Annex, Zip code, Place of residence, Country of residence etc., and the Address in printable format will be communicated Y Gender M Male, female Y Date of birth M   Y Legal entity M individual, association, company, firm etc. Y Place of Birth O   Y ID Number O An identifier that uniquely identifies the person or the company. N Type of ID Number O The type of ID Number (e.g. passport number). N Start date holdership O Start date of the holdership of the car. This date will often be the same as printed under (I) on the registration certificate of the vehicle. N End date holdership O End data of the holdership of the car. N Type of holder O If there is no owner of the vehicle (C.2) the reference to the fact that the holder of the registration certificate: — is the vehicle owner — is not the vehicle owner — is not identified by the registration certificate as being the vehicle owner N Data relating to owners of the vehicle   (C.2)   Owners’ (company) name M (C.2.1) Y First name M (C.2.2) Y Address M (C.2.3) Y Gender M male, female Y Date of birth M   Y Legal entity M individual, association, company, firm etc. Y Place of Birth O   Y ID Number O An identifier that uniquely identifies the person or the company. N Type of ID Number O The type of ID Number (e.g. passport number). N Start date ownership O Start date of the ownership of the car. N End date ownership O End data of the ownership of the car. N Data relating to vehicles       Licence number M   Y Chassis number/VIN M   Y Country of registration M   Y Make M (D.1) e.g. Ford, Opel, Renault etc. Y Commercial type of the vehicle M (D.3) e.g. Focus, Astra, Megane Y Nature of the vehicle/EU Category Code M (J) mopeds, motorbikes, cars etc. Y Date of first registration M (B) date of first registration of the vehicle somewhere in the world Y Start date (actual) registration M Date of the registration to which the specific certificate of the vehicle refers Y End date registration M (I) End data of the registration to which the specific certificate of the vehicle refers. It is possible this date indicates the period of validity as printed on the document if not unlimited (document abbreviation = H). Y Status M scrapped, stolen, exported etc. Y Start date status M   Y End date status O   N kW O (P.2) Y Capacity O (P.1) Y Type of licence number O Regular, transito etc. Y Vehicle document id 1 O The first unique document ID as printed on the vehicle document Y Vehicle document id 2 (8) O A second document ID as printed on the vehicle document. Y Data relating to insurances       Insurance company name O   Y Begin date insurance O   Y End date insurance O   Y Address O   Y Insurance number O   Y ID Number O An identifier that uniquely identifies the company. N Type of ID Number O The type of ID Number (e.g. number of the Chamber of Commerce) N

2.   Datu drošība

2.1.   Pārskats

Eucaris lietojumprogrammatūra nodrošina drošu komunikāciju ar citām dalībvalstīm un, izmantojot XML, nodrošina komunikāciju ar dalībvalstu uzstādītajām aizmugursistēmām. Atbildes sūtījumu dalībvalstis nosūta tieši saņēmējam. Dalībvalsts datu centrs ir savienots ar ES TESTA tīklu.

XML sūtījumus sūta šifrēti. Šo sūtījumu šifrēšanā izmanto SSL tehniku. Aizmugursistēmai sūta parasta teksta XML sūtījumus, jo lietojumprogrammas un aizmugursistēmas sakariem jābūt aizsargātiem.

Ir paredzēta klientu lietojumprogramma (client application), ko var lietot dalībvalstī, lai veiktu meklēšanu šīs valsts reģistrā vai citu dalībvalstu reģistros. Klientus identificēs, izmantojot lietotājvārdu un paroli vai klienta sertifikātu. Savienojumus ar lietotājiem var šifrēt, bet tā ir katras dalībvalsts individuāla atbildība.

2.2.   Ar sūtījumu apmaiņu saistītas drošības iezīmes

Drošības sistēmas pamatā ir HTTPS un XML paraksta kombinācija. Tas ļauj izmantot XML parakstu, lai parakstītu visus serverim nosūtītos sūtījumus, turklāt tā var autentificēt sūtījuma autoru, pārbaudot parakstu. Vienas puses SSL (1-sided SSL) drošības standartu (tikai servera sertifikāts) izmanto, lai aizsargātu sūtījuma konfidencialitāti un integritāti un lai nodrošinātu aizsardzību pret dzēšanas, atbildes un nesankcionētas datu iekļaušanas uzbrukumiem. Tā vietā, lai attīstītu īpašu programmatūru, kas nodrošinātu divu pušu SSL standartu, izmanto XML parakstu. XML paraksta izmantojums ir tuvāks tīkla pakalpojumu standartam nekā divu pušu SSL, un tāpēc tā lietojums ir stratēģiski izdevīgāks.

XML parakstu var īstenot dažādi, bet ir izvēlēta pieeja, ka XML parakstu izmanto kā tīkla pakalpojumu drošības daļu (Web Services Security – WSS). WSS nosaka, kā izmantot XML parakstu. Tā kā WSS pamatā ir SOAP standarts, būtu loģiski pēc iespējas rīkoties saskaņā ar SOAP standartu.

2.3.   Ar sūtījumu apmaiņu nesaistītas drošības iezīmes

2.3.1.   Lietotāju autentifikācija

Eucaris tīkla lietojumprogrammas lietotāji autentificējas, izmantojot lietotājvārdu un paroli. Tā kā izmanto Windows standarta autentifikāciju, dalībvalstis vajadzības gadījumā lietotāju autentifikācijas drošību var paaugstināt, izmantojot klientu sertifikāciju.

2.3.2.   Lietotāju lomas

Eucaris lietojumprogramma veic dažādas lietotāju lomas. Katram pakalpojumu kopumam ir sava autorizācija. Piemēram, “Eucaris līguma funkcionalitātes” (konkrētiem) lietotājiem var nebūt pieeja “Prīmes funkcionalitātei”. Administratora funkcijas ir nošķirtas no regulāru tiešo lietotāju funkcijām.

2.3.3.   Reģistrēšana (logging) un sūtījumu apmaiņas trasēšana (tracing)

Eucaris lietojumprogramma veicina visu sūtījumu tipu reģistrēšanu (logging). Administratora funkcijas dod iespēju valstu administratoriem noteikt, kuri sūtījumi ir reģistrēti: tiešo lietotāju pieprasījumi, no citām dalībvalstīm saņemti pieprasījumi, valstu reģistru sniegta informācija u. c.

Lietojumprogrammu var konfigurēt, lai tā, veicot šo reģistrēšanu, izmantotu iekšēju datubāzi vai ārēju (Oracle) datubāzi. Lēmumi par to, kuri sūtījumi ir jāreģistrē, nepārprotami ir atkarīgi no citām uzstādīto sistēmu (legacy systems) reģistrācijas iekārtām un to klientu lietojumprogrammām, kas ir pieslēgušies.

Katra sūtījuma galvenē ir informācija par pieprasījuma iesniedzēju dalībvalsti, par šīs dalībvalsts pieprasījuma iesniedzēju organizāciju un iesaistītiem lietotājiem. Ir norādīts arī pieprasījuma iemesls.

Izmantojot kombinētu reģistrēšanu (combined logging) pieprasījuma iesniedzējā un atbildes sniedzējā dalībvalstī, ir iespējams veikt pilnīgu jebkura sūtījuma trasēšanu (piemēram, ja to lūdz attiecīgais iesaistītais pilsonis).

Reģistrēšanu konfigurē, izmantojot Eucaris tīkla klientu (web client) (izvēlņu administrēšana, reģistrēšanas konfigurācija). Reģistrēšanas funkcionalitāti pilda pamatsistēma (Core System). Kad ir aktivizēta reģistrēšanas funkcija, visu sūtījumu (galveni un pamattekstu) saglabā vienā reģistrācijas ierakstā (logging record). Katram definētam pakalpojumam un katram sūtījumu tipam, kas nonāk pamatsistēmā, var iestatīt reģistrācijas līmeni (logging level).

Reģistrācijas līmeņi

Ir iespējami šādi reģistrācijas līmeņi (logging levels):

Privāts – sūtījums ir reģistrēts: reģistrācija NAV pieejama konkrētam reģistrācijas pakalpojumam (extract logging service), tomēr tā ir pieejama valsts līmenī, lai veiktu revīziju un risinātu problēmas.

Nav (none) – sūtījums nav reģistrēts vispār.

Sūtījuma tipi

Dalībvalstu savstarpēja informācijas apmaiņa notiek ar vairākiem sūtījumiem, kuri shematiski ir attēloti zemāk dotajā attēlā.

Iespējamie sūtījumu tipi (kas attēlā parādīti ar dalībvalsts X Eucaris pamatsistēmu) ir šādi:

1.	Request to Core System_Request message by Client.

2.	Request to Other Member State_Request message by Core System of this Member State.

3.	Request to Core System of this Member State_Request message by Core System of other Member State.

4.	Request to Legacy Register_Request message by Core System.

5.	Request to Core System_Request message by Legacy Register.

6.	Response from Core System_Request message by Client.

7.	Response from Other Member State_Request message by Core System of this Member Stat.

8.	Response from Core System of this Member State_Request message by other Member State.

9.	Response from Legacy Register_Request message by Core System.

10.

Response from Core System_Request message by Legacy Register. Attēlā parādīta šāda informācijas apmaiņa: — ar zilām bultām attēlots informācijas pieprasījums, ko dalībvalsts X sūta dalībvalstij Y. Šie pieprasījumi un atbildes attiecīgi sastāv no 1., 2., 7. un 6. sūtījumu tipa, — ar sarkanām bultām attēlots informācijas pieprasījums, ko dalībvalsts Z nosūta dalībvalstij X. Šie pieprasījumi un atbildes attiecīgi sastāv no 3., 4., 9. un 8. sūtījumu tipa, — ar zaļām bultām attēlots uzstādītā reģistra sūtīts informācijas pieprasījums tā pamatsistēmai (šajā datu plūsmā ir iekļauts arī mantotā reģistra klienta nosūtīts pieprasījums). Šādi pieprasījumi attiecīgi sastāv no 5. un 10. sūtījuma tipa.

Attēls. Reģistrācijā izmantotie sūtījumu tipi

2.3.4.   Aparatūras drošības modulis (Hardware Security Module)

Aparatūras drošības moduli neizmanto.

Ar aparatūras drošības moduli (Hardware Security Module (HSM)) nodrošina labu aizsardzību atslēgai, ar ko paraksta sūtījumus un identificē serverus. Tas palielina vispārējo drošības līmeni, tomēr HSM moduļa pirkšanas un uzturēšanas izmaksas ir augstas, turklāt nav paredzētas prasības ieviest “FIPS 140-2” 2. vai 3. līmeņa HSM. Tā kā izmanto slēgtu tīklu, tas lielā mērā mazina apdraudējumu, tāpēc ir pieņemts lēmums sākotnēji neizmantot HSM. Ja HSM ir vajadzīgs, piemēram, lai iegūtu akreditāciju, to var pievienot arhitektūrai vēlāk.

3.   Datu apmaiņas tehniskie nosacījumi

3.1.   Vispārējs Eucaris lietojumprogrammas apraksts

3.1.1.   Pārskats

Eucaris lietojumprogramma savieno visas iesaistītās dalībvalstis vienotā tīklā, ar kā starpniecību jebkura dalībvalsts tieši sazinās ar citām dalībvalstīm. Lai notiktu saziņa, nav vajadzības izmantot centrālu elementu. Eucaris lietojumprogrammatūra garantē drošu komunikāciju ar citām dalībvalstīm un, izmantojot XML, nodrošina komunikāciju ar dalībvalstu uzstādīto aizmugursistēmu (back-end legacy system). Šī arhitektūra ir atainota šajā attēlā.

Dalībvalstis ar sūtījumiem apmainās, tos nosūtot tieši saņēmējam. Dalībvalsts datu centrs ir savienots ar tīklu, ko izmanto sūtījumu apmaiņai (TESTA). Lai piekļūtu TESTA tīklam, dalībvalstis tajā ieslēdzas, izmantojot savu pieslēguma līniju (national gate). Lai pieslēgtos tīklam, izmanto ugunssienu, turklāt Eucaris lietojumprogrammu ugunssienai pievieno ar maršrutētāju. Atkarībā no izvēlētās sūtījumu aizsardzības vai nu maršrutētājs, vai Eucaris lietojumprogramma izmanto sertifikātu.

Ir paredzēta klientu lietojumprogramma, ko var lietot dalībvalstī, lai veiktu meklēšanu šīs valsts reģistrā, vai citu dalībvalstu reģistros. Klientu lietojumprogramma pieslēdzas Eucaris. Klientus identificēs, izmantojot lietotājvārdu un paroli vai klienta sertifikātu. Savienojumu ar lietotājiem ārējā organizācijā (piemēram, policijā) var šifrēt, bet tā ir katras dalībvalsts individuāla atbildība.

3.1.2.   Sistēmas darbības joma

Eucaris sistēmas darbības joma ir ierobežota no dalībvalstu reģistrācijas iestāžu savstarpējas informācijas apmaiņas procesu viedokļa un no informācijas pasniegšanas paņēmiena viedokļa. Procedūras un automatizēti procesi, kuros informāciju ir paredzēts izmantot, neietilpst sistēmas darbības jomā.

Dalībvalstis var vai nu izvēlēties Eucaris klienta funkcionalitāti, vai arī izveidot pašas savu pielāgotu klientu lietojumprogrammu. Šajā tabulā ir aprakstīts, kuri Eucaris sistēmas aspekti ir obligāti jāizmanto un/vai jāparedz un kurus var izmantot fakultatīvi, un/vai kurus var izmantot pēc dalībvalstu brīvas izvēles.

EUCARIS aspects	M/O (9)	Remark
Network concept	M	The concept is an “any-to-any” communication.
Physical network	M	TESTA
Core application	M	The core application of EUCARIS has to be used to connect to the other Member States. The following functionality is offered by the core: — Encrypting and signing of the messages — Checking of the identity of the sender — Authorization of Member States and local users — Routing of messages — Queuing of asynchronous messages if the recipient service is temporally unavailable — Multiple country inquiry functionality — Logging of the exchange of messages — Storage of incoming messages
Client application	O	In addition to the core application the EUCARIS II client application can be used by a Member State. When applicable, the core and client application are modified under auspices of the EUCARIS organisation.
Security concept	M	The concept is based on XML-signing by means of client certificates and SSL-encryption by means of service certificates.
Message specifications	M	Every Member State has to comply with the message specifications as set by the EUCARIS organisation and this Council Decision. The specifications can only be changed by the EUCARIS organisation in consultation with the Member States.
Operation and Support	M	The acceptance of new Member States or a new functionality is under auspices of the EUCARIS organisation. Monitoring and help desk functions are managed centrally by an appointed Member State.

3.2.   Funkcionālas prasības un nefunkcionālas prasības

3.2.1.   Vispārējas funkcijas

Šajā iedaļā vispārīgi ir aprakstītas galvenās vispārējās funkcijas.

Nr.	Apraksts
1.	Sistēma dod iespēju dalībvalstu reģistrācijas iestādēm interaktīvi apmainīties ar pieprasījuma un atbilžu sūtījumiem.
2.	Sistēmā ir iekļauta klientu lietojumprogramma, kas dod iespēju tiešiem lietotājiem nosūtīt savus pieprasījumus un sniegt atbildes informāciju manuālai apstrādei.
3.	Sistēma veicina informācijas izplatīšanas darbības, ļaujot dalībvalstij pieprasījumu nosūtīt visām pārējām dalībvalstīm. Saņemtās atbildes pamata lietojumprogramma (core application) apvieno vienā klienta lietojumprogrammai (client application) adresētā atbildes sūtījumā (šo funkcionalitāti sauc “vairāku valstu izziņa” (“Multiple Country Inquiry”)).
4.	Sistēma spēj apstrādāt dažādu tipu sūtījumus. Katram lietojuma pakalpojumam definē savas lietotāju lomas: autorizāciju, maršrutēšanu, parakstus un reģistrāciju.
5.	Sistēma dod iespēju dalībvalstīm apmainīties ar sūtījumu paketēm vai sūtījumiem, kuros ir liels skaits pieprasījumu vai atbilžu. Šo sūtījumu apstrāde notiek asinhroni.
6.	Sistēma uzkrāj asinhronos sūtījumus, ja saņēmēja dalībvalsts īslaicīgi nav pieejama, un garantē to nosūtīšanu, tiklīdz saņēmējs atkal ir pieejams.
7.	Sistēma uzglabā ienākošos asinhronos sūtījumus līdz brīdim, kad tos var apstrādāt.
8.	Sistēma dod piekļuvi tikai citu valstu Eucaris lietojumiem, nevis atsevišķām organizācijām šajās citās dalībvalstīs, proti, katra reģistrācijas iestāde darbojas kā vienīgā pieslēguma līnija starp attiecīgās valsts tiešiem lietotājiem un attiecīgām citu valstu iestādēm.
9.	Vienā Eucaris serverī ir iespējams definēt dažādu dalībvalstu lietotājus un autorizēt tos saskaņā ar attiecīgās valsts piekļuves tiesībām.
10.	Sūtījumos ir iekļauta informācija par pieprasījuma iesniedzēju dalībvalsti, organizāciju un tiešo lietotāju.
11.	Ar šo sistēmu veicina dažādu dalībvalstu un pamata lietojumprogrammas un valstu reģistrācijas sistēmu starpā sūtīto sūtījumu apmaiņas reģistrēšanu (logging).
12.	Sistēma ļauj veidot īpašu sekretariātu, kas ir organizācija vai dalībvalsts, kas ir nepārprotami deleģēta veikt šo uzdevumu – apkopot reģistrēto informāciju (logged information) par visu iesaistīto dalībvalstu nosūtītajiem un saņemtajiem sūtījumiem, lai izstrādātu statistikas ziņojumus.
13.	Katra dalībvalsts pati norāda, kāda reģistrētā informācija ir darīta pieejama sekretariātam un kāda informācija ir “privāta”.
14.	Šī sistēma ļauj valstu administratoriem katrā dalībvalstī apkopot izmantošanas statistiku.
15.	Sistēma dod iespēju, izpildot dažus vienkāršus administratīvus uzdevumus, pievienoties jaunām dalībvalstīm.

3.2.2.   Izmantojamība

Nr.	Apraksts
16.	Sistēma nodrošina saskarni, lai veiktu automatizētu sūtījumu apstrādi, izmantojot aizmugursistēmu un uzstādītu sistēmas (back-end systems/legacy), un dod iespēju integrēt lietotāja saskarni šajās sistēmās (pielāgota lietotāja saskarne (customised user-interface).
17.	Sistēmu ir viegli apgūt, tā ir viegli saprotama, un tajā ir iekļauti palīdzības skaidrojumi.
18.	Sistēma ir dokumentēta, lai dalībvalstīm palīdzētu nodrošināt integrāciju, sistēmas darbību un turpmāku uzturēšanu (piemēram, uzziņu rokasgrāmatas, funkcionāla un tehniska dokumentācija, darbības instrukcija...).
19.	Lietotāja saskarne ir vairākās valodās un dod iespēju tiešam lietotājam izvēlēties lietojuma valodu.
20.	Lietotāja saskarnē ir paredzēta iespēja, lai vietējais administrators varētu valsts valodā iztulkot gan redzamo, gan kodēto informāciju.

3.2.3.   Uzticamība

Nr.	Apraksts
21.	Sistēma ir izveidota kā droša un darbā uzticama sistēma, kas pieļauj zināmas operatoru kļūdas un kas atkopsies (clean recovery) pēc elektroenerģijas padeves pārtraukumiem vai citiem traucējumiem. Ir jābūt iespējamam restartēt sistēmu, izvairoties no datu zuduma vai pieļaujot tikai minimālu datu zudumu.
22.	Sistēmas darbības rezultātiem ir jābūt stabiliem un atkārtojamiem.
23.	Sistēma ir izstrādāta tā, lai tās darbība būtu uzticama. Ir iespējams īstenot sistēmu konfigurācijā, kas katrā divpusējā komunikācijā garantētu 98 % pieejamību (izmantojot papildelementus (redundancy), dublējuma serverus (back-up servers) u. c.).
24.	Ir iespējams izmantot sistēmas daļu pat tad, ja daži komponenti nedarbojas (ja dalībvalsts C nav pieejama, dalībvalstis A un B var turpināt uzturēt sakarus). Vajadzētu pēc iespējas novērst atsevišķu informācijas ķēdes punktu kļūdainu darbību.
25.	Atkopšanās laikam pēc nopietnas sistēmas kļūmes vajadzētu būt mazākam nekā viena diena. Vajadzētu pēc iespējas samazināt laiku, kad sistēma nedarbojas, izmantojot tālvadību, ko, piemēram, veiktu no centrāla sistēmas kontrolpunkta (central service desk).

3.2.4.   Darbība

Nr.	Apraksts
26.	Sistēmu var izmantot cauru diennakti septiņas dienas nedēļā. Šīs darbības laika (time-window 24x7) prasības ir jāievēro arī dalībvalstu uzstādītām sistēmām.
27.	Sistēma ātri reaģē uz lietotāja prasījumiem neatkarīgi no fonā risinātiem uzdevumiem. Tāda prasība ir izvirzīta arī pušu uzstādītām sistēmām, lai nodrošinātu pieņemamu atbildes laiku. Par pieņemamu uzskata vispārēju atbildes laiku, kas vienam prasījumam nav ilgāks kā 10 sekundes.
28.	Sistēma ir izstrādāta tā, lai to varētu lietot vairāki lietotāji un lai fonā risināmie uzdevumi varētu turpināt darbību, kamēr lietotājs risina priekšplāna uzdevumus.
29.	Sistēma ir izstrādāta, lai tā būtu adaptīva un tā varētu tikt galā ar iespējamu sūtījumu skaita pieaugumu, ja sistēmai pievieno jaunu funkcionalitāti vai arī tai pievienojas jauna organizācija vai dalībvalsts.

3.2.5.   Drošība

Nr.	Apraksts
30.	Sistēma ir piemērota (proti, ir paredzēti atbilstīgi drošības pasākumi), lai varētu veikt apmaiņu ar sūtījumiem, kas satur personas datus (piemēram, transportlīdzekļu īpašnieki/turētāji), kuri ir klasificēti kā ES dati ar ierobežotu piekļuvi (EU restricted).
31.	Sistēmu uztur tā, lai novērstu neatļautu piekļuvi datiem.
32.	Sistēmā ir integrēta valstu tiešo lietotāju piekļuves tiesību un atļauju pārvaldības funkcija.
33.	Dalībvalstīm ir iespējams pārbaudīt sūtītāja identitāti (dalībvalsts mērogā), izmantojot XML parakstu.
34.	Dalībvalstīm ir skaidri jāautorizē citas dalībvalstis, lai tās lūgtu konkrētu informāciju.
35.	Sistēma lietojumprogrammas līmenī nodrošina pilnīgu drošības un šifrēšanas politiku, kas ir saskaņā ar šādās situācijās vajadzīgo drošības pakāpi. Informācijas pilnīgu aizsardzību un integritāti garantē XML paraksta un šifrēšanas izmantojums, ko veic ar SSL tunelēšanas (SSL-tunnelling) palīdzību.
36.	Jebkuru sūtījumu apmaiņu var izsekot, izmantojot reģistrēšanu (logging).
37.	Aizsardzību nodrošina pret informācijas dzēšanas uzbrukumiem (trešā puse dzēš sūtījumu) un atbildes vai datu iekļaušanas uzbrukumiem (trešā puse atbild vai iekļauj sūtījumu).
38.	Sistēma izmanto uzticamas trešās puses sertifikātu (Trusted Third Party – TTP).
39.	Sistēma var attiecībā uz katru dalībvalsti apstrādāt dažādus sertifikātus atkarībā no sūtījuma vai konkrētās darbības tipa.
40.	Lietojumprogrammas drošības pasākumi ir pietiekami, lai varētu izmantot neakreditētus tīklus.
41.	Sistēma spēj izmantot novatoriskus drošības risinājumus, piemēram, XML ugunssienu.

3.2.6.   Pielāgošanās spēja

Nr.	Apraksts
42.	Sistēma var apstrādāt jaunus sūtījumus, un to var papildināt ar jaunām funkcijām. Pielāgojumu izmaksas ir minimālas, jo lietojumprogrammas komponentus izstrādā centralizēti.
43.	Dalībvalstīm ir iespēja divpusēja izmantojuma vajadzībām definēt jaunu sūtījumu tipus. Visām dalībvalstīm nav izvirzītas prasības strādāt ar visiem sūtījumu tipiem.

3.2.7.   Atbalsts un uzturēšana

Nr.	Apraksts
44.	Sistēmā ir integrētas pārraudzības funkcijas, ko attiecībā uz dažādu dalībvalstu tīkliem un serveriem veic centrālais sistēmas kontrolpunkts un/vai operatori.
45.	Sistēma dod iespēju centrālajam sistēmas kontrolpunktam veikt tālvadību.
46.	Sistēmas funkcijas ļauj veikt problēmu analīzi.
47.	Sistēmai var pievienoties arī jaunas dalībvalstis.
48.	Lietojumprogrammu var viegli instalēt darbinieki, kuriem ir minimālas IT zināšanas un pieredze. Instalācijas procedūra ir maksimāli automatizēta.
49.	Sistēmā paredzētas pastāvīgas testēšanas un kontroles funkcijas.
50.	Tā kā sistēma ir veidota atbilstīgi tirgū pieejamiem standartiem, turklāt lietojumprogramma ir izstrādāta tā, lai centrālā sistēmas kontrolpunkta palīdzība būtu pēc iespējas mazāk vajadzīga, tad sistēmas apkopes un uzturēšanas gada izmaksas ir saglabātas iespējami zemā līmenī.

3.2.8.   Izstrādes prasības

Nr.	Apraksts
51.	Sistēma ir izstrādāta un dokumentēta, lai to varētu ekspluatēt daudzu gadu garumā.
52.	Sistēma ir izstrādāta, lai tās darbība būtu neatkarīga no tīkla pakalpojumu sniedzēja.
53.	Sistēma ir saderīga ar pašreizējo dalībvalstīs lietoto aparatūru un programmatūru un mijiedarbojas ar šīm reģistrācijas sistēmām, izmantojot atvērto standartu tīkla pakalpojumu tehnoloģijas (XML, XSD, SOAP, WSDL, HTTP(s), Web services, WSS, X.509 u. c.).

3.2.9.   Piemērojamie standarti

Nr.	Apraksts
54.	Sistēma ir saskaņā ar datu aizsardzības standartiem, kas izklāstīti Regulā (EK) Nr. 45/2001 (21., 22. un 23. pantā) un Direktīvā 95/46/EK.
55.	Sistēma ir saderīga ar IDA standartiem.
56.	Sistēma darbojas ar UTF8.

4. NODAĻA. Izvērtējums

1.   Izvērtējuma procedūra saskaņā ar 20. pantu (Lēmuma gatavošana saskaņā ar Lēmuma 2008/615/TI 25. panta 2. punktu)

1.1.   Anketa

Attiecīgā Padomes darba grupa izstrādā anketu par katru no Lēmuma 2008/615/TI 2. nodaļā izklāstītajiem automatizētiem datu apmaiņas paņēmieniem.

Tiklīdz dalībvalsts uzskata, ka tā izpilda priekšnosacījumus, lai veiktu attiecīgās kategorijas datu apmaiņu, tā izpilda attiecīgo anketu.

1.2.   Izmēģinājumi

Lai izvērtētu anketas rezultātus, dalībvalsts, kas vēlas sākt datu apmaiņu, veic izmēģinājumus kopā ar vienu vai vairākām citām dalībvalstīm, kuras saskaņā ar Padomes lēmumu jau piedalās datu apmaiņā. Izmēģinājumus veic vai nu īsi pirms, vai īsi pēc izvērtējuma inspekcijas.

Izmēģinājumu apstākļus un mehānismus noteiks attiecīgā Padomes darba grupa, un tos veiks saskaņā ar iepriekš panāktu konkrētu vienošanos ar attiecīgo dalībvalsti. Par izmēģinājumu praktiskiem aspektiem lēmumu pieņems dalībvalstis, kas tajās piedalās.

1.3.   Izvērtējuma inspekcija

Lai izvērtētu anketas rezultātus, dalībvalstīs, kas vēlas sākt piedalīties datu apmaiņā, rīkos izvērtējuma inspekcijas.

Šo inspekciju apstākļus un mehānismus noteiks attiecīgā Padomes darba grupa, un tās rīkos saskaņā ar konkrēto vienošanos, kas pirms tam panākta starp attiecīgo dalībvalsti un izvērtējuma grupu. Attiecīgā dalībvalsts dos iespēju izvērtējuma grupai pārbaudīt automatizēto datu apmaiņu datu kategorijā vai kategorijās, kuras paredzēts izvērtēt, jo īpaši saskaņā ar izvērtējuma grupas pieprasījumiem organizējot inspekcijas norises programmu.

Viena mēneša laikā izvērtējuma grupa izstrādā izvērtējuma inspekcijas ziņojumu, ko tā nosūta attiecīgai dalībvalstij, lai tā to komentētu. Vajadzības gadījumā izvērtējuma grupa pārskatīs šo ziņojumu, pamatojoties uz dalībvalsts sniegtajiem komentāriem.

Izvērtējuma grupā ir ne vairāk kā trīs eksperti, ko izraudzījušās dalībvalstis, kas piedalās automatizētā datu apmaiņā ar tām datu kategorijām, ko paredzēts izvērtēt, turklāt šiem ekspertiem ir darba pieredze ar attiecīgo datu kategoriju, viņiem ir atbilstīga valsts izsniegta drošības pielaide darbam ar šiem jautājumiem, un viņi pauduši vēlmi piedalīties vismaz vienā izvērtējuma inspekcijā citā dalībvalstī. Komisiju aicinās piedalīties izvērtējuma grupā novērotāja statusā.

Izvērtējuma grupas dalībnieki ievēros slepenības statusu informācijai, kas viņiem būs kļuvusi zināma, pildot darba uzdevumus.

1.4.   Ziņojums Padomei

Padomei iesniegs vispārēju izvērtējuma ziņojumu, kurā apkopoti anketu, izvērtējuma inspekciju un izmēģinājumu rezultāti, lai tā pieņemtu lēmumu saskaņā ar Lēmuma 2008/615/TI 25. panta 2. punktu.

2.   Saskaņā ar 21. pantu veiktā izvērtēšanas procedūra

2.1.   Statistika un ziņojumi

Katra dalībvalsts apkopo statistiku par automatizētas datu apmaiņas rezultātiem. Lai nodrošinātu iespēju statistiku salīdzināt, attiecīgā Padomes darba grupa izstrādās statistikas modeli.

Statistikas datus reizi gadā pārsūtīs Komisijai un Ģenerālsekretariātam, kas sagatavos apkopotu pārskatu par iepriekšējo gadu.

Turklāt dalībvalstīm lūgs regulāri, ne biežāk kā reizi gadā iesniegt papildu informāciju par automatizētās datu apmaiņas administratīvu, tehnisku un finansiālu īstenošanu, lai informāciju analizētu un izmantotu procesa uzlabošanai. Pamatojoties uz tādu informāciju, izstrādās ziņojumu, ko iesniegt Padomei.

2.2.   Pārskatīšana

Padome izskata šeit aprakstītos izvērtēšanas mehānismus pienācīgā laikā un vajadzības gadījumā tos pārskata.

3.    Ekspertu sanāksmes

Attiecīgajā Padomes darba grupā eksperti regulāri rīkos sanāksmes, lai organizētu un īstenotu minētās izvērtēšanas procedūras, kā arī lai dalītos pieredzē un pārrunātu iespējamus uzlabojumus. Vajadzības gadījumā šo ekspertu pārrunu rezultātus integrēs 2.1. punktā minētajā ziņojumā.

---

(1)  “Pilnīgs” nozīmē to, ka izmanto arī reti sastopamu alēļu vērtības.

(2)  Šī pozīcija ir definēta ASCII standartā.

(3)  M = obligāts (mandatory), ja pieejams valsts reģistrā; O = fakultatīvs (optional).

(4)  Visi dalībvalstu īpaši norādītie atribūti ir atzīmēti ar Y.

(5)  Saskaņotā dokumenta saīsinājums, skatīt Padomes Direktīvu 1999/37/EK, 29.4.1999.

(6)  M = obligāts (mandatory), ja pieejams valsts reģistrā; O = fakultatīvs (optional).

(7)  Saskaņotā dokumenta saīsinājums, skatīt Padomes Direktīvu 1999/37/EK, 29.4.1999.

(8)  Luksemburgā izmanto divus dažādus transportlīdzekļu dokumentu reģistrācijas ID.

(9)  M = obligāts (mandatory) jāizmanto vai jāievēro; O = fakultatīvs (optional) izmantojums vai ievērošana.