ČESKÁ TECHNICKÁ NORMA

ICS 35.240.80 Srpen 2010

Health informatics – Electronic health record communication –
Part 1: Reference model

Informatique de santé – Dossier de santé informatisé et Communication –
Partie 1: Modèle de référence

Medizinische Informatik – Kommunikation von Patientendaten in elektronischer Form –
Teil 1: Referenzmodell

Tato norma je českou verzí evropské normy EN 13606-1:2007. Překlad byl zajištěn Úřadem pro technickou normalizaci, metrologii a státní zkušebnictví. Má stejný status jako oficiální verze.

This standard is the Czech version of the European Standard EN 13606-1:2007. It was translated by Czech Office for Standards, Metrology and Testing. It has the same status as the official version.

Nahrazení předchozích norem

Touto normou se nahrazuje ČSN EN 13606-1 (98 1015) ze září 2007.

Národní předmluva

Změny proti předchozím normám

Proti předchozí normě dochází ke změně způsobu převzetí EN 13606-1:2007 do soustavy norem ČSN. Zatímco ČSN EN 13606-1 ze září 2007 převzala EN 13606-1:2007 vyhlášením ve Věstníku jako ČSN, tato norma ji přejímá překladem.

Souvisící ČSN

ČSN ISO/IEC 2382-8:2001 (36 9001) Informační technologie – Slovník – Část 8: Bezpečnost

ČSN ISO 7498-2:1993 (36 9615) Systémy na spracovanie informácií. Prepojenie otvorených systémov (OSI). Základný referenčný model. Část 2: Bezpečnostná architektúra

ČSN ISO/IEC 10746-1:2000 (36 9526) Informační technologie – Otevřené distribuované zpracování – Referenční model: Přehled

ČSN ISO/IEC 11179-3:2006 (97 9736) Informační technologie – Registry metadat (MDR) – Část 3: Metamodel registru a základní atributy

ČSN EN 12967 (98 2006) (všechny části) Zdravotnická informatika – Architektura služeb – převzatá vyhlášením ve Věstníku

ČSN EN 13940-1 (98 0006) Zdravotnická informatika – Systém pojmů pro zajištění kontinuity péče – Část 1: Základní pojmy

ČSN EN 14822-1:2006 (98 0015) Zdravotnická informatika – Informační komponenty pro všeobecný účel – Část 1: Přehled

ČSN EN 14822-2:2006 (98 0015) Zdravotnická informatika – Informační komponenty pro všeobecný účel – Část 2: Pro neklinické použití

ČSN EN 14822-3:2006 (98 0015) Zdravotnická informatika – Informační komponenty pro všeobecný účel – Část 3: Pro klinické použití

ČSN ISO 639 (01 0182) (všechny části) Kódy pro názvy jazyků

ČSN EN ISO 3166-1:2007 (97 1002) Kódy pro názvy zemí a jejich částí – Část 1: Kódy zemí

ČSN ISO 3166-2:2010 (97 1002) Kódy pro názvy zemí a jejich částí – Část 2: Kód částí zemí

ČSN ISO 3166-3:2000 (97 1002) Kódy pro názvy zemí a jejich částí – Část 3: Kód dříve používaných názvů zemí

ČSN ISO 8601:2005 (97 9738) Datové prvky a formáty výměny – Výměna informací – Zobrazení data a času

ČSN ISO/IEC 8824-1:2010 (36 9632) Abstraktní syntaxe způsobu zápisu jedna (ASN.1)“ Specifikace základního způsobu zápisu

ČSN ISO/IEC 11404:1999 (36 9151) Informační technologie – Programovací jazyky, jejich prostředí a softwarové rozhraní – Jazyk – nezávislé typy dat

Upozornění na národní poznámky

Malé písmeno „s“ u anglické zkratky vyjadřuje její množné číslo, například: COMPOSITIONs, ENTRYs FOLDERs, RECORD_COMPONENTs apod.

Pro účely této normy je anglický termín „federated“ přeložen jako federovaný. Federovaný model elektronického zdravotního záznamu integrované péče je model systému sdíleného EHR, kdy je EHR integrované péče sestaven v reálném čase, tedy když je požadován, na rozdíl od konsolidovaného modelu elektronického zdravotního záznamu integrované péče, kdy je EHR integrované péče sestaven při jeho tvorbě a aktualizaci.

Anglický termín „encounter“ je přeložen jako (osobní) kontakt. Anglický termín „Communication“ se překládá jako přenos, sdílení nebo komunikace.

Zkratka N/A znamená v českém významu žádný/jakýkoli.

Vypracování normy

Zpracovatel: Ing. Vladimír Pračke, IČ 40654419

Technická normalizační komise: TNK 20 Informační technologie

Pracovník Úřadu pro technickou normalizaci, metrologii a státní zkušebnictví: Ing. Petr Wallenfels

EVROPSKÁ NORMA EN 13606-1
EUROPEAN STANDARD
NORME EUROPÉENNE
EUROPÄISCHE NORM Únor 2007

ICS 35.240.80 Nahrazuje EN 13606-1:2000

Zdravotnická informatika – Přenos elektronického zdravotního záznamu –
Část 1: Referenční model

Health informatics – Electronic health record communication –
Part 1: Reference model 

Tato evropská norma byla schválena CEN 2006-12-15.

Členové CEN jsou povinni splnit Vnitřní předpisy CEN/CENELEC, v nichž jsou stanoveny podmínky, za kterých se musí této evropské normě bez jakýchkoliv modifikací dát status národní normy. Aktualizované seznamy a bibliografické citace týkající se těchto národních norem lze obdržet na vyžádání v Řídicím centru nebo u kteréhokoliv člena CEN.

Tato evropská norma existuje ve třech oficiálních verzích (anglické, francouzské, německé). Verze v každém jiném jazyce přeložená členem CEN do jeho vlastního jazyka, za kterou zodpovídá a kterou notifikuje Řídicímu centru, má stejný status jako oficiální verze.

Členy CEN jsou národní normalizační orgány Belgie, Bulharska, České republiky, Dánska, Estonska, Finska, Francie, Irska, Islandu, Itálie, Kypru, Litvy, Lotyšska, Lucemburska, Maďarska, Malty, Německa, Nizozemska, Norska, Polska, Portugalska, Rakouska, Rumunska, Řecka, Slovenska, Slovinska, Spojeného království, Španělska, Švédska a Švýcarska.

CEN

Evropský výbor pro normalizaci

European Committee for Standardization

Comité Européen de Normalisation

Europäisches Komitee für Normung

Řídicí centrum: rue de Stassart 36, B-1050 Brusel

© 2007 CEN Veškerá práva pro využití v jakékoli formě a jakýmikoli prostředky Ref. č. EN 13606-1:2007 E
jsou celosvětově vyhrazena národním členům CEN.

Předmluva

Tento dokument (EN 13606-1:2007) byl připraven technickou komisí CEN/TC 251 „Zdravotnická informatika“, jejíž sekretariát zajišťuje NEN.

Tato evropská norma musí dostat statut národní normy, buď publikováním identického textu, nebo schválením, nejpozději do srpna 2007 a národní normy, které s ní nejsou kompatibilní, musí být nejpozději do srpna 2007 staženy.

Tento dokument nahrazuje ENV 13606-1:2000.

Tato několikadílná norma se společným názvem Zdravotnická informatika – Přenos elektronického zdravotního záznamu se skládá z následujících částí:

Část 1: Referenční model

Část 2: Specifikace pro výměnu archetypů

Část 3: Odkazy na archetypy a seznamy termínů

Část 4: Bezpečnost

Část 5: Zprávy pro výměnu

V souladu s Vnitřními předpisy CEN/CENELEC jsou zavázány tuto normu implementovat národní normalizační orgány následujících zemí: Belgie, Bulharska, České republiky, Dánska, Estonska, Finska, Francie, Irska, Islandu, Itálie, Kypru, Litvy, Lotyšska, Lucemburska, Maďarska, Malty, Německa, Nizozemska, Norska, Polska, Portugalska, Rakouska, Rumunska, Řecka, Slovenska, Slovinska, Spojeného království, Španělska, Švédska a Švýcarska.

Obsah

Strana

Úvod 9

1 Předmět normy 25

2 Citované normativní dokumenty 25

3 Termíny a definice 25

4 Zkratky 29

5 Shoda (normativní) 30

5.1 Shoda systému EHR 30

5.2 Shoda členského státu 31

6 Referenční model 31

6.1 Index k balíkům 31

6.2 Balík: EXTRACT 32

6.3 Balík: DEMOGRAPHICS Package 42

6.4 Balík: SUPPORT Package 48

6.5 Primitivní datové typy 54

Příloha A (informativní) Profil UML 56

Příloha B (informativní) Vztah k ostatním normám 58

Příloha C (informativní) Klinický příklad 69

Příloha D (informativní) Mapování na prohlášení požadavku 83

Bibliografie 89

Seznam obrázků a tabulek

Strana

Obrázek 1 – Schéma hierarchie EHR Extrakt (část 1) 12

Obrázek 2 – Schéma hierarchie EHR Extrakt (část 2) 12

Obrázek 3 – UML diagram třídy balíku Extrakt 33

Obrázek 4 – UML diagram třídy demografického balíku 43

Obrázek 5 – UML diagram třídy balíku podpory 49

Obrázek 6 – UML diagram třídy balíku primitiv 55

Tabulka 1 – Hlavní komponenty hierarchie referenčního modelu EHR Extrakt 11

Tabulka B.1 – Mapování CONTSYS na EN 13606-1 59

Tabulka B.2 – Mapování HISA na EN 13606-1 60

Tabulka B.3 – Mapování položky dokumentu XDS na EN 13606-1 61

Tabulka B.4 – Mapování podřízené sady XDS na EN 13606-1 62

Tabulka B.5 – Mapování složky XDS na EN 13606-1 62

Tabulka B.6 – Mapování ENV 13606-1 na EN 13606-1 62

Úvod

Celkovým cílem této evropské normy je definovat rigorózní a stabilní informační architekturu pro přenášení celého elektronického zdravotního záznamu nebo jeho části (Electronic Health Record, EHR) o jednotlivém subjektu péče (pacientu). Tím je podporována interoperabilita systémů a komponent, které potřebují přenášet (přistupovat k, přenést, přidat nebo modifikovat) EHR data prostřednictvím elektronických zpráv nebo jako distribuované objekty:

