Model transportowy danych o Zdarzeniach Medycznych oraz Indeksie Elektronicznej Dokumentacji Medycznej gromadzonych w systemie P1

Transkrypt

1 Elektroniczna Platforma Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych Model transportowy danych o Zdarzeniach Medycznych oraz Indeksie Elektronicznej Dokumentacji Medycznej gromadzonych w systemie P1 Zamówienie współfinansowane przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regionalnego oraz budżet państwa w ramach Programu Innowacyjna Gospodarka Priorytet VII Społeczeństwo Informacyjne Budowa elektronicznej administracji Projekt Elektroniczna Platforma Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych Dotacje na innowacje Inwestujemy w Waszą przyszłość

2 Elektroniczna Platforma Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych Podstawowe informacje o dokumencie: Właściciel CSIOZ Zatwierdzający CSIOZ Data zatwierdzenia Wersja 0.3 Status Robocza Data utworzenia 05/09/2013 Data ostatniej modyfikacji 27/09/2013 Historia zmian Data Wersja Autor zmiany Opis zmiany 27/09/ CSIOZ Przygotowanie do publikacji wersji roboczej

3 Strona 3 z 33 Spis treści 1. Wstęp Ogólna koncepcja Komunikat informujący o zdarzeniu medycznym i elektronicznej dokumentacji medycznej Zdarzenie Medyczne Indeks Elektronicznej Dokumentacji Medycznej... 17

4 Strona 4 z WSTĘP Celem niniejszego opracowania jest określenie formatu i zakresu informacji gromadzonych w zakresie Zdarzeń Medycznych w systemie P1 oraz Indeksu Elektronicznej Dokumentacji Medycznej. Podstawą do utworzenia dokumentu są dokumenty: IHE IT Infrastructure (ITI) Technical Framework Revision 9.0, Vol 1, 2a, 2b, 2x, 3 oraz dodatki uzupełniające wymienione w treści dokumentu. Treść oznaczona kolorem czerwonym podlega standaryzowaniu niezależnie od prac nad tym dokumentem. Zawartość tak oznaczona zostanie zamieniona na poprawne wartości po zakończeniu prac.

5 Strona 5 z OGÓLNA KONCEPCJA W celu zapewnienia wymiany informacji pomiędzy usługodawcami na potrzeby kontynuacji procesu leczenia pacjentów, w SGDM-ZM gromadzone będą informacje o zdarzeniach medycznych mających miejsce u poszczególnych usługodawców. Aby spełnić ten cel konieczne jest gromadzenie danych zarówno o zdarzeniach medycznych, jak również o dokumentacji medycznej związanej z tymi zdarzeniami medycznymi. Poprzez zdarzenie medyczne rozumie się, w tym kontekście, świadczenie zdrowotne udzielane pacjentowi przez usługodawcę. Takim zdarzeniem może być pobyt w oddziale szpitalnym, porada, badanie diagnostyczne czy cykl leczenia. Poprzez dokumentację medyczną, w tym kontekście, rozumie się dokumentację powstałą w wyniku zaistnienia zdarzenia medycznego. Pojęcie dokumentacji medycznej, w rozumieniu dokumentacji przetwarzanej w SGDM-ZM nie jest tożsame z dokumentacją zewnętrzną zdefiniowaną w Rozporządzeniu w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania (Dz. U. z dnia 29 grudnia 2010 r.). W ramach SGDM-ZM będą gromadzone informacje o zdarzeniach medycznych oraz dokumentacji medycznej, która została w ich kontekście wytworzona. Zakłada się, że w kontekście jednego zdarzenia medycznego będzie możliwe zgromadzenie informacji o jednym lub wielu dokumentach medycznych. Zdarzenie medyczne będzie instancją grupującą dokumentację medyczną. Ze względu na różnorodność i szeroki zakres informacyjny zdarzeń medycznych oraz dokumentacji medycznej zakłada się, że w SGDM-ZM będą gromadzone i przetwarzane: osobne zbiory informacji o zdarzeniach medycznych i dokumentacji medycznej skróty informacyjne opisujące zdarzenia medyczne lub dokumentację medyczną, a nie pełne informacje/dokumenty. Dla ułatwienia przetwarzania informacji przez usługodawców zakłada się również, że w SGDM-ZM będzie istniało powiązanie pomiędzy zdarzeniem medycznym a dokumentacją medyczną (jedną lub wieloma) wynikającą z tego zdarzenia. Informacja o zdarzeniu medycznym będzie opisywała cechy tego zdarzenia, zaś informacja o dokumentacji medycznej, poza wartością informacyjną o istnieniu takiego dokumentu, będzie miała na celu umożliwienie przekazania pomiędzy usługodawcami właściwej instancji dokumentu. Jako standard komunikowania wymienionych powyżej informacji przyjęto profil IHE XDS.b. Niniejszy dokument opisuje rozmieszczenie informacji w strukturze danych tego profilu, z uwzględnieniem niezbędnych polskich rozszerzeń. Struktura danych profilu przedstawiona została w formie opisu pól komunikatu, którym przesyłana jest informacja o zdarzeniu i indeksie dokumentacji medycznej z systemu usługodawcy na platformę P1.

6 Strona 6 z KOMUNIKAT INFORMUJĄCY O ZDARZENIU MEDYCZNYM I ELEKTRONICZNEJ DOKUMENTACJI MEDYCZNEJ 3.1. OGÓLNA BUDOWA KOMUNIKATU DANYCH Komunikat rozpoczyna element RegistryObjectList, zawierający listę elementów standardu ebxml, na którym bazuje profil IHE XDS.b. W poniższej tabeli podkreślono element górnego poziomu, pozostałe elementy z tabeli zawarte są bezpośrednio w tym elemencie. Element Wyróżnik typu Krotność Opis elementu RegistryObjectList - 1 Główny element komunikatu wymiany danych obejmujący wszystkie inne elementy zawierające poszczególne grupy informacji. Postać zgodna z ogólnym formatem nagłówka wszystkich komunikatów. ExtrinsicObject objecttype 0..* Jedno wystąpienie elementu zawiera pojedynczy zestaw danych (w nomenklaturze XDS są to metadane, czyli dane opisujące dokument) jednego dokumentu medycznego. RegistryPackage 2..* Element umożliwiający grupowanie dokumentów. Obowiązkowy jest jeden element informujący o bieżącym pakiecie wysyłki (XDSSubmissionSet), oraz jeden element informujący o zdarzeniu medycznym, którego dotyczy komunikat (polskie rozszerzenie standardu XDS - ExtPLHealthcareEvent). Opcjonalnie mogą też pojawić się kolejne elementy definiujące foldery (XDSFolder), nie są one jednak przedmiotem opracowania. Association - 0..* Element umożliwiający tworzenie relacji obejmowania przez element RegistryPackage (pakiet wysyłki, folder, zdarzenie medyczne) poszczególnych elementów ExtrinsicObject (informacji o dokumentach). W kolejnych podrozdziałach przedstawiona zostanie struktura poszczególnych elementów poziomu 1.

