---
# System prepended metadata

title: 品質強化プロジェクト（次期DICOMライブラリ情報共有会）
tags: [Meeting]

---

品質強化プロジェクト（次期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で流れた。来季以降受注になるかは未定
  - ピノー社を切って、ラズパイに完全移行すること


