Instrukcja stosowaniaPolskiej Implementacji Krajowej HL7 CDA

Instrukcja stosowania Polskiej Krajowej Implementacji HL7 CDA

Wydanie wstpne do konsultacji

Warszawa 2015

Egzemplarz bezpatny

Dokument przygotowany dla Centrum

Systemw Informacyjnych Ochrony Zdrowia

w ramach projektu Elektroniczna Platforma Gromadzenia, Analizy iUdostpniania Zasobw Cyfrowych o Zdarzeniach Medycznych

CSIOZ posiadajce autorskie prawa majtkowe do dokumentu zezwala na nieograniczone (pod wzgldem czasu i terytorium), nieodpatne korzystanie z niego. Uprawnienie obejmuje w szczeglnoci moliwo zmiany formatu zapisu dokumentu oraz moliwo jego wywietlania, kopiowania, drukowania, tumaczenia zarwno w caoci, jak i w czci.

Autor: Marcin Pusz

Certified HL7 CDA and HL7 V3 RIM Specialist

HL7 oraz CDA s zastrzeonymi znakami towarowymi

Strona 196 z 200

Health Level Seven International

Projekt Elektroniczna Platforma Gromadzenia, Analizy iUdostpniania zasobw cyfrowych o Zdarzeniach Medycznych,wspfinansowany przez Uni Europejsk ze rodkw Europejskiego Funduszu Rozwoju Regionalnego oraz budetu pastwa wramach osi priorytetowej "Spoeczestwo informacyjne - budowa elektronicznej administracji" Programu Operacyjnego Innowacyjna Gospodarka 2007-2013"Dotacje na innowacje" "Inwestujemy wWasz przyszo"

Projekt Elektroniczna Platforma Gromadzenia, Analizy iUdostpniania zasobw cyfrowych o Zdarzeniach Medycznych,wspfinansowany przez Uni Europejsk ze rodkw Europejskiego Funduszu Rozwoju Regionalnego oraz budetu pastwa wramach osi priorytetowej "Spoeczestwo informacyjne - budowa elektronicznej administracji" Programu Operacyjnego Innowacyjna Gospodarka 2007-2013"Dotacje na innowacje" "Inwestujemy wWasz przyszo"

Spis treci

1.Wprowadzenie7

2.Cel i zakres dokumentu7

3.Podstawy standardu HL7 CDA8

3.1.Pryncypia standardu9

3.2.Struktura dokumentu HL7 CDA10

3.2.1.Ciao elektronicznego dokumentu medycznego12

3.2.2.Nagwek elektronicznego dokumentu medycznego13

3.3.Szablony13

3.4.Zasady przekazywania dokumentu medycznego14

3.5.Wywietlanie i automatyczna analiza zawartoci15

3.5.1.Blok narracyjny16

3.5.2.Wyraenie kliniczne17

3.5.3.Relacje midzy blokiem narracyjnym a wyraeniem klinicznym18

3.6.Typy danych HL7 CDA21

3.6.1.Typ abstrakcyjny ANY21

3.6.2.Dane binarne BL23

3.6.3.Dane tekstowe StrucDoc.Text, ED, ST, SC23

3.6.4.Dane sownikowe CD, CE, CV, CS, CR31

3.6.5.Identyfikatory II, OID33

3.6.6.Adresy AD, ADXP, oraz adres telekomunikacyjny TEL37

3.6.7.Nazwy EN, ENXP, PN, ON41

3.6.8.Ilo QTY, INT, REAL, wielko fizyczna PQ, wskanik RTO, RTO_PQ_PQ42

3.6.9.Czas TS, TS.DATE, GTS44

3.6.10.Zbiory danych i przedziay SET, LIST, IVL46

4.Zasady stosowania polskiego IG48

4.1.Polska Implementacja Krajowa HL7 CDA48

4.1.1.Zakadka Szablony dokumentw49

4.1.2.Zakadka Wszystkie szablony67

4.1.3.Zakadka Terminologia68

4.1.4.Zakadka extPL79

4.1.5.Zakadka Rejestr OID79

4.1.6.Zakadka Wizualizacja81

4.2.Klasy gwne HL7 RIM82

4.3.Szablony83

4.3.1.Szablony typw danych [7]84

4.3.2.Szablony wpisw entry [4]85

4.3.3.Szablony sekcji [3]111

4.3.4.Szablony elementu nagwka [2]114

4.3.5.Abstrakcyjne szablony dokumentw medycznych [1]140

4.4.Specyfika wybranych dokumentw medycznych143

4.4.1.Recepta143

4.4.2.Skierowanie144

5.Polityka stosowania wzw ISO OID145

5.1.Pojcie OID145

5.1.1.Sposb zapisu numeru PESEL146

5.1.2.Warto extension146

5.1.3.Warto root147

5.1.4.Identyfikator bez wartoci extension147

5.2.Rejestracja wza OID148

5.2.1.Wzy OID nadane przez CSIOZ dla danych przechowywanych w P1149

5.2.2.Wasne wzy OID instytucji149

5.2.3.Wzy OID Aplikacji Usugodawcw i Aptek AUA150

5.2.4.Rejestrowanie wzw OID nadanych przez P1151

5.3.Zasady identyfikacji dokumentw medycznych154

5.3.1.Identyfikator dokumentu154

5.3.2.Identyfikator zbioru wersji dokumentu i numer wersji155

5.3.3.Identyfikacja dokumentw wersjonowanych156

5.4.Zasady identyfikacji osb157

5.4.1.Identyfikacja pacjenta157

5.4.2.Zasady identyfikacji pracownikw medycznych159

5.4.3.Tworzenie identyfikatora osoby159

6.Multimedia160

6.1.Polski multimedialny dokument medyczny160

6.2.Umieszczanie multimediw w treci dokumentu161

6.2.1.Zasady umieszczania multimediw w treci dokumentu161

6.2.2.Sposb umieszczania multimediw w treci dokumentu162

6.3.Umieszczanie multimediw i innych zacznikw poza dokumentem168

6.4.Rodzaje wywietlanych plikw multimedialnych169

6.5.Udostpnianie multimedialnych dokumentw medycznych170

7.Wersjonowanie szablonw i transformat XSL171

7.1.Powody i charakter zmian w IG171

7.2.Wersjonowanie IG171

7.3.Wersjonowanie szablonw172

7.4.Wersjonowanie transformat XSL173

7.4.1.Nazwa pliku transformaty XSL z wersj IG174

7.4.2.Wersjonowanie Transformaty w ramach wersji IG174

7.5.Wdraanie nowej wersji IG174

8.Zasady rozwoju standardu elektronicznej dokumentacji medycznej175

8.1.Standaryzacja kolejnych rodzajw dokumentw medycznych175

8.1.1.Centralna standaryzacja176

8.1.2.Lokalne rozszerzenia w zgodzie z IG177

8.1.3.Lokalna standaryzacja179

8.2.Wytwarzanie dokumentw medycznych XML niezgodnych z IG194

8.3.Inne dopuszczalne formaty dokumentw medycznych195

8.4.Zasady wymiany dokumentacji medycznej przy wsparciu P1195

Wprowadzenie

Punktem wyjcia do opracowania dokumentu Polskiej Implementacji Krajowej HL7 CDA, zwanego w skrcie polskim IG (Implementation Guide), jest standard HL7 CDA (Clinical Document Architecture) Release 2. Standard ten definiuje skadni i semantyk elektronicznych dokumentw medycznych na potrzeby ich wymiany w rodowisku medycznym. Z uwagi na zrnicowany charakter obszarw informatyki medycznej i dziedzin medycyny, pomimo wysokiego poziomu szczegowoci samego standardu, praktykuje si tworzenie globalnych (na poziomie organizacji HL7) i lokalnych (na poziomie wdroenia, w przypadku polskiego IG dotyczy to Polski) tzw. dokumentw Implementation Guide, czyli regu doprecyzowujcych standard HL7 CDA w ramach obszaru informatyki lub dziedziny medycyny. Takim doprecyzowaniem standardu, uwzgldniajcym specyfik i wymagania zarwno polskiego systemu ochrony zdrowia, jak i Platformy P1, jest wanie polskie IG.

Poprawna implementacja dokumentw medycznych specyfikowanych polskim IG wymaga zarwno znajomoci w stopniu przynajmniej podstawowym samego standardu HL7 CDA, jak i umiejtnoci odczytu i interpretacji polskiego IG. Intencj autora niniejszej instrukcji jest przekazanie tej wiedzy w sposb moliwie peny, ograniczony jedynie form opracowania.

Cel i zakres dokumentu

Korzystanie z Polskiej Implementacji Krajowej HL7 CDA wymaga znajomoci samego standardu, przyjtych sposobw notacji, uzgodnionych na etapie tworzenia polskiego IG zasad, intencji stojcych za wypracowanym zbiorem regu, a take zestawu artefaktw zwizanych ze standardem i samym IG. Niniejszy dokument jest instrukcj stosowania Polskiej Implementacji Krajowej HL7 CDA, przeznaczon dla twrcw oprogramowania oraz dziaw informatyki usugodawcw, ktrej celem jest uatwienie wdroenia elektronicznej dokumentacji medycznej w zgodzie ze standardem i reguami.

W ramach dokumentu omwiono podstawy standardu HL7 CDA, w tym stosowane typy danych i elementy XML bdce nonikami tych danych, zasady posugiwania si zawartoci polskiego IG, specyfik polskich szablonw, sposoby wykorzystania multimediw w specyfikowanych dokumentach medycznych, wymagania dotyczce stosowania wzw OID, a take podstawowe zasady, ktre naley przyj tworzc nowe typy dokumentw elektronicznych.

W Instrukcji omawiane s dokumenty medyczne w zakresie wersji 1.1 IG, z podziaem na dwa zbiory. Zbir pierwszy stanowi dokumenty, ktrych miejscem przechowywania jest System P1:

recepta;

skierowanie;

zlecenie na zaopatrzenie w wyroby medyczne;

dokument anulujcy powysze, przy czym anulowa mona rwnie inne dokumenty medyczne, w takiej sytuacji dokument anulujcy przechowywany jest wraz z dokumentem anulowanym.

Zbir drugi dotyczy dokumentacji indywidualnej, zarwno zewntrznej, jak i wewntrznej, ktra docelowo powinna zosta ustandaryzowana w caoci, a z ktrej do wersji 1.1 IG opracowano dokumenty:

karta informacyjna leczenia szpitalnego;

karta odmowy przyjcia do szpitala;

protok operacyjny;

konsultacja lekarska i karta porady ambulatoryjnej;

opis badania diagnostycznego;

sprawozdanie z badania laboratoryjnego;

wpis do karty uodpornienia;

karta indywidualnej opieki pielgniarskiej, na ktr skada si pi dokumentw:

karta wywiadu pielgniarskiego;

karta oceny stanu pacjenta;

plan opieki pielgniarskiej;

zalecenia pielgniarskie przy wypisie ze szpitala;

raport pielgniarski.

Instrukcja ma na celu przede wszystkim stworzenie twrcom oprogramowania i osobom wdraajcym elektroniczn dokumentacj medyczn wsplnej bazy wiedzy dotyczcej zasad wytwarzania tej dokumentacji. Lepsze zrozumienie Polskiej Implementacji Krajowej HL7 CDA skutkowa ma zwikszeniem interoperacyjnoci systemw informatycznych ochrony zdrowia, a ostatecznie popraw jakoci obsugi pacjenta i komfortu pracy kadry medycznej.

Podstawy standardu HL7 CDA

Standard HL7 CDA, zatwierdzony przez organizacj ANSI, stosowany jest w wiatowej informatyce medycznej ju od ponad 10 lat, posiadajc implementacje zarwno w wielu europejskich krajach, jak i poza naszym kontynentem. Wysikiem Centrum Systemw Informacyjnych Ochrony Zdrowia (CSIOZ) take Polska staje si jednym z pastw stosujcych ustandaryzowan elektroniczn dokumentacj medyczn. W obliczu sukcesywnego zwikszania poziomu interoperacyjnoci midzy europejskimi systemami ochrony zdrowia pozwala to oczekiwa korzyci nie tylko z informatyzacji procesw wymiany danych medycznych w kraju, ale te z samego faktu zastosowania popularnego standardu.

Warto zauway, e proces standaryzacji realizowany jest przy wykorzystaniu wiedzy polskich ekspertw oraz dowiadcze wynikajcych z zagranicznych implementacji, zatrzymujc t wiedz w kraju i jednoczenie stwarzajc dobre warunki do jej rozpowszechniania.

