HL7

Z Wikipedii, wolnej encyklopedii
Skocz do: nawigacja, szukaj

HL7 (ang. Health Level Seven) – standard elektronicznej wymiany informacji w środowiskach medycznych. Opracowany przez organizację o tej samej nazwie, powstałą w 1987 roku. Celem organizacji jest rozwój standardów elektronicznej wymiany informacji klinicznych, finansowych i administracyjnych między systemami informatycznymi w ochronie zdrowia.

Protokoły opisane w HL7 dotyczą warstwy aplikacyjnej (siódmej) modelu OSI stąd nazwa standardu.

HL7 bazuje na tekście ASCII, jest on protokołem komunikacyjnym służącym do wymiany danych medycznych, który definiuje komunikaty poziomu aplikacji używane przez kilka głównych systemów szpitalnych. Główne funkcje systemu obejmują komunikaty dotyczące: dostępu do danych, pobierania danych, przesyłania danych, sterowania, pobierania wyników i obserwacji klinicznych. Wersja 3.0 standardu całkowicie zmieniła model komunikacji. W wersji tej standard jest oparty o język XML, więc wykorzystuje model obiektowy.

Organizacja HL7[edytuj | edytuj kod]

Health Level Seven jest jedną z kilku organizacji amerykańskich akredytowanych przy ANSI. Jest organizacją typu not-for-profit. Obecnym dyrektorem generalnym (ang. CEO – Chief Executive Officer) jest Charles Jaffe. Siedziba organizacji mieści się w Stanach Zjednoczonych w mieście Ann Arbor (stan Michigan). Ponadto organizacja posiada swoje filie w ponad 40 krajach. Pierwsza z filii powstała w Niemczech w 1993 roku.

Organizacja jest złożona z zarządu oraz komitetów technicznych i grup interesu. Każdy komitet lub grupa interesu jest kierowana przez dwóch lub więcej przewodniczących, którzy tworzą wspólnie tzw. Komitet Sterujący. Organ ten głosuje nad przyjęciem standardu oraz jego modyfikacją. Wynik głosowania jest rozpatrywany przez zarząd, który podejmuje ostateczne decyzje odnośnie standardu. Spotkania komitetów i grup odbywają się 3 razy do roku.

Komitety rozwijają standard w wielu dziedzinach. Do dziedzin tych można zaliczyć kwestie związane ze wspomaganiem decyzji w placówkach medycznych, związane z diagnostyką, leczeniem, zarządzaniem personelem, a także logistyką. Ponadto w organizacji działają komitety odpowiedzialne za zapewnienie jakości specyfikacji, zajmujące się kwestiami związanymi ze sposobem przesyłania komunikatów, opracowujące modele danych oraz słowniki pojęć i kodów. Niektóre komitety zajmują się konkretnymi technologiami, przykładowo istnieją komitety zajmujące się składnią Arden, językiem XML, a także tworzeniem API dla języka Java. Ponadto w organizacji pracują osoby odpowiedzialne za promocję standardu, szkolenia oraz opracowywanie podręczników, a także zajmujące się współpracą z oddziałami HL7 w innych krajach[1].

HL7 współpracuje także z innymi organizacjami. Należą do nich m.in.[2]:

  • DICOM (Digital Imaging and Communications in Medicine – Obrazowanie Cyfrowe i Wymiana Obrazów w Medycynie)
  • ASC X12 (The Accredited Standards Committee X12)
  • ASTM (American Society for Testing and Materials) – Amerykańskie Stowarzyszenie Badań I Materiałów
  • MEDIX (IEEE P1157)

Standard HL7 – informacje ogólne[edytuj | edytuj kod]

Głównym celem standardu jest zapewnienie właściwej komunikacji między systemami medycznymi. Przykładami systemów medycznych mogą być systemy informacji radiologicznej (ang. Radiology Information System – RIS), systemy informacji laboratoryjnej (ang. Lab Information System – LIS), systemy informacji szpitalnej (ang. Hospital Information System – HIS). Każdy z tych systemów ma inną specyfikę oraz funkcjonalność. Głównym zadaniem HL7 jest ułatwienie implementacji interfejsów dla tych systemów oraz redukcja kosztu ich wytwarzania, aby w ten sposób wymiana danych między systemami była tańsza oraz mniej skomplikowana. Standard zamierza zrealizować także następujące cele:[2]

  1. Realizacja wymiany danych między systemami opartymi na różnorodnych protokołach
  2. Wspieranie rozwoju specyfikacji jeśli zostaną wyznaczone nowe wymagania
  3. Wykorzystanie istniejących norm powiązanych ze standardem. Nie powinien faworyzować interesów konkretnych przedsiębiorstw
  4. Długoterminowym celem powinno być określenie formatów i protokołów dla programów komputerowych we wszystkich placówkach służby zdrowia

