Małopolski System Informacji Medycznej projekt pilotażowy

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 3.1. 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 badań 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 4. 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: anie 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 zapewniać rozdzielność 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ę komunikować 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ęść regionalną, w której funkcjonować będą elementy systemu odpowiadające za interoperacyjność rozwiązania oraz część 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 pozwalać 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 odbywać 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 (warstwa lokalna MSIM) Adapter komunikacyjny (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 przechowywać 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ść 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ł odpytać warstwę regionalną o dokumenty w innych jednostkach oraz pobrać je w całości lub częściowo. Dostęp do dokumentacji będzie autoryzowany, co oznacza, że użytkownik będzie mógł otrzymać 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ść 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ść). Pełna dokumentacja medyczna z hospitalizacji/wizyty z danymi obrazowymi w jakości diagnostycznej (duża objętość) 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ść 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ść 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ść rejestracji na wskazany termin i anulowania wizyty. Z e-rejestracji mogą korzystać wyłącznie zarejestrowani na poziomie regionalnym użytkownicy końcowi (pacjenci). W ramach usługi powinien funkcjonować system komunikatów (powiadomień dla użytkowników końcowych 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ść 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ść 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ść 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ępować 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 dostarczać 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ą zostać wymienione pomiędzy dwoma jednostkami, aby nastąpiło poprawne przekazanie dokumentu medycznego. Standard wspierany jest obecnie przez większość głównych dostawców oprogramowania medycznego na świecie. Sam układ dokumentu medycznego powinien być 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 stosować 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 być na część regionalną, w której funkcjonować będą elementy systemu odpowiadające za interoperacyjność rozwiązania oraz część lokalną, działającą w poszczególnych jednostkach medycznych. Warstwa regionalna może być 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 być: wysyłana EDM z HIS do MSIM, przyjmowana EDM do ewentualnego zapisania w danym HIS (zapisanie w HIS powinno być opcją) w formacie HL7 CDA R2 na 3 poziomie interoperacyjności scharakteryzowanym w rozdziale 2. Wymaganie to należy rozumieć w ten sposób, że należy stosować poziom 3, jeżeli nie jest możliwy poziom 2, należy stosować poziom 1. Nie zastosowanie wyższego poziomu musi być 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ęść systemu resortowych kodów identyfikacyjnych d) nazwę jednostki organizacyjnej oraz jej kod resortowy stanowiący V część systemu resortowych kodów identyfikacyjnych w przypadku zakładu opieki zdrowotnej, e) nazwę komórki organizacyjnej, w której udzielono świadczeń 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) data urodzenia c) płeć d) adres miejsca zamieszkania(ulica, kod pocztowy, miasto, kraj) e) 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ść 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 świadczeń 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 zawrzeć 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ążyć 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 badań 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ść komunikacji należy opisywać zgodnie z zestawem Entries zdefiniowanym w sekcji 2.3 W ramach pilotażu MSIM, z systemów dziedzinowych należy przysyłać do lokalnych systemów EDM co najmniej: karty informacyjne z leczenia szpitalnego, opisy wyników badań obrazowych, wyniki badań laboratoryjnych, skierowania, zlecenia, recepty, bądź informacje o zastosowanych lekach, opisy konsultacji medycznych, protokoły operacyjne. 3. Standard HL7 CDA 3.1. 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ładać się z wielu elementów takich jak: tekst, obraz, dźwięk i inne multimedia. Dokument CDA charakteryzują poniższe cechy: 1. Niezmienność (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ść uwierzytelniania (ang. potential for authentication) dokument kliniczny zawiera informacje konieczne do uwierzytelnienia; 12 z 60

4. Całość (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ść (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 być 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. może być 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 być budowane z wykorzystaniem modelu referencyjnego HL7 RIM (Reference Information Model), oraz w ramach możliwości wykorzystywać skodyfikowane terminologie medyczne (np. LOINC, SNOMED, ICD-9, ICD-10). Przykładowymi dokumentami HL7 CDA mogą być: 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 kończy 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 stopień 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 posiadać pojedynczy blok narracyjny znajdujący się w znaczniku <text>. Przechowuje on informacje wyświetlane na poglądzie dokumentu. W bloku narracyjnym można wykorzystywać 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ść powiązania konkretnych entries pomiędzy sobą oraz wiązania ich z fragmentami bloku narracyjnego. Wejścia CDA mogą także zawierać referencje do zewnętrznych plików, np. skanów zdjęć. W celu zapewnienia rozszerzeń o charakterze lokalnym, CDA umożliwia wykorzystanie dodatkowych elementów XML oraz atrybutów niewyspecyfikowanych w standardzie. Rozszerzanie powinno być 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. aną 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> <section> <section> <section> <section> <section> <section> 3.2.3. Tagi formatujące w blokach narracyjnych HL7CDA Treści zamieszczane w blokach narracyjnych (wewnątrz tagu <text>) mogą być czystym tekstem, bądź wykorzystywać 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 (choć 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ą tworzyć na bazie własnej wiedzy dziedzinowej, wprowadzając do dokumentu sekcje odpowiadające informacjom uzupełnianym w aplikacji przez lekarza. Takie dokumenty mogą być 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 traktować 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 przeszukiwać i odczytywać w przeglądarce, ale także informacje z nich pochodzące zostaną odpowiednio przetworzone i zaprezentowane (np. na zbiorczym widoku z listą wszystkich rozpoznań). Ogólne założenia: ważna jest kolejność 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 zostać wypełniony, w przypadku gdy jest opcjonalny i nie zamierzamy go wypełniać, należy go usunąć (wymaganie HL7 CDA R2). 3.3.1. Grupa krwi Przykład: <code code="278153001" 16 z 60

displayname="grupa krwi AB Rh-" /> <effectivetime value="201305221000" /> <text>opcjonalny opis.</text> </entry> 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" displayname="pozytywny test na alergię"/> <text> reakcji alergicznej.</text> <effectivetime value="200508291238"/> <value xsi:type="st">nazwa alergii</value> 17 z 60

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"> </code> <originaltext> <reference value="#_z1"/> </originaltext> <entryrelationship typecode="refr"> <code code="90734009" displayname="przewlekle"/> </entryrelationship> <entryrelationship typecode="refr"> <code code="8319008" displayname="rozpoznanie główne"/> </entryrelationship> 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: <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"> <effectivetime value="20130505"/> <prioritycode code="ur" codesystem="2.16.840.1.113883.11.16866"/> <independentind value="false"/> 19 z 60

<quantity value="1"/> <product> <manufacturedproduct> <manufacturedlabeleddrug> <code code="5909990014958" codesystem="1.0.15418.0" codesystemname="gs1" displayname="enarenal 5mg (60 tabl.)" /> </manufacturedlabeleddrug> </manufacturedproduct> </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> </entryrelationship> </substanceadministration> </entry> 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" displayname="przeciwwskazania"/> <text> przeciwskazań do aktualnie zażywanych leków oraz inne</text> <effectivetime value="200508291238"/> 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: <code code="62014003" 21 z 60