• zachovávající původní klinický význam určený autorem;

• zvažující důvěrnost těchto dat, jak byla zamýšlena autorem a pacientem.

Účelem této evropské normy není specifikovat interní architekturu nebo návrh databáze systému nebo komponent EHR, a také není jejím účelem stanovit druhy klinických aplikací, které by mohly vyžadovat EHR data nebo k nim přispívat v jednotlivých nastaveních, oblastech nebo specializacích. Z tohoto důvodu se zde navrhovaný informační model nazývá EHR Extrakt, který by mohl být použit pro definici zprávy, XML dokumentu nebo schématu, nebo rozhraní objektu. Informační model v této evropské normě je ISO RM-ODP informačním stanoviskem EHR Extrakt.

Tato evropská norma považuje EHR za stabilní průběžný a potenciálně multipodnikový a nadnárodní záznam o zdraví a poskytnutí péče, týkající se jednotlivého subjektu péče (pacienta), vytvořený a uložený v jednom nebo více fyzických systémech za účelem informování budoucího poskytovatele zdravotní péče subjektu a poskytnutí lékařsko-právního záznamu o péči, která byla poskytnuta. Zatímco služba nebo systém EHR bude muset interagovat s mnoha dalšími službami nebo systémy poskytujícími terminologii, lékařské znalosti, směrnice, pracovní toky, bezpečnost, registry osob, účtování atd., tato evropská norma se týká těchto oblastí pouze, je-li samotným EHR vyžadováno nějaké trvalé sledování takových interakcí a vyžaduje v referenčním modelu specifické vlastnosti pro povolení jejich přenášení.

Tato evropská norma může nabídnout praktický a užitečný příspěvek k návrhu EHR systémů, ale bude především realizována jako obvyklá sada externích rozhraní nebo zpráv vybudovaná na jinak heterogenních klinických systémech.

Technický přístup

Tato evropská norma čerpá z praktických zkušeností, získaných při implementaci předcházející předběžné evropské normy ENV 13606, dalších norem a specifikací týkajících se EHR, komerčních systémů a předváděcích pilotních instalací pro přenášení celých elektronických zdravotních záznamů pacientů nebo jejich částí, a z patnácti let výzkumné činnosti v této oblasti. Tato evropská norma staví na ENV 13606 a aktualizuje ji, aby byla rigoróznější a úplnější, aby vyhověla nově identifikovaným požadavkům, aby začlenila robustní prostředky aplikace generických modelů na jednotlivé klinické oblasti a aby umožnila komunikaci s použitím zpráv HL7 verze 3. Pro podporu implementátorů existujících konformních systémů je rovněž poskytnuto mapování z existující předchozí normy. Technický přístup k vytvoření této evropské normy vzal v úvahu několik současných oblastí požadavků.

1. Kromě tradiční na zprávách založené komunikaci mezi izolovanými klinickými systémy bude Elektronický zdravotní záznam v některých případech implementován jako middleware komponenta (server záznamů) s použitím distribuované objektové technologie a/nebo webových služeb.

2. „Zákazníky“ takových záznamových služeb nebudou jenom další systémy elektronických zdravotních záznamů, ale také jiné služby middleware jako komponenty bezpečnosti, workflow systémy, služby pro varování a podporu rozhodování a další agenti lékařských znalostí.

3. Existuje široký mezinárodní zájem o tuto činnost a tato evropská norma byla společně navržena prostřednictvím CEN a ISO za významného přispění mnoha členských zemí.

4. Za důležitý cíl bylo považováno mapování na HL7 verze 3, aby byla v rámci prostředí HL7 verze 3 umožněna shoda s touto evropskou normou.

5. Vstupy z výzkumu a vývoje, z kterých ENV 13606 vycházela, od roku 1999 pokročily a v úvahu byly vzaty důležité nové příspěvky v této oblasti. Jedním takovým příkladem je nadace openEHR, která integruje procesy výzkumu a vývoje v Evropě a Austrálii.

Vzhledem k různorodosti nasazených systémů EHR stanovila tato evropská norma většinu vlastností komunikace EHR jako spíše volitelnou než povinnou. Nicméně se vyžaduje určitý předepsaný stupeň, který by měl zajistit, aby byly EHR Extrakty bezpečně zpracovatelné systémem příjemce EHR, o čemž svědčí povinné vlastnosti v mezích modelů v částech 1, 2 a 4 této řady a seznamy normativních pojmů (definované v části 3 této řady).

Tato evropská norma bude v praxi obvykle adoptována vedle dalších norem zdravotnické informatiky, které definují specifické aspekty reprezentace zdravotnických dat. Příloha B objasňuje, jak může být tato evropská norma použita vedle klíčových doplňkových norem, zahrnujících Referenční informační model HL7 verze 3 (RIM), EN 14822-1, EN 14822-2, EN 14822-3, CEN/TS 14822-4 (GPIC), prEN 12967 (HISA) a prEN13940 (CONTSYS).

Přístup dvojitého modelu

Úkolem pro interoperabilitu EHR je navrhnout zobecněný přístup k reprezentaci každého možného druhu struktury dat zdravotního záznamu konzistentním způsobem. Je nutné se postarat o záznamy vznikající v libovolné profesi, specializaci nebo službě a současně připustit, že soubory klinických dat, významné soubory, šablony atd. vyžadované různými oblastmi zdravotní péče budou různorodé, komplexní a budou se často měnit s pokrokem klinické praxe a lékařských znalostí. Tento požadavek je součástí obecně uznávané výzvy zdravotnické informatiky k řešení sémantické interoperability.

Přístup přijatý touto evropskou normou odlišuje Referenční model, definovaný v této evropské normě a používaný pro reprezentaci generických vlastností informací zdravotního záznamu, a Archetypy (přizpůsobené modelu archetypů definovaném v části 2 této řady), které představují metadata použitá k definování vzorů pro specifické charakteristiky klinických dat, které představují požadavky každé jednotlivé profese, specializace nebo služby. 

Referenční model představuje globální charakteristiky komponent zdravotního záznamu, tak jak jsou sestaveny, a kontextovou informaci nutnou ke splnění požadavků etických, právních a požadavků týkajících se původu. Tento model definuje množinu tříd, tvořících generické stavební bloky EHR. Vyjadřuje stabilní charakteristiky elektronického zdravotního záznamu a byl by začleněn v distribuovaném (federovaném) prostředí EHR jako specifické zprávy nebo rozhraní (dle specifikace v části 5 této řady).

Tento generický informační model je nutné doplnit formální metodou komunikace a sdílení organizační struktury předdefinovaných tříd částí EHR, odpovídající souborům komponent záznamu vytvořeným v určitých klinických situacích. Jsou to efektivně předem uspořádané kombinace pojmenovaných RECORD_COMPONENT hierarchií, které jsou odsouhlaseny v rámci komunity pro zajištění interoperability, konzistence dat a kvality dat.

Archetyp představuje formální definici stanovených kombinací stavebnicových tříd definovaných v Referenčním modelu pro určité klinické oblasti nebo organizace. Archetyp je formálním vyjádřením odlišného pojmu na úrovni oblasti, vyjádřený formou omezení vzhledem k datům, jejichž instance vyhovují referenčnímu modelu. Pro EHR_Extract, tak jak je definovaný v této evropské normě, specifikuje instance archetypu (a efektivně omezuje) konkrétní hierarchii podtříd RECORD_COMPONENT, definuje nebo omezuje jejich názvy a další příslušné hodnoty atributů, volitelnost a multiplicitu v libovolném bodě v hierarchii, typy dat a rozsahy hodnot, které mohou datové hodnoty ELEMENT nabývat, a další omezení.

Tato evropská norma připouští, že archetypy by mohly být v budoucnu použity k podpoře přenosu mezi některými EHR systémy nebo by mohly být použity jako znalostní specifikace externími rozhraními některých EHR systémů při mapování částí EHR na EHR_EXTRACT, nebo by vůbec nemohly být použity mezi některými EHR systémy. Použití archetypů je proto touto evropskou normou podporováno, ale není závazné. Specifikace pro přenášené archetypy je definována v části 2 této řady.

Základy požadavků této evropské normy

Z počátku let devadesátých se respektovalo, že pro komunikaci libovolných zdravotních záznamů mezi systémy je vyžadována genericky použitelná reprezentace, a v Evropě to vedlo k sérii R&D projektů sponzorovaných EU a dvěma generacím CEN norem zdravotnické informatiky před touto normou. Tyto projekty a normy se snažily definovat generické charakteristiky EHR informací a včlenit je do informačních modelů a modelů zpráv, které by mohly poskytovat standardní rozhraní mezi klinickými systémy. Vizí takové snahy bylo umožnit různorodým a odborným klinickým systémům výměnu celých osobních EHR nebo jejích částí standardním způsobem, který může rigorózně a všeobecně reprezentovat datové hodnoty a související organizaci informací v jakémkoliv vznikajícím systému. Doplňkovým cílem bylo vyjít vstříc vyvíjející se povaze lékařských znalostí a vrozené rozmanitosti klinické praxe.

Během tohoto období proběhlo mnoho průzkumů požadavků uživatelů a společností na EHR, které se snažily překlenout informační potřeby různorodých specializací napříč primární, sekundární a terciární péčí, mezi profesemi a napříč zeměmi. Tyto požadavky byly extrahovány a analyzovány expertními skupinami, především v Evropě, aby se identifikovaly základní informace, které je nutné umístit v rámci informační architektury EHR pro:

• věrné zachycení původního významu zamýšleného autorem záznamu nebo sady záznamů;

• poskytnutí rámce vyhrazeného potřebám odborníků a firem k analýze a interpretaci EHRs na individuálním nebo populačním základě;

• začlenění nezbytných lékařsko-právních pojmových konstrukcí k podpoře bezpečného a relevantního přenosu EHR záznamů mezi odborníky pracujícími na stejných nebo různých pracovištích.