Standard HL7 bywa nazywany „niestandardowym standardem” (ang. nonstandard standard). Sformułowanie to podkreśla elastyczny charakter standardu, który opisuje sposób komunikacji między systemami w sposób ogólnikowy i niezwiązany z konkretną technologią informatyczną, językiem programowania itp. HL7 jest standardem bardzo popularnym w Stanach Zjednoczonych. Jest wykorzystywany w ponad 90 procentach placówek medycznych w tym kraju. Standard ten jest rozwijany także w innych krajach.

Osoby tworzące standard HL7 można podzielić na 3 grupy:

  • Specjalistów od interfejsów medycznych, którzy zajmują się przesyłaniem danych medycznych pomiędzy systemami oraz tworzeniem narzędzi służących wymianie tych danych
  • Rząd oraz inne organizacje polityczne, ich zadaniem jest opracowywanie norm prawnych
  • Informatyków medycznych, którzy zajmują się modelowaniem wiedzy medycznej oraz terminologią medyczną

Początkowo standard nie spotkał się z dużym zainteresowaniem sprzedawców systemów medycznych. Członkowie organizacji HL7 zauważyli jednak, że nie jest konieczne implementowanie standardu w 100%, aby zredukować w sposób znaczny koszt tworzenia interfejsu. Okazało się, że wystarczy zdefiniować jedynie 80% interfejsu systemu zgodnie ze standardem pozostawiając 20% interfejsu na pozostałe funkcje charakterystyczne dla danego systemu[3]. To podejście przyczyniło się do zwiększenia zainteresowania standardem przez firm wytwarzające systemy medyczne.

Wartość standardu jest zależna od tzw. efektu sieciowego (ang. network effect). Polega on na tym, że wartość standardu rośnie znacząco, jeśli więcej stron i sprzedawców go wykorzystuje. Podobny efekt można zauważyć w przypadku innych standardów lub protokołów, np. http, ftp. Są one obecnie bardzo wartościowe, ponieważ są popularne wśród użytkowników.

Standard nie określa szczegółów implementacyjnych systemów medycznych. Dwa systemy oparte i w pełni zgodne z HL7 mogą być niekompatybilne. Rozwiązaniem tego problemu mogą być specjalne silniki interfejsów tworzone przez HL7, które pełnią rolę pośredników między systemami.

Większość standardów HL7 jest traktowana jako standardy otwarte. Od kwietnia 2013 roku są one dostępne dla każdego za darmo[4], wystarczy rejestracja na stronie organizacji (www.hl7.org).

Elementy standardu HL7[edytuj | edytuj kod]

Standard HL7 dzieli się na kilka specyficznych standardów – każdy z nich związany z innym elementem informatycznej obsługi służby zdrowia. Należą do nich m.in.:

  • HL7 MDF (Message Development Framework)
  • HL7 RIM (Reference Information Model)
  • HL7 CDA (Clinical Document Architecture)
  • standardy opisujące wiadomości HL7 (HL7 v2.x oraz HL7 v3)
  • HL7 CCOW (Clinical Context Object Workgroup)
  • Składnia Arden
  • HL7 MIF (Model Interchange Format)

Ponadto standard HL7 wykorzystuje różne systemy kodowań. Należą do nich przykładowo terminologia SNOMED, identyfikatory OID oraz kody LOINC. Są one wykorzystywane także do innych zastosowań, przykładowo OID wykorzystywany jest w sieciach komputerowych.

HL7 MDF – Message Development Framework[edytuj | edytuj kod]

MDF jest kompletną, w pełni udokumentowaną metodologią, która ma na celu rozwój specyfikacji wiadomości. Rozwój wiadomości HL7 jest rozproszonym procesem. Każdy komitet techniczny tworzy część standardu, za którą jest odpowiedzialny. Osoba będąca członkiem Komitetu Modelowania i Metodologii towarzyszy każdemu z komitetów przy tworzeniu ich części standardu i jest odpowiedzialna za harmonizację modelu obejmującego całość standardu.

Model przypadków użycia jest pierwszym krokiem w procesie projektowania wiadomości[5]. Model ten określa okoliczności, w których informacja jest przesyłana między aplikacjami. Ponadto określa aktorów oraz funkcje związane z przesyłanymi wiadomościami.

Model informacji jest jednym z najważniejszych elementów całego procesu. Model ten jest oparty na RIM. Jest to model obejmujący obszary podmiotu, atrybuty dla każdej z klas, strukturę dziedziczenia oraz inne typy połączeń między klasami. Ponadto zawiera także diagram stanu, który przedstawia cykl życia klasy. Każda klasa w modelu posiada swój komitet nadzorczy odpowiedzialny za zmiany w tej klasie. Każdy z komitetów zajmuje się podzbiorem klas pochodzącym ze standardu RIM. Dla tego podzbioru klas, zwanego modelem roboczym, komitet wysuwa propozycje zmiany. Odbywa się to na specjalnych spotkaniach. Zadaniem Komitetu Modelowania i Metodologii jest zebranie propozycji zmian od każdego komitetu i opublikowanie ich. Następnie na spotkaniu organizacyjnym następuje głosowanie za przyjęciem lub odrzuceniem propozycji zmian.