7 Strona 7 z ZDARZENIE MEDYCZNE Standard IHE XDS definiuje sposób dzielenia się informacjami o dokumentach, oraz zasady wyszukiwania i pobierania dokumentów w oparciu o te informacje. Zdarzenie medyczne nie posiada swojego odpowiednika w standardzie IHE XDS. Standard definiuje jedynie kilka prostych atrybutów, które w polskiej interpretacji są elementami zdarzenia medycznego. Sytuacja ta, w zgodzie z podstawowym standardem ebxml, wymusiła stworzenie odpowiedniego rozszerzenia standardu IHE XDS. Rozszerzenie to wykorzystuje wyłącznie typowe elementy stosowane w IHE XDS, co pozwala unikać problemów przy implementacji, szczególnie rozszerzania typowej bazy danych stosowanej w rozwiązaniach implementujących rejestry IHE XDS. W kontekście standardu IHE XDS zdarzenie medyczne należy więc traktować jako informację dodatkową, rozszerzającą informacje o dokumentach. Szczegółowy opis zakresu informacji o dokumentach przedstawiony zostanie w rozdziale dotyczącym Indeksu Elektronicznej Dokumentacji Medycznej ELEMENT REGISTRYPACKAGE DLA ZDARZENIA MEDYCZNEGO Na potrzeby przesłania wspólnej dla kilku dokumentów medycznych informacji o zdarzeniu medycznym wykorzystano element ebxml RegistryPackage. Jak wspomniano, element ten został rozszerzony do typu stosowanego wyłącznie w P1 ExtPLHealthcareEvent. Wzorowano się na zastosowaniu elementu ebxml RegistryPackage do przesyłania informacji o folderach (XDSFolder) i pakietach wysyłki (XDSSubmissionSet). Element i wyróżnik typu Atrybut lub element podrzędny Krot ność Pochodz enie Opis Dodatkowe wyjaśnienia, ograniczenia i zależności RegistryPackage 1 ebxml Główny element zdarzenia medycznego Wszystkie pozostałe elementy przedstawione w tabeli znajdują się na najwyższym poziomie elementu RegistryPackage. id 1 ebxml Identyfikator zdarzenia medycznego w rejestrze W postaci docelowej UUID nadawany przez rejestr. Do rejestru przesyłany w dowolnej postaci tekstowej, unikalnej w ramach komunikatu, np. ZdarzenieMedyczne01. objecttype 1 ebxml Typ rejestrowanego obiektu Wartość stała: urn:oasis:names:tc:ebxmlregrep:objecttype:registryobject:registrypackage

8 Strona 8 z 33 "classcode" lid 0..1 ebxml Logiczny identyfikator dokumentu Atrybut służy do wersjonowania danych o obiektach rejestru. Funkcjonalnie odpowiada atrybutowi setid standardu HL7 CDA. Szczegóły na temat wersjonowania, wraz z informacją o dodatkowym elemencie VersionInfo dostępne są w [IHE_ITI_Suppl_XDS_Metadata_Update_Rev1-2_TI_ pdf] mechanizm ten jest implementowany w dostępnych rozwiązaniach. status 1 ebxml Status dostępności informacji o zdarzeniu Wartość przy zapisie do rejestru: urn:oasis:names:tc:ebxml-regrep:statustype:approved. Może być zmieniana w rejestrze (np. na Deprecated w wyniku odbierania kolejnej wersji tego zdarzenia) noderepresen tation name= codin g 1 XDS Typ zdarzenia według słownika kodów jednostek statystycznych świadczeń 1 XDS Definiuje przestrzeń wartości słownika w ramach komunikatu 1 XDS Wartość typu ze słownika Należy nadać wewnętrzny UUID w ramach CSIOZ dla tego. 1 XDS Nazwa słownika Wartość stała: Jednostki statystyczne świadczeń Name 1 XDS Nazwa typu ze słownika Tzw. display name. registrypackage Type Node 1 XDS Wskazanie typu ExtPLHealthcareEvent dla bieżącego elementu RegistryPackage Uwaga, stosuje się klasyfikację w ciele elementu RegistryPackage, jednak dopuszczalna jest także forma umieszczenia klasyfikatora poza ciałem elementu. Jest to klasyfikator o wewnętrznym zestawie wartości, stąd brak atrybutu. 1 XDS UUID dla typu ExtPLHealthcareEvent Należy nadać wewnętrzny UUID w ramach CSIOZ dla typu ExtPLHealthcareEvent.

9 Strona 9 z 33 payertypecode ExternalIdentifier patientid noderepresen tation name= codin g 1 extpl Typ płatnika 1 XDS Definiuje przestrzeń wartości słownika w ramach komunikatu Należy nadać wewnętrzny UUID w ramach CSIOZ dla tego. 1 XDS Wartość typu płatnika Dopuszczalne wartości: public inne do opracowania 1 XDS Nazwa słownika Wartość stała: Typ płatnika Name 1 XDS Nazwa typu płatnika Tzw. display name, np. Osoba prywatna, NFZ name= payeri d identification 0..1 extpl Identyfikator płatnika Wymagany wyłącznie, gdy typ płatnika = public. Należy podać identyfikator oddziału NFZ i OID oddziałów NFZ XDS Identyfikator pacjenta stosowany w P1 Brak identyfikatora dopuszczalny jest wyłącznie dla pacjentów niezidentyfikowanych, lub zidentyfikowanych niejednoznacznie 1 XDS Definiuje przestrzeń identyfikatorów w ramach komunikatu Należy nadać wewnętrzny UUID w ramach CSIOZ dla identyfikatora pacjenta w ramach zdarzenia medycznego. value 1 XDS Wartość identyfikatora pacjenta Format wg specyfikacji XDS: CX, np.: ^^^& &ISO Dopuszczalne wartości: PESEL + OID_peselu idnoworodka + OID_idNoworodka idwkrajupochodzenia + OID_tego_identyfikatora (ewentualnie kod kraju, do ustalenia) nrdokumentu + OID_dokumentu_tożsamości Name 1 XDS Wskazanie którego identyfikatora dotyczy ta informacja Wartość stała: ExtPLHealthcareEvent.patientId 0..1 XDS Identyfikator pacjenta w systemie Wartość wymagana jeśli system usługodawcy posiada wewnętrzny

