Załącznik

Transkrypt

Załącznik

Załącznik nr 9A
Dotyczy przetargu nieograniczonego na zamówienie pn.: Stworzenie oraz kompletne wdrożenie
Małopolskiego Systemu Informacji Medycznej - projekt pilotażowy, w ramach Małopolskiego
Regionalnego Programu Operacyjnego na lata 2007 – 2013 (399/ZP/2014)
Standard wymiany danych pomiędzy HIS i MSIM
Małopolski System Informacji Medycznej –
projekt pilotażowy
1.
Wstęp ....................................................................................................................................................... 3
1.1.
Informacje o MSIM .................................................................................................................................. 3
1.2.
Cel dokumentu ........................................................................................................................................ 3
1.3.
Założenia MSIM ....................................................................................................................................... 4
2.
Specyfikacja interfejsów komunikacyjnych HIS ....................................................................................... 10
3.
Standard HL7 CDA................................................................................................................................... 12
4.
3.1.
Opis standardu ...................................................................................................................................... 12
3.2.
Struktura dokumentu ............................................................................................................................ 13
3.3.
HL7CDA - Entries.................................................................................................................................... 16
3.4.
Spis kodów identyfikujących poszczególne sekcje ................................................................................. 39
3.5.
Spis kodów dla sekcji opisujących różne rodzaje badao obrazowych .................................................... 42
3.6.
Przykładowe kody LOINC dla wybranych typów dokumentów ............................................................. 42
3.7.
Obsługiwane kody słownika 2.16.840.1.113883.5.111 ......................................................................... 44
Specyfikacja interfejsów komunikacyjnych e-Rejestracja ....................................................................... 45
4.1.
Komunikacja HIS -> e-Rejestracja .......................................................................................................... 45
4.2.
Komunikacja e-Rejestracja -> HIS .......................................................................................................... 54
5.
Wymagania w zakresie SSO .................................................................................................................... 59
6.
Wymagania w zakresie PKI ..................................................................................................................... 59
2 z 60
1. Wstęp
1.1. Informacje o MSIM
Założeniem projektu MSIM (Małopolski System Informacji Medycznej) – projekt pilotażowy
jest stworzenie regionalnego systemu informacji medycznej – narzędzia informatycznego
pozwalającego na wymianę dokumentacji medycznej pomiędzy podmiotami leczniczymi w
województwie małopolskim.
Projekt planowany jest do realizacji jako indywidualny projekt kluczowy Małopolskiego
Regionalnego Programu Operacyjnego na lata 2007-2013 i umieszczony jest
w Indykatywnym Wykazie Indywidualnych Projektów Kluczowych Małopolskiego
Regionalnego Programu Operacyjnego na lata 2007-2013.
W projekcie bierze udział Urząd Marszałkowski oraz jako partnerzy 3 podmioty lecznicze z
terenu województwa małopolskiego:



Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu,
Szpital Specjalistyczny im. J. Dietla w Krakowie,
Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o.
1.2. Cel dokumentu
Celem dokumentu jest:


Opisanie przedmiotu zamówienia producentom oprogramowania HIS w zakresie
zapewnienia współpracy pomiędzy MSIM, a HIS,
Wyspecyfikowanie zakresu współpracy pomiędzy HIS, a MSIM dla Wykonawców w
postepowaniu „Małopolski System Informacji Medycznej – projekt pilotażowy”.
Przedmiotem zamówienia jest:
 Wykonanie dwukierunkowego interfejsu HIS ↔ EDM (rozdziały 2. i 3.),
 Wykonanie dwukierunkowego interfejsu HIS ↔ eRejestracja (rozdział 4.).
 Zaimplementowanie usługi Single Sign-On w ramach HIS oraz MSIM dostarczonej przez
Wykonawcę MSIM (rozdział 5.),
 Zaimplementowanie usługi PKI w ramach w ramach HIS oraz MSIM dostarczonej przez
Wykonawcę MSIM (rozdział 6.),
3 z 60
1.3. Założenia MSIM
1.3.1.Warstwy MSIM
System MSIM ma zapewniad rozdzielnośd warstwy regionalnej i warstwy lokalnej. Planowane
rozwiązanie nie pozwala na bezpośredni dostęp do systemów dziedzinowych Szpitali z
poziomu warstwy regionalnej.
Warstwa regionalna
Warstwa lokalna
HIS
LIS
RIS
PACS
.
Rysunek 1. Separacja dostępu do systemów dziedzinowych (źródłowych).
Wymiana Elektronicznej Dokumentacji Medycznej jest realizowana dwustronnie na osi
Warstwa lokalna ↔ Warstwa regionalna oraz HIS ↔ Warstwa lokalna. Z kolei e-Rejestracja
jest zasilana za pośrednictwem WebService’ów może się komunikowad z HIS w zakresie
wymiany grafików, terminów, informacji o kolejkach oczekujących. Pozostałe systemy
dziedzinowe takie jak LIS, RIS, PACS nie są integrowane z warstwą lokalną (ew. pośrednio
poprzez HIS). Integracja z systemami HIS, jak i z systemami LIS, RIS i PACS jest poza
zakresem zamówienia.
Pod względem architektury rozwiązania cały system wymiany dokumentów i danych
medycznych jest podzielony na częśd regionalną, w której funkcjonowad będą elementy
systemu odpowiadające za interoperacyjnośd rozwiązania oraz częśd lokalną, działającą w
poszczególnych jednostkach medycznych wchodzących w skład domeny. Dokumentacja
medyczna jest gromadzona w EDM, które są elementem dostawy w warstwie lokalnej,
natomiast warstwa regionalna zawiera jedynie jej indeks.
4 z 60
W ramach części regionalnej, zostanie zorganizowane pojedyncze źródło identyfikacji
pacjentów, pojedynczy rejestr dokumentów (baza danych gdzie przechowywane będą
metadane wszystkich dokumentów). Ustalany jest też schemat i zasady identyfikacji
obiektów powstających w systemie oraz ich wersjonowaniem.
W poszczególnych szpitalach zostaną utworzone Lokalne Repozytoria EDM, które pozwalad
będą na gromadzenie, przechowywanie i przesyłanie zgodnie z przepisami (Ustawa z dnia 28
kwietnia 2011 r. o systemie informacji w ochronie zdrowia oraz Rozporządzenie Ministra
Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej
oraz sposobu jej przetwarzania) dokumentacji medycznej. Integracja warstwy regionalnej i
lokalnej powinna odbywad się za pomocą usług sieciowych w oparciu o regionalną szynę
danych. W szpitalach będzie konieczne wykonanie integracji z WebSerwisami dostawców HIS
wykonanymi w ramach odrębnego zlecenia.
Warstwa regionalna MSIM
Regionalna Szyna Usług
Warstwa lokalna MSIM
Integracja z WebSerwisami dostawców HIS
HIS
Rysunek 2. Metody integracji w MSIM.
Zamawiający jednocześnie nie określa sposobu wewnętrznej wymiany danych w ramach
dostarczanych w ramach zamówienia modułów (tj. w przypadku, gdy oprogramowanie
Wykonawcy będzie miało jakąś wewnętrzną strukturę – to nie określa sposobu wymiany
danych w ramach oferowanego oprogramowania).
5 z 60
1.3.2. Wymiana EDM
W zakresie wymiany EDM rozwiązanie przewiduje podział funkcjonalny na warstwę lokalną i
warstwę regionalną według poniższych wytycznych.
Rejestr dokumentów EDM
(warstwa regionalna MSIM)
EDM
Adapter komunikacyjny
(warstwa lokalna MSIM)
(warstwa lokalna MSIM)
Interfejs z HIS
HIS
Rysunek 3. Wymiana danych w zakresie EDM.
Warstwa lokalna – gdzie będzie wdrożony moduł odpowiedzialny za wytwarzanie,
gromadzenie i przesyłanie EDM oraz usługi towarzyszące pozwalające na integrację z węzłem
regionalnym.
W warstwie lokalnej będzie gromadzona EDM zgodna z Załącznikiem 9A „Standard wymiany
danych pomiędzy HIS i MSIM”, zgodnie zobowiązującymi przepisami oraz zgodnie ze
specyfiką, potrzebami i oczekiwaniami poszczególnych Podmiotów. Za pomocą
odpowiednich usług i serwisów informacja o wytworzeniu dokumentacji medycznej będzie
przesyłana do warstwy regionalnej, gdzie zostanie utworzony indeks z podstawowymi
informacjami dotyczącymi tego dokumentu. Pozwoli to na poziomie regionalnym
przechowywad scentralizowane informacje o miejscu składowania i fakcie wytworzenia wraz
z informacją o wersjonowaniu wszystkich dokumentów medycznych w podmiotach
biorących udział w Projekcie. Wiarygodnośd EDM będzie wymagała poświadczenia przy
użyciu mechanizmów zaimplementowanych w systemie.
Za pomocą odpowiednich interfejsów uwierzytelniony Użytkownik będzie mógł odpytad
warstwę regionalną o dokumenty w innych jednostkach oraz pobrad je w całości lub
częściowo. Dostęp do dokumentacji będzie autoryzowany, co oznacza, że użytkownik będzie
mógł otrzymad dokumenty, do których ma prawo.
W poszczególnych szpitalach uczestniczących zostaną wdrożone i wykorzystane repozytoria
lokalne, których głównym zadaniem będzie przyjmowanie i przechowywanie zgodnie z
6 z 60
przepisami wskazanymi w dalszej części dokumentów medycznych z systemów
dziedzinowych (HIS, LIS, RIS lub innych) funkcjonujących w szpitalach.
Warstwa regionalna – gdzie wdrożony będzie rejestr EDM, który zawiera rejestr
dokumentów czyli tzw. indeks EDM znajdującej się we wszystkich lokalnych repozytoriach
EDM.
W przypadku konieczności pobrania przez lekarza pełnej dokumentacji medycznej pacjenta
z konkretnego pobytu/wizyty wymaga się możliwośd jej zamówienia/pobrania jedynie
w trzech wariantach możliwych do wybrania przez Użytkownika:



