電子カルテ（ANNYYS_D）との疎結合
「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 には負荷をかけずに、院内ソリューション側で自由に参照。患者別ではなく、時系列で並べたり、検索だって思いのままです。下図は時系列で並べたイメージです。
もちろん、院内ソリューションの患者別の情報欄にポータルで配置するのも簡単というか、当たり前にできます。
リスク分散のためにも、推奨したいと思っています。
Meraki-Go における、4つのSSIDでの運用
これまでも、ネットワークの運用には苦心してまいりました。
今回も、もうひとつ、Wi-Fi の設定、運用についての取り組みを。
今回の問題は、名付けて、「端末の接続が、遠くの SSID に浮気してしまう問題」です。
目次
メッシュ Wi-Fi なのに
例えば、メッシュWi-Fi にしていて、近くにアクセスポイントがあるのに、遠くのアクセスポイントに接続されたりすることがありまして。この件について、メーカーさんに問い合わせたこともあるのですが、結局のところ、どのアクセスポイントに接続されるかは子機しだいという面があるようです。
うーむ。デスクトップ端末などは、接続するアクセスポイントを固定したいんだけど。ちなみに、件の無線LANアクセスポイントは、Cisco社製のMeraki-Go。
というわけで、何か良い方法がないものかと考えながら、専用アプリを触っていたのですが、良さそうな機能を見つけました。数ヶ月前から、アップデートによって機能付加されていたようです。
ひとつは、最大4つのSSIDを発出できる機能。
もうひとつは、アクセスポイントごとに、発出するSSIDを選択できる機能。
Meraki-Go アプリから設定
以下、Meraki-Go アプリの画像から。
アップデート情報。
4つのSSIDを設定できる。
端末を選択できる。
これで、ある程度、接続先をコントロールすることができるようになりました。
それでも、移動する端末については、基本的には常に接続先を気にかけるべきではありますね。
関連記事
Wi-Fi のトラブルと電源ノイズ
まさか。電源ノイズがネットワーク障害の原因になるとは。
怖いのは、タコ足配線しているわけでもないのに起こりうることです。
今回の発端は、同じコンセントに Wi-Fi 親機と複合機が差してあり、その Wi-Fi 親機がたびたび落ちてしまうという現象が発生。別のコンセントから電源をとることで、問題は回避されました。
ただし、このコンセントが直接の原因ではなく、施設全体のインフラに原因がある可能性もあるわけで、このあたり、原因の特定は非常に難しいのは確かです。そういえば、以前は、雨の日の後に落ちてしまうスイッチングハブがありました。あれも別の場所から電源を引くことで解消された記憶が。雨の日の後というのは気のせいなんでしょうけど。そして実は同様のことが別の場所でも発生。そうなると老朽化が原因なのか。
以下、今回参考にさせていただいた記事です。
「電源ノイズ」をキーワードに、かつての同僚が見つけてくださいました。
では、どのような機器がノイズをハッスルしてるかの簡単な見極めは以下の２つです。
ネットワークトラブルの原因は多岐にわたります。確認事項も膨大ですね。最初の頃は、サーバーマシンの負荷に問題があると考えて、サーバーの設定に苦心しておりました。その後、有線LANの爪折れが発見されたり、ループが発見されたり、遠くのSSIDを掴んでしまう問題などなど、インフラのメンテナンスは大変なものです。単にすべてを有線LANにすれば解決するわけでもなく、Wi-Fi なら簡単というわけでもなく、サーバー管理、ネットワークの設計、配線の敷設、電源工事、末端の接続設定などなど、関わる専門分野も多岐にわたるわけで、電力やネットワークなど社会のインフラを維持管理されている皆様、本当にご苦労さまです。
今回の施設では、電源工事も行っていただき、Wi-Fi の負荷分散も施してみました。
これまでもネットワークトラブルには悩まされてきましたが、どうやら、ようやく、数年来のオンコール態勢から解放されそうです。もう、1ヶ月くらい障害は発生しておりませんし。
いやはや、本当に膨大な時間と労力を費やしてまいりました。
関連記事
転職の前に、キャリアコンサルタントのカウンセリングを受けておりました。
タイトルのとおりなのですが、地元のキャリアコンサルタントの方にカウンセリングを受けておりました。転職の前に、一度なのですが。
「ディーリンクス」さんのことは、以前から存じあげていて、また、友人にキャリアコンサルタントを取得した方もいて、一度、プロのカウンセリングは受けてみたいと思っておりました。自分の頭の中の整理も兼ねて。もちろん、きちんとカウンセリング料はお支払い。
数年前から「なにか変えたい」と考えていました。そのために、結婚も考えよう、住む場所を変えよう、転職も考えよう、って感じで考えておりました。私なりの働き方改革と言いますか、ワーク・ライフ・バランスといいますか。とはいえ、前職での給与や職務内容に特に不満があったわけではありません。早い話が、15年以上努めてきて、いろいろと倦んで来てたんですね。
カウンセリングの結果、自分なりの方針として、元の職場に繋がりを持ちつつも、軸足を移したいと思うようになったのであります。元の職場での職務を放棄するわけにはいかないし、自分が構築したシステムへの愛着もあったわけで。それでも、少し働き方は変えてみたい。
一方で、別の観点から持っていた懸念がありました。
長年、元の職場で、FileMaker を用いた業務用システムの内製化を担ってきたのですが、「私への属人化を防がなくてはならない」とも思っていました。そのためには、実は私が少し手を引く必要があるのではないか、私が執着を捨てた方が良いのではないか、そう思うようにもなっていました。幸い、私が手を引いた今でも、十分システムは稼働しているなという印象で、むしろ、私が辞めた現在の方が安定しているような気がします（笑）。
こういう流れで転職となりました。
急いで付け加えますと、退職願を出してから、転職の打診を始めました。
この辺は、私、義理堅いのです。
そのうち、友人のカウンセリングも受けてみたい。
前職でのローコード開発 by Claris FileMaker
前の職場では、Claris FileMaker を利用した独自Solutionを長年に渡って構築していました。転職して3ヶ月が経ちますが、日常的な設定変更やトラブル対応は、かつての同僚がカバーしてくれています。ちょっとしたスクリプトの変更なども対応してくれます。ありがたいことです。インハウスの一人情シスだったのですが、ある程度、属人化からは免れていたようで安心しています。…窓際でしたし（笑）。
こういったことが可能となった要因のひとつは、今で言う「ローコード開発」だったから、と言えるかもしれません。つまり、あまり高度なことはやっていない。
目次
15年におよぶ開発
自分で言うのも何ですが、構築したSolutionは職場の業務を広範囲にカバーするものでした。様々な情報が連動するSolutionでして、止まってしまうと経営に支障が出るレベルと言えなくもありません。図にすると、なかなか凄いでしょ。ほぼ一人でやってましたから。でも、ローコードなので、ある程度再現は可能です。
開発過程を共有
上図に描かれていない機能もたくさんあります。とはいえ、そのひとつひとつは、それほど難しいものではありません。また、在職時から、数人の同僚に完全アクセス権を付与して、開発の着手から運用、バグの発生まで多くの事案をオープンにして見てもらっていました。見てもらえば、何となく理解できるレベル。そんな手の内を晒したローコード開発でした。
プロの方との連携
プロの方々とも連携して、環境面の整備もできていたんじゃないかと思います。
現在は、私自身が株式会社エヌ・ケイ・カスタマイズの社員として関わっております。
当ブログの過去記事から連携事例を振り返りますと、例えば、FileMaker のライセンスは、ASLA ( 年間サイトライセンス )ですが、公式トレーニングを受講したご縁でご教示いただき、以来、株式会社ジェネコム様よりライセンスを購入しています。あの頃はまだ、鹿児島にはリセラーさんがいなかったような。
FileMaker Server のセットアップについては、株式会社キー・プラニング様にご支援いただきました。今では、コールドスタンバイマシンをサブマシンとしてテスト用に活用しています。コールドにしていない（笑）。
そして、電子カルテ ANNYYS を導入・開発するにあたって、株式会社エムシス様と提携して現在も継続中です。
前職の経験は、まさに私の血肉です。
Wi-Fi の親機と子機、そしてHUB
事業所内のLAN環境の整備に関する、自分の記事のまとめです。
Claris FileMaker Server を運用する以前に、ネットワークインフラには本当に悩まされてきました。その経緯は度々当ブログでも記事にしてきました。ネットワークインフラは全体的な設計はもちろん、ケーブル1本にしたって大切ですが、ここでは、お世話になった機器についてまとめてみます。もっと良いものがあれば、ぜひ、教えてちょーだい。
目次
Wi-Fi親機
まず、Wi-Fi親機。Cisco社のMeraki Go だと、スマホアプリを使って自宅からでも監視できるのはもちろん、各端末の電波強度（受信強度）が確認できるのが嬉しい。メッシュだし、有線LANでバックホール接続もできますし。
- 発売日: 2019/06/21
- メディア: Personal Computers
下図のように、アプリで各端末（子機）の受信強度を確認できます。加えて、どの親機に接続されているかも確認できます。この点、「なぜ遠くのWi-Fi親機を掴んでるの？」という事態も確認できます。
意外と受信強度が弱い、遠くのWi-Fiを掴んでしまう、という事態は、意外と発生しやすいうえに把握が難しく、対応に悩まされてきた問題でした。それこそ数社の親機を試してみたり、親機の設置場所を工夫してみたり、長年、悪戦苦闘を続けてきました。で、ここで目を向けたのが子機でした。
Wi-Fi子機
ちょっといい子機に換えることで受信強度がかなり改善されました。そして、その強度をアプリで確認できたのも嬉しい。とりあえず、子機は迷ったらこれを買っています。
TP-Link WiFi 無線LAN 子機 867 + 400Mbps 規格値 11ac 11n デュアルバンド MU-MIMO対応 USB3.0 ３年保証 Archer T4U Plus
- 発売日: 2021/01/14
- メディア: Personal Computers
HUB（スマートスイッチ）
見えづらい「ループ」にも悩まされていました。
これも機器を買うことで解決。この価格でループ防止機能がついているのが嬉しい。要所要所に配置してしまいましょう。
TP-Link 8ポート 10/100/1000Mbps ギガビット イージー スマート スイッチ TL-SG108E
- 発売日: 2016/06/25
- メディア: Personal Computers
以上、Claris FileMaker Server で何かおかしいなと思ったら、これらにも目を向けてみてください。私からの経験でした。
以下、関連記事。
病床管理システムのサンプルを作成中
稼働数、稼働率、入退院履歴、さらにはそこから派生する様々な指標の算出に関して。
当ブログに対して、今でも忘れた頃にお問い合わせのあるカテゴリーのお話です。
例えば、
在庫管理であれば・・・
→ 「商品マスタ」 と 「入出庫履歴」
病床管理であれば・・・
→ 「患者マスタ」 と 「入退院履歴」
がどうしても必要になるかと思います。
こういったことは、宿泊施設の予約管理でも同様かもしれません。
これらは日々の基礎データの入力がとても重要になります。すべての業務がそこから派生していると言っても過言ではありません。例えば入出庫の履歴が登録されていないのに、在庫のチェックなんて無理なわけですよ。逆にこれらがしっかりしていれば、在庫チェックが可能になる。あとの仕事が非常に楽になるわけです。
病床管理に関して、私は前の職場（病院）で、Claris FileMaker を使って自作でシステムを構築、運用しておりました。かれこれ10年以上、手を加えながら運用しておりまして、未だに稼働中。いまも日々の病院運営に寄与しております。
私の仕組みは、3つのテーブルを基本にしていて、そのことは2007年に記事にしています。これが、様々な集計の基礎になっています。
こと「病床管理」に関していえば、たとえ電子カルテを導入したとしても、必ずしも、電子カルテから直接、平均在院日数が算出されるというわけではないかもしれません。。少なくとも、これは、「狭義の電子カルテ」の機能ではないわけです。つまりそれは、紙のカルテ庫に行っても平均在院日数が算出できるわけではないのと一緒です。この点、前の職場においても、病棟用の電子カルテが導入されたとしても、私のシステムは機能し続けるのかな、と思っております。
それはさておき。
現在、前述の「3つのテーブル」を基本にしたサンプルを作成中です。
自分の考え方の基礎でもあるので、説明の際にも役立つのではないかと思っております。