10 Strona 10 z 33 name="sourcepat ientid" usługodawcy Value 1 XDS Wartość identyfikatora pacjenta w systemie usługodawcy identyfikator pacjenta Format wg specyfikacji XDS: CX, np.: ^^^& &ISO z odpowiednim OID identyfikatora pacjenta u usługodawcy. name="sourcepat ientinfo name="healthcare EventStartTime" 0..1 XDS Dane pacjenta pochodzące z systemu usługodawcy Dane te muszą być podane jeśli są znane Value 1..3 XDS Dopuszczalne wartości ze standardowym separatorem Field, każda para w oddzielnym Value: PID-5 imię i nazwisko PID-7 data urodzenia PID-8 płeć 1 extpl Czas rozpoczęcia zdarzenia medycznego Value 1 XDS Format daty opisany jest w [IHE_ITI_TF_Vol3 Rev.9.0 str13/14]: YYYY[MM[DD[hh[mm[ss]]]]] name="healthcare EventStopTime" 1 extpl Czas zakończenia zdarzenia medycznego Jeśli zdarzenie zakończyło się w tym samym czasie, co rozpoczęło, należy podać tę samą wartość w polach start i stop. Value 1 XDS Format daty opisany jest w [IHE_ITI_TF_Vol3 Rev.9.0 str13/14]: YYYY[MM[DD[hh[mm[ss]]]]] "serviceeventcod e" 0..* extpl Procedury wykonane w czasie trwania zdarzenia 1 XDS Definiuje przestrzeń wartości w ramach komunikatu Jedna procedura powinna zawierać się w jednym elemencie. Należy nadać wewnętrzny UUID w ramach CSIOZ dla tego. Stosowany jest słownik ICD-9 PL. noderepresen tation 1 XDS Wartość ze słownika procedur

11 Strona 11 z 33 name= codin g 1 XDS Nazwa słownika Wartość stała: ICD-9 PL name= snome dcode 0..1 extpl Opcjonalne wskazanie odpowiednika według słownika SNOMED-CT. Kod wg słownika SNOMED-CT jest tu dodatkiem do kodu ICD-9 PL, nie zdefiniowano oddzielnego klasyfikatora. name= servic eeventtime 1 extpl Data i czas wykonania procedury Format daty opisany jest w [IHE_ITI_TF_Vol3 Rev.9.0 str13/14]: YYYY[MM[DD[hh[mm[ss]]]]] Name 1 XDS Nazwa procedury wskazanej w noderepresentation "observationcode " noderepresen tation name= ismai nobservation name= codin g name= snome dcode 1..* extpl Rozpoznania końcowe Jedno rozpoznanie powinno zawierać się w jednym elemencie 1 XDS Definiuje przestrzeń wartości w ramach komunikatu 1 XDS Wartość ze słownika rozpoznań 1 extpl Wskazanie czy rozpoznanie jest rozpoznaniem głównym czy współistniejącym. 1 XDS Nazwa słownika Wartość stała: ICD extpl Opcjonalne wskazanie odpowiednika według słownika SNOMED-CT. Należy nadać wewnętrzny UUID w ramach CSIOZ dla tego. Stosowany jest słownik ICD-10. Musi występować dokładnie jedno rozpoznanie główne. Przyjmuje wartości true i false, alternatywnie może zostać wykorzystane rozwiązanie zdefiniowane w polskim IG HL7 CDA. Kod wg słownika SNOMED-CT jest tu dodatkiem do kodu ICD-10, nie zdefiniowano oddzielnego klasyfikatora.

12 Strona 12 z 33 Name 1 XDS Nazwa trybu rozpoznania wskazanego w noderepresentation ExternalIdentifier uniqueid identification 1 extpl Identyfikator zdarzenia medycznego nadawany przez usługodawcę, tj. unikalny u usługodawcy 1 XDS Definiuje przestrzeń identyfikatorów w ramach komunikatu Należy nadać wewnętrzny UUID w ramach CSIOZ dla tego identyfikatora. value 1 XDS Wartość identyfikatora Służy do referencji poza rejestrem, np. między dokumentami a zdarzeniem medycznym. Nie jest używane wewnętrznie w rejestrze/repozytorium do utrzymywania relacji, jednak można po nim wyszukiwać. Należy zagwarantować unikalność tego identyfikatora w rejestrze. Zgodnie z XDS obowiązuje format OID^id, z odpowiednim OID usługodawcy identyfikującym lokalne identyfikatory stosowane przez tego usługodawcę, umieszczane w atrybucie extension tego identyfikatora w dokumentach HL7 CDA. Name 1 XDS Wskazuje którego identyfikatora dotyczy ta informacja Wartość stała: ExtPLHealthcareEvent.uniqueId legalauthenticat orinstitution 1 extpl Usługodawca Wzorowano się na sposobie przesyłania informacji o usługodawcy w dokumentach medycznych zgodnych z HL7 CDA i polskim IG, gdzie informacja ta znajduje się w elemencie ClinicalDocument/ legalauthenticator/assignedperson/representedorganization. Klasyfikator legalauthenticatorinstitution został stworzony w postaci polskiego rozszerzenia na potrzeby przesyłania informacji o usługodawcy w Indeksie Elektronicznej Dokumentacji Medycznej specyfikacja klasyfikatora dalej w tym dokumencie. Element z Indeksu, po zamianie pola Dziedzina medyczna na Specjalność komórki organizacyjnej, wykorzystano w tym miejscu do przesyłania informacji o usługodawcy w ramach informacji o zdarzeniu medycznym.

13 Strona 13 z 33 noderepresen tation name= institu tionid name= institutionuni t name= institu tionunitspeci alty 1 XDS Definiuje przestrzeń wartości w ramach komunikatu 1 XDS - Wymagana wartość pusta Należy nadać wewnętrzny UUID w ramach CSIOZ dla, unikalny dla legalauthenticatorinstitution zdarzenia medycznego. 1 extpl Identyfikator usługodawcy. Identyfikator usługodawcy w formacie OID^id w elemencie Value slotu, przy czym obie wartości reprezentowane są przez atrybuty root i extension w dokumentach zgodnych z HL7 CDA w ramach polskiego IG. 1 extpl Specjalność komórki organizacyjnej, tj. VII część kodu resortowego, lub wartość uzyskana w inny sposób 1 extpl Specjalność komórki, tj. VIII część kodu resortowego, lub wartość uzyskana w inny sposób author noderepresen tation authorperson 1 XDS Pracownik medyczny realizujący / odpowiedzialny 1 XDS Definiuje przestrzeń wartości w ramach komunikatu 1 XDS - Wymagana wartość pusta Należy nadać wewnętrzny UUID w ramach CSIOZ dla, unikalny dla author zdarzenia medycznego. 1 XDS Dane autora Format wg specyfikacji XDS: XCN, np.: "D12398^Doe^John^^^^^^& &ISO" W ramach identyfikatora osoby dopuszcza się wartości: NPWZ + OID_npwz PESEL + OID_peselu idwkraju + OID_tego_identyfikatora (kod kraju?) nrdokumentu + OID_dokumentu_tożsamości