Podstawowa dokumentacja medyczna (m. in. dokumentacja zewnętrzna: karta
informacyjna, karta porady specjalistycznej, karta informacyjna SOR).
Pełna dokumentacja medyczna z hospitalizacji/wizyty bez danych obrazowych
(mniejsza objętośd).
Pełna dokumentacja medyczna z hospitalizacji/wizyty z danymi obrazowymi w jakości
diagnostycznej (duża objętośd)
Wymagane rozwiązanie zapewni w przypadku konieczności zapoznania się z bardziej
szczegółową dokumentacją pobranie jej w komplecie dla danego pobytu, przez co
gwarantuje się analizę danych diagnostycznych i z procesu leczenia w kontekście całego
pobytu. Eliminuje to zagrożenie opierania się podczas decyzji leczniczych na pobranym
dokumencie (np. z danymi diagnostyki laboratoryjnej) bez kontekstu procesu leczenia
wdrożonego podczas danego pobytu.
W ramach części regionalnej, zostanie zorganizowane pojedyncze źródło identyfikacji
pacjentów, pojedynczy rejestr dokumentów (baza danych gdzie przechowywane będą
metadane wszystkich dokumentów).
W warstwie regionalnej będzie realizowana większośd usług (np. wyszukiwanie,
przeglądanie, pobieranie, przekazywanie do innych podmiotów). Rozwiązanie takie
minimalizuje warunki techniczne potrzebne w warstwie lokalnej do sprawnego
funkcjonowania systemu – wszelkie zapytania od strony klientów obsługiwane są wyłącznie z
wykorzystaniem warstwy regionalnej.
Przedmiotem zamówienia w ramach MSIM jest:



warstwa regionalna (rejestr EDM),
EDM w warstwie lokalnej,
adapter komunikacyjny.
Pozostałe elementy wymiany EDM są realizowane w toku umów z dostawcami HIS.
7 z 60
1.3.3. E-Rejestracja
Szczególną usługą realizowaną w ramach komponentu regionalnego jest usługa
e-Rejestracji. Usługa e-Rejestracji udostępnia funkcjonalnośd rezerwacji usług medycznych
w jednostkach ochrony zdrowia zintegrowanych z MSIM.
e-Rejestracja MSIM
(warstwa regionalna MSIM)
e-Rejestracja
partnera
(poza MSIM)
HIS
Rysunek 4. Wymiana danych w ramach e-Rejestracji.
Użytkownik ma możliwośd rejestracji na wskazany termin i anulowania wizyty. Z e-Rejestracji
mogą korzystad wyłącznie zarejestrowani na poziomie regionalnym użytkownicy koocowi
(pacjenci). W ramach usługi powinien funkcjonowad system komunikatów (powiadomieo dla
użytkowników koocowych w formie np. wiadomości e-mail i SMS) dotyczących:
potwierdzenia rejestracji, zbliżającego się terminu wizyty, anulowania wizyty oraz zmiany
terminu wizyty (zarówno przez użytkownika jak i w lokalnym systemie medycznym HIS). W
szczególności usługa obejmuje następujące funkcjonalności:

Przegląd listy usług możliwych do realizacji w placówce Zamawiającego dla pacjenta.

Przegląd listy usług możliwych do rezerwacji przez Internet.

Możliwośd rezerwacji terminu usługi do wybranej poradni lub wybranego lekarza.

Określenie celu wizyty u lekarza, z podziałem na: przypadek nagły incydentalny, stan
nagły przy chorobie przewlekłej, wizytę kontrolną, wizytę po kolejną receptę, wizytę
po skierowanie na badanie specjalistyczne.

Udostępnienie danych o zaplanowanych wizytach i usługach.

Prezentacja informacji o stanie usługi (zaplanowana, anulowana, wykonana).

Możliwośd wydruku potwierdzenia rezerwacji: data i godzina usługi, imię i nazwisko
pacjenta, numer rezerwacji, miejsce wykonania usługi, informacje dodatkowe dla
pacjenta.
8 z 60

Dostęp do informacji o lokalizacji miejsca wykonania usługi.

Możliwośd odwołania rezerwacji.

Zmianę danych osobowych (imię, nazwisko, adres, nr telefonu, adres e-mail).
Zamówieniem objęta jest e-Rejestracja na poziomie regionalnym integrująca jednostki w
ramach MSIM. Poza tą rejestracją mogą występowad inne moduły e-Rejestracji na poziomie
poszczególnych partnerów, jednak – o ile zostanie utrzymana decyzja o ich eksploatacji.
Zamawiający nie wymaga przeprowadzania integracji pomiędzy e-Rejestracją na poziomie
regionalnym, a ewentualnymi rejestracjami lokalnymi.
1.3.4. Podstawowe standardy wykonania MSIM
Głównym celem proponowanego rozwiązania jest usprawnienie zarządzania i podniesienie
jakości procesów leczniczych w podmiotach leczniczych objętych systemem, poprzez
rozbudowę
i rozszerzenie stanu istniejącego przedstawionego w analizie stanu obecnego. Rozbudowa
ma na celu bezpieczne i zgodne z prawem wytwarzanie, przechowywanie, oraz
przekazywanie dokumentów medycznych pomiędzy jednostkami oraz integrację z tworzoną
na szczeblu krajowym Elektroniczną Platformą Gromadzenia Informacji O Zdarzeniach
Medycznych (projekt P1).
W celu zapewnienia dalszej łatwej rozbudowy oraz integracji z nowymi systemami wymaga
się, aby system w jak największym stopniu oparty był o obowiązujące w tej dziedzinie na
świecie
standardy
i dobre praktyki. Najszerzej przyjętym w chwili obecnej standardem dotyczącym
przekazywania dokumentacji pomiędzy szpitalami jest profil XDS.b proponowany przez
międzynarodową organizację IHE Wykonawca powinien dostarczad WebSerwis’y
umożliwiające zewnętrzną wymianę danych zgodnie z profilem XDS.b, jakkolwiek nie jest
wymagane, aby Wykonawca korzystał z tego standardu w komunikacji w ramach
komunikacji pomiędzy dostarczanymi komponentami MSIM. Profil ten opisuje procesy i
komunikaty jakie muszą zostad wymienione pomiędzy dwoma jednostkami, aby nastąpiło
poprawne przekazanie dokumentu medycznego. Standard wspierany jest obecnie przez
większośd głównych dostawców oprogramowania medycznego na świecie.
Sam układ dokumentu medycznego powinien byd zdefiniowany w języku XML, w oparciu
o najszerzej przyjęty na świecie format dokumentu opracowany przez organizację HL7 CDA
R2 na 3-cim poziomie interoperacyjności (w zakresie, gdy to jest możliwe w pozostałych
wypadkach należy stosowad poziom 2-gi i 1-szy – w szczególności dla zeskanowanych
dokumentów dopuszcza się 1-szy poziom interoperacyjności). HL7 CDA R2 na trzecim
poziomie interoperacyjności zostało także zaproponowane jako podstawowy format
dokumentów medycznych na poziomie krajowym przez Centrum Systemów Informatycznych
w Ochronie Zdrowia.
9 z 60
Pod względem architektury rozwiązania cały system wymiany dokumentów i danych
medycznych podzielony powinien byd na częśd regionalną, w której funkcjonowad będą
elementy systemu odpowiadające za interoperacyjnośd rozwiązania oraz częśd lokalną,
działającą w poszczególnych jednostkach medycznych. Warstwa regionalna może byd
posadowiona w lokalizacji jednego z uczestników projektu.
W przyszłości planuje się rozwój systemu co najmniej w następujących aspektach:



Podłączanie nowych jednostek do systemu.
Rozszerzanie zakresu wymienianych danych zarówno w aspekcie dodatkowych
danych do obecnie wymienianych dokumentów, jak i podłączania nowych systemów
dziedzinowych.
Rozszerzanie funkcjonalności poprzez podłączanie dodatkowych modułów.
2. Specyfikacja interfejsów komunikacyjnych HIS
Dokumentacja powinna byd:


wysyłana EDM z HIS do MSIM,
przyjmowana EDM do ewentualnego zapisania w danym HIS (zapisanie w HIS
powinno byd opcją)
w formacie HL7 CDA R2 na 3 poziomie interoperacyjności scharakteryzowanym w rozdziale
2. Wymaganie to należy rozumied w ten sposób, że należy stosowad poziom 3, jeżeli nie jest
możliwy poziom 2, należy stosowad poziom 1. Nie zastosowanie wyższego poziomu musi byd
obiektywnie uzasadnione (np. brakiem odpowiednich danych w HIS w wymaganej
granulacji). Szczegółowe zasady zostaną opracowane w ramach projektu technicznego.
Każdy przekazywany dokument zawiera:
1) oznaczenie podmiotu
a) nazwę podmiotu
b) adres podmiotu, wraz z numerem telefonu
c) kod identyfikacyjny, o którym mowa w przepisach wydanych na podstawie art. 13
ust. 5 ustawy z dnia 30 sierpnia 1991 r. o zakładach opieki zdrowotnej (Dz. U. z 2007
r. Nr 14, poz. 89, z późn. zm.2), zwany dalej „kodem resortowym”, stanowiący I częśd
systemu resortowych kodów identyfikacyjnych
d) nazwę jednostki organizacyjnej oraz jej kod resortowy stanowiący V częśd systemu
resortowych kodów identyfikacyjnych — w przypadku zakładu opieki zdrowotnej,
e) nazwę komórki organizacyjnej, w której udzielono świadczeo zdrowotnych, oraz jej
kod resortowy — w przypadku zakładu opieki zdrowotnej,
2) oznaczenie pacjenta (art. 25 Ustawa z dnia 6 listopada 2008 r. o prawach pacjenta i
Rzeczniku Praw Pacjenta)
a) nazwisko i imię (imiona)
10 z 60
b)
c)
d)
e)
data urodzenia
płed
adres miejsca zamieszkania(ulica, kod pocztowy, miasto, kraj)
numer PESEL, jeżeli został nadany, w przypadku noworodka - numer PESEL matki, a w
przypadku osób, które nie mają nadanego numeru PESEL - rodzaj i numer dokumentu
potwierdzającego tożsamośd
f) w przypadku gdy pacjentem jest osoba małoletnia, całkowicie ubezwłasnowolniona
lub niezdolna do świadomego wyrażenia zgody - nazwisko i imię (imiona)
przedstawiciela ustawowego oraz adres jego miejsca zamieszkania
3) oznaczenie osoby udzielającej świadczeo zdrowotnych, oraz kierującej na badanie,
konsultację lub leczenie
a) nazwisko i imię
b) tytuł zawodowy
c) uzyskane specjalizacje
d) numer prawa wykonywania zawodu - w przypadku lekarza, pielęgniarki i położnej
4) data dokonania wpisu
Powyższe informacje wynikające z:

Rozporządzenia Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i
zakresu dokumentacji medycznej oraz sposobu jej przetwarzania,
 Ustawy z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta,