Klasy podmiotu są to klasy, których informacja musi być aktywnie zarządzana przez systemy opieki medycznej. Przykładami takich klas są klasy opisujące pacjenta, badanie lub wynik badania. Dla klas podmiotu utworzony jest cykl życia oparty na diagramie stanu. Przejścia w diagramach stanu są potencjalnymi wyzwalaczami w modelu interakcji.

Model interakcji definiuje zachowanie systemów komunikujących się z wykorzystaniem wiadomości HL7. Model ten jest oparty na wyzwalaczach, interakcjach oraz rolach aplikacji. Wyzwalacze pochodzą z modelu przypadków użycia oraz diagramu stanu z modelu informacji. Interakcje są pojedynczymi, jednokierunkowymi transferami wiadomości, opisanymi za pomocą wyzwalacza oraz dwóch ról aplikacji. Jedna z ról aplikacji wysyła wiadomość, druga ją odbiera. Pozwala na uproszczenie struktury wiadomości oraz zwiększenie jej przejrzystości.

Ostatnim krokiem przeprowadzanym przez komitet techniczny jest stworzenie modelu projektowania wiadomości. Komitet wybiera z RIM te klasy, atrybuty oraz połączenia, które są potrzebne do konkretnego zbioru wiadomości. Elementy te tworzą wspólnie tzw. model informacji wiadomości (ang. MIM – Message Information Model). MIM jest podstawowym modelem wykorzystywanym przy tworzeniu diagramu wiadomości. Diagram ten jest hierarchicznym zbiorem obiektów, które są instancjami klas z MIM. W następnym kroku obiekty w diagramie wiadomości są rozszerzane o atrybuty, które mogą tworzyć pola wiadomości HL7. W wyniku tej operacji powstaje część strukturalna (prawostronna) hierarchicznego deskryptora wiadomości (ang. HMD – Hierarchical Message Descriptor). Ostatni etap procesu definiuje jeden lub więcej formatów wiadomości oraz profili zawartych w lewostronnej części HMD. Formaty i profile są opisane dla poszczególnych interakcji.

Po utworzeniu HMD członkowie organizacji HL7 głosują za jego przyjęciem lub odrzuceniem. Po zaakceptowaniu HMD jest on wykorzystywany w połączeniu z przynajmniej jedną tzw. implementowalną specyfiką wiadomości (ang. IMS – Implementable Message Specification). IMS jest oparty na konkretnym protokole komunikacji. Z tego względu zapewnia algorytm dla HMD służący generowaniu oraz interpretacji struktury wiadomości oparty na określonym protokole komunikacji.

HL7 RIM – Reference Information Model[edytuj | edytuj kod]

HL7 RIM jest modelem statycznym dotyczącym informacji o zdrowiu oraz opiece zdrowotnej, jest częścią procesu rozwoju standardu HL7 v3. Obejmuje m.in. diagramy klas, stanu, przypadków użycia, interakcji. Standard RIM jest standardem zatwierdzonym przez ANSI oraz ISO. Jest on wykorzystywany także przez inne organizacje akredytowane przez ANSI lub ISO takie, jak X12 lub CEN-TC251 (Europejska Standaryzacja Informatyki Medycznej).

RIM w ogólnym podejściu składa się z klas. Każda z tych klas jest przypisana do jednego lub większej liczby pakietów (tzw. obszarów podmiotu). Atrybuty, związki i stany są powiązane z klasami. RIM jest wyrażony w języku UML z dodatkowymi tagami HL7. Wszystkie wartości tych metadanych są unormowane[6].

RIM składa się z sześciu zasadniczych klas:

  • Act (czynność) – reprezentuje akcje, które są wykonywane i które muszą być udokumentowane
  • Participation (udział) – wyraża kontekst dla czynności, tzn. określa kto ją wykonał, gdzie była wykonywana, jakie osoby brały udział w tej czynności
  • Entity (jednostka) – reprezentuje fizyczne przedmioty i obiekty, które są związane z opieką medyczną
  • Role (rola) – ustanawia role, które jednostki pełnią w przypadku ich udziału w czynnościach opieki medycznej
  • ActRelationship (powiązanie czynności) – reprezentuje powiązanie dwóch czynności
  • RoleLink (powiązanie ról) – reprezentuje związki między rolami
Klasy HL7 RIM – Referencyjnego Modelu Informacji