14 Strona 14 z 33 Należy zwrócić uwagę, że identyfikator osoby znajduje się w pierwszym komponencie danych, a OID w środkowym subkomponencie ostatniego komponentu danych. authorinstituti on authorrole authorspecialt y Wartość tworzona wg wzorca stosowanego w elementach indeksu dokumentacji medycznej, gdzie w przypadku zgodności dokumentu źródłowego z HL7 CDA tworzy się zawartość w następujący sposób: concat( $person/id/@extension,"^", $person/assignedperson/name/family,"^", $person/assignedperson/name/given[1],"^", $person/assignedperson/name/given[2],"^", $person/assignedperson/name/suffix,"^", $person/assignedperson/name/prefix,"^", "^^^&", $person/id/@root,"&iso") gdzie $person jest osobą autorem dokumentu z ClinicalDocument/author. Zaprezentowany sposób budowy zawartości elementu pochodzi z dokumentacji standardu IHE XDS-MS XDS Instytucja, którą autor reprezentuje Informacja o instytucji, którą reprezentuje autor. Format wg specyfikacji XDS: XON, np.: "Nazwa szpitala^^^^^^^^^ " 0..1 XDS Rola autora Rola osoby odpowiedzialnej w stosunku do pacjenta w trakcie zdarzenia medycznego. Wartość czysto informacyjna. Nazwa roli zależna od instytucji XDS Specjalność/specjalizacja autora Specjalizacja autora w kontekście zdarzenia medycznego. Wartość czysto informacyjna. Nazwa specjalizacji zależna od instytucji.

15 Strona 15 z 33 ExternalIdentifier ledgernumber 0..1 extpl Numer księgi głównej Wymagane przy zdarzeniu medycznym w ramach hospitalizacji. Do weryfikacji angielskojęzyczna nazwa elementu. identification 1 XDS Definiuje przestrzeń identyfikatorów w ramach komunikatu Należy nadać wewnętrzny UUID w ramach CSIOZ dla tego identyfikatora. value 1 XDS Wartość identyfikatora Numer w postaci pełnej, tj. rok, numer księgi, pozycja i ewentualny numer dziecka, bez wykorzystania separatorów XDS. Name 1 XDS Wskazanie którego identyfikatora dotyczy ta informacja Wartość stała: ExtPLHealthcareEvent.ledgerNumber admissionmode 0..1 extpl Tryb przyjęcia Pożądane przy zdarzeniu medycznym w ramach hospitalizacji. Można rozszerzać o kolejne sloty, np. datę przyjęcia. Do weryfikacji angielskojęzyczna nazwa elementu. 1 XDS Definiuje przestrzeń wartości w ramach komunikatu Należy nadać wewnętrzny UUID w ramach CSIOZ dla tego. noderepresen tation 1 XDS Wartość ze słownika trybów przyjęcia name= codin g 1 XDS Nazwa słownika Name 1 XDS Nazwa trybu przyjęcia wskazanego w noderepresentation

16 Strona 16 z 33 dischargemode 0..1 extpl Tryb wypisu Wymagane przy zdarzeniu medycznym w ramach hospitalizacji. Można rozszerzać o kolejne sloty, np. datę wypisu. Do weryfikacji angielskojęzyczna nazwa elementu. 1 Definiuje przestrzeń wartości w ramach komunikatu Należy nadać wewnętrzny UUID w ramach CSIOZ dla tego. noderepresen tation 1 Wartość ze słownika trybów wypisu name= codin g 1 Nazwa słownika Name 1 Nazwa trybu wypisu wskazanego w noderepresentation

17 Strona 17 z INDEKS ELEKTRONICZNEJ DOKUMENTACJI MEDYCZNEJ W niniejszym rozdziale przedstawiono zakres informacji o dokumentach przesyłany przy wykorzystaniu standardu IHE XDS. Jak wspomniano, opisane w poprzednim rozdziale informacje o zdarzeniu medycznym należy, przynajmniej z punktu widzenia standardu IHE XDS, traktować jako informację dodatkową do treści zawartej w tym rozdziale ELEMENT EXTRINSICOBJECT DLA INDEKSU EDM Pojedyncza instancja elementu ExtrinsicObject opisuje jeden faktycznie istniejący dokument medyczny. Dane te, tworzące zawartość rejestru dokumentów medycznych, należy de facto traktować jako główne zasoby wyszukiwarki dokumentów. Główny element podkreślono, pozostałe zawarte są bezpośrednio w tym elemencie. Element i wyróżnik typu Atrybut lub element podrzędny Krot ność Pochodz enie Opis ExtrinsicObject 0..* Główny element indeksu dokumentacji medycznej Dodatkowe wyjaśnienia, ograniczenia i zależności id 1 ebxml Identyfikator dokumentu w rejestrze W postaci docelowej UUID nadawany przez rejestr. Do rejestru przesyłany w dowolnej postaci tekstowej, unikalnej w ramach komunikatu, np. Dokument01 dla pierwszego ExtrinsicObject w komunikacie, Dokument02 dla drugiego, itd. mimetype 1 ebxml Format oryginalnego dokumentu Przykładowe wartości: application/pdf, text/xml lid 0..1 ebxml Logiczny identyfikator dokumentu Atrybut służy do wersjonowania obiektów rejestru. Funkcjonalnie odpowiada atrybutowi setid standardu HL7 CDA. Szczegóły na temat wersjonowania, wraz z informacją o dodatkowym elemencie VersionInfo dostępne są w [IHE_ITI_Suppl_XDS_Metadata_Update_Rev1-2_TI_ pdf] mechanizm ten jest implementowany w dostępnych rozwiązaniach.