należy zawrzed w nagłówku dokumentu HL7 CDA zgodnie z formatem zaproponowanym
przez CSIOZ w dokumencie Reguły biznesowe i walidacyjne określające strukturę
dokumentów medycznych (eRecepta, eSkierowanie i eZlecenie) przetwarzanych na
platformie P1, rozdz. 5 „Bazowy wzór dokumentu medycznego, definicja struktury".
Należy dążyd do tego, by dokumenty wytwarzane były na możliwie najwyższym (trzecim)
poziomie interoperacyjności (w takim zakresie na jaki pozwalają dane źródłowe z HIS).
W szczególności następujące dane:
1. grupa krwi,
2. alergie i uczulenia,
3. rozpoznania,
4. przepisane leki,
5. przeciwskazania do aktualnie zażywanych leków,
6. niekorzystne reakcje na leki,
7. dane o szczepieniach i surowicach,
8. dodatkowe dane o szczepieniach
9. implanty i ciała obce,
10. urazy i wypadki,
11. tętno,
12. waga,
13. wzrost,
14. ciśnienie,
11 z 60
15. informacja o ciąży rekonwalestencji, intensywnym treningu,
16. informacje o brakujących organach,
17. obciążenia dziedziczne,
18. hospitalizacje,
19. wyniki badao laboratoryjnych,
20. dane środowiskowe,
21. upoważnienia,
22. zastrzeżenia do stosowanych procedur,
23. certyfikat donora organów,
24. honorowy krwiodawca,
25. informacje o transfuzji,
26. niepełnosprawności,
27. dane kontaktowe osoby do kontaktu w nagłych przypadkach,
28. deklaracje POZ,
29. zdolnośd komunikacji
należy opisywad zgodnie z zestawem Entries zdefiniowanym w sekcji 2.3
W ramach pilotażu MSIM, z systemów dziedzinowych należy przysyład do lokalnych
systemów EDM co najmniej:
 karty informacyjne z leczenia szpitalnego,
 opisy wyników badao obrazowych,
 wyniki badao laboratoryjnych,
 skierowania,
 zlecenia,
 recepty, bądź informacje o zastosowanych lekach,
 opisy konsultacji medycznych,
 protokoły operacyjne.
3. Standard HL7 CDA
3.1. Opis standardu
Dokumenty medyczne przechowywane są w formacie zgodnym ze standardem HL7 CDA
(ang. Health Level Seven Clinical Document Architecture). Standard ten definiuje kwestie
związane ze składnią i semantyką dokumentów klinicznych. Bazuje on na języku XML (j. ang.
eXtensible Markup Language). Dokumenty HL7 CDA mogą składad się z wielu elementów
takich jak: tekst, obraz, dźwięk i inne multimedia.
Dokument CDA charakteryzują poniższe cechy:
1. Niezmiennośd (j. ang. persistence) – dokument kliniczny istnieje w niezmienionym
stanie przez okres czasu ustalony przez lokalne wymagania oraz regulacje prawne;
2. Zarządzanie (j. ang. stewardship) – dokument kliniczny jest utrzymywany przez osobę
lub organizację, której go powierzono;
3. Możliwośd uwierzytelniania (ang. potential for authentication) – dokument kliniczny
zawiera informacje konieczne do uwierzytelnienia;
12 z 60
4. Całośd (j. ang. wholeness) – uwierzytelnienie dokumentu klinicznego stosuje się
wyłącznie do jego całości, nie ma możliwości zastosowania uwierzytelnienia do części
dokumentu bez pełnego kontekstu tego dokumentu;
5. Czytelnośd (j. ang. readability) – dokument kliniczny jest czytelny dla człowieka.
Dokumenty HL7 CDA zdefiniowane są na trzech poziomach interoperacyjności:

Poziom 1: zawiera nagłówek CDA oraz nieustrukturyzowane ciało dokumentu, które
może byd tekstem (plain-text), bądź treścią (np. typu PDF, DOC, zeskanowanym
obrazem itp.)

Poziom 2: zawiera nagłówek CDA wraz z ciałem podzielonym na sekcje. Każda sekcja
zawiera kod i tytuł oraz opis. Opis może byd tekstem podlegającym dodatkowemu
formatowaniu (np. pogrubienie, pochylenie, lista numerowana, tabelka).

Poziom 3: stanowi rozszerzenie poziomu 2. Poza opisami dochodzą tzw. entries,
które niosą informację ustrukturyzowaną, umożliwiającą automatyczne
przetwarzanie treści dokumentu przez systemy informatyczne, w szczególności analizę semantyczną. Entries powinny byd budowane z wykorzystaniem modelu
referencyjnego HL7 RIM (Reference Information Model), oraz w ramach możliwości –
wykorzystywad skodyfikowane terminologie medyczne (np. LOINC, SNOMED, ICD-9,
ICD-10).
Przykładowymi dokumentami HL7 CDA mogą byd: skierowanie, recepta, karta wypisowa,
badania laboratoryjne, historia zdrowia i choroby.
3.2. Struktura dokumentu
Każdy dokument HL7 CDA dzielimy na dwie części: nagłówek (ang. header) oraz ciało (ang.
body).
3.2.1.
Nagłówek
Nagłówek dokumentu rozpoczyna się od znacznika XML <ClinicalDocument>, a kooczy
znacznikiem <structuredBody> lub <nonXMLBody>. Zawiera treści odpowiedzialne za
identyfikację dokumentu, takie jak numer identyfikacyjny systemu źródłowego, typ
dokumentu, numer wersji, język, czas wystawienia, tytuł oraz stopieo poufności. Ponadto
nagłówek zawiera informacje identyfikujące pacjenta, lekarza oraz inne osoby związane z
dokumentem, a także miejsce wystawienia tego dokumentu.
13 z 60
3.2.2.
Ciało dokumentu
Ciało na poziomie pierwszym znajduje się pomiędzy znacznikami <nonXMLBody> i
</nonXMLBody>. Na tym poziomie dane nie podlegają analizie semantycznej i są
przeznaczone jedynie do wyświetlania w nieustrukturyzowany sposób. Ciało dokumentu na
poziomie drugim i trzecim HL7 CDA znajduje się pomiędzy znacznikami <structuredBody> i
</structuredBody>. Zawiera raport medyczny podzielony na sekcje identyfikowane
odpowiednimi kodami ze standardowych słowników typu LOINC, SNOMED itp.
Każda sekcja w ciele dokumentu opakowana jest w znaczniki <section> i może
posiadad pojedynczy blok narracyjny znajdujący się w znaczniku <text>. Przechowuje on
informacje wyświetlane na poglądzie dokumentu. W bloku narracyjnym można
wykorzystywad tagi formatujące (opisane w rozdziale 3.2.3).
Na poziomie trzecim sekcja zawiera dodatkowo wejścia CDA (ang. entries),
podlegające analizie semantycznej. Każde entry opatrzone jest odpowiednim kodem ze
słowników medycznych. Istnieje możliwośd powiązania konkretnych entries pomiędzy sobą
oraz wiązania ich z fragmentami bloku narracyjnego. Wejścia CDA mogą także zawierad
referencje do zewnętrznych plików, np. skanów zdjęd. W celu zapewnienia rozszerzeo o
charakterze lokalnym, CDA umożliwia wykorzystanie dodatkowych elementów XML oraz
atrybutów niewyspecyfikowanych w standardzie. Rozszerzanie powinno byd robione w taki
sposób, aby jego ewentualne pominięcie czy nawet usunięcie nie miało wpływu na znaczenie
dokumentu. Typy danych (takie jak na przykład INTEGER, TIME STAMP, PQ) definiują
strukturę danych pozyskiwanych z atrybutów klas RIM i mają wpływ na możliwe wartości
atrybutów.
Opisaną koncepcję graficznie przedstawia poniższy rysunek:
14 z 60
Poziom 1
Poziom 2
Poziom 3
Nagłówek HL7 CDA
Nagłówek HL7 CDA
Nagłówek HL7 CDA
Ciało dokumentu
Bez struktury
Ciało dokumentu
Z podziałem na sekcje
Ciało dokumentu
Ustrukturyzowane
<section>
<section>
<entry>
<section>
<entry>
<section>
<entry>
<section>
<section>
3.2.3.
<section>
<section>
<entry>
<entry>
Tagi formatujące w blokach narracyjnych HL7CDA
Treści zamieszczane w blokach narracyjnych (wewnątrz tagu <text>) mogą byd czystym
tekstem, bądź wykorzystywad dodatkowe tagi, zgodnie z HL7 CDA. Są to m.in.:







<content>, będący logicznym odpowiednikiem HTMLowego <span>
<link>, będący logicznym odpowiednikiem HTMLowego <a>
<br> - do podziału linii
<paragraph>, będący logicznym odpowiednikiem HTMLowego <p>
<list listType=”ordered”>, będący logicznym odpowiednikiem HTMLowego <ol>
<list listType=”unordered”>, będący logicznym odpowiednikiem HTMLowego <ul>
<table>, będący logicznym (chod uproszczonym) odpowiednikiem HTMLowego
<table>
Tag <content> jest najczęściej wykorzystywany w celu:

wprowadzenia identyfikatora elementu (przy użyciu atrybutu ID) na potrzeby
odwołania się do tego elementu z poziomu Entry,

nadania stylu (przy pomocy atrybutu styleCode, przyjmującego wartości „Bold”,
„Italics”, bądź „Underline”).
15 z 60
3.2.4.
Implikacje wykorzystania standardu HL7 CDA
Charakter standardu HL7 CDA sprawia, że nie jest konieczne odgórne zdefiniowanie
sztywnych struktur dla poszczególnych typów dokumentów. Każdy system źródłowy,
produkujący dokumentację medyczną, może ją tworzyd na bazie własnej wiedzy
dziedzinowej, wprowadzając do dokumentu sekcje odpowiadające informacjom
uzupełnianym w aplikacji przez lekarza.
Takie dokumenty mogą byd następnie odczytywane za pośrednictwem uniwersalnej
przeglądarki dokumentacji HL7 CDA.
3.3.
HL7CDA - Entries
Specyfikacja P1 jest nadrzędna w stosunku do niniejszej. Oznacza to, że jeśli platforma P1
opublikuje alternatywny zestaw entries, należy traktowad je jako obowiązujące.
Niniejszy rozdział opisuje Entries – ustrukturyzowane informacje zamieszczane w
dokumentach HL7 CDA R2 na 3 poziomie interoperacyjności.
W przypadku gdy informacje opisane w tej sekcji, pojawiają się w dokumentach przesyłanych
do systemu EDM, zalecane jest wykorzystanie wpisów Entry. Dzięki temu takie dokument nie
tylko będzie można przeszukiwad i odczytywad w przeglądarce, ale także informacje z nich
pochodzące zostaną odpowiednio przetworzone i zaprezentowane (np. na zbiorczym widoku
z listą wszystkich rozpoznao).
Ogólne założenia:
 ważna jest kolejnośd elementów. (wymaganie HL7 CDA)
 jeśli któryś z elementów jest datą, zakładamy, że będzie ona podana w jednym z
