には、部で指定したMmlModuleItemのcontentModuleTypeのDTDも記載する必要があるのでしょうか？データの参照要求を出しますのでDTDは使用しているとはいえないと思いますが、どのように定められているのでしょうか？A：MMLでは、Namespaceを使う今回の仕様を策定した時点で、すでにDTDを使うことは厳密にはできなくなっています．これは、そももそDTDがXMLNamespaceの仕様を含んだ形でXML1.0ができていないことに起因しています．（ですが、NamespaceのPrefixをMMLの仕様の中に固定することを強く推奨しているので、現在のDTDを記述できているわけです．とはいえ、Prefixを変えた文書を作成されたら、それでもうValidationはできなくなります）．MMLでは、あくまでもDTDで書けばこのようになるというだけでそれ以上の意味はありません．W3Cでは、XMLSchemaを現在作成中ですが、これができると文書のValidationがNamespaceを意識した形でできるようになります．そういうわけで、データ交換時にDTDの宣言は必要でなく（入れたとこでValidationすること自体、QueryではElementを補充して返すという仕様ですから、なければいけないElementは返答文書でしか入っていないわけでValidationはできません．）、したがって、Query文書はWelformedでありさえすればOKという仕様です．DTD宣言自体は書いても特にValidationをしないのであれば、（これはValidationをするXMLParserを使っていなければということですが）無視されるだけですので，別段あってもなくても関係ありません．（これはHTMLの文書を処理するブラウザでもそうでね．ブラウザはValidationしませんから．）最終的な回答ですが、Queryのリクエスト文書はエレメントを補完して返す仕様ですので、この場合はWelformedであることが条件で、Validationの条件は規定していません．したがってDTD宣言は必要ありません．Q：AttributeのtableIdのあるもの，ないものAttributeのtableIdですが、あるものと、ないものがあります．#REQUIREDのattributeのものだけあるのかと思うと、外部参照形式mmlCm:extRefにはtableIdのAttributeがありません．どう違うのでしょうか？A：MMLを日本国内に限らず，外国においても実装する際に，今回のMML規格書で定義されたテーブル以外のものを使う可能性が高いものについては，tableIdのAttributeを附加し，使用したテーブル名を記載できるようにしています．例えば，repCode（表記法）は，MML0025テーブル（漢字，アルファベット，ひらがな）を日本では用いますが，将来韓国で実装する場合には，MMLｘｘｘｘテーブル（漢字，アルファベット，ハングル文字）を作るだろうと予想しています．このように，将来のテーブル拡張（複数のテーブルから一つを選択して使用）を想定したものについては，tableIdの属性を設けました．全て（予約語を使用するデータ型のすべて）にtableIdをつけるという意見もありました．しかし，単なるテーブルのバージョンアップは，予約語（テーブルの値）の追加で対応し，上位互換を保つようにすることで，すべてにtableIdをつける必要は無い，との結論に達しました．なるべくシンプルに，しかし，多様性に対応できるように，というジレンマからこのような形になりました．
Q：二つの生成者情報の違いMmlModuleItem内docInfoに登場する「生成者情報」とMmlHeader内登場する「生成者情報」の違いが明確にわかりません．具体的に申しますと、最初回（患者にとっては初診です）にはM先生が診察を受け持ったため、診断履歴情報モジュールの「生成者情報」およびそのモジュールが含まれているMml文書のHeaderの「生成者情報」にはM先生の「生成者情報」が入ります．しかし次回以降違う先生が診断をした場合はそれぞれのモジュールの「生成者」情報にはM先生ではない、診断担当の先生の生成者情報が入るだろうとは思うのですがHeaderの生成者情報にはどなたの生成者情報が入るのでしょうか．カルテを一番先に作成された先生の情報なのでしょうか？規格書に記載されていたサンプルではどちらもで同じでしたのでそれが例外のケースが通常のケースががはっきりとわかりませんでしたので質問させていただきました．
A：モジュールはカルテの一文書に相当し，docInfoには，本当にそれを作成した人の生成者情報を入れます．カルテを書いたときには，必ずサインを入れるように指導されていますが，それがMMLモジュールの生成者情報です．一方，MmlHeaderは，文書の束を送るときの封筒のようなものです．いろんな人が書いた文書を束ねて，一つの封筒に入れて送るときの，差出人が，MmlHeaderの生成者情報です．よって，一人診療所のような一人でやってるところでは，同じ生成者が入るかもしれませんが，病院から文書をまとめて送るときには，MmlHeaderには送る人の情報が入ります．一つの運用形態として，病院全体の一日の全文書を，まとめて一つのMMLインスタンスに収め，バッチ処理で遠隔バックアップサーバに送るような場合は，誰が送るというものではありませんので，とりあえず病院長や医療情報担当者の生成者情報をMmlHeaderにいれることになると思います．MmlHeaderの生成者情報が重要となるのは，受けてのMMLプロセッサが，MｍｌHeaderの生成者情報を解析して，セキュリティチェックをかけるような場合と予想されます．ただし，MMLでは現時点においては，認証等のセキュリティに関してとくに規定していません．
Q：MML各モジュールの到着順位MML各モジュールの到着順位はあるのでしょうか．具体的には、たとえば「健康保険情報」のモジュールのみが「患者情報」のモジュールよりも前に、MMLインスタンスを受け取ったサーバなりDBなりに格納されているということはありえるのでしょうか．
A：モジュール間のリンクに関しては，規格書に明記しています．リンクを用いる場合は，送信先にリンク先のモジュールが存在していること，としています．Aモジュール（健康保険）とBモジュール（病名）があり，BからAにリンクが張られている（病名の適用保険）場合は，両者を同時に送るか（インスタンス内の順位は問わない），Aモジュールを先に送ることとしています．質問の例は，規格書としては，とくにダメだとは規定していませんが，当然運用的に問題が発生しますので，患者情報は，送信先に送っておく必要があります．そうしないと患者氏名も表示できませんから．MMLでは，ある目的のために，どのモジュールの組み合わせを送るのかは規定していません．これは，かなり具体的なユースケースを想定しないと，決められないからです．逆の言い方をすると，お互いに既知の送信者と受信者の間で，ユースケースに応じて，どのモジュールを送るかは取り決めておかないといけません．また，紹介状を送るような，相手が既知とは限らないケースでは，送信者は常識的に必要なモジュールを全て送る必要があります．
Q：文書レコードの意味P.37のMmlModuleItemの「内容」のついて「ユーザーのローカルデータベースにおいては、１つの文書レコードとして管理されることが想定される．」とあります．これは具体的にはどういうことを意味しているのでしょうか？たとえば、お医者様が電子カルテをお使いになる場合には、「患者情報」「健康保険情報」、、、などのモジュール単位に使用したいので当然ＤＢも各モジュール単位で１レコードとして保存するほうがよいということなのでしょうか？それともあまり意味がないのでしょうか？
A：これは，主として「経過記録情報」について述べたものでした．どのように電子カルテDBを作るかは，MMLの関知するところではありませんが，プログレスノートのような文書情報は，一人の医師の一回の記述を一レコードとして管理するのが電子保存の確定操作を行う意味でも自然だと思われます．MMLでは，それを一（経過記録）モジュールとしている，と言うことを言いたかっただけです．
Q：会計番号，社会番号 解説の意味が不明瞭な点・mmlPi:accountNumberの「会計番号」とは何を意味するのか？・mmlHi：socialIdentificationの「社会番号」は何を意味するのか？
A：ＨＬ7から引き継いだ情報項目です．日本では，当面当てはまるものはありませんが，ＭＭＬがインターナショナルを目指す以上，消してしまう必要もないので，入れています．日本では，省略して結構です．
Q：健康保険情報モジュールにおける公費の重みつけについて・mmlHi:publicInsuranceItem「公費負担」のmmlHi:priority「複数公費の優先順位」は1から始まるのか？また、値が小さいほど優先度が高いのか？
A：確かに，説明が不十分ですね．「1から始まる整数で，少ないほうが優先度が高い」と考えています．
Q：健康保険情報モジュールの継続適応疾患名について健康保険情報モジュール内mmlHi:diseases(継続適応疾患名）について質問があります．この項目は、勤めていた人が「退職時に治療を受けていた病気については手続きをすることにより、その病気に限り保険資格を延長することが可能」な「継続療養」の対象となる病名のための項目と考えてよろしいのでしょうか．それとも何か「継続疾患適応」対象の「病名」リストのようなものがあるのでしょうか．
A：前者です．とくに病名リストがあるわけではありません．常識的に，風邪が継続適応疾患になることはありませんが，あくまで常識的な判断であって，決まったリストがあるわけではありません．
Q：要求と一般的な文書の違い 要求と一般的な文書の違いは「ProcessingInstruction」があるかないかの違いでしかなく、また要求に対する返答にも<?mmlResult>部分や<?mmlItemResult>部分があるかないかの区別だけ、と考えてよろしいのでしょうか？
A：その通りです．DTD上必須のタグは，省略できません．
Q：MMLにおける文書の訂正 MMLのデータ交換規約において，「訂正文書＝APPEND要求」の考え方について、お伺いいたしたいと思います．MMLインスタンスを受け取るシステムは、訂正文書をどのように扱うのでしょうか．過去のデータ（元データ）についての「更新」なのでしょうか、それともデータをどんどん追加していく、文字通りの「APPEND」ということでよろしいのでしょうか．もしもMMLにおける「APPEND」が文字通りの「追加」であるならば過去のデータ（元データ）があるためそれらを参照することが可能になります．参照に関してはMML規格書には何も記述されていないと思いますが、規格書の内容を実現しようとするシステムにおいては、はからずして実現する機能となるのでしょうか？（そして、それはあたかも紙カルテを見ているのと同じようなルック＆フィールを実現することにもなるのでしょうか）それともシステムの運用方法による、ということになるのでしょうか．
A：厚生省の電子保存の通達により，カルテ文書の訂正は，必ず履歴を残すことになっています．よって，訂正前の過去のデータを消去することなく，訂正後の文書をAPPENDすることになります．訂正後の文書は，訂正個所（差分）のみではなく，それだけでも完全な文書でなければならなりません．書籍に，｢初版」，「第二版」，「第三版」とあるのと同じことです．過去のデータの参照は，可能としておくべきです．実装システムの訂正文書の見せ方は，実装者の判断に委ねられます．・訂正前の文書も全て見せる．・訂正前の文書は，必要に応じて，何らかのアクションがあったときにのみ見せる．・訂正前の文書と訂正後の文書の差分を取り，訂正前文書に差分を（赤字や取り消し線を用いて）追加する．などが考えられますが，MMLとしては，どれが良いと言う記載はしません．
Q：MMLにおける文書の削除文書の訂正が「訂正文書のAPPEND」で行われるとするならば、文書の「削除」要求はどのようなケースが想定されているのでしょうか．カルテの改ざんは違法であり、カルテの保存期間も法律で制定されていたと思います．だとするならば、MML文書「削除」というのは、例えば、患者が死亡し、またその患者のカルテ保存期間も経過した、というようなケースを想定しているのでしょうか．日常的に頻繁に出力する要求ではないと考えてよろしいのでしょうか．
A：削除要求は，通常の電子カルテ管理においては，使いません．規格書では，運用に関しては関知しないため書きませんでしたが，削除はシステム管理上のコマンドとして用意しただけであって，一般ユーザが使うことを想定していません．管理者が，不適当を思われる文書を発見したときに（たとえばシステムのバグ等により記録されてしまったとき），電子カルテ保存とは違う観点で，削除の必要を認めたときに使うことを想定しています．よって，MMLのコマンドとして用意しておくことには異論があるかもしれません．運用については，事例を積み重ねることにより，規格書とは別の次元で，「規則」が生まれていくものと考えています．「規格は規格であり、それを実現する形は問わない」という事なのですが，あまり運用での判断が多すぎると，規格としての意味がありませんので，通常の電子カルテの運用では，DELETEコマンドは用いない，と言うことを明確にしておかなければならないと考えています．MMLの運用面での取り決め（裁判で言う判例）を，FAQの形で公開したいと思います．
Q：reqIdとuidについてreqIdとuidについて．この二つのIdはMMLインスタンスを出力する側がMMLインスタンスに対して付与するものなのでしょうか、それともインスタンス出力先の患者のデータを管理する、例えばサーバなどがMMLインスタンスを入力してくる個々のシステムに対して付与するものなのでしょうか？もしも出力する側が個々に上記Idを付与してMMLインスタンスを出力した場合、可能性はとても低いとは思いますが、Idが他のシステムが出力したMMLインスタンスと同じになってしまうという可能性はないのでしょうか？
A：出力する側が設定します．このIDは，UUID（GUIDとも言う）を用いることとしています．これは，Macアドレスと時刻（ミリセカント）から自動的に発生させるIDで，全世界のコンピュータが勝手に設定しても，同じIDが振られる確立は，限りなく0に近いといわれています．UUIDを用いずに，勝手な方法で譜番すると，重なるかもしれません．これは，MMLの規格違反と言うことになります．Q：ＵＵＩＤは16バイト？32バイト？ ＵＵＩＤは下記ＵＲＬの解説では，http://home.impress.co.jp/magazine/dosvpr///ryakugo98/u3.htm「UUID Universally Unique IDentifierオブジェクトを識別するために使われる16 byte （128 bit ）の ID ． GUIDとも．日時と ネットワークカード の MACアドレス（あるいは乱数）を組み合わせ、自動的に一意の IDを生成する．」すなわち，UUIDは16バイトとあります．32バイトではないのですが，32が正しいのでしょうか？
A：binaryだと16byteです．XMLに書くときはBinaryで書くことができないので、文字列に変換すると32文字プラスハイフンの長さになります．
Q：Data ExchageSpecificationにおけるサンプルインスタンスの記載ミス Data ExchageSpecification P5のmmlQueryコマンドを用いたデータ照会要求の例にはの中身としてのみが（タグが開始と終了で異なっていますが）入っていますが、本来であればの情報として必要な要素、例えばcreatorInfoなども本当は必要である、ということなのでしょうか？省略されているということなのでしょうか？同様にP6「mmlAppend」についてもには部分しか存在しませんが本来は存在するのでしょうか？またP7「mmlDelete」についても同様なのでしょうか？A：サンプルデータが間違いであり，MMLインスタンスである以上，MMLのDTDに則る必要があります．Q：リクエストにおけるの必要性リクエストに基づきデータを返す場合にはは満たす必要がないと考えてよろしいのでしょうか．A：サンプルインスタンスが，実例に基づいて作成されていないため，必要な部分を省略してしまっているようです．お詫びします．返しの電文は，MMLインスタンスである訳ですから，当然必須エレメントであるは満たす必要があります．