18 Strona 18 z 33 name="creationti me" status 1 ebxml Status dostępności dokumentu Wartość przy zapisie do rejestru: urn:oasis:names:tc:ebxml-regrep:statustype:approved. Może być zmieniana w rejestrze (np. na Deprecated w wyniku odbierania kolejnej wersji tego dokumentu). objecttype 1 ebxml Typ rejestrowanego obiektu Wartość stała: urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1 1 XDS Data wystawienia dokumentu Value 1 XDS Wartość daty Format daty opisany jest w [IHE_ITI_TF_Vol3 Rev.9.0 str13/14]: YYYY[MM[DD[hh[mm[ss]]]]] name="language Code" 1 XDS Kod języka dokumentu Value 1 XDS Wartość kodu języka dokumentu Polskie dokumenty posiadają wartość pl-pl. name= size 1 XDS Rozmiar dokumentu Value 1 XDS Wartość rozmiaru dokumentu Zgodnie ze standardem IHE XDS wielkość dokumentu wyrażona jest w bajtach [IHE_ITI_TF_Vol3 Rev.9.0 str27] name= hash 1 XDS Skrót dokumentu Wartość skrótu służy do identyfikowania duplikatów. Value 1 XDS Wartość skrótu SHA-1 dokumentu "typecode" 1 XDS Typ dokumentu według słownika LOINC 1 XDS Definiuje przestrzeń wartości słownika w ramach komunikatu Wartość stała urn:uuid:f0306f51-975f-434e-a61cc59651d33983 noderepresen tation 1 XDS Wartość typu ze słownika LOINC

19 Strona 19 z 33 name= codin g 1 XDS Nazwa słownika Wartość stała LOINC Name 1 XDS Nazwa typu ze słownika LOINC Tzw. display name. "classcode" noderepresen tation name= codin g 1 XDS Typ dokumentu według słownika P1 1 XDS Definiuje przestrzeń wartości słownika w ramach komunikatu 1 XDS Wartość typu ze słownika P1 1 XDS Nazwa słownika Name 1 XDS Nazwa typu ze słownika P1 Tzw. display name. Wartość stała urn:uuid:41a5887f c09-adf7-e362475b143a "confidentialityc ode" noderepresen tation name= codin g 1 XDS Kod poufności 1 XDS Definiuje przestrzeń wartości słownika w ramach komunikatu 1 XDS Wartość kodu poufności 1 XDS Nazwa słownika Name 1 XDS Nazwa kodu poufności Wartość stała: urn:uuid:f4f85eac-e6cb-4883-b524-f f

20 Strona 20 z 33 Name (tytuł) 1 XDS Nazwa dokumentu, np. nazwa pliku Dokumenty medyczne zwykle nie posiadają tytułu, a w tej roli używa się wartości displayname atrybutu classcode. Element ten jest w takiej sytuacji wymagany, a jego wartość pozostaje pusta. LocalizedStri ng 0..1 XDS Treść nazwy w języku polskim Description (opis) 1 XDS Opis dokumentu Zalecany przez IHE, rzadko stosowany. Element jest wymagany, a jego wartość może zostać pusta. LocalizedStri ng 0..1 XDS Treść opisu w języku polskim ExternalIdentifier patientid identification 0..1 XDS Identyfikator pacjenta stosowany w P1 Brak identyfikatora dopuszczalny jest wyłącznie dla pacjentów niezidentyfikowanych, lub zidentyfikowanych niejednoznacznie 1 XDS Definiuje przestrzeń identyfikatorów w ramach komunikatu Wartość stała: urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427 value 1 XDS Wartość identyfikatora pacjenta Format wg specyfikacji XDS: CX, np.: ^^^& &ISO Dopuszczalne wartości: PESEL + OID_peselu idnoworodka + OID_idNoworodka idwkrajupochodzenia + OID_tego_identyfikatora (ewentualnie kod kraju, do ustalenia) nrdokumentu + OID_dokumentu_tożsamości Name 1 XDS Wskazanie którego identyfikatora dotyczy ta informacja Wartość stała: XDSDocumentEntry.patientId name="sourcepat 0..1 XDS Identyfikator pacjenta w systemie usługodawcy Wartość wymagana jeśli system usługodawcy posiada wewnętrzny identyfikator pacjenta

21 Strona 21 z 33 ientid" Value 1 XDS Wartość identyfikatora pacjenta w systemie usługodawcy Format wg specyfikacji XDS: CX, np.: ^^^& &ISO z odpowiednim OID identyfikatora pacjenta u usługodawcy. name="sourcepat ientinfo name="servicesta rttime" 0..1 XDS Dane pacjenta pochodzące z systemu usługodawcy Dane te muszą być podane jeśli są znane, tj. np. zostały wskazane w opisywanym dokumencie. Value 1..3 XDS Dopuszczalne wartości ze standardowym separatorem Field, każda para w oddzielnym Value: PID-5 imię i nazwisko PID-7 data urodzenia PID-8 płeć 1 XDS Czas rozpoczęcia procedury, w wyniku wykonania której powstał dokument Przykładowo czas ten może zostać pobrany z opisywanego dokumentu, dla formatu CDA /ClinicalDocument/documentationOf/ serviceevent/effectivetime/low Value 1 XDS Format daty opisany jest w [IHE_ITI_TF_Vol3 Rev.9.0 str13/14]: YYYY[MM[DD[hh[mm[ss]]]]] name="servicest optime" 1 XDS Czas zakończenia procedury, w wyniku wykonania której powstał dokument Przykładowo czas ten może zostać pobrany z opisywanego dokumentu, dla formatu CDA: /ClinicalDocument/documentationOf/ serviceevent/effectivetime/high Jeśli procedura zakończyła się w tym samym czasie, co rozpoczęła, należy podać tę samą wartość w polach start i stop. Value 1 XDS Format daty opisany jest w [IHE_ITI_TF_Vol3 Rev.9.0 str13/14]: YYYY[MM[DD[hh[mm[ss]]]]] "serviceeventcod e" 0..* Włochy Procedury, w wyniku których powstał dokument 1 XDS Definiuje przestrzeń wartości w ramach komunikatu Jedna procedura powinna zawierać się w jednym elemencie. Należy nadać wewnętrzny UUID w ramach CSIOZ dla tego w ramach indeksu dokumentacji medycznej. Stosowany jest słownik ICD-9 PL.