następujących formatów: YYYY, YYYYMM, YYYYMMDD, YYYYMMDDHH,
YYYYMMDDHHMM, YYYYMMDDHHMMSS
 każdy atrybut bądź element powinien zostad wypełniony, w przypadku gdy jest
opcjonalny i nie zamierzamy go wypełniad, należy go usunąd (wymaganie HL7 CDA
R2).
3.3.1. Grupa krwi
Przykład:
<entry>
<observation classCode="OBS" moodCode="EVN">
<code code="278153001"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"
16 z 60
displayName="Grupa krwi AB Rh-" />
<effectiveTime value="201305221000" />
<text>Opcjonalny opis.</text>
</observation>
</entry>
Opis elementów:
 <code> - grupa krwi zakodowana w systemie SNOMED CT, możliwe wartości:
 nazwa: grupa krwi AB Rh minus
 kod: 278154007
 nazwa: grupa krwi AB Rh plus
 kod: 278151004
 nazwa: grupa krwi B Rh minus
 kod: 278153001
 nazwa: grupa krwi B Rh plus
 kod: 278150003
 nazwa: grupa krwi A Rh minus
 kod: 278152006
 nazwa: grupa krwi A Rh plus
 kod: 278149003
 nazwa: grupa krwi O Rh minus
 kod: 278148006
 nazwa: grupa krwi O Rh plus
 kod: 278147001
 <effectiveTime> – data wykonania badania
 <text> – (opcjonalny) dodatkowy opis
3.3.2. Alergie i uczulenia
Przykład:
<entry>
<code code="165014009"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT" displayName="pozytywny test na
alergię"/>
<text>Opis reakcji alergicznej.</text>
<effectiveTime value="200508291238"/>
<value xsi:type="ST">Nazwa alergii</value>
</observation>
</entry>
17 z 60
Opis elementów:
 <code> - stwierdzenie wystąpienia alergii, zakodowane w SNOMED CT:
 nazwa: pozytywny test na alergię
 kod: 165014009
 <text> - opis reakcji alergicznej
 <value> - nazwa alergii
 <effectiveTime> - data i czas stwierdzenia
3.3.3. Rozpoznania
Przykład:
<entry>
<code code="G36.9"
codeSystem="2.16.840.1.113883.6.3"
codeSystemName="ICD10"
displayName="Ostre rozsiane demielinizacje, nie określone">
<originalText>
<reference value="#_z1"/>
</originalText>
</code>
<entryRelationship typeCode="REFR">
<code code="90734009"
codeSystem="2.16.840.1.113883.6.96"
displayName="Przewlekle"/>
</observation>
</entryRelationship>
<code code="8319008"
codeSystem="2.16.840.1.113883.6.96"
displayName="Rozpoznanie główne"/>
</observation>
</observation>
</entry>
Opis elementów:
 <code> - rozpoznanie zakodowane w ICD10, wraz z opisem.
 <originalText> - (opcjonalne) referencja do części opisowej, która zawiera dane
18 z 60
rozpoznanie.
 <entryRelationship> - (opcjonalne) zawiera obserwację, w której zakodowana jest
informacja o przewlekłości danego rozpoznania. Kolejne to adnotacja, że rozpoznanie
jest główne lub dodatkowe. Możliwe wartości:
 nazwa: rozpoznanie główne
 kod: 8319008
 nazwa: rozpoznanie dodatkowe

kod: 85097005
3.3.4. Przepisany lek
Przykład:
<entry>
<templateId root="{oid_csioz}.13.4.1"/>
<substanceAdministration classCode="SBADM" moodCode="RQO">
<text><reference value="#SBADM_1"/></text>
<effectiveTime xsi:type="PIVL_TS">
<period value="12" unit="h"/>
</effectiveTime>
<doseQuantity value="1"/>
<consumable>
<manufacturedProduct>
<manufacturedLabeledDrug>
<code code="4321"
codeSystem="{oid_identyfikatory_lekow_RL}"
displayName="Enarenal 5mg tabletki"/>
</manufacturedLabeledDrug>
</manufacturedProduct>
</consumable>
<entryRelationship typeCode="COMP">
<supply xsi:type="extPL:Supply"
classCode="SPLY" moodCode="RQO">
<priorityCode code="UR"
codeSystem="2.16.840.1.113883.11.16866"/>
<independentInd value="false"/>
19 z 60
<quantity value="1"/>
<product>
<code code="5909990014958"
codeSystem="1.0.15418.0"
codeSystemName="GS1"
displayName="Enarenal 5mg
(60 tabl.)" />
</product>
<extPL:component typeCode="COMP">
<extPL:templateId root="{oid_csioz}.13.4.2"/>
<extPL:substitution classCode="SUBST"
moodCode="RQO">
<extPL:code code="N"
codeSystem="2.16.840.1.113883.11.16621"/>
</extPL:substitution>
</extPL:component>
<extPL:coverage typeCode="COVBY">
<extPL:templateId root="{oid_csioz}.13.4.3"/>
<extPL:coveragePlan classCode="COV" moodCode="EVN">
<extPL:code code="PUBLICPOL"
codeSystem="2.16.840.1.113883.11.19350">
<qualifier>
<name code="POLEKR"
codeSystem="{oid_plany_finansowania}"
displayName="Poziomy odpłatności
leków refundowanych"/>
<value code="R"
codeSystem="{oid_odplatnosci_leku}"/>
</qualifier>
</extPL:code>
</extPL:coveragePlan>
20 z 60
</extPL:coverage>
</supply>
</substanceAdministration>
</entry>
Opis elementów:
Zgodnie ze specyfikacją P1 (P1-DS-E6-IG_0.9.8_Reguły_20131212)
3.3.5. Przeciwskazania do aktualnie zażywanych leków
Przykład:
<entry>
<code code="103306004"
codeSystem="2.16.840.1.113883.6.96"
displayName="Przeciwwskazania"/>
<text>Opis przeciwskazań do aktualnie zażywanych leków oraz
inne</text>
</observation>
</entry>
Opis elementów:
 <code> - zakodowana informacja o tym, że entry dotyczy przeciwwskazania. Dozwolony
kod:
 nazwa: przeciwwskazanie
 kod: 103306004
 <text> - tekstowy opis przeciwwskazania
 <effectiveTime> - data i czas wpisania przeciwwskazania
3.3.6. Niekorzystne reakcje na leki
Przykład:
<entry>
<code code="62014003"
codeSystem="2.16.840.1.113883.6.96"
21 z 60
displayName="Działanie niepożądane na lek"/>
<text>Opis nieporządanego działania na lek.</text>
<substanceAdministration classCode="SBADM"
moodCode="EVN">
<code code="297181003"
codeSystem="2.16.840.1.113883.6.96"
displayName="Substancja czynna"/>
<consumable>
<name>Sodium chloride</name>

</consumable>
<entryRelationship typeCode='REFR'>
moodCode="EVN">
<code code="718891000000103"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT" displayName="Lek"/>
<consumable>
<code code="9876"
codeSystem="EAN"
displayName="Aspirin, tabl. 500 mg,."/>
<name>Aspirin, tabl. 500 mg,.</name>
</consumable>
</observation>
</entry>
Opis elementów:
<code> - zakodowana informacja o tym, że entry dotyczy niekorzystnych reakcji na leki. Dozwolony kod:
22 z 60
 nazwa: Działanie niepożądane na lek
 kod: 62014003
 <text> - Opis niepożądanego działania na lek
 <entryRelationship> - zagnieżdżone entries, zawierają nazwę substancji czynnej, oraz
leku.
3.3.7. Dane o szczepieniach i surowicach
Przykład:
<entry>
<procedure classCode="PROC" moodCode="EVN">
<code code="425457005"
codeSystem="2.16.840.1.113883.6.42"
displayName="Odbyte szczepienie"/>
<text>99.33 Szczepienie przeciw gruźlicy</text>
<effectiveTime value="201304021838"/> 
moodCode="EVN">
<consumable>
<name>ENGERiX B</name>

</consumable>
<code code="263760002"
codeSystem="2.16.840.1.113883.6.96"
displayName="Przymusowe"/>
<value xsi:type="BL" value="true"/>
</observation>
<code code="419492006"
23 z 60
codeSystem="2.16.840.1.113883.6.96"
displayName="Informacje o dawkowaniu"/>
<value xsi:type="ST">Podstawowe 1</value>
</observation>
</procedure>
</entry>
Opis elementów:




<text> - tekstowy opis wykonanej procedury
<effectiveTime> - data i czas wykonania szczepienia
<entryRelationship><substanceAdministration> - nazwa szczepionki
<entryRelationship> - zawierają informacje obligatoryjności danego szczepienia, oraz
numerze dawki. Wykorzystywane kody:
 nazwa: Informacje o dawkowaniu
 kod: 419492006
 nazwa: przymusowe

kod: 263760002
3.3.8. Dodatkowe dane o szczepieniach
Przykład:
<entry>
<code code="408864009"
codeSystem="2.16.840.1.113883.6.42"
displayName="Status szczepień"/>
<text>99.33 Szczepienie przeciw gruźlicy</text>
<code code="263760002"
codeSystem="2.16.840.1.113883.6.96"
displayName="Przymusowe"/>
</observation>
<code code="37361000000105"
24 z 60
codeSystem="2.16.840.1.113883.6.96"
displayName="Dodatkowe uwagi"/>
<value xsi:type="ST">Dodatkowe uwagi</value>
</observation>
</procedure>
</entry>
Opis elementów:
 <text> - Nazwa planowanego szczepienia (np.: szczepienie przeciwko gruźlicy)
 <effectiveTime> - data nadchodzącego szczepienia
 <entryRelationship> - określa czy szczepienie jest obligatoryjne oraz zawiera
dodatkowe uwagi dotyczące szczepienia.
3.3.9. Implanty i ciała obce
Przykład:
<entry>
<id extension="Rozrusznik serca"/>
<code code="125670008"
codeSystem="2.16.840.1.113883.6.96"
displayName="ciało obce"/>
<text>Opcjonalny opis.</text>
</procedure>
</entry>
Opis elementów:
 <id> - nazwa implantu bądź ciała obcego
 <code> - kod określający typ entry, możliwe wartości:
 nazwa: ciało obce
 kod: 125670008
 <text> - (opcjonalne) opcjonalny opis
 <effectiveTime> - data i czas operacji
