Системы связи *

Внимание! Данная статья устарела. Вы можете ознакомиться с более свежими статьями здесь или почитать блог на нашем сайте.

В последнее время мы были заняты работой над большим обновлением VoxImplant, которое должно сделать платформу еще более гибкой и удобной для разработчиков коммуникационных сервисов. Количество новых функций достаточно большое, поэтому будем рассказывать о них по-порядку и начнем с месседжинга и презенса. Так как банальное описание функционала мало кому интересно, то сразу разберем пример создания приложения для внутрикорпоративных коммуникаций с использованием популярного ReactJS и Flux. Это позволяет достаточно оперативно сделать более-менее сложное приложение, ну и заодно показать как использовать VoxImplant при таком подходе. Presence у нас тоже с некоторыми интересными особенностями, про которые мы расскажем более детально и объясним потом зачем это может быть нужно.

Сегодня мы немного отступим от традиционного продолжения истории о том Как мы «женили» облачную АТС, GSM и риэлтеров и просто поделимся новостями сервиса, которые случились за последние три недели. История с риэлторами развивается и вскоре мы расскажем еще о целом наборе «вкусностей», которые реализовали на базе нашего AltegroCloud, тем более что после публикаций на Хабре число запросов на подключение резко возросло, а каждое такое подключение — это целая полудетективная история со счастливым финалом (запись разговоров, контроль кадров, геолокация и много чего еще).

Напомним схему работы нашего клауда:



Специальные сим-карты, выпущенные в рамках партнерства с одним их GSM-операторов, хитрым образом «задружены» по SIP-протоколу с облачной АТС и теперь симка работает как обычный офисный телефон и фактически (и технически) является внутренним экстеншеном офисной АТС — мы можем записывать все разговоры с сим-карт, видеть статистику онлайн, управлять симками в личном кабинете да еще и наблюдать их местоположение на карте. Проект заточен для использования риэлторскими агентствами, курьерскими службами, компаниями с большими количеством мобильных сотрудников, которых нужно тщательно контролировать.

Теперь, собственно, новости из песочницы

Ниже приведённая статья — мой вольный перевод сравнительного (достаточно поверхностного) анализа стандартов HL7 и openEHR опубликованной в electronic Journal of Health Informatics 2010 Vol 5 под названием “Putting Health Record Interoperability Standards to Work”. Сама статья, как это принято говорить, любезно предоставлена одним из авторов, правда, ввиду давности публикации, я воздержался от кучи дополнительных вопросов.

Из всей статьи взяты только положительные и отрицательные стороны каждого из стандартов с точки зрения авторов, которые (авторы) являются адептами openEHR и, как бы, должны подвести читателей к мысли, что openEHR имеет явные преимущества по сравнению с HL7.

Очевидно, что сколько людей столько и сравнений (можно глянуть «Какими должны быть стандарты» от Адам Босворт), для меня ниже приведённое больше похоже на сравнение мягкого и зелёного, т.к. HL7 и openEHR преследуют разные цели, их развитие строилось на разных принципах, и, если удалось углядеть какое-то соответствие между ними, то это вовсе не означает, что они равнозначны. Тем не менее, данное сравнение имеет место быть, авторы сами занимаются разработкой стандарта (openEHR), поэтому их мнение должно быть интересным. Мои редкие комментарии в квадратных скобках. Если что-то не совсем понятно, рекомендую обращаться к первоисточнику, возможно ваш перевод будет лучше. Также, статья содержит положительные и отрицательные стороны CDA и CEN EN13606, на мой взгляд эти сравнения не столь существенные, т.к. ссылаются на свои стандарты-предки.

OsmocomBB — это проект, целью которого является свободная (Open Source) имплементация стека протоколов GSM. OsmocomBB предоставляет исходный код прошивок для совместимых телефонов, а также программное обеспечение для их взаимодействия с компьютером. В этом цикле статей я постараюсь описать наиболее интересные возможности, тонкости и ошибки, которые могут возникнуть при работе с данным ПО. Заинтересованных приглашаю под кат!

