「ANNYYS_D」は、Claris FileMaker で構築された電子カルテです。
前職では、この ANNYYS_D と、施設で独自に構築してきた FileMaker のソリューションを連携させて利用しておりました。今回は、その連携のさせ方についてのお話です。
当然、FileMaker で構築されたシステム同士なので、圧倒的に連携させやすいわけです。互いのテーブルを直接参照してリレーションを張ることだって可能。ただ、私は可能な限り「疎結合」で連携させていました。ANNYYS_D を製品として尊重して、できるだけ手は加えない。実際、手を加えて不具合が発生しても大変ですし、保守の面からも難しくなってしまいます。全く手を加えていないわけではないんですけれども。
具体的には、
- ANNYYS_D と院内ソリューションでサーバーマシンを分ける
- 直接リレーションを張らない
- 互いのデータは、スクリプトスケジュールでインポート・エクスポートして参照
といったことを基本方針として運用しておりました。
繰り返しになりますが、必ずしも遵守していたわけではないのですけれども。
サーバーマシンを分けて運用すること自体は、簡単です。FileMaker のデータベースがマシン複数台に分かれていても、テーブルを参照したり、リレーションを張ったり、スクリプトを呼び出すことはできるわけですから。何よりもメリットとして、リスク分散になります。
その上で、できるだけ、外部から ANNYYS_D のテーブルを直接参照したり、ましてや直接書き込んだりするのは避けたいと思っています。書き込むのであれば、要件を備えたスクリプトを経由して書き込むべきでしょうし、無粋な利用者によって、レコードのロックが発生し続ける、なんてことも起きかねません。
というわけで、ANNYYS_D と院内ソリューションの互いの情報の参照は、互いにインポート・エクスポートして参照しておりました。サーバー上のスクリプト実行（Perform Script On Server）で、毎日だったり、1時間毎だったり、定期的に実行。これがちょっとしたバックアップにもなったりします。下図は、そのスクリプトのイメージです。ここでは、ANNYYS_D の診察データを院内ソリューションにインポート。
インポートしてしまえば、ANNYYS_D には負荷をかけずに、院内ソリューション側で自由に参照。患者別ではなく、時系列で並べたり、検索だって思いのままです。下図は時系列で並べたイメージです。
もちろん、院内ソリューションの患者別の情報欄にポータルで配置するのも簡単というか、当たり前にできます。
リスク分散のためにも、推奨したいと思っています。