Jak wspomniano na wstpie, standard, rozwijany przez organizacj non-profit Health Level Seven International (HL7), specyfikuje struktur i semantyk dokumentw medycznych na potrzeby ich wymiany midzy usugodawcami i pacjentami. Dokument medyczny rozumie si przy tym jako efekt aktu udokumentowania przeprowadzonych wiadcze medycznych i uzyskanych w wyniku tych wiadcze rozpozna. Hl7 CDA nie jest wic standardem wymiany danych medycznych - dokument medyczny przekaza mona odbiorcy w dowolny, uzgodniony z nim sposb. Podobnie nie jest te standardem przechowywania danych medycznych mona sobie wyobrazi generowanie dokumentu medycznego przy odczycie danych z relacyjnej bazy danych i sam standard zupenie nie odnosi si do takich praktyk. Standard definiuje przede wszystkim sposb zapisu danych medycznych do pliku XML i zasady ich wywietlania.

Niniejszy dokument nie przedstawia kompletu informacji i wymaga standardu, jego intencj jest jedynie uatwienie wejcia w wiat specyfikacji polskich elektronicznych dokumentw medycznych, a po gbsz wiedz, jeeli taka okae si niezbdna, naley sign bezporednio do standardu.

Pryncypia standardu

Przyjmuje si, e zgodny z HL7 CDA dokument medyczny charakteryzuje si szecioma waciwociami, ktre na jzyk polski mog by przetumaczone nastpujco:

niezmienno w czasie (ang. persistence) dokument medyczny nie moe by zmieniany po jego wystawieniu, moe by co najwyej wykorzystany jako np. zacznik do innych dokumentw, w wyniku czego nie traci jednak pozostaych cech wymienionych niej. W przypadku dokumentw elektronicznych nie istnieje takie pojcie jak adnotacja realizatora na dokumencie w dokumencie zrealizowanym nie ma adnego ladu jego faktycznej realizacji;

moliwo zarzdzania (ang. stewardship) nad dokumentem opiek sprawuje kustosz, tj. instytucja przechowujca dokument. Dba ona o poprawne wersjonowanie dokumentu i jego udostpnianie;

moliwo powiadczenia podpisem (ang. potential for authentication) standard nie precyzuje zasad elektronicznego podpisywania dokumentu medycznego, stosowana jest jedynie flaga w dokumencie informujca o istnieniu zewntrznego podpisu. Mimo to dopuszczalne jest, a w polskim wdroeniu wrcz wymagane, podpisywanie dokumentw zgodnych z HL7 CDA przy wykorzystaniu jednego ze standardw podpisw elektronicznych;

kompletno (ang. wholeness) dokument medyczny jest kompletny i niezaleny jako cao, nie powinien np. zalee od zewntrznych w stosunku do niego systemw informatycznych. Przykadem jest konieczno podania w dokumencie wraz z identyfikatorem pacjenta jego imienia i nazwiska, pomimo e podanie identyfikatora wraz z dostpem do systemu informatycznego przechowujcego dane osobowe mogoby by z technicznego i merytorycznego punktu widzenia wystarczajce. Dokument wywietla si wic bez korzystania z zewntrznych w stosunku do niego zasobw, nie liczc multimediw przekazywanych wraz z dokumentem;

czytelno (ang. human readability) dokument medyczny musi by w peni, tj. w zakresie caej niesionej merytoryki, czytelny dla czowieka, niezalenie od faktu, e format XML i zastosowane przez standard szczegy implementacyjne daj te moliwo analizy dokumentu przez systemy informatyczne. Czytelno zapewnia si stosujc zgodn ze standardem transformat XSL generujc warstw prezentacyjn dokumentu standard zapewnia wic separacj treci dokumentu, zapisanego na potrzeby wymiany w formacie XML, od sposobu jej wywietlania.

Dokument medyczny moe, oprcz tekstu, zawiera take multimedia typu grafik, wideo i dwik, o ile zastosowano opisywane przez standard zasady umieszczania tych multimediw w dokumencie. Zasady stosowania multimediw w ramach polskiego wdroenia standardu opisane s w jednym z rozdziaw niniejszej instrukcji.

Struktura dokumentu HL7 CDA

Dokument medyczny zgodny ze standardem HL7 CDA posiada format XML, jednoczenie standard precyzyjnie definiuje struktur takiego dokumentu i nazwy jego elementw, w tym schem XSD suc weryfikacji instancji dokumentu z t struktur.

Standard nie dopuszcza tworzenia wasnych elementw przez wystawc dokumentu - jedynym sposobem na utworzenie rozszerze standardu o dodatkowe, lokalnie stosowane elementy, poza dugotrwaym procesem uzgadniania ich w ramach prac standaryzacyjnych HL7, jest ich zdefiniowanie w ramach regu obejmujcych lokalne wdroenie standardu (tzw. Implementation Guide omawiany w kolejnym rozdziale), co wie si rwnie z rozszerzeniem standardowej schemy XSD. Prace takie zrealizowano m.in. w polskim wdroeniu, wykorzystujc przedrostek wasnej przestrzeni nazw extPL, dbajc jednoczenie o spenienie jednego z wymaga standardu dotyczcego zakazu tworzenia lokalnych rozszerze gdy istnieje moliwo poprawnego wykorzystania struktur i elementw standardowych, a jednoczenie zakazu zmiany znaczenia elementw standardowych w wyniku wprowadzenia rozszerze. Systemy informatyczne odbierajce dokumenty medyczne nie mog zgasza bdw w wyniku napotkania tego typu lokalnych rozszerze, ktrych one same nie obsuguj, mog je natomiast pomija. Oczywicie polskie rozszerzenia musz by implementowane przez wszystkie systemy informatyczne stosujce Polsk Implementacj Krajow HL7 CDA.

Szkic struktury dokumentu medycznego zaprezentowano na poniszym przykadzie.

Jan

Kowalski

...

...

..

W przykadzie pominito wiele elementw, ma wic on charakter wycznie ilustracyjny. Dokument medyczny w formacie XML moe posiada w nagwku XML element z instrukcj sterujc xml-stylesheet wskazujc transformat XSL stosowan do wywietlenia dokumentu w typowym rodowisku informatycznym klasy PC - w przypadku polskich dokumentw jest to wrcz wymagane, patrz zasady wywietlania dokumentw w dalszej czci niniejszej instrukcji.

Element pocztkowy dokumentu posiada nazw ClinicalDocument. Wewntrz dzieli si on na nagwek i ciao dokumentu. W powyszym przykadzie zaprezentowano rozmieszczone w rnych czciach dokumentu specjalne elementy templateId, zawierajce identyfikatory szablonw, tj. definicji regu dotyczcych oznaczonej czci dokumentu, o ktrych to szablonach mowa jest w kolejnym punkcie.

Ciao elektronicznego dokumentu medycznego

Ciao dokumentu zawiera wszystkie informacje merytoryczne niesione przez dokument, w szczeglnoci dane medyczne pacjenta. Ciao dokumentu zaczyna si od elementu structuredBody podzielone jest na sekcje, ktrych znaczenie wynika z zastosowanych klasyfikatorw (sekcja jest jednym z elementw podlegajcych kodowaniu, zawiera element code). Sekcje zawieraj element tekstowy (text, tzw. blok narracyjny) z opcjonalnym tytuem, przy czym standard wymaga, by elementy tekstowe wywietlane byy w caoci i zawieray pene dane merytoryczne dokumentu medycznego. Dodatkowo sekcja moe zawiera elementy entry, ktrych zawarto musi by niesprzeczna z zawartoci elementu text, a ktre mog nie informacje zapisane w elemencie text, ale w postaci umoliwiajcej automatyczn analiz tych danych przez systemy informatyczne. System sucy do wytwarzania tego typu dokumentw medycznych musi zapewni pen zgodno danych z czci entry sekcji z informacj tekstow w bloku narracyjnym, o czym bdzie jeszcze mowa w dalszej czci instrukcji. Efektem takiego zabiegu jest np. poprawny i czytelny w oczach farmaceuty wygld dokumentu recepty z jednoczesnym automatycznym, realizowanym przez system tego farmaceuty, wyszukaniem leku i zamiennikw w bazie lekw apteki na podstawie danych zawartych w elemencie:

entry/substanceAdministration/entryRelationship/supply/product

Sekcje mog zagnieda si jedne w drugich, a take posiada referencje do zewntrznych dla dokumentu obiektw, np. multimediw - taka zewntrzna referencja oznacza, e obiekt zewntrzny nie naley do dokumentu, jest jednak przez niego wskazywany, a wic do dokumentu naley informacja o tym obiekcie.

Szczegy dotyczce sekcji ciaa dokumentu HL7 CDA opisane zostay w dalszej czci instrukcji.

Nagwek elektronicznego dokumentu medycznego

Nagwek dokumentu tworzy kompletny kontekst danych medycznych zapisanych w ciele dokumentu. Zawiera unikalny identyfikator dokumentu, informacje o dacie i miejscu wytworzenia dokumentu, dane osobowe pacjenta, ktrego dane medyczne dotycz, informacje o wystawcy dokumentu, wizycie, osobach uczestniczcych itp. Takie zestawienie danych zapewnia zachowanie jednej z cech dokumentu, tj. jego kompletnoci.

Zdefiniowany na poziomie nagwka kontekst dokumentu dotyczy caoci ciaa dokumentu, o ile nie jest nadpisywany w poszczeglnych czciach tego ciaa dokumentu. W polskim IG nie wprowadza si tego typu potrzeb, jednak zgodnie ze standardem moliwe jest dla wybranych czci ciaa dokumentu medycznego wskazanie innego ich autora, innego poziomu poufnoci danych czy przykadowo innych ni wymienieni w nagwku uczestnikw udokumentowanej czynnoci. Kontekst jest wic propagowany w gb dokumentu medycznego, a spord wielu mechanizmw standardu HL7 CDA dotyczcych kontroli teje propagacji, w ramach polskiego wdroenia wykorzystuje si jedynie najprostsze.

Szczegy dotyczce nagwka dokumentu HL7 CDA opisane zostay w dalszej czci instrukcji.

Szablony

Szablon HL7 (ang. template) jest zarejestrowanym, a wic take posiadajcym unikalny identyfikator, zestawem regu naoonych na okrelony model danych. W przypadku dokumentu zgodnego ze standardem HL7 CDA model ten dotyczy okrelonej, predefiniowanej czci dokumentu, tj. szablony definiuje si na poziomie caego dokumentu, na poziomie elementu nagwka, na poziomie ciaa dokumentu, poziomie sekcji dokumentu i poziomie elementu entry sekcji. Szablon moe by te naoony na typ danych HL7, lokalnie rozszerzajc lub zawajc jego specyfikacj, co zostao wykonane w wybranych przypadkach w polskim IG.

Szablon HL7 reguluje zarwno struktur modelu, na ktry jest naoony, jak i zawarto instancji tego modelu, a wic fragmentu dokumentu XML w przypadku HL7 CDA. Reguy dotyczce struktury obejmuj takie obszary jak liczno elementw modelu, rozszerzanie lub ograniczanie elementw (dodawanie atrybutw do elementw XML, zmiana struktury wewntrznej elementu), modyfikacja zalenoci pomidzy elementami w modelu, a take wspomniana modyfikacja typw danych. Reguy dotyczce zawartoci instancji modelu obejmuj wskazanie dozwolonych zbiorw wartoci i samych wartoci z tych zbiorw, a take warunkowe wystpowanie okrelonych danych, zalene od innych danych w modelu.

Identyfikatory szablonw zapisuje si w dokumencie XML w postaci elementw templateId, posiadajcych warto identyfikatora w postaci OID w atrybucie root tego elementu (wicej na ten temat w dalszej czci instrukcji, a wskazana w poniszym przykadzie warto atrybutu extension omwiona bdzie w rozdziale dotyczcym wersjonowania szablonw). Na poziomie jednej czci dokumentu medycznego naley umieszcza je w kolejnoci od szablonu najbardziej nadrzdnego do najbardziej szczegowego. Przykadowo kady z kolejnych szablonw stosowanych w polskiej recepcie na poziomie dokumentu:

...

...

jest doprecyzowaniem poprzedniego. Reguy wynikajce z szablonw propagowane s wic w gb dokumentu (nie obowizuj wstecz, ani w kierunku wyszych czci dokumentu), gdzie szablon wymieniony niej na poziomie jednej czci dokumentu dodaje reguy, niekiedy je przepisujc na nowo, do szablonu wymienionego przed nim, podobnie jak szablony stosowane w gbi dokumentu doprecyzowuj reguy definiowane w wyszych czciach dokumentu.

Wytworzenie dokumentu medycznego w zgodzie z szablonami stosowanymi w caej jego definicji wymaga zgodnoci kadego z elementw wytworzonego dokumentu ze wszystkimi reguami z szablonw tego elementu oraz reguami z szablonw wskazanych w wyszych czciach dokumentu.

Zasady przekazywania dokumentu medycznego

