Referenční rozhraní národního konektoru Národního kontaktního místa pro ehealth úloha pacientský souhrn

Podobné dokumenty
Národní ehealth a epsos

ERP-001, verze 2_10, platnost od

CÚeR a RLPO Workshop č SÚKL

eneschopenka technické řešení Pavel Borkovec ČSSZ, Křížová 25, Praha Architekt, Asseco Central Europe

Artlingua Translation API

Michal Kolařík ISZR - Brána k základním registrům

V této příloze jsou uvedeny výchozí podmínky a požadavky na dodávku v rámci této veřejné zakázky. 1 Obsah Seznam příloh... 2

Certifikáty a jejich použití

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY

Popis B2B rozhraní pro elektronickou neschopenku

TRANSPORTY výbušnin (TranV)

Aktuální stav projektu přeshraničních služeb ehealth

Funkční specifikace ABOKWS. Aplikační rozhraní elektronického bankovnictví ABO-K. Verze 0.5

Národní elektronický nástroj. Import profilu zadavatele do NEN

Chybová hlášení METODIKA MET-01/2014. SZR-56-1/OPICT-2013 počet stran 28 přílohy 0. Nahrazuje:

Koncept zprovoznění nového řešení

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace

Řízení identit v resortu zdravotnictví

Popis egon služby. E93 - roszapispravnistav. Název dokumentu: Popis egon služeb Verze: Datum aktualizace: Správa základních registrů

Specifikace služby RVI_NOU01B

KSRZIS. Postup kroků nutných pro napojení nemocničního informačního systému s registrem NSHNU v prostředí registrů resortu zdravotnictví

B2B SOAP - popis funkcionality

Registr pojištěnců veřejného zdravotního pojištění. Ing. Radek Papp vedoucí projektu

ELEKTRONICKÝ ARCHIV ZDRAVOTNICKÉ DOKUMENTACE

Referenční rozhraní. Jiří Kosek. Ministerstvo informatiky ČR. ISSS 25. března 2003

Postup pro vytvoření žádosti o digitální certifikát pro ověřovací a produkční prostředí Základních registrů

emedocs CHYTRÉ regionální ehealth řešení Michal Opatřil ICZ a.s. 1

PODMÍNKY POSKYTOVÁNÍ PŘÍSTUPU K PORTÁLU NAMĚŘENÝCH DAT POMOCÍ WEBOVÝCH SLUŽEB SPOLEČNOSTI ČEZ DISTRIBUCE, A. S.

Živé ehealth projekty ICZ

Registrace a aktivace uživatelského profilu k přístupu do systému erecept pro pacienta

Registr Osob. zveřejněno podepsáno

Elektronická evidence tržeb. P r a h a 2. srpna 2016

Datové schránky. Technická specifikace. Vytvořeno dne: Aktualizováno: Verze: Software602, a.s.

Technické řešení. Poskytování časových razítek. v. 1.0

ELEKTRONICKÝ ARCHIV ZDRAVOTNICKÉ DOKUMENTACE A VIDITELNÝ

1.1. Základní informace o aplikacích pro pacienta

Výtisk č.: Počet listů 9. Přílohy: 0 ÚZIS ČR

SPRÁVA ZÁKLADNÍCH REGISTRŮ ČESKÉ REPUBLIKY. Základní registry a eidas

PROJEKT NIX-ZD.CZ CEF Connecting Europe Facility

V této příloze jsou uvedeny výchozí podmínky a požadavky na dodávku v rámci této veřejné zakázky. 1 Obsah Seznam příloh... 2

Popis egon služby. E177 - iszrctireklamaci. Název dokumentu: Popis egon služeb Verze: Datum aktualizace: Správa základních registrů

JIHOMORAVSKÝ KRAJ Žerotínovo nám. 3/5, Brno

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY

Výtisk č.: Počet listů 10. Přílohy: 0 ÚZIS ČR. Příručka pro externí žádost

Technická dokumentace

Příručka pro potvrzování zůstatku vydavatelům karetních platebních prostředků

PEPS, NIA a mojeid. Budoucnost elektronické identity. Jaromír Talíř

l Kontakt s klientem SSP Popis automatizované komunikace s ÚP ČR v součinnosti a exekuci

Postup při registraci (autentizaci) OVM do informačního systému evidence přestupků (ISEP)

Koncept zprovoznění nového řešení

KSRZIS. Příručka pro externí žádost. Projekt - ereg - Úprava rezortních registrů a konsolidace rezortních. dat v návaznosti na základní registry VS

Osnova. GIOP a IIOP IDL IOR POA. IDL Klient Server. 2 Historie. 3 Princip a základní pojmy. 4 Implementace. 5 Aplikace CORBA