3.3.10. Urazy i wypadki
Przykład:
25 z 60
<entry>
<code code="243793001"
codeSystem="2.16.840.1.113883.6.96"
displayName="Badanie powypadkowe"/>
<text>Opis badania</text>
</observation>
</entry>
Opis elementów:
 <code> -zakodowana informacja o tym, że mamy do czynienia z wypadkiem lub
urazem, możliwe wartości:
 nazwa: Badanie pourazowe
 kod: 225163008
 nazwa: Badanie powypadkowe
 kod: 243793001
 <text> - opis urazu/wypadku
 <effectiveTime> - data i czas badania
3.3.11. Tętno
Przykład:
<entry>
<code code="364075005"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT" displayName="Tętno"/>
<effectiveTime value="201307111430"/> 
<value xsi:type="RTO_PQ_PQ">
<numerator value="88"/>
<denominator value="1" unit="min"/>
</value>
</observation>
</entry>
Opis elementów:
 <code> - Oznaczenie tętna, możliwe wartości:
 Nazwa: tętno
 kod: 364075005
 <effectiveTime> - data pomiaru
26 z 60
 <value> - wynik pomiaru
3.3.12. Waga
Przykład:
<entry>
<code code="27113001"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT" displayName="Waga"/>
<value xsi:type="PQ" value="94" unit="kg"/>
</observation>
</entry>
Opis elementów:
 <code> - oznaczenie wagi za pomocą słownika SNOMED CT, możliwe wartości:
 nazwa: waga
 kod: 27113001
 <value> - wynik pomiaru w [kg]
3.3.13. Wzrost
Przykład:
<entry>
<code code="50373000"
codeSystem="2.16.840.1.113883.6.96"
displayName="Wzrost"/>
<value xsi:type="PQ" value="172" unit="cm"/>
</observation>
</entry>
Opis elementów:
 <code> - oznaczenie wzrostu za pomocą słownika SNOMED CT, możliwe wartości:
 nazwa: wzrost

kod: 50373000
27 z 60
 <value> - wynik pomiaru
3.3.14. Ciśnienie
Przyklad:
<entry>
<code code="251076008"
codeSystem="2.16.840.1.113883.6.96"
displayName="Nieinwazyjny pomiar ciśnienia"/>
<code code="271649006"
codeSystem="2.16.840.1.113883.6.96"
displayName="ciśnienie skurczowe"/>
<value xsi:type="PQ" value="132" unit="mm[Hg]"/>
</observation>
<code code="271650006"
codeSystem="2.16.840.1.113883.6.96"
displayName="ciśnienie rozkurczowe"/>
<value xsi:type="PQ" value="86" unit="mm[Hg]"/>
</observation>
</observation>
</entry>
Opis elementów:
 <code> - oznaczenie ciśnienia za pomocą słownika SNOMED CT, możliwe wartości:
 nazwa: nieinwazyjny pomiar ciśnienia
 kod: 251076008
 <effectiveTime> - data i czas wykonania pomiaru
 <entryRelationship> - zawierają informacje o przeprowadzonym pomiarze, możliwe
28 z 60
wartości:
 nazwa: ciśnienie skurczowe
 kod: 271649006
 nazwa: ciśnienie rozkurczowe

kod: 271650006
3.3.15. Informacja o ciąży rekonwalestencji, intensywnym treningu,
Przykład:
<entry>
<code code="255409004"
codeSystem="2.16.840.1.113883.6.1"
displayName="kobieta w ciąży"/>
<text>Opcjonalny dodatkowy opis.</text>
</observation>
</entry>
Opis elementów:
 <code> - specyficzny stan zdrowia zakodowany w systemie SNOMED CT. Dozwolone
kody:
 nazwa: Kobieta w ciąży
 kod: 255409004
 nazwa: Rekonwalescencja
 kod: 105499002
 nazwa: Intensywny trening
 kod: 21407008
 <text> - opcjonalny opis
 <effectiveTime> - w przypadku oznaczenia kobiety w ciąży, data ostatniej miesiączki.
W pozostałych przypadkach czas rozpoczęcia.
3.3.16. Informacje o brakujących organach
Przykład:
<entry>
<code code="371640009"
codeSystem="2.16.840.1.113883.6.1"
displayName="Brakujące organy"/>
29 z 60
<text>Opcjonalny dodatkowy opis.</text>
<value xsi:type="ST">Nerka</value>
</observation>
</entry>
Opis elementów:
 <code> - określa typ entry poprzez zakodowaną wartośd przy użyciu SNOMED CT,
możliwe wartości:
 nazwa: brakujący organ
 kod: 371640009
 <text> - opcjonalny, dodatkowy opis.
 <effectiveTime> - data i czas utraty/operacji
 <value> - nazwa brakującego organu
3.3.17. obciążenia dziedziczne
Przykład:
<entry>
<code code="102486008"
codeSystem="2.16.840.1.113883.6.96"
displayName="obciążenia dziedziczne"/>
<value xsi:type="ST">opis zaobserwowanego obiciążenia</value>
<subject>
<relatedSubject classCode="PRS">
<code code="FTH" codeSystem="2.16.840.1.113883.5.111"/>
</relatedSubject>
</subject>
</observation>
</entry>
Opis elementów:
 <code> - określa typ entries, poprzez zakodowaną wartośd w SNOMED CT, możliwe
wartości:
 nazwa: obciążenie dziedziczne
 kod: 102486008
 <effectiveTime> - data i czas obserwacji
 <value> - opis zaobserwowanego obciążenia
 <subject> - zakodowana relacja (oid słownika 2.16.840.1.113883.5.111) z osobą u
30 z 60
której występuje choroba dziedziczna.
3.3.18. Hospitalizacje
Przykład:
<entry typeCode="COMP">
<encounter classCode="ENC" moodCode="EVN">
<id extension="Szpital Specjalistyczny"/>
<text> ODDZIAŁ ANESTEZJOLOGII I INTENSYWNEJ TERAPII</text>
<effectiveTime>
<low value="20060326"/>
<high value="20060329"/>
</effectiveTime>
<code code="G36.9"
codeSystem="2.16.840.1.113883.6.3"
codeSystemName="ICD10"
displayName="Ostre rozsiane demielinizacje,
nie określone"/>
</observation>
</encounter>
</entry>
Opis elementów:




<id> - nazwa placówki
<text> - nazwa oddziału
<effectiveTime> - data początku i zakooczenia hospitalizacji
<entryReltionship> - rozpoznanie główne
3.3.19. Wyniki badao laboratoryjnych
Przykład:
<entry>
<code code="C53.03-0"
codeSystem="c0bba240-5043-11e3-aa4d-0002a5d5c51b"
codeSystemName="WEW_BAD" displayName="Hemoglobina">
<originalText>
<reference value="#r0_1"/>
31 z 60
</originalText>
</code>
<effectiveTime>
<low value="201304021838"/>
<high value="201304031338"/>
</effectiveTime>
<value xsi:type="PQ" unit="g/dl" value="1.025"/>
<referenceRange>
<observationRange>
<value unit="g/dl" xsi:type="IVL_PQ">
<low value="1.015"/>
<high value="1.03"/>
</value>
</observationRange>
</referenceRange>
</observation>
</entry>
Opis elementów:
 <code> - typ badania zakodowany w jednym z dostępnych słowników.
 <code><originalText> - referencja do części opisowej w której znajduje się wynik
badania.
 <effectiveTime> - czas i data pobrania próbki oraz czas i data wykonania badania.
 <value> - wynik badania.
 <referenceRange> - (opcjonalnie) zakres referencyjny badania.
3.3.20. Dane środowiskowe
Przykład:
<entry>
<code code="2658000"
codeSystem="2.16.840.1.113883.6.96"
displayName="Wywiad środowiskowy z pacjentem"/>
<effectiveTime>
<low value="201304031338"/>
<high value="201304031338"/>
</effectiveTime>
32 z 60
<code code="273302005"
codeSystem="2.16.840.1.113883.6.96"
displayName="Ocena pacjenta wg skali Barthel"/>
<value xsi:type="INT" value="5"/>
</observation>
</observation>
</entry>
Opis elementów:
 <code> - zakodowana wartośd, oznaczająca że entry dotyczy wywiadu
środowiskowego. Możliwe wartości:
 nazwa: dane środowiskowe
 kod: 2658000
 <effectiveTime> (opcjonalne)
 <low> - (opcjonalna) data wywiadu
 <high> - (opcjonalna) data zakooczenia terminu opieki środowiskowej
 <value> - wartośd typu bool, definiuje czy pacjent został zakwalifikowany do objęcia
opieką środowiskową
 <entryRelationship> - zawiera informacje o ocenie pacjenta wg skali Barthel
3.3.21. Upoważnienie
Przykład:
<entry>
<id root="1.2.616.1.999999.1.1.616" extension="83038493845"/>
<code code="867131000000109"
codeSystem="2.16.840.1.113883.6.96"
displayName="Udzielanie pisemnej
udostępniania informacji"/>
<text>Upoważnienie
medycznej.
jednorazowe
do
informacji
wydania
na
temat
dokumentacji
</text>
 
<subject>
<relatedSubject>
<code code="POWATT"
codeSystem="2.16.840.1.113883.5.111"
displayName="POWATT"/>
<addr>
33 z 60
<postalCode>31-333</postalCode>
<city>Warszawa</city>
<houseNumber>3</houseNumber>
<streetName>Nowa</streetName>
<postBox>Warszawa</postBox>
</addr>
<subject>
<name>
<given>Roman</given>
<family>Kurzuk</family>
</name>
</subject>
</relatedSubject>
</subject>
</procedure>
</entry>
Opis elementów:
 <id> - PESEL i/lub numer dokumentu osoby upoważnianej. (opcjonalne)
 <code> - zakodowana informacja o typie entries
 nazwa: Udzielanie pisemnej informacji na temat udostępniania informacji
 kod: 867131000000109
 <text> - treśd upoważnienia
 <effectiveTime> - jeśli upoważnienie jest czasowe, element zawiera datę do kiedy jest
ono ważne (opcjonalne)
 <subject> - informacje o osobie upoważnionej
3.3.22. Zastrzeżenia do stosowanych procedur
Przykład:
<entry>
<code code="427681000000103"
codeSystem="2.16.840.1.113883.6.96"
displayName="Zastrzeżenia do stosowanych procedur"/>
<value xsi:type="ST">Pacjent nie wyraża zgody na transfuzję ze
względów religijnych.</value>
</observation>
</entry>
Opis elementów:
34 z 60
 <code> - zakodowana informacja o type entries
 nazwa: zastrzeżenia do stosowanych procedur
 kod: 427681000000103
 <effectiveTime> - data dodania zastrzeżenia
 <value> - treśd zastrzeżenia