Zgodnie z zasad kompletnoci, przekazywany dokument medyczny, w tym rwnie przesyany drog elektroniczn lub na fizycznym noniku danych, musi stanowi komplet informacji, tzn. do wywietlenia danych autoryzowanych przez wystawc nie moe by wymagany dostp do jakiegokolwiek zewntrznego systemu. W zwizku z tym wszelkie elementy zewntrzne, jak np. multimedia wskazywane w dokumencie medycznym jako wywietlane wraz z jego danymi, musz by przesyane wraz z dokumentem w jednej paczce, np. archiwum ZIP.

To samo tyczy si transformaty XSL, standard dopuszcza przekazywanie transformaty lub zestawu transformat jako zalecanych form wywietlania dokumentu, a dodatkowe zaczenie transformaty jest wrcz wymagane jeeli nie ma pewnoci, e system odbierajcy dokument medyczny stosuje odpowiedni, tj. zgodn ze standardem transformat. W przypadku Platformy P1 zakada si, e kady z podczonych systemw bdzie stosowa standardow transformat dostarczan przez CSIOZ, w zwizku z czym transformata nie jest doczana gdy dokumenty przekazywane s przy wsparciu Platformy P1. Przekazanie dokumentw w trybie offline, np. na pendrive lub pycie CD, powinno si wiza z umieszczeniem obok pliku dokumentu medycznego i wywietlanych z dokumentem multimediw, take pliku transformaty XSL do wywietlenia tego dokumentu.

Dokument musi pozosta niezmienny w wyniku przekazania go do odbiorcy, tj. nie mona wymaga od odbiorcy adnych zmian w treci dokumentu, np. modyfikacji identyfikatorw elementw XML lub przepisywania linkw URL do multimediw, celem jego poprawnego wywietlenia. Podobnie zabrania si wymagania specjalnej struktury katalogw, w ramach ktrej dokument byby poprawnie wywietlany. Wymaga si rwnie, by istotne z punktu widzenia interpretacji dokumentu dane dodatkowe, przechowywane poza niezmiennym dokumentem, np. fakt anulowania dokumentu, przesyane byy wraz z tym dokumentem, choby w postaci dodatkowego pliku tekstowego, mimo e nie bd one wywietlane wraz z dokumentem standardow transformat XSL.

Wywietlanie i automatyczna analiza zawartoci

Pord wymaga standardu HL7 CDA dotyczcych zawartoci dokumentu medycznego odnale mona jedno, wymagajce szczeglnej uwagi i jednoczenie do uciliwe dla twrcw oprogramowania. Poniewa zawarto dokumentu medycznego odczytywana jest przez ludzi, a zarazem analizowana automatycznie przez systemy informatyczne, wobec braku prostych i niezawodnych, automatycznych narzdzi rozumiejcych tekst czytelny dla ludzi, w specyfikacji sekcji ciaa dokumentu wydzielone zostay dwa, w zasadzie niepowizane ze sob (nie liczc opisanego niej mechanizmu referencji) obszary. Proponuje si tu polskojzyczne tumaczenie popularnych w angielskojzycznym rodowisku nazw tych obszarw:

blok narracyjny (ang. narrative block) - sformatowany tekst czytelny dla czowieka;

wyraenie kliniczne (ang. clinical statement) - ustrukturyzowany fragment XML do analizy przez systemy, wczony w sekcj relacj, ktrej element nosi nazw entry (z ang. wpis, wejcie, miejsce wpicia danych ustrukturyzowanych w sekcj obok jej danych tekstowych).

W dalszej czci rozdziau omwione zostan oba obszary zawartoci sekcji dokumentu, a take moliwe relacje pomidzy nimi. Naley zaznaczy, e wyraenia kliniczne w sekcjach stosuje si wycznie, gdy w ramach lokalnego wdroenia standardu odpowiednie szablony konkretnego rodzaju dokumentu medycznego na to zezwalaj. We wszystkich standaryzowanych rodzajach polskich dokumentw medycznych dopuszcza si stosowanie wyrae klinicznych, w wikszoci przypadkw zdecydowanie ich wymagajc. Tego typu wymagania nazywa si zwykle stosowaniem szczegowoci na poziomie HL7 CDA Level Three, cho ta nazwa szczegowoci wdroenia standardu nie jest ju wykorzystywana w przypadku stosowanego w Polsce HL7 CDA Release 2, gdy pochodzi ona z wczeniejszego Release.

Blok narracyjny

Z perspektywy osoby czytajcej wywietlan posta HTML dokumentu medycznego, zasada zachowania czytelnoci treci dokumentu obejmuje ca tre autoryzowan przez wystawc. Wystawca, podpisujc dokument elektroniczny, widzi oczywicie t sam tre, ktr czyta odbiorca, a wic wycznie tre wywietlana jest treci autoryzowan przez wystawc. Absolutnie nie jest praktykowane wywietlanie postaci rdowej pliku XML dokumentu medycznego ani osobie czytajcej, ani te podpisujcej, jak to ma miejsce w przypadku niektrych innych stosowanych w Polsce dokumentw elektronicznych i komunikatw.

Blokiem narracyjnym, ktry poza nagwkiem dokumentu jest jedyn treci dokumentu autoryzowan przez wystawc (nie liczc wewntrznych multimediw, o czym dalej), jest element text w kadej sekcji ciaa dokumentu, oznaczany w skrcie jako Section.text, posiadajcy typ danych StrucDoc.Text opisany dalej w rozdziale dotyczcym typw danych. Liczno elementu text w sekcji to 0..1, jest wic on elementem opcjonalnym, przy czym jego wymagalno ma warto Required, a wic jeeli w danej sekcji posiadajcej merytoryczne znaczenie wynikajce z kodowania jej konkretn wartoci np. ze sownika LOINC istnieje jaka zawarto tekstowa do wpisania, to musi ona by podana. Brak bloku narracyjnego w sekcji, gdy jednoczenie umieszczone s w niej dane elementu entry, stosuje si w przypadku, gdy sekcja nie jest wywietlana czytelnikowi dokumentu, a zawiera informacje dla systemw analizujcych tre dokumentu, przykadowo parametry kalibracji urzdze pomiarowych albo informacje o stosowanych w badaniach odczynnikach chemicznych.

Czytelno elementu Section.text wymaga odpowiedniego formatowania. HL7 opracowao specjalny jzyk formatowania tekstu w bloku narracyjnym, podobny do jzyka HTML w zakresie jego najbardziej podstawowych tagw, posiadajcy dedykowan schem XSD zapisan w pliku NarrativeBlock.xsd, umieszczon w zestawie schem dostpnych w polskim IG. Schema ta jest automatycznie wykorzystywana przez gwn schem CDA.xsd, a wic nie musi by uywana bezporednio w kodzie do weryfikacji istniejcych dokumentw, moe za to posuy do implementacji edytora blokw narracyjnych. Dla zawartoci bloku ustalono take dedykowany typ MIME o wartoci text/x-hl7-text+xml.

Ciekawym elementem stosowanym w tym bloku jest tag wskazujcy miejsce w tekcie, w ktrym powinny by wywietlone dane multimedialne, zdefiniowane poza tym blokiem we wpisie strukturalnym.

Dodatkowo sekcja zawiera element opcjonalny title, ktry musi by wypeniony tytuem sekcji, jeeli sekcja taki tytu posiada. Innymi sowy - nie naley stosowa specjalnych zabiegw, np. elementu caption ze stylem pogrubienia tekstu w elemencie Section.text celem wyrnienia etykiety bd tytuu sekcji - w takiej sytuacji obowizkowo naley stosowa element Section.title.

Wyraenie kliniczne

Poza czci czyteln dla czowieka, a wic autoryzowan przez wystawc i widoczn w trakcie jego wywietlania, dokument medyczny moe posiada rwnie cz informacji, ktre nie s autoryzowane przez wystawc, a posiadaj warto merytoryczn np. dla systemw informatycznych. Zapisane w polskim IG reguy wytwarzania konkretnego rodzaju dokumentu medycznego s rdem wymaga odnonie umieszczania tego typu informacji w dokumencie medycznym celem ich automatycznego przetwarzania przez systemy informatyczne w ramach procesw biznesowych, w ktrych dokument jest nonikiem danych.

Przykadem wykorzystania danych nieautoryzowanych moe by identyfikator leku w dokumencie recepty, o ktrym to przykadzie mowa bya nieco wczeniej. Tre recepty wywietla nazw leku, jednak podawanie identyfikatora leku w czci czytelnej przez farmaceut nie powinno by praktykowane. Znacznie lepiej jest umieci identyfikator z rejestru lekw, odpowiadajcy zamieszczonej w czci czytelnej nazwie leku, w danych niewywietlanych, ale przetwarzanych automatycznie przez system farmaceuty. Regua wymagajca takiej informacji we wpisie strukturalnym umoliwia wyszukanie leku w danych magazynowych apteki jeszcze w czasie, gdy sam farmaceuta czyta wywietlan tre recepty. Co wicej, umieszczenie zarwno w bloku narracyjnym, jak i we wpisie strukturalnym flagi nie zamienia umoliwia automatyczne wyszukanie zamiennikw leku wraz z ich cenami, lub zaniechanie wykonywania tej operacji, bez jakichkolwiek dziaa farmaceuty. Potencja elektronicznych dokumentw medycznych w stosunku do ich papierowych odpowiednikw jest, jak wida, ogromny.

Poniewa autor dokumentu autoryzuje wycznie czyteln cz dokumentu, a wic wyraenia kliniczne nie s informacjami, za ktrych poprawno wystawca bierze odpowiedzialno. Za dane wyrae klinicznych odpowiada twrca systemu, w ktrym dokument wystawiono. Do momentu gdy wystawca dokumentu celowo zmodyfikuje tre bloku narracyjnego wprowadzajc niespjno midzy rdow treci tego bloku, a jego ostateczn zawartoci, twrca systemu odpowiedzialny jest rwnie za zachowanie zgodnoci danych czci entry w stosunku do treci bloku narracyjnego. Przykadem moe by dokument z wynikami bada laboratoryjnych, gdzie odpowiadajce poszczeglnym wynikom wyraenia kliniczne typu observation posiadaj wartoci tych wynikw do dalszej analizy przez systemy informatyczne - system taki moe rejestrowa poszczeglne wyniki z dokumentu w rekordzie medycznym pacjenta, po czym umoliwia lekarzowi analiz trendw zmian tych wynikw na przestrzeni czasu. Jednoczenie system wystawcy proponuje tre bloku narracyjnego dokumentu ukadajc te wyniki w czyteln tabel. Wystawca dokumentu ma moliwo dodania opisu w bloku narracyjnym zawierajcym t tabel, ostatecznie moliwo ta skutkowa moe bdn informacj w bloku narracyjnym, przy czym do atwe jest wyznaczenie granicy midzy odpowiedzialnoci twrcy systemu za spjno tych dwch obszarw, a odpowiedzialnoci wystawcy za poprawno ostatecznej wersji bloku w stosunku do jej pierwotnej zawartoci.

Analiza wyrae klinicznych przez systemy odbierajce dokument medyczny nie jest oczywicie obowizkiem tych systemw, lekarz lub pacjent moe by zainteresowany wycznie autoryzowan treci dokumentu bez dodatkowego wspomagania przez system informatyczny. Wyraenia kliniczne mog by wic pomijane przez system odbiorcy dokumentu. Dodatkowo usugodawcy, w wyniku uzgodnie bezporednich, np. posiadajcy to samo oprogramowanie usugodawca kierujcy na badanie i realizujcy to badanie, mog przy zachowaniu zgodnoci z reguami wynikajcymi z szablonu konkretnego rodzaju dokumentu (dalej mowa bdzie o tzw. szablonach otwartych i zamknitych) stosowa elementy opcjonalne, w tym dopuszczalne przez standard i niewymieniane przez reguy szablonw polskiego IG. Zastosowanie elementw opcjonalnych do wasnych celw, moliwe jest oczywicie wycznie gdy nie narusza ono merytorycznych wymaga standardu, niedopuszczalne jest np. wykorzystanie elementw niezgodnie z ich standardowym przeznaczeniem. Napotkane przez systemy innych usugodawcw opcjonalne elementy, z zawartoci ktrych takie systemy nie potrafi skorzysta, s przez nie pomijane jako zbdny dodatek niemajcy wpywu na merytoryk dokumentu medycznego.

Relacje midzy blokiem narracyjnym a wyraeniem klinicznym

Poza faktem, e zawarto bloku narracyjnego i wyrae klinicznych jednej sekcji nie mog by ze sob sprzeczne, nie istniej wymagania na wskazywanie relacji midzy obiema czciami tej samej sekcji.

W sytuacjach rzadkich, tj. wymagajcych dedykowanego tego typu operacjom oprogramowania, gdy zapis wyraenia klinicznego powsta bezporednio z tekstu bloku narracyjnego, co jest moliwe przy zastosowaniu technologii analizy tekstu z tego bloku, ewentualnie w zaawansowanym edytorze tekstu bloku poprzez oznaczanie tekstu i generowanie wybranych typw wyrae klinicznych na potrzeby ich pniejszego automatycznego przetwarzania przez system odbiorcy dokumentu, wane moe by zachowanie informacji o rdle danych wyraenia klinicznego.

