Мій батько - лікар. Він наполягає на написанні бази даних для зберігання некритичної інформації про пацієнтів, без програми програмування [закрито]

Таким чином, мій батько зараз перебуває у "злому" баз даних за допомогою FileMaker Pro - інструменту базування даних на основі GUI для своєї невеликої практики (4 лікаря). База даних буде використана, щоб полегшити тягар звіту з медичних машин, упорядкувавши досить незграбний процес.

У нього немає програми програмування, і, здається, він робить все, що в його силах, щоб не навчитися правильно. У нього є повторювані типи даних, відсутність зв’язків із застосуванням баз даних (обмеження зовнішнього / первинного ключа) та десяток інших проблем. Він робить це вручну за допомогою інструменту GUI, використовуючи відео Youtube.

Моє питання полягає в тому, що, хоча я хочу, щоб він досяг 100% успіху, я не вважаю, що йому доречно обробляти такі рішення. Як переконати його, що без якоїсь освіти з цих тем рішення зламаного рішення - це погана ідея? Він може бути досить впертим, і я думаю, що він бачить такі види роботи як "діти грають"

Як я повинен підходити до цього? Це навіть погана ідея - чи я правильно маю на увазі, що він повинен найняти відповідного DBA / розробника для вирішення цього питання, щоб він не став кошмаром технічного обслуговування?

NB: Я консультант-розробник 4 років і бачив свою частку хворобливих реалізацій клієнтів.

Оновлення:

Отже, це вже через кілька років, і я встиг задуматися над цим питанням. Мій тато закінчив впроваджувати рішення за допомогою Документів Google, FileMaker Pro та деяких гачок електронної пошти. Він налаштував всю цю справу сам, і він каже, що отримує від цього величезну цінність.

Якщо ви досвідчений розробник, можливо, ви читаєте цей опис та формулюєте. Але я навчився досить хорошого уроку з усієї справи насправді - що люди дбають лише про результати, а не про їх реалізацію. Мене хвилює лише мій тато - той факт, що йому не потрібно вручну вводити інформацію про пацієнтів на папері, а замість цього можна швидко заповнити форму документів Google. Що чудово, він шукає, щоб найняти молодшого розробника / оператора, щоб зосередитися виключно на автоматизації в межах своєї практики.

Я багато років розробляв рішення для охорони здоров'я. Я не буду вникати в усі різні причини того, що твій батько не повинен цього робити; Більшість причин - академічні: це означає, що якщо ви досить довго працювали в цій галузі, ви знаєте, як ці речі є сніжком та розвивають власне життя.

Натомість твій батько, як лікар, повинен розуміти професійні причини та реальні, неакадемічні причини, чому те, що він робить, є небезпечним та, можливо, небезпечним для життя; небезпечний для своїх колег, небезпечний для конфіденційності та ідентичності пацієнтів та небезпечний для його практики з юридичної точки зору.

Небезпека багатогранна:

