Архитектура на езерото със семантични данни в здравеопазването и извън него

Лекарите искат да използват суперкомпютъра на IBM за диагностициране на здравословни състояния

Езерата с данни вонят. Това е така, защото много от тях се обръщат към блата с данни, а блатата са вонящи. Каква е разликата между езеро с данни и блато с данни?

Езерото от данни е изградено върху рентабилна инфраструктура. По-често в днешно време това е Hadoop, който използва две от най-примамливите си свойства: много място за съхранение за евтини и схема при четене. Това означава, че можете да съхранявате всичките си данни и повече сега и да се тревожите за това по-късно.

И точно това в крайна сметка правят много организации, което води до блато от данни. Блатото с данни е езеро от данни, където данните умират: без описателни метаданни и механизъм за поддържането им, вие получавате голяма купчина данни, която на практика е неизползваема.

Част от това е свързано с Hadoop, тъй като поддръжката за управление на метаданни и данни е една от болезнените му точки. Ситуацията там се подобрява, но все още има няколко проблема.

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

Второто е, че не всички метаданни са създадени еднакви. Когато започнем да говорим за описателни метаданни, необходимостта от семантика бързо става ясно изразена. И така, какво получаваме, когато добавим семантика върху езерата от данни? Семантични езера от данни.

Предизвикателства в здравеопазването, решения за Semantic Data Lake

Montefiore Health System внедри семантично езеро от данни (SDL)и обсъждаме с Franz Inc., доставчика на семантичния елемент, цялостната архитектура и ролята на семантиката.

Разположена в Бронкс, Montefiore Health System обслужва едно от най-етнически и социално-икономически разнообразните популации в САЩ. Комплексът включва, но не се ограничава до Медицински център Монтефиоре, Медицински колеж Алберт Айнщайн и изследователска база.

Като всички здравни организации, Montefiore е изправена пред много предизвикателства, свързани с данните. Както д-р Андрю Д. Расин, системен старши вицепрезидент и главен медицински директор в Монтефиоре, казва:

„Предизвикателството, при което имате стотици хиляди пациенти, оказващи влияние върху институцията във всеки даден момент, е да имате подходящото информация за всеки един от тези пациенти на върха на пръстите на терапевта, който взаимодейства с тях в момента на това взаимодействие."

Montefiore използва своите разнообразни и огромни количества необработени данни за по-задълбочен анализ, за ​​да маркира пациенти, които са изложени на риск, или да помогне на клиницистите да идентифицират оптимални планове за лечение. За да може да изгради такива усъвършенствани аналитични решения, Montefiore разгърна Semantic Data Lake (SDL), използвайки набор от технологии и компоненти.

SDL решението предоставя възможности, които включват:

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

Онтологичен канал за данни

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

Обсъдихме подхода и архитектурата с д-р Янс Асман, главен изпълнителен директор на Franz, Inc. Franz Inc. е продавачът зад AllegroGraph, на RDF база данни с графики който обработва аспекта на описателните метаданни/онтологичен тръбопровод на решението.

Асман обяснява, че SDL поддържа както бързо въвеждане в реално време (напр HL7 потоци) и големи, пакетно ориентирани групови вмъквания от ETL (Extract Transform Load) процеси.

Но въпросът за милиони долари е как се случва семантичната анотация. Всички данни, които влизат в езерото, вече ли са анотирани при поглъщане или е необходима допълнителна анотация? Как се извършва - автоматично, полуавтоматично, ръчно? Има ли инструменти за това?

Aasman казва, че използват визуален ETL инструмент, за да начертаят съпоставяне между данните в потоците EDW или HL7 към здравна онтология, която обхваща всичко, което може да се случи на пациент в болничния живот цикъл:

„Това създава декларативно картографиране, което се чете от Java програма, която автоматично трансформира (най-вече) релационни данни в графично представяне (известно още като тройки). Всеки елемент в графиката е анотиран с таблицата и колоната, от които идва, и ETL датата.

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

„В тази обстановка управлението на речника е изключително важно. Healthcare разполага с повече от 180 речника, таксономии и терминологични системи, като Mesh, Snomed, UMLS, LOINC, RxNorm и т.н."

Интегрирането на данни е една от силните страни на онтологичното моделиране, а Асман казва, че всички тези таксономии са взаимосвързани и свързани с важни концепции от „реалния живот“ като ICD9 и ICD10, кодове на процедури и NDC за лекарства:

„Тази комбинирана и интегрирана терминологична система (онтологията на здравеопазването) е в основата на ETL процеса и е изключително важна за заявки и анализи“, казва той.

SPARQL над Spark

Онтологиите и графичните бази данни звучат страхотно и всичко останало, но има още нещо в SDL решението. Къде и как точно се вписват онтологичното моделиране и AllegroGraph в голямата картина?

Асман обяснява: „Ние изпълняваме разпределен AllegroGraph на клъстер на Cloudera. Можем да четем/пишем от HDFS и можем да стартираме Spark отгоре и да използваме MLlib за нашите анализи. Distributed AllegroGraph, базата данни под SDL архитектурата, предоставя всички функции на Lambda архитектура."

