・以下のような翻訳サービスを考えていましたが MMLL では不要のようです
実際に MMLL を扱うエディターを作りそれを取り扱ってみると、このエディターの中で MMLL で規定されたタグを、自施設用の名称に置き換えて使うことが極めて簡単にできることがわかりました。従って、以下の翻訳サービスは MMLL を使う限りにおいて不要であることがわかりました。
・標準規格を強制するより Data Mapping：翻訳の方が現実的
MedXML が立ち上がった頃、医療情報学会をはじめ世の中は「医療情報を異システム間でやりとりするには、皆が標準規約コードを使う必要がある」という考えが一般的でした。その考えのもとに幾つかの標準規約が作られ、夫々が夫々の世界で或る程度使われましたが、全体に普及し広く使われることなく現在に至っています。
「この考え自体、現実に則さない無理があるのではないか」と考えるようになりました。
では、どうすれば良いのだろうと、、
人間の世界で異なる人種同士がどう意思疎通しているかというと「全体が英語を使う」場合もありますが、これでは少数民族は蚊帳の外になってしまいます。そこで現実には「翻訳（通訳）」しながら意思疎通を行います。
すなわち「異システム同士でデータをやりとりするには翻訳すればよいではないか」という考えに至りました。
A システムで「female」というコードをBシステムでは「女」と記述しています。夫々の環境では、そのような呼び方が使いやすいからでしょう。そこでAシステムのデータをBシステムが受け取ったら翻訳します。B内で翻訳してもよいし、A内でB用に翻訳したものを送る、途中に翻訳システムが介在、など色々あってよい。
・翻訳サービスの考え
インターネット上の「翻訳サービス」を利用できれば理想的と考えます。
翻訳センターで持つデータ構造はどのようにすればよいでしょう。
例えば「個人名」などをひとつのオブジェクトと考え以下を説明します。
あるオブジェクトに関し以下のような情報を持てばよいのでしょう。
・オブジェクトの 標準的タグ名（なるべく短く簡潔で理解しやすいものが理想的）
・そのオブジェクトに関する説明（誰が読んでもそのオブジェクトを間違いなく正しく認識できる参考情報）
・そのオブジェクトの別名とそれを定義したシステムや施設情報（例えば mmlAd:fullname と MML3.0 ）
新たな定義システムや施設が加わるごとに、オブジェクトの別名を追加していきます。
新たな定義の追加作業はちょっと手間ですが、それはやむを得ないでしょう。
Bシステムが、初めてAシステムから文書を受け取った時、Bは「翻訳サービス」にアクセスして、送られてきた文書の全てのタグを自施設のタグに変換します。人間の目による確認作業も必須でしょう。しかし手間のかかるのは初回のみです。次からはBシステムが 翻訳結果を記憶し自動翻訳 となるので、何の手間もかからなくなります。翻訳システムへのアクセスも不要となります。
翻訳サービスはひとまず、単語から単語の翻訳だけを考えています。
構文解析などのサービスは次の段階、文書構造を含めた変換は当面 人の手によるものとします。
しかしこれも一旦テンプレートを作成してしまえば、後は自動的にそこへ流しこむだけ。
A・B間の変換用テンプレートを翻訳センターへ登録する考えも有りかも知れません。
・文書構造は必要か
自動翻訳する場合、おそらく 翻訳作業を複雑化 するのが 文書構造の差異 と思います。
同じ医療データの記述であっても、施設ごとに好む構造が異なることは容易に想像できます。
すなわち 翻訳メカニズムの簡素化 のためにも、文書構造にはあまりこだわらない 方が得策と考えます。
人がしゃべる内容を見ても、構造は夫々まったく違いますが、ほとんどの場合意味は通じていますね。
ただし、意味が間違いなく正しく伝わるよう最低限の構造化 は必要と思われます。
例えば name だけでは何の名前か判りませんが Facility.name とあれば「ああ、施設名だな」と判ります。
そのような意味で、翻訳センターには Facility.name という塊として記憶する必要もあるのかも知れません。
Facility が無くても人間は文脈から「施設名だろう」と類推しますが、当面そこまで利口ではないとします。
Update: 2011-04-07