Podobnie w znacznie czstszym przypadku odwrotnym, gdy fragmenty tekstu bloku narracyjnego pochodz bezporednio z wyrae klinicznych, reprezentujcych np. wyniki bada albo nazw leku, istotne moe by wskazanie w dokumencie tego typu zalenoci rdo - opis.

Opracowano wic mechanizmy budowy tego typu relacji, stosowane szczeglnie celem wskazania systemowi odbierajcemu dokument poszczeglne rda fragmentw treci bloku narracyjnego. Mechanizmy te przydatne s m.in. w sytuacji, gdy w systemie wytwarzajcym dokument pojawi si konieczno edycji wytworzonego ju dokumentu i zapisania jego nowej wersji - dobrze zaprojektowany edytor tekstowy jest w stanie zachowa w bloku narracyjnym bez zmian tre posiadajc swoje rdo w danych wyraenia klinicznego, o ile dane te nie ulegn zmianie w wyniku wykonywanej edycji.

Mechanizmw tych nie naley myli ze stosowanym w wyraeniach klinicznych elementem reference, ktry suy do budowy relacji midzy tym wyraeniem a zewntrznym dokumentem. Element ten bdzie omawiany na przykadach, w dalszej czci dokumentu.

Relacja wyraenie kliniczne -> blok narracyjny

Z punktu widzenia systemu informatycznego moe istnie potrzeba wskazania, za jak cz treci bloku narracyjnego odpowiadaj poszczeglne fragmenty strukturalnego zapisu wyraenia klinicznego. Potrzeb tak realizuje si stosujc referencj w tekstowej czci wyraenia klinicznego do odpowiadajcej mu czci treci bloku narracyjnego, dokadnie do elementu content posiadajcego identyfikator, obejmujcego tre pochodzc z wyraenia klinicznego.

Uwaga, zapis tekstowa cz wyraenia klinicznego oznacza wskazane przez standard miejsce w wyraeniu klinicznym lub czci jego zapisu, przeznaczone do umieszczania takiej treci - miejsca takie zdefiniowano, mimo e tre ta nie jest nigdy bezporednio wywietlana uytkownikowi, a suy wycznie analizie komputerowej. Przykadem takiej tekstowej reprezentacji klasy Act jest element text wyrae klinicznych typu observation, supply, substanceAdministration, encounter. Przykadem tekstowej reprezentacji czci zapisu wyraenia klinicznego jest element originalText stosowany w elementach code, wykorzystywanych m.in. do klasyfikacji wyrae klinicznych.

Poniszy fragment kodu zawiera przykad relacji elementu observation do tekstu w bloku narracyjnym, przy czym w tej sytuacji zastosowano referencj nie do elementu content, a do elementu tr, co mimo e standard wydaje si o takim przypadku nie wspomina, jest dopuszczalne w polskim IG:

...

...

Morfologia krwi obwodowej

...

...

Drugi przykad prezentuje relacj elementu originalText wartoci sownikowej klasyfikujcej rozpoznanie, tym razem do elementu content w bloku narracyjnym:

Wyniki badania: Morfologia krwi obwodowej

W zaawansowanym edytorze edycja zawartoci elementu content, do ktrego stworzona jest referencja z wyraenia klinicznego, powinna by zabroniona, nie liczc przypadku usunicia lub modyfikacji danych wyraenia klinicznego, w ktrej to sytuacji powinna by realizowana automatycznie.

Relacja blok narracyjny -> wyraenie kliniczne i inne czci dokumentu

Istniej trzy elementy zapisywane w treci bloku narracyjnego, umoliwiajce odnoszenie si z tej treci do zawartoci wyrae klinicznych i innych czci dokumentu, przy czym kady z nich omwiony jest w dalszej czci instrukcji:

element renderMultimedia - w miejscu w tekcie, w ktrym go uyto, umoliwia wywietlenie wskazywanego przez ten element obiektu multimedialnego, ktrego zawarto zdefiniowana jest w treci wyraenia klinicznego, zapisanego w postaci elementu ObservationMedia lub opakowujcego taki element elementu RegionOfInterest. Jest to jedyny przypadek wywietlania w czci tekstowej, a wic czci autoryzowanej przez wystawc dokumentu, zawartoci, ktra zapisana jest w wyraeniu klinicznym;

element linkHTML umoliwia wskazanie zasobu, zarwno znajdujcego si bezporednio w dokumencie (odnonik przenoszcy czytelnika do innej sekcji), jak i znajdujcego si poza dokumentem (zewntrzne zasoby multimedialne). W takiej sytuacji wystawca dokumentu - z punktu widzenia tego bloku narracyjnego - nie autoryzuje wskazywanych odnonikiem danych, autoryzowana jest jedynie tre tego odnonika;

element footnoteRef umoliwia wskazanie treci przypisu umieszczonego np. w bloku narracyjnym innej sekcji dokumentu.

Relacje wyprowadzane z bloku narracyjnego maj wic charakter widocznych dla czytelnika odnonikw, a w przypadku elementu renderMultimedia - wywietlanych danych multimedialnych.

Typy danych HL7 CDA

W niniejszym punkcie opisano wszystkie stosowane przez polskie IG typy danych, ktrymi oznacza si poszczeglne elementy i atrybuty w kadym z szablonw. Dla uproszczenia wykorzystywane jest sowo "element oznaczony typem" nawet jeeli typ danych dotyczy rwnie lub wycznie atrybutu.

Typ abstrakcyjny ANY

Oznaczenie typu ANY dopuszcza zastosowanie dowolnego typu danych, przy czym wymagane jest wskazanie wybranego typu w atrybucie xsi:type tworzonego elementu. Typ ANY, jako bazowy dla wszystkich innych typw danych, zapewnia jednoczenie istnienie podstawowych cech w kadym typie pochodnym, w tym atrybutu nullFlavor, jednego z najbardziej istotnych i najczciej wykorzystywanych przy tworzeniu instancji dokumentu medycznego. Oba atrybuty szczegowo opisano w kolejnych punktach.

xsi:type

Atrybut xsi:type z przestrzeni nazw XMLSchema-instance, oznaczonej tu "xsi", suy do wskazywania dokadnego typu danych elementu, bdcego specjalizacj typu przypisanego do tego elementu. Brak wskazania typu w atrybucie xsi:type oznacza zastosowanie typu przypisanego do elementu, nie liczc wyjtkw niedopuszczalnych, jak abstrakcyjny typ ANY oraz typy RTO i QTY, w przypadku ktrych podanie wartoci atrybutu xsi:type jest konieczne. Przykad zastosowania atrybutu w elementach value oznaczonych typem ANY zaprezentowano w poniszym fragmencie kodu:

...

gdzie wskazanie typu PQ pierwszego elementu value umoliwia uzupenienie konkretnych wartoci tego elementu, jak np. symbol jednostki w atrybucie unit, za wskazanie typu IVL_PQ drugiego elementu value podobne, z moliwoci zdefiniowania zakresu wartoci elementami low i value.

nullFlavor

Atrybut nullFlavor wskazuje wiadome (np. zamierzone przez wystawc dokumentu) oznaczenie elementu jako nieposiadajcego wartoci. Brak tego atrybutu w elemencie oznacza brak oznaczenia elementu jako celowo nieposiadajcego wartoci. Brak wartoci w takim elemencie moe by interpretowany jako niewiadome, bdne ominicie tego elementu przez wystawc, co w przypadku danych wymaganych nie powinno by dopuszczalne w wysokiej klasy edytorze dokumentw HL7 CDA. Istnienie atrybutu nullFlavor w elemencie oznacza celowy brak wartoci elementu, przy czym nawet jeeli jakiekolwiek dane w elemencie s podane, naley je traktowa jako nieistniejce. Dodatkowo sam element nullFlavor przyjmuje wartoci kodw z nastpujcego, obsugiwanego w polskiej transformacie XSL (wywietlanie dotyczy w tym przypadku danych nagwka dokumentu, nullFlavor stosuje si rwnie w wyraeniach klinicznych), zbioru wartoci:

brak kodu lub kod inny ni ponisze - "nie podano";

NI (ang. no information) - "brak informacji";

NA (ang. not applicable) - "nie dotyczy";

UNK (ang. unknown) - "nieznane";

ASKU (ang. asked, but not known) - "nie uzyskano informacji";

NAV (ang. temporaily not available) - "czasowo niedostpne";

NASK (ang. not asked) - "nie pytano".

Istnieje te wyjtek w obsudze wywietlania niektrych szablonw - w zgodzie z regulacjami prawnymi wymagajcymi odpowiedniego oznaczenia usugobiorcy niezidentyfikowanego, a take oznaczenia braku wymaganego w dokumencie adresu usugobiorcy, niezalenie od kodu lub jego braku w atrybucie nullFlavor dla tak oznaczonych elementw identyfikatora usugobiorcy i jego adresu wywietla si oznaczenia "NN" (usugobiorca niezidentyfikowany) i "NMZ" (nie ma miejsca zamieszkania).

Dane binarne BL

Element oznaczony jako BL (ang. Boolean) przyjmuje jedn z dwch wartoci "true" lub "false". Typ BL dopuszcza take brak wartoci, tj. "null". Standard definiuje rwnie typ "nienullowalny" BN (ang. BooleanNotNull), przy czym nie zosta on wykorzystany w polskim IG.

Zastosowanie typu BL w przypadku elementu XML zapisuje si zwykle w postaci atrybutu value tego elementu, np.:

Oznaczenie atrybutu typem BL skutkuje prostym zapisem, jak w przypadku atrybutu displayable:

Dane tekstowe StrucDoc.Text, ED, ST, SC

Standard HL7 CDA, definiujcy dokumenty medyczne, w ktrych niezwykle wan rol peni tekst wywietlany uytkownikowi, definiuje cztery typy danych tekstowych, przypisanych bardzo precyzyjnie do poszczeglnych zawierajcych tekst elementw XML dokumentu medycznego.

StrucDoc.Text

Specyficzny typ danych tekstowych stworzony wycznie dla bloku narracyjnego, tj. elementu Section.text. Posiada dedykowan schem XSD NarrativeBlock.xsd, a take dedykowany typ MIME o wartoci text/x-hl7-text+xml. Powysze zabiegi wynikaj z istnienia dedykowanego jzyka tagowania treci tekstowej w bloku narracyjnym celem jej poprawnego formatowania. Oczywicie tagowanie nie jest wymagane, w Section.text mona wpisa sam czysty tekst, zostanie on wtedy wywietlony w najprostszej postaci.

Standard dopuszcza tagi wymienione w kolejnych punktach.

Uwaga: wikszo tagw i stylw zaprezentowano w przykadach doczonych do polskiego IG, szczeglnie pomocny moe by tzw. dokument testowy z du iloci danych.

(1) content

Element ten suy do objcia fragmentu tekstu, ktry mona w ramach standardowego dla elementu XML atrybutu ID oznaczy unikalnym identyfikatorem, dziki czemu do objtego tekstu mona si pniej odwoa przez referencj - patrz punkt na temat relacji midzy blokiem narracyjnym a wpisem strukturalnym.

Drug istotn cech elementu content jest moliwo stosowania stylw wywietlania objtego nim tekstu przy wykorzystaniu atrybutu styleCode, o ktrym mowa jest w dalszej czci rozdziau.

Trzeci cech jest moliwo oznaczenia tekstu usunitego lub dodanego w stosunku do poprzedniej wersji dokumentu medycznego. Wykorzystywany do tego celu jest atrybut revised elementu content, ktry przyjmuje wartoci insert lub delete. Pierwsza warto oznacza, e tekst objty elementem content zosta dodany w stosunku do treci z poprzedniej wersji dokumentu, druga warto oznacza usunicie treci z poprzedniej wersji dokumentu. Poniewa funkcjonalno ta przydatna jest w wyjtkowych okolicznociach, tj. gdy osoba czytajca zna tre poprzedniej wersji dokumentu i zainteresowana jest zmianami w kolejnej, polska transformata XLS nie obsuguje tego formatowania, nie wywietla treci oznaczonej jako delete, a tre oznaczon jako insert wywietla nie wyrniajc faktu jej dodania. Funkcjonalno transformaty w tym obszarze moe zosta rozszerzona, naley zgosi tak potrzeb do CSIOZ wraz z uzasadnieniem.

(2) linkHtml

Element ten suy tworzeniu odnonikw do identyfikatorw, tj. standardowych atrybutw ID innych elementw dokumentu medycznego, np. content tego samego lub innego bloku narracyjnego - w takiej sytuacji identyfikator w atrybucie href elementu naley poprzedzi znakiem #. Jego funkcja jest wtedy podobna do tagu HTML anchor i nie posiada adnego dodatkowego znaczenia merytorycznego. Naley zaznaczy, e polska transformata XLS obsuguje odnoniki tego typu wycznie do przypisw, czyli elementw footnote.