В этой небольшой статье хотелось бы затронуть некоторые, может быть для кого-то не совсем очевидные, аспекты тестирования интерфейсов медицинских систем. И хотя чаще всего взаимодействие подобных систем строится на основе одного из протоколов Health Level 7 (HL7), это не обязательное условие, могут быть использованы и другие способы коммуникации (как пример, можно назвать ASTM Continuity of Care Records (CCR) до того, как он был адаптирован HL7 под названием CCD).

И так, после того как интерфейс между мед системами реализован, на следующем шаге необходимо провести ряд различных тестов направленных на проверку реализации бизнес-требований (acceptance testing или приёмочные испытания, кстати, статьи в Wiki на русском языке про этот тип тестов нет) и реализацию технологических требований (интеграционное тестирование и юнит-тестирование). Оба типа тестирования невозможны без тестовых данных. Данная статья как раз про один из аспектов создания тестовых данных для тестирования мед систем.

Чтобы проблему было легче понять, посмотрим, как это происходит в общем случае. Команда тестировщиков получает дамп базы из рабочей (production) системы. Эти данные состоят из трёх достаточно условных групп: непосредственно данные для тестирования, справочные данные тестов и справочные данные для приложения. Для проверки корректности работы программы (проверки реализации технологических требований), тестировщик может создать свои собственные фейковые данные, которые перекрывают все три типа.

Сегодня день Великого праздника, который, как мы надеемся, никогда не забудут. Люди, подарившие нам мир, с годами уходят, но мы будем помнить их Подвиг, то, что они сделали для нас…

В этот день нам бы хотелось вспомнить тех, кто обеспечивал связь на протяжении всей Войны. Речь пойдет о войсках связи, о подвиге связистов во время Великой Отечественной Войны.

На это раз статья, которая должна быть многим гораздо ближе, чем просто описание каких-то там EHR-S FM стандартов, так что комменты welcome. Если всё ниже сказанное кому-то покажется из серии «я вообще не понимаю о чём это», предлагаю прочитать несколько моих ранних статей про Health Level 7.

Приступим. Почему-то считается, что если речь идёт о создании медицинской системы, то это обязательно электронная медицинская карта пациента и, может быть, что-то ещё, но совсем немного. Однако, ЭМК пациента не единственная категория медицинских систем.

Можно выделить следующие три:
Electronic Patient Record-centric – сюда входит то, что относится к конкретному пациенту. Приложения не ограничиваются только хранением демографических данных пациента и его истории болезни. В эту же категорию можно отнести телемедицину, медицинские порталы и т.д.
Public Health Information Networks – системы этого уровня абстрагируются от индивида и агрегируют количественные данные со множества систем ориентированных на пациента для прогноза развитие событий таких как эпидемии, биотероризм и т.п.
Clinical Research Support – в этой группе системы для принятия решений, моделирования лекарств и т.п.

Между категориями нет явной границы, данные перетекают из одной в другую, обрабатываются, дополняются и возвращаются обратно. Не имея опыта в конкретной области или категории зачастую весьма трудно предположить, какие данные могут быть в ней использованы, и в этом случае HL7 Reference Information Model (RIM) предлагает неоценимую помощь предоставляя опыт множества экспертов денно и нощно корпевших над структурой классов и их отношениями.

В связи с этим, когда FHIR ещё даже на горизонте не было, возникла такая тема – если стандарт HL7 такая классная вещь и описывает всё что нужно для обмена мед данными, почему бы не использовать её как структуру базы данных, тогда точно всё что будет принято в сообщении от любой другой системы можно будет как-то сохранить. Бери весь RIM, или RMIM или DMIM относящийся к нужному домену, и используй для проектирования базы данных только нужные для разрабатываемой системы классы.

