BDT интерфейс f; r Основна документация за тумора

Следва предложение за обмен на данни от основната туморна документация във формат BDT. Предложението съдържа дефиниции за цялата основна документация за тумора. Какво съдържание трябва да се предаде от това на централната оценка (извън съдържанието на вече съществуващия формат за обмен) все още се обсъжда.

историята типа

Интерфейсът BDT се предоставя от Централния институт за задължително здравно осигуряване (ZI), ИТ консултативен център, Ottostr. 1, 50859 Кьолн, стандартизиран и използван за обмен на данни за лечение между практикуващи компютърни системи [1]. ZI издава сертификати за изпитване на производителите на практически системи, които потвърждават, че въпросните системи отговарят на стандарта.

Доколкото е възможно, следващото описание се основава на стандарта, тъй като средносрочната цел е също така обмен на специални данни от основната туморна документация в рамките на трансфера на BDT със системи за практика. Общите обяснения и видовете записи, дефинирани от ZI, не са включени в подробности, защото те се поддържат от ZI.

Предавателната единица в рамките на BDT трансфера се нарича пакет данни. Пакетът данни в рамките на трансфера BDT се състои от записи, които съдържат, от една страна, медицинска информация (в различни видове записи, които са обобщени в следващия преглед като данни за лечение), и от друга страна, структурна информация, напр. за изпращача, дължината и разпределението на пакета на няколко диска и т.н.

Различните записи, съдържащи данни за лечението, са силно ориентирани към случая и са ориентирани към фактуриране (напр. Медицинско лечение, препращане, BG фактуриране).

Всеки запис се състои от няколко полета, които са разделени едно от друго чрез CR/LF. Първите две полета на запис съдържат информация за типа и продължителността на записа; това е последвано от действителното съдържание, обикновено започващо с полето за номер на пациента. Всяко поле започва с 3 байта спецификация на дължината (дължина съдържание + 9), 4 байта идентификатор на поле, n байтове съдържание, 2 байта прекратяване на поле (CR/LF).

Като пример - коментиран - как би изглеждал при отпечатване на изречение, следното показва началото на изречение от типа на изречението "пациент-майстор":

Структурата BDT позволява множество вложени структури от данни (например пациенти-> дни на лечение) да бъдат прехвърлени на до четири йерархични нива, наречени "повторения" (1-во ниво: пациент, 2-ро ниво: ден на лечение) в рамките на запис. Освен това полетата могат да се повтарят в рамките на ниво. Повтарящите се полета могат да служат като „полета за въвеждане“ на ново ниво. В дефиницията на BDT това вижда за данните за обработка на типа запис, напр. като този:

В следващия пример пациентът е посещавал лекаря няколко пъти. Във всеки случай бяха взети няколко мерки.

.
017620025011990
0546210 Бускопан д-р. Раздел XX филм на Баразан. X Urol Drg.
0686220 Бъбречна колика, хематурия болезнено бъбречно легло вляво
0456222 Левкоцитурия, хематурия, повишаване на СУЕ
017620026011990
0626260 Спазмоаналгетично продължаване на лекарствената терапия
0286260 Антибиотична терапия
.

Леченията са проведени на 25 януари 1990 г. и 26 януари 1990 г. (поле 6200 като входна точка към новото ниво). На 26 януари 1990 г. са проведени 2 терапии (поле за повторение 6260).

Както вече споменахме, дефиницията на BDT в момента се основава на изискванията на практическите системи. В допълнение към дефинирането на нови типове записи са необходими корекции на съществуващите структури за туморна документация. Заглавието на носителя на данни от типове записи и практическите данни се използват за идентифициране на изпращащата система или източника на данни. Това означава, че поле 9100 може да съдържа номер, идентифициращ регистъра, а поле 0201 номер, идентифициращо болничното отделение. Дали това е практика или отдел в поле 0201 може да се види от записа в поле 0202. В този случай списъкът на допустимите стойности ще трябва да бъде удължен с 6 = болнично отделение. По-рано недефинираното поле 9220 показва версията на формата за обмен на туморни данни (MM/YY), стига ZI да не е извършила стандартизация.

Представената версия първоначално е до голяма степен ограничена до характеристиките, дефинирани в основната документация за пациенти с тумор (публикувана от Springer-Verlag, август 1994 г.) [2]. Значението на характеристиките и техните характеристики са показани там.

След първоначалния опит с него, интерфейсът трябва да бъде допълнително разширен и прехвърлен към стандартизация от ZI. Това ще направи поддръжката за практикуващи производители на компютри задължителна и данните за туморната документация, записани от лекарите в частната практика, могат в бъдеще да се обменят с регистри без разписки.

За разлика от други формати като напр. HL7 не прави разлика между съобщенията и типовете съобщения. Не се предоставя потвърждение за успешния трансфер или за отхвърлени данни поради грешки. От това следва, че цялата предадена информация се предава с намерението да бъде изцяло поета от получателя. Тъй като при интензивен обмен на данни за пациенти и лечение, голямо количество данни се събират бързо във всяко място за съхранение, важно е да се гарантира, че по време на обмена

  • данните се предават отделно за всеки лекуващ орган и
  • ще бъде предадено само авторството на данните, събрани от лекуващия орган.