Element moe suy te do umieszczania linkw do zewntrznych w stosunku do dokumentu zasobw, w tym treci multimedialnej. Zawarto atrybutu href elementu wywietlana jest transformat w postaci standardowego tagu a z atrybutem href i treci linku pobieran spomidzy tagu otwierajcego i zamykajcego linkHtml. Zapis jest identyczny ze standardowym kodem HTML.

(3) sub i sup

Otoczony elementem sub tekst wywietlany jest w tzw. indeksie dolnym, a w przypadku sup - w grnym. Podobnie wywietlane s odnoniki footnoteRef do przypisw.

(4) br

Nieposiadajcy zawartoci Tag, zapisywany w postaci , przenosi tre zapisywan po nim do nowej linii. Zamiast tego elementu zaleca si stosowanie elementu paragraph celem wydzielenia fragmentu tekstu do akapitu.

(5) caption

Element caption otacza tekst bdcy nagwkiem takich elementw, jak: paragraph, list, list item, table i table cell oraz renderMultimedia. Nagwek elementw jest wyrniony w tekcie bloku narracyjnego, przyjmujc dodatkowe zasady wyrniania w postaci zawartoci atrybutu styleCode. Zwraca si uwag, e w przypadku niektrych elementw zastosowanie nagwka caption powoduje do dziwne efekty - trudno jest dobrze wywietli nagwek w kadym moliwym przypadku, np. w polskiej transformacie XSL nagwek elementu list item po prostu poprzedza tekst pozycji listy, stajc si pogrubionym pocztkiem tego tekstu.

(6) footnote i footnoteRef

Funkcjonalno odnonikw umoliwia wyjcie treci objtej znacznikiem footnote w inne miejsce w dokumencie (jest to zalene od implementacji transformaty), przy czym w miejscu znacznika footnote pojawia si odnonik do wyjtej treci. Dodatkowo, jeeli do wyjtej treci stosuje si wicej ni jeden odnonik, umieszczenie kadego kolejnego odnonika wymaga wykorzystania znacznika footnoteRef. Znacznik footnote przyjmuje identyfikator wskazywanej treci w atrybucie ID. Znacznik footnoteRef wymaga wykorzystania tego samego identyfikatora w atrybucie IDREF.

W polskiej transformacie XSL zawarto elementu footnote przenoszona jest na koniec bloku narracyjnego, w ktrym zostaa zapisana, do dedykowanego obszaru posiadajcego tytu Przypisy.

(7) paragraph

Otoczony elementem paragraph tekst zostaje wydzielony do oddzielnego akapitu. Element moe zawiera wewntrzny element caption, tj. nagwek akapitu, wywietlany przed treci akapitu i odpowiednio wyrniony. Zaleca si stosowanie akapitw celem poprawy czytelnoci duszych tekstw, jest to metoda znacznie lepsza od elementu br.

(8) list

Element list ma podobne zastosowanie jak element HTML o tej samej nazwie, zawiera on jeden lub wicej elementw item, w treci ktrych umieszcza si tekst do wypunktowania. Atrybut listType elementu list dla wartoci ordered skutkuje wywietleniem listy numerowanej, a dla domylnej wartoci unordered - zastosowaniem punktorw graficznych. Zarwno list, jak i item, umoliwiaj zastosowanie atrybutu styleCode, a take umieszczenie w ich treci elementu caption z treci nagwka listy lub punktora, ktry to element caption standardowo przyjmuje atrybut styleCode.

(9) table

Element table stosuje si podobnie jak jego odpowiednik w jzyku HTML. Ograniczono zawarto komrek i dostosowano style, dla ktrych stosuje si atrybut styleCode zarwno na poziomie samej tabeli, jak i poszczeglnych jej elementw. Lista obsugiwanych tagw, w zastosowaniu podobnych do swoich odpowiednikw z HTML, oraz dopuszczalnych dla nich atrybutw - prezentuje si nastpujco:

tag TABLE: ID language summary width border frame rules cellspacing cellpadding;

tag COL: ID language span width align char charoff valign;

tag COLGROUP: ID language span width align char charoff valign;

tag TBODY: ID language align char charoff valign;

tag TD: ID language abbr axis headers scope rowspan colspan align char charoff valign;

tag TFOOT: ID language align char charoff valign;

tag TH: ID language abbr axis headers scope rowspan colspan align char charoff valign;

tag THEAD: ID language align char charoff valign;

tag TR: ID language align char charoff valign,

przy czym atrybuty border, cellspacing i cellpadding uznano za przestarzae ze wzgldu na moliwo wykorzystania atrybutu styleCode.

(10) atrybut styleCode

Opracowano do krtk list stylw stosowanych w elementach (uwaga, wane s wielkoci znakw, kady kod stylu zaczyna si od wielkiej litery), a mianowicie:

(a) style czcionki

Bold - pogrubiona;

Underline - podkrelona;

Emphasis - pogrubiona;

Italics - kursywa;

(b) krawdzie komrek tabeli

Lrule - rysowana jest lewa krawd;

Rrule - rysowana jest prawa krawd;

Toprule - rysowana jest grna krawd;

Botrule - rysowana jest dolna krawd;

Uwaga, jeeli powysze style dotyczce krawdzi tabeli nie s wykorzystywane w dokumencie, transformata domylnie rysuje wszystkie krawdzie.

(c) numery list

Arabic - liczby arabskie od 1;

LittleRoman - mae liczby rzymskie od i;

BigRoman - wielkie liczby rzymskie od I;

LittleAlpha - mae litery od a;

BigAlpha - wielkie litery od A;

(d) punktory list

Disc - koo;

Circle - okrg;

Square - kwadrat.

Style traktowane s jako sugestie wywietlania tekstu, tj. nie s obligatoryjne w zastosowaniu, jednak w polskiej transformacie zaimplementowano je wszystkie. List stylw mona rozszerza o style lokalne, nie zostao to jednak wykorzystane w polskim wdroeniu standardu.

Elementy zawierajce atrybut styleCode mog si nawzajem zawiera, styl wskazany w elemencie nadrzdnym propaguje si wtedy do wewntrz, o ile nie zostanie nadpisany wewntrz wartoci odmienn dotyczc tego samego rodzaju formatowania.

(11) renderMultimedia

Element renderMultimedia wskazuje dokadne miejsce w bloku narracyjnym, w ktrym to miejscu umieszczona ma zosta (np. wywietlona) tre multimedialna. Tag ten, przy wykorzystaniu atrybutu referencedObject, pozwala wskaza definicj tej treci w dokumencie, umieszczon we wpisie strukturalnym w elemencie ObservationMedia lub RegionOfInterest (wicej o zasadach umieszczania treci multimedialnej w dedykowanym temu tematowi rozdziale). Element renderMultimedia moe te zawiera nagwek caption, wywietlany bezporednio przed treci multimedialn.

Przykad zastosowania elementu wraz z elementem zawierajcym tre multimedialn bezporednio w ciele dokumentu wyglda nastpujco:

Zdjcie rodzinne:

{tu tre base 64}

Multimedia wywietlane w ramach bloku narracyjnego s uznawane za penoprawn, autoryzowan przez wystawc tre dokumentu. Jednoczenie zawarto wyraenia klinicznego observationMedia jest jedyn zawartoci, ktra wywietlana jest w ramach bloku narracyjnego z danych wyraenia, o ile w bloku zastosowano wskazujcy t zawarto element renderMultimedia.

ED (Encapsulated Data)

Typem ED oznacza si element zawierajcy dane, ktrych struktura nie jest regulowana specyfikacj standardu HL7 CDA. Moe to by tekst pisany jzykiem naturalnym, dane multimedialne, podpis elektroniczny, a take referencja poza dokument wskazujca dane zewntrzne.

Typ ED jest specjalizacj typu binarnego BIN, dla ktrego nie zapisano tu dedykowanego punktu, a co do ktrego warto nadmieni, e element tego typu w swojej zawartoci (tzn. midzy tagiem otwierajcym a zamykajcym) przechowuje dane tekstowe bd w postaci Base64, przy czym atrybut representation elementu posiada warto odpowiednio TXT bd B64 - w tym drugim przypadku informujcy, e zawarto naley zdekodowa do postaci czysto binarnej.

Typ ED zachowuje waciwoci typu BIN rozszerzajc go o rne atrybuty i elementy wewntrzne, z ktrych najbardziej istotne s mediaType i reference. Poniej zaprezentowano dwa przykady, w ktrych w pierwszym przypadku dane binarne (posta skrcona) zawarte s w treci elementu value typu ED:

/9j/4AAQSkZJR{...}

a w drugim zaprezentowano referencj do danych zewntrznych:

W przypadku zastosowania wartoci TXT atrybutu representation zabrania si wprowadzania elementw rozszerzajcych standard HL7 CDA (tu extPL) do zawartoci takiego elementu, celem np. jakiejkolwiek automatycznej interpretacji danych z tej zawartoci.

Poniej opisano atrybut mimeType i element reference.

(12) mediaType

Typ MIME (standard RFC 2046) danych zawartych w treci elementu. HL7 CDA wymaga, by system obsugujcy dokumenty medyczne potrafi obsuy typy danych takie jak:

text/plain - dla zwykego tekstu;

image/png - obraz;

image/jpeg - obraz

audio/basic - dwik;

audio/mpeg - dwik;

video/mpeg - wideo;

Powysze typy danych obsuguje polska transformata XSL, o czym mowa jest w rozdziale dotyczcym multimediw. Dodatkowo zaleca si, a wic nie jest to konieczne, obsug takich typw jak:

text/html - zawarto HTML;

text/x-hl7-ft - typ danych ze standardu HL7 v2;

model/vrml - obiekty 3D;

application/pdf - dokumenty PDF

application/dicom - dane obrazowe w standardzie DICOM.

(13) reference

Element typu TEL do danych zewntrznych, np. w postaci adresu pliku lokalnego, zasobu FTP lub HTTP, zastpujcy zawarto wbudowan w dokument medyczny (czyli jest to alternatywa np. do wbudowywania danych multimedialnych w postaci base64 bezporednio w dokument medyczny), ewentualnie wskazujcy w zewntrznych zasobach zawarto, ktra mimo to traktowana jest jak wbudowana w dokument medyczny. Dane zewntrzne w stosunku do dokumentu medycznego wymagaj oczywicie ich pobrania celem ich wywietlenia.

ST (Character String) specjalizacja ED

Typ ST wykorzystywany jest do przechowywania danych tekstowych, a wic jest to niejako typ ED (jego specjalizacja) z wartoci atrybutu representation ograniczon do TXT i mimeType do text/plain.

Typowy przykad elementu typu ST to element title, zawierajcy tytu dokumentu:

Recepta

a w przypadku atrybutu - extension elementu typu II:

SC (Character String with Code) specjalizacja ST

Typ SC rozszerza prosty typ tekstowy ST o opcjonalny kod ze wskazanego systemu kodowania. Do zapisania kodu stosuje si standardowe atrybuty typu danych sownikowych CD (omawianego w kolejnym punkcie). Zastosowanie typu SC ograniczone jest w rzeczywistoci do elementu opisujcego urzdzenie, np. sprzt do bada diagnostycznych, gdzie w atrybutach z kodem elementw manufacturerModelName i softwareName podaje si informacj tekstow i jednoczenie kod modelu ze stosowanego sownika - element taki ma charakter raczej informacyjno-dowodowy dla wystawcy dokumentu ni istotne merytorycznie znaczenie w procesie leczenia.

Dane sownikowe CD, CE, CV, CS, CR

Istniej cztery typy elementw sucych do zapisywania danych sownikowych. Dla zobrazowania do zoonego mechanizmu zaprezentowano przykad.

Przykad elementu XML z zapisem typu recepty:

Zaprezentowany kod XML pochodzi z przykadu recepty na import docelowy, dla poprawy czytelnoci usunito jeden z qualifierw. W elemencie code, bdcym typu CE, zawierajcym kod 57833-6 z systemu kodowania LOINC, zapisano jego odpowiednik w elemencie translation typu CD o wartoci 04.01 (Recepta) z systemu kodowania KLAS_DOK_P1, ktry dodatkowo doprecyzowano dwoma kodami ze sownika stworzonego w IG na potrzeby klasyfikacji typw dokumentw.

CD (Concept Descriptor)

CD jest podstawowym, a zarazem najszerszym typem danych sownikowych. Skada si z omiu atrybutw lub elementw, z ktrych w schemie XSD wszystkie s opcjonalne:

@code (ST) - kod ze zbioru wartoci kodw (sownika);

@codeSystem (UID) - identyfikator zbioru wartoci;

@codeSystemName (ST) - nazwa zbioru wartoci moliwa do wywietlenia;

@codeSystemVersion (ST) jeeli konieczne, numer wersji zbioru wartoci;

