Hlavní blok. Kořen grafu. Varianta pro DS3.
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 (varianta
pro DS3) |
|
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.