Klasy Czynność, Jednostka oraz Rola są określone przez zbiór specjalizowanych klas i podtypów. Te trzy klasy posiadają ponadto atrybut classCode, który reprezentuje daną klasę, pozwala określić jej rodzaje. Atrybut classCode może przykładowo przyjmować następujące wartości dla poszczególnych klas:

  • klasa Czynność – obserwacja, procedura, nadzorowanie procesu leczenia, wizyta pacjenta
  • klasa Jednostka – osoba, organizacja, materiał, miejsce
  • klasa Rola – pacjent, licencjonowana jednostka, miejsce

Klasy zawierają także inne atrybuty. Jednym z ważniejszych atrybutów jest moodCode. Jest to atrybut czynności opisujący jej charakter.

Wartości moodCode:

  • Definicja – (Definition – DEF) – definicja aktu
  • Zamiar (Intent – INT) – zamiar wykonania czynności
  • Żądanie (Request – RQO) – żądanie zlecenia czynności
  • Obietnica (Promise – PRMS) – zamiar wykonania czynności z dużym stopniem zobowiązania
  • Potwierdzenie (Confirmation – CNF)
  • Zdarzenie (Event – EVN) – czynność, która ma aktualnie miejsce, zdarzenie posiada dodatkowo raport czynności

Atrybut moodCode nie określa stanu czynności. Każda czynność może mieć tylko jedną wartość tego atrybutu. Oznacza to, że te same czynności różniące się jedynie atrybutem moodCode są w rzeczywistości różnymi czynnościami.

HL7 CDA – Clinical Document Architecture[edytuj | edytuj kod]

HL7 CDA[7] jest standardem obejmującym kwestie związane ze składnią i semantyką dokumentów klinicznych. Dokumenty te mogą być złożone z wielu elementów, mogą zawierać tekst, obraz, dźwięk oraz innego typu multimedia. Standard ten jest implementowany w języku XML. Został zatwierdzony przez organizację ANSI.

Dokument CDA jest opisywany za pomocą sześciu cech:

  • Niezmienność (Persistence) – dokument kliniczny nie zmienia swojego stanu przez ustalony czas
  • Zarządzanie (Stewardship) – jest nadzorowany przez konkretną osobę lub organizację
  • Możliwość uwierzytelniania (Potential for authentication)
  • Dokument jako całość (wholeness)
  • Czytelność (human readability)

Dokument CDA składa się z nagłówka oraz ciała. Rozpoczyna się od znacznika <ClinicalDocument>. Nagłówek znajduje się między znacznikami <ClinicalDocument> i <structuredBody>. Jego zadaniem jest identyfikacja oraz klasyfikacja dokumentu. Ciało zawiera raport medyczny podzielony na sekcje, których zawartość może być zakodowana za pomocą standardowych słowników. Informacje zawarte w dokumencie CDA opierają się na referencyjnym modelu informacji (RIM).

Sekcje ciała dokumentu są opakowane znacznikami <section>. Każda z nich może posiadać pojedynczy tzw. blok narracyjny i dowolną liczbę wejść CDA (ang. CDA entries) oraz zewnętrznych referencji. Blok narracyjny jest kluczowym elementem sekcji, jest otoczony znacznikami <text>. Przechowuje informacje, które będą generowane w raporcie. Wejścia CDA zawierają natomiast informacje służące dalszemu przetwarzaniu komputerowemu. Blok narracyjny jest obowiązkowym elementem sekcji, wejścia CDA są opcjonalne. Wejścia CDA mogą być zagnieżdżane i mogą odwoływać się do zewnętrznych obiektów. Obiektami tymi są dane znajdujące się poza dokumentem CDA, mogą do nich należeć zdjęcia, procedury, dokumenty itp.

W celu zapewnienia rozszerzeń o charakterze lokalnym, CDA umożliwia wykorzystanie dodatkowych elementów XML oraz atrybutów niewyspecyfikowanych w standardzie. Umieszczone rozszerzenia nie powinny zmieniać znaczenia dokumentu i powinna istnieć możliwość ich ignorowania przez odbiorców. Typy danych definiują strukturę danych pozyskiwanych z atrybutów klas RIM i mają wpływ na możliwe wartości atrybutów. Niektóre typy danych są typami podstawowymi (np. INTEGER, TIME STAMP). HL7 definiuje także bardziej złożone typy takie, jak GENERAL TIMING SPECIFICATION (GTS) oraz CONCEPT DESCRIPTOR (CD).

Zasadniczym punktem modelu CDA jest ClinicalDocument.class związana ze znacznikiem <ClinicalDocument> dokumentu CDA.

Klasa ClinicalDocument składa się z następujących atrybutów:

  • id – identyfikator dokumentu
  • code – specyfikuje typ dokumentu za pomocą codu LOINC
  • effectiveTime – określa czas powstania dokumentu
  • confidentialityCode – określa status dokumentu
  • languageCode – język dokumentu

Podstawowe elementy dokumentu CDA:

<ClinicalDocument>
  ... CDA Header ...
  <structuredBody>
    <section>
	  <text>narrative block</text>
	  <observation>...</observation>
	  <substanceAdministration>
	    <supply>...</supply>
	  </substanceAdministration>
	  <observation>
	    <externalObservation>...</externalObservation>
	  </observation>
	</section>
	<section>
	  <section>...</section>
	</section>
  </structuredBody>
</ClinicalDocument>

Przykład obserwacji:

<section>
  <code code="8716-3" codeSystem="2.16.840.1.113883.6.1"
   codeSystemName="LOINC"/>
  <title>Pomiar temperatury</title>
  <text>Temperatura wynosi 36.9 C</text>
  <entry>
    <observation classCode="OBS" moodCode="EVN">
	  <code code="386725007" codeSystem="2.16.840.1.113883.6.96"
	   codeSystemName="SNOMED CT" displayName="Body temperature"/>
	  <statusCode code="completed"/>
	  <effectiveTime value="200004071430"/>
	  <value xsi:type="PQ" value="36.9" unit="Cel"/>
	</observation>
  </entry>
</section>

Standard HL7 v2.x oraz HL7 v3[edytuj | edytuj kod]

Standard HL7 występuje w dwóch wersjach: drugiej oraz trzeciej. Standard w wersji drugiej posiada mniej formalny model danych. Było to szczególnie przydatne na początku jego istnienia, ponieważ standard z mniejszą dokumentacją cieszy się większym zainteresowaniem firm wytwarzających systemy medyczne.

Standard w miarę upływu lat był rozwijany. Jego rozwojem zainteresowały się instytucje rządowe i informatycy medyczni, którzy dołączyli do organizacji HL7. Zauważyli oni, że standard HL7 v2 ma pewne braki. Dotyczyły one m.in. tego, że standard nie posiadał spójnego modelu danych, formalnej metodologii, a także zdefiniowanych ról aplikacyjnych oraz ról użytkowników. Problemy te nowi członkowie organizacji zamierzali rozwiązać w kolejnej wersji standardu – wersji trzeciej. Dzięki temu powstała wersja standardu o wyższym poziomie modelowania, złożoności oraz wewnętrznie spójnym.

HL7 v3 jest standardem nastawionym na zastosowania międzynarodowe, uwzględniającym specyficzne normy dotyczące danego kraju lub regionu. Ponadto trzecia wersja standardu posiada spójny model danych bardziej precyzyjny niż HL7 v2. Wersja trzecia nie jest kompatybilna z wersją drugą oraz odwrotnie[8]. Systemy medyczne, które chcą w pełni implementować standard HL7 powinny w związku z tym implementować go w dwóch wersjach.

Kolejną kwestią, która odróżnia obie wersje standardu jest składnia wiadomości. Wiadomości HL7 v2 są łańcuchami znaków ASCII podzielonymi na segmenty. Segmenty składają się z pól, które są oddzielone od siebie separatorem w postaci pionowej kreski „|”. Dodatkowo pola mogą być zbudowane z komponentów rozdzielanych separatorem w postaci daszka „^”. Wiadomości HL7 v3 są natomiast opisane za pomocą języka XML.

Przykładowa wiadomość HL7 v2.X:

MSH^~\&|AcmeHIS|StJohn|ADT|StJohn|20060307110111||ADT^A04|MSGID20060307110111|P|2.4EVN|A04
PID|||12001||Jones^John||19670824|M|||123 West St.^^Denver^CO^80020^USA
PV1||O|OP^PAREG^||||2342^Jones^Bob|||OP|||||||||2|||||||||||||||||||||||||20060307110111|
AL1|1||3123^Penicillin||Produces hives~Rash~Lossof appetite

Przykładowa wiadomość HL7 v3:

<author>
  <assignedEntity>
    <id root="2.16.840.1.113883.9876.210.3"
	  extension="5332443"/>
	<telecom value="tel:+1(317)630-7960"/>
	<assigneePerson>
	  <name>
	    <given>Keiko</given>
		<family>Jones</family>
		<suffix>MD</suffix>
	  </name>
	</assigneePerson>
  </assignedEntity>
</author>
<patientSubject>
  <patient>
    <id root="2.16.840.1.113883.9876.211"
	  extension="344253425"/>
	<addr>...</addr>
	<telecom value="tel:213-555-4344"/>
	<patientPerson>
	  <id root="2.16.840.1.113883.4.1"
	    extension="333224444"/>
	  <name>
	    <given>George</given>
		<given>Simon</given>
		<family>Wigny</family>
	  </name>
	  <administrativeGenderCode code="M"
	    codeSystem="2.16.840.1.113883.5.1"/>
	  <birthTime value="19740423"/>
	</patientPerson>
  </patient>
</patientSubject>

CCOW – Clinical Context Object Workgroup[edytuj | edytuj kod]