@displayName (ST) nazwa kodu do wywietlenia, przy czym jest to nazwa wywietlana w systemie rdowym dokumentu i nie musi by wykorzystana w systemie odbiorcy;

originalText (ED) rdowy tekst, dla ktrego utworzono kod, mowa o nim bya w relacjach wyraenia klinicznego do bloku narracyjnego, oczywicie element ten moe zawiera tekst bez adnych referencji;

translation (SET) mechanizm zapisu tego samego kodu odpowiednikiem z innego zbioru wartoci. Przykadem zastosowania translacji jest sowo nieruchomo w kontekcie sowa budynek - znaczenie obu kodw nie musi by takie same, gdy dwa zbiory wartoci opisuj modelowany wiat w innym kontekcie;

qualifier (LIST) mechanizm doprecyzowujcy kod podstawowy dodatkowym kodem z tego samego lub innego zbioru wartoci. Przykadem zastosowania qualifiera jest uycie kodu LEWA dla kodu STOPA.

Warto zauway w przykadzie umieszczonym wyej, e to element translation jest typu CD, w zwizku z czym w tym elemencie umieszczono elementy qualifier. Element code posiada wszy typ CE, w ktrym stosowanie qualifierw jest zabronione.

CE (Coded With Equivalents) specjalizacja CD

Typ CE rni si od CD wycznie brakiem qualifierw, sama schema XSD ogranicza liczno tego elementu do maxOccurs = 0. W samym standardzie, a przez to take w IG, stosuje si moliwie najbardziej precyzyjne typy danych, a wic jeeli w elemencie podlegajcym kodowaniu nie przewiduje si stosowania qualifierw, naley wykorzysta typ CE lub jego specjalizacje.

CV (Coded Value) specjalizacja CE

Typ CV rni si od CE wycznie brakiem elementw translation. Powinien by stosowany zawsze w przypadkach, gdy element podlegajcy kodowaniu posiada wycznie jeden kod z jednego (wybranego z dopuszczalnych) zbioru wartoci, bez moliwoci podawania kodw z alternatywnych zbiorw wartoci w tym samym miejscu.

CS (Coded Simple Value) dziedziczcy z CV

Najprostszy typ elementu danych sownikowych, przechowujcy wycznie kod (dopuszczalne jest stosowanie jedynie elementu code), wykorzystywany w sytuacjach, gdy wymagany jest wycznie jeden zbir wartoci, a przez to zbir ten jest znany i nie jest konieczne przekazywanie informacji o identyfikatorze tego zbioru. Funkcjonalnie zastosowanie tego elementu w elemencie podlegajcym kodowaniu nie rni si niczym od zastosowania atrybutu elementu podlegajcego kodowaniu.

CR (Concept Role)

Typ CR stosowany jest jako tzw. qualifier, o ktrym wspomniano w definicji typu CD. Element o nazwie qualifier posiada dwa podstawowe elementy - name i value oraz opcjonalny atrybut inverted.

Wartoci kodw qualifier'w stosowanych jako doprecyzowanie typu dokumentu medycznego w polskim IG nie wywietla si polsk transformat - kody te su do automatycznej analizy przez systemy informatyczne. Praktykuje si np. uzalenianie nazwy dokumentu medycznego od zastosowanego kodu okrelajcego rodzaj tego dokumentu, a take od qualifier'w okrelajcych typ tego dokumentu w ramach wskazanego rodzaju.

(14) name

Element o nazwie name o typie CV definiuje rol, w ramach ktrej qualifier wystpuje w stosunku do kodu, dla ktrego ten qualifier zdefiniowano. Przykadowo, jeeli kod, dla ktrego zdefiniowano qualifier posiada warto STOPA oznaczajc stop, rola kodu doprecyzowujcego moe brzmie "STRONA", przy czym wymagane jest stosowanie kodu z przyjtego systemu kodowania, ktry moe by inny ni system kodowania kodu, dla ktrego zdefiniowano qualifier.

(15) value

Element o nazwie value o typie CD definiuje doprecyzowanie kodu, dla ktrego zdefiniowano qualifier, w ramach roli tego qualifiera wskazanej kodem elementu name. Dla powyszego przykadu warto kodu elementu value moe brzmie "LEWA", przy czym wymagane jest stosowanie kodu z przyjtego systemu kodowania, ktry moe by inny ni systemy kodowania elementu name i kodu, dla ktrego zdefiniowano qualifier.

(16) atrybut inverted

Atrybut typu binarnego BN, warto true "odwraca" sens roli wskazywanej elementem name, przy czym stosowanie tego atrybutu jest dopuszczalne, gdy w kontekcie wykorzystywanych systemw kodowania ma to sens. W polskim IG nie przewiduje si potrzeby stosowania tego atrybutu.

Identyfikatory II, OID

Stosowane w standardzie HL7 CDA identyfikatory maj charakter globalny i niezmienny w czasie. Innymi sowy - oznaczenie jednego obiektu konkretnym identyfikatorem skutkowa musi tym, e jest to jedyny na wiecie obiekt posiadajcy ten identyfikator, a sam identyfikator nie zostanie ponownie wykorzystany do wskazania innego obiektu. Zaleca si rwnie, by obiekt ten posiada wycznie ten jeden identyfikator, o ile to moliwe - w praktyce np. czowiek moe posiada wiele identyfikatorw, kady w kontekcie roli i zwizanego z ni rodowiska, przykadowo ta sama osoba stosuje PESEL jako pacjent, a NPWZ jako lekarz.

Standardy unikalnych identyfikatorw w HL7 CDA

W HL7 CDA wykorzystywane s dwa standardy unikalnych identyfikatorw, opisane w kolejnych podpunktach.

(17) ISO Object Identifier (OID)

Standard ISO OID definiuje zasady zapisu, a take sposb przydzielania, unikalnych identyfikatorw obiektw, w tym rwnie "unikalnych identyfikatorw pul identyfikatorw generowanych przez systemy informatyczne". Identyfikator w zapisie OID skada si z tzw. segmentw (nazwa stosowana przez CSIOZ), bdcych liczbami dodatnimi i ewentualnie zerami rozdzielanymi znakiem kropki, przykadowo Centrum Systemw Informacyjnych Ochrony Zdrowia posiada nadany przez HL7, jedyny w skali globalnej identyfikator o tej wartoci:

2.16.840.1.113883.3.4424

Wymaga si, by zera stosowane w segmentach identyfikatora nie byy zerami wiodcymi, tzn. niedopuszczalny jest zapis segmentu rozpoczynajcy si od zera, przy czym dopuszcza si, cho jest to rzadko stosowane, by segment by zerem.

Cech charakterystyczn standardu ISO jest struktura identyfikatorw obiektw ukadajca si w drzewo, ktre zaczyna si od segmentu z cyfr 1 lub 2 w zalenoci od organizacji zarzdzajcej wybran czci identyfikatorw.

W polskim IG atrybut root identyfikatora oznaczany jest typem OID, a wic standard ISO OID jest wymaganym sposobem budowy identyfikatorw w dokumentach medycznych w Polsce.

Na potrzeby stosowania tego typu identyfikatorw CSIOZ prowadzi Rejestr OID, publikowany w ramach polskiego IG. Dodatkowo od twrcw systemw informatycznych, ktre pracuj w ramach Platformy P1, wymaga si zgodnoci tych systemw z tzw. polityk stosowania identyfikatorw typu OID, przy czym o samej polityce traktuje dedykowany jej rozdzia w dalszej czci niniejszej instrukcji.

(18) DCE Universal Unique Identifier (UUID)

Standard UUID, podobnie jak OID, definiuje zasady zapisu, a take sposb generowania (identyfikatorw nie przydziela si jak w przypadku OID), unikalnych identyfikatorw obiektw, w tym rwnie "unikalnych identyfikatorw pul identyfikatorw generowanych przez systemy informatyczne". Kady identyfikator obiektu skada si z piciu liczb w zapisie szesnastkowym rozdzielanych znakiem mylnika, przy czym pierwsza liczba jest 8-cyfrowa, ostatnia 12-cyfrowa, a pozostae 4-cyfrowe. Unikalno, ktra w przeciwiestwie do OID nie jest unikalnoci stuprocentow, zapewnia si stosujc do generowania identyfikatorw adres MAC systemu generujcego, aktualn dat i czas, a take generator liczb losowych.

UUID, cho dopuszczalny przez HL7 CDA jako warto root identyfikatora, np.:

nie jest stosowany w ramach polskiego IG.

O standardzie tym wspomina si tutaj, poniewa wartoci w formacie UUID wykorzystywane s w niektrych sytuacjach w systemach Platformy P1, np. jako warto extension tzw. "lokalnego w systemie usugodawcy identyfikatora pacjenta" w sytuacji gdy systemem tym jest udostpniana przez CSIOZ Aplikacja Usugodawcw i Aptek AUiA. Identyfikatory tego typu wymagane s te w komunikacji z tzw. Rejestrem IHE, ktr to rol dla polskiej dokumentacji medycznej peni jeden z podsystemw Systemu P1, przy czym zapis identyfikatora w tym przypadku poprzedza si przedrostkiem, np.:

urn:uuid:f0306f51-975f-434e-a61c-c59651d33983

II (Instance Identifier)

Element oznaczony typem II jest identyfikatorem obiektu, opisywanego elementem, w ramach ktrego identyfikator ten jest umieszczony w dokumencie medycznym. Element ten posiada zwykle nazw id, cho nie jest to wymagane przez sam standard, a take atrybuty wymienione w kolejnych punktach.

(19) root

W elemencie id wymaga si podania atrybutu root, zawierajcego w polskim IG identyfikator typu OID. Z praktycznego punktu widzenia sam atrybut root wskazuje konkretny obiekt do rzadko, wycznie gdy temu obiektowi przypisze si warto OID. Przykadowo instytucja CSIOZ, posiadajca przypisany OID o wartoci 2.16.840.1.113883.3.4424, jest jednoznacznie wskazywana identyfikatorem o zapisie:

Wikszo obiektw nie posiada przypisanego OID, a zarazem OID przypisany jest czsto do typu stosowanego identyfikatora (puli identyfikatorw nadawanych obiektowi przy zachowaniu ich unikalnoci w ramach tej puli, jak np. numery polskich praw jazdy). W takiej sytuacji w zapisie identyfikatora warto root wskazuje typ tego identyfikatora (np. PESEL, numer wpisu do rejestru RPWDL, identyfikator instancji dokumentu medycznego), a warto identyfikatora podaje si w atrybucie extension.

(20) extension

Jeeli identyfikowany obiekt (konkretna instancja) wymaga zastosowania dodatkowej wartoci wskazujcej dokadnie ten obiekt, warto t podaje si w atrybucie extension.

Zaleca si, by warto extension bya identyfikatorem alfanumerycznym, nie zawierajcym wiodcych zer. Warto, podobnie jak cz root, porwnuje si na zasadzie porwnywania typw tekstowych, tj. extension rwne 0123 jest inn wartoci ni extension rwne 123. Zasady unikania wiodcych zer absolutnie nie stosuje si, gdy wiodce zera wymagane s przez specyfikacj konkretnego typu identyfikatora, przykadowo identyfikatory podmiotw leczniczych bdce numerami wpisw do Rejestru Podmiotw Wykonujcych Dziaalno Lecznicz skadaj si z 12 cyfr, w tym wikszo cyfr wiodcych jest zerami (przynajmniej jedno zero wiodce pojawia si bdzie w identyfikatorze dopki w kraju nie osigniemy iloci stu miliardw podmiotw wykonujcych t dziaalno), a wic poprawny identyfikator podmiotu z numerem wpisu 000000999999 to:

Istotny jest zapis wartoci identyfikatora, wymaga si, by stosowany by zapis wycznie istotnych merytorycznie skadowych tej wartoci, bez dopuszczalnych znakw dodatkowych. Przykadowo identyfikator PESEL musi skada si wycznie z 11 cyfr bez mylnikw rozdzielajcych. Podobnie seria i numer dowodu osobistego lub innego, w tym zagranicznego dokumentu - bez spacji midzy literami serii i numerem oraz bez dodatkowych znakw rozdzielajcych. Spjny zapis wartoci identyfikatora jest jedynym sposobem na zachowanie jednoznacznej identyfikacji wszystkich wystpie obiektu identyfikowanego t wartoci.

(21) assigningAuthorityName

Atrybut opcjonalny, przechowujcy nazw instytucji generujcej identyfikator, powinien by wypeniany wycznie, gdy informacja ta ma dla osoby czytajcej dokument jaki merytoryczny sens. Warto atrybutu nie moe by wykorzystywana do analizy przez systemy informatyczne, do tego celu suy warto atrybutu OID. W przypadku polskiej transformaty XSL nazwa instytucji wywietlana jest przy identyfikatorze w nawiasach, przy czym szczeglnie nie zaleca si wypeniania tej nazwy dla powszechnie znanych identyfikatorw, ktrych OID tumaczony jest przez transformat na ich nazw, jak np. PESEL.