Certifikační autorita EET. Veřejný souhrn certifikační politiky

NIA. Josef Knotek

emedocs Exchange Medical Document System David Zažímal Petr Pavlinec

Elektronizace zdravotnictví a legislativa. JUDr. Radek Policar

HLÁŠENÍ DODÁVEK LÉČIVÝCH PŘÍPRAVKŮ UVEDENÝCH NA TRH V ČR DRŽITELI ROZHODNUTÍ O REGISTRACI LP - REG13

POPIS DATOVÉHO ROZHRANNÍ PRO IMPORT DAT DO ASW PRO SLEDOVÁNÍ DEKUBITŮ

eneschopenka Pavel Borkovec technické řešení ČSSZ, Křížová 25, Praha Architekt, Asseco Central Europe

Anabix API. Popis způsobu používání služby

Dokumentace k nevizuálnímu rozhraní aplikace DopisOnline

Návrh funkcí webových služeb (WS) pro komunikaci mezi Informačním systémem datových schránek (ISDS) a spisovými službami (SS)

Úvod do Web Services

Příručka pro editaci kontaktů na eagri

Informační systém pro nemocnici

1 Webový server, instalace PHP a MySQL 13

Synchronizace CRM ESO9 a MS Exchange

Elektronická evidence tržeb. Produkční prostředí Přístupové a provozní informace

Certifikáty a jejich použití

ADIS Opt-Out rozhraní na okolní systémy. Technický popis rozhraní s pojišťovnami

Informační podpora poskytovatelů zdravotních služeb. Ing. Zdeněk Vitásek, MBA

Požadavky pro výběrová řízení TerraBus ESB/G2x

egov se z vizí pomalu stává realitou

Katalog egon služeb verze: 0.01

l Kontakt s klientem SSP Popis automatizované komunikace s ÚP ČR v součinnosti a exekuci

JSON API pro zjišťování cen MtG karet

poskytovatele zdravotnických služeb Fares SHIMA Ministerstvo zdravotnictví Ředitel odboru informatiky

Portál Značení tabáku Uživatelská příručka pro registrované uživatele

VYHLÁŠKA. ze dne o provedení některých ustanovení zákona o léčivech týkajících se elektronických receptů

Metodický pokyn k uvedení registru do produkčního provozu

PODMÍNKY POSKYTOVÁNÍ PŘÍSTUPU K PORTÁLU NAMĚŘENÝCH DAT POMOCÍ WEBOVÝCH SLUŽEB SPOLEČNOSTI ČEZ DISTRIBUCE, A. S.

Uživatelská dokumentace

Popis egon služby. E23 - roszapisdatovouschranku. Název dokumentu: Popis egon služeb Verze: Datum aktualizace: Správa základních registrů

Popis egon služby. E75 - orgctidavkuaifo. Název dokumentu: Popis egon služeb Verze: Datum aktualizace: Správa základních registrů

Postup pro vytvoření žádosti o digitální certifikát pro produkční prostředí Základních registrů

sms.sluzba.cz API_XML30 pro textové SMS zprávy do ČR a do zahraničí

Základní registry ve veřejné správě

PŘÍSTUPOVÁ KONTA PRO POVĚŘENÉ OSOBY DRŽITELŮ ZL

Spuštění základních registrů. ing. Ondřej Felix CSc. hlavní architekt egovernmentu MV ČR

Uživatelská příručka SBOX

