病院などの臨床現場で新しいシステムを設計する際には、医師、看護師、薬剤師、技術者などからシステムの使用例に関する情報を収集することが重要だと思います。
これらすべてが忙しい専門家でもあるという事実は別として、ソフトウェアエンジニアリング設計で使用できる(おそらく混沌とした時間に敏感な)ワークフローに関連する情報を共有させるための良い方法は何ですか?
医療専門家が行っていることをリバースエンジニアリングする唯一の方法は、彼らが働いている間に直接観察することです。白米のような喜んでおしゃべりな専門家を見つけてフォローし、仕事と思考のプロセスを説明するように依頼します。提案が必要な場合は、次のようなルールに向かう質問をします。何を考えていますか。なぜそれよりもこれを選んだのですか?何を探していますか?それは何を除外しますか?
学びながら、メンタルモデルを共有し、ルールを形作り、洗練する質問をします。彼らの仕事の日記になりなさい。
積極的で、実践的で、対面で、敬意を持って観察し、フィードバックする以外のことは、エンジニアリングではなく推測です。
少し異なる視点からの別のopenEHR関連の回答...
OpenEHRアプローチは、臨床データ要件の標準化にかなりの成功を収めています。つまり、臨床医が定義したEHRコンテンツ仕様です。モデルが有効で、安全で、正しいことを保証するための臨床医と利害関係者の専門家の協力。臨床EHRシステムで使用するためにそれらを管理/配布します。この標準化されたアプローチは、注文や対応するアクティビティの文書化など、ワークフロープロセスのキャプチャを簡素化するのに役立ち、ワークフローの追跡を可能にします。 openEHRクリニカルナレッジマネージャーは、このアクティビティのハブとして機能しています-www.openEHR.org/Knowledge。
一部の法域では、国のeHealth標準の作成にもこのアプローチを使用し始めています http://www.nehta.gov.au/connecting-australia/terminology-and-information/detailed-clinical-models =および http://dcm.nehta.org.au/ckm/
一部の専門学校もこれらの方針に沿って考え始めており、ベンダーが構築しているソフトウェアが安全で臨床使用に適していることを確認しています。オーストラリア、英国、米国で初期の活動が行われていることを認識しています。
ドメイン固有言語に投資します。ソフトウェア開発の観点からは、正しい方法でソフトウェアを開発できるため、臨床ソフトウェアには注意が必要ですが、適切なソフトウェアを開発するのは困難です。最も優秀なビジネスアナリストやソフトウェア開発者でさえ、臨床医とのコミュニケーションに苦労しています。
医療ITドメインでは、特定の言語(ほとんど)が電子医療記録関連の標準に対応しています。チェックアウト http://www.openehr.org 臨床医がドメインを説明する計算可能な言語を使用して要件を表現できる場合は、要件をソフトウェアに変換する方がはるかに簡単です。私が話しているアプローチの例を見るには、私たちのオープンソースプロジェクトを見ることができます: http://opereffa.chime.ucl.ac.uk
Davidの投稿から飛び降りる:一般的なEHR製品の開発を検討していますか、それとも特定のクライアントサイトをインストールしていますか?私たちは社内でオンコロジーEHRシステムを開発しており、毎日オフィスにいなければこのプロジェクトがどこにあるのかさえわかりません。あなたが本当に練習を学びたいのなら、あなたは本当にたくさんの顔の時間と彼らがあなたのスクリーン上でそれが異なるべき方法を指し示す時間を必要とします。
顧客から離れるほど、コミュニケーションが遅くなり、顧客が望むものではなく、顧客が望むものにプログラミングするようになります。
また、ほとんどの機能は複数の人、看護師、管理者などに影響を与えるため、全員から意見を聞き、十分な情報に基づいて意思決定を行うことが重要です。