Есть некоторый опыт в данной области, но постановка вопроса не вполне корректна.

Софт-Траст, кстати - одна из немногих фирм (аффилированная одним из крупных участников информационного обмена "от медицины").

Принципиально знать - какой город?

В силу специфики деятельности ЛПУ (поликлиники, в частности), я бы сказал что жизнеспособность подобного софта определяется в первую очередь интегрированностью его в "единое информационное пространство". А это определяется региональными реалиями (т.е. вопрос скорее в органищационной плоскости). Мне вот неизвестны примеры качественной интеграции с ТФОМС и ПФР, в силу их традиционной информационной "закрытости" для всех остальных участников.

Второй немаловажный факт - адаптируемость ПО к изменчивости нормативных документов (которые в медицине перетряхиваются по два раза в год).

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

Собственно ПО - видимо-невидимо. Софта "общегородского" масштаба не так много (успешно внедренного - еще меньше). "На коленке" сделаных решений достаточно (от досовских программ до вполне прилиных с виду, софттраст в принципе одна из них). Любой разработчик легко объяснит что именно его ПО обеспечивает всестороннюю автоматизацию деятельности, но в отрыве от реалий вашего города это не имеет значения, а со знанием реалий - конкретное по не имеет значения.

Есть некоторая разница между "системой электронного документооборота" и "атоматизацией деятельности" (в виде, скажем, создания АРМ-ов на основе ЭМК).

Лавров СергейПосмотрите вот тут - http://soft.mtometeo.ru/ (есть демоверсия)

Идеальное решение для поликлиник, в том числе платных. Только бухгалтерию вести в ней нельзя.
Неизменно радуюсь, когда встречаю человека, который не только верит в достижимость идеала, но и может на него указать! :)

Лавров СергейВсе относительно. Идеалов не бывает в реальной жизни. Так что будем считать, что я погорячился, используя данное слово.

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

P.S. Вот и помогай после этого людям, тебя же во всех грехах еще обвинят =)
Сергей, простите мне мою иронию! :)

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

Просто я в силу специфики своей деятельности как раз занимаюсь координацией разработки и внедрения подобных систем в ЛПУ (в масштабах города, от имени Комитета по здравоохранению). И вынужден помимо прочего постоянно мониторить рынок на предмет появляения / ухода тех или иных программных решений. И накопившийся опыт диктует несколько философский подход к даннйо проблеме, я об этом говорил выше.

Да, все (нормальные) системы ес-но пишутся при взаимодействии с будущими пользователями (в данном случае врачами, мед. регистраторами, мед. статистиками и пр.). Ес-но не все системы пишутся так и в итоге многие из них являются "мертворожденными" и оторванными от реальности.
Кое-что из написанного действительно представляет собой вполне дружественный пользователю и надежный продукт (например все тот же TrustMed от СофтТраста).
Но (!)
Выживаемость ПО в ЛПУ (из моей жизненной практики) определяется не только этим (я бы даже сказал сосем не этим, к сожалению).

Продукт может быть удобен. Невероятно удобен. И красив. И функционален. И вообще он покрывает все "внутренние" потребности ЛПУ (от регистратуры до глав. врача; от выписаных рецептов до учета швабр в чулане).
Но помимо функциональных задач (уровня учреждения) в бюджетных структурах всегда остро стоят задачи "управленческие" (внешние, по отношению к ЛПУ). Т.е., скажем
1. Комитет заинтересован оперативно мониторить ситуацию по всем поликлиникам по тем или иным вопросам
2. ТФОМС ОМС должен получать информацию по выставленым счетам и "отвечать" на них
3. Уполномоченая структура (какой-нибудь городской центр обработки данных) должен оперативно мониторить информацию о реализации нац. проектов (диспансеризация, вакцинация, льготные лекарства, родовые сертифиакты и проч.).
Список далеко не полный...

И все эти участники имеют право "потребовать" нужное от ЛПУ. Как они это сделают? Вариантов три:
- оговорят форматы передачи данных и сроки и периодичность предоставления информации (достойны уважения, но этот вариант встречается очень редко)
- предложат свое по (в 99% случаев - чудовищное, сделаное студентами - этот вариант наблюдается чаще всего)
- никак, потребуют и все

Так вот, в этом мире (а это объективная реальность для всех мед. учреждений) реально выжевет не то ПО которое удобно врачу, а то, которое сможет эффективно решать все "внешние" задачи.
Вот в этом и загвоздка. Автоматизация поликлиники - это не только (и к сожалению не столько) автоматизация их "внутренней кухни" - это, в первую очередь, искусство подружить систему со "внешним миром". Интегрироваться в единое информационное поле. Если вы не в нем - ваша система испустит дух через 1-3 года с вероятностью близкой к абсолютной (стационары немного в стороне, поликлиники - точно). Вас просто забросают "лоскутными решениями".

А обеспечение интеграции в данной среде - вопрос весьма нетривиальный и отнюдь не технический (он политический, и без административного рычага не решается). Скажем, далеко не всегда можно договориться с ТФОМС об обмене финансовыми или просто персонифицированными данными. Да и "архитектура" информационного обмена у нас по стране сильно разнится от региона к региону.

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