(22) displayable

Warto typu BL, z domyln wartoci true, skutkujc wywietleniem identyfikatora przez transformat. Podanie wartoci false powoduje, e identyfikator nie bdzie wywietlany transformat, a wic podano go w dokumencie wycznie do wykorzystania przez systemy informatyczne.

W polskiej transformacie XSL stosuje si wyjtki od powyszej zasady - w przypadku niektrych identyfikatorw przyjmuje si, e podany identyfikator zawsze jest wywietlany, ewentualnie wywietla si wycznie identyfikatory powszechnie znane pomijajc te nieposiadajce oficjalnej nazwy. Stosowane wyjtki dotycz np. identyfikatora pacjenta - wywietlane s wycznie znane, tj. uznawane przez polskie prawo identyfikatory pacjenta, a dodatkowo wywietlanie nie jest zalene od obecnoci i wartoci atrybutu displayable w tym identyfikatorze. Przyjte zaoenie powoduje, e twrca systemu informatycznego powinien oznacza wartoci false atrybutu displayable wycznie identyfikatory, ktre nie s wymagane przez polskie prawo, a jednoczenie dedykowane s wycznie automatycznej obsudze przez systemy informatyczne.

Istotny jest rwnie fakt, e identyfikatory stosowane w wyraeniach klinicznych sekcji (tj. wewntrz entry) nigdy nie s wywietlane bezporednio z poziomu wyraenia, tzn. aby identyfikator taki by wywietlany, jego warto musi by umieszczona w bloku narracyjnym sekcji.

Adresy AD, ADXP, oraz adres telekomunikacyjny TEL

Elektroniczny dokument medyczny zawiera dane kontaktowe, w tym dotyczce kontaktu rodkami telekomunikacyjnymi i korespondencji papierowej, a take dane adresowe osb i instytucji wymienianych w dokumencie. Cz wymaga dotyczcych podawania w dokumencie medycznym danych tego typu regulowana jest odpowiednimi aktami prawnymi, jak np. Ustawa o Systemie Informacji w Ochronie Zdrowia wprowadzajca numer telefonu, adres e-mail, albo adres korespondencyjny usugobiorcy do dokumentu zlecenia na zaopatrzenie w wyroby medyczne, jeeli pacjent nie posiada konta na Platformie P1 a chciaby otrzyma potwierdzenie akceptacji zlecenia przez patnika na numer telefonu, adres e-mail lub korespondencj papierow. Cz umieszczanych w dokumencie danych kontaktowych ma zapewni moliwo kontaktu usugobiorcy z usugodawc, gdyby taki kontakt okaza si konieczny w konsekwencji udzielonych wiadcze. Kolejna cz danych ma charakter identyfikacyjny, jak np. dopuszczalny w dokumencie medycznym adres siedziby usugodawcy, mimo e sugeruje si podawanie wycznie adresu miejsca udzielenia wiadczenia.

Wymienione w kolejnych punktach dwa typy danych su realizacji powyszych potrzeb.

TEL (Telecommunication Address)

Dane do kontaktu rodkami telekomunikacyjnym podaje si w postaci adresu URL, tj. zgodnie ze specyfikacj Internet standard RFC 1738. Dane te obejmuj adresy e-mail, WWW, numery telefonw, faksw, adresy plikw na serwerze FTP itp. URL wymaga podania protokou komunikacyjnego i adresu zasobu zgodnego z tym protokoem.

Standardowo typ TEL przypisany jest do elementu posiadajcego nazw telecom, przy czym istniej te inne przypadki, jak atrybut value elementu reference, bdcego skadnikiem elementu typu ED.

Element telecom moe posiada opcjonalny atrybut use o wartociach, dla ktrych polska transformata XSL realizuje wywietlanie nastpujcych informacji dotyczcych adresu telekomunikacyjnego:

brak kodu - informacja o rodzaju adresu nie jest wywietlana;

H i HP - "domowy";

HV - "podczas urlopu";

WP - "subowy";

DIR - "subowy bezporedni";

PUB - "recepcja";

TMP - "tymczasowy";

EC - "w nagych przypadkach";

MC - "komrkowy";

inny kod - "inny: tu kod adresu".

Prosz zauway, e powysze wartoci stosuje si raczej do numerw telefonw, ewentualnie faksw, rzadziej adresw e-mail.

Atrybut useablePeriod nie jest w Polsce wykorzystywany, moliwe bdzie dodanie jego obsugi do polskiej transformaty na zawierajcy odpowiedni argumentacj wniosek zoony do CSIOZ.

Zawarto atrybutu value elementu telecom posiada typ ST i jak wspomniano - format URL, w ktrym przed znakiem dwukropka podaje si protok, inaczej - czego dotyczy adres, a po dwukropku sam adres. Polska transformata XSL obsuguje nastpujce protokoy:

fax - "faks: ";

http - "Internet: ", tzn. adres WWW;

e-mail - "e-mail: ";

tel - "tel: ";

pozostae - "inny: tu kod protokou".

Przykadowy numer telefonu komrkowego powinien moe by zapisany w dokumencie w nastpujcy sposb:

co przy wykorzystaniu polskiej transformaty, zakadajc, e istnieje tylko jeden element telecom w elemencie nadrzdnym, zostanie wywietlone nastpujco:

AD (Postal Address) i jego cz ADXP

Adres fizyczny zapisywany jest w strukturze wyrniajcej jego poszczeglne fragmenty.

Standardowy typ AD zosta rozszerzony przez polskie IG o atrybut extPL:postCity w dedykowanym temu rozszerzeniu szablonie, opisanym w rozdziale dotyczcym szablonw. Specyfikacja stosowanego w Polsce rozszerzonego typu AD znajduje si wic we wspomnianym rozdziale.

Standardowo typ AD przypisany jest do elementu posiadajcego nazw addr. Element addr moe posiada opcjonalny atrybut use o wartociach, dla ktrych polska transformata XSL realizuje wywietlanie nastpujcych informacji dotyczcych adresu:

brak kodu oraz kody WP, DIR, PUB i PHYS - "Adres";

H i HP - "Adres zamieszkania";

HV - "Adres w trakcie urlopu";

TMP - "Adres tymczasowy";

PST - "Adres korespondencyjny";

pozostae - "Inny adres (tu kod adresu)".

Stosujc kody w atrybucie use elementu addr naley by wiadomym powyszych zasad ich wywietlania w Polsce.

Atrybuty useablePeriod i isNotOrdered nie s w Polsce wykorzystywane, moliwe bdzie dodanie ich obsugi do polskiej transformaty na zawierajcy odpowiedni argumentacj wniosek zoony do CSIOZ.

Zawarto elementu o typie AD charakteryzuje si do zoonym mechanizmem budowania poprawnego, w tym take wizualnie, zapisu danych adresowych. Jego zoono najlepiej jest omwi na przykadzie, ktrego rdem jest specyfikacja standardu:

Windsteiner Weg

54a,

D-14165

Berlin

Efektem takiego zapisu XML ma by wg standardu sformatowanie adresu w postaci:

Windsteiner Weg 54a,

D-14165 Berlin

Omawiajc powyszy przykad, zaczynajc od najprostszej postaci naley zaznaczy, e typ AD dopuszcza rwnie zapisanie danych adresowych w postaci czystego tekstu:

Windsteiner Weg 54a,

D-14165 Berlin

zapis ten ma jednak wady, z ktrych gwne to brak moliwoci automatycznej weryfikacji kompletnoci takiego adresu, zwizany z tym brak technicznej specyfikacji poszczeglnych fragmentw adresu, a take trudnoci z wywietlaniem znaku przejcia do nowej linii adresu. Z tego powodu w treci adresu stosuje si dodatkowe elementy XML o typie ADXP i nazwach wynikajcych z ich przeznaczenia (np. city), ktrymi obejmuje si poszczeglne fragmenty adresu. Mechanizm ten pozwala w sposb techniczny wymaga istnienia wybranych danych adresowych w dokumencie, nie wpywajc jednak na sposb ich wywietlania. Dodatkowym elementem, pozwalajcym wymusi przeniesienie czci adresu do nowej linii, jest element delimiter, stosowany w odpowiednich miejscach, tj. w ssiedztwie innych nazwanych elementw. Dodanie do tego znakw interpunkcji pomidzy elementami nazwanymi pozwala autorowi dokumentu, ale te specyfikacji typu IG, definiowa peny sposb wywietlania danych adresowych w dokumencie medycznym, niezalenie od zastosowanej transformaty XSL, a w rzeczywistoci zalenie od zastosowanych w transformacie mechanizmw obsugi takiego formatowania.

W polskich warunkach, w tym w polskiej transformacie XSL, przyjto nieco inne zaoenia. Polski adres formatowany jest wycznie przez transformat w jeden, spjny sposb, zaleny od obecnoci poszczeglnych elementw adresu w dokumencie. Nie stosuje si formatowania poprzez wykorzystanie elementu delimiter czy te interpunkcji w dokumencie medycznym. W przypadku adresu zagranicznego dopuszcza si wykorzystanie najprostszego zapisu, a wic czystego tekstu, ktry wywietlany jest w postaci, w jakiej zosta podany w dokumencie, przy czym naley stosowa wymaganie polskiego IG w tej kwestii, omwione w dedykowanym rozdziale.

Podobnie, z perspektywy polskich wymaga, specyfikacja typu ADXP, tj. fragmentu adresu, ogranicza si do istnienia i wymaga obecnoci w dokumencie poszczeglnych nazwanych elementw, zgodnie z polskim IG, o czym mowa bdzie we wspomnianym rozdziale dotyczcym polskich szablonw.

Nazwy EN, ENXP, PN, ONEN (Entity Name)

Nazwy instytucji, miejsc, osb i rzeczy zapisuje si w elementach oznaczanych typem EN lub jego specjalizacjami. Podobnie jak w przypadku adresu, zoono zapisu zawartoci elementu EN, skadajcego si z atrybutu use, atrybutu validTime, definiujcych zasady formatowania elementw nazwanych przemieszanych ze znakami interpunkcji - pozwala na zapisanie dowolnie zoonej nazwy, wraz z wymaganiem poszczeglnych jej czci.

W polskim IG zastosowanie oglnego typu EN, jak w przypadku elementu name szablonu 2.16.840.1.113883.3.4424.13.10.4.27 Miejsce, wie si z wymaganiem prostej nazwy - nie przewidziano potrzeby stosowania elementw skadowych i nie zaleca si komplikacji tego typu nazw w polskich dokumentach medycznych. Polska transformata XSL nie obsuguje zoonoci elementu typu EN poza wywietlaniem prostej zawartoci tekstowej tego elementu po stosownym, wasnym formatowaniu, ewentualnie poinformowaniu o braku nazwy jeeli uyto atrybutu nullFlavor.

ENXP (Entity Name Part)

Element oznaczony typem ENXP stosowany jest jako cz treci elementu typu EN lub jego specjalizacji. W polskim IG wskazuje si wycznie trzy elementy typu ENXP w nazwie osoby (polska transformata XSL obsuguje cztery), o czym mowa bdzie w punkcie dotyczcym typu PN. Jednoczenie pomijane s dopuszczalne przez standard atrybuty elementu typu ENXP, a jego zawarto wywietlana jest wprost w postaci tekstu.

PN (Person Name) specjalizacja EN

Nazwa osoby to imiona i nazwisko poprzedzone prefiksem. Na potrzeby tego typu danych w polskim IG zdefiniowano dedykowany szablon 2.16.840.1.113883.3.4424.13.10.7.2 Nazwisko i imi osoby (bazowy), w ktrym wymaga si minimum jednego elementu typu ENXP o nazwie given (imi, od ang. "nadane") i minimum jednego elementu o nazwie family (nazwisko). Dodatkowo dopuszcza si zastosowanie maksimum jednego prefiksu, a jednoczenie szablon jest szablonem otwartym, a wiec dopuszcza si zastosowanie sufiksu, ktry jednak w Polsce w zasadzie nie jest wykorzystywany (moe posuy np. do zapisania anglosaskiego tytuu doktora PhD, ktry podaje si po nazwisku). Polska transformata XSL obsuguje wszystkie cztery elementy typu ENXP wprost wywietlajc sformatowan ich zawarto. Nie stosuje si elementu delimiter i jest on pomijany przez polsk transformat.

ON (Organization Name) specjalizacja EN

Nazwa instytucji, stosowana zwykle w elemencie o nazwie name, oznaczonym typem ON, wywietlana jest polsk transformat XSL w najprostszej moliwej tekstowej postaci, z pominiciem obsugi atrybutw typu use, validTime, oraz elementw skadowych typu prefix, suffix i delimiter. Obsugiwany jest atrybut nullFlavor. Wobec powyszego, zaleca si stosowanie prostych, czysto tekstowych nazw instytucji w dokumentach medycznych.