3.3.23. Certyfikat donora organów
Przykład:
<entry>
<code code="443564001"
codeSystem="2.16.840.1.113883.6.96"
displayName="Certyfikat donora organów"/>
<value xsi:type="ST">Wyrażam zgodę na pobranie
moich tkanek i narządów do przesczepienia.</value>
po
śmierci
</observation>
</entry>
Opis elementów:
 nazwa: certyfikat donora organów
 kod: 443564001
 <effectiveTime> - data dostarczenia zgody
 <value> - treśd zgody
3.3.24. Honorowy krwiodawca
Przykład:
<entry>
<code code="465391000000107"
codeSystem="2.16.840.1.113883.6.96"
displayName="Honorowy krwiodawca"/>
</observation>
</entry>
35 z 60
Opis elementów:
 nazwa: Honorowy krwiodawca
 kod: 465391000000107
 <effectiveTime> - data wprowadzenia informacji
 <value> - true|false
3.3.25. Informacje o transfuzji
Przykład:
<entry>
<code code="250373003"
codeSystem="2.16.840.1.113883.6.96"
displayName="Dane o transfuzji krwi"/>
<value xsi:type="ST">opis transfuzji krwi</value>
</observation>
</entry>
Opis elementów:
 nazwa: dane o transfuzji krwi
 kod: 250373003
 <value> - opis dotyczący transfuzji
3.3.26. Niepełnosprawności
Przykład:
<entry>
<code code="21134002"
codeSystem="2.16.840.1.113883.6.96"
displayName="Niepełnosprawności"/>
<value xsi:type="ST">opis niepełnosprawności</value>
</observation>
36 z 60
</entry>
Opis elementów:
 <code> - zakodowana informacja o type entries
 nazwa: Niepełnosprawności
 kod: 21134002
 <value> - opis niepełnosprawności
3.3.27. Dane kontaktowe osoby do kontaktu w nagłych przypadkach
Przykład:
<entry>
<code code="70862002"
codeSystem="2.16.840.1.113883.6.96"
displayName="Dane kontaktowe osoby do kontaktu w nagłych
przypadkach"/>
<informant typeCode="INF" contextControlCode="OP">
<relatedEntity classCode="PRS">
<addr>
<city>Kraków </city>
<streetName>Budryka</streetName>
<postBox>Kraków </postBox>
<unitID>7</unitID>
</addr>
<telecom value="500600700"/>
<relatedPerson classCode="PSN"
determinerCode="INSTANCE">
<name>Genowefa Kłycz</name>
</relatedPerson>
</relatedEntity>
</informant>
</observation>
</entry>
Opis elementów:
37 z 60
 <id> - PESEL osoby upoważnionej (opcjonalne)
 nazwa: Dane kontaktowe osoby do kontaktu w nagłych przypadkach
 kod: 70862002
 <informant> - dane kontaktowe osoby do kontaktu w nagłych przypadkach
3.3.28. Deklaracje POZ
Przykład:
<entry>
<code code="62247001"
codeSystem="2.16.840.1.113883.6.96"
displayName="Lekarz pierwszego kontaktu"/>
<informant typeCode="INF" contextControlCode="OP">
<relatedEntity classCode="PRS">
<addr>
<city>Kraków-Nowa Huta</city>
<streetName>Kolorowa</streetName>
<postBox>Kraków-Krowodrza</postBox>
<unitID>5</unitID>
</addr>
<telecom value="501600700"/>
<relatedPerson classCode="PSN"
determinerCode="INSTANCE">
<name>Jan Nowakowski</name>
</relatedPerson>
</relatedEntity>
</informant>
</observation>
</entry>
Opis elementów:
 <id> - pesel lekarza, pielęgniarki lub położnej (opcjonalny)
 <code> - zakodowana informacja o typie wybieranego specjalisty:
 nazwa: 62247001
 kod: lekarz pierwszego kontaktu
 nazwa: położna
38 z 60
 kod: 309453006
 nazwa: 170939002
 kod: pielęgniarka
 <informant> - dane wybieranego lekarza, pielęgniarki lub położnej
3.3.29. Zdolnośd komunikacji
Przykład:
<entry>
<code code="118230007"
codeSystem="2.16.840.1.113883.6.1"
displayName="Jakość słuchu"/>
<text>Słuch w normie</text>
</observation>
</entry>
Opis elementów:
 <code>
 nazwa: zdolnośd komunikacji
 kod: 288574004
 nazwa: jakośd słuchu
 kod: 118230007
 nazwa: języki
 kod: 284530008
 nazwa: jakośd wzroku
 kod: 118235002
 <text> - opis jakości komunikacji lub informacji o językach którymi posługuje się pacjent
3.4.
Spis kodów identyfikujących poszczególne sekcje
Do określania typu sekcji, zalecane jest stosowanie systemu kodyfikacji SNOMED CT.
Poniższa tabela prezentuje przykładowe typy sekcji wraz z kodami.
TYP SEKCJI
KOD
SYSTEM KODYFIKACJI
39 z 60
TYP SEKCJI
KOD
SYSTEM KODYFIKACJI
Przyczyna/cel skierowania
716101000000104
SNOMED CT
Miejsce skierowania
257557008
SNOMED CT
Badanie fizykalne
5880005
SNOMED CT
Epikryza wypisowa
250171008
SNOMEC CT
Leczenie
716151000000103
SNOMED CT
Personel
303118004
SNOMED CT
Procedury
887171000000109
SNOMED CT
Wywiad
723941000000100
SNOMED CT
Zalecenia
424900004
SNOMED CT
Zastosowane leczenie
182991002
SNOMED CT
Grupa krwi
365636006
SNOMED CT
Alergia
165014009
SNOMED CT
Rozpoznanie
439401001
SNOMED CT
Leki
228011000000101
SNOMED CT
Ogólna charakterystyka
pacjenta
363789004
SNOMED CT
Przeciwwskazania
103306004
SNOMED CT
Działania niepożądane na lek
62014003
SNOMED CT
Odbyte szczepienie
425457005
SNOMED CT
Status szczepieo
408864009
SNOMED CT
Ciała obce/Implanty
125670008
SNOMED CT
Brakujące organy
371640009
SNOMED CT
Obciążenia dziedziczne
102486008
SNOMED CT
Badanie powypadkowe
225163008
SNOMED CT
Badanie pourazowe
225163008
SNOMED CT
40 z 60
TYP SEKCJI
KOD
SYSTEM KODYFIKACJI
Hospitalizacje
32485007
SNOMED CT
Dane środowiskowe
273302005
SNOMED CT
Badania laboratoryjne
429361000000107
SNOMED CT
Udzielanie pisemnej zgody na
temat udostępniania informacji
867131000000109
SNOMED CT
Zastrzeżenia do stosowanych
procedur
427681000000103
SNOMED CT
Certyfikat donora organów
443564001
SNOMED CT
Honorowy krwiodawca
465391000000107
SNOMED CT
Dane o transfuzji krwi
250373003
SNOMED CT
Niepełnosprawności
21134002
SNOMED CT
Dane kontaktowe osoby do
kontaktu w nagłych
przypadkach
70862002
SNOMED CT
Deklaracje POZ
91971000000101
SNOMED CT
Zdolności komunikacji
288574004
SNOMED CT
Opis wyników badao
diagnostycznych
i konsultacji
163081000000108
SNOMED CT
Opis zastosowanego
farmakologicznego
430061000000102
SNOMED CT
Zalecana dieta
230125005
SNOMED CT
Leki przepisane na receptach
182817000
SNOMED CT
Wydane zaświadczenia
308707006
SNOMED CT
Orzeczenie o niezdolności do
pracy
18381000000107
SNOMED CT
Skierowania
440379008
SNOMED CT
Rodzaj wizyty
325851000000107
SNOMED CT
41 z 60
TYP SEKCJI
KOD
SYSTEM KODYFIKACJI
Dodatkowe informacje
37361000000105
SNOMED CT
3.5.
Spis kodów dla sekcji opisujących różne rodzaje badao obrazowych
KOD LOINC
RODZAJ BADANIA OBRAZOWEGO
18747-6
CT
18755-9
MRI
18760-9
USG
18757-5
Medycyna nuklearna
18758-3
PET
11522-0
Echokardiografia
18782-3
Rentgen
18752-6
Test wysiłkowy
18754-2
Holter
11524-0
ECG
18748-4
Mammografia
3.6.
Przykładowe kody LOINC dla wybranych typów dokumentów
KOD LOINC
TYP DOKUMENTU
67852-4
Przyjęcie pacjenta do szpitala
57057-2
Karta obserwacji przebiegu porodu
34104-0
Konsultacje lekarskie
34105-7
Zalecenia
28623-7
Karta indywidualnej opieki pielęgniarskiej
68564-4
Karta indywidualnej opieki prowadzonej przez położną
57057-2
Karta obserwacji przebiegu porodu
42 z 60
KOD LOINC
TYP DOKUMENTU
11485-0
Karta przebiegu znieczulenia
28579-1
Karta zabiegów fizjoterapeutycznych
34111-5
Karta medycznych czynności ratunkowych
34104-0
Wyniki konsultacji
64292-6
Upoważnienie do uzyskiwania dokumentacji medycznej pacjenta
64292-6
Upoważnienie do uzyskiwania informacji o stanie zdrowia pacjenta
64298-3
Zgoda lub zezwolenie dla sądu opiekuoczego
18743-5
Protokół badania sekcyjnego
68560-2
Karta przebiegu ciąży
11488-4
Konsultacje
28570-0
Zabiegi Lub operacje
11488-4
Porady ambulatoryjne lub wizyty domowe
28623-7
Karta indywidualnej opieki pielęgniarskiej
68683-2
Karta noworodka
34836-7
Karta pacjenta
64286-8
Karta zlecenia
68564-4
Karta indywidualnej opieki prowadzonej przez położną
57133-1
Zlecenie na świadczenia zdrowotne realizowane poza szpitalem
68472-0
Karta informacyjna z leczenia szpitalnego
34878-9
Karta medycznych czynności ratunkowych
68817-6
Książeczka zdrowia dziecka
57833-6
Recepta
34140-4
Skierowanie do szpitala lub innego podmiotu leczniczego
57133-1
Skierowanie na konsultację
57161-2
Skierowanie na rehabilitację leczniczą
43 z 60
KOD LOINC
TYP DOKUMENTU
34140-4
Skierowanie do
opiekuoczego
52063-5
Zlecenie zaopatrzenia w przedmioty ortopedyczne
57829-4
Zlecenie zaopatrzenia w środki pomocnicze
11502-2
Badanie laboratoryjne
18842-5
Historia zdrowia i choroby - ambulatoryjna
18748-4
Badanie obrazowe
X-2003
Zwolnienie lekarskie
X-2005
Zaświadczenie lekarskie
X-2007
Karta zgody i oświadczeo
X-2009
Dane rejestrowane o zdrowiu samodzielnie przez pacjenta
3.7.
zakładu
opiekuoczo-leczniczego
lub
pielęgnacyjno-
Obsługiwane kody słownika 2.16.840.1.113883.5.111
KOD
Rola
FTH
Ojciec
MTH
Matka
GRPRN
Dziadek/Babka
GGRPRN
Pradziadek/Prababka
44 z 60
4. Specyfikacja interfejsów komunikacyjnych e-Rejestracja
4.1. Komunikacja HIS -> e-Rejestracja
Usługa
umożliwiająca
przesłanie
do
Portalu
Pacjenta
informacji
utworzeniu/zmianie/usunięciu grafiku, rezerwacji lub kolejki w systemie HIS
4.1.1.
Grafik
Cecha
Opis
Nazwa logiczna usługi
Opis
Grafik
Zasób RESTowy służący do zarządzania grafikiem przez system
HIS:
 Utworzenie grafiku
 Modyfikacja grafiku
 Usunięcie grafiku
 Utworzenie blokady na grafiku
 Usunięcie blokadu z grafiku