Tato aktivita zahrnuje projekty GEHR, EHCR-SupA, Synapses, I4C anNora a aktivitu SPRI. Tyto publikace nejdůležitějších požadavků jsou uvedeny v Bibliografii. Tyto požadavky byly nedávno konsolidovány na mezinárodním stupni v rámci technické specifikace ISO, ISO/TC 18308.

V tomto Referenčním modelu nejdůležitější kontextuální požadavky EHR na takovou věrohodnost souvisejí se sadou tříd logických stavebních bloků, s vhodnými atributy navrženými pro každou úroveň v hierarchii EHR Extrakt. ISO/TS 18308 byla přijata jako referenční sada požadavků pro podporu vlastností v rámci tohoto Referenčního modelu komunikace EHR a mapování těchto požadavků na pojmové konstrukce v Referenčním modelu je uvedeno v příloze D.

Přehled hierarchie EHR Extrakt záznamů

Informace ve zdravotním záznamu jsou přirozeně hierarchické. Klinická pozorování, úvahy a záměry mohou mít jednoduchou nebo složitější strukturu. Obecně jsou uspořádány podle záhlaví a obsaženy v „dokumentech“ jako konzultační poznámky, dopisy a zprávy. Tyto dokumenty jsou obvykle založeny ve složkách a pacient může mít v rámci zdravotnické společnosti více než jednu složku (například lékařskou, ošetřovatelskou, porodní).

Referenční model EHR Extrakt potřebuje vyjádřit tuto hierarchickou strukturu a organizaci a přitom vyhovět zveřejněným požadavkům, aby věrně odrážel původní klinický kontext a bylo zajištěno uchování významu v případě přenosu záznamů mezi heterogenními klinickými systémy. Model proto formálně dále člení hierarchii EHR na části, které poskytují konzistentní mapování na způsoby, jakými jsou individuální EHRs uspořádány v rámci heterogenních EHR systémů.

Tyto části jsou shrnuty v tabulce 1 dále.

Tabulka 1 – Hlavní komponenty hierarchie referenčního modelu EHR Extrakt 

EHR_EXTRACT obsahuje data EHR ve formě COMPOSITIONs, volitelně uspořádané dle hierarchie FOLDER.

COMPOSITIONs obsahují ENTRYs, volitelně obsažené v rámci hierarchie SECTION.

ENTRYs obsahují ELEMENTs, volitelně obsažené v rámci hierarchie CLUSTER.

[image]

Obrázek 1 – Schéma hierarchie EHR Extrakt (část 1)

[image]

Obrázek 2 – Schéma hierarchie EHR Extrakt (část 2)

Popis hlavních tříd referenčního modelu

EHR_EXTRACT

EHR_EXTRACT je použita pro reprezentaci části informací zdravotního záznamu nebo všech informací zdravotního záznamu extrahovaných ze systému poskytovatele EHR pro účely komunikace s příjmem EHR (kterým může být jiný EHR systém, repositář klinických dat, klientská aplikace nebo služba middleware jako například komponenta elektronické směrnice) a podpory přesného začlenění komunikovaných dat v přijímajícím systému.

Třída EHR_EXTRACT obsahuje atributy k identifikaci subjektu péče, k němuž tento záznam náleží, k identifikaci systému poskytovatele EHR, z kterého byl získán, a k identifikaci identifikátoru EHR tohoto subjektu v tomto systému, a volitelně k identifikaci agenta, odpovědného za vytvoření EHR.

EHR_EXTRACT obsahuje data EHR ve třech částech.

1. sada COMPOSITIONs;

2. volitelně adresáře FOLDERs, které poskytují seskupení a uspořádání COMPOSITIONs na vyšší úrovni;

3. volitelně sadu demografických deskriptorů pro každého z jedinců, organizací, zařízení nebo SW komponent identifikovaných v rámci 1) a 2). Tento přístup umožňuje, aby na tyto entity bylo jedinečně odkazováno prostřednictvím identifikátoru v rámci základní části EHR, bez nutnosti pokaždé opakovat popisné detaily, a rovněž zajišťuje, že každý EHR_EXTRACT lze izolovaně interpretovat, pokud nemá přijímající systém přístup k službám potřebným k dekódování identifikátorů entit použitých poskytovatelem EHR.

V části 4 této řady je definován formální mechanismus pro začlenění politiky přístupu k informaci v rámci EHR_EXTRACT. Cílem je informovat EHR Příjemce o požadavcích subjektu péče a poskytovatele zdravotní péče o tom, jak má být zacházeno s budoucími žádostmi o přístup k datům.

EHR_EXTRACT rovněž obsahuje přehled filtračních nebo výběrových kritérií, pomocí nichž byla tato třída EHR_EXTRACT vytvořena. To může nebo nemusí odpovídat přímo kritériím v EHR Požadavku a poskytuje záznam druhu podmnožiny, kterou tato EHR_EXTRACT představuje vůči celkovému EHR, který udržuje EHR Poskytovatel. To by mohlo být důležité, pokud je EHR_EXTRACT udržována netknutá EHR Poskytovatelem nebo EHR Příjemcem a následně je uskutečněn přístup agenty, kteří nemají přístup k původnímu EHR požadavku. Například tato třída může specifikovat, zda je tato EHR_EXTRACT omezena na nejaktuálnější verzi každé COMPOSITION (jak je vyžadováno pro účely většiny klinické péče) nebo zda obsahuje všechny historické verze (které mohou být vyžadovány pro právní účely). Mohla by určovat maximální úroveň citlivosti dat (naznačující, že mohou existovat data citlivější než tato úroveň a že byla odfiltrována) nebo že pro omezení její celkové velikosti byly vyloučeny multimediální objekty. Pokud byla EHR_EXTRACT vytvořena výběrem jednotlivých kategorií klinických dat (například pouze laboratorních dat), potom toto může být indikováno prostřednictvím seznamu archetypů, které byly zahrnuty do výběrových kritérií. Existuje možnost volby zahrnout dodatečná kritéria (vyjádřená jako řetězce); to může být použito k poskytnutí dalších člověkem čitelných informací o této třídě EHR_EXTRACT nebo to může být použito pro místně odsouhlasené počítačem interpretovatelné omezující informace.

RECORD_COMPONENT

Třídy hlavních stavebních bloků, které jsou použity pro vybudování hierarchie dat EHR v rámci EHR_EXTRACT jsou druhem RECORD_COMPONENT. To je abstraktní třída, nadřazená třída pro všechny konkrétní uzly v hierarchii EHR: FOLDER, COMPOSITION, SECTION, ENTRY, CUSTER, ELEMENT a rovněž nadřazená třída pro dva další uzly abstraktní třídy: CONTENT a ITEM.

RECORD_COMPONENT definuje informační vlastnosti, které jsou společné všem těmto stavebním blokům, včetně:

• jedinečného identifikátoru, který byl tomuto EHR uzlu vydán EHR systémem, ve kterém byl poprvé potvrzen (jeho výchozí EHR systém); ostatní držitelé této RECORD_COMPONENT potřebují uchovat tuto hodnotu atributu pro zajištění, že jakékoliv následné extrakty jsou vždy konzistentně identifikovány;

• klinického názvu, použitého v jeho výchozím EHR systému k označení této části EHR dat;

• volitelně normalizovaného kódovaného pojmu, na nějž byl název namapován pro podporu sémantické interoperability ekvivalentních instancí EHR, dokonce i když jim byly dány různé klinické názvy různými EHR systémy;

• identifikátoru uzlu archetypu, kterému tato RECORD_COMPONENT vyhovuje, jenž bude použit EHR systémy používajícími archetypy, nebo pokud byly archetypy použity při mapování dat do formátu EHR_EXTRACT;

• kódu citlivosti a odkazů na politiky řízení přístupu, které by měly být použity EHR Příjemcem pro řízení budoucího přístupu k datům;

• podpory pro Spojení mezi libovolnými Komponentami záznamu.

Pří generování EHR_EXTRACT, která odpovídá této evropské normě, by mohl systém poskytovatele EHR v některých situacích potřebovat zavést RECORD_COMPONENT do hierarchie, která nemá přímý soulad s žádnými původními daty v EHR systému. Syntetizovaný atribut třídy RECORD_COMPONENT povoluje exportujícímu EHR systému poskytovatele indikovat, že RECORD_COMPONENT byla pro tento účel vytvořena v rámci EHR_EXTRACT.

Položky zdravotních záznamů často odkazují na další již existující položky a začleňují je jako „kopie“. Častým příkladem toho je propouštěcí zpráva, která by mohla zahrnovat kopie několika částí záznamu o pobytu hospitalizovaného pacienta jako například okolnosti přijetí, hlavní diagnózy, základní zákroky a léčebné postupy. Ve většině případů vyžaduje EHR_EXTRACT, aby obsahoval tyto odkazované RECORD_COMPONENTS explicitně jejich hodnotou tak, aby každá COMPOSITION mohla být interpretována EHR Příjemcem. Z lékařsko-právního hlediska je však také důležité sdělit, že tyto položky jsou kopiemi a že pocházejí z odlišné části EHR daného subjektu. Jsou-li data kopií, může být pro reprezentaci rc_id původní rodičovské RECORD_COMPONENT použit volitelný atribut original_parent_ref.

Libovolná RECORD_COMPONENT může zahrnovat auditní data o tom, kdy a kým byla potvrzena ve svém výchozím EHR systému. Každá revidovaná verze RECORD_COMPONENT může dokumentovat status verze, důvod revize a identifikátor předcházející verze. Z důvodů ochrany dat se však obyčejně doporučuje, aby předchozí (chybné) verze EHR nebyly sdělovány jako část normální klinické společné péče, ale pouze za okolností, kdy je přenos EHR prováděn z právních důvodů.

Je důležité, aby byla každá RECORD_COMPONENT jedinečně a konzistentně identifikována napříč vícenásobných EHR_EXTRACTS tak, aby odkazy na ně nebo mezi nimi zůstaly platné. Příklady takových odkazů jsou sémantické linky, revize a atestace. Atribut rc_id je datovým typem Instance Identifier (II), který začleňuje ISO OID; II je v současné době považován za mezinárodně nejvhodnější datový typ pro trvalé identifikátory, u kterých je vyžadováno, aby byly globálně jedinečné. Je nepravděpodobné, že současné EHR systémy budou mít stávající primární klíče nebo interní identifikátory, které přímo odpovídají globálně jedinečným instancím II. Nicméně systém EHR Poskytovatele, kterému byl vydán organizační OID, by mohl používat své interní odkazy pro vytvoření jedinečných local extensions k tomuto OID a tímto vytvořit globálně jedinečné hodnoty rc_id.

