natgillin/translations-raw huggingface dataset:
Oblast 3: v jakémkoliv kroku po [krok 3] se může kterýkoliv účastník rozhodnout, že bude od druhého účastníka požadovat ad hoc informace. 
Branch 3: at any step after [step 3], any participant may choose to Request AdHoc Information from the other participant
Účastník provede případ životní situace H_BUC_01_Subproces – Ad hoc výměna informací; 
The participant executes business use case H_BUC_01_Subprocess – AdHoc Exchange of Information;
Následující oblasti určují použití administrativních procesů v rámci tohoto procesu 
The Following Branches Determine the use of Administrative Processes within this Business Process
Oblast 4: v jakémkoliv kroku mezi [krok 3] a [krok 8] se může protistrana rozhodnout, že tento případ životní situace předá jiné příslušné instituci v rámci svého členského státu, která převezme odpovědnost za jeho vyřízení. 
Branch 4: at any step between [step 3] and [step 8] the Counterparty may choose to Forward this Business Use Case to another Competent Institution within their MS who assumes responsibility for handling it
Účastník provede případ životní situace AD_BUC_05 – předání případu. 
The participant executes business use case AD_BUC_05 – Forward Case;
Oblast 5: v jakémkoliv kroku po [krok 4] se může vlastník případu rozhodnout zneplatnit H120 SED, který byl zaslán. 
Branch 5: at any step after [step 4] the Case Owner may choose to invalidate the H120 SED that was sent.
Vlastník případu provede případ životní situace AD_BUC_06-Subproces - zneplatnění_SEDu. 
The Case Owner executes business use case AD_BUC_06-SubProcess - Invalidate_SED;
Vlastník případu nepovinně vyplní „Žádost o zdravotnické informace / informace o odhadovaných nákladech“ (H120), a to zanesením všech požadovaných údajů. 
Optionally, the Case owner fills in " Request for Medical Information / Information on Estimated Costs " (H120) by entering all required data;
Vlastník případu nepovinně zašle H120 protistraně. 
Optionally, the Case Owner sends the H120 to the Counterparty;
Oblast 6: v jakémkoliv kroku po [krok 7] se může protistrana rozhodnout zneplatnit H121 SED, který byl zaslán. 
Branch 6: at any step after [step 7] the Counterparty may choose to invalidate the H121 SED that was sent.
Protistrana provede případ životní situace AD_BUC_06 – Subproces - zneplatnění_SEDu. 
The Counterparty executes business use case AD_BUC_06 -SubProcess Invalidate_SED;
Vlastník případu nepovinně vyplní „Odpověď na žádost o zdravotnické informace / informace o odhadovaných nákladech“ (H121), a to zanesením všech požadovaných údajů. 
Optionally, the Case Owner fills in " Reply to Request for Medical Information / Reply to Request for Information on Estimated Costs " (H121) by entering all required data;
Vlastník případu nepovinně zašle H121 protistraně. 
Optionally, the Case Owner sends the H121 to the Counterparty.
Oblast 7: [odstraněna] 
Branch 7: [Removed]
Oblast 8: v jakémkoliv kroku po [krok 3] se může protistrana rozhodnout zaslat aktualizovanou verzi H121 SED 
Branch 8: at any step after [step 3] the Counterparty may choose to send an updated version of the H121 SED
Vlastník případu provede životní situace případu AD_BUC_010 - aktualizace_SEDu. 
The Case Owner executes business use case AD_BUC_010 - Update_SED;
Oblast 9: v jakémkoliv kroku po [krok 4] se může jakýkoliv účastník nepovinně rozhodnout zaslat druhému účastníkovi připomínku týkající se zaslání informací, které od druhého účastníka očekávali, ale neobdrželi. 
Branch 9: at any step after [step 4] the any Participant may optionally choose to send a Reminder to the other participant for the return of information they were expecting from that participant but did not receive.
Účastník, který uplatní tuto oblast, provede případ životní situace AD_BUC_07 -_připomínka. 
The participant who invokes this branch executes business use case AD_BUC_07 -_Reminder;
Oblast 10: [odstraněna] 
Branch 10: [Removed]
Výjimky: 
Exceptions:
Zahrnuje: 
Includes:
Viz diagram v části 4.4 
See diagram at part 4.4
Zvláštní požadavky: 
Special Requirements:
Zvl. požadavek 1: Pravidla týkající se uplatňování oblastí: 
SR1: Rules about the invoking of Branches:
[Oblast 1] – Lze uplatnit jednou 
[Branch 1] – May be invoked once
[Oblast 2] – Lze uplatnit jednou 
[Branch 2] – May be invoked once
[Oblast 3] – Lze uplatnit jednou 
[Branch 3] – May be invoked once
[Oblast 4] – Lze uplatnit více než jednou 
[Branch 4] – May be invoked more than once
[Oblast 5] – Lze uplatnit jednou v každé verzi SED H120 
[Branch 5] – May be invoked once per instance of SED H120
[Oblast 6] – Lze uplatnit jednou v každé verzi SED H121 
[Branch 6] – May be invoked once per instance of SED H121
[Oblast 8] – Lze uplatnit více než jednou 
[Branch 8] – May be invoked more than once
[Oblast 9] – Lze uplatnit více než jednou 
[Branch 9] – May be invoked more than once
Zvl. požadavek 2: Alternativní oblasti 1–9 představují nepřerušující oblasti. 
SR2: Alternative Branches 1 – 9 are non-interrupting Branches;
Předpoklady: 
Assumptions:
Poznámky a otázky: 
Notes and Issues:
Následující tabulka upřesňuje SEDy, které k sobě logicky patří; obvykle jsou známy jako dvojice žádost – odpověď. 
The following table specifies the SEDs that have a logical pairing to one another, usually this is known as a request-reply pair.
SED PRO ŽÁDOST 
REQUEST SED
SED(y) PRO ODPOVĚĎ 
REPLY SED(s)
Následující tabulka upřesňuje, zda je při zasílání typu SEDu povoleno zahrnout přílohy. 
The following table specifies whether attachments are permitted to be included when sending a SED type.
Přílohy 
Attachments
Povoleno 
Allowed
Bude upřesněno 
TBD
Následující tabulka upřesňuje verzi SEDu, která se použije v tomto případě životní situace. 
The following table specifies the version of the SED that are used in this Business Use Case.
Verze 
Version
4.0.x 
4.0.x
Následující tabulka upřesňuje verzi subprocesů, které se použijí v tomto případě životní situace. 
The following table specifies the version of the Sub-processes that are to be used in this Business Use Case
SUBPROCES 
SUB PROCESS
H_BUC_01_Subproces 
H_BUC_01_Subprocess
1.0.x 
1.0.x
H_BUC_02_Subproces 
H_BUC_02_Subprocess
Nepoužívá se 
Not used
H_BUC_03a_Subproces 
H_BUC_03a_Subprocess
H_BUC_03b_Subproces 
H_BUC_03b_Subprocess
H_BUC_05_Subproces 
H_BUC_05_Subprocess
H_BUC_06_Subproces 
H_BUC_06_Subprocess
H_BUC_07_Subproces 
H_BUC_07_Subprocess
H_BUC_08_Subproces 
H_BUC_08_Subprocess
H_BUC_09_Subproces 
H_BUC_09_Subprocess
AD_BUC_01_Subproces – uzavření případu 
AD_BUC_01_Subprocess – Close Case
AD_BUC_02_Subproces – opětovné otevření případu 
AD_BUC_02_Subprocess – Reopen Case
AD_BUC_03_Subproces – přidání účastníka 
AD_BUC_03_Subprocess – Add Participant
AD_BUC_04_Subproces – odstranění účastníka 
AD_BUC_04_Subprocess – Remove Participant
AD_BUC_05_Subproces – předání případu 
AD_BUC_05_Subprocess – Forward Case
AD_BUC_06_Subproces – zneplatnění SEDu 
AD_BUC_06_Subprocess – Invalidate SED
AD_BUC_07_Subproces – připomínka 
AD_BUC_07_Subprocess – Reminder
AD_BUC_08_Subproces – objasnění obsahu 
AD_BUC_08_Subprocess – Clarify Content
AD_BUC_09_Subproces – zamítnutí SEDu 
AD_BUC_09_Subprocess – Reject SED
AD_BUC_10_Subproces – aktualizace SEDu 
AD_BUC_10_Subprocess – Update SED
AD_BUC_11_Subproces – výjimka 
AD_BUC_11_Subprocess – Business Exception
AD_BUC_12_Subproces – změna účastníka 
AD_BUC_12_Subprocess – Change of Participant
Tato kapitola popisuje případ životní situace výměna zdravotnických informací za použití BPMN 2.0. 
This chapter describes the Business Use Case Medical Information using BPMN 2.0.
Bude upřesněno 
tbd
Datum otázky 
Issue date
Akce/Usnesení 
Action/Resolution
Datum uzavření 
Close date
Nóta obdržená od J-I.S.A: Když protistrana obdrží první H120, začne jednat s lékařem/nemocnicí. 
Comment received from J-I.S.A: When the counterparty receives the first H120 they start the arrangement with the doctor/hospital.
Lékař/nemocnice dotčenou osobu objedná a provede nezbytné přípravy. 
The doctor/hospital book an appointment with the person concerned and makes the necessary preparations.
Pokud by dorazila aktualizovaná žádost, pravděpodobně by to znamenalo, že všechna opatření musí být provedena znovu, což by znamenalo, že aktualizaci je třeba považovat za novou žádost. 
If an updated request arrives it would probably mean that all arrangements have to be redone meaning that the update is to be considered a new request.
Na toto je třeba myslet. 
You need to think about that.
Bude projednáno se všemi zainteresovanými sektorovými ad hoc skupinami. 
To be discussed with all interested sectorial AHGs
V případě důchodů může existovat více než jedna protistrana, což je třeba zohlednit, i když v sektorech S a DA bude vždy pouze jedna protistrana. 
In case of pensions there may be more than one counterparty so we need to take it into account even if in S and DA sectors there will be always one Counterparty.
Souhlasíme, že je pouze jedna protistrana a pokud je zapojeno více institucí, jako například v sektoru P, měl by být pro každou zúčastněnou P instituci otevřen nový BUC. 
we agree that there is only one counterparty and if more institutions are involved like in P sector a new BUC should be opened in regard to each P institution involved.
Velice důležitá nóta. 
A very important comment.
Z mého pohledu je v tomto případě bezpečnější celý SED zneplatnit a zaslat nový. 
For me it is safer to invalidate the whole SED and send a new one here.
Tato logika byla použita v některých ad hoc skupinách, pokud jde o zajištění úhrady SEDů. 
This logic was used in some AHGs in regard for sure to reimbursement SEDs.
Ale aktualizaci lze možná zdůvodnit, pokud budou k dispozici jasné informace (nyní je máme), že aktualizované SEDy jsou verzemi (tedy že pozdější nenahrazuje dřívější), a jak postupovat, pokud jsme obdrželi aktualizovanou verzi, ale již jsme začali konat na základě „původní verze“ – mělo by to záviset čistě na odbornosti úředníka, nebo by měla existovat možnost nejprve odpovědět na původní SED a poté dodatečně na aktualizovaný? 
But maybe update can be justified when there will be a clear information (now we have it) that updated SEDs are versioned (the latter does not replace the former) and how should we act when we have received updated version but have already acted based on the “original one” – should it depend purely on the knowledge and expertise of the clerk or should there be a possibility to first answer to the original SED and in addition to an updated one?
V případě, že jsou s těmito činnostmi spojeny nějaké náklady, budou verze aktualizovaných SEDů dostatečné jako důkaz/základ, že jsme jednali v dobré víře na základě žádosti/informací, které byly v době provádění činností platné? 
In case of bared costs of such actions, will the versioning of updated SEDs be enough as a proof / basis we acted in good faith on basis of a request/information valid at time we performed actions?
Potřebujeme mezisektorové dohody, abychom docílili společného chápání a tím také pravidel pro všechny BUCy. 
We need some intersectoral agreements to have common understanding and therefore rules in all BUCs
24/06/2016 
24/06/2016
Změna modelu BPMN, aby byl rozdělen mezi vlastníka případu a protistranu. 
Conversion of BPMN model to split between Case Owner and Counterparty
Naplánovaná aktualizace 
Scheduled for Update
27/09/2016 
27/09/2016
Použití AD-BUC-09 Subproces zamítnutí. 
Usage of AD-BUC-09 Subprocess Reject
Použití AD-BUC-09 Subproces zamítnutí bylo projednáno s členy ad hoc skupin. 
The usage of AD-BUC-09 Subprocess Reject has been discussed with AHG members.
Bylo rozhodnuto, v tomto BUCu se toto nepoužije, ale SED bude odpovídajícím způsobem aktualizován. 
It was decided this will not be used in this BUC but SED will be updated accordingly.
Zaměstnanost, sociální věci a sociální začleňování 
Employment, Social Affairs & Inclusion
Případ životní situace – H_BUC_08 Výměna zdravotnických informací 
EESSI Business Use Case – H_BUC_08 Medical Information
10/2016 2 
10/2016 2
Zaměstnanost, sociální věci & sociální začleňování 
Employment, Social Affairs & Inclusion
Případ životní situace EESSI– H_BUC_08 Výměna zdravotnických informací 
EESSI Business Use Case – H_BUC_08 Medical Information
EESSI – AW_BUC_07a - Oznámení o lékařském potvrzení pro dávky AWOD 
EESSI – AW_BUC_07a - Notification of medical certificate for AWOD benefits
Evropská komise – GŘ pro zaměstnanost, sociální věci a sociální začleňování 
European Commission DG Employment
19. října 
October 19th
Shrnutí diskuse 
Discussion Summary
Vysvětlení 
Clarifications
Existují tři scénáře pro identifikaci institucí: 
There are 3 scenarios for institution identification:
Úředník může potřebovat identifikovat příslušnou protistranu při práci na konkrétním případu, jakožto součást konkrétních obchodních [VM(11]případů užití (BUC). 
A clerk may need to identify the relevant counterparty while working on a specific case, so as part of executing a specific BUC.
V takovém případě běžným postupem je, že úředníka při identifikaci konkrétní instituce (může se jednat i o styčný orgán) povede RINA / vnitrostátní [VM(12]aplikace. 
In this case the standard approach is for the clerk to be guided through RINA/ the National Application towards the identification of a single institution (which can also be a liaison body).
Případně může úředník relevantní instituci nalézt v přístupovém rozhraní pro úředníky (CAI) a následně využít cílené vyhledávání v RINA / vnitrostátní[VM(13] aplikaci. 
Alternatively, the clerk may search for the relevant institution in CAI and then apply a targeted search in RINA/ the National Application
Úředník může mít zájem zobrazit informaci o relevantních institucích podle specifických filtrů / kritérií vyhledávání (mimo svou vnitrostátní[VM(14] aplikaci nebo dokonce mimo konkrétní případ). 
A clerk may wish to visualize information on relevant institutions according to specific filters/ search criteria (outside their national applications or even outside a specific case work).
V takovém případě využije přístupové rozhraní pro úředníky. 
In this case they would refer to the CAI.
Občan může mít zájem vyhledat informace o relevantních institucích podle specifických filtrů / kritérií vyhledávání. 
A citizen may wish to consult information on relevant institutions according to specific filters/ search criteria.
V takovém případě využije přístupové rozhraní pro veřejnost (PAI). 
In this case they would refer to the PAI.
Předběžné mapování atributů definujících instituci jakožto součásti institucionálního repozitáře ve vztahu k těm, které byly dříve použity v hlavním adresáři: všechny původní atributy byly převzaty, přičemž také došlo k přidání nových atributů (návrh souboru ve formátu Excel byl předložen spolu s mapováním atributů mezi centrálním uzlem služeb a hlavním adresářem, dostupné na úložišti Confluence na následující adrese – dokument „Preliminary Mapping Between MMI and CSN“: https://webgate.ec.europa.eu/CITnet/confluence/display/EESSI/EESSI+Institution+Repository+Workspace#IRWW1--442329626). 
Preliminary mapping of attributes defining an institution as part of the Institution Repository to the ones used previously in the Master Directory: all old attributes have been taken over, while also adding new attributes (a draft Excel file was presented with the mapping of attributes between CSN and Master Directory, available in Confluence at the following address – "Preliminary Mapping Between MMI and CSN": https://webgate.ec.europa.eu/CITnet/confluence/display/EESSI/EESSI+Institution+Repository+Workspace#IRWW1--442329626)
Ve všech případech, kde to je relevantní, mapování jurisdikce příslušnosti institucí ve vztahu k právním předpisům koordinace sociálního zabezpečení v institucionálním repozitáři bude provedeno prostřednictvím druhu BUC, neboť každý BUC zahrnuje podrobné informace o článku (článcích) právního předpisu koordinace sociálního zabezpečení, který se na něj vztahuje (které se na něj vztahují). 
In all cases where this is relevant, the mapping of the jurisdiction of the competences of the institutions in relation to the Social Security Coordination Regulations in the Institution Repository will be done via the BUC Type, as every BUC includes detailed info on the article(s) of the SSC regulation that it covers.
Vyhledávání vycházející z těchto článků bude technicky možné na základě informací obsažených v institucionálním repozitáři. 
The search based on the articles will be technically possible based on information contained in the IR.
Validované pokyny 
Validated Directions
Ve vztahu k období platnosti instituce by mělo být možné mít otevřené datum; řešení, jak toho dosáhnout, bude konkrétně popsáno v případech užití 
For institution validity period, it should be possible to have an open end date; the solution on how to handle this will be explicitly specified in the use cases
Řídicí konzole institucionálního repozitáře případů použití (UC) „Přidat uživatele a přiřadit role“ budou odstraněny, neboť tento proces je již pokryt[VM(15] v konzolích pro správu institucionálního repozitáře centrálního uzlu služeb UC „Vytvořit uživatele a přidat role“ 
The " Add users and allocate roles " IR Management Consoles UC will be removed as this process is already captured in the "Create users and allocate roles" CSN IR Administration Consoles UC
Kód použitý v kategorii dávek sociálního zabezpečení „Vymáhat příspěvek“ by měl být nahrazen kódem „Vymáhat“, neboť bude možné i zpětně vymáhat dávky. 
The code used in category of social security benefits “Recovery of contribution” should be replaced by “Recovery” as recovery of benefits is also possible.
Neaktivní instituce by měly být zobrazeny způsobem, který minimalizuje nedorozumění na straně uživatele. 
Inactive institutions should be displayed in a manner that will minimize user confusion.
Kódy použité v oddíle osobní pokrytí jsou kódy, které byly vytvořeny na základě systémů existujících v členských státech, avšak bez správné struktury kódů, identifikace totožných rysů a odstranění nadbytečných kódů a rovněž bez vytvoření seznamu, který by byl platný bez ohledu na drobné změny v právní úpravě členských států (například systém osob samostatně výdělečně činných a systém osob, které zaměstnávají sebe sama; systém samostatně výdělečně činných řemeslníků a obchodníků a systém samostatně výdělečně činných osob v odvětví řemesel, obchodu nebo výroby). 
The codes used in the Personal coverage section are codes that were created based on schemes existing in the Member States but without proper structuring of the codes or identifying the commonalities and removing redundancies and also creating a list that will be valid regardless of very detailed changes in the legislation of the MS (e.g. scheme for self employed persons & scheme for self employee; scheme for self employed craftsmen and tradesmen & scheme for self employed persons engaged in a craft industry, in trading or in a manufactory).
Nemělo by být možné zavádět do tohoto seznamu systémy, které jsou na velmi nízké úrovni a podrobné a velmi specifické pouze pro jeden členský stát (například systém pro pracovníky v telefonních společnostech platný v Lisabonu a Portu), spíše by se mělo jednat o obecnější kategorie. 
It should not be possible to introduce in this list schemes which are very low level and detailed and very specific to only one MS (e.g. Scheme for workers in phone companies in Lisbon and Porto) but rather more generic categories.
Tyto kódy by měly být revidovány, aby používaly logičtější strukturu. 
These codes should be revisited in order to follow a more logical structure.
Návrhy na použití normy ISCO 08 nebyly podpořeny a byla naznačena preference, že by systémy měly zůstat na stejné úrovni. 
The proposals to use the standard ISCO 08 was not supported and the indicated preference was to keep at the level of schemes.
Styčný orgán: styčný orgán by měl být definován jako základní instituce v případě, že jsou identifikační parametry příliš složité na to, aby byly u specifického obchodního[VM(16] případu užití (BUC) v institucionálním repozitáři definovány, nebo pokud není možné identifikační parametry identifikovat (například případy vyrovnání zatížení). 
Liaison body: The Liaison Body should be defined as the default institution in case identification parameters are too complex to be defined in the IR for a specific BUC or in case identification parameters cannot be identified (e.g. load balancing cases).
Výjimečně je možné mít dva nebo více styčných orgánů pro stejný druh BUC, pokud je tentýž BUC nutné adresovat oběma institucím naráz pro dokončení zpracování (někteří účastníci však trvali na tom, že taková situace musí zůstat výjimečná). 
Exceptionally, it is possible to have two or more liaison bodies for the same BUC type, if the same BUC needs to be addressed to both institutions at the same time for complete processing (however some participants insisted that this should stay an exception).
Někteří účastníci žádali, aby v případě, že styčný orgán vystupuje jako základní instituce, byl takto jednoznačně označen (tj. uvedením, že styčný orgán ve skutečnosti funguje jako adresát zastupující vícero jiných institucí, které jsou za standardní situace pro daný případ příslušné, ale které nebudou přímým adresátem, když vlastník případu zašle první SED v případu). 
The participants asked that for the case when a liaison body is acting as a default institution, that this will be clearly marked as such (i.e. indicating that the liaison body is in fact acting as addressee on behalf of multiple other institutions that are normally competent for the case but which will not be the direct addressee when the case owner will send the first SED in the case)
Dle přílohy 4 nařízení č. 987/2009 musí být informace o všech orgánech sociálního zabezpečení (tj. příslušných institucích, příslušných orgánech atd.) 
According to annex 4 of Regulation 987/2009, information on all social security institutions (i.e. competent institutions, competent authorities, etc.)
veřejně přístupné (tj. v institucionálním repozitáři), a to bez ohledu na to, zda se instituce zapojuje do elektronické výměny informací (například ministerstva dohlížející na koordinační aktivity, která však na případu nepracují, instituce, které budou „schovány“ za styčným orgánem). 
must be made public (i.e. in the Institution Repository), regardless if an institution participates or not in the electronic exchange of information (e.g. ministries overseeing coordination activities but not performing case work, institutions which will "hide" behind an liaison body).
Výše uvedená příloha nařízení rovněž podrobně uvádí aspekty, které by měly být uvedeny ve veřejné databázi, například: název instituce v angličtině, příslušná použitelná část právních předpisů koordinace sociálního zabezpečení, druhy dávek, pokrytá rizika, systémy a zeměpisné pokrytí. 
The above mentioned annex from the regulation also details aspects that should be contained in the public data base, such as: the name of the institutions in English, part of the SSC Regulations covered, types of benefits, risks covered, schemes and geographical coverage.
I když v některých případech mohou být tyto údaje kontraproduktivní (je možné, že je občané nebudou snadno chápat), měly by v zájmu dodržování právní úpravy i tak být zadány. 
Even if in some cases these elements might be counterproductive (e.g. maybe not always be easy to grasp by citizens), they should nonetheless be inserted for legislative compliance.
Další údaje lze vložit například pro účely průvodců vyhledáváním institucí občany a úředníky v rámci formulářů, které jsou pro ně vhodnější a uživatelsky vstřícnější, například výběrem několika počátečních filtrů (jako je stát). 
Additional elements can be added for example to guide the search of the institutions by citizens and clerks in forms which are more suitable and user friendly for them, i.e. selecting a few initial filters (like country).
V souladu se schválenou strukturou dokumentace budou následující identifikační parametry institucí: společné identifikační parametry, které budou použity ve všech případech, budou „stát“ a „druh BUC“. 
In accordance with agreed architecture documentation, institution identification parameters: the common identification parameters that will be used in all cases will be "country" and "BUC Type".