Interval
Usługa sieciowa
JSON, XML, CSV
Nazwa fizyczna usługi
Rodzaj interfejsu
Format pobieranych
danych
Protokół komunikacyjny
Sposób publikacji danych
Kodowanie znaków
HTTP / REST / SOAP
On-line
UTF-8
Nazwa metody
POST/PUT/DELETE
4.1.1.1.
o
Metoda tworząca grafik
Cecha
Opis
Opis
Struktura adresu (url
structureS)
Parametry wejściowe
(query)
(body)
Tworzy grafik
PUT /system/{ SystemGUID }/interval
{ SystemGUID } – globalny identyfikator placówki
(wymagany)
{
"intervalUID" : "11111",
"organizationUnitGUID" : "0f8fad5bd9cb-469f-a165-708677289501",
"staffGUID" : "0f8fad5b-d9cb-469f-a165708677289502",
"roomUID" : "22222",
"day" : "20131227",
"beginTime" : "0000",
"endTime" : "2400",
45 z 60
Cecha
Opis
"slotDuration" : "15",
"serviceTypes" : [
"0f8fad5b-d9cb-469f-a165708677289503",
"0f8fad5b-d9cb-469f-a165708677289504"
],
“payerCodes”:[
“nfz”
],
"externalRegistration" : true,
"externalRegistrationLimit" : 10
}
gdzie:
• intervalUID - identyfikator grafiku w systemie HIS
• organizationUnitGUID - globalny identyfikator komórki
organizacyjnej
• staffGUID - globalny identyfikator lekarza
• roomUID - wewenętrzny identyfikator pomieszczenia w
systemie HIS
• day - data tworzonego grafiku w formacie YYYYMMDD,
gdzie YYYY oznacza rok, MM oznacza miesiąc, DD oznacza
dzieo
• beginTime - czas rozpoczęcia grafiku w formacie HHMM,
gdzie HH oznacza godzinę (00-23), MM minutę (00-59)
• endTime - czas zakooczenia grafiku w formacie HHMM,
gdzie HH oznacza godzinę (00-24), MM minutę (00-59) oraz
"2400" oznacza koniec danego dnia
• slotDuration - średni czas trwania wizyty/usługi w ramach
grafiku wyrażony w minutach
• serviceTypes - tablica globalnych identyfikatorów
wizyt/usług, które mogą byd planowane w grafiku
• payerCodes - tablica kodów identyfikujących możliwe
sposoby płatności za usługę wykonaną w ramach grafiku.
Niezbędny jest co najmniej jeden kod. Możliwe kody to:
„commercial” – za usługę zapłaci pacjent
„nfz” – usługa w ramach NFZ,
• externalRegistration - flaga informująca o możliwości
rezerwacji wizyt/usług z Portalu Pacjenta
• externalRegistrationLimit - liczba informująca o
maksymalnej ilości rezerwacji wizyt/usług z Portalu
Pacjenta
Statusy odpowiedzi
202 – komunikat został przyjęty
46 z 60
4.1.1.2.
Metoda modyfikująca grafik
Cecha
Opis
Opis
structure)
(query)
(body)
Modyfikuje grafik
POST /system/{ SystemGUID }/interval/{ IntervalUID }
{ SystemGUID } – globalny identyfikator placówki (wymagany)
{ IntervalUID } – identyfikator grafiku w systemie HIS
{
"roomUID" : "22222",
"day" : "20131227",
"endTime" : "2400",
"slotDuration" : "15",
"serviceTypes" : [
"0f8fad5b-d9cb-469f-a165708677289503",
"0f8fad5b-d9cb-469f-a165708677289504"
],
“payerCodes”:[
“commercial”
],
"externalRegistration " : true,
"externalRegistrationLimit" : 10,
"eventsAutoUpdate " : false
}
gdzie:
systemie HIS
dzieo
• slotDuration - średni czas trwania wizyty/usługi w ramach
grafiku wyrażony w minutach
• serviceTypes - tablica globalnych identyfikatorów
wizyt/usług, które mogą byd planowane w grafiku
• payerCodes - tablica kodów identyfikujących możliwe
sposoby płatności za usługę wykonaną w ramach grafiku.
47 z 60
Niezbędny jest co najmniej jeden kod. Możliwe kody to:
„commercial” – za usługę zapłaci pacjent
„nfz” – usługa w ramach NFZ,
• externalRegistration - flaga informująca o możliwości
rezerwacji wizyt/usług z Portalu Pacjenta
• externalRegistrationLimit - liczba informująca o
maksymalnej ilości rezerwacji wizyt/usług z Portalu
Pacjenta
• eventsAutoUpdate - flaga informująca o automatycznym
propagowaniu zmian (np. zmiana lekarza, pomieszczenia)
w grafiku do zarezerowanych w nim wizyt/usług
Statusy odpowiedzi
4.1.1.3.
Metoda usuwająca grafik
Cecha
Opis
Opis
structure)
(query)
Usuwa grafik
DELETE /system/{ SystemGUID }/interval/{
IntervalUID }
(body)
(wymagany)
{
"eventsAutoUpdate" : true
}
gdzie:
• eventsAutoUpdate - flaga informująca o automatycznym
usunięciu rezerwacji w usuwanym grafiku
Statusy odpowiedzi
4.1.1.4.
Metoda blokująca przedział czasowy w grafik
Cecha
Opis
Opis
structure)
(query)
Dodaje blokadę na grafiku
PUT /system/{ SystemGUID }/interval/{
IntervalUID }/lock
(body)
(wymagany)
{
"endTime" : "1400"
}
48 z 60
Cecha
Opis
gdzie:
Statusy odpowiedzi
4.1.1.5.
Metoda odblokowująca przedział czasowe w grafiku
Cecha
Opis
Opis
structure)
(query)
Usuwa blokadę z grafiku
DELETE /system/{ SystemGUID }/interval/{
IntervalUID }/lock
(body)
(wymagany)
{
"endTime" : "1400",
}
gdzie:
Statusy odpowiedzi
4.1.2.
Rezerwacja
Cecha
Opis
Opis
Rezerwacja
Zasób RESTowy służący do zarządzania rezerwacjami z
systemu HIS:
 Zaplanowanie zdarzenia (system HIS)
 Przeplanowanie zdarzenia (system HIS)
 Anulowanie zdarzenia
Event
Usługa sieciowa
Rodzaj interfejsu
49 z 60
Cecha
Opis
Format pobieranych
danych
JSON, XML, CSV
Kodowanie znaków
HTTP / REST / SOAP
On-line
UTF-8
Nazwa metody
POST/PUT/DELETE
4.1.2.1.
Metoda tworząca rezerwacje
Cecha
Opis
Opis
structure)
(query)
(body)
Rezerwacja z systemu HIS
PUT /system/{ SystemGUID }/event
(wymagany)
{
"eventUID" : "33333",
"patientUID" : "44444",
"patientGUID" : ""0f8fad5b-d9cb-469fa165-708677289505"",
"serviceTypeGUID" : "0f8fad5b-d9cb469f-a165-708677289516",
"roomUID" : "22222",
"day" : "20131227",
"endTime" : "2400",
"externalRegistered" : true,
“notify” : true,
“notificationTarget” : “500500500”
}
gdzie:
• eventUID - identyfikator rezerwacji w systemie HIS
• patientUID - identyfikator pacjenta w systemie HIS
• patientGUID - globalny identyfikator pacjenta
• serviceTypeGUID - globalny identyfikator usługi
organizacyjnej
systemie HIS
50 z 60
Cecha
Opis
dzieo
• externalRegistered - flaga informująca czy termin został
zarejestrowany z Portalu Pacjenta
 notify – flaga informująca czy informowad pacjenta, za
pomocą bramki sms, o terminie
 notificationTarget – numer telefonu komórkowego
pacjenta, na który należy wysład sms z powiadomieniem.
Statusy odpowiedzi
4.1.2.2.
Metoda modyfikująca rezerwacje
Cecha
Opis
Opis
structure)
(query)
Modyfikacja rezerwacji przez system HIS
POST /system/{ SystemGUID }/event/{
EventUID }
(body)
(wymagany)
{ EventUID } –identyfikator rezerwacji w systemie HIS
(wymagany)
{
"roomUID" : "22222",
"day" : "20131227",
"endTime" : "2400",
"reason" : "Zepsuty aparat
diagnostyczny"
}
gdzie:
systemie HIS
51 z 60
Cecha
Opis
dzieo
• reason - powód przeplanowania
Statusy odpowiedzi
Metoda anulująca rezerwacje
4.1.2.3.
Cecha
Opis
Opis
structure)
(query)
Usunięcie rezerwacji przez system HIS
DELETE /system/{ SystemGUID }/event/{
EventUID }
(body)
Statusy odpowiedzi
4.1.3.
(wymagany)
(wymagany)
{
"reason" : "Lekarz odwołał wizytę"
}
Kolejka
Cecha
Opis
Opis
Rodzaj interfejsu
Format pobieranych
danych
Kolejka
Zasób RESTowy służacy do aktualizacji stanu kolejki
Queue
Usługa sieciowa
JSON, XML, CSV
Kodowanie znaków
HTTP / REST / SOAP
On-line
UTF-8
Nazwa metody
POST/PUT/DELETE
52 z 60
4.1.3.1.
Metoda tworząca kolejkę
Cecha
Opis
Opis
structure)
(query)
(body)
Dodanie kolejki z systemu HIS
PUT /system/{ SystemGUID }/queue
(wymagany)
{
"queueUID" : "55555",
"type" : "P",
"code" : "0001",
"name" : "Poradnia alergologii",
"category" : "1",
"length" : "7",
"avgWaitingTime" : "13",
"realWaitingTime" : "13",
"updateTime" : "201312270001"
}
gdzie:
 queueUID - identyfikator kolejki w systemie HIS
 organizationUnitGUID - globalny identyfikator komórki