Alternativně by mohl vytvořit zcela nová rc_ids a udržovat záznam jejich mapování na každý interní identifikátor tak, aby jakékoliv budoucí EHR_EXTRACTS, které vytvoří, používaly konzistentní hodnoty rc_id. Je rovněž nepravděpodobné, že systém EHR Příjemce bude schopen použít obdržené hodnoty rc_id jako své interní primární klíče pro data, protože každá databáze používá mírně odlišný přístup ke generování a používání takových klíčů. EHR Příjemce by proto také mohl potřebovat udržovat záznam mapování importovaných hodnot rc_id na své primární klíče, aby budoucí odkazy na tyto RECORD_COMPONENTS mohly být náležitě spárovány, a může vytvořit EHR_EXTRACTs, které znovu použijí tyto hodnoty rc_id na exportovaná data. Alternativní přístup pro EHR systémy je explicitně uložit hodnoty rc_id společně s klinickými daty a toto považovat za část dat „užitečného zatížení“ a nepokoušet se je používat také jako primární klíče. Mělo by rovněž být poznamenáno, že rc_id nefunguje jako ekvivalent primárního klíče v rámci EHR_EXTRACT, tj. zdvojené hodnoty rc_id jsou povoleny, pokud každá instance skutečně odkazuje na stejnou část klinických dat v rámci systému EHR Poskytovatele. 

FOLDER

Tato třída je používána k reprezentaci organizací EHR dat na nejvyšší úrovni v rámci EHR_EXTRACT, například k seskupení COMPOSITIONs podle příhody, pečovatelského týmu, klinické specializace, klinického stavu nebo časového intervalu. Mezinárodně je tento druh organizační struktury používán variabilně: v některých podnicích a systémech je pojem pořadače (folder) považován za neformální rozdělování celkového zdravotního záznamu na oddíly; v jiných by mohl představovat významnou právní část EHR, týkající se služeb, poskytovaných podnikem nebo týmem.

V EHR_EXTRACT jsou FOLDERs volitelnou hierarchií. FOLDERs mohou obsahovat jiné FOLDERs pro vytvoření úplného adresářového systému a mohou zahrnovat jakékoliv příslušné informace o jejich svěření nebo revizi v rámci systému EHR Poskytovatele. FOLDERs odkazují na COMPOSITIONs pomocí seznamu jedinečných identifikátorů spíše než aby je fyzicky obsahovaly. To umožňuje každé COMPOSITION objevit se ve více než jedné FOLDER, což je požadavek, který indikovali někteří dodavatelé a jurisdikce.

V některých situacích by FOLDERs mohly být specificky vytvořeny pro uspořádání EHR_EXTRACT nebo obsahují pouze vybranou podmnožinu dat v odpovídající složce v systému EHR poskytovatele. Za takových okolností nebudou mít FOLDERs v rámci EHR_EXTRACT přímou shodu s FOLDERs v přispívajícím systému EHR poskytovatele, tj. budou muset být syntetizovány.

FOLDER může být použit pro seskupování množiny COMPOSITIONS zahrnující jednotlivé záznamy vytvořené členy týmu více odborníků během jediného klinického kontaktu. V situacích jako tato, kdy FOLDER představuje konečné období péče, může být atestován. Tento přístup by měl být použit pro sdělení, že obsah FOLDER představuje úplný záznam daného období péče. To rovněž EHR Příjemci indikuje, že dodatečné COMPOSITIONS by neměly být k této FOLDER přidávány.

Protože systémy složek jsou v rámci systémů EHR používány variabilně, nemůže tato evropská norma předepisovat, jak by s nimi mělo být zacházeno v rámci systému EHR Příjemce: tj. nevyžaduje, aby je EHR Příjemce explicitně používal v rámci svého systému EHR. Pokud však byla FOLDER atestována, měla by být neporušená kopie této informace ponechána pro budoucí odkaz a možnou další komunikaci.

COMPOSITION

COMPOSITION představuje sadu RECORD_COMPONENTS sestavených (vytvořených) během klinické porady týkající se jednoho uživatele nebo během porady o záznamu dokumentace, pro zapsání v rámci jednoho EHR. Obvyklé příklady zahrnují konzultační poznámky, poznámky k postupu, hlášení nebo dopis, vyšetřovací zprávu, lékařský předpis a soubor pozorování u lůžka při ošetřování. COMPOSITION dokládá datum a čas nebo interval vizit a jurisdikci, ve které byly záznamy sestaveny.

Sestavovatelem je agent (strana, zařízení nebo software) zodpovědný za vytvoření, syntetizování nebo uspořádání informací, které jsou zapsány do EHR. Tento agent přebírá odpovědnost za své začlenění do tohoto EHR, i když není jeho původcem ani jeho potvrzovatelem. Obsah COMPOSITION je primárně přisuzován této osobě. Zda je nebo není sestavovatel po revizi změněn, je volitelné. Obecně budou aplikace používat název sestavovatele k označení dat COMPOSITION při použití pro klinickou péči. Mohou nastat situace, kdy nebude existovat jediný hlavní sestavovatel (například telekonzultace více odborníků nebo porada k případu); v takových případech by nemusela být role sestavovatele formálně stanovena, ačkoli je uveden každý účastník a klinická role: uvedení sestavovatele proto není povinné.

Je zajištěno, aby COMPOSITION zahrnovala podrobnosti a lokality všech účastníků zapojených do klinického kontaktu nebo porady o záznamu dokumentace. Někteří z nich se mohou zúčastnit z různých lokalit (například telefonicky nebo prostřednictvím videokonzultace).

COMPOSITION je třída hlavního kontejneru pro EHR data v rámci samotného extraktu, která zajišťuje použití konzistentní hierarchie schránky v rámci všech Extraktů: EHR_EXTRACT obsahuje sadu COMPOSITIONs společně s auditními daty o potvrzení každé z nich v rámci systému EHR Poskytovatele. COMPOSITION je vždy použita pro sdělení o aktualizacích verze mezi EHR systémy, dokonce i když současná aktualizace odkazuje na části této COMPOSITION. Je-li nutné přenést vícenásobné verze EHR dat v rámci jedné EHR_EXTRACT, bude to formou sady odlišných COMPOSITIONs, z nichž každá odkazuje na předchozí verzi, a společně odkazují na identifikátor sady verzí.

Každá COMPOSITION rovněž volitelně prokazuje jakékoliv atestace (například digitální Podpis(y)), které se této třídy nebo jakéhokoliv jejího obsahu týkají.

Contribution Příspěvek je sada COMPOSITIONs potvrzených jedním uživatelem v jednom časovém okamžiku v EHR jednoho subjektu péče. Některé klinické aplikace zahrnují komplexní obrazovky schopné prezentovat vícenásobné části EHR současně (například prostřednictvím tabulkových podoken). Při ukládání obrazovky by mohl uživatel vlastně potvrdit data pro více než jednu část pacientova EHR (například přidání nové konzultační poznámky a revize léčebného záznamu uloženého někde jinde v EHR). Příspěvek odkazuje na všechny změny a aktualizace potvrzené v tomto EHR během relace potvrzovatele. Všechny COMPOSITIONs, tvořící jeden Příspěvek, mohou být hromadně identifikovány poskytnutím společné hodnoty pro atribut contribution_id.

SECTION

Položky záznamu týkající se jednotlivé klinické porady jsou obvykle seskupeny pod záhlavími, která představují fáze nebo podbody v rámci klinického kontaktu, nebo pomáhají s uspořádáním a navigací. Klinická záhlaví obvykle vyjadřují průběh klinické práce během porady o péči a mohly by rovněž vyjadřovat hlavní procesy usuzování autora. Mnoho výzkumů ukázalo, že záhlaví jsou rozdílně používána rozdílnými odbornými skupinami a spe-
cializacemi a že záhlaví nejsou používána dostatečně konzistentně, aby podporovala bezpečné automatické zpracování EHR. Jsou proto v této evropské normě považována za volitelný (neformální) kontejnment pro navigaci, filtrování a čitelnost pro člověka.

SECTIONs mohou být používány pro znázornění hierarchie kontejnmentu klinických záhlaví použitých v rámci systému EHR Poskytovatele k seskupení a uspořádání položek v rámci COMPOSITION. Každá SECTION může obsahovat další SECTIONs a/nebo ENTRYs.

ENTRY

ENTRY představuje třídu kontejneru pro datovou strukturu ITEM, která představuje informace získané a zazna-
menané pro jednotlivé pozorování nebo soubor pozorování (sada nebo časová řada), jednotlivé klinické prohlášení jako například část pacientovy historie nebo závěr či tvrzení, nebo jednotlivou činnost, která může být zamýšlena nebo je právě vykonávána. Třída ENTRY spojuje tuto strukturu ITEM se sadou kontextových atributů pro usnadnění bezpečné interpretace:

• informace v ENTRY může být o někom jiném než o pacientovi (například příbuzný): ENTRY definuje subjekt informace;

• informace v ENTRY může být poskytnuta určitým jedincem nebo je mu přisuzována: ENTRY definuje poskytovatele informace;

• ostatní účastníci by mohli potřebovat být spojováni s určitou ENTRY;

• ENTRY může představovat vyvíjející se status klinického úkonu (například požadováno, provedeno, hlášeno, zrušeno) a může volitelně nést identifikátor, který ji spojuje se systémem průběhu práce;

• ENTRY může používat příznak oznamující EHR Příjemci, že datová struktura obsahuje určitou indikaci nejistých nálezů nebo názorů, a že je nutné při použití dat pro automatizované zpracování dávat pozor.

ENTRY obsahuje datovou strukturu představovanou použitím CLUSTERS a ELEMENTS. Je důležité poznamenat, že ENTRY nemůže obsahovat další ENTRYs. Sada kontextů definovaná na úrovni ENTRY (například subjekt informace) platí pro celou datovou strukturu a nelze ji potlačit.