CCOW jest standardem służącym do synchronizacji odrębnych aplikacji w czasie rzeczywistym. Wykorzystuje technikę o nazwie „zarządzanie kontekstem” (ang. context management)[9]. Dzięki tej technice informacje dotyczące określonego pacjenta lub obiektu, które pochodzą z rożnych aplikacji medycznych, mogą być ze sobą łączone. Standard CCOW zapewnia mechanizm współdzielenia informacji, dzięki czemu funkcjonują one jako jeden system. Współdzielona informacja jest nazywana kontekstem. Przykładem informacji przechowywanej jako kontekst może być imię, nazwisko oraz identyfikatory pacjenta. CCOW specyfikuje tzw. managera kontekstu, który jest odpowiedzialny za kontrolę kontekstu. Aplikacje są uczestnikami kontekstu. W organizacji HL7 istnieje specjalny komitet techniczny zajmujący się rozwojem tego standardu.

Składnia Arden[edytuj | edytuj kod]

Składnia Arden jest językiem zatwierdzonym przez ANSI służącym do kodowania wiedzy medycznej oraz współdzielenia tej wiedzy między personel, systemy informatyczne oraz instytucje. Język ten wspomaga lekarzy w podejmowaniu decyzji w oparciu o dane zawarte w tzw. MLM (ang. Medical Logic Module). Każdy moduł MLM jest związany z pojedynczą decyzją, dotyczącą na przykład jednego z pacjentów.

MIF – Model Interchange Format[edytuj | edytuj kod]

MIF[10] jest zbiorem formatów XML, które wspierają przechowywanie oraz wymianę danych opartą na standardzie HL7 v3. Dokumentacja MIF obejmuje następujące struktury związane z:

  • wymaganiami oraz analizą
  • modelem statycznym – statyczne modele pochodzące z RIM
  • modelem dynamicznym – wyzwalacze, interakcje oraz role aplikacji
  • infrastrukturą – typy danych i słownictwo
  • testowaniem – przypadki testowe
  • zgodnością – profile zgodności
  • publikacjami – m.in. reprezentacje przewodników implementacyjnych

Głównym zadaniem jest ułatwienie integracji standardu z różnego typu narzędziami służącymi na przykład do projektowania systemów. MIF może być konwertowany do innych formatów, m.in. do UML lub XMI.

SNOMED CT – Systematized Nomenclature Of Medicine Clinical Terms[edytuj | edytuj kod]

SNOMED CT jest terminologią medyczną, która zawiera szeroki zakres słownictwa medycznego na różnym poziomie szczegółowości. Jest jedną z zewnętrznych terminologii, która może być użyta w komunikacji zgodnej ze standardem HL7 w wersji 3. W skład tej terminologii wchodzą różnego typu kody, wyrażenia, synonimy dotyczące chorób, procedur medycznych, mikroorganizmów, substancji itp. Wyrażenia SNOMED mogą być mapowane na inne kodowania, np. na LOINC lub ICD-10.

Struktura SNOMED jest oparta o pojęcia, które są jednostkami biorącymi udział w szeroko rozumianym procesie opieki medycznej. SNOMED posiada ponad 311000 pojęć, każde z nich zawiera unikalny identyfikator. Pojęcia są ze sobą powiązane za pomocą acyklicznych powiązań typu „jest” (ang. „is-a”). Każde pojęcie może być opisane za pomocą różnego typu wyrażeń, np. za pomocą synonimów.

Przykład wyrażenia SNOMED: Headache is-a ache: finding-site = head structure

OID – Object IDentifier[edytuj | edytuj kod]

OID jest globalnym unikalnym identyfikatorem ISO. HL7 wykorzystuje sposób zapisu OID w postaci cyfr oraz kropek. Identyfikatory OID tworzą ścieżki w strukturze drzewa. Skrajnie lewa liczba w kodzie oznacza korzeń drzewa, natomiast skrajnie prawa liczba oznacza liść.

LOINC – Logical Observation Identifiers Names and Codes[edytuj | edytuj kod]

LOINC jest bazą danych, która udostępnia uniwersalny system kodowania dla raportowania obserwacji medycznych. Dla każdej obserwacji, baza danych zawiera kod, długą nazwę formalną, krótką 30-znakową nazwę oraz synonimy. LOINC składa się z ponad 30000 różnych obserwacji.

Przykładowy kod LOINC dla wapnia (o nazwie Calcium 24H Ur-sRate): 14637-3.

Organizacja HL7 w poszczególnych krajach[edytuj | edytuj kod]

Australia[edytuj | edytuj kod]

Filia organizacji HL7 w Australii została utworzona w 1998. Standard HL7 był wprowadzony w tym kraju przy współpracy z narodową organizacją ustalającą normy o nazwie Standards Australia. Ponadto oddział HL7 w Australii współpracuje z NEHTA (ang. National E-Health Transition Authority)[11][12].

Kanada[edytuj | edytuj kod]