Platební systém XPAY [

Výměnný formát XML DTM DMVS PK

Využívání čipových karet na MPSV. Mgr. Karel Lux, vedoucí odd. koncepce informatiky

SMETerminal a SMEReader AutoCont CZ a.s.

Obsah. Příloha č. 1: Specifikace Díla

Jednoznačná identifikace jako předpoklad funkčního e-health. Martin Pavlík

EXTRAKT z české technické normy

Výtisk č.: Počet listů 12. Přílohy: 0 ÚZIS ČR. Příručka pro aktivaci účtu

Transkript:

Referenční rozhraní národního konektoru Národního kontaktního místa pro ehealth úloha pacientský souhrn příloha č.4 Specifikace API národního konektoru (NC) pro získávání patient summary (PS) Autor: kolektiv projektu NIX-ZD Získání PS ze zdrojových systémů lze dosáhnout pomocí 2 implementovaných rozhraní. Finální API pro komunikaci zdrojového systému a NC je definováno pomocí mezinárodních standardů IHE (profily XCPD, XCA). Jako dočasné řešení je možné na úrovni zdrojových systémů implementovat národní API viz níže. Obě API (jak IHE, tak národní) by měla umožňovat zjištění existence PS ve zdrojovém systému a jeho následné získání NC a předání NCPeH infrastruktuře. V rámci komunikace NCPeH resp. jeho národního konektoru je událost vyžádání PS iniciována externím subjektem (typicky tzv B server NCPeH v jiném státě). Proto je zdrojový systém v ČR (NIS) v roli serveru a NC NCPeH v roli klienta. NC NCPeH pak v rámci dotazu oslovuje jednotlivé integrované systémy s dotazem na existenci PS buď prostřednictvím tzv. národního API (viz dále) nebo v budoucnu pomocí metod příslušných IHE profilů. Národní API a) Autentizace Ověření NC vůči zdrojovému systému: 1. PKI Client Authentication - certifikát vydá zdrojový systém (NIS), ověření probíhá při navazování spojení. Forma a náležitosti serverového certifikátu je předmětem dohody mezi správcem NCPeH a poskytovatel dat (správcem zdrojového systému). 2. HTTP Basic Authentication - do doby než bude zdrojový systém podporovat metodu ověření PKI je možné použít basic autentizaci (jméno a heslo přiděluje zdrojový systém) s omezením na vyjmenované přístupové IP adresy b) Bezpečnost Nutnou podmínkou vzájemné komunikace je použití šifrované komunikace protokolem HTTPS/TLS. c) Metody Zdrojový systém poskytující PS pro NC musí mít implementovány tyto metody: 1. Pro ověření existence PS (getpsexists.xml) tato metoda ve zdrojovém systému ověří existenci PS pacienta (bez toho, aniž aby si zatím vyžádala samotný dokument PS). Metoda umožní rychle paralelně oslovit všechny potenciální zdrojové systémy a podle zaslané aktuálnosti PS (v případě existence PS pro daného pacienta datum a čas posledního lidského záznamu do zdravotní dokumentace použitého pro tvorbu PS) se NC rozhodne, od kterého zdrojového systému si následně vyžádá zaslání dokumentu PS (viz bod 2).

2. Pro stažení PS dokumentu (getps.cda) tato metoda stáhne požadované PS (dokument CDA L3 a volitelně i dokument CDA L1, pokud ho umí zdrojový systém vytvořit. Pokud zdrojový systém neumí vytvořit dokument CDA L1, bude CDA L1 dokument vygenerován v NC dle definovaných pravidel ze zaslaného dokumentu CDA L3) Metoda getpsexists.xml HTTP metoda: GET Vstupní parametry: Název parametru Datový Povinnost Význam typ idtype varchar Povinný Typ identifikátoru pacienta, aktuálně RC = rodné číslo resp. číslo pojištěnce, v budoucnu případně nový typ ID (bezvýznamový identifikátor, resortní ID, ) idvalue varchar Povinný Identifikátor pacienta (hodnota) purposeofuse varchar Povinný Důvod dotazu na PS (EMERGENCY TREATMENT NONNCP) 1 subjectnameid varchar Povinný Identifikace uživatele, který požaduje data v Base64 kódování (saml2subjectnameid). Příklady dle implementace: EidasId, LoginName,... requestorgid varchar Nepovinný Identifikace organizace posílající request (primární použití pro identifikaci organizace při purposeofuse=nonncp, např. Portál občana). Příklady dle implementace: IČO,... requestid varchar Povinný Identifikátor dotazu, který si uloží obě strany pro usnadnění případných reklamací nebo průkaznost vydání dat pacienta (saml2assertionid). Výstupní parametry: Pozn: jednotlivé výstupní parametry jsou součástí kolekce elementů. Důvod využití opakovacích elementů patientsummary je možnost vracet více patient summary v rámci sběrnicových systémů, které jsou napojeny na více NISů (např. emedocs). V případě, že metoda je implementována v jedné organizaci a vrací pouze jedno PS z NIS, je součástí elementu patientsummary pouze jedna sada výstupních parametrů. Název parametru Datový typ Povinnost Význam 1 EMERGENCY = rychlá záchranná služba, TREATMENT = ošetření ambulantní/nemocniční, NONNCP = jiné využití např. Portál občana