Ранее в комментариях и в статье я упоминал, что в западном мире принято три обозначения ЭМК – Electronic Health Record (EHR), Electronic Medical Record (EMR) и Personal Health Record (PHR).

Прежде чем гадать на кофейной гуще, в чём похожи или отличны эти три термина, нужно определиться, что же такое эта самая Электронная Медицинская Карта. Начнём с того, что существует два измерения медицинских данных – какая информация хранится (или полнота информации) и кто хранитель (custodian) этой информации.

Для первого измерения, полнота информации, возможны следующие два случая:
• Система, хранящая все возможные записи о состоянии больного, по всем направлениям медицины, в течение всей жизни пациента.
• Системы хранящая строго определённые записи о состоянии больного, по конкретной области медицины, в течение всей жизни пациента.

Второе измерение, хранитель информации, для которого характерны следующие варианты:
• Организация, представляющая медицинские услуги.
• Пациент как частное лицо.

Данная короткая статья мой вольный перевод поста на блоге Rene Spronk на тему “Analysis of CDA R2 testing tools — most requirements are neither tested nor respected” [1], которая сама по себе основана на презентации сделанной во время конференции IHIC (International HL7 Interoperability Conference) в Праге в начале 2015 года. [2]

PS. Ссылки на видео и прочие материалы в конце статьи.

Во время конференции была затронута очень интересная и важная тема валидации как документа CDA, так и не очень многочисленных средств разработки CDA. Насколько они соответствуют или не соответствуют стандарту.

Рене выделяет следующие 4-ре шага валидации документа CDA, что также соответствует основным шагам валидации сообщений HL7v3 (где возможно я буду это указывать), причём если документ или сообщение не прошли валидацию на каком-то шаге проверки, то не имеет смысла проводить все последующие шаги.

Кремниевая фотоника — одно из наиболее перспективных направлений в электронике, которое обещает значительное снижение энергопотребления и увеличение пропускной способности. Эта технология позволяет создавать электронно-оптические микросхемы на одном кристалле кремния, что позволяет отдельным чипам взаимодействовать посредством оптических, а не электрических сигналов. На создание первой работающей гибридной микросхемы у IBM ушло около 12 лет. Повышение производительности систем с такими чипами позволяет создавать намного более мощные суперкомпьютеры, чем те, что работают сейчас.

Так, использование импульсов света вместо электрических импульсов позволяет обеспечить быструю передачу очень больших массивов информации как в пределах одного чипа, так и между разными частями электронной вычислительной системы. Ранее корпорации удалось создать фотонный приемопередатчик, который обеспечивал функцию мультиплексирования каналов по длине волны света. Теперь компания смогла разместить чипы, выполненные по технологии кремниевой фотоники, прямо на модуле процессора.

На Хабре уже была заметка о том, как работает PTPv2. Я же собираюсь рассказать о том, как и для чего данный метод высокоточной синхронизации был реализован в наших приборах.

Для чего это надо

Я работаю в российской компании НТЦ-Метротек, которая разрабатывает и выпускает кучу всякой аппаратуры (свичи, тестеры, балансировщики и т.д.) для систем связи, в том числе и тестеры для ethernet-сетей. Например, вот такой. Одним из параметров, измеряемых этим прибором, является задержка прохождения пакета в тестируемой сети. Ха, скажет читатель Хабрахабра — задержку можно и ping'ом померить. Так-то оно и есть, но при разной загруженности сети может быть разная задержка. Наш прибор может измерять задержку с точностью до нескольких наносекунд и при этом создавать нагрузку до 10 Гб/с.

Если вы читали книжки про Health Level 7 (HL7) или проходили курсы, или может учавствовали в конференциях, смотрели презентации и т.д. и т.п., то наверняка обращали внимание, что чаще всего они начинаются с утверждения, что основной целью деятельность организации Health Level 7 является улучшение interoperability или интероперабельности.