Това е необичаен избор, който означава например, че вместо SQL SPARQL се използва като език за заявки. Защо да го правим? И колко добре се представя в сравнение с по-конвенционалните решения?

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

„Освен това базите данни с графики се представят много по-добре, когато имате много ad hoc заявки или когато вашите данни са абсурдно сложни или ако вашето приложение ще се възползва от разсъжденията“, казва Асман.

Какво ще кажете за сложността на заявката? Aasman казва, че като доставчик те виждат заявки, вариращи от един ред до 1500 реда код, и предоставят типична SPARQL заявка от проекта Montefiore за добра мярка:

„Тази заявка намира първите 100 пациенти, които са най-сходни с един конкретен пациент от набор от 2,7 милиона пациенти. Първата подзаявка намира за конкретен пациент неговия пол и раса и всички icd9 кодове.

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

„След като ги имаме, намираме всички останали пациенти, които имат най-голямо припокриване в кодовете на icd9 (е, супер членовете) с нашия начален пациент. Това е още един пример за компактността на SPARQL.

„Можем също да използваме Spark, за да направим SPARQL заявка срещу разпределен AllegroGraph. Използваме Spark за анализ и след това можем да запазим резултатите от анализите обратно в AllegroGraph като новонаучена информация“, казва той.

SDL поддържа както бързо въвеждане в реално време, така и големи, пакетно ориентирани групови вмъквания от ETL процеси. AllegroGraph е база данни само за добавяне на графики, обяснява Aasman, така че новите данни се добавят към съществуващите индекси:

„Има непрекъснати процеси на фонова оптимизация, които обединяват всички части от данни в едно линейно сортирано индексно пространство, но реалността е че ако данните се предават 24 часа в денонощието, 7 дни в седмицата, индексите никога не са перфектно сортирани, така че машината за заявки трябва да търси както в съществуващите индекси, така и в добавените нови парчета."

Графични браузъри, машини на времето и машинно обучение

Aasman добавя, че Gruff, графичният браузър на AllegroGraph, позволява на потребителите да създават визуално заявка и след това да генерират SPARQL (или Prolog) код на заявка. Franz Inc току-що пусна нова версия на Gruff, добавяйки това, което те наричат ​​"Машина на времето" възможности към него.

Много случаи на използване на графични бази данни включват времеви събития. Събитията се моделират като обекти, които имат начален час, краен час, тип, някои актьори и геопространствено местоположение.

Aasman казва, че новата функция за времеви плъзгач на Gruff v7.0 позволява на потребителите да демонстрират визуално как графиките състоящи се от времеви събития, се конструират с течение на времето, което позволява вашето изследване като машина на времето данни.

Не на последно място, частта за машинно обучение. Това не е нещо, което базите данни с графики обикновено предлагат, така че как работи за AllegroGraph?

Учените по данни всъщност не се интересуват срещу какво правят своите анализи, твърди Асман, стига да могат вземете техните набори от функции от основното хранилище на данни като csv файл или дори по-добре като (panda) данни кадър.

„За да направим живота по-прост за учените по данни, които искат да работят с AllegroGraph, в момента имаме отворен източник R интерфейс и AllegroGraph с отворен код - Python интерфейс, който може да се инсталира директно чрез Анаконда.

„Ние обаче имаме още по-добра точка на интеграция и тя е, че поставяме всички резултати от анализите обратно в AllegroGraph като тройки и след това го правим навигируем чрез Gruff.

„Вижте пример по-долу. Не само съхраняваме всички резултати, но и метаданните за резултатите, като например: кой е направил анализа, кога, какви скриптове са използвани, какви набори от данни са използвани и т.н.“, казва той.

Семантични езера от данни в облака?

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

Franz Inc предоставя готови инструменти като AllegroGraph като част от внедряването заедно с инструменти по поръчка и програмиране за цялостно решение. За Montefiore решението е внедрено на локален клъстер от машини в техния център за данни.

Асман казва, че повечето болници все още не са свикнали да поставят данните си в облака, но със съответствието на HIPAA от Amazon, Azure и Google Cloud бъдещето ще бъде в облака, също и за Монтефиоре. Все още Aasman смята, че местните клъстери са по-добри за момента по 2 причини.

Първото е удобството: „Наистина е удобно да имате локален клъстер за разработка, който можете да разположите директно в подобен производствен клъстер. Можем лесно да преинсталираме ядра, да коригираме проблеми със сигурността и да минимизираме времето за внедряване."

Вторият е цената: „Всички бази данни с графики са по-производителни с високопроизводителни SSD и много RAM – ако данните са много по-големи от паметта. Откриваме, че големите машини с памет със SSD в облака все още са много скъпи."

Асман добавя, че виждат голямо търсене на AllegroGraph в облака, предимно в AWS и в момента проучват AWS за разузнавателната общност на САЩ. Franz Inc предлагаше управлявана услуга в облака, но Aasman вярва, че е изпреварила времето си, тъй като повечето от клиентите им искаха да запазят контрола.

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