ITEM, CLUSTER a ELEMENT

ITEM může představovat jak aktuální data popisující pozorování, závěr nebo činnost, tak volitelně podrobnosti popisující vyšetřovací metodu, pacientův fyzický stav, nebo podrobnosti podporující proces klinického uvažování jako je odkaz na elektronický návod, systém podpory rozhodování nebo jiný znalostní odkaz. Atribut item_category poskytuje volitelné prostředky pro rozlišování těchto rozdílných částí datové struktury jako pomoc k automati-
zované analýze nebo filtrování ITEMS v ENTRY. Kódová sada pro tento atribut je definována v Části 3 této řady.

Informace v ITEM (CLUSTER nebo ELELMENT) by mohly vzniknout v době/čase odlišném od pečovatelské činnosti nebo jejím záznamu. Atribut obs_time připouští reprezentaci jednotlivého data nebo času nebo období na libovolné úrovni granularity. To by například dovolilo datovat výkon pouze rokem, počátek symptomu měsícem a rokem, dobu trvání zaměstnání přesným datovým rozsahem nebo intervalem v rocích, přesné vyznačení času arytmie, nebo uspořádat angiogram jako časovou řadu obrazů.

Informace v ITEM by mohla být zdůrazněna autorem jako výjimečná nebo pozoruhodná. Tato evropská norma nedefinuje kódovou sadu tohoto atributu: ke specifikaci míry zdůraznění nebo druhu výjimky může být použita jakákoliv dohodnutá terminologie.

CLUSTER podporuje reprezentaci složitých datových struktur potřebných k vyjádření aktuálních datových hodnot v rámci vícenásobného (vloženého) pozorování, klinického prohlášení nebo instrukce. Toto může vyžadovat vyjádření formou tabulky, stromu nebo časové řady. Specifické příklady zahrnují ECG záznam, úplný krevní obraz, vyšetření kotníkového reflexu, předepsání nitrožilní infuze léku.

Třída ELEMENT představuje koncový uzel v rámci hierarchie EHR. Každá instance této třídy bude mít jedinou Datovou hodnotu. (Podíl, interval nebo souřadnicový termín jsou zde považovány za příklady jediné datové hodnoty.) Příklady ELEMENT mohou zahrnovat důvod pro kontakt, tělesnou váhu, puls. ELEMENT může mít nulovou datovou hodnotu, pokud například není hodnota známa.

Každá třída ELEMENT obsahuje jednu datovou hodnotu pro vyjádření aktuálních hodnot instance. To je jeden z datových typů CEN (CEN/TS 14796) pro:

• text a kódované termíny;

• kvantity včetně procent, intervalů a dob trvání;

• data a čas;

• grafické a jiné MIME typy (například obraz, signál).

Připouští se, že v době vytváření této evropské normy vyvíjí ISO/TC 215 novou sadu datových typů zdravotnické informatiky. Jakmile bude publikována, CEN se může rozhodnout zamítnout CEN/TS 14796 ve prospěch této nové normy. To bude vyžadovat poskytnutí souladu mapování s novým standardem datových typů a toto mapování bude nutné použít pro převzetí nových datových typů vedle EN 13606-1.

Za účelem podpory osvojení této evropské normy v širším mezinárodním měřítku než to činí jurisdikce CEN/TS 14796, je sada atributů datových typů skutečně použitých v rámci tohoto referenčního modelu (jiných než datová hodnota ELEMENT) explicitně zahrnuta v této evropské normě v balíku podpory. Ty by měly rovněž být zamítnuty ve prospěch datových typů ISO, až budou zveřejněny.

Popis dalších hlavních tříd referenčního modelu

AUDIT_INFO

Lékařsko-právním požadavkem je dokumentovat a sdělit, kdy a kým byla EHR data zadána do EHR systému. Rovněž je důležité sledovat změny EHR dat, pokud je prováděna jejich modifikace, a toto sdělovat v rámci EHR_EXTRACT. Třída AUDIT_INFO je používána k reprezentaci těchto auditních dat:

1. pro libovolnou RECORD_COMPONENT, jako trvalý záznam jejího potvrzení v jejím počátečním systému EHR;

2. pro libovolnou COMPOSITION, jako záznam jejího potvrzení v rámci systému EHR Poskytovatele, který vytvořil tuto EHR_EXTRACT.

COMPOSITION by proto mohla mít až dva soubory auditních dat, jeden týkající se počátečního systému EHR (nazývaný „feeder_audit“) a jeden týkající se jejího následného potvrzení v rámci systému EHR Poskytovatele (nazývaný „committal“), pokud jsou odlišné. Tato evropská norma však nevyžaduje nebo nepodporuje přenášení neomezeně nahromaděných souborů auditních dat pro každý systém, pro který je COMPOSITION potvrzena.

Pro potvrzení představuje třída AUDIT_INFO časové razítko potvrzení. Identifikuje potvrzovatele a systém EHR, pro který byla data potvrzena. Časové razítko vyjadřuje, jak dlouho tato RECORD_COMPONENT přetrvávala v rámci systému EHR a stala se proto částí EHR subjektu péče. Potvrzovatel je odpovědný za začlenění této RECORD_COMPONENT v rámci EHR, ale neměl by být odpovědný za usnesení se na klinickém obsahu, který je potvrzován.

Potvrzovatel a atributy s potvrzením času jsou nepovinné, aby se ponechala možnost, že některá data budou importována z jednoduchých zděděných systémů, ve kterých klinická data vznikla, ale pro něž nejsou tyto hodnoty známy. Nicméně pro asociaci potvrzovací AUDIT_INFO je vyžadováno, aby tyto atributy měly nenulové hodnoty, protože představují čas a stranu odpovědnou za autorizaci klinických dat, která mají být začleněna do systému EHR vyhovujícího této evropské normě.

Pro revizi reprezentuje třída AUDIT_INFO status verze, nepovinný důvod revize, identitu bezprostředně předcházející verze, z níž vychází tato revize, a identifikátor společný pro všechny verze – tak aby verze vytvořené na různých systémech EHR, které nenásledují po sobě, mohly ještě být uvedeny do vzájemného vztahu. Nepovinný atribut statusu verze indikuje, zda předchozí verze byla v době jejího potvrzení návrhem (tj. v blízké budoucnosti se předpokládalo její nahrazení), aktualizací předchozího návrhu, opravou dřívější chybné verze, nebo prázdnou COMPOSITION nebo ENTRY, která je logickým vymazáním jejích předchůdců (například pokud byl předchůdce uložen v nesprávném EHR). Pokud není status k dispozici, předpokládá se, že se jedná o definitivní (první) verzi.

Systémy EHR se liší v granularitě EHR dat, pro která jsou povolena potvrzení a revize, a je velmi pravděpodobné, že všechny RECORD_COMPONENTs v rámci části EHR hierarchie (například v jedné COMPOSITION) budou sdílet stejná auditní data. Norma proto pouze vyžaduje reprezentaci této informace, pokud se liší od informace rodičovské RECORD_COMPONENT.

FUNCTIONAL_ROLE

Tato třída je používána k vyjádření podrobností, kdo a kde jednotlivý agent přispěl ke zdravotní péči nebo zdravotnímu záznamu subjektu péče. Tato třída identifikuje:

• funkci, která byla vykonána v dokumentované situaci;

• identitu agenta vykonávajícího tuto funkci;

• mód realizované součinnosti (například osobně, telefonicky);

• zdravotnické zařízení, kde byl agent přítomen;

• druh umístění služby, oddělení nebo nastavení, ve kterém agent vykonal tuto roli.

Některé z těchto informací mohou být vynechány, pokud vykonavatel nepůsobil v rámci zdravotnického zařízení, například subjekt péče zadávající data z domova.

ATTESTATION_INFO

Atestace je proces potvrzující a zaznamenávající právní odpovědnost za specifickou jednotku informace. Atestace části EHR je mechanismus, pomocí něhož atestátor může svou autoritou stanovit, že ony obsahy jsou dle jeho názoru správné. To znamená, že je přesvědčen, že obsahy jsou poctivým a věrným odrazem procesů, které dokumentují, a nezkreslují vědomě skutečnost. Atestace části EHR nebude modifikovat jeho obsah nebo interpretaci jinak než přidáním váhy jeho autenticitě. (Cokoliv, co přidalo názor, nové hledisko nebo pohled by mělo být buď revizí, nebo novou sadou vstupů se spojením na tento jeden záznam.)

Nepochybně jakákoliv modifikace části EHR prostřednictvím revize nemůže automaticky přenést jakékoliv předchozí atestace – pokud je to nutné, původní atestátor by měl být pozván, aby znovu osvědčil, že atestace je platná i po modifikaci, nebo že souhlasí s atestováním nové verze tím, kdo provedl revizi, nebo obojí nebo ani jedno.

Po mnoho let bylo vedeno hodně debat o tom, které informace je potřebné v rámci elektronických systémů uchovat:

1. k verifikaci autorizace atestátora (v rozsahu od jednoduchého příznaku indikujícího, že byl autentizován normálním způsobem daného systému až ke složité hašovací hodnotě digitálního klíče uživatele, data a času a části nebo celého podepisovaného dokumentu a volitelně zaslané notářským službám důvěryhodné třetí strany);

2. jako trvalý právní záznam toho, co bylo atestováno (v rozsahu od žádného specifického doplňku k nez-
   pracovanému databázovému záznamu, který je podepisován, k XML výstupním souborům se stylesheetem jako proxy k předvedení, jak byl prezentován, a k bitovým mapám každé obrazovky tak, jak byl skutečně předložen k Podpisu).

Atestace může být uskutečněna více než jednou osobou, v čase odlišném od potvrzení, a nemusela by vždy být vyžadována v některých službách zdravotní péče. Atestátor bude někdy také potvrzovatelem, ale nemusel by být, pokud například data zapisuje zdravotnická sekretářka.

Tato evropská norma připouští, že v některých situacích bude vhodné sdělit podrobný důkaz atestace a v jiných jednoduše potvrdit, že data byla v systému EHR Poskytovatele atestována a pouze sdělit jméno signatáře a datum atestace.

Třída ATTESTATION_INFO reprezentuje následující data o atestaci:

• datum a čas, kdy k ní došlo;