sourceidentifier varchar Povinný identifikátor zdroje (zdravotnického zařízení) dle katalogu XXXXX. V případě sběrnicových systémů pro vracení agregovaného PS bude uvedena konstanta AGGREGATE sourcename varchar Povinný Oficiální název organizace (tento údaje se použije v případě, že nedojde k vyhledání oficiálního názvu organizace pomocí identifikátoru zdravotnického zařízení sourceidentifier). V případě AGGREGATE uvede sběrnicový systém svůj oficiální název. exists boolean Povinný Zdrojový systém má pacientský souhrn pro požadovaného pacienta (uložený nebo generovaný). Povolené hodnoty (true false) effectivetime datetime Povinný (pokud exists=true) cdal1support boolean Povinný (pokud exists=true) Zdrojový systém uvede čas posledního lidského záznamu do zdravotní dokumentace, použitého pro tvorbu PS (CDA dokumentu) tento čas slouží k identifikaci nejaktuálnějšího PS ze všech zdrojových systémů. Formát YYYYMMDD, YYYYMMDDhhmm, YYYYMMDDhhmmss Zdrojový systém má PS ve formátu CDA L1. Povolené hodnoty (true false) Příklad volání: getpsexists.xml?idtype={idtype}&idvalue={idvalue}&purposeofuse={purposeofuse}& subjectnameid={subjectnameid}&requestorgid={requestorgid}&requestid={requestid} getpsexists.xml?idtype=rc&idvalue=7551130000&purposeofuse=emergency& subjectnameid=q1ovq1ovyjdiogjlmjutn2uyoc00mgvkltg5mtctnwjjmjk2otaxyjy5&request OrgId=00090638&requestId=1234 Příklad odpovědi pro NIS: <getpsexistsresponse> <sourceidentifier>667788</sourceidentifier> <sourcename>nemocnice XYZ, a. s.</sourcename> <effectivetime>20171207153400</effectivetime>... </getpsexistsresponse> Příklad odpovědi pro sběrnicové systémy: <getpsexistsresponse>

<sourceidentifier>aggregate</sourceidentifier> <sourcename>sběrnicový systém XYZ</sourceName> <effectivetime>20180120165000</effectivetime> <sourceidentifier>667788</sourceidentifier> <effectivetime>20171207153400</effectivetime>... </getpsexistsresponse> Pozn k výstupnímu paramentru subjectnameid: EidasID = CZ/CZ/b7b8be25-7e28-40ed-8917-5bc296901b69 (Base64 Q1ovQ1ovYjdiOGJlMjUtN2UyOC00MGVkLTg5MTctNWJjMjk2OTAxYjY5) LoginName = doctor@nixzd.cz (Base64 ZG9jdG9yQG5peHpkLmN6) Metoda getps.cda HTTP metoda: GET Vstupní parametry: Název Datový Povinnost Význam parametru typ sourceidentifier varchar Povinný identifikátor zdroje (zdravotnického zařízení) dle katalogu IČZ (identifikační číslo zařízení). V případě sběrnicových systémů pro vracení agregovaného PS bude uvedena konstanta AGGREGATE idtype varchar Povinný Typ identifikátoru, aktuálně RC = rodné číslo resp. číslo pojištěnce, v budoucnu případně nový typ ID (bezvýznamový identifikátor, resortní ID, ) idvalue varchar Povinný Identifikátor pacienta purposeofuse varchar Povinný Důvod dotazu na PS. Povolené hodnoty (EMERGENCY TREATMENT NONNCP) subjectnameid varchar Povinný Identifikace uživatele, který požaduje data v Base64 kódování (saml2subjectnameid). Příklady dle implementace: EidasId, LoginName,... requestorgid varchar Nepovinný Identifikace organizace posílající request (primární použití pro identifikaci organizace při purposeofuse=nonncp, např. Portál občana). Příklady dle implementace: IČO,... cdatype varchar Povinný Povolené hodnoty (L3 L1)

requestid varchar Povinný Identifikátor dotazu který si uloží obě strany pro usnadnění případných reklamací nebo průkaznost vydání dat pacienta (saml2assertionid). Výstupní parametry: CDA dokument L3 nebo L1 (dle parametru cdatype) Příklad volání: getps.cda?sourceidentifier={sourceidentifier}&idtype={idtype}&idvalue={idvalue}&purposeofus e={purposeofuse}&subjectnameid={subjectnameid}&requestorgid={requestorgid}&cdatype={c datype}&requestid={requestid} getps.cda?sourceidentifier=aggregate&idtype=rc&idvalue=7551130000&purposeofuse=eme RGENCY&subjectNameId=Q1ovQ1ovYjdiOGJlMjUtN2UyOC00MGVkLTg5MTctNWJjMjk2OTAxYjY5 &requestorgid=00090638&cdatype=l3&requestid=12345 Příklad odpovědi: Validní CDA dokument dle ehdsi ART-DECOR based CDA (PIVOT) Bude doplněno v dalších verzích: Specifikace metod pro získání PS z NCP-B (API pro NIS) klientský konektor Příklady validních CDA dokumentů