22 Strona 22 z 33 noderepresen tation name= codin g name= snome dcode 1 XDS Wartość ze słownika procedur 1 XDS Nazwa słownika 0..1 extpl Opcjonalne wskazanie odpowiednika według słownika SNOMED-CT. Name 1 XDS Nazwa procedury wskazanej w noderepresentation Kod wg słownika SNOMED-CT jest tu dodatkiem do kodu ICD-9 PL, nie zdefiniowano oddzielnego klasyfikatora. ExternalIdentifier uniqueid identification 1 XDS Identyfikator dokumentu nadawany przez usługodawcę, tj. unikalny u usługodawcy 1 XDS Wartość stała: urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab value 1 XDS Wartość identyfikatora Służy do referencji poza rejestrem, np. między dokumentami a zdarzeniem medycznym. Nie jest używane wewnętrznie w rejestrze/repozytorium do utrzymywania relacji, jednak można po nim wyszukiwać. Należy zagwarantować unikalność tego identyfikatora w rejestrze. Zgodnie z XDS obowiązuje format OID^id, z odpowiednim OID usługodawcy identyfikującym lokalne identyfikatory stosowane przez tego usługodawcę, umieszczane w atrybucie extension tego identyfikatora w dokumentach HL7 CDA. Name 1 XDS Wartość stała: XDSDocumentEntry.uniqueId name="repository 0..1 XDS Identyfikator kustosza dokumentu, będącego fizycznym repozytorium dla tego dokumentu. Wymagane dla operacji rejestrowania danych o dokumencie w rejestrze.

23 Strona 23 z 33 UniqueId" Value 1 XDS Wartość identyfikatora w postaci OID. Jeśli usługodawca nie wyznaczył dedykowanego OID dla własnego repozytorium, może być stosowany OID usługodawcy. name="legalauth enticator" 0..1 XDS Osoba podpisująca opisywany dokument Standard w tym miejscu nie przewiduje prezentowania informacji o instytucji, którą osoba podpisująca reprezentuje Value 1 XDS Format wg specyfikacji XDS: XCN, np.: "D12398^Doe^John^^^^^^& &ISO" W ramach identyfikatora osoby dopuszcza się wartości: NPWZ + OID_npwz PESEL + OID_peselu idwkraju + OID_tego_identyfikatora (kod kraju?) nrdokumentu + OID_dokumentu_tożsamości Należy zwrócić uwagę, że identyfikator osoby znajduje się w pierwszym komponencie danych, a OID w środkowym subkomponencie ostatniego komponentu danych. Wartość tworzona na podstawie dokumentu zgodnego z HL7 CDA, gdzie $person jest osobą, która podpisała dokument: ClinicalDocument/legalAuthenticator/assignedPerson: concat( $person/id/@extension,"^", $person/assignedperson/name/family,"^", $person/assignedperson/name/given[1],"^", $person/assignedperson/name/given[2],"^", $person/assignedperson/name/suffix,"^", $person/assignedperson/name/prefix,"^", "^^^&", $person/id/@root,"&iso") Zaprezentowany sposób budowy zawartości elementu pochodzi z dokumentacji standardu IHE XDS-MS 1 extpl Usługodawca Rozwiązanie zbudowane na przykładzie elementu XDS author.

24 Strona 24 z 33 legalauthenticat orinstitution noderepresen tation name= institu tionid name= institutionme dicaldomain name= institu tionunitspeci alty 1 XDS Definiuje przestrzeń wartości w ramach komunikatu 1 XDS - Wymagana wartość pusta Dla dokumentów zgodnych z HL7 CDA wg polskiego IG zawartość podawana jest z pola ClinicalDocument/ legalauthenticator/assignedperson/representedorganization. Należy nadać wewnętrzny UUID w ramach CSIOZ dla unikalny dla legalauthenticatorinstitution dokumentu medycznego. 1 extpl Identyfikator usługodawcy. Identyfikator usługodawcy w formacie OID^id w elemencie Value slotu, przy czym obie wartości reprezentowane są przez atrybuty root i extension w dokumentach zgodnych z HL7 CDA w ramach polskiego IG. 1 extpl Dziedzina medyczna, tj. X część kodu resortowego, lub wartość uzyskana w inny sposób 1 extpl Specjalność komórki, tj. VIII część kodu resortowego, lub wartość uzyskana w inny sposób author noderepresen tation authorperson 1 XDS Autor dokumentu 1 XDS Definiuje przestrzeń wartości w ramach komunikatu Wartość stała: urn:uuid:93606bcf ec-9b4e-a7748d1a838d 1 XDS Wymagana wartość pusta 1 XDS Dane autora Format wg specyfikacji XDS: XCN, np.: "D12398^Doe^John^^^^^^& &ISO" W ramach identyfikatora osoby dopuszcza się wartości: NPWZ + OID_npwz PESEL + OID_peselu

25 Strona 25 z 33 idwkraju + OID_tego_identyfikatora (kod kraju?) nrdokumentu + OID_dokumentu_tożsamości Należy zwrócić uwagę, że identyfikator osoby znajduje się w pierwszym komponencie danych, a OID w środkowym subkomponencie ostatniego komponentu danych. authorinstituti on authorrole authorspecialt y Wartość tworzona wg wzorca stosowanego w elementach indeksu dokumentacji medycznej, gdzie w przypadku zgodności dokumentu źródłowego z HL7 CDA tworzy się zawartość w następujący sposób: concat( $person/id/@extension,"^", $person/assignedperson/name/family,"^", $person/assignedperson/name/given[1],"^", $person/assignedperson/name/given[2],"^", $person/assignedperson/name/suffix,"^", $person/assignedperson/name/prefix,"^", "^^^&", $person/id/@root,"&iso") gdzie $person jest osobą autorem dokumentu z ClinicalDocument/author. Zaprezentowany sposób budowy zawartości elementu pochodzi z dokumentacji standardu IHE XDS-MS XDS Instytucja, którą autor reprezentuje Informacja o instytucji, którą reprezentuje autor. Format wg specyfikacji XDS: XON, np.: "Nazwa szpitala^^^^^^^^^ " 0..1 XDS Rola autora Rola autora dokumentu w stosunku do pacjenta w trakcie przeprowadzania procedury. Wartość czysto informacyjna. Nazwa roli zależna od instytucji XDS Specjalizacja autora Specjalizacja autora w kontekście przeprowadzanej wobec pacjenta procedury. Wartość czysto informacyjna. Nazwa specjalizacji zależna od instytucji.