• osobu, která provedla tuto atestaci, jako odkaz na třídu FUNCTIONAL_ROLE popsanou výše;

• seznam RECORD_COMPOPNENTS, které byly atestovány;

• volitelně důvod nebo právní význam této atestace;

• volitelně elektronický Podpis (jako zapouzdřená data nebo odkaz na ně), který verifikuje atestaci;

• volitelně zapouzdřená data, nebo odkaz na ně, která představují vizuální obraz, který byl skutečně pozorován atestátorem; nyní je některými zeměmi EU vyžadováno, aby tato data byla uchována v EHR navíc k datům v jejich zpracovatelné formě.

Atestace vztahující se k FOLDER jsou obsaženy v této FOLDER; očekává se, že to bude ojedinělý případ. Častěji budou atestovány celé COMPOSITIONS nebo jednotlivé ENTRYs uvnitř COMPOSITION; všechny atestace vztahující se ke COMPOSITION nebo každému z jejích obsahů jsou obsaženy v COMPOSITION.

RELATED_PARTY

Občas nastane případ, kdy EHR data popisují zdravotní případ nebo případ zdravotní péče týkající se někoho jiného než subjektu péče. Nejběžnějším případem je rodinná historie, ale informace o přátelích, životních partnerech, sexuálních partnerech, zaměstnavateli, dětech atd. subjektu péče by mohly být občas zaznamenány v EHR a toto musí být jednoznačně odlišeno od většiny EHR informací, které jsou o subjektu péče. ENTRY obsahuje atribut “subject_of_information”, který používá třídu RELATED_PARTY pro reprezentaci předmětu informace, který není subjektem péče.

Tato třída může být použita:

1. k identifikaci osoby na základě jejího vztahu k subjektu péče, ve formě kódovaného výrazu nebo textového popisu;

2. volitelně k identifikaci osoby prostřednictvím identifikátoru a poskytnutí souboru demografického popisu této osoby v rámci demografického balíku třídy EHR_EXTRACT.

Připouští se, že z důvodů ochrany dat není obvyklé spojovat EHR jednoho datového subjektu s EHR jiného subjektu (například pokud je člen rodiny rovněž pacientem stejné společnosti), ale že takový případ občas nastane na klinikách poskytujících genetické nebo rodinné terapie a občas při základní péči. Tato evropská norma formálně nepodporuje vazby mezi EHRs odlišných subjektů péče, ačkoliv tato třída může být použita k poskytnutí identifikátorů, které jsou aktuálními identifikátory, jejichž prostřednictvím je v rámci systému EHR Poskytovatele známa jiná osoba, je-li takové použití povoleno.

LINK

Uživatel si může přát vytvoření ad hoc sémantického spojení mezi libovolnými body v EHR, například k indikaci vývoje podmínky, pravděpodobné historické příčiny problému nebo odezvy na předchozí žádost, k indikaci příčiny a následku, ke sledování vývoje objednávek od žádosti po dokončení, nebo k vytvoření sdružených sítí pro klinické problémy nebo příhody. V těchto situacích je vyžadován mechanismus, aby mohl sestavovatel poukázat z libovolného uzlu v jejich aktuálním obrazovkovém formuláři nebo elektronickém dokumentu na libovolnou předchozí komponentu v EHR a označit toto spojení vhodným klinickým termínem. Občas může jedno umístění v EHR fungovat jako spojovací rozbočovač, například formální prohlášení klinické podmínky by mohlo být použito jako pevný bod pro všechny historické a následující vstupy vztahující se k této podmínce (například v problémově orientovaném záznamu).

Taková spojení by mohla být vytvořena uživatelem jako ukazatel od nové položky záznamu na již existující položku nebo by mohla být vytvořena jako nové prohlášení o klinickém vztahu mezi dvěma nebo více již existujícími položkami (pomocí ukazatele na každou z nich ze současné položky, čímž dojde k odůvodnění vztahu). Pro takovou funkčnost si lze představit široký rozsah rozhraní koncového uživatele, ale úlohou této evropské normy je poskytnout generické a bezpečné prostředky pro sdělování existence takových spojení různým systémům EHR. To by občas mohlo vyžadovat komunikaci cíle spojení stejně jako zdroje spojení, protože tvůrce se domníval, že jakýkoliv budoucí příjemce si potřebuje být vědom obsahu obou položek, například pokud by postup nebo předpis léku měly za následek tragické komplikace. 

Třída LINK, která je spojena s RECORD_COMPONENT, povoluje, aby byl ze zdrojové komponenty reprezentován libovolný počet označených spojení k libovolnému počtu cílů (pomocí odkazů na jejich jedinečné identifikátory).

K dispozici pro označení každé LINK jsou 2 atributy:

1. hrubě strukturovaná kategorie spojení, která musí být jednou z několika hodnot definovaných v části 3 této řady;

2. volitelně jemně strukturované označení; informativní seznam termínů pro označení je uveden v části 3 této řady, ale mohou být použity jiné terminologie.

Dalším a důležitým rysem je Booleovský atribut follow_link, který, je-li pravdivý, indikuje, že tvůrce zamýšlel, aby libovolná EHR_EXTRACT, která zahrnuje COMPOSITION obsahující zdroj, musela rovněž zahrnovat COMPOSITION obsahující cíl a naopak.

Diskuze specifických témat týkajících se reprezentace

Reprezentace rolí a odpovědností v rámci EHR_EXTRACT

Provádění úkonů v rámci péče v moderní zdravotní službě může zahrnovat velký počet aktivních účastníků, s odlišnými rolemi a odpovědnostmi, z nichž každá by mohla vyžadovat reprezentaci v pacientově EHR. Přístup, přijatý v nejvšeobecnějších architekturách EHR včetně této evropské normy, tyto role a odpovědnosti rozlišuje na tři obsáhlé kategorie.

Účastníci hrající roli v aktuálním procesu zdravotní péče

Tento soubor bude obvykle zahrnovat hlavní stranu, která je klíčovou osobou vztahující se k pacientovi během tohoto úkonu (například během porodu kleštěmi to v industrializované zemi obyčejně bude porodník), a řadu souvisejících stran, které mohou poskytovat nebo podporovat části péče (například porodní asistentka), jsou zapojeny do rozhodování (například anesteziolog), jsou pozorovateli (například studenti medicíny) nebo jsou přítomni, aby podporovali nebo spolureprezentovali pacienta (například pacientův manžel/ka). Tito účastníci nemusí být všichni přítomni: například mohou být dodržovány politiky konzultanta, jenž se stará o péči, protože pacient je v péči jeho týmu, i když on osobně při této události s pacientem není. Někdy by účastníci mohli dokumentovat revizi případu nebo jednání o plánované péči zahrnující jednoho nebo více odborníků, při kterém ale pacient není přítomen.

Účastníci přispívající k procesu dokumentace péče v rámci EHR

Toto obvykle bude podmnožina těch, kteří jsou zapojeni do péče (a nejčastěji významný účastník), ale mohla by zahrnovat lidi, kteří se nepodíleli na dodávání péče (například sekretářka nebo přepisovatelka) a může (ještě více v budoucnosti) zahrnovat osobu, která je subjektem jejich péče. Je důležité připustit, že různí účastníci budou často vyplňovat různé záznamy událostí a mohou je rovněž nezávisle atestovat.

Účastníci potvrzující validitu dokumentace EHR

Analogií v papírové formě je Podpis dopisu nebo zprávy. Úkon podepsání dokumentu má nejčastěji dva účely: potvrzení správnosti dokumentu (například že je bez překlepů a vynechání) a pro signatáře potvrzení, že souhlasí s obsahem (například schválení lékařského receptu). Ve většině těchto situací je důležitý status nebo nadřízenost signatáře. Někteří účastníci popsaní v úkonu péče nebudou sami podepisovat položky popisující jejich příspěvek k péči: velká část zdravotní péče je poskytována delegováním. Například dokumentace chorobopisu vytvořená sekundářem při vizitě je zřídka revidována konzultantem a téměř nikdy není spolupodepsána. Většina pozorování na pozorovacím monitorovacím grafu není jednotlivě podepsána. U elektronického systému by se tato praxe mohla změnit, ale určitá úroveň delegování a důvěry bude pravděpodobně v rámci pečovatelských týmů vždy existovat.

Nepochybně existuje široký rozsah možných rolí a odpovědností, které by mohly vyžadovat reprezentaci v EHR, a to se může v budoucnosti změnit, jak se vyvíjejí modely zdravotních služeb. Cílem architektury EHR_EXTRACT je povolit definování libovolného počtu účastníků a rolí v rámci COMPOSITION: buď pro celou COMPOSITION nebo přesněji pro jednotlivé ENTRYs.

Přístup přijatý touto evropskou normou (jako v jiných EHR architekturách, například ENV 13606 a HL7 CDA) je:

• určit malý počet rolí, které je třeba jednoznačně sdělit pro zajištění bezpečné interpretace EHR_EXTRACTs přijímajícím systémem, a které se pravděpodobně často vyskytnou;

• povolit definování dalších ad hoc spoluúčastí zdravotními službami, systémy nebo jednotlivými instancemi EHR na úrovni COMPOSITION nebo ENTRY;

• povolit přidání libovolného počtu atestací k EHR pro Podpis FOLDERs nebo COMPOSITIONs nebo povolit atestaci pouze částí COMPOSITIONs.

Některé specifické role definované v tomto referenčním modelu jsou diskutovány níže.

Subjekt péče

Předpokládá se, že každý EHR a tedy každá EHR_EXTRACT, se bude týkat zdraví a zdravotní péče jedné osoby, která je z pohledu ochrany dat datovým subjektem. To má důležité důsledky pro data obsažená v daném EHR, která by se mohla týkat odlišného datového subjektu (jako v případě historie rodiny); toto je diskutováno dále v části Subjekt informací.

Vzhledem k obvyklé situaci, že každý EHR se týká jednoho datového subjektu, je často uváděno několik výjimek typu „zvláštních případů“.

Těhotenství: zde je obvyklým postupem, aby záznam matky obsahoval úplný záznam těhotenské péče zahrnující záznam jejího dítěte nebo dětí až do narození, kdy jsou všechny relevantní informace zkopírovány do nových záznamů těchto dětí.