Данните, които са присвоени на различни отдели в регистър, съответно се предават като отделни пакети от данни със собствени идентификатори на подателя.

Основните данни за пациента и постоянните находки или състояния и заболявания, описващи или идентифициращи данни за тумори, метастази и вторични и съпътстващи заболявания, заемат специално място. Както при другите видове записи, те се използват за предаване на съответните данни. Тъй като обаче други данни, като исторически данни, имат връзка със споменатите обекти (напр. Туморът), данните на тези обекти също трябва да бъдат прехвърлени, за да се даде възможност за съответна връзка в целевата система, без да е налице авторството. Това не означава, че и те трябва да бъдат внесени. Ако са налице няколко тумора, могат да се предават само данните за тумора, за които се отнасят останалите данни (напр. Диагноза или курс).

По този начин данните се предават в съответствие с диагностиката, хода и събитията, завършени в основната документация. Тъй като данните за терапията обикновено са свързани с данни за напредъка, те не се предават отделно, а се включват в типа запис на напредъка, както и данните за аутопсия, които по същество представляват оценки на напредъка по отношение на съдържанието. Данните или полетата, които не са приложими, са пропуснати и няма да бъдат предадени.

От тази гледна точка планираните мерки са премахнати и са посочени като допълнителен тип запис. Те не оценяват съществуващите състояния, но играят независима роля в хода на лечението на тумори и следователно могат да бъдат предадени отделно от останалите данни. Трябва да се отбележи, че лекарският номер там има различно значение от медицинския номер в практическите данни. Той идентифицира лекаря, при когото трябва да се извърши мярката.

Следователно документите на основната документация ще бъдат съпоставени с предаването на типове записи, както следва (терминът прехвърляне на данни трябва да означава, че се приема, че приемащото приложение приема данните за разлика от термина идентификация, който има за цел само да позволи правилно присвояване):

Интерфейс във формат BDT е разработен и внедрен в GTDS за предаване на данни между клиничните регистри на рака, резидентните лекари, епидемиологичните регистри и за централните оценки. Форматът BDT може да се разглежда като стандарт за практическите компютърни системи в Германия. Почти всяка практическа компютърна система, която се предлага на пазара, има този интерфейс, чието функциониране е сертифицирано от Централния институт на Асоциацията на задължителните здравноосигурителни лекари в Кьолн (ZI). Следователно комуникацията с практически компютърни системи трябва да вземе предвид този интерфейс. Това беше причината да се използва за други задачи по предаване на клиничните регистри за рак. Особено предимство на BDT интерфейса е, че всички характеристики се идентифицират в предавания запис на данни, така че не трябва да се дефинира фиксирана структура на записите на данни. Това дава на интерфейса известна гъвкавост, особено при често променящото се съдържание на клиничните данни.

Целта е да се включат новодефинираните данни за туморната документация в директорията с данни на BDT интерфейса, управлявана от ZI, за да могат тези данни да бъдат предоставени на практика в бъдеще на компютърни системи в бъдеще.

С дефиницията на този BDT интерфейс за клиничните регистри на рака е разработена важна предпоставка за установяване на електронни връзки между регистрите и резидентните лекари в долекуването.

[1] F. Lichtner, J. Sembritzki, BDT описание на записа - описание на интерфейса за независим от системата трансфер на данни за лечение, версия 02/94, Централен институт за задължително здравно осигуряване, Кьолн

[2] J. Dudeck, G. Wagner, E. Grundmann, P. Hermanek, основна документация за пациенти с тумор 4-то издание, Springer Verlag Berlin Heidelberg New York и др. (1994)

Промени във версия 0.1 от 3 юли 1996 г .:

Относно историята на типа записи:

  • Добавяне на полета за навлизане в нови етапи и хистологии
  • Корекции, така че историята на типа на записа да е подходяща и за предаване на резултати от аутопсия (полета за локализация и поле за аутопсия)

Промени на 10/11/96 (засяга историята на типа записи):

  • Добавете следните полета

Промени във версия 0.2 от 29 август 1996 г .:

Промени на 14.05.97

Засяга всички видове записи:

Документирането на тумора все още се извършва до голяма степен на листове с документи. Спецификацията на данните за интерфейса обаче е ориентирана към съдържанието, така че лист може да бъде картографиран в няколко записа. Следователно тези две полета са необходими за възстановяване на тази връзка. По-специално идентификацията на документа дава възможност да се провери от кой документ произхожда информацията, напр. за заявки. В допълнение, идентификацията чрез ясно задание позволява по-лесното обработване на информацията за актуализация.

Относно данните за практиката на типа запис:

  • Тъй като информацията идва и от болници или регистри, данните за практиката се разширяват (регистър от типа практика, отдел). Безплатните категории се използват за пълен трансфер на болнична информация.

По отношение на диагнозата и курса на записа:

  • Добавяне на полето за издание TNM

Относно историята на типа записи:

  • Правилна класификация (възходящ идентификатор на полето) на R класификация и метастази