26 Strona 26 z ELEMENT REGISTRYPACKAGE DLA SUBMISSION SET Komunikat zawiera pojedynczy element RegistryPackage typu SubmissionSet zawierający informację o wysyłce. SubmissionSet nie podlega wersjonowaniu. Główny element podkreślono, pozostałe zawarte są bezpośrednio w tym elemencie. Element i wyróżnik typu Atrybut lub element podrzędny Krot ność Pochodz enie Opis RegistryPackage 1 Główny element informacji o wysyłce "contenttypecod e" Dodatkowe wyjaśnienia, ograniczenia i zależności id 1 ebxml Identyfikator wysyłki w rejestrze W postaci docelowej UUID nadawany przez rejestr. Do rejestru przesyłany w dowolnej postaci tekstowej, unikalnej w ramach komunikatu, np. SubmissionSet. objecttype 1 ebxml Typ rejestrowanego obiektu Wartość stała: urn:oasis:names:tc:ebxmlregrep:objecttype:registryobject:registrypackage status 1 ebxml Status informacji o wysyłce Wartość do odczytu, zarządzana przez rejestr. Dopuszczalne dwie wartości: urn:oasis:names:tc:ebxml-regrep:statustype:approved oznacza dostępność zestawu do odczytu urn:oasis:names:tc:ebxml-regrep:statustype:submitted oznacza, że zestaw nie jest kompletny i nie może być udostępniony Wysyłka nie może być uznana np. za Deprecated. noderepresen tation 1 XDS Typ zdarzenia medycznego, którego efektem jest wysyłka. 1 XDS Definiuje przestrzeń wartości słownika w ramach komunikatu 1 XDS Wartość typu ze słownika Wydaje się, że jest to dublowanie słownika LOINC z polskiego rozszerzenia komunikacji o informacji o zdarzeniu medycznym. Niemniej standard IHE XDS wymaga podania tego kodu, przy czym rodzaj użytego słownika zależy od P1. Wartość stała: urn:uuid:aa bdda-424e-8c96-df4873be8500

27 Strona 27 z 33 name= codin g 1 XDS Nazwa słownika Name 1 XDS Nazwa typu ze słownika Tzw. display name. registrypackage Type Node 1 XDS Wskazanie typu XDSSubmissionSet bieżącego elementu RegistryPackage Uwaga, stosuje się klasyfikację w ciele elementu RegistryPackage, jednak dopuszczalna jest także forma umieszczenia klasyfikatora poza ciałem elementu. Jest to klasyfikator o wewnętrznym zestawie wartości, stąd brak atrybutu. 1 XDS UUID dla typu XDSSubmissionSet Wartość stała: urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd ExternalIdentifier patientid identification 0..1 XDS Identyfikator pacjenta stosowany w P1 Brak identyfikatora dopuszczalny jest wyłącznie dla pacjentów niezidentyfikowanych, lub zidentyfikowanych niejednoznacznie 1 XDS Definiuje przestrzeń identyfikatorów w ramach komunikatu Wartość stała: urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446 value 1 XDS Wartość identyfikatora pacjenta Format wg specyfikacji XDS: CX, np.: ^^^& &ISO Dopuszczalne wartości: PESEL + OID_peselu idnoworodka + OID_idNoworodka idwkrajupochodzenia + OID_tego_identyfikatora (ewentualnie kod kraju, do ustalenia) nrdokumentu + OID_dokumentu_tożsamości Name 1 XDS Wskazanie którego identyfikatora dotyczy ta informacja Wartość stała: XDSSubmissionSet.patientId

28 Strona 28 z 33 Name (nazwa) 1 XDS Nazwa wysyłki Element obowiązkowy, jego wartość zwykle pusta. LocalizedStri ng 0..1 XDS Treść nazwy w języku polskim Description (opis) 1 XDS Opis, uwagi do wysyłki Element obowiązkowy, jego wartość zwykle pusta. LocalizedStri ng 0..1 XDS Treść opisu w języku polskim name="submissio ntime" 1 XDS Czas wysyłki Value 1 XDS Format daty opisany jest w [IHE_ITI_TF_Vol3 Rev.9.0 str13/14]: YYYY[MM[DD[hh[mm[ss]]]]] ExternalIdentifier uniqueid identification 1 XDS Identyfikator wysyłki nadawany przez usługodawcę, tj. unikalny u usługodawcy 1 XDS Definiuje przestrzeń wartości w ramach komunikatu Wartość stała: urn:uuid:96fdda7c-d e-bf5ee74998a8 value 1 XDS Wartość identyfikatora Służy do referencji poza rejestrem. Nie jest używane w rejestrze/repozytorium do utrzymywania relacji, jednak można po tym wyszukiwać. Standard wymaga, by był to globalnie unikalny OID inkrementowany dla każdej wysyłki, przy czym początkowy OID byłby równie unikalny dla każdego usługodawcy/systemu usługodawcy. Jeśli w P1 przyjęty zostanie zakaz stosowania inkrementowanych OID, stosowany będzie tu standardowy format globalnie unikalnego identyfikatora OID^id. Name 1 XDS Wartość stała: XDSSubmissionSet.uniqueId ExternalIdentifier 1 XDS Identyfikator źródła wysyłki Jednoznaczne wskazanie źródła wysyłki (można interpretować jako

29 Strona 29 z 33 sourceid author identification 1 XDS Definiuje przestrzeń wartości w ramach komunikatu usługodawcę, lub system usługodawcy). Wartość stała: urn:uuid:554ac39e-e3fe-47fe-b d2a value 1 XDS Wartość identyfikatora W specyfikacji wymagana jest wartość typu OID. Name 1 XDS Wartość stała: XDSSubmissionSet.sourceId noderepresen tation authorperson 1 XDS Pracownik medyczny wykonujący wysyłkę Autor wysyłki uznany jest także za autora korekty, jeśli wysyłka zawiera nowe dane obiektów istniejących już w rejestrze (dotyczy informacji o dokumentach i o zdarzeniu medycznym). Autor wysyłki nie jest osobą podpisującą się cyfrowo w komunikacie, ustalono, że podpisy wykonywany jest przez automat, niemniej jednak to autor wysyłki odpowiada za poprawność danych w komunikacie. 1 XDS Definiuje przestrzeń wartości w ramach komunikatu Wartość stała: urn:uuid:a7058bb9-b4e ba5b-e3f0ab85e12d 1 XDS - Wymagana wartość pusta 1 XDS Dane autora Format wg specyfikacji XDS: XCN, np.: "D12398^Doe^John^^^^^^& &ISO" W ramach identyfikatora osoby dopuszcza się wartości: NPWZ + OID_npwz PESEL + OID_peselu idwkraju + OID_tego_identyfikatora (kod kraju?) nrdokumentu + OID_dokumentu_tożsamości Należy zwrócić uwagę, że identyfikator osoby znajduje się w pierwszym komponencie danych, a OID w środkowym subkomponencie ostatniego komponentu danych. Wartość tworzona wg wzorca stosowanego w elementach indeksu dokumentacji medycznej, gdzie w przypadku zgodności dokumentu