Ilo QTY, INT, REAL, wielko fizyczna PQ, wskanik RTO, RTO_PQ_PQQTY (Quantity)

Abstrakcyjny, jak wspomniano w punkcie dotyczcym atrybutu xsi:type, typ QTY jest generalizacj wszystkich typw okrelajcych policzaln wielko. Oznaczenie elementu tym typem wymaga podania konkretnego typu w atrybucie xsi:type instancji. Sam typ QTY nie wnosi istotnych waciwoci do dziedziczcych po nim typw.

INT (Integer Number) specjalizacja QTY

INT oznacza liczb cakowit. Dla okrelenia dodatniej i ujemnej nieskoczonoci stosuje si atrybut nullFlavor o wartoci PINF i NINF. Przykadem zastosowania elementu typu INT jest numer wersji dokumentu medycznego:

W polskim IG spotyka si rwnie oznaczenie typu INT.POS, obejmujce podzbir liczb cakowitych dodatnich, jak np. numer kolejny urodzenia dziecka z ciy mnogiej (numer wersji dokumentu rwnie mgby by tak oznaczony, posiada jednak typ oglny INT).

REAL (Real Number) specjalizacja QTY

Liczba rzeczywista, oznaczana typem REAL, zgodna z typem decimal schemy XSD. Wartoci dodatniej i ujemnej nieskoczonoci zapisuje si w sposb identyczny, jak w przypadku typu INT.

PQ (Physical Value) specjalizacja QTY

Typem PQ oznacza si elementy zawierajce informacje o okrelonej wielkoci fizycznej, np. wynik pomiaru. Warto elementu o tym typie zawiera liczb rzeczywist w atrybucie value oraz jednostk miary w atrybucie unit typu CS. Dopuszczalne jest, podobnie jak w przypadku elementw typu CD, stosowanie elementu translation do wskazania wartoci tej samej wielkoci fizycznej z inn jednostk (np. cale dla metrw) - przypadek taki nie jest jednak wykorzystywany w polskim IG. Wartoci dodatniej i ujemnej nieskoczonoci zapisuje si w sposb identyczny, jak w przypadku typu INT.

Typowym przykadem elementu typu PQ jest warto wyraona w procentach:

RTO (Ratio) specjalizacja QTY

Wspczynniki wielkoci zapisuje si w elementach oznaczonych typem RTO. Wspczynnik skada si z wartoci licznika i wartoci mianownika, dla ktrych niezalenie okrela si typy ich wartoci. Istotne jest, by warto zapisana w elemencie typu RTO bya rzeczywicie wielkoci fizyczn, przykadowo nie jest ni zapis wyniku cinienia krwi ("120/80"). Dodatkowo wiele wspczynnikw, dla ktrych nie s istotne jednostki miary, zapisa mona w postaci wartoci typu REAL.

Naley przyj, e podanie wartoci licznika i mianownika jest obowizkowe. Standard przewiduje domyln wartoci licznika i mianownika rwn 1 typu INT, jednak nie praktykuje si przyjmowania tej wartoci jako istniejc gdy licznika lub mianownika nie podano. Dodatkowo mianownik nie moe posiada wartoci 0. Wartoci dodatniej i ujemnej nieskoczonoci zapisuje si na poziomie gwnego elementu w sposb identyczny, jak w przypadku typu INT.

RTO jest typem generycznym, co oznacza, e typ licznika i mianownika musi by zdefiniowany w instancji elementu typu RTO. S dwa sposoby definiowana tej wartoci - pierwszy poprzez wykorzystanie atrybutu xsi:type licznika i mianownika, gdzie w obu przypadkach podaje si jeden z typw dziedziczcych z typu QTY:

Drugi - poprzez wykorzystanie atrybutu xsi:type elementu typu RTO, gdzie podaje si typ zoony z nazw poszczeglnych typw poczonych znakiem podkrelenia. Przykadowo zastosowanie typu RTO_INT_PQ w atrybucie xsi:type elementu typu RTO oznacza, e licznik wspczynnika jest liczb cakowit, a mianownik wartoci fizyczn posiadajc jednostk. Nasz poprzedni przykad wyglda bdzie w tej sytuacji nastpujco:

Oba sposoby zapisu s rwnowane, w obu przypadkach kady z typw moe by oczywicie inny.

Czas TS, TS.DATE, GTSTS (Point In Time) specjalizacja QTY

Wielko typu TS wskazuje punkt w czasie w postaci wyraenia (zapisu) "kalendarzowego", tj. inaczej ni w wikszoci jzykw programowania. Stosowany format zapisu nie jest jednak zgodny z typem xsd:dateTime standardowej schemy XSD, nie stosuje si mylnikw ani litery T do rozdzielenia czasu od daty. Format zapisu wyglda nastpujco:

YYYYMMDDHHMMSS.UUUU[+|-ZZzz]

gdzie Y oznacza cyfr roku, M cyfr miesica, D dnia, H godziny, kolejne M minuty i S sekundy - w polskich warunkach, tj. w typowych dokumentach medycznych, nie zaleca si stosowania wikszej precyzji (litery U po kropce) ani informacji o strefie czasowej (litery Z i z ze znakiem). Cyfry kadej z liter mog zosta od strony prawej pominite, co zmniejsza precyzj zarwno czasu, jak i ostatecznie daty (a do samego roku), a jest zarazem poprawnie wywietlane polsk transformat XSL. Przykad zapisu daty i czasu z dokadnoci do sekundy:

Zapis typu w postaci TS.DATE oznacza zastosowanie typu TS, czyli punktu w czasie, z dokadnoci do daty, tj. bez czasu. Typ ten stosuje si m.in. w przypadku dat urodzenia:

GTS (General Timing Specification)

GTS to oglny typ pozwalajcy na zastosowanie, wraz z jego podaniem w atrybucie xsi:type elementu oznaczonego typem GTS, dowolnego precyzyjnego typu danych opisujcego czas. Przykadem jest czstotliwo podawania leku w elemencie substanceAdministration.effectiveTime oznaczonym typem GTS, zapisana przy wykorzystaniu precyzyjnego typu danych PIVL_TS, omwionego w nastpnym punkcie.

PIVL (Periodic Interval of Time)

Punkt w czasie lub okrelony czas trwania powtarzajcy si okresowo zapisuje si w elementach oznaczanych typem PIVL, zawierajcym dwa wewntrzne elementy: phase i period. W punkcie tym omwione zostan najprostsze, a zarazem wystarczajce do zdecydowanej wikszoci zastosowa przypadki zapisu tego typu danych.

phase - opcjonalny element o typie IVL, opisanym w nastpnym rozdziale, zawiera przedzia czasu (czas trwania), o ktrym mowa w definicji typu PIVL. Brak tego elementu oznacza nieokrelony punkt w czasie, co jest wykorzystywane, gdy istotny jest tylko okres.

period - element o typie T.diff jest czstotliwoci powtarzania si przedziau czasu z elementu phase. Zapis T.diff oznacza, e period jest wartoci typu QTY w wymiarze czasu, tzn. jednostka miary wartoci konkretnego typu danych wyraona jest w wymiarze czasu (godzina, minuta, tydzie itp.).

Przykad oznaczajcy np. zaywanie leku "co 12 godzin" wyglda nastpujco, przy czym zawarto atrybutu xsi:type oznacza, e operuje si typem TS:

Kolejny przykad, oznaczajcy 10 minutowy czas trwania np. jakiej czynnoci, powtarzany rwnie co 12 godzin:

Zaleca si stosowanie najprostszych moliwych zapisw czasu, komplikacja moe powodowa pomijanie zapisw przez systemy informatyczne przy jednoczesnym niewielkim wkadzie merytorycznym.

Zbiory danych i przedziay SET, LIST, IVL

Pomimo e polskie IG nie wymienia typw generycznych, w szczeglnoci kolekcji (popularne sformuowanie specjalistyczne w jz. ang.: generic collections) w sposb bezporedni, zbiory, listy i przedziay wartoci wykorzystywane s w wielu miejscach w dokumencie medycznym - zawsze w kontekcie konkretnego typu danych. W XML nie definiuje si specjalnych elementw na kolekcje elementw okrelonego typu, zamiast tego wymienia si te elementy kolejno jeden po drugim, std brak oznacze poszczeglnych elementw kodami typw generycznych.

Punkt ten pozwoli lepiej zrozumie sens zapisu typw np. IVL_PQ, a take zastosowanie typw wymienionych w kolejnych podpunktach w postaci zbiorw i przedziaw.

SET (zbir)

SET jest nieuporzdkowan kolekcj danych o rnych wartociach, tj. nieuporzdkowan (uporzdkowan losowo) list kolejnych elementw o tej samej nazwie, a wic tym samym typie danych, ale rnych wartociach. Przykadem takiej listy s zwykle identyfikatory obiektu - najczciej dla jednego obiektu dopuszcza si podanie zbioru rnych identyfikatorw, z ktrych wybr "waciwego" zaley od kontekstu, np. PESEL jako oficjalny identyfikator usugobiorcy wybierany jest przez systemy informatyczne, midzy ktrym dokument medyczny jest wymieniany, a drugi podany w danych usugobiorcy, tzw. lokalny w systemie usugodawcy identyfikator usugobiorcy, wykorzystywany jest wycznie gdy istnieje potrzeba odnalezienia np. rekordu medycznego lub logw w systemie, w ktrym dokument zosta wystawiony. Przykad zapisu tego typu zbioru identyfikatorw wyglda nastpujco:

...

List adresw okrela si typem danych BAG, o podobnym charakterze co SET, przy czym BAG dopuszcza istnienie takich samych elementw w zbiorze.

LIST (lista)

Lista posiada podobne zastosowanie co zbir, jest jednak uporzdkowanym zbiorem wartoci, tzn. istotna jest kolejno wystpowania elementw listy. List jest przykadowo zestawienie elementw templateId wskazujcych szablony zastosowane dla konkretnego elementu, przy czym identyfikatory szablonw wymienia si od najbardziej oglnego, do najbardziej precyzyjnego. Innym przykadem zastosowania listy s punkty w ukadzie wsprzdnych kartezjaskich, dla ktrych rysowana jest linia, kolejno od pierwszego punktu do ostatniego i w kocu od ostatniego znw do pierwszego, przy czym same wartoci punktw podzielone s na oddzielne elementy dla kadej ze wsprzdnych. Poniszy listing prezentuje elips - trzeba liczy element, by odgadn ich przeznaczenie w ukadzie wsprzdnych:

...

IVL (przedzia wartoci) i IVXB (warto graniczna przedziau)

Przedzia wartoci jest zbiorem kolejnych wartoci ograniczonym wartoci pocztkow i kocow, ewentualnie wartoci rodkow i szerokoci, przy czym ten drugi przypadek nie jest wymieniany w polskim IG, nie jest te obsugiwany w polskiej transformacie XSL i nie bdzie tu omawiany.

Element, w ramach ktrego definiuje si przedzia wartoci, oznacza si typem zoonym z kodu IVL, znaku podkrelenia _ i kodu typu elementu, ktrego przedzia wartoci si definiuje. W ten sposb dla przedziau liczb cakowitych oznaczenie typu elementu gwnego przyjmuje posta IVL_INT. W przypadku przedziau wielkoci fizycznych - IVL_PQ. W przypadku okresu czasu - IVL_TS.

Warto pocztkowa i kocowa przedziau zapisywana jest w postaci elementu posiadajcego typ IVXB. Typ ten jest specjalizacj dowolnego typu wyliczeniowego, stosowan by wskaza granic przedziau wartoci tego typu. Typ rozszerza kady z typw wyliczeniowych o atrybut inclusive, dla ktrego domylna warto true oznacza, e warto brzegowa przedziau naley do tego przedziau, a false, e nie naley. Typ ten stosowany jest w IG np. jako typ czci skadowych elementu effectiveTime, oznaczanego typem IVL_TS, gdzie czci skadowe to elementy o nazwach low i high. Brak atrybutu inclusive w poniszym przykadzie oznacza, e obie daty wczone s w oznaczony tym elementem przedzia czasu, co naley uzna za preferowany sposb przedstawiania przedziaw, w tym rwnie czasowych. Przykad definiujcy peny przedzia czasu:

Warto zauway, e gdyby pomin element high w powyszym przykadzie, uzyskalibymy przedzia czasu, w ktrym warto pocztkowa jest okrelona, a warto kocowa nie. Zapis taki stosuje si np. dla czasu trwania hospitalizacji (effectiveTime), gdy pacjent wci przebywa na oddziale.

Zasady stosowania polskiego IGPolska Implementacja Krajowa HL7 CDA

Polskie IG publikowane jest w postaci stron HTML m.in. pod adresem http://www.csioz.gov.pl/HL7POL/pl-cda-html-pl-PL/index.html. Przyjto