Zákroky „in utero“: v některých situacích je nový záznam vytvořen značně dříve, než se dítě narodí, eventuálně je-li vyžadována podstatná zdravotní péče. V takových situacích je vhodná příležitost pro vytvoření nového záznamu pro plod, dovolující oddělení dat od záznamu matky v očekávání nového zákonného záznamu pro dítě. V závislosti na stáří plodu a zákonů platících v každé zemi stane se buď dítě, nebo matka zákonným datovým subjektem, v každém případě zde ale stále bude jednotlivý identifikovatelný subjekt péče pro každý záznam.

Vícenásobné těhotenství, přičemž každý plod má svůj vlastní záznam: tento případ je často citován jako situace, ve které by mohly zdravotní úkony skutečně „příslušet“ dvěma nebo více subjektům péče. V těchto situacích by se zdálo být logické, aby EHR_EXTRACT každého dítěte obsahovala kopii příslušných COMPOSITIONs, spíše než se pokoušet o úplné spojení mezi dvěma nebo více záznamy kvůli odkazu na jednotlivou COMPOSITION uchovanou v jednom z těchto záznamů. (Samozřejmě by mohla být v rámci systému EHR vytvořena složitější uspořádání typu křížové vazby, povolující uživatelům jednou zadat data a nechat je logicky přidat k oběma záznamům).

Siamská dvojčata: ano, byly diskuze i o těchto vzácných případech! Opět se v tomto případě zdá být logické a bezpečné mít pro každé z dvojčat kopii příslušných COMPOSITIONs, kdykoliv jsou vytvořeny samostatné EHRs, spíše než spojené extrakty záznamů, které by nemusely být bezpečně zvládnuty systémy příjemce.

Darované orgány: Některé výsledky testů vztahujících se k dárci orgánu může být vhodné uchovat v EHR příjemce darovaného orgánu – například virový status dárce a v budoucnu genetický záznam dárce – neboť příjemce bude od tohoto okamžiku genetickou mozaikou. Z těchto důvodů může být subjektem informace některých informací v EHR „dárce“.

Identifikátor subjektu péče EHR_EXTRACT bude odkazovat na snímek demografické informace, který je udržován EHR Poskytovatelem, aby umožnil pacientovi být sdružen s demografickým repositářem EHR Příjemce, a/nebo pro EHR_EXTRACT být odkázán na jednotlivý subjekt péče, i když nejsou externí demografické služby dostupné. Subjekt péče je definován na nejvyšší úrovni modelu, v třídě EHR_EXTRACT.

Tvůrce

Účastník je osoba, která skutečně uspořádala slova, termíny, obrázky a hodnoty atd., které jsou reprezentovány v COMPOSITION. Tvůrce bude téměř vždy hrát klíčovou roli při shromažďování informací, zvažující nebo nařizující hlediska dokumentované zdravotní péče. Někdy by však mohl být podřízeným členem týmu zapisujícím poznámky jménem týmu. Přesto to budou slova a fráze tvůrce, co utváří dokumentaci.

Atribut Composer proto reprezentuje stranu, která vytvořila data v COMPOSITION, nezávisle na tom, kdo je potvrdil nebo atestoval. Na COMPOSITION se bude nahlížet jako na primárně přisouzenou k této osobě. Zda se tvůrce při revizi změní nebo nezmění, je volitelné. Aplikace budou obecně používat jméno tvůrce k označení dat COMPOSITION pro účely zobrazení. (Role členů týmu jiných než tvůrce mohou být přidány jako role jiných účastníků, buď pro celou COMPOSITION nebo pro jednotlivé ENTRYs.)

Potvrzovatel

V mnoha situacích není osoba, která uspořádává slova, osobou, která je zapisuje. Obvyklým příkladem je diktování dopisů a hlášení, které mohou být zapisovány sekretářkou nebo zapisovatelkou. Podřízený člen klinického týmu by mohl rovněž popsat sebe jako potvrzovatele, pokud skutečně vystupuje ve funkci pouze sepisovatele pro jiného nadřízeného (sestavujícího) týmového kolegu. V některých transkripčních scénářích je zapisovaný text kontrolován tvůrcem, který ho potom sám potvrzuje v pacientově EHR. V některých scénářích spolupracuje několik členů klinického týmu na poskytnutí péče; každý z nich by měl být schopen zdokumentovat (a atestovat) své vlastní části této péče v pacientově záznamu.

Mohou nastat jiné situace, kdy potvrzovatel není odpovědný za zápis údajů, například když měřící zařízení přímo předává data klinické aplikaci. V těchto situacích lze použít atributy information_provider nebo other_participations třídy ENTRY pro doplnění souboru stanovených účastníků.

Subjekt informací

Tento atribut je potřebný pro identifikaci osoby, ke které se informace v ENTRY vztahuje, pokud není subjektem péče, například když se informace týká člena rodiny jako například otce nebo matky pacienta. To je považováno za důležitý „bezpečnostní“ atribut pro doplnění libovolného významu vyplývajícího z názvu komponenty nebo archetypu, zejména pokud jsou záznamy sdělovány napříč zeměmi a jazyky.

V některých kontextech mohou být strany přesně specifikovány, pouze pokud jsou registrovány v rámci lokální demografické služby A daly svůj souhlas, aby byly identifikovány v tomto pacientově EHR. To se bude stále více objevovat v klinických oblastech jako je genetika rakoviny, která pracuje s pacienty v rámci jejich rodinného kontextu. Běžnější situací je, když pacient popisuje zdravotní stav ostatních. 

Asociace subject_of_information z třídy ENTRY odkazuje na třídu RELATED_PARTY, dovolující definovat vztah tohoto subjektu k pacientu jako kódovaný termín a volitelně rovněž prostřednictvím identifikátoru strany (pravděpodobně spojením na demografickou službu v rámci systému EHR).

Tento přístup umožní opakované použití archetypů s různými subjekty péče a jednoznačné zpracování EHR ENTRYs k odlišení dat o pacientovi od dat o jiných stranách.

Poskytovatel informace

Většina informací zdokumentovaných v EHR bude pocházet od pacienta nebo jednoho z dalších účastníků v úkonu péče. Místy však mohou být přidány ENTRYs, jejichž datové hodnoty pochází od nějaké další strany, například příbuzného nebo ošetřovatele, kteří mohou být s pacientem nebo sami důvěrně navštíví pacientova lékaře. Další klinické strany by mohly poskytnout informace tvůrci nepřímo (například telefonicky).

Asociace info_provider z třídy ENTRY odkazuje na třídu FUNCTIONAL_ROLE, povolující reprezentaci jejich funkce a způsobu přispívání (telefonicky, osobně atd.). Stejně jako u subjektu informací by strana mohla nebo nemusela být formálně identifikována, v závislosti na souhlasu a tom, zda jsou registrováni v lokální demografické službě. Formální identifikace poskytovatelů informací poskytuje tvůrci jeden způsob, jak přisoudit některé ENTRYs v této COMPOSITION jiným klinickým lékařům nebo zařízením (dalším způsobem je atribut other_participations).

Demografie

Elektronický zdravotní záznam může odkazovat na široký rozsah instancí specifických entit, jako například na subjekt péče, různé agenty zdravotní péče a jiné agenty, kteří hráli role při dodání zdravotní péče, zařízení, která měřila tělesné parametry nebo poskytnutou léčbu, a organizace, které převzaly odpovědnost za péči. Mnohé z těchto entit jsou odkazovány v rámci jakéhokoliv daného EHR vícenásobně a v mnoha podnicích by mohly být definovány v rámci demografického serveru.

V tomto referenčním modelu byl přijat rovnocenný přístup: specifické entity jsou definovány jednou v rámci balíku demografického extraktu a dle potřeby odkazovány v celém zbytku EHR_EXTRACT prostřednictvím dedikovaného identifikátoru instance. Identifikátor instance použitý v rámci EHR_EXTRACT by mohl, ale nemusel být jedním z aktuálních identifikátorů, pomocí nichž je každá entita v systému EHR Poskytovatele známa.

Cílem této části modelu je poskytnout nezbytný a dostatečný popis každé entity pro podporu lidské interpretace EHR a nalezení demografické shody, aby bylo EHR Příjemci umožněno identifikovat odpovídající entity v rámci jeho vlastního demografického serveru. Je-li vyžadována podrobnější výměna demografických informací, doporučuje se použít příslušná alternativní norma jako například CEN/TS 14796.

Celý balík DEMOGRAPHIC_EXTRACT je volitelný a demografické podrobnosti každé entity není nutné sdělovat, pokud je známo, že EHR Poskytovatel a EHR Příjemce sdílejí nebo mohou mít přístup ke společné demografické službě – například uvnitř jednoho podniku, oblasti nebo zdravotnické služby.

Revize

Revize je důležitou a potenciálně složitou oblastí. Navíc ke známým lékařsko-právním požadavkům na sledování revizí a označování revizí atributy podpořily přijatý přístup následující funkční požadavky:

1. velká většina žádostí o části EHRs nebo celé EHRs bude zaručovat vytvoření EHR_EXTRACT, která obsahuje nejnovější verze obsažených RECORD_COMPONENTs;

2. i v těchto situacích může být důležité vědět, že přenášené RECORD_COMPONENTs byly předmětem korekce;

3. bude existovat málo častá potřeba přenést sériová čísla RECORD_COMPONENTs pro účely klinické péče, například pro vysvětlení chyby;

4. existuje potřeba schopnosti přenést celý EHR, včetně všech verzí revidovaných komponent, například je-li péče legálně převáděna mezi dvěma společnostmi;

5. COMPOSITION by měla upevnit sdělování potvrzení a revize v rámci EHR_EXTRACT, třebaže by změny provedené během revize mohly ovlivnit pouze několik málo z obsažených komponent;

6. vývoj FOLDERs může časem rovněž potřebovat podobný způsob správy revizí, ačkoliv toto bude obvykle provedeno v rámci systémů EHR a auditní záznam třídy FOLDER bude pravděpodobně jen příležitostně obsažen v rámci EHR_EXTRACT;

