Рекомендации по интерфейсу интерфейса HL7

Я занимаюсь консалтинговой работой для небольшого поставщика аптечных услуг, которому нужна установка движка интерфейса HL7 для обеспечения взаимодействия с продуктами, которые работают в стеке LAMP.

Более конкретно, что я ищу, это движок HL7, который работает на * NIX и может вставлять данные из сообщения HL7 v2.X в базу данных MySQL. Вставляемые данные будут взяты из произвольных полей, поэтому необходимо провести синтаксический анализ.

Я пробовал использовать Mirth, но его способность сделать любую кажущуюся просто сложную задачу чрезмерно сложной и чрезмерную медлительность ее клиентского интерфейса/времени отклика заставила нас задуматься. Когда я заявляю простую задачу, я имею в виду как отправить обратно пользовательское сообщение ACK, основанное на нескольких правилах, заставляет меня писать 100 строк javascript и после этого все еще получать ужасные отклики.

Я любил Игуану и хотел ее использовать, но они процитировали нас от $12 тыс. до $15 тыс. за один экземпляр на одном сервере. Это был хороший кусок программного обеспечения, но не так хорошо оправдывать такой ценник, как и тот, который намного превосходит то, что мой клиент готов заплатить за единую программу, которая управляет небольшой частью своего бизнеса.

Есть ли у кого-нибудь рекомендации по программному обеспечению с открытым исходным кодом и/или запатентованным программным обеспечением, которое будет отвечать этим требованиям?

Ответ 1

Лучшие варианты с открытым исходным кодом, которые мы используем в нашем бизнесе, - Mirth и OpenESB. Какую версию Mirth вы использовали? Я думаю, вы будете удивлены улучшениями в версии 2.0.

Другой вариант с разумным ценовым тегом - Orion Rhapsody. Мы считаем, что это самый простой в использовании по самой низкой цене для лицензированных двигателей. Это очень подходит для организаций здравоохранения по бюджету. Если вам нужен контакт для настройки демонстрации, я могу помочь с этим.

Ответ 2

Если вам нужно написать более 100 строк Javascript для отправки пользовательского ACK, я бы предположил, что вы делаете это неправильно. Фактическая отправка ack - это одна строка кода, использующая функцию responseMap.put. Возможно, опубликуйте резюме того, что вы пытаетесь сделать, и ваш существующий код на форуме поддержки Mirth; есть много людей, включая меня, которые могут взглянуть на него.

Всегда разочаровывает услышать плохую обратную связь на Mirth, поскольку большую часть времени это не недостаток в продукте, а в программировании. Как я уже сказал, очень рад помочь - просто опубликуйте в нужном месте.

Ответ 3

К сожалению, взаимодействие системы здравоохранения не всегда тривиально и дешево. Я не знаю, какие продукты удовлетворяют вашим требованиям с точки зрения ценообразования и набора функций. Если вы найдете что-нибудь, дайте мне знать...:)

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

Ответ 4

Я думаю, что Mirth по-прежнему ваш лучший вариант, потому что openESB слишком сложно и сложно поддерживать для "малого поставщика аптечных услуг". Если вы используете LLP, вам не нужно настраивать решение.