organizacyjnej
 type - rodzaj kolejki ("K" - do komórki organizacyjnej; "P" na procedurę medyczną)
 code - kod resortowy albo kod procedury
 name - nazwa rodzaju jednostki albo nazwa procedury
 category - kategoria kolejki: "1" - stabilny, "2" - pilny
 length - liczba oczekujących
 avgWaitingTime - średni czas oczekiwania
 realWaitingTime - rzeczywisty czas oczekiwania
 updateTime - data oceny kolejki w formacie
YYYYMMDDhhmm, gdzie YYYY oznacza rok, MM oznacza
miesiąc, DD oznacza dzieo, hh oznacza godzinę, mm
oznacza minutę
Statusy odpowiedzi
4.1.3.2.
Metoda aktualizująca kolejkę
Cecha
Opis
Opis
Aktualizacja stanu kolejki
POST /system/{ SystemGUID }/queue/ {
53 z 60
Cecha
Opis
structure)
(query)
QueueUID }
(wymagany)
{ QueueUID } –identyfikator kolejki w systemie HIS
(wymagany)
{
"length" : "7",
"avgWaitingTime" : "13",
"realWaitingTime" : "13",
"updateTime" : "201312270001"
}
(body)
gdzie:
 length - liczba oczekujących
 avgWaitingTime - średni czas oczekiwania
 realWaitingTime - rzeczywisty czas oczekiwania
 updateTime - data oceny kolejki w formacie
YYYYMMDDhhmm, gdzie YYYY oznacza rok, MM oznacza
miesiąc, DD oznacza dzieo, hh oznacza godzinę, mm
oznacza minutę
Statusy odpowiedzi
4.1.3.3.
Metoda usuwająca kolejkę
Cecha
Opis
Opis
structure)
(query)
Usunięcie kolejki
DELETE /system/{ SystemGUID }/queue/ {
QueueUID }
(body)
Statusy odpowiedzi
(wymagany)
{ QueueUID } –identyfikator kolejki w systemie HIS
(wymagany)
brak
4.2. Komunikacja e-Rejestracja -> HIS
Usługa umożliwiająca przesłanie do systemu HIS informacji o utworzeniu lub wystąpieniu
zmian w rezerwacjach utworzonych przez użytkownika w Portalu Pacjenta
54 z 60
4.2.1.
Rezerwacja
Cecha
Opis
Opis
Rezerwacja
Zasób RESTowy służacy do zarządzania rezerwacjami z Portalu
Pacjenta:
 Zaplanowanie zdarzenia
 Przeplanowanie zdarzenia
 Anulowanie zdarzenia
Event
Usługa sieciowa
JSON, XML, CSV
Rodzaj interfejsu
Format pobieranych
danych
Kodowanie znaków
HTTP / REST / SOAP
On-line
UTF-8
Nazwa metody
POST/PUT/DELETE
4.2.1.1.
Metoda tworząca rezerwacje
Cecha
Opis
Opis
Rezerwacja z Portalu Pacjenta
structure)
(query)
(body)
Rezerwacja z portalu pacjenta wymaga potwierdzenia w
systemie HIS. Potwierdzenie jest wykonywane poprzez
wywołanie metody tworzącej rezerwacje w Portalu Pacjenta.
PUT /event
brak
{
"patientGUID" : ""0f8fad5b-d9cb-469fa165-708677289505"",
"roomUID" : "22222",
"day" : "20131227",
"endTime " : "1415",
"payerCode" : “nfz”,
"referralCode" : "SK00001",
"purpose" : "emergency",
55 z 60
Cecha
Opis
"referralData" : { }
}
gdzie:
• patientGUID - globalny identyfikator pacjenta
organizacyjnej
• roomUID - wewnętrzny identyfikator pomieszczenia w
systemie HIS
dzieo
• beginTime - czas rozpoczęcia rezerwacji w formacie
HHMM, gdzie HH oznacza godzinę (00-23), MM minutę
(00-59)
• endTime - czas zakooczenia rezerwacji w formacie HHMM,
• payerCode – kod identyfikujący sposób płatności
• referralCode - numer skierowania
• purpose – cel wizyty, możliwe wartości to:
„emergency” – przypadek nagły incydentalny
„chronic” – stan nagły przy chorobie przewlekłej
„checkup” – wizyta kontrolna
„prescription” – wizyta po kolejną receptę
„referral” – wizyta po skierowanie na badanie
specjalistyczne
• referralData – obiekt w notacji JSON reprezentujący dane z
formularza skierowania.
Statusy odpowiedzi
Udało się dodad rezerwacje
Status: 201
Body:
{
"eventUID" : "33333"
}
gdzie:
• eventUID – identyfikator stworzonej rezerwacji w systemie
HIS
Nie udało się dodad rezerwacji, ponieważ już istniała inna w
podanym terminie
56 z 60
Cecha
Opis
Status: 412
Body:
{
"errorCode": "BookingExists"
}
Nie udało się dodad rezerwacji, ponieważ w podanym terminie
nie istniał żaden grafik
Status: 412
Body:
{
"errorCode": "NoSchedule"
}
Nie udało się dodad rezerwacji, ponieważ dla wybranej usługi
wymagane jest podanie numeru skierowania
Status: 412
Body:
{
"errorCode": "NoReferralCode"
}
Nie udało się dodad rezerwacji, ponieważ pacjent posiadał już
inną rezerwację w tym terminie w danym HIS
Status: 412
Body:
{
"errorCode": "TooManyBookings"
}
4.2.1.2.
Metoda modyfikująca rezerwacje
Cecha
Opis
Opis
Modyfikacja rezerwacji z Portalu Pacjenta.
Modyfikacja wymaga potwierdzenia z systemu HIS i jest
realizowana poprzez metode modyfikującą rezerwacje w
Portalu Pacjenta.
POST /event/{ EventUID }
structure)
(query)
(body)
(wymagany)
{
"roomUID" : "22222",
"day" : "20131227",
57 z 60
"endTime" : "2359"
}
gdzie:
systemie HIS
dzieo
Statusy odpowiedzi
4.2.1.3.
Metoda anulująca rezerwacje
Cecha
Opis
Opis
Usunięcie rezerwacji z Portalu Pacjenta.
Anulowanie wymaga potwierdzenia z systemu HIS i jesr
realizowane poprzez metode anulującą rezerwacje w Portalu
Pacjenta.
DELETE /event/{ EventUID }
structure)
(query)
(body)
Statusy odpowiedzi
{ EventUID } – identyfikator rezerwacji w systemie HIS
(wymagany)
{
"reason" : "Odwołanie wizyty z powodów
osobistych"
}
gdzie:
•
reason - powód anulowania
58 z 60
5. Wymagania w zakresie SSO
W ramach MSIM będzie zaimplementowana usługa Single Sign-On (SSO) spełniająca
następujące wymagania:
a.) System powinien zapewnid funkcjonalnośd pojedynczego uwierzytelniania
użytkowników w obrębie dostarczanej platformy oraz dostarczanych aplikacji
dziedzinowych
b.) System powinien zapewnid interfejs API umożliwiający podłączenie do systemu SSO
zewnętrznych aplikacji dziedzinowych.
c.) Uwierzytelnianie użytkowników musi byd realizowane na podstawie jednoznacznie
przydzielonego loginu oraz hasła użytkownika.
Przedmiotem zamówienie jest zapewnienie funkcjonowania oprogramowania HIS w ramach
jednego logowania w ramach infrastruktury dostarczonej przez Wykonawcę MSIM.
6. Wymagania w zakresie PKI
W ramach MSIM będzie zaimplementowana usługa PKI, która będzie obsługiwad funkcje
podpisywania i weryfikacji podpisu elektronicznego z wykorzystaniem Centrum Autoryzacji
(CAPE w Małopolsce – opis funkcjonalności dalej).
Centrum CAPE będzie wykorzystywane w zakresie:
a.) wydawania certyfikatów elektronicznych do podpisywania (przyjmowanie wniosku o
certyfikat w postaci pliku PKCS#10 i udostępnianie wygenerowanego certyfikatu)
b.) znakowania czasem (usługa znakowania czasem zgodna ze standardem RFC 3161.
Przedmiotem zamówienie jest zapewnienie funkcjonowania oprogramowania HIS w ramach
jednego logowania w ramach infrastruktury dostarczonej przez Wykonawcę MSIM.
Opis funkcjonalności CAPE
Obecnie funkcjonująca w Centrum aplikacja PentaSCAPE RA-Service umożliwia uzyskanie
certyfikatu na podstawie żądania w formacie PKCS#10. Nie ma określonych wymagao dot.
zawartości żądania PKCS#10 (do certyfikatu pobierany jest jedynie klucz publiczny). CAPE
obsługuje klucze i rozmiary zgodne z profilem certyfikatu użytego w PentaSCAPE Ra-Service
do wystawienia certyfikatu.
Usługa umożliwiająca uzyskanie certyfikatu udostępniana jest poprzez interfejs WWW, w
którym uwierzytelnianie odbywa się poprzez podanie loginu i hasła.
59 z 60
Usługa znakowania czasem realizowana jest za pomocą dostępnej przez protokół http
aplikacji PentaSCAPE-TSAService i zgodna ze standardem RFC 3161.
Nie przeprowadzano testów wydajnościowych usługi. Aktualna wydajnośd usługi powinna
byd wystarczająca do planowanej skali systemu.
Ścieżka certyfikacyjna certyfikatu TSA obejmuje certyfikaty CA o nazwach wyróżniających:
'CN=RootCA, O=Wojewodztwo Malopolskie, C=PL' i 'CN=Centrum Autoryzacji w Malopolsce,
O=Wojewodztwo Malopolskie, C=PL'.
Odpowiedzi OCSP podpisywane są kluczem dedykowanym. Nie przeprowadzano testów
wydajnościowych usługi OCSP.
60 z 60

Załącznik

Transkrypt

Podobne dokumenty

PRO FORMA INVOICE Faktura pro

referencje - szybkastrona

Pobierz artykuł w PDF.

CODE 2.0 - InvestGDA