カテゴリー「覚え書き」の7件の記事

2020年8月15日 (土)

歯式メーカー アップデート

気がついたら1年半以上更新していない(^^;

 

たまには記事を投下しないと忘れ去られちゃうので...

 

ということで、突然ですがご好評いただいている「歯式メーカー」をアップデートしました(ってこれも結構前のことですがw)。

20200815-140920

 

ダウンロードページ

アップデートしたのはMac版だけです。

機能的には全く変更ありません。
最大の変更点は64bitアプリケーションになってMac OSX 10.15 Catalinaに正式対応した点です。

単純に64bitアプリケーションに対応しただけでなく、新しいMacのGatekeeperとアプリケーション公証(Notarized)制度への対応です。

10.14までは、アプリケーションを署名するだけでOKでした。署名をすることでアプリケーションが配布の過程で改竄、修正されていないことを証明していたのですが、時代が変わり、アプリケーション自体に悪意あるコードが仕込まれていないか、また、プライバシーの関連で不用意に個人情報に関わるハードウエア(カメラやGPSなど)にアクセスしていないかなどのチェックも必要になったために、10.15からアプリケーションの公証が必要になったのです。

署名自体もより深くまた追加の情報も必要になりました。また、実行環境の変化も見逃せません。実行コードは必ずリードオンリー(書き込み不可)の状態で実行され(Hardened Runtime)、コードの書き換えを禁止してマルウエアの可能性を排除することになり、また、実行時にアクセスするハードウエア等の情報(Entitlements)の付加も必要です。署名自体もタイムスタンプの付加が必須になりました。

この署名をした上で、アプリのコードをアプリをAppleに送り、内容をチェックし認証を受けます(公証)。認証されると「チケット」が発行されますので、これをアプリにホチキス止め(ステープル)してサイトにアップすることになります。

ダウンロードされたアプリは署名をチェックし、さらに「チケット」の有無と有効性をチェックされます。「チケット」がなければ、Appleの認証サーバーに問い合わせて、正しいアプリかどうかがチェックされます。この厳重なチェックを受けてようやく実行できるようになるんですね。

さらに、アプリは「アプリケーション」フォルダで実行する必要があります。「アプリケーション」フォルダ以外で実行すると、どこかわからない隔離された「箱庭」で実行されます。「箱庭」ではファイルアクセスも禁止されているので実質、起動できないんですねぇ。徹底してます。

そんなわけで、歯式メーカーも4Dv18を使うことで、上記への対応を済ませたバージョンにアップデートしたわけです。

上記への対応は、4Dv18から正式に対応してます。v17までは10.14までのコード署名にだけ対応していたので、v17で署名付きのアプリをビルドしても10.15では実行できませんでした。

v17で10.15へ対応するには、マニュアルで新しい署名をする必要があります。幸い4D社のmiyako氏が、新しい署名をするための4Dのプログラムを作成して公開されていますので、これをダウンロードして利用させていただきました。ありがとうございます。

https://github.com/miyako/4d-utility-build-application

v18では新しい署名に対応していますので、署名付きビルドをするだけでAppleの認証を受けられるアプリのコードを作ることができます。

ただ、歯式メーカーでは、4D社以外のプラグインを利用しており、これがどうしても4Dのオリジナルの機能ではうまく署名ができずAppleの認証を受けられませんでした。miyako氏のプログラムでは問題なく署名できたのではできたのでよかったですが、あいかわらずAppleへの対応では罠が多いですw

この新しい署名や公証の情報は少なくて最初の頃は苦労したのですが、これもmiyako氏がとても丁寧な記事を書いていらっしゃいますので、ご興味のあるかたは是非ご覧になってください。

https://miyako.github.io/2019/10/16/notarization.html

 

 

 

| | コメント (0)

2007年12月 5日 (水)

メモ

東京都のまる子について
まる子の一部負担金のレセプト、請求書への記載は1円単位で丸めない。
(東京都の他の公費はすべて丸めて記載)
どう対応するか?
まる子は88133,88135
まる乳は88132
公費の法別を上位2桁で判断しているが、これを前方一致に変更できないか?
レセプト、カルテ全体にわたる大幅な改造が必要かも。
あるいは従前通り、「負担金形式」の追加、修正で対応すべきか?

| | コメント (0) | トラックバック (0)

2007年11月 5日 (月)

メモ

画像パレットの機能強化
 ローカル画像パレット:
 患者ごとにローカルの画像パレットを作る。

画像ページで過去画像を簡単に呼び出してペーストできるようにする。

| | コメント (0) | トラックバック (0)

2007年10月29日 (月)

メモ(エラーチェックに関して)

エラーチェックで、算定がない項目でのエラーを報告するかどうかを検討。
エラー自体は報告するが、チェック一覧で絞る方が良いだろう。
チェック一覧に点数の無い処置のエラーが表示するしないのチェックを追加する。

| | コメント (0) | トラックバック (0)

2007年10月27日 (土)

メモ:ワーキングテーブル

「患者マスタ」に隷属
作業用のテーブル。治療履歴の記録の補助をする。

用途
治療計画の進捗管理
自費支払い計画の管理(売り掛け管理)
PostIt!機能

なぜ必要か?
治療履歴は電子保存を前提とした記録方式なので、動的な記録を管理するには向いていない。

例)
売り掛け管理
請求書->会計入金->会計入金
の場合の売り掛け残高管理などを想定。
治療履歴に請求書があるとして、
この治療履歴に残高を含めると、入金の度に訂正処理が発生し、その都度確定処理が必要になる。
残高を含めないで残高を管理するには、残高が必要な時に全記録を抽出し計算し直す必要がある。

残高を管理するために別テーブル(電子保存の対象外)を用意して、そこで残高を管理する。
(ただ、残高の処理は本質的に再計算を要求する。削除、追加があるため)
(この再計算を確実に行うため、治療履歴の削除追加に連動してこのテーブルを更新する方法を組込む必要あり。)
(そうなると、作業用テーブルは必要ないかも?)
(でも、売り掛け残高を素早く検索するには、やはり必要。ない場合は全患者のデータを再計算しないと検索できない。これは明らかに時間がかかりすぎて実用的でない。)

構造:
多目的に使い回すためメタ構造とする。

患者コード
対象GsID
機能コード
管理XML
データXML
long P1
long P2
long P3
long P4
str(A40程度) P1
str(A40程度) P2
str(A40程度) P3
str(A40程度) P4
text P1
text P2
日付 P1
日付 P2

| | コメント (0) | トラックバック (0)

メモ:キーワード

「キーワードテーブル」
「患者マスタ」に隷属。
キーワードカテゴリー:キーワードの組み合わせを記録。
患者検索等に利用

年賀状:2006
お中元:2005
自費治療:あり
など

| | コメント (0) | トラックバック (0)

メモ

どうも最近、物忘れが多いので、メモ帳代わりに。(^^;

確定操作中のユーザー選択ダイアログで、初期値に前回選択したユーザーを選ぶようにする。

セット入力画面中から処置のディフォルトコメントを修正できるようにする。(サーバ−のみ)

日計、会計日計等のウインドウの位置を保存する。(マシンごとに)

| | コメント (0) | トラックバック (0)