Составление отчетов, аналитических записок, выдача статистических данных для оперативного управления и т.п. — головная боль и кошмар любого заведующего ОМО, который ведет бумажный учет. Попробуйте быстро посчитать, например, сколько инвалидов, страдающих гипертонией, прикреплено к поликлинике или какова средняя длительность больничного листа и процент госпитализации по пневмониям за последние три месяца? Тем более что информация обычно нужна уже "вчера"... Единственный путь избавиться от этого кошмара — перейти от бумажного учета к компьютерному.
Кажется, что это просто... Любая поисковая система на запрос "Автоматизация медицины" выдаст несколько сотен тысяч ссылок — иди по самой понравившейся и пользуйся! Однако, даже при самом поверхностном анализе того, что предлагается на современном рынке автоматизации, на первый план выходят несколько достаточно сложных и трудноразрешимых для малобюджетного медицинского учреждения (а таковых в современной России большинство) проблем.
Первая проблема в том, что большая часть продуктов, представленных на рынке автоматизации (примерно 85%) — авторские разработки на различных СУБД с закрытыми исходными кодами интерфейсов и баз данных. Приобретая подобный продукт, вы оказываетесь намертво привязанными к разработчику. И если, не дай бог, с разработчиком что-нибудь случится или вас перестанет устраивать его сервис, либо цены, продукт смело можно выбрасывать, потому как внести какие-то изменения в продукт самостоятельно вы не сможете. Имеет смысл покупать только продукты с открытым исходным кодом и оговоркой в лицензионном соглашении, что вы имеете право вносить свои изменения в продукт. При этом достаточно большое значение имеет платформа, на которой построено решение, ведь нанять программиста на "1С" проще и дешевле, чем на «Oracle» или «Delphi».
Следующая проблема, с которой вы неизбежно столкнетесь — недостаточность вашей материальной базы для эффективного построения автоматизированного учета. Практически все программы автоматизации, предлагаемые сегодня на рынке, рассчитаны на глобальную автоматизацию, то есть, у вас должны быть компьютеризированы все рабочие места врачей + все параклинические кабинеты + три-пять рабочих мест в регистратуре + с десяток вспомогательных рабочих мест (отделение статистики, администрация и прочее подобное). Итого шестьдесят-восемьдесят компьютеризированных рабочих мест для стандартной территориальной поликлиники (при самом оптимистичном раскладе). А куда податься «бедному крестьянину» с имеющимся на сегодняшний день десятком маломощных и зачастую устаревших компьютеров? Приобрести недостающее «железо»? Прикинем... Шестьдесят комплектов «системный блок + широкоформатный монитор (23') + принтер с дуплексной печатью» (минимальная рабочая конфигурация) обойдутся в два миллиона рублей по самым минимальным прикидкам. Сюда же приплюсуем расходы по организации локальной сети с сервером, который по минимуму потянет всю эту сеть, — это примерно пять-семь миллионов. Всего выходит семь-девять миллионов рублей одномоментно для обычной территориальной поликлиники. Выбить такие деньги из местного департамента здравоохранения? Нереально... Придется обходиться тем, что имеется, и расширять сеть постепенно. При этом список возможных программных решений съёживается практически до нуля.
Очередная проблема, с которой вам придется иметь дело — отсутствие многих вещей, необходимых для повседневной текущей работы практического здравоохранения. При внимательном изучении программ, представленных на рынке, возникает впечатление, что к их написанию привлекался кто угодно: юристы, экономисты, ИТ-специалисты, администраторы, страховщики, но только не практикующие врачи. Простейший пример: по правилам учета заболеваемости «Статистический талон для регистрации заключительных (уточненных) диагнозов» - Ф. 025-2/у на хронические заболевания подается только раз в году, при первой явке пациента с таким диагнозом. Повторная подача талона на уже имеющееся хроническое заболевание является недопустимой. Ни в одной из исследованных программ автоматизации не предусмотрен механизм предотвращения ввода дублирующего статистического талона! Мало того, ни в одной программе не предусмотрено механизмов поиска дублирующихся статистических талонов, что делает статистику учета заболеваемости заведомо недостоверной. Такая же ситуация и в отношении многих других «мелочей», необходимых в текущей работе практикующего врача. Получается весьма нерадостная картинка: либо вам придется пользоваться заведомо недостоверными или не полными сведениями, либо платить достаточно приличные деньги за доработку уже купленной системы учета. Грустно, господа...
Но! Не так грустно, как кажется на первый взгляд. Можно пойти несколькими путями. Например, если у вас есть пять-десять компьютеров, связанных в какую-никакую сеть, и возможность выделить на автоматизацию полмиллиона-миллион рублей, можно обратиться в какую-нибудь фирму, занимающуюся автоматизацией на платформе «1С», и заказать там конфигурацию конкретно под ваши нужды. При этом нужно быть готовым к тому, что написание конфигурации и ее отладка займет порядка шести-восьми месяцев и в дальнейшем придется заниматься еще и внесением поправок в уже написанное. Да, еще учтите, что постановка задач для написания конфигурации — дело далеко не простое. Проблема в том, что вы и программист говорите на разных языках и то, что вам кажется само собой разумеющимся, для программиста далеко не факт. Так что если вы не уточните абсолютно все, вплоть до каждого нажатия любой клавиши, то рискуете получить в итоге совсем не то, что ожидали. А переделывать придется опять же за дополнительные деньги.
Можно пойти тем же путем, которым пошли мы четыре года назад: нанять программиста на «1С» на аутсорсинге (это обойдется совсем недорого), который будет писать конфигурацию в соответствии с поставленными вами задачами. Тогда года через два-три как минимум вы получите что-то, более-менее отвечающее вашим потребностям. Правда вам не раз придется «пройтись по граблям», на которые уже неоднократно наступали другие, но от этого никуда не денешься.
Данный материал был написан почти четыре года назад, но по различным причинам не публиковался. Самое интересное, что с момента написания (за прошедших четыре года) не изменилось ничего! Ситуация только ухудшилась. Только не нужно мне говорить про бурное развитие медицинских информационных систем типа ЕМИАС и ЕГИСЗ. Они страдают ровно теми же недостатками, что и все остальные и заточены больше на маркетинговые вещи и обслуживание пациентов, а не на облегчение и упрощение работы врача. Для практического врача они не то что не облегчают работу, но скорее усложняют и ухудшают условия, в которых приходится работать. Мало того, они внедряются силком, приказами сверху, не глядя на уже имеющиеся в ЛПУ системы учета, зачастую с потерей многолетних данных, уже в них накопленных и препятствуя созданию своих систем, более удобных для работы.
Нужно отметить еще один момент, на который почему-то внимание почти не обращается. Это зарубежные «санкции». Например, любая система, построенная на Оракл (американская фирма) может оказаться в очень интересном положении, если компании «Oracle» придет в голову заявить, что они вынуждены подчиниться «санкциям» и отозвать лицензии у российских компаний. В том, что у «Oracle» имеются закладки, способные обрушить базы, разработанные на их платформе, я абсолютно уверен.
Комментарии
Автору - в наше время от половины до двух третей времени и сил при разработке(полный цикл) системы (если это не 1с и прочий креатифф) уходит на написание грамотного ТЗ. А две трети ТЗ - вообще не относится к программированию: простая формализация и алгоритмизация. Ибо автоматизация хаоса дает лишь автоматизированный хаос.
Итого: проблема чисто методологическая.
Не чисто.
Ну точнее чисто, но на совсем другом уровне.
Написание любого ТЗ не гарантирует получения успешной системы на всём Ее жизненном цикле. Более того ТЗ как правило становится неактуально через пару - тройку недель или месяцев разработки.
Это если под грибами - то тогда да, как отпустит так и выясняется, что надо все менять.
Не знаю при грибы, такого опыта у меня нет - вам виднее.
Я немного о другом - о том, очень мало где реально применяется инженерия требований и системная инженерия.
написать ТЗ и выполнить совсем не проблема - проблема выявить и учесть требования всех заинтересованных лиц, притом что реальные люди их воплощающие в данном конкретном случае практически всегда имеют не требования а некие представления о них, либо не имеют достаточно времени на работу по их формализации. Так же практически всегда путают целевую систему с какой-либо подсистемой.
а в случае ПО почти во всех случаях разрабатывается подсистема или система в операционном окружении, но об этом не принято думать.
Приведите пример системы из вашего опыта, где без грибов у вас Требования заложенные в ТЗ остались неизменными на протяжении проекта и после него.
В универе рассказывали забавный момент... при разработке сайта с заказчика обязательно надо брать ТЗ.. и чем подробнее ТЗ тем лучше... и самым лучшим, самым подробным ТЗ является сам готовый сайт...
К сожалению очень часто проблема не только в программистах, которые разговаривают на птичьем языке и не в менеджерах проекта, которые должны бы все это для программистов переводить и не в технических писателях, а в том, что на объекте внедрения никто не может четко сформулировать, что именно должна делать программа. Т.е. сами исполнители не знают бизнес процессов. На вопрос "с чего начинается родина?" в ответ идет какой-то поток сознания, который другой человек в другой день не может повторить или ещё хуже называет бредом и выдвигает свое видение, как оно все должно работать.
А о таких страшных вещах как UML диаграммы процессов и потоков данных, декомпозиция бизнесс-процессов никто вообще не знает в независимости от должности.
Вообще-то автор намекает, что есть люди, которые могут сформулировать, что именно должна делать программа. Такие, как автор - эксперты в предметной области с ИТ-знаниями и многолетним опытом постановки задач/разработки приложений.
И все эти диаграммы не могут этого заменить. Это я вам как аналитик с 15-летним стажем говорю. Сделать удобный и хороший продукт можно не ранее, чем с третьей попытки, об этом еще Питер Брукс младший писал в своем знаменитом "Мифическом человеко-месяце". А у нас таких возможностей у команд практически не бывает. Ибо либо внутренняя автоматизация - и начальство больше одной попытки не дает, либо это госзаказ, который вообще - лишь бы формально закрыть. Вот тут хорошо обыграно:
За год делал ЭКГ три раза в одном государственном медучереждении (разные поликлиники, но одно юрлицо (если можно так выразится)). В третий раз не выдержал и поинтересовался почему бы не воспользоваться данными из других поликлиник. Выяснилось, что у каждого учреждения своя база и с другими аналогичными учреждениями они не контактируют, даже в рамках одной районной поликлиники.
Кстати аналогичный бардак наблюдался не только в медицине, но и в системе ПФР.
Сейчас внедряют с опозданием ЦАМИ. Там можно смотреть все изображения по вашему id
Вот посмотрите http://electronxray.com/equipment4/centralnyj_arhiv_medicinskih_izobrazh...
Это не объясняет почему в рамках хотя бы ОДНОЙ районной поликлиники (со всеми удаленными подразделениями) за 15 лет (именно столько я наблюдаю мониторы на столах врачей) не создано единой БД.
В одной обмен идет только снимками. Задача была глобальней создать целую сеть , к которой подключены рентгенаппараты ЛПУшек. А этой задаче года 4 только.
Ага... А теперь расскажите, как будет организован обмен снимками для тех ЛПУ, где цифры нет, а есть пленочные аппараты, которые не собираются менять еще лет 15-20? Таких даже по Москве немало. Кто пленку будет оцифровывать? На чем? За какие деньги? Или эта информация тупо будет отбрасываться?
Ну тут все касается только цифровых устройств. А так есть у минздравов паспорт ЛПУ где учреждения описывают все свое оборудование.
Нудаконешно... На поставленные вопросы вы не ответили. Тогда, может быть вы сможете ответить, на какой срок намечена Минздравом установка цифрового рентгеноборудования ну хотя бы в 95% ЛПУ? За какие деньги? Оборудование каких фирм будут устанавливать? По каким ценам? В чей карман потекут деньги от этой «модернизации»?
Вообще-то запуск подобной системы имеет смысл тогда, когда в нее будет ложится вся имеющаяся информация, т.е. цифрой будет оснащено 95% ЛПУ, а остальные смогут ее оцифровывать.
С чего вы это взяли? Наверняка единая БД есть. Но только вот какая беда: создавалась она не для врачей, а для чиновников. Поэтому нужной для врачей информации в ней нет. Или у врачей нет к ней доступа. ЕМИАС вам в пример...
Тут многие писали за врачей.
А вот с точки зрения пациента: дедушка 89 лет, Москва, должен сделать УЗИ сердца. Два года назад сделал в своей поликлинике, из-за плохого результата записался и сделал повторную консультацию в Боткинской (или в другой, не уверен уже). В этом году повтор. Идёт записываться, ему говорят - в ближайшую нельзя, система вам назначит день и место. Назначили, ехать на другой конец больше часа, это же Москва. Повторяю: 89 лет. Приехал, посмотрели в комп, сказали, дедиля, ты ошибся, улица та, но это не к нам, это вона через 500 метров. Дополз, там смотрят в комп - не, идите в третью. В третьей посмотрели и сказали, что первая была таки правильная, но что-то всё равно не так. Дедушка взмолился и его перезаписали на другой срок и в совершенно другую контору - так, ТБМ, назначила система!
Такое внедрение - задача на много-много лет. В Австрии её внедряют по мягкому варианту - то есть так, чтобы не нарушить то, что работает и чтобы с обратной совместимостью. Например, пришедшего без записи при наличии времени примут, а за неприход не убьют, хоть и попеняют (и правильно: в конце концов, это больные, да и не каждая бабушка может в мобилу). Соответственно внедрение цифры идёт мизерными темпами уже более 10 лет, хотя электронную карточку пациента (с чипом, во!) ввели сразу.
Но зато для людей это весьма щадящий переход.
Дополнительно накладывается страсть к защите личной сферы, из-за чего буксует обмен информацией. Пример: результаты анализа в Вене (столица, не хухры-мухры) только пару лет как стали слать заказавшему врачу не по факсу, а по электронной почте. Пациенту - строго в заклееном конверте. Особо продвинутые конторы дают возможность видеть собственный анализ онлайн в личном кабинете под паролем и даже распечатывать в графику.
Обмен историями болезни или, скажем, файлами рентгена, УЗИ или МРТ - забудьте ваще, зато вам обязательно всучат мешки с распечатанными простынями и по отдельной просьбе прожгут сидюк. Если я тащу к врачу себя или семейных, то иной раз волоку целую сумку распечаток заключений, анализов и снимков, я же не знаю, чего ему понадобится.
Так что Россия ещё только в самом начале пути. Ещё прольётся море крови как врачей, так и пациентов.
Согласен систему внедряют где то с 2012 года. Но перемены есть и видимые. Функционал системы растет.И не забывайте про ЗПД.У нас это закон , а как в австрии не знаю.
В Австрии ЗПД не просто закон, а лёгкое помешательство. В частности, запрещены видеофиксаторы в автомобилях и даже на собственном доме, если он не смотрит строго только в свою же сторону. Даже измерение скорости автомобиля идёт только в номер, а автоматические - ещё и в задний. Вся Европа фотографирует спереди и с мордой водилы, а в Австрии низзя. Ну и так далее.
Но хохма не в этом, а в том, что всё это сразу же накрывается при столкновении маленькой Австрии с большим миром. Анонимные сберкнижки и счета пали жертвой нахмуренных бровей дяденек из-за океана и соседней Германии. Запрет на видеофиксаторы годится, чтобы заставить руссо автотуристо его снять, но он падет сразу же, как только с Европы приедут первые беспилотные автомобили, напичканые камерами выше крыши (это буквально). Любой квадрокоптер из магазина игрушек, вообще говоря, вне закона, но их же не запретишь и границу не закроешь. Делают вид, что такой проблемы нет. С хранением данных вообще цирк, ибо они все хранятся где угодно, кроме Австрии и с ними делают кто и что хочет. Ну вот сейчас какая-то общеевропейская движуха намечается. Но что может Европа против гугла, я уже и не говорю о фейсбуке с микрософтом. И это не считая того, что дядя из-за лужи прослушивает вообще всех и вся, причем в отношении высших должностных лиц это после Меркель происходит, по сути, официально.
ДЛя начала надо наладить сортировку больных. По моим ощущениям в поликлиниках процентов 70 больных - пожилые люди, которым с врачом поговорить о болячках хочется. Либо направлять народ возраста 60+ к геронтологам сначала. ТИпичные старческие болячки требуют скорее психолога, нежели специалиста. Кто очереди создает в поликлиниках? И почему с началом дачного сезона много чего проходит?
А работоспособные люди не могут зависать в очередях и ждут,, пока их принесут к доктору.
Что касается проблем компьютеризации, то начинать надо с создания хорошей базы данных, единой для всей страны. У нас в фармации давно все компьютеризировано. И один из главных головняков был - у каждого свой справочник.
Если учесть все выгоды, не так уж велики деньги.. Но мне порой кажется, что врач и компьютер друг друга не любят..
по мне так все очевидно:
1. создание нормальной автоматизированной медицинской системы для поликлиники - задача государственная или министерская.
2. почему не решена? потому что у нас у руля самые продвинутые и передовые руководители. разработка подобной системы не представляет никакой сложности, если исходить даже из моего древнего программистского опыта. предполагаю ,что последние лет 20 все же регресса не было
3. ваши замечания касательно имеющихся претензий к реализациям говорят только то, что уровень имеющегося продукта смехотворно низок. причины? смотрите пункт 2.
4. конечно интереснее клепать перинатальные центры и ввозить компьютерные томографы, чем унифицировать работу поликлиник. но оснащение поликлиник ,к примеру, Москвы - совсем и не дорогая задача. но разве можно за счет Москвы это делать быстро, когда еще не решена задача монетизации перемещения и стояния жоповозок?
наивный чукотский юноша
пысы. мудрые руководители "рисуют" показатели с потолка. И не тратят человеко-часы на запросы неорганизованного стада баранов, имитирующего деятельность.
Ага... Для отчетов наверх. А когда они начинают пользоваться «рисованными» показателями для решения внутренних оперативных вопросов, то достаточно быстро перестают быть руководителями...
Как можно перестать быть тем, чем ты не являешься? Раз ты не знал, что для решения оперативных вопросов тебе нужны данные о средней длине полового члена находящихся на больничном с ОРЗ, то как ты жил без этих данных ранее? Ведь эти цифры нужны были в министерстве "еще вчера"?
ПыСы Ну есть у вас программист 1С. Ну так и автоматизируйте формы загрузки данных из 1С в те системы учета, которые вам навязывают. Хоть в текстовом файле, хоть в каком
Я ведь не просто так привел эти примеры... Думаете департамент интересует сколько инвалидов с гипертонией имеется в районе? Да ни фига, им это абсолютно по барабану. А вот сколько денег выделить на льготные и бесплатные рецепты для инвалидов их очень сильно интересует. И руководителя спрашивают именно об этом, прося прислать заявочку на бесплатные и льготные рецепты. И если руководитель выдаст цифру в 10.000.000 рублей (с потолка), а реализуют только 5.000.000 или потребуется 20.000.000, а не 10, то руководитель получит больших и хороших звездюлей. И поэтому руководитель и озадачит меня требованием посчитать ему инвалидов с конкретными заболеваниями, чтобы не попасть пальцем в потолок и не получить в обратку.
Вы считаете меня настолько идиотом, что подобное решение не пришло мне в голову в первую очередь? Только, видите-ли, беда в том, что техзадание для навязываемой системы составляли идиоты, которые не учли, что туда придется загружать данные. Не предусмотрена такая возможность, от слова совсем. А для того, чтобы сделать интерфейс для загрузки, разработчик дополнительных денежек требует и немалых. А таковых нету - не предусмотрено. И кто же из чиновников сознается, что он идиот и чего-то там в ТЗ не запланировал? Вот и поступает распоряжение - использовать как есть, а накопленные данные - в помойку...
Слава богу, речь идет не о нас, хотя у нас такая ситуация тоже возможна
. Речь идет о территориалах.
Команда из департамента звучит однозначно: «С такого-то числа использовать то-то и то-то.» Никаких других вариантов не предусмотрено. И начальник, если он хочет и дальше им оставаться, вынужден взять под козырек и сказать «Слушаюсь!».
Вообще-то подобные вопросы должны решаться еще на стадии постановки ТЗ. Вы слышали, чтобы из департамента когда-нибудь спрашивали типа: «Ребята, а что вам нужно для
счастьяработы?». Я не слышал, и вы вряд ли услышите. В сети валяются ТЗ на разработку ЕМИАС. Попробуйте найти там что-нибудь про загрузку данных из других систем учета. Хотя логичнее было бы вообще просто предусмотреть протокол обмена и не трогать уже работающие системы. Но такого не имеется даже в мыслях.И вообще, медицинские чиновники уровня департамента и выше - это отдельная песня. 99,9% из них либо не работали в практической медицине, либо были из нее вышвырнуты за неспособность нормально лечить пациентов. Но при этом они кристально уверены, что знают, как надо строить практическую работу. Мнение тех, кто эту самую практическую работ ведет, их абсолютно не интересует.
Я как-то сунул нос в минздравовский стандарт автоматизации медицины, плюс покопался в том, что на рынке автоматизации медицины продают. Авто прав, все выстроено под финансовый учет оказанных услуг в рамках страховой медицины.
Сама по себе в голове всплыла учебная база "Борей" из MS Access для торговых организаций. Пациент как тележка из универсама, а врач как кассир, который пробивает каждое обследование/лечебную манипуляцию как отдельный товар из тележки, и потом общий чек идет в страховую компанию для оплаты.
Оно конечно дело нужное, деньги считать, но собственно медицины там нет.
Поставил закладку. Мысль насчёт 1С не лишена разумности, но как по мне - так лучше бы наладили единый формат обмена данными. От него можно было бы и к формату хранения дотанцевать.
А ещё - единые классификаторы рулят. Только - электронные. Есть же КЛАДР, и банковский классификатор, и различные ведомственные. Как мне представляется, медикам тоже имело бы смысл завести пару-тройку - а там, глядишь, и до унификации более сложных вещей дорастут.
Ишь чего придумали
. Никто этим заниматься не желает ибо тогда пилить неудобно будет...
есть. такой в мире и у нас тоже!
Медиалог этого тоже не умеет?
Прочел с большим интересом, как и предыдущие статьи автора об автоматизации медицины.
Проблемы на которые указывает ТС несомненно существуют, но некоторые вещи автор передёргивает по каким то причинам.
Так уж сложилась судьба что я больше 10 лет уже один из тех разработчиков, которые говорят с врачами на разных языках.
Тезисно...
"Врачи не учавствовали в разработке ПО"
Во первых это не правда. Многие разработчики привлекают консультантов из медицины.
И встречный вопрос много ли врачей учавствовали в разработке стандартов лечения?
Я так понимаю автор в теме и понимает о чем я.
Программист 1с не дешевле других. Ну если только не студент.
Про oracle и прочие рассуждения.
Да импорт да если что-то вдруг, то все печально.
Много ли у нас аналогов? Не просто СУБД а именно аналогов. Способных ворочать терабайты бд и строить срезы типа гиперкубов. Да и все не стоит на месте работа ведётся в этом направлении но на все нужно время.
Та же 1с которую тут так хвалят не так давно слезла с платной СУБД и то по факту уже после того как сообщество уже давно это делало само.
закрытый код - смешно. У закрытого кода тоже есть исходники и заказчик их может получить при желании.
Про то что нет стандартов автор или не в курсе или намерено вводит в заблуждение.
ГуглСпутник вам в помощь.Куча приказов регламентирующих информационный обмен в медицине и структуры данных.
Про насаждение сверху и коррупционную составляющую этого.
А когда каждое ЛПУ пилит свою систему это хорошо? Это не расточительно?
И не имеет коррупционной составляющей?
Возможно сумбурно но попытался донести взгляд с другой стороны.
И понятное дело что большинство систем автоматизации медицины имеют цель облегчить работу врача в последнюю очередь потому как создаются в контрольно-надзорных целях и платит за все Минздрав
Вставлю свои пять копеек, как специалист отчасти связанный с автоматизацией.
Для сбора статистики Правительство должно выпустить требования к структуре таблиц базы данных. СУБД пусть пилят создатели конкретных приложений.
По аналогии с 1С которые в свои обновления фактически формализуют требования НК, ПБУ и прочих нормативных документов.
Если конкретный врач конкретной поликлиники хочет особенного, то пусть делают в СУБД отдельные таблицы и пилить там функционал. И вести двойную запись. Что бы накатка обновлений не превращалась в гемор. От туда же будет собираться статистика. Если чинараям потребуется что-то с изысками, то вносится соответствующее изменение в правила, пишутся изменения в СУБД и через определенный цикл статистика выдается.
Сервера я считаю должно обеспечивать местное управление или как там его. Уверен рано или поздно дойдет до создания государственных датацентров, где смогут хоститься БД соответствующих госучреждений.
Если в конкретном учреждении не хватает рабочих мест (в смысле компов) то документы ведутся по старинке, а в СУБД забивается уже свод под роспись главного, с периодической проверкой.
Насчет беготни медсестер на 4-й этаж за распечаткой. Правительство пишет требования к организации рабочих мест и процедурам, где все должно расписываться до мелочей. Ведь борьбу за производительность они декларируют, вот пусть и стараются.
Вот там и нужно прописать параметры рабочего места, вплоть до разрешения монитора, количества памяти, наличия РАЙД (зеркала для АРМ), параметров принтера, вплоть до количества лотков подачи и выдачи. Пусть берут не обломятся лишний месяц без джипа на премию - прогресс стоит денег. Бумагооброт до минимума - лес наше достояние.
Контроль аккаунтов делать на уровне Москвы с приложением всех документов по трудоустройству, дабы не возникало соблазна ЗП на мертвых душ получать. Тогда и подпись электронная не сильно и нужна. Верификация документов выданных пациенту через штрих и QR коды.
Уважаемые господа.
Никто и никогда из заказчиков внятного ТЗ на автоматизацию чего-либо не напишет. Потому отродясь ТЗ писали разработчики. Заказчики только утверждали. Так что те, кто плачет, что ТЗ плохие - это не заказчики плохие, это вы плохие. Вы сами не смогли составить хорошее ТЗ. У кого заказчики постоянно меняют требования - тоже самое: не заказчики плохие - вы сами плохие разработчики.
Главный закон для разработчика - ТЗ. Именно по ТЗ идет процесс разработки. Как именно идет - это проблемы разработчиков. Но результат заказчик будет принимать по ТЗ. Если заказчик делает шаг влево, шаг вправо - можно заказчика тянуть в арбитраж. И судья не будет слушать блеянье "а нам бы еще хотелось...": он сравнит то, что написано в ТЗ и заключение на текущее состояние дел. Написано в ТЗ "калькулятор должен уметь суммировать 2 и 2" - есть? Есть. Еще требования есть? Нет. Все, работа выполнена, бабки на бочку. А то, что вам там еще и другие числа суммировать хочется - это вы новый проект открывайте. С новым ТЗ и за новые деньги.
Самое "лучшее" ТЗ, которое лично я получил, состояло из фразы "Модернизировать установку У1 современной электроникой и она должна работать как установка У2". /вместо У1 и У2 стояли реальные индексы/. В процессе общения с заказчиком выяснилось, что установка У1 разграблена, схем на нее нет, но она похожа на У2 /почти такая, но немножечко отличается/, еще похожих установок с пяток, все они управляются электроникой, которой уже давным-давно нет. И в общем-то им бы хотелось все это заменить на современное. Но начинать надо с восстановления разграбленной. Наше ТЗ получилось в палец толщиной и в нем были рассмотрены все варианты.
Года три-четыре назад немцы плакались в жилетку: они установку не могли сдать нашим. При этом почти такую же мы сдали со свистом. Дело, как вы понимаете, было в ТЗ: у немцев в требованиях было написано "установка должна выполнять испытания по ГОСТ ХХХХ", у нас же кроме этой строчки еще был выкопирован весь процесс и скрупулезно расписан что есть что. Т.е. в ГОСТ написано "недопустимая вибрация", у нас помимо "недопустимая вибрация" еще и параметры, при достижении которых мы можем говорить о недопустимой вибрации. Я тогда месяц каждый рабочий день часа по четыре выедал технологам мозги, пока попытка расписать по формулам весь процесс контроля кривой не закончилась успешно, без вопросов. И когда в процессе сдачи начали появляться непонятные люди и говорить "это еще не вибрация" и "это уже слишком много", мы тыкали пальцем в ТЗ и говорили примерно так "мы сделали по требованиям ТЗ, если вы с ним не согласны - излагайте на бумаге со своей подписью и передавайте через начальника в рабочем порядке". Ни одного желающего не нашлось письменно изложить свои претензии. Наоборот, все хвалили нашу разработку - к ней не было замечаний. Немцы же переписывали и переписывали... И так сдать свою установку и не смогли.
Vasia91, ваши сообщения удалены, сами получаете бан на неделю за нарушение «Правил ведения дискуссии в данном блоге (техническое)» (офтоп, пункт 1). Предупреждение выносилось.
З.Ы. судя по вашим репликам вы как раз относитесь к той прослойке, о которой в статье и говорится (разработчик вторпродукта, с которым работать невозможно). Лучше бы вы ответили на те вопросы, которые были вам заданы, а не измысливали мотивы написания данного материала.
Немного из личного опыта, в 2008 году я работал в одном "стартапе", регионального уровня который как раз и был МИС, но я разрабатывал не основные модули, на тот момент "Регистратура", "Отчеты ОМС", а уже дополнительные "Функциональная диагностика", "Лабаратория(анализы)", и прочее. Как и описал автор это было приложение с закрытым кодом Delphi + FireBird.
С самого начала разработки этой МИС был сделан основной упор именно на статистику и отчеты ОМС, это была одна из "киллер-фич" на тот момент, что позволило продукту быстро выжать с большинства ЛПУ области, дейстивтельно страшный продукт от депаратмента здравоохранения, который там и разрабатывался до этого (Clipper вроде или FoxPro не помню точно). Вторая особенность для местного рынка была схема продаж, ПО устанавливалось бесплатно, но в мес примерно 10тр "за обслуживание". И с ЛПУ разработчками контактировали очень плотно и для внешнего пользователя проблемы решались быстро. Приезжал(или удаленно) "прокачанный мальчик" и всем все помогал (учил, настраивал шаблоны, помогал в вычисткой отчетов, со сложными отчетами и прочее разное) или по крайней мере внятно формулировал задчу разработчикам, патчи клепались быстро и целевым образом, по конкретному запросу от каждой ЛПУ, так и жили.
Такая схема продаж (месячная оплата) + киллерфича - (минимизация ошибок по ОМС и пр статистики) + оперативная поддержка, были очень удобны и выгодны для главврачей. За пару мес. работы отбивалось все, так как предварительное исправление ошибок по базам ОМС (актуализация полисов, статусов) и прочие эверистичесике процедуры по БД, проделывалсиь каждый месяц или "прокачанными мальчиками" или особо въедливыми работниками медстатистики, данного ЛПУ. Данная схема работы была привлекательна отсутсвием серьезных денежных затрат: на старте(+ можно было держать параллельно две системы и сравнивать на живых данных) сохраняла для ЛПУ много(на порядки превышающие мес платежи) денег каждый месяц на ОМС + минимизируя конфликты со страховыми.
Потом началась какая-то программа и всем ЛПУ в приказном порядке сказали использовать Тра***Ме*, очень хорошо архитектурно система сделана, но как автор правильно и написал очень слабо учитывала потребности конкретного ЛПУ и детали работы на местах, а в то время очень сырая еще была она. Главные отбивались от нее как могли, я принимал участие в написании репликации данных из базы "Регистратуры" Тра***Ме* в МИС, дабы и главным можно было отчитаться перед департаментом и привычную налаженную! работу с ОМС не ломать. Также удаленность разработчиков, и скорость реакции саппорта Тра***Ме* == 0. Представьте, что будет творится в регистратуре Детской городской больницы, у кторой по 1000 приемов в день если все ПО "вдруг" после обновления зависло и не стартует, а мало того что в Липецке еще спят в это время. В общем было много недостатоков и у вновь централизовано продвигаемой МИС.
Потом ушел я из этой области. И многие годы думал что Тра***Ме* окончательно выжмет МИС, так как темболее собственник, начал делать упор на обслжуивании ПО и оргтехники, клиетская баз то была)) и ушел от больниц в народ, да и много чего еще, я утратил связь с этой конторой;
Недавно разговаривал с товарищем который там работал тоже разработчиком и сейчас пересекается с ними. На удивление мое Тра***Ме* за 10 лет не выжало МИС из Омской области окончательно, несмотря на серьезное давление из депаратмента. И МИС работает и развивается по той же схеме и по сей день. К сожалению нету сайта описывающей все возможности и прочее, так как владельцы понимают, что с такой схемой дальше омской области не уйти им, а в Омске про них и так все знают.
Страницы