Ver.2011-03-23

久しく MML light プロジェクトを中断していましたが「やはりこのようなものが必要」という思いに駆られ、さらに削り落としたものを考えることにしました。少しずつ考えながら記述していくので未完成、途中で変化してゆく可能性があります。

このバージョンの基本的考え

    1. JSON 形式を使う:以前のバージョンでは JSON を多少モディファイした形でしたが、やはり「デファクト・スタンダードには素直に従うべき」ということで、オリジナルの JSON を採用することにしました。「速やかに普及するのはシンプルなもの」「シンプルなものは頑丈」「シンプルなものは想定外のものにも柔軟に対応」ということですが、データを記述する規格として世の中で広く使われているの中でもっとも単純なものの一つが CSV です。しかし CSV ではオブジェクトを記述できません(できないことはないでしょうが、極めて複雑になってしまい本末転倒)。JSON を採用した理由は「シンプルかつオブジェクトを記述できる」ことです。「XML より JSON の方が冗長度がずっと少ない」というのも採用の理由です(JSON を XML へコンバートするのは極めて容易)。

    2. タグは MML の規格を使う:すべてのオブジェクトは key:value の組み合わせで表現できると考えており、JSON 採用の理由もここにありますが、問題は key をどのようにするかです。以前のバージョンでは人間の可視性に重きを置いて patientName とか birthDay のようなタグを用いていましたが、やはり何らかのスタンダードなテーブルに基づいたタグ付けをした方が良いだろうということ。そのような意味では、規格をすべて公開している MedXML の MML を当面使うことにしました。将来はヘッダー部分でテーブルを指定することにより、他のテーブルでの記述もできるようにしたいと考えます。また、通信相手の方で支障なければ、以前のバージョンのように "patientName" や "birthDay" のような表現も可としたいと思います。

    3. 構造化と断片化:基本的には「ある受診者データを塊として他のシステムへ渡す」ことを考えていますが、用途によっては「その中の一部のデータだけの受け渡しもしたい」ということもあるかと思います。その場合はどう表現するか、についても考えて行きたいと思います。基本的には単なる箇条書きのように無構造の書き方も可としますが、関連のあるものをまとめた階層構造で表現する方が冗長度も低く効率的で、こちらの書き方を推奨します。

ここで述べたことは、個々の事例で具体的に説明します。