7. v mnoha případech by nemuselo být legální přenášet chyby, které byly opraveny: revidované komponenty by proto neměly „obsahovat“ původní data, která byla opravena, i když jsou označena jako logicky vymazaná. Například chybná data opravená na žádost pacienta nemusí být sdělována v souladu s direktivami EU a většinou národní legislativy o ochraně dat;

8. v některých případech, například rozhodnutím soudu, mohou být data fyzicky vymazána ze systému EHR. V takových případech by mohlo někdy být vhodné uchovat prázdné rezervované místo RECORD-COMPONENT na stejném místě hierarchie pro indikaci, kdy a proč došlo k vymazání.

Pro sledování verzí změn v databázích existují různé techniky, z nichž kterákoliv by mohla být použita v rámci jednotlivých systémů EHR. Přístup zvolený pro tuto evropskou normu je specifikovat uspořádanou metodu, kterou lze vyhovět nezbytným klinickým a lékařsko-právním požadavkům v rámci EHR_EXTRACT, bez předepisování specifické metodologie správy verzí, která má být použita uvnitř těchto systémů EHR.

Třída AUDIT_INFO obsahuje sadu atributů, které definují systém EHR, potvrzovatele a potvrzený čas, které definují původ libovolné RECORD_COMPONENT v rámci systému EHR, ve které byla poprvé vytvořena. Tuto datovou sadu je nutné zahrnout do EHR_EXTRACT, kdykoliv je tato RECORD_COMPONENT přenášena. Je-li RECORD_COMPONENT revizí dřívější verze, je nutné rovněž poskytnout dodatečnou sadu popisů a odkazů na předchozí verze. Je proto vždy možné zjistit, byla-li RECORD_COMPONENT revidována, kdy, proč, kým a v kterém systému EHR. Identita předchozí verze je známa, ale přístup k této předchozí verzi je možný pouze pokud má EHR Příjemce nezbytná privilegia a EHR Poskytovatel je připraven ji uvolnit.

Sdělování EHR dotazů

Uživatelé často požadují náhledy na určité typy položek nebo na vyšší úrovně seskupení, které mohou být výpočetně odvozeny filtrováním longitudinálního EHR pro určité třídy informací (v budoucnu by to mohlo být podle archetypu). Určité hodnoty atributů nebo datové hodnoty by mohly být použity pro třídění výsledku filtrace na vhodný uživatelský náhled, například dle data, abecedně nebo dle klesající velikosti hodnoty.

Pro podporu tohoto nejsou ve výchozích položkách EHR požadovány žádné specifické vlastnosti a logika pro odvození každého náhledu bude obvykle spočívat na klinické aplikaci, nikoliv na jednotlivém EHR. Výsledek provedeného dotazu normálně není uložen v EHR nebo sdělován, takže Referenční model komunikací EHR ho nemusí reprezentovat. Příkladem by mohl být graf krevního tlaku v průběhu času nebo seznam léků předepsaných během uplynulých 30 dnů.

Některé pohledy nebo výsledky filtrování mohou být získány „uživatelem upraveným“ dotazem, který byl specificky sestaven pro použití v rámci EHR jednotlivého subjektu péče. V takových případech může být žádoucí uložit parametry dotazu v rámci EHR pacienta ve prospěch budoucích klinických lékařů. Hranice do kdy je užitečné toto sdílet mezi společnostmi a systémy záleží na úrovni interoperability specifikace tohoto dotazu. Jestliže byl jazyk specifikující definice a omezení archetypů (Archetype Definition Language – ADL) nyní normalizován (V Části 2 této řady) a společné směrnice rovněž postupují směrem k interoperabilním specifikacím, zdá se být pravděpodobné, že se objeví generická specifikace EHR dotazu.

Dosud neexistuje normalizovaná konvence specifikace dotazu týkajícího se EHR, ale je pravděpodobné, že těmito specifikacemi budou datové soubory řetězcových hodnot nebo dvojice jmenných hodnot. Taková specifikace může být reprezentována v rámci podtříd CLUSTER a ELEMENT třídy ITEM, s datovými hodnotami typu STRING. Archetypy ENTRY lze proto použít pro definici reprezentace jakýchkoliv EHR dotazů, které je potřebné sdělovat. To má tu výhodu, že pro použití v rámci systémů zdravotní péče může být definována více než jedna taková specifikace dotazu a může být v průběhu času zdokonalena, aniž by to vyžadovalo modifikaci této evropské normy. Níže je uveden názorný příklad.

ENTRY Blood Pressure Graph Query

CLUSTER: Query Specification

ELEMENT: Query Syntax: <EHR_OQLv1>

ELEMENT: Query String: “Select….

where Cluster.meaning = <Blood Pressure>

and containing.Entry.subject_of_information = <Patient>

and containing.Composition.Clinical_Session.session_time.start

> (now>–365days)”

ELEMENT: Datetime first authored: 20 February 2003

POZNÁMKA Aktuální syntaxe řetězce dotazu ve výše uvedeném příkladu je pouze pro ilustraci a neodpovídá žádné známé syntaxi. V případě takového skutečného dotazu uloženého v záznamu by syntaxe měla vyhovovat schématu, identifikovanému v ELEMENTu syntaxe dotazu.

Sdělování prezentačních informací

Všeobecně není z několika důvodů považováno za vhodné zahrnout v rámci sdělování EHR podrobnosti, jak byla klinická data původně prezentována na obrazovce v okamžiku jejich zachycení.

1. Obrazovky zachycení dat často neodpovídají přímo obrazovkám prezentace dat, dokonce ani v rámci jedné klinické aplikace, tudíž pro jiného zdravotnického odborníka nemá velké využití informace o vzhledu obrazovky těsně před tím, než byla uložena;

2. klinická data mohou často být zobrazena více než jedním způsobem (například souhrnné obrazovky, podrobné obrazovky) a pro různé uživatelé by v jejich situaci mohly být různé prezentace více nebo méně použitelné;

3. systém EHR Příjemce by nemusel být schopen přesně zobrazit rozvržení obrazovky podporované systémem EHR Poskytovatele;

4. zdravotničtí odborníci EHR Příjemce pravděpodobně mají své vlastní aplikace, pomocí nichž si chtějí konzistentně prohlížet jak importovaná, tak lokálně vytvořená data;

Existují však dva scénáře, kdy by mohlo být důležité sdělení přesné prezentace informací spolu s daty EHR:

1. je-li potřebné zachytit vzhled obrazovky a způsob uspořádání dat pro lékařsko-právní účely (například ukázat, jaká data klinický lékař skutečně viděl, když data podepisoval);

2. pokud specifická prezentace dat zprostředkuje jedinečný pohled na jejich interpretaci, jako například diagram nebo graf.

V obou případech může být atribut attested_view třídy ATTESTATION_INFO použit pro zahrnutí reprezentace zapouzdřených dat pro libovolnou úroveň granularity dat EHR. Tento atribut může být například použit pro zahrnutí poskytnutého pohledu na dokument HL7 verze 3 CDA vydání 1 nebo vydání 2.

Vyšetřování klinických požadavků ukázala častější potřebu zvýraznění specifické části dat jako pozoruhodných, abnormálních nebo neočekávaných, spíše než prezentaci. Požadavkem v takových situacích je obvykle indikovat, že data by měla být koncovému uživateli vhodně zdůrazněna spíše než přikazovat, zda je potřebné je znázornit tučným nebo červeným fontem. Atribut zdůraznění ITEM povoluje toto sdělovat jako kódovanou hodnotu.

Sdělování multimediálních dat

Požadavek zahrnout a sdělovat multimediální data v rámci EHRs, například výsledky diagnostických zobrazovacích studií, je nesporný. Zdravotničtí odborníci všech disciplín a specializací chtějí být plně informováni při rozhodování o péči a pacienti sami stále více chtějí být schopni vidět své vlastní zdravotní problémy a rozumět jim, včetně vizuálních formátů jako jsou zobrazení. Průměrní uživatelé multimediálních záznamů mohou zahrnovat ty, kteří nabízejí doplňková odborná vyjádření ke studiím a doporučení pro plánování následné péče, nebo ty, kteří potřebují zhodnocení dřívějších studií při interpretaci nové (potenciálně na jiném místě nebo v jiné zemi).

V rámci EHR mohou být data ze širokého rozsahu typů médií zahrnuta jako specifické datové hodnoty třídy ELEMENT. Složitější struktury multimediálních dat mohou být proto reprezentovány kombinací tříd ELEMENT, volitelně obsažených v CLUSTERs, jako tabulky, seznamy nebo stromy, Specifické datové struktury nebo multimediální záznamy mohou být reprezentovány jako specifické ENTRYs nebo COMPOSITIONs a mohou být archetypovány.

Volba typu dat pro zapouzdřená data (zkrácený kód ED) dle definice v CEN/TS 14796 povoluje reprezentovat libovolný datový typ MIME.

1 Předmět normy

Tato evropská norma specifikuje komunikaci části nebo celého elektronického zdravotního záznamu (electronic health record, EHR) jednotlivého identifikovaného subjektu péče mezi systémy EHR, nebo mezi systémy EHR a centralizovaným repozitářem dat EHR.

Může být rovněž použita pro komunikaci EHR mezi systémem EHR nebo repozitářem a klinickými aplikacemi nebo komponentami middleware (například komponenty podpory rozhodování), které potřebují přistupovat k datům EHR nebo je poskytovat.

Tato evropská norma bude převážně používána k podpoře přímé péče poskytované identifikovatelným jedincům nebo k podpoře systémů sledování populace, jako například registry chorob a veřejný zdravotní dohled. Použití zdravotních záznamů pro jiné účely jako například pro vyučování, klinický audit, administraci a hlášení, správu služeb, výzkum a epidemiologii, které často vyžadují anonymizaci nebo agregaci jednotlivých záznamů, nejsou těžištěm této evropské normy, ale podobné druhotné využití by rovněž mohlo shledat normu užitečnou.

Tato Část 1 několikadílné řady je specifikací Informačního hlediska dle definice v normě Otevřené distribuované zpracování – Referenční model: Přehled (ISO/IEC 10746-1). Tato evropská norma není zamýšlena pro specifikování vnitřní architektury nebo návrhu databáze systému EHR.

Konec náhledu - text dále pokračuje v placené verzi ČSN.

Zdroj: www.cni.cz