Если научиться без запинки произносить эту самую «интероперабельность», то можно выдавать фразы, вроде «Наша компания успешно консолидирует ещё бОльшие аспекты интероперабельности квази и мультидоменных гетерогенных систем и средств кастомизации к условиям конкретного применения» и дуть щёки. Все вокруг будут многозначительно кивать головами — ну как же, интероперабельность, это же совершенно понятно, плавали, знаем.

Попробуем всё так разобраться, что же означает это слово и почему HL7 считает это понятие таким важным. Для начала, заменим его на равноценное по значению, но русское слово. Мне кажется, «совместимость» вполне подходит. Тогда получается, что HL7 озабочена совместимостью медицинских систем. Звучит не так заумно, щёки дуть уже не получится, зато сам термин становится гораздо проще и понятнее.

Среди стандартов Health Level 7 (HL7), не смотря на название организации, есть такие, которые не относятся напрямую к передаче медицинских данных. Стандарт «HL7 EHR-System Functional Model» или «HL7 Функциональная Модель системы ЭМК», вторая версия которого с существенными дополнениями опубликована в апреле 2014 года, относится именно к таким стандартам. Данный стандарт носит нормативный, а не рекомендательный характер, одобрен ANSI в 2007, в 2009 первая версия стандарта, после ревизии ISO и CEN, опубликована как ISO/HL7 10781. Стандарт можно свободно скачать на сайте HL7.org под названием HL7 EHR-System Functional Model, Release 2. В стандарт входит описание стандарта и как им пользоваться, и приложение со списком функций.

Прежде чем кто-то из вас побежит его скачивать, минуточку внимания. Данный стандарт несколько сложен для понимания, поскольку ориентирован точно не на программистов, и даже не на бизнес аналитиков, а уровнем несколько повыше. Следующая картинка условно показывает место этого стандарта среди всех других публикуемых HL7.

В любых системах радиосвязи, что сотовых, что спутниковых, помехи — вечная проблема. Для спутниковых линий все помехи можно разделить на два класса: местные и бортовые.



Местные — это любые радиосигналы в рабочей полосе частот системы связи, попадающие на вход приёмника из местного эфира. Спутниковые системы по сравнению с нашими привычными сотовыми куда чувствительнее. Если вы орёте в ухо человеку на расстоянии 1 метра, шум листьев во дворе вас не волнует. А вот если вы стоите на расстоянии километра и шепчете, то даже при наличии у человека нужного приёмника листья будут мешать. Мощность на входе приёмника порядка минус 110 дБм, или 1х10-14Вт. Всё то же самое, только вместо листьев — наземные радиоточки, трамваи, системы зажигания автомобилей, антирадары.

В данной небольшой статье, ни в коей мере не претендующей на полноту охвата, перечислены некоторые средства разработки для разных версий HL7 и CDA. Критерии, по которым библиотеки, фреймворки или сопутствующие средства попали в этот список следующие: средство должно быть бесплатное или условно бесплатное, поддерживаться организацией или устоявшимся сообществом разработчиков и, желательно, open-source. По этой причине не перечислены всякие хорошие вещи вроде Trifolia или Mirth CDAPI, о которых многие из читателей вряд ли слышали или сталкивались, и вряд ли когда-нибудь столкнутся, если только родная компания вдруг не решит прикупить парочку подобных средства. Так же не попали, например, HL7SDK, множество HL7 редакторов и средства разработки для DICOM.

И так, по порядку с очень кратким описанием.

HL7v2 Software Development Frameworks

• HAPI (Java)

«HAPI (HL7 application programming interface) is an open-source, object-oriented HL7 2.x parser for Java». Данный набор библиотек можно считать стандартом де-факто для разработки HL7v2 приложений на Java. HAPI может быть расширен генерацией своих профилей HL7. Доступен по адресу – hl7api.sourceforge.net

Согласно определению в wiki, Continuity of Care Document или CCD, это стандарт, основанный на XML, и направленный на кодирования структуры и семантики медицинской карты пациента для последующего обмена.