Oddziałem HL7 w Kanadzie jest organizacja o nazwie Canadian Health Infoway. Organizacja ta bierze udział w procesie rozwoju HL7. Ponadto realizuje przedsięwzięcia mające na celu wypromowanie standardu. Organizuje szkolenia, informuje i wspiera potencjalne osoby zainteresowane korzystaniem ze standardu. Przeprowadza także testy pozwalające uzyskać certyfikat organizacji HL7.[13]

Finlandia[edytuj | edytuj kod]

W Finlandii działa system medyczny o nazwie KanTa z bazą danych opartą na HL7 CDA oraz wiadomościach HL7 v3. Od lutego 2013 system przechowuje informacje dotyczące wszystkich leków oraz recept realizowanych w Finlandii. System umożliwia lekarzom wprowadzanie recept do systemu. Recepty te mogą być realizowane następnie przez pacjentów w aptekach. Pacjent po zalogowaniu się do systemu może odczytać listę przepisanych lekarstw, kto i kiedy je przepisał, które z leków zostały wykupione, kiedy miało to miejsce oraz ile one kosztowały. W bazie danych systemu KanTa umieszczone są także informacje na temat dawkowania leków. KanTa ostrzega również lekarzy i pacjentów w przypadku, gdy pacjentowi zostały przepisane wykluczające się leki[14][15].

Niemcy[edytuj | edytuj kod]

Oddział HL7 w Niemczech został założony w 1993 roku. Działania HL7 w Niemczech polegają głównie na udzielaniu potrzebnych informacji osobom zainteresowanym standardem oraz na współpracy z organizacjami odpowiedzialnymi za standardy w kraju[16].

Indie[edytuj | edytuj kod]

Filia HL7 w Indiach prowadzi kursy e-learningowe dotyczące standardu oraz przeprowadza egzaminy pozwalające otrzymać certyfikat HL7.[17]

Włochy[edytuj | edytuj kod]

Filia HL7 we Włoszech została założona w 2003 roku. Głównym celem oddziału HL7 we Włoszech jest ukierunkowanie działań regionalnych i narodowych w stronę rozwoju standardu oraz poprawy systemów medycznych w kraju. Do członków włoskiego HL7 należą m.in. niektóre agencje rządowe, instytucje badawcze, lokalne oddziały szpitali oraz indywidualne osoby specjalizujące się w informatyce medycznej[18].

Holandia[edytuj | edytuj kod]

W Holandii do wymiany danych między systemami medycznymi jest wykorzystywana infrastruktura o nazwie AORTA. Do przesyłania danych AORTA wykorzystuje wiadomości HL7 w wersji trzeciej. Holenderski Minister Zdrowia zamierza wprowadzić narodowe elektroniczne rekordy pacjentów, które byłyby udostępniane między systemami medycznymi. To przedsięwzięcie jest realizowane przy współpracy z organizacją Nictiz (ang. National Information and Communication Technology Institute for Healthcare). W przedsięwzięciu biorą także udział członkowie HL7 w Holandii oraz wykorzystywany jest standard HL7 v3.[19][20][21]

Pakistan[edytuj | edytuj kod]

HLH (ang. Health Life Horizon) jest narodowym projektem przeprowadzanym przez Szkołę Inżynierii Elektrycznej i Informatyki Narodowego Uniwersytetu Nauki i Technologii przy wsparciu Rządu Pakistanu oraz finansowanym przez Narodową Fundację Badań i Rozwoju Technologii Informacyjnej.

Głównym zadaniem projektu jest zrealizowanie wymiany informacji w opiece medycznej za pomocą standardu HL7 v3. Członkowie zespołu projektowego HLH biorą udział w międzynarodowych spotkaniach grupy roboczej HL7 oraz konferencjach[22][23][24].

USA[edytuj | edytuj kod]

Komisja Certyfikacyjna Technologii Informacyjnej Opieki Medycznej (CCHIT) utworzyła program Laika na licencji open-source. Program ten służy do testowania zgodności aplikacji EHR (ang. Electronic Health Record) ze standardami CCHIT.

Działania HL7 związane z dokumentem dotyczącym ubezpieczeń medycznych o nazwie HIPAA (ang. Health Insurance Portability and Accountability Act) rozpoczęły się w 1996 i polegały na dopisaniu załączników do dokumentu. Początkowo dołączono zbiór sześciu twierdzeń dla procesu NPRM (ang. Notice of Proposed Rule Making). Twierdzenia te są odpowiedzialne za wdrażanie przepisów administracyjnych zapewniających wsparcie i reprezentację HL7 w DSMO (ang. Designated Standards Maintenance Organization). Działanie to miało na celu zachęcić do wykorzystania HL7 w systemach medycznych. Ponadto specjalna grupa interesu działająca na rzecz HL7 publikuje przewodniki opisujące wiadomości HL7.[25]

Przykładowe systemy implementujące HL7[edytuj | edytuj kod]

Oracle Healthcare[edytuj | edytuj kod]

