А ссылку на видео Бориса Марцинкевича не надо дать?
Он достаточно доступно и гораздо подробнее рассказывает про эти и подобные темы. Например (не в качестве рекламы) — /watch?v=BNDFhnsPWXk
А можно подробнее? А то я на одном известном youtube канале, посвящённом авиации про такое заметил и понеслось. А ведь коммантаторы там вроде в теме должно быть.
У меня были несколько специфические задачи (HL7). То, что есть в NiFi by default совсем ни куда не годиться, поэтому я с самого начала делал своё. Это заняло примерно месяц работы с сорцами. Литературы, кроме собственной документации, практически нет или на уровне первых двух дней изучения.
Вся эта операция сопровождается довольно продолжительными танцами с бубном, которыми мы не будем в рамках этой статьи заниматься.
Я хотел было написать книжку про эти танцы с бубнами (про программирование процессов для NiFi), но вот не знаю, насколько это вообще кому-то интересно.
The rules, which are effective immediately, mean recreational users will face a fine of up to $3,000 CAD if drones weighing more than 250 grams are caught flying:
* Higher than 90 metres.
* Within 75 metres of buildings, vehicles, vessels, animals or people.
* More than 500 metres away from the user.
* At night, in clouds or somewhere you can't see it.
* Within nine kilometres of somewhere aircraft take off or land, or a forest fire.
* Without your name, address and phone number marked on the drone itself.
* Over forest fires, emergency response scenes or controlled airspace.
B.C.'s Wildfire Act was amended last year to include sanctions of up to a year in jail and fines of as much as $100,000 for interfering with wildfire control efforts. Under Transport Canada regulations, the penalties can include up to 18 months in jail and fines as high as $25,000 for unauthorized aircraft found flying within a radius of about nine kilometres of a fire or below an altitude of about a 900 metres.
Когда я рос и у меня была «склонность к технике», я ходил на колхозный авто-двор, там около кузницы (да, тогда ещё были!) валялся полу-разобранный донор-комбайн, я его пытался доразобрать в меру сил и способностей.
С черчением и начерталкой в универе проблем не было вообще. Сопромат я сдал заняв первое место на олимпиаде так же в универе.
На одним фото-стоке долго и упорно пытался загрузить фотки зданий, 99% отлуп по причине «копирайта на архитектуру». Youtube надо подтягиваться — снял видео на улице и всё, получай отлуп, у тебя же копирайтная архитектура на заднем плане. Вот веселуха то начнётся!
Я почему то думал, что там X12 810 Invoice. Смысл забивать invoice в компе, печатать его, чтобы потом обратно отсканировать, когда можно отправить X12 сообщением (тоже 40-летний бред, но всё же).
Применительно к HL7 есть два вида парсинга, условно назовём их flat parsing и structure parsing. Что ты описываешь и что большинство, в том числе автор 300 строкового парсера делают, это flat parsing. HAPI реализует второй вид парсинга — structure parsing – причём ещё и типы данных распарсивает в отдельные структуры. И далее HAPI позволяет работать с этим используя либо собственные методы, либо в виде XML.
Несомненно, flat parsing также будет отлично работать, но ровно до того момента пока не придёт сообщение с двумя и более remittance detail группами, либо пока в группе не появится более одной внутренний группы или сегмента. То, что они прекрасно распарсятся даже не вопрос. Вопрос в том, будут ли они потом также прекрасно обработаны. Потому что flat parsing это скорее CSV. "Прекрасный XML" или JSON подобный результат даёт как раз HAPI, от которого чел упорно отказывается. В результате, в лучшем случае, парсер тупо падает, а в худшем данные теряются, о чём может стать известно через недели или месяцы работы в production. Со всеми неприятными вытекающими последствиями.
Применительно к X12 это как работа с loop группами.
Кстати, есть какой-то стандарт де-факто парсер для парсинга X12 сообщений аналогичный HAPI, акромя коммерческих типа того же BizTalk?
Небольшое пояснение для того большинства, которое вообще не курсе о чём идёт речь.
HL7v2 – стандарт передачи медицинских данных. Появился тогда, когда некоторые из вас ещё либо не родились, либо в первый класс не пошли. Для своего времени он был не лучше и не хуже других подобных форматов – X12, AFTN и прочее.
HAPI – Java библиотека, родилась в недрах канадской University Health Network как пост-док примерно в 2000 году. В дальнейшем поддерживалась и развивалась James Agnew. К слову сказать, я знаком с James. HAPI — это open-source free library. Портов в C# или куда-то ещё официально не существует. Если вы нашли, значит это какая-то самоделка.
James Agnew – не берёт ни каких денег за консультацию по HAPI. В текущий момент они развивают другой продукт – HAPI FHIR – также open-source free library. Коммерческий вариант этого продукта называется SmileCDR.
FHIR – стандарт передачи медицинских данных, впервые был аннонсирован примерно в 2010 году. Есть надежда, что первая нормативная версия появится в начале 2019 г. Т.е. почти 10 лет огромное количество признанных экспертов в своей области обсуждают каким должен быть новый медицинский стандарт. (За это время было отправлено около 13 тыс change request'ов.)
Это всё значит, что если какой-то лох, которому было лень прочитать документацию как по HL7v2, так и HAPI, вдруг решил, что он умнее всех на свете, который без понятия, что есть HL7 interface engine от open-source free до сильно платных коммерческих, вдруг сотворил что-то на 300 строк кода (мне не понятно, откуда 300, я уже сказал, что достаточно двух строк, чтобы перевести в XML и далее ровно столько строк, сколько полей в сообщении), то большие поздравления его организации в будущей поддержки всего этого. Я не вижу ни единого повода для умиления.
Ещё раз обращаю внимание, что если вы ковыряли какой-то энергетический протокол или самопальный API или видели HL7 «из-за спины», то поверьте, HL7v2 сложнее всего этого вместе взятого. Его можно сопоставить разве что с X12 (кстати, HL7 покрывает HIPAA часть X12). Что, однако, не означает, что адекватный, не очень ленивый человек не сможет его осилить, тем более, что в отличии от X12, все спеки по HL7 бесплатны и доступны.
Если есть вопросы конкретно по HL7v2, HL7v3, FHIR, HAPI или HL7 interface engine можете в PM.
Я видел эти «здесь и здесь». Для очень простого процессора это пойдёт, для сложного прихдится копаться в документации, но она, как я уже упомянул, оставляет желать лучшего по некоторым специфическим вопросам.
PS. У меня процессоры для HL7 и FHIR — конвертация из одного формата в другой, валидация, динамические аттрибуты и прочее подобное.
Он достаточно доступно и гораздо подробнее рассказывает про эти и подобные темы. Например (не в качестве рекламы) — /watch?v=BNDFhnsPWXk
Я хотел было написать книжку про эти танцы с бубнами (про программирование процессов для NiFi), но вот не знаю, насколько это вообще кому-то интересно.
С черчением и начерталкой в универе проблем не было вообще. Сопромат я сдал заняв первое место на олимпиаде так же в универе.
Несомненно, flat parsing также будет отлично работать, но ровно до того момента пока не придёт сообщение с двумя и более remittance detail группами, либо пока в группе не появится более одной внутренний группы или сегмента. То, что они прекрасно распарсятся даже не вопрос. Вопрос в том, будут ли они потом также прекрасно обработаны. Потому что flat parsing это скорее CSV. "Прекрасный XML" или JSON подобный результат даёт как раз HAPI, от которого чел упорно отказывается. В результате, в лучшем случае, парсер тупо падает, а в худшем данные теряются, о чём может стать известно через недели или месяцы работы в production. Со всеми неприятными вытекающими последствиями.
Применительно к X12 это как работа с loop группами.
Кстати, есть какой-то стандарт де-факто парсер для парсинга X12 сообщений аналогичный HAPI, акромя коммерческих типа того же BizTalk?
HL7v2 – стандарт передачи медицинских данных. Появился тогда, когда некоторые из вас ещё либо не родились, либо в первый класс не пошли. Для своего времени он был не лучше и не хуже других подобных форматов – X12, AFTN и прочее.
HAPI – Java библиотека, родилась в недрах канадской University Health Network как пост-док примерно в 2000 году. В дальнейшем поддерживалась и развивалась James Agnew. К слову сказать, я знаком с James. HAPI — это open-source free library. Портов в C# или куда-то ещё официально не существует. Если вы нашли, значит это какая-то самоделка.
James Agnew – не берёт ни каких денег за консультацию по HAPI. В текущий момент они развивают другой продукт – HAPI FHIR – также open-source free library. Коммерческий вариант этого продукта называется SmileCDR.
FHIR – стандарт передачи медицинских данных, впервые был аннонсирован примерно в 2010 году. Есть надежда, что первая нормативная версия появится в начале 2019 г. Т.е. почти 10 лет огромное количество признанных экспертов в своей области обсуждают каким должен быть новый медицинский стандарт. (За это время было отправлено около 13 тыс change request'ов.)
Это всё значит, что если какой-то лох, которому было лень прочитать документацию как по HL7v2, так и HAPI, вдруг решил, что он умнее всех на свете, который без понятия, что есть HL7 interface engine от open-source free до сильно платных коммерческих, вдруг сотворил что-то на 300 строк кода (мне не понятно, откуда 300, я уже сказал, что достаточно двух строк, чтобы перевести в XML и далее ровно столько строк, сколько полей в сообщении), то большие поздравления его организации в будущей поддержки всего этого. Я не вижу ни единого повода для умиления.
Ещё раз обращаю внимание, что если вы ковыряли какой-то энергетический протокол или самопальный API или видели HL7 «из-за спины», то поверьте, HL7v2 сложнее всего этого вместе взятого. Его можно сопоставить разве что с X12 (кстати, HL7 покрывает HIPAA часть X12). Что, однако, не означает, что адекватный, не очень ленивый человек не сможет его осилить, тем более, что в отличии от X12, все спеки по HL7 бесплатны и доступны.
Если есть вопросы конкретно по HL7v2, HL7v3, FHIR, HAPI или HL7 interface engine можете в PM.
PS. У меня процессоры для HL7 и FHIR — конвертация из одного формата в другой, валидация, динамические аттрибуты и прочее подобное.