С точки зрения разработчика мед стандартов, CCD это совместное детище комитетов HL7 International и ASTM (American Society for Testing and Materials). С семантической точки зрения, CCD есть руководство разработчика по реализации стандарта ASTM CCR (Continuity of Care Record) на основе CDA R2 (HL7 Version 3 Clinical Document Architecture Release 2). Вот такая вот запутанная история.

Проще говоря, встретились два комитета, которые долго бодались по поводу стандартов, и решили, что все те данные, которые используются в ASTM CCR (также известного как ASTM E2369-05), будут закодированы, с небольшими дополнениями, в стандарте CDA. То, что получилось, было названо Continuity of Care Document.

Стандарт описан в следующих двух документах, доступных на сайте HL7.org:

• HL7v3 Normative Edition — HL7 Clinical Document Architecture, Release 2.0;
• HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD).

В прошлом посте я показывал, как выглядит земная станция спутниковой связи снаружи. Теперь давайте немного посмотрим на теорию, плюс спустимся вниз в аппаратный зал. Кабели ПЧ, которые мы видели в контейнерах, приходят сюда. Ну, или уходят отсюда, у нас же «приём» и «передача».



Всё начинается и заканчивается антенной:



Антенна, кроме, собственно, зеркала и облучающей системы, имеет в своём составе волноводные тракты, МШУ и (по варианту) систему автосопровождения, антиобледенения, осушки волноводного тракта. Осторожно, трафик.

Мы, команда специалистов RingCloud, приветствуем Вас в нашем корпоративном блоге.

Зачем мы здесь? А затем, что мы умеем решать большие и маленькие задачи изящными хитроумными и простыми способами и проводить собственные исследования, касающиеся использования телефонии, а результаты мы оформляем в виде статей. И эти статьи будут появляться здесь. Присоединяйтесь, чтобы следить за нашими решениями. Обещаем: будет интересно. Далее мы хотели бы рассказать, кто мы такие и чем занимаемся.

Несколько задержавшаяся, вопреки обещаниям, четвертая глава постиндустриальной телеком-саги о химической свадьбе облаков, виртуальной АТС, сотовой связи, агентства недвижимости и теперь еще и сервисов геолокации, которые сейчас как раз активно тестируются.

Задача, которую мы решаем на протяжении 3-х предыдущих серий, достаточно проста идеологически, но запутана технически: с помощью облачного виртуального офиса и специальных FMC сим-карт мы хотим управлять работой большого риэлторского агентства, автоматизировать продажи и, помимо этого, еще и контролировать разговоры с мобильных разъездных агентов-риэлторов, которые постоянно норовят отхватить свой кусок пирога и ведут себя некорректно, особенно когда речь заходит о том, что неплохо бы отчитаться о сделках, совершенных за последний месяц. Оно и понятно: при совершении сделки расчет за аренду квартиры зачастую происходит на кухне и практически без свидетелей, проценты за работу риэлтор стремится оставить себе.

Коротко представим главных героев предыдущих серий:

Это очень старая заметка, которая уже не отражает ни текущих реалий, ни взглядов автора. Но тем не менее, почему-то, я решил её не удалять. Прошу не судить строго материал 2015 г. )

Строительство башни было прервано Богом, который создал новые языки для разных людей, из-за чего они перестали понимать друг друга, не могли продолжать строительство города и башни и рассеялись по всей земле.
(С)

Сегодня появилось огромное количество способов обмениваться голосовыми и текстовыми сообщениями: классические телефония и электронная почта, ICQ, Skype, ВКонтакте, Facebook, Viber, WhatsApp, FireFox (да, теперь он ещё и телефон) и т.д. И, похоже, дальше будет больше. Это жутко неудобно: для того, чтобы связываться большим кругом лиц человек должен иметь кучу аккаунов и своевременно их отслеживать. В этой статье я попытаюсь кратко изложить свои соображения, на тему, почему так происходит.