Oracle Healthcare dostarcza technologie oraz wszechstronne aplikacje biznesowe w dziedzinie służby zdrowia, wliczając w to kluczową funkcjonalność zbudowaną specjalnie dla płatników opieki medycznej, dostawców oraz agencji rządowych związanych z opieką medyczną. System Oracle Healthcare oferuje zunifikowany model danych, istnieje więc możliwość zarządzania dużymi wolumenami informacji o pacjentach oraz ubezpieczeniach, sprawowania kontroli nad przestrzeganiem przepisów oraz zarządzania materiałami.

Adapter systemu Oracle Healthcare pozwala dodawać komponenty służące do integracji kompozytów aplikacji SOA w celu stworzenia procesów takich, jak wysyłanie informacji o przyjmowaniu pacjentów wygenerowanych przez aplikację służącą do rejestracji. Adapter ustanawia typy dokumentów przesyłane między kompozytami aplikacji SOA oraz zewnętrznymi aplikacjami medycznymi. Przesyłane dokumenty mogą być oparte standardzie HL7[26].

System Oracle Healthcare jest wykorzystywany między innymi w Australii.

System Eskulap[edytuj | edytuj kod]

Eskulap jest systemem informatycznym przeznaczonym dla sektora opieki zdrowotnej. Jest skierowany do różnego rodzaju szpitali, przychodni, aptek oraz innych placówek medycznych. Został wdrożony w wielu placówkach na terenie całej Polski. Jednym z modułów systemu Eskulap jest moduł HL7. Jest to specjalna bramka komunikacyjna służąca do wymiany informacji między zewnętrznymi systemami medycznymi[27].

InfoMedica[edytuj | edytuj kod]

InfoMedica jest pakietem oprogramowania, który pozwala na ewidencję świadczeń zdrowotnych w placówkach medycznych. Przechowuje informacje o pacjentach, wykorzystywanych lekach oraz materiałach, a także badaniach, zabiegach, konsultacjach i procedurach medycznych. Służy ponadto do zarządzania kwestiami finansowymi, kadrowymi oraz płacowymi.

Standard HL7 jest wykorzystywany przy przesyłaniu danych między systemami składającymi się na pakiet InfoMedica[28][29].

Centrum[edytuj | edytuj kod]

Centrum to system obsługi labolatorium (medycznego, analitycznego, weterynaryjnego) pracujący w większości laboratoriów szpitalnych i sieci laboratoryjnych w Polsce. Standard HL7 jest wykorzystywany do przesyłania informacji (zlecenia, wyniki badań itd ) pomiędzy systemami szpitalnymi i laboratoryjnymi, a także do wymiany danych pomiędzy laboratoriami.

Zobacz też[edytuj | edytuj kod]

Przypisy

  1. Polska wersja narodowa standardu HL7 (pol.). UHC Medical Informatics CompuGROUP Holding.
  2. 2,0 2,1 HL7 V3 Standard: Backbone, Draft 1.0.
  3. HL7 101: A Beginner’s Guide.
  4. HL7’s Standards Licensed At No Cost.
  5. HL7 Version 3 – An object-oriented methodology for collaborative standards development.
  6. Reference Information Model (RIM) Downloads – HL7 RIM version 2.07.
  7. HL7 Clinical Document Architecture, Release 2.
  8. The HL7 Evolution. Comparing HL7 Version 2 to Version 3, including a History of Version 2.
  9. CCOW Information for the healthcare industry.
  10. The HL7 MIF – Model Interchange Format.
  11. Standards Australia eHealth. Standards Australia.
  12. National E-Health Transition Authority. National E-Health Transition Authority.
  13. HL7 Canada.
  14. KanTa website.
  15. HL7 Finland -esite. HL7 Finland ry.
  16. DIN NAMed Jahresbericht 2007. Deutsches Institut für Normung e. V. (DIN).
  17. HL7 Healthcare Standard Institute. HL7 India.
  18. HL7 Italia. HL7 IT.
  19. Onze organisatie HL7. HL7 Nederland.
  20. Nictiz (National Information and Communication Technology Institute for Healthcare). Nictiz.
  21. AORTA, the Dutch national infrastructure. Ringholm.
  22. HLH Team Member Participation in HL7 plenary meeting for signing agreement of HL7 Pakistan with HL7 International at Cambridge, US. National University of Sciences and Technology.
  23. Health Life Horizon. National University of Sciences and Technology.
  24. HL7 Pakistan. HL7 Pakistan.
  25. Health Insurance Reform: Announcement of Designated Standard Maintenance Organizations. Department of Health and Human Services, Health Care Financing Administration, 2000-08-17.
  26. Oracle Healthcare.
  27. System Eskulap.
  28. Pakiet InfoMedica.
  29. Komunikaty HL7 w InfoMedica.

Linki zewnętrzne[edytuj | edytuj kod]