Hlavní blok. Kořen grafu.
Váže se k celému odesílanému souboru všech odesílatelů určenému pro jednoho příjemce.
Popis struktury bloku v obecném tvaru je
k dispozici v odkazu popis struktury bloků a souborů DS.
Změny realizované od vydání DS2 jsou v seznamu soupis nových a
doplněných bloků v DS 3.01.01.
Změny realizované od vydání DS3 jsou v seznamu změny v popisu
struktury bloků a souborů DS.
{distribuováno od
verze 2.01.01}
kód |
T |
D |
V |
plný
název |
hodnota |
podmínky,
pokyny, poznámky |
změny |
id_soubor |
a |
-40 |
1 |
jednoznačná vnitřní
identifikace souboru v rámci firmy a jejího programu nebo
informačního systému |
text předepsané konstrukce |
pokyny: 1. povinný 2. viz id_soubor - pokyny |
|
verze_ds |
a |
8 |
1 |
verze datové struktury |
[V_DS] # |
pokyny: 1. ve formátu xx.xx.xx, 3. viz verze_ds - pokyny poznámky: 1. například: ”03.02.01” 2. viz verze_ds - poznámky |
|
verze_nclp |
a |
8 |
1 |
verze používaného NČLP |
[V_NCLP] #! |
pokyny: 1. ve formátu xx.xx.xx 2. není-li NČLP vůbec
využíván, zadává se nejnižší verze 2.00.00 3. viz verze_nclp - pokyny poznámky: například: ”02.07.01” |
|
bin_priloha |
a |
1 |
1 |
binární datové bloky |
T, B viz seznam hodnot |
pokyny: viz priloha poznámky: nejčastěji bude = T |
|
ur |
a |
1 |
1 |
určení; typ přenášených
dat (v případě pacientských dat
též urgentnost sdělení nebo zpracování souboru) |
R, S, U, V,
B, C, H,
T viz seznam
hodnot |
pokyny: 1. viz blok is a též
viz název souboru
2. viz ur
- pokyny 3. viz 01 poznámky: viz ur -
poznámky |
od verze DS 3.01.01 je místo L nyní B, nově je C, H a V (H, V je pro
další verzi DS) |
typ_odesm |
a |
2 |
1 |
typ odesílajícího místa |
[TAB_TO] #! |
pokyny: 1. viz název souboru
2. viz typ_odesm - pokyny 3. viz 01 |
|
ozn_soub |
a |
5 |
1 |
doplňující označení
odesílaného souboru |
libovolný text |
pokyny: 1. viz název souboru
2. viz 01 |
|
potvrzeni |
a |
1 |
? |
požadavek na potvrzení
přijetí souboru |
N, P viz seznam
hodnot |
pokyny: implicitní hodnota = N |
|
e |
|
1 |
informace o firmě a jejím
programu nebo IS, kterým byl soubor vytvořen |
|
poznámky: specifikuje: kod_firmy, kod_prog,
verze_prog; |
|
|
e |
|
1 |
příjmové místo souboru (=komu je soubor určen) |
|
poznámky: je vždy jen jedno |
|
|
e |
|
? |
garant odesílaných dat |
|
pokyny: 1. garantuje všechna data
odesílaná v rámci celého bloku DASTA 2. sděluje se, jen pokud to
vyžaduje příjemce! poznámky: |
nové od 3.01.01 |
|
e |
|
+/ |
odesilatel (odesílatelé)
souboru |
|
podmínky: ve struktuře je buď element
”is” nebo element ”pd” pokyny: viz 02 poznámky: 1. tito odesílatelé se
podílejí na souboru 2. viz is
- poznámky |
|
|
e |
|
/1 |
potvrzení doručení souboru (=zpětné hlášení) |
|
podmínky: ve struktuře je buď element
”is” nebo element ”pd” pokyny: 1. viz pd
- pokyny 2. viz 02 |
|
|
e |
|
? |
protokol o komunikaci |
|
pokyny: nastavení kontrol na straně
příjemce poznámky: |
|
|
a |
|
1 |
datum a čas vytvoření bloku dasta
tj.datum a čas vytvoření souboru |
formát DTS |
pokyny: viz dat_vb
- pokyny |
|
Podmínky, pokyny,
seznam hodnot, poznámky:
*dasta
Viz:
DS -
schéma blokové - DASTA, PM, IS, IP
DS -
schéma blokové - V, VR, VRN
DS -
schéma blokové - LO, LOP, LOI, LOD
id_soubor
Jednoznačná vnitřní
identifikace zasílaného souboru.
Každá firma (= tvůrce
příslušného komunikujícího SW) je povinna zajistit jednoznačnost tohoto řetězce
pro všechny svoje aplikace, které soubory vytvářejí tj. není možné, aby různé
nebo stejné programy u různých uživatelů vytvořily soubor se shodnou
identifikací.
Identifikační řetězec musí být
bez mezer a povinně začíná osmiznakovým kódem firmy, která soubor
generuje - viz číselník [TAB_KF] popsaný v bloku zdroj_is .
Další konstrukce řetězce je libovolná (dle interních směrnic firmy).
Pokud není kód firmy přidělen,
lze použít zástupný provizorní kód, který má na první pozici znak ”_”
(podtržítko), za kterým následuje 7 písmen. Tento provizorní kód lze
používat jen po vzájemné jednoznačné dohodě mezi komunikujícími stranami!
Pro konstrukci názvu lze
použít tyto údaje:
kod_firmy (z elementu zdroj_is)
- povinný osmiznakový údaj určující firmu, od níž je komunikující
program nebo IS
kod_prog (z elementu zdroj_is)
- kód programu nebo IS jednoznačně specifikovaný firmou, která jej vytvořila
verze_prog (z elementu zdroj_is)
- verze programu nebo IS jednoznačně specifikovaná firmou, která jej vytvořila
liccis_prog (z elementu zdroj_is)
- licenční číslo programu přidělené firmou, která jej vytvořila
ur - určení souboru (v případě
pacientských dat též informace o urgentnosti)
typ_odesm - typ odesílajícího místa
ozn_soub - označení souboru
datum a čas vzniku ve formátu: ”YYYY-MM-DDTHH:MM:SS”
Osmiznakový kód firmy je
povinný, za ním doporučujeme
uvádět kód programu, verzi programu, licenční číslo a datum a čas vzniku.
Příklady: Firma…ABCDEFGH, OKB v Aši, program... LIS,
verze ... 12.10, č.licence...
0125
ABCDEFGHLIS12.1001252001-09-27T11:23:01 firma+ program+verze+lic. číslo+datum a čas
vzniku
ABCDEFGH12345678902001-09-27T11:23:01 firma+unikátní firemní kód pro program,
verzi a pracoviště+datum
a čas vzniku
Tato vnitřní identifikace
souboru nemá přímý vztah k názvu souboru.
Konstrukce názvu souboru
zůstává stejná jako v DS 1.20 - viz název souboru
.
verze_ds
V této položce je
sdělováno, že soubor byl vytvořen na podkladě DS XX.xx.yy (uvedené verze XX.xx
a subverze yy).
Informace o jednotlivých
verzích DS jsou v číselníku [V_DS]. Subverze nejsou do číselníku zapisovány
(pouze verze).
V rámci verzí budou
realizovány zásadní doplňky a úpravy týkající se povinných atributů a elementů.
V rámci subverzí budou
realizovány pouze drobné změny a doplňky týkající se popisů anebo nepovinných
atributů a elementů.
Viz verze datového standardu, číselník verzí [V_DS], záhlaví datového souboru DS a datový standard - použití DTD.
Informaci o verzi a subverzi
využívají validující parsery. Takové parsery nemusí být (a mnohdy zřejmě ani nebudou)
volány při běžném zpracování zprávy informačním systémem.
verze_nclp
V této položce je
sdělováno, že odesílatel pracoval s NČLP a příslušnými interními číselníky
uvedené verze.
V položce není záměrně
zohledněno případné provizorní rozšíření NČLP o lokální položky (a jeho lokální
verze), neboť lokální doplňky do NČLP jsou považované za dočasné a nouzové
řešení, které je realizováno pouze provizorně a to vždy jen po vzájemné
dohodě komunikujících stran.
Informace o jednotlivých
verzích NČLP jsou v číselníku [V_NCLP]
.
Číslo verze NČLP vystupuje při
každém generování souborů z programu ČLP i systému SLP.
Není-li NČLP vůbec využíván,
zadává se implicitní hodnota nejnižší možné verze ”2.00.00”.
Na úrovni třetího (pravého)
dvojčíslí budou vyznačovány pouze drobné změny a naléhavé doplňky položek
(položky potřebné pro některé uživatele, které byly doplněny v době mezi
upgrade a budou oficiálně distribuovány v nejbližším řádném upgrade).
Na úrovni druhého
(prostředního) dvojčíslí budou vyznačovány oficiální upgrade NČLP realizované
v definovaných termínech.
První dvojčíslí zůstane
neměnné po dobu existence tohoto NČLP s touto současnou filosofií jeho
struktury.
bin_priloha
Binární datové bloky
v souboru:
T = v souboru není
odkazováno na žádné binární bloky, jedná se pouze o běžný text (běžná
varianta)
B = v souboru je
odkazováno na binární datové bloky (libovolného obsahu)
ur
Určení souboru nebo-li typ
přenášených dat:
R = pacientská data - rutinní
zpracování
S = pacientská data - statimové zpracování = indikace, že má být
tento soubor příjemcem zpracován přednostně před ”R”
U = výkazy a zprávy pro ÚZIS
ČR
V = soubor
vykazovaných výkonů - bude rozpracováno v další verzi DS
B = laboratorní bloky dat -
Laboratorní příručka, profily pro externí zpracování atd.
C = číselníky
H = hlášení a
zprávy z oblasti "hygiena a epidemiologie" - bude rozpracováno
v další verzi DS
T = technická (testovací) data
- přenáší se bloky, jejichž struktura je domluvena pouze mezi příjemcem a
odesílatelem
Určení souboru má vztah
k příslušnému výběru (zařazení) struktury pro přenos dat v bloku is (např: ip,
ivv, ilp aj.).
Slouží ke konstrukci jména
datového souboru - viz název souboru - ”U”.
Dělení podle
typu přenášených dat je zde zvoleno s ohledem na konstrukci názvu souborů,
která vychází z DS1.20 a respektuje limitující možnosti vyplývající
z krátkých názvů (8.3). Jedná se o hrubé účelové rozdělení (které ale nyní
bohatě vyhovuje).
typ_odems
Typ odesílajícího místa je od
verze DS1.20 povinně kódován do názvu souboru.
Seznam odesílajících míst -
viz [TAB_TO] .
Slouží ke konstrukci jména
datového souboru - viz název souboru - ”TT”.
potvrzeni
N
= nepotvrzovat (implicitní varianta)
P = potvrdit, že soubor byl
doručen a přijat
garant_dat
Připraveno pro příjemce typu
"IZIP" aj. Blok může být vkládán i do jiných bloků (viz popis v
poznámce bloku garant_dat).
is
Více odesílatelů (skupin
záznamů) může sdružit své záznamy do jednoho souboru a ten je odeslán jako celek
na adresu jednoho příjemce (příjmové místo).
pd
V bloku pd je
sdělován stav doručení souboru - hlášení příjemce o doručení a správnosti
souboru. Je zasíláno na základě požadavku potvrzeni, který byl připojen
k původnímu zasílanému souboru.
prot_kom
Blok vybraných informací o
specifikaci komunikačního protokolu mezi právě komunikujícími systémy ”A” a
”B”.
Systém odesílatele ”A”
připravuje data s respektováním omezení a požadavků systému ”B” a
s ohledem na své možnosti. Kontrolní aparát na straně systému příjemce ”B”
realizuje kontroly a zpracování na základě sdělených specifikací a omezení.
Blok může být vždy speciální pro každou dvojici komunikujících stran. Sděluje se vždy, je významný i pro zpětné zpracování zaslaného souboru (příjemcem nebo i auditorem) i pro řešení případných kolizních stavů.
Blok je
připraven, ale naplněn bude až podle požadavků praxe.
dat_vb
Datum a čas vytvoření souboru
příslušným programem nebo IS. Nejedná se o datum a čas odeslání.
Viz též evidence časů zpracování souboru .
01 - pokyny
společné pro ur, typ_odesm, ozn_soub:
Konstrukce názvu vychází z:
URČENÍ (”U”),
TYPU ODESÍLAJÍCÍHO MÍSTA
(”TT”) a
OZNAČENÍ SOUBORU (”XXXXX”) -
viz název souboru .
Upozornění pro tvůrce
DS:
Vzhledem ke krátkému řetězci
pro název (s ohledem - mimo jiné na operační systém DOS - je délka = ”8.3”)
může dojít v dlouhodobém archivu k výskytu několika souborů stejného
jména. Je proto nutné zajistit, aby toto nevedlo ke kolizi (například vhodným
zavedením různých složek s ohledem na odesílající místa a vhodná kontrola
jmen).
Jednoznačnou identifikací
souboru je jeho vnitřní identifikace ”id_soub” - viz též poznámka ”01”.
02 - pokyny
společné pro is, pd:
Ve struktuře bloku ”dasta”
může být několik elementů is anebo jeden element pd. Čili is
a pd se nemohou vyskytovat v jednom bloku současně. Tento zápis
nelze v textové tabulce vhodně realizovat (je vyznačen symbolickými
lomítky ve sloupci V).
Tato podmínka je realizována v XML.