品質強化プロジェクト（次期DICOMライブラリ情報共有会）
===

###### tags: `Meeting`

:::info
- **Date:** July 21, 20209 17:15 PM
- **Agenda**
1. Walk through signup flow`
- **Participants:**
- 磯島部長
- 石橋
- 内海
- 笠埼
- 西原
- 藤岡
- **Host:** 磯島

:::

## ユーズテック社内で使われているDICOMライブラリ
1. DCMTK 3.5.4(FCR Storage対応社内ビルド版)
2. DCMTK 3.5.5
3. DCMTK 3.6.0
4. fo-dicom

## 現状の問題点
- VisualStudio 2013でビルドされている
- ビルドの際に2013のランタイムが必須（VC7）
- 不具合があっても修正パッチは当たっていない
- DCM2XML
- v3.6.1 エスケープシーケンスがうまく機能しない
- SCP Core / AscServiceが社内ライブラリに強く依存している
- SCPCoreServiceをSCPCore.dllに、
- SCPCore.dllは、

## 富士プライベート仕様（シーケンスタグ）の件
- 過去の経緯
- 約15年前：HIC => SYNAPSEへ画像コンバート（石橋）
- SYNAPSEのプリセット編集が使えない
- 現地にてFMS SEより指定があった
- DCMTK3.5.4に置いて、プライベート仕様で
- 起動オプションで指定すれば解決するのでは？（笠埼）
- DCMTK3.6.5 GroupLengthが元のデータと一致しない（石橋）
- GroupLengthは既にRetiredであり、DICOM規約的には問題ないのでは？（笠埼）
- DCMTK3.6.xのDcmodifyでは問題になっていない
- DCMTKのツール間で、DATASET周りのコードが共通化されているはず
- RADACEでは数年前よりDCMTK3.6.xで問題になっていない
- SYNAPSEに対して、明示的にプライベート対応していない画像をストレージしても問題ない可能性はある

## 今後の方針
- 新たにMWMサーバーを作る案
- fo-dicomを用いる案
- 三つのアプリケーションを統合する
- ScpCore Service
- Asc Service
- MWM Responder
- メリット
- 速度
- DCMTKではテキストに起こしてからでないと、DICOMタグを触れないため遅い
- プロキシーサーバーとして成り立つ
- C,C++から解放される
- アンマネージド（C,C++）からマネージド（.NET）にコールバックをするのはしんどい
- 開発できる敷居が下がる
- デメリット？
- 新規開発になる為、コストが発生する
- コンフォーマンスステートメント
- テストの実施など

## まとめ
- 今後の方針を決めて一歩一歩するしか
1. DCMTKのバージョンをあげる案
2. 新規にMWMサーバーを開発する案

## その他検討課題
- BISは？
- HW変更の予定あり
- 三菱社がパネル生産事業を終了
- 現在ピノー社が代わりのパネルを調査中
- あまり売れていないので新規開発のうメリットは薄い
- BIS40台の案件がCOVID-19で流れた。来季以降受注になるかは未定
- ピノー社を切って、ラズパイに完全移行すること