30 Strona 30 z 33 authorinstituti on authorrole authorspecialt y źródłowego z HL7 CDA tworzy się zawartość w następujący sposób: concat( $person/id/@extension,"^", $person/assignedperson/name/family,"^", $person/assignedperson/name/given[1],"^", $person/assignedperson/name/given[2],"^", $person/assignedperson/name/suffix,"^", $person/assignedperson/name/prefix,"^", "^^^&", $person/id/@root,"&iso") gdzie $person jest osobą autorem dokumentu z ClinicalDocument/author. Zaprezentowany sposób budowy zawartości elementu pochodzi z dokumentacji standardu IHE XDS-MS XDS Instytucja, którą autor reprezentuje Informacja o instytucji, którą reprezentuje autor. Format wg specyfikacji XDS: XON, np.: "Nazwa szpitala^^^^^^^^^ " 0..1 XDS Rola autora Rola autora wysyłki w stosunku do pacjenta w trakcie zdarzenia medycznego. Wartość czysto informacyjna. Nazwa roli zależna od instytucji XDS Specjalność/specjalizacja autora Specjalność/specjalizacja autora wysyłki w kontekście zdarzenia medycznego. Wartość czysto informacyjna. Nazwa specjalności zależna od instytucji ELEMENT ASSOCIATION NA POTRZEBY RELACJI DOKUMENT - PAKIET Lista elementów Association przypisuje do poszczególnych RegistryPackage dokumenty z elementów ExtrisincObject. Każdy dokument musi być przypisany zarówno do zdarzenia medycznego, jak i do informacji o wysyłce. Elementy Association nie podlegają wersjonowaniu.

31 Strona 31 z 33 Element i wyróżnik typu Association associationtype= HasMemeber Atrybut lub element podrzędny Krot ność Pochodz enie Opis 0..* XDS Przypisanie dokumentu do RegistryPackage typu SubmissionSet i HealthcareEvent Dodatkowe wyjaśnienia, ograniczenia i zależności sourceobject 1 XDS Obiekt, do którego przypisujemy Identyfikator id (w postaci UUID jeśli jest dostępna, lub symbolicznej przy pierwszym zapisie) obiektu typu RegistryPackage. targetobject 1 XDS Obiekt przypisywany Identyfikator id (w postaci UUID jeśli jest dostępna, lub symbolicznej przy pierwszym zapisie) obiektu typu ExtrinsicObject. name= Submi ssionsetstatus lub name= Healt hcareeventsta tus 1 XDS / extpl Rodzaj przypisania dokumentu do RegistryPackage ELEMENT ASSOCIATION NA POTRZEBY KOREKT DOKUMENTÓW W przypadku przypisywania dokumentu do SubmissionSet, (nazwa slotu SubmissionSetStatus dopuszczalne są wartości: Original - informacja o dokumencie jest wysyłana po raz pierwszy do rejestru Reference - informacja o dokumencie istnieje w rejestrze, a sam dokument (możliwe są różne powody) jest uznany za należący do tej wysyłki. Szczegóły: [IHE_ITI_TF_Vol3 Rev.9.0 str7] W przypadku przypisywania dokumentu do HealthcareEvent (P1 Zdarzenie Medyczne, nazwa slotu HealthcareEventStatus) dopuszczalne są te same wartości, o identycznym znaczeniu technicznym i nieco innym znaczeniu merytorycznym: Original dokument został stworzony w ramach zdarzenia wysyłanego w komunikacie Reference dokument jest dokumentem powiązanym ze zdarzeniem, ale nie został stworzony w ramach zdarzenia. Zwykle dokument taki istnieje w rejestrze i należy (jako Original ) do innego SubmissionSet i HealthcareEvent. Dotyczy to np. skierowań na badania. Na potrzeby korygowania dokumentów wykorzystano wbudowany w standard IHE XDS mechanizm asocjacji między dokumentami, ograniczając się do typu asocjacji RPLC, w której dokument korygujący zastępuje dokument korygowany. Należy zauważyć, że komunikat z korektą dokumentu przesyła informację

32 Strona 32 z 33 o zupełnie nowym dokumencie zastępującym dokument poprzedni, przy czym nowy dokument posiada nową wartość uniqueid i nową, nadawaną przez rejestr wartość id (tzw. entryid w postaci UUID). Komunikat z korektą pojedynczego dokumentu składa się z następujących elementów: - nowy pakiet wysyłki SubmissionSet; pakiety wysyłek są niemodyfikowalne - nowy element ExtrinsicObject z danymi nowej wersji dokumentu - standardowy element Association typu HasMember przypisujący informację o dokumencie do bieżącego SubmissionSet - standardowy element Association typu HasMember przypisujący informację o dokumencie do wyszukanego wcześniej UUID zdarzenia; oznacza to przypisanie nowej wersji dokumentu do zdarzenia istniejącego w rejestrze, a więc komunikat z korektą nie będzie zawierał RegistryPackage z informacją o zdarzeniu - nowy element Association typu RPLC przypisujący informację o dokumencie do poprzedniej wersji tego dokumentu; oznacza to, że komunikat z korektą nie będzie zawierał elementu ExtrinsicObject z danymi poprzedniego dokumentu, tylko sam UUID poprzedniego dokumentu. Zawartość tego elementu opisana jest w poniższej tabeli. Element i wyróżnik typu Association associationtype= urn:ihe:iti:2007:a ssociationtype:r PLC Atrybut lub element podrzędny Krot ność Pochodz enie Opis 0..* Korekta dokumentu poprzez wskazanie dokumentu zastępującego. Dodatkowe wyjaśnienia, ograniczenia i zależności sourceobject 1 XDS Dokument korygujący Identyfikator id (w postaci UUID jeśli jest dostępna, lub symbolicznej przy pierwszym zapisie) obiektu typu ExtrinsicObject. targetobject 1 XDS Dokument korygowany Identyfikator id w postaci UUID korygowanego dokumentu. Jeśli UUID korygowanego dokumentu nie jest dostępne w lokalnym systemie, należy je wyszukać w rejestrze przed zbudowaniem komunikatu. Odebranie komunikatu przez rejestr skutkować będzie zmianą statusu indeksu dokumentu korygowanego na Deprecated, lub błędem, jeśli próba korekty dotyczyć będzie dokumentu w statusie innym niż Approved.

33 Strona 33 z 33 Nie planuje się wykorzystania dodatkowych atrybutów XDSDocumentEntry.parentDocumentId i XDSDocumentEntry.parentDocumentRelationship, które duplikują funkcjonalność asocjacji. Za autora tej korekty uznany będzie author z przesyłanego komunikatem korekty elementu SubmissionSet.