1. конфіденційність пацієнта (HIPAA, ARRA, значне використання, відповідність HITECH)
   • які поля вважаються полями, що ідентифікують пацієнта (багато фахівців у цій галузі цього не розуміють, і лише тому, що ви усуваєте деякі очевидні поля, такі як прізвище, адреса, поштовий індекс, є ще багато інших полів, які могли б зробити це легко пов'язувати клінічні дані з конкретним пацієнтом; це саме по собі складно; там компанії, які роблять багато грошей, де-ідентифікують клінічні дані - це сама по собі область).
2. HIPAA, HITECH та нове законодавство чітко визначає, як саме
   • аудит повинен проводитися
   • безпеку слід робити
   • вимоги до пароля
   • якщо дані в спокої повинні бути зашифровані
   • чи слід зашифровувати передані дані та яким чином
   • ви повинні врахувати елементи управління, якщо ви використовуєте будь-який розміщений сервіс (IaaS, PaaS)
   • чи є у вас відповідні BAA та DSA
   • як ті, хто розміщує ваші сервери, контролюють доступ
   • як вони поводяться з багатьма орендами (ви були б вражені тим, як деякі з цих великих організацій НЕ справляються з цим належним чином)
   • якщо ви розірвете договір з тими, хто розміщує вашу інфраструктуру, як вони забезпечать постійне видалення ваших даних (правила NIST)
3. які регулюючі органи існують для вашого розвитку
   • чи є у вас SDC на місці
   • чи є у вас відстеження від вимог до коду до якості
   • чи підтверджуєте ви «призначене» використання медичного додатка / пристрою
4. чи є ваше програмне забезпечення QA'd, і чи є у вас середовище тесту прийняття користувача (UAT)
   • як убезпечити це середовище, оскільки ви будете використовувати справжні дані про пацієнтів
5. чи збирається він обробляти медичних пацієнтів, якщо так, чи планує він використовувати свою базу даних для звітування?
   • уряд має жорсткий контроль за обміном цими даними на обмін інформацією про охорону здоров'я (HIE)
   • що призводить до того, як він буде здійснювати власний обмін, якщо захоче скористатися своїм сховищем клінічних даних (CDR)
6. чи розуміє він конкретні норми NIST, які він повинен дотримуватися для безпеки даних
   • наприклад, постійне видалення даних (якщо використовується розміщена інфраструктура)
7. Ви згадали, що він буде брати дані з медичних машин
   • чи він розуміє нові стандарти медичного обладнання FDA?
   • Починаючи з 2013 року, будь-яку цифрову систему, яка відображає дані з медичних пристроїв, можна кваліфікувати як медичний пристрій ... це означає, що він повинен відповідати нормативним вимогам FDA щодо медичних пристроїв
8. чи буде його команда та персонал приймати медичні рішення на основі даних у його базі даних?
   • чи розробив він надійну модель клінічних даних, достатньо гнучку, щоб впоратися з постійно змінюються вимогами (тобто, ICD-9 до ICD-10 до ICD-11 стандартам кодування)?
   • як він буде модифікувати модель даних і тримати її синхронізувати з даними (тобто, якщо він змінить модель клінічних даних, як будуть представлені старі дані?)
   • чи зможе його система створити точний знімок клінічних даних, як це було видно в день прийняття клінічного рішення? Є юридичні наслідки, якщо він не може
   • чи знає він різницю між реальним видаленням та логічним видаленням та наслідками для його моделі даних; до вимог його зберігання; до політики його практики?
   • чи є у нього рішення словникового запасу для роботи з усіма різними послугами, які йому знадобляться; значну частину даних потрібно кодувати (на відміну від вільного тексту), оскільки він захоче скористатися своїм CDR для створення звітів, сумісних з ICD-9. І тоді йому потрібно врахувати зміну цих стандартів; наприклад, ICD-9 до ICD-10.
   • для словникового запасу, термінології або словника даних про здоров'я (як правило, це синоніми), як він буде реалізовувати та гарантувати, що стару термінологію все ще можна винести на старі клінічні рішення?
9. чи зберігатиме він дані про алергію?
   • як зберігатимуться його визначення «медична термінологія» чи «словниковий запас»?
   • він інтегруватиметься з іншими термінологічними системами, такими як LOINC та First Bank Data?
   • чи має він розуміння термінологічних служб (тобто, Словник даних про здоров'я)
10. чи захоче він мати дані, пов'язані зі своєю системою, і, можливо, на обмін інформацією про здоров'я (HIE)?
    • якщо так, чи він розуміє HL7 та його вплив на його базу даних?
    • він розуміє інтерфейсні двигуни і все, що йде разом з цим?
11. чи розуміє він, як деіндентифікувати інформацію?
    • це важливо у фазі розробки та фазі виправлення помилок

Це лише кілька питань, і це аж ніяк не слід вважати вичерпним переліком. І до кожної відповіді буде незліченно більше запитань.

У базі даних охорони здоров’я не повинно бути жодного видалення або перезапису попередніх даних. Це означає, що ніколи не буде "видалити звідки ..." або "встановити оновлення ...". Натомість у вас будуть лише вставки. Ви можете уявити, як це змінює вашу модель даних та ваші запити. Тепер ви можете бути творчими та придумувати різні рішення для досягнення цієї мети, але факт залишається фактом, що це вимога, яка є унікальною для сховища клінічних даних охорони здоров'я.

Ще одна думка щодо небезпечної для життя сторони цього питання:

Візьмемо, наприклад, інформацію про алергію; Я піднімаю це, тому що установи, які роблять це цифрово протягом багатьох років, дізналися, що їхні процеси повинні забезпечувати захоплення даних про алергію, і що ми не можемо припустити, що оскільки технології, отримані в базі даних, це якось по суті вірно вірно . Ось чому пацієнтів запитують на алергію щоразу, коли вони переходять з одного відділення в інше, навіть у межах однієї лікарні. Алергію пацієнта неможливо видалити (оновлення рядків видаляють стару інформацію). Клінічне рішення, засноване на цифрових даних, повинно відображати те, що було «представлено» клініцисту на момент прийняття рішення.

Я знаю, що багато з цього може здатися орієнтованим на велику установу. Однак регуляторні частини не є. І в будь-якому випадку інформаційні системи охорони здоров’я за своєю суттю є складними. Інженерія системи охорони здоров’я залежить і визнає досвід та досвід хороших лікарів. Однак у ІТ-галузі охорони здоров’я є більша за середню невідповідність імпедансу (запозичити термінологію з технології ORM) ... Я ризикую сказати більше, оскільки кожен домен має свої невідповідності.

Удачі!

Рішення зламана разом не завжди є поганим. Якби він вирішив його проблему, я б не надто сильно смердував над цим. Напевно, 10 працюючих рішень злому разом у File Maker та Access для кожного професійного рішення бази даних. Зрештою, саме для цього призначені Filemaker та Access. Звичайно, більшість розбитих разом рішень жахливо під кришкою. Але вони існують, щоб вирішити проблеми, а не вигравати конкурси краси. Часто обсяг цих рішень зростає, і саме тоді когось наймають на створення професійного рішення.

Що ви можете зробити, щоб допомогти йому шанси на успіх, це висловити зацікавленість його проектом і запропонувати сісти і допомогти йому визначити базу даних і пройти все. Якщо він не хоче вашої допомоги ... киньте його і нехай буде. Що ти збираєшся робити, борсук свого батька? Якщо / коли він зайде над головою, він повідомить вам про це.

Інша річ, яку слід враховувати, якщо це поширена проблема серед лікарів, у вас може бути дуже хороша можливість для бізнесу в створенні загального рішення.

Як дизайнер програмного забезпечення, який має досвід 25+ років, я все ще бачу привабливість у тому, щоб створити щось самостійно. Пояснення речей комусь, хто не розбирається в цій галузі, може бути величезним тягом.

Що робити, якщо база даних не нормалізується або її можна зробити швидше? Принцип wabi-sabi дотримується багато некритичного програмного забезпечення (особливо в епоху спритності). Це робить те, що потрібно робити, і не більше.

Зверніть увагу, що не все програмне забезпечення має кричати разом із ідеальним інтерфейсом, блискавичним доступом до бази даних та непорушним графічним інтерфейсом.

Моє питання полягає в тому, що, хоча я хочу, щоб він досяг 100% успіху, я не вважаю, що йому доречно обробляти такі рішення.

Filemaker почав свою роботу як базу даних, яку кожен міг би використовувати, і вона все ще дуже добре працює в цій ролі. Якщо ваш батько знає, що він хоче, і почуває себе комфортно, склавши його разом, що ви переживаєте? Якщо це працює так, як він хоче, він виграє. Якщо це не працює так, як він хоче, він це виправить.

Ви були б праві, щоб він був стурбований, якби він будував базу даних для всіх лікарів, які працюють на Кайзера Пермантенте, але якщо він просто створює інструмент для використання у власній практиці, здається, що він, мабуть, є саме правильною людиною, яка займається цим. рішення.

Не дозволяйте досконалим бути ворогом добра.

Моя порада зробити вигляд, що цього не існує, інакше це зведе вас з розуму. У мене є родич, який зробив подібну справу зі своїм списком клієнтів, і те, що він створив самостійно, - це жахливість. Я спочатку запропонував допомогти, і він вважав, що моя цитата (на яку була знижена "сімейна" знижка) була обурливою. Подивившись на це, я запропонував купу змін, які він попросив внести в обмін на "пару пива". Сім'я чи ні, Хомі не грає в це. Я сказав йому, що він повинен найняти когось, щоб це зробити, але він ніколи цього не робив. Мені просто довелося повністю відірватися від цього і зробити вигляд, що його не існує, просто щоб ужас проекту не з'їдав мене.

Ви повинні дозволити йому спробувати. Однак вам слід дати йому знати про те, що коли він потрапить у глухий кут, це його проблема, і будь-який розробник, якого він вирішить найняти в цей момент, повинен буде почати з нуля.

Мені подобається дуже багато ламати речі, наприклад, меблі та навіть сантехніка. Мені це подобається і я не бачу в цьому нічого поганого. Я ніколи навіть не наважувався б попросити кваліфікованого майстра підстрибнути на мене, коли я застряг, просто тому, що думаю, що вони кинулися б перед самим поглядом моїх творінь.

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

він розглядає ці види робіт як "діти грають"

Я консультант-розробник 4 років

Для власного благополуччя та особистого розвитку батька нехай він провалюється. Відповідь Джона є непохитною, і вам слід згадати достатньо, щоб уберегти батька від неправильної сторони закону або, принаймні, достатньо, щоб він міг краще знати. Але вся ця річ "смирення" - це не те, про що ви можете читати лекції людям і очікувати, що вони це дізнаються. Це дуже важливий життєвий урок, щоб спробувати найважче і зовсім провалитись. Невдача - дуже потужний вчитель. І він може завоювати певну повагу до професії сина.

І ей, якщо йому вдасться обрушити щось, що працює досить добре (і не порушує жодних законів), тим більше сили для нього.

Це його справа. І якщо він рішучий, він змусить це працювати. І багато людей зближували рішення з різних технологій, щоб налагодити роботу.

Роки тому я переглянув код мого друга, який склав веб-додаток із PHP та деяким програмним забезпеченням дошки оголошень. Він сильно налаштував це для задоволення своїх потреб. Код був гидотою. Крім ледве першої нормальної форми, він мав HTML-теги з даними у своїй базі даних. Відсутнє відділення MVC. Але Бог благословить його. Його заявка спрацювала, і він міг оплачувати свої рахунки доходом від цього веб-сайту.

Моя порада до нього полягала в наступному: Якщо ви хочете доїти заявку на отримання доходів якомога довше, тоді не відмовляйте її, використовуючи хороші методи проектування програмного забезпечення, і залишайте "досить добре" в спокої. Якщо ви хочете розвивати свою заявку, щоб пропонувати більше послуг та отримувати більше доходу, тоді вам доведеться заплатити і перефактурувати код. Він обрав поїхати з колишнім. Це життя.

Якщо ваш тато зараз не відчуває болю за дублювання даних та слабку цілісність даних, він пізніше, і лише тоді він дізнається значення того, що ви говорите.

Я думаю, що відповідь на ваше запитання головним чином залежить від того, наскільки критичним для його медичної практики є ця програма. Чи зберігатиме він там лише деякі дані пацієнтів, які він вважає корисними, або будь-яка несправність цієї програми може мати серйозні наслідки? Якщо це може мати серйозні наслідки, тоді він не повинен цього робити, а тому, що ми не живемо у досконалому світі, переконуючи його, що це не гарна ідея, може бути зовсім іншою справою.

Оскільки ви консультант-розробник, я б запропонував запропонувати йому допомогу в питаннях забезпечення якості та тестуванні. Таким чином ви будете підтримувати добрі стосунки з батьком, тому що ви "допомагаєте" йому, але в той же час ви можете переконатися, що його додаток робить те, що потрібно зробити, або навіть знайти проблему, яку він не зможе вирішити. тому він буде шукати більш професійного рішення.

До речі, я бачив досить багато жахливих додатків, які виконували свою роботу, і жодне пояснення того, чому це страшно, переконувало б когось зробити якісь реальні зміни у ньому.

Будучи нещодавно звільненим програмним інженером для великого некомерційного постачальника медичних послуг, я настійно рекомендую шукати лікарню чи велику практику поблизу, яка може за розумну плату дозволити йому ділитися своєю системою електронних медичних записів, яка відповідає вимогам ініціативи «Значне використання». (та інші урядові програми заохочення).

Я знаю, що “Epic” ( http://Epic.com ) підтримує своїх клієнтів, дозволяючи меншим провайдерам ділитися своєю системою, і я думаю, що це роблять і деякі їх конкуренти. Сернер є їх найбільшим конкурентом, але кілька інших обговорюються на веб- сайті http://www.beckershospitalreview.com/healthcare-information-technology/50-things-to-know-about-epic-cerner-meditech-mckesson-athenahealth-and- other-major-ehr-vendors.html

Існує 75% субсидія від CMS для такого типу обміну. Ми передали субсидію нашим клієнтам, зробивши вартість передплати 25% від нашої вартості.