Office オープン XML 形式を使用した、電子医療記録ポータビリティおよびヘルスケア業界標準のサポート

概要 : Office オープン XML 形式および HL7 CDA を使用して、医療データを業界標準形式で安全に送受信します (24 印刷ページ)。

Ted Pattison、Chris Predeek、Ted Pattison Group (英語)

Chris Predeek、Ted Pattison Group (英語)

Wouter van Vugt、Info Support (英語)

2007 年 10 月

適用対象 : 2007 Microsoft Office System

サンプル ファイルのダウンロード : 2007 Office Sample: Using the Office Open XML Formats to Support Electronic Health Records Portability and Health Industry Standards (英語)

目次

• 概要

• 顧客シナリオ

• コードの概要

• 標準の概要

• Office オープン XML 形式のアーキテクチャについて

• Open Packaging Conventions 仕様を利用する

• XSLT を実装する

• オープン XML SDK を使用する

• ドキュメント構造について

• XML データ ストアを作成する

• オープン XML ファイル形式のデジタル署名

• まとめ

• 作成者について

概要

患者および消費者が電子医療記録を安全に送受信できるようにすることは、世界中のヘルスケア業界での大きな課題となっています。ここでは、安全なデータ交換のために、Office オープン XML 形式およびカスタム XML 形式の使用方法を学習します。ここで取り上げるシナリオでは、HL7 (Health Level Seven) の CDA (Clinical Document Architecture) を使用して、電子医療記録を業界標準形式で記述する方法を示します。また、複数の医療従事者間でのポータビリティのために、Office オープン XML 形式に基づいてセキュリティ保護されたドキュメントにデータを格納する方法についても示します。

顧客シナリオ

最近新しく引っ越してきた安田さんは、新しいかかりつけ医に申し込もうと考えました。医療機関として選択したのは、Contoso, LLC です。Contoso は、医療分野だけでなく、テクノロジの採用と顧客へのサービス提供についてもリーダー的な機関です。将来来院する可能性のある顧客は、単純なフォームに記入するだけで、安全にオンラインで登録でき、現在治療中の患者は、自分の診療記録のコピーを安全にダウンロードできます。安田さんは、登録フォームに情報を記入します。記入した情報は、自動的に抽出されて Contoso のシステムに格納され、初めて患者として来院したときに確認されます。安田さんが何年にもわたって Contoso で日々の診療を受けるうちに、Contoso の電子医療記録 (EHR: Electronic Health Record) システムに安全に格納された診療履歴が多数蓄積されていきます。紙ベースのシステムで診療記録を保持している他の多くの医療機関と異なり、Contoso では、患者が業界標準形式を使用して自分の診療記録をエクスポートできる EHR システムに投資しています。診療記録には HL7 CDA が使用され、Office オープン XML 形式に基づきデジタル署名されたドキュメントによってビジュアルな表示と安全な転送が可能です。HL7 CDA 形式の診療記録が持つ豊富な情報と意味内容を完全に保持しながら、患者は表示および印刷に適したリッチな形式でこのドキュメントにアクセスできます。

技術的な観点で見ると、これらの診療記録のデータは、Contoso の EHR システムに格納されます。安田さんのような患者が、安全な Web サイトから診療記録のコピーをダウンロードするためのリンクをクリックすると、HL7 CDA が動的に (必要に応じて複数のデータ ソースおよびシステムから) アセンブルされ、ドキュメントに埋め込まれて患者のデスクトップにダウンロードされます。

安田さんは、Microsoft Office Word 2007 を使用して、自分の診療記録を表示し、必要に応じて保存用に印刷できます。また、ドキュメントを電子的にバックアップして、他の重要な記録と共に保管しておくこともできます。自分の診療記録を完全に管理できることで、安田さんは家族または他の医師や組織などと記録を共有することもできます。診療記録は、医師のオフィスに保存されている内容のコピーであるため、ドキュメントを更新したり改ざんしたりすることはできません。そのような行為を行うと、Contoso の Web サイトからダウンロードされる前に医療記録に適用されていたデジタル署名が壊れます。

安田さんが自分の診療記録を他の組織と共有する場合、その組織のシステムでは、ドキュメントが改ざんされていないこと、および埋め込まれた HL7 CDA ドキュメントがダウンロード時点またはアセンブル時点での診療記録の正確なスナップショットを反映していることを確認できます。

安田さんは、オンラインの個人健康記録 (PHR) サービスに登録することに決めました。このサービスを選んだのは、Office オープン XML 形式に基づくドキュメントに埋め込まれた形で HL7 CDA 形式の診療記録を受け取ることができるからです。この機能を利用すると、安田さんの診療記録が Contoso から厳密に完全な形で転送されるため、情報を再入力する手間がかからず、入力ミスの可能性も回避できます。PHR サービスにより、安田さんは自分の診療記録を個人的に閲覧し、自分の健康をより効果的および積極的に管理できるようになります。アップロード プロセス中に、ドキュメントは検査され、デジタル署名が確認されます。ドキュメントが、PHR サービスに対する既知の組織 (Contoso など) によりデジタル署名されていて、そのデジタル署名が正しく確認されれば、HL7 CDA を抽出して PHR サービス システムに格納することができます。デジタル署名によって正しく確認されることで、PHR サービスでは、これらの診療記録が Contoso によって提供されたものであり、改変されていないということを高い信頼性で確認できます。

コードの概要

この記事には、このシナリオのサンプル実装を含む Microsoft .NET Framework ベースのソリューションが付属しています。詳細については、「2007 Office Sample: Using the Office Open XML Formats to Support Electronic Health Records Portability and Health Industry Standards (英語)」を参照してください。

2 つの Web サイトがあります。1 つは医師向けでもう 1 つが PHR サービス向けです。あなたが安田さんであると仮定すると、実際に Contoso に登録し、自分の診療記録をダウンロードできます。これらの記録は、ドキュメントの整合性を保証するため、医師によって署名されています。署名の整合性は、Office Word 2007 を使用して簡単に確認できます。確認後、記録をオンライン PHR サービスに送信できます。

HL7 CDA を格納する方法は、場合により異なります。たとえば、ドキュメントを分解して診療記録の各要素をデータベースに格納することができます。または、XML ドキュメント全体を格納し、必要に応じて要素を抽出することもできます。この例では、HL7 CDA がそのまま格納され、HL7 の CDA 標準で提供される標準 XSLT を使用して内容が表示されるようになっています。このシナリオで使用されるサンプル データ、およびサンプル コードは、HL7 標準に含まれるサンプル CDA ドキュメントから得られたものです。

標準の概要

ここでは、このソリューションの実装に使用される標準について説明します。

Office オープン XML ファイル形式

2007 Microsoft Office system は、ドキュメント、スプレッドシート、およびプレゼンテーションについて、Office オープン XML 形式という新しいマークアップ言語標準に準拠しています。Office オープン XML 形式の標準の詳細については、「TC45 - Office Open XML Formats (英語)」を参照してください。また、このファイル形式は、仕様とライセンスのダウンロード に基づいており、XML Paper Specification (XPS) でも使用されています。Office オープン XML 形式の標準では、ドキュメントを使用して実行される多くの異なるタスクを簡単にするようデザインされたドキュメント マークアップ標準が提供され、ドキュメント内でビジネス関連データを表現するためのモデルも提供されます。この標準には、障碍を持つユーザーでもドキュメントを利用できるようにするユーザー補助サポートなど、さまざまな機能が含まれています。Office オープン XML 形式は、複数の商用およびオープン ソースの生産性スイートに実装されています。Office オープン XML 形式を、ドキュメントにカスタム XML データを埋め込む機能と組み合わせることで、ドキュメントをヘルスケア業界で利用できるようにする魅力的なチャンスが生まれます。標準化プロセスにより、ドキュメントの使用期間全体にわたって透明性と互換性が保証されます。

ヘルスケア業界の組織では、患者のカルテ、退院時の情報、紹介状、処方箋など、多くの臨床ドキュメントを長期間にわたって作成および管理する必要があります。診療記録を電子形式で管理するためのどのようなテクノロジも、持続的である必要があります。導入後すぐに使用中止されるようなテクノロジでは、情報へのアクセスに関して問題が生じます。Office オープン XML 形式は国際標準です。そのため、ドキュメントの保持についての課題や、ドキュメントの記述に使用される形式などの問題が軽減されます。Office オープン XML 形式の標準とそれに付随する仕様を、構造化情報に対する HL7 CDA などの業界標準と組み合わせて使用することで、だれもがそのような診療記録の持続的な表現を作成できます。これらの標準により、病院や PHR サービスなどの組織間で相互運用が可能になると同時に、消費者が自分の診療記録を管理するうえで積極的な役割を演じられるようになります。

患者記録や研究結果などの機密性の高いデータを処理および格納する際のもう 1 つの重要な側面は、データが改ざんされていないことを保証することです。不正な変更の検出を簡単にするために、Office オープン XML 形式では、ドキュメントの内容に署名するための精巧な構造を用意しています。X509 証明書などの業界標準を使用するか、またはカスタム実装を使用できます。

Office オープン XML 形式では、コアの文書パーツとして業界標準を使用し、それに基づいてドキュメント作成用のリッチな環境を構築しています。これらのテクノロジは、どのプラットフォームでも使用できます。ドキュメントは、ZIP コンテナ内にアセンブルされた XML ファイルから構成されます。この XML データのほとんどは、3 つのマークアップ言語のいずれかで表現されています。これら各言語の名前は、単純なパターンに従っています。WordprocessingML は、ワープロ ドキュメントの内容を定義します。SpreadsheetML はスプレッドシート ドキュメントの内容を定義し、PresentationML はプレゼンテーションの内容を定義します。これらに加えて、図、グラフ、表などを定義するための共通言語を提供する DrawingML などのサポート言語があります。

図 1. オープン XML 標準のメイン コンポーネント

ドキュメントの内容を定義するための構造に加えて、Office オープン XML 形式では、ドキュメント内でビジネス データを表現するためのいくつかのテクノロジを提供しています。この形式とビジネス データの組み合わせによって、優れた顧客ソリューションを実現できます。Office オープン XML 形式以前には、一般にビジネス関連データは、通常のドキュメント コンテンツとして格納されていました。患者番号や処方箋などのデータを取得するための標準的なアプローチは、ドキュメントをプログラムで開き、段落 3 つ分を検索し、目的のデータを表す最初の斜体テキストを見つける、などの方法でした。このアプローチには、明らかな欠点があります。ドキュメントの形式を整えたり、同じデータに新しいテンプレートを適用したりすると、コードが壊れ、それを改訂する必要が生じます。Office オープン XML 形式を使用すれば、太字や斜体などの構造化ビジネス データが持つ書式を定義するリファレンス スキーマを結合できます。患者番号の書式に基づいてアクセスする代わりに、患者番号に直接アクセスできます。追加の利点の 1 つは、データをメイン ドキュメント本体の外部で保持できるため、ドキュメントからの抽出や埋め込みの際に簡単にアクセスできることです。

図 2. 書式指定によるデータの特定とコンテンツ コントロールによるデータの特定

HL7 (Health Level Seven) CDA (Clinical Document Architecture)

HL7 (Health Level Seven) は、ヘルスケア情報通信テクノロジの分野で全世界的に活動している多くの標準開発組織 (SDO: Standards Development Organization) の 1 つです。HL7 は、1980 年代に臨床統合に関する標準の策定作業を開始しました。今日では、ヘルスケア関連の標準策定で最も成功した組織の 1 つとなっています。HL7 は、世界中で最も広く使用されている臨床情報交換標準のいくつかを保持しています。具体的には、HL7 Messaging Version 2、HL7 Version 3、および CDA (Clinical Document Architecture) です。

HL7 CDA は、XML に基づくドキュメント マークアップ標準です。HL7 Version 3 の RIM (Reference Information Model) では、交換の目的のために、ドキュメント内の各データ要素の構造と意味の両方を指定しています。HL7 CDA は主に、退院時の情報、紹介状、ディクテーション レポートなどの臨床ドキュメントに使用されます。

CDA が 2005 年に ANSI 標準として承認されてから、その開発に従事する HL7 委員会は、一般的に使用される臨床ドキュメントに対する再利用可能なテンプレートおよび制約を作成することに、焦点を合わせてきました。この作業の最初の成果が、この記事に付属のサンプル コードで患者の個人健康記録を表すために使用した CCD (Continuity of Care Document) です。

HL7、CDA、および CCD の詳細については、Health Level Seven (英語) の Web サイトを参照してください。

Office オープン XML 形式のアーキテクチャについて

この新しいファイル形式コンテナは、単純なパーツ ベースの圧縮 ZIP ファイル形式仕様に基づいています。新しい Office オープン XML 形式のコアとなるのは、XML リファレンス スキーマと ZIP コンテナの使用です。各ファイルにはさまざまな数のパーツの集合が含まれ、この集合がドキュメントを定義します。

ドキュメントの各パーツは、業界標準の ZIP 形式を使用して、コンテナ ファイルまたはパッケージに格納されます。ほとんどのパーツは XML ファイルで、アプリケーション データを表すものもあれば、メタデータやユーザー データを表すものまであり、すべてコンテナ ファイル内に保存されます。画像を表すバイナリ ファイルやドキュメントに埋め込まれた OLE オブジェクトなどの XML ではないパーツも、コンテナ パッケージ内に保存されます。また、パーツ間の関係を指定するリレーションシップ パーツもあり、このデザインによって Office ファイルの構造が形成されます。パーツがファイルのコンテンツを構成し、コンテンツの各部がどのように協調して動作するのかをリレーションシップが表します。

詳細については、次の情報を参照してください。

• Office (2007) Open XML ファイル形式の概要

• 方法 : Office オープン XML 形式のドキュメントを操作する

• ウォークスルー : Word 2007 XML 形式

新しいファイル形式の内部を見るための簡単な方法は、Word 2007 のドキュメントを新しい既定の形式で保存し、そのファイルの拡張子を .zip に変更することです。ファイルをダブルクリックして開き、その内容を表示します。

Word XML 形式のファイルを Word 2007 で開くには

1. ファイルとそのパーツを保存するための一時フォルダを作成します。

2. (テキストや画像などを含む) Word 2007 ドキュメントを .docx ファイルとして保存します。

3. ファイル名の末尾に拡張子 .zip を追加します。

4. ファイルをダブルクリックします。ZIP アプリケーションでファイルが開きます。ファイルに含まれているドキュメント パーツが表示されます。

5. 作成したフォルダにパーツを抽出します。

図 3. イメージおよび埋め込みオブジェクトを含む Word 2007 ドキュメントの階層的ファイル構造

Open Packaging Conventions 仕様は、新しいファイル形式を使用した Word 2007 ドキュメントの構造を定義します。Open Packaging Conventions の詳細については、「仕様とライセンスのダウンロード」を参照してください。これは XML Paper Specification でも使用されています。また、最近リリースされた Java ベースのバージョンもあります。OpenXML4J は、Office オープン XML (ECMA-376) および OPC ベースのドキュメント (たとえば、Microsoft Office Word 2007、Microsoft Office Excel 2007、および Microsoft Office PowerPoint 2007 のドキュメント) の作成および操作専用の Java ライブラリです。OpenXML4J を使用すれば、Microsoft Office スイートを使用しなくても、多くのscenariosに対してオープン XML ドキュメントの作成および操作が可能になります。詳細については、「OpenXML4J Project: Office Open XML File Format library for Java」を参照してください。

この記事では、サンプル ドキュメントとして "Hello World" の例を使用しています。ウォークスルーでは、Packaging API を使用して、XML と ZIP の低レベルの詳細を処理しています。この Hello World ドキュメントには 3 つのパーツが含まれ、そのうちの 2 つだけを手動で作成します。最初に、"Hello World" というテキストを格納するドキュメント パーツを作成します。WordprocessingML では、別のドキュメント パーツを使用してこのデータを格納します。次に、リレーションシップ パーツを作成し、データを含むドキュメント パーツとパッケージとの間のリレーションシップを作成します。最後に、Packaging API でコンテンツ タイプのリストを作成します。このコンテンツ タイプ リストは、パッケージ内の各ドキュメント パーツの内容を識別します。Packaging API は ZIP の詳細を抽象化するだけなので、System.Xml を使用し、"Hello World" テキストを形成する XML マークアップを手動で作成する必要があります。

図 4. "Hello World" テキストの XML マークアップ例

以降のセクションでは、Office オープン XML 形式アーキテクチャの主要なコンポーネントについて説明します。

コンテンツ タイプ

最初の重要な概念は、コンテンツ タイプ リストです。ドキュメント コンテナのルートには、[Content_Types].xml という名前のドキュメント パーツがあります。このドキュメント パーツは一意であり、パッケージ内の他のすべてのパーツに対するコンテンツ タイプ文字列の辞書を格納しています。コンテンツ タイプは、パーツ内に含まれるコンテンツの種類をユーザーに示すものです。バイナリ データと XML データが区別されますが、パッケージ内のパーツのほとんどは XML を使用して定義されているため、XML データはさらに複数のタイプに分類されます。コンテンツ タイプは、2 つのモデルを使用して定義できます。特定のファイル名の拡張子に既定のコンテンツ タイプを関連付けるか、または、コンテナ内のパッケージ パーツの位置に基づいてこの既定のコンテンツ タイプを変更できます。次のコード例に、単純なコンテンツ タイプ リストを示します。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Types xmlns="http://schemas.liquid-technologies.com/OfficeOpenXML/2006/default.html">
    <Default
        Extension="rels"
        ContentType="application/vnd.openxmlformats-package.relationships+xml"/>
    <Default
        Extension="xml"
        ContentType="application/xml"/>
    <Override
        PartName="/word/document.xml"
        ContentType="application/vnd.openxmlformats-…
            …officedocument.wordprocessingml.document.main+xml"/>
</Types>

リレーションシップ

ZIP コンテナ内では、拡張子 .rels を持つ別の XML ファイルが _rels というフォルダに常に格納されています。これらのリレーションシップ パーツは、ドキュメントの各種パーツを互いに関連付けます。パッケージ パーツ間のリレーションシップを各パーツそれ自体にインラインで格納する代わりに、リレーションシップ パーツ モデルが使用されています。どのドキュメント パーツも、リレーションシップを使用して他の任意のパーツと関連付けることができます。これには、循環的なリレーションシップも含まれます。リレーションシップ モデルにより、パッケージから特定の要素を参照する必要のあるアプリケーションの作業負荷が大きく軽減します。ヘッダーを見つけるために大きなドキュメントの内容全体を解析する必要はありません。その代わり、リレーションシップ パーツによってこの情報が提供されます。これは、Office オープン XML 形式に基づくパッケージの使用に関する非常に重要な側面の 1 つです。リレーションシップ パーツにより、パッケージ内での任意のパーツの位置を各ユーザーの好みに基づいて変更できます。パッケージ内のパスは静的ではありません。ドキュメントのバージョンごとに、またはドキュメントを異なる生産性アプリケーションで変更した場合に、パスは変化する可能性があります。常に、リレーションシップを使用して作業することが必要です。

リレーションシップには、4 つのデータが格納されます。各リレーションシップには、固有のリレーションシップ ID が使用されます。この ID は、リレーションシップの各ソースについて固有である必要があります。次に、リレーションシップ タイプを適用します。これは、パッケージ内でドキュメント パーツを検索するために使用できる第 2 のモデルです。WordprocessingML ベースのドキュメントの場合、ヘッダーとフッターはリレーションシップ タイプに基づいて配置されます。埋め込みイメージは、リレーションシップ ID を使用して検索されるドキュメント パーツの例です。リレーションシップには、それが指し示す場所のターゲット URI が格納されています。この URI は、パッケージの内部でも外部でもかまいません。これは、次のコード例に示すように、リレーションシップ マークアップ内のフラグによって示されます。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Relationships
    xmlns="http://schemas.liquid-technologies.com/OfficeOpenXML/2006/default.html">
    <Relationship Id="rId1"
        Type="http://schemas.liquid-technologies.com/OfficeOpenXML/2006/default.html
        2006/relationships/extended-properties"
        Target="docProps/app.xml"/>
    <Relationship Id="rId2"        Type="http://schemas.liquid-technologies.com/OfficeOpenXML/2006/default.html
        2006/relationships/officeDocument"
        Target="word/document.xml"/>
</Relationships>

オープン XML 仕様では、2 つのタイプのリレーションシップが定義され、これらは常に拡張子 .rels のファイルに格納されます。ソース パーツが定義されているリレーションシップと、定義されていないリレーションシップがあります。

ソース パーツの定義されていないリレーションシップは、パッケージ レベルのリレーションシップです。パッケージ全体をリレーションシップのソースと考えることができます。パッケージ レベルのリレーションシップは、パッケージ内の検索を開始するときに使用されます。これらのリレーションシップは、常に特定のリレーションシップ ファイルに格納されています。具体的には、_rels/.rels ファイルです。この場所は変更できません。Office オープン XML 形式に基づくドキュメントのほとんどには、少なくとも 3 つのパッケージ レベルのリレーションシップが含まれています。コア プロパティ用に 1 つ、アプリケーション プロパティ用に 1 つ、および開始パーツと呼ばれるパッケージ内の特殊なパーツの検索用に 1 つです。このリレーションシップは、ドキュメントの解析を開始する場所を示す特定のタイプを持っています。このリレーションシップは、開始パーツと呼ばれるパッケージ パーツを指し示します。開始パーツの検索に使用されるリレーションシップ タイプを次に示します。

http://schemas.liquid-technologies.com/OfficeOpenXML/2006/default.htmlrelationships/officeDocument

開始パーツは通常、スタイルやテーマなど、他のドキュメント コンテンツを含んでいるパーツを示すリレーションシップを定義します。このリレーションシップはソース パーツ内で定義されるため、アイテム レベルのリレーションシップと考えられます。これらのアイテム レベルのリレーションシップは、ソース パーツの場所を基準とした _rels サブフォルダに格納されます。各リレーションシップ ファイルの名前は、関係付けられるパーツの完全なファイル名に拡張子 .rels を追加したものになります。たとえば、document.xml というパーツのリレーションシップ パーツは、document.xml.rels という名前になります。

図 5. パッケージ リレーションシップとドキュメント パーツ

Open Packaging Conventions 仕様を利用する

Open Packaging Conventions では、ファイル構造の定義に同じ概念を使用しています。Package クラスは、オープン XML パッケージ全体を定義します。PackageRelationship は、1 つのリレーションシップを定義します。PackagePart クラスは、パッケージ内のパッケージ パーツをカプセル化します。

サンプル ドキュメントを作成するには、Packaging API の 3 行のコードと、"Hello World" テキストを表示する WordprocessingML マークアップを生成するためのいくつかのコードが必要です。

パッケージを作成する

最初の手順は、パッケージの作成です。これには、Package クラスと、静的な Open メソッドを使用します。このメソッドは、新しい Package インスタンスを返します。

class Program
{
    static void Main()
    {
        using (Package package = Package.Open("Sample.docx", FileMode.Create))
        {
            // The rest of the code goes here.
        }
    }
}

メイン ドキュメント パーツを作成する

パッケージを作成した後、次の手順はメイン ドキュメント パーツの作成です。ドキュメント パーツは、開いているパッケージの CreatePart メソッドを呼び出すことで作成します。パーツを作成するには、最初に、新しいパーツを格納するためのパッケージ内の固有の場所を指定します。この場所は URI を使用して特定します。場所が既に使用中である場合は、例外がスローされます。CreatePart メソッドの第 2 のパラメータは、新しいパーツのコンテンツ タイプ定義です。これにより、パッケージ内の [Content_Types].xml リストが自動的に更新されます。これを手動で行う必要はありません。

PackagePart mainPart = package.CreatePart(
    new Uri("/document.xml", UriKind.Relative),
    "application/vnd.openxmlformats-
     officedocument.wordprocessingml.document.main+xml");

リレーションシップを作成する

最後の手順は、メイン パッケージ パーツを指し示すリレーションシップの作成です。このリレーションシップは、ソース オブジェクトの CreateRelationship メソッドを呼び出すことで作成します。ソースがパッケージである場合は、package.CreateRelationship を呼び出します。ソースが他のドキュメント パーツである場合は、mainPart.CreateRelationship を呼び出します。たとえば、mainPart に他の子パーツとのリレーションシップが必要だとします。指定するデータは 3 つあります。まず、URI 値を使用して、相手パーツを指定します。次に、この相手パーツがパッケージの内部にあるか (TargetMode.Internal)、または外部にあるか (TargetMode.External) を指定します。この 2 番目のターゲット モードは、ハイパーリンクや他の外部リンクに対して使用します。さらに、最後のパラメータとしてリレーションシップ タイプを指定する必要があります。後でこのリレーションシップ タイプを使用して、パッケージ内を参照できます。

PackageRelationship mainRelationship = package.CreateRelationship(
    mainPart.Uri, 
    TargetMode.Internal,
    "http://schemas.liquid-technologies.com/OfficeOpenXML/2006/default.html
    relationships/officeDocument");

System.Xml を使用する

パッケージの詳細を処理した後は、次の手順として、メイン ドキュメント パーツにコンテンツを格納します。Hello World の例には基本的な階層が含まれています。<document> タグがルートです。次に、ドキュメントの本文を含む <body> があります。本文は、段落や表などのブロック レベルの内容を使用して構成されます。段落には、<r> で示されるランが含まれます。ランは、<t> で示されるテキスト片に分割されます。このモデルを使用する理由は、ランが書式設定を適用できる最低レベルの要素であるためです。ランには、改行コード (<cr />) などの印刷されない文字も含めることができます。

Open Packaging Conventions API では、Office オープン XML 形式の XML の詳細は実装されていません。パーツのコンテンツは Stream オブジェクトとして提供されます。XmlWriter インスタンスを使用して、このストリームに XML を書き込むことができます。ここで、重要な考慮事項が 1 つあります。ドキュメントのテキストを構成するノードはすべて、WordprocessingML 名前空間に存在する必要があります。

http://schemas.liquid-technologies.com/OfficeOpenXML/2006/default.html

次のコード例を使用して、1 つの段落を含む基本的なドキュメントを作成できます。

string xmlNamespace =      "http://schemas.liquid-technologies.com/OfficeOpenXML/2006/default.html";
using (XmlWriter writer = XmlWriter.Create(
    mainPart.GetStream(FileMode.Create, FileAccess.ReadWrite))) {
    writer.WriteStartDocument();
    writer.WriteStartElement("w", "document", xmlNamespace);
    writer.WriteStartElement("w", "body", xmlNamespace);
    writer.WriteStartElement("w", "p", xmlNamespace);
    writer.WriteStartElement("w", "r", xmlNamespace);
    writer.WriteStartElement("w", "t", xmlNamespace);
    writer.WriteString("Hello World");
    writer.WriteEndDocument();
}

System.Xml の代替手段

ここでは、コードを使用せずにドキュメントを生成するための代替手段について説明します。

XSLT を実装する

XML 関連コードを使用してドキュメント全体を生成するのは、面倒なプロセスです。ごく単純なドキュメントを生成する場合でも、たくさんのコードを保持する必要があります。100% コードを使用して大きなドキュメントを作成する代わりに、2 つの主要なソリューションを利用して困難を軽減できます。ドキュメント テンプレートと XSLT ファイル、またはそれら 2 つの任意の組み合わせを使用できます。ドキュメント テンプレートを使用すると、ドキュメントの書式部分をテンプレート内のメイン コード ベースの外部に保持できるため、作業負荷を大きく軽減できます。これらのテンプレートは、より簡単に編集でき、直接書式を変更できます。ただし、データを含む領域の特定が難しいという問題があります。そのために使用できるテクノロジを、この記事の後の方で説明しています。最初に、XSLT ファイルを詳しく調べる必要があります。

単純な XSLT ファイルの例は次のようになります。

<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template match="/">
        <w:document 
            xmlns:w="http://schemas.liquid-technologies.com/OfficeOpenXML/2006/default.html">
            <w:body>
                <w:p>
                    <w:r>
                        <w:t>Hello World!</w:t>
                    </w:r>
                </w:p>
            </w:body>
        </w:document>
    </xsl:template>
</xsl:stylesheet>

XSLT ファイル内の XML データは XML 形式を保持できるため、後で XSLT ファイルを変更するのが簡単です。XSLT ファイルはテキスト ファイルなので、コンパイルされたコードを再テストする必要はありません。これにより、開発および保守のプロセスが簡単になります。

XSLT ファイルでの作業については、2 つの重要な考慮事項があります。1 つ目は、コード ベースのアプローチに比べて表現力に欠けるということです。XSLT ファイルは、たとえば日付の書式設定などが得意ではありません。多くの XSLT エンジンでは、XSLT ファイルをカスタム オブジェクトで拡張して、XSLT 仕様では定義されていない高度な機能を提供できるようになっています。.NET Framework で使用されているエンジンでは、拡張オブジェクトおよびカスタム パラメータを使用できます。

2 つ目の考慮事項は、XSLT エンジンの出力機能に関連します。オープン XML パッケージは多数の XML ファイルから構成され、その多くはさまざまなプロパティを通じて関連し合っています。XSLT 1.0 仕様では、XSLT ごとに 1 つの出力ファイルしか許可されません。XSLT 2.0 仕様では 1 つの XSLT ファイルを使用して複数のファイルを作成できますが、XSLT 2.0 を実装するエンジンはまだ一般的ではありません。

オープン XML SDK を使用する

オープン XML ソリューションで記述して保守する必要のあるコード量を減らすもう 1 つのアプローチは、2007 年 6 月に初めてリリースされた Microsoft SDK for Open XML Formats を使用することです。この API では、ドキュメントの開始パーツや他のパーツなどの概念が高いレベルで抽象化されるため、リレーションシップやコンテンツ タイプをコード内で明示的に管理する必要がなくなります。

SDK を無料でダウンロードするには、「2007 Office system: Microsoft SDK for Open XML Formats」を参照してください。オンライン ドキュメントを見るには、「Microsoft SDK for Open XML Formats へようこそ」を参照してください。

この記事の執筆時点では、この API の最終バージョンのリリース日や提供機能については発表されていません。マイクロソフトでは、ロードマップの策定に役立てるために、「Open XML Format SDK」にある MSDN サポート フォーラムを通じて、新しい API に対する開発者からのフィードバックを募っています。

ドキュメント構造について

単純な患者登録フォームでは、通常 2 つのレベルのコンテンツが定義されています。最初のレベルは、フォームのレイアウトと基本的な書式設定によって定義されます。2 番目のレベルは、患者の詳細情報や保険情報など、各種の情報に対するプレースホルダです。これらのドキュメントをデジタル形式で扱う際の困難の 1 つは、確実に正しい内容を取得できる方法でデータにアクセスするようプログラムを作成することです。書式がわずかに変更されて登録フォームの外観が変わったために、抽出された患者の名前が "名前を入力してください" となっているような事態は避ける必要があります。

Office オープン XML 形式では、Microsoft ActiveX のようなコード ベースのソリューションに頼らずドキュメント内のデータのアクセス性を高めるために、さまざまなテクノロジが導入されています。WordprocessingML の場合、主要なテクノロジはコンテンツ コントロールであり、これは構造化ドキュメント タグとも呼ばれます。これらの構造化ドキュメント タグを使用して、日付などの単純な要素や、段落やページなどの複雑な構造に対するプレースホルダを作成できます。次に示す患者登録フォームを考えます。これは、医療機関 (上記のシナリオの Contoso など) によって提供され、それに属する多くの医師が使用できる汎用フォームです。

図 6. 患者登録フォームのサンプル

登録フォーム内には多くのデータが定義されています。単純なテキスト、日付、選択フィールドなど、さまざまな種類のデータがあることがわかります。印刷されたフォームの場合、フォームが正しく記入されたことを検証するのは困難です。コンテンツ コントロールを使用すれば、これらのフィールド タイプすべてに対して、削除の禁止や内容の確認などの追加機能を提供できます。

コンテンツ コントロールは WordprocessingML のマークアップ要素の 1 つにすぎないため、データはやはり WordprocessingML マークアップ内に格納されます。登録フォーム内のデータに対して構築されるカスタム ソリューションでは、ネイティブのビジネス関連フォームのまま使用される場合と比べて、このデータへのアクセスに困難を伴います。データと書式の分離を簡単にするために、ドキュメント内にいくつかの XML データ アイランドを作成し、そのデータをドキュメント内のコンテンツ コントロールにバインドすることができます。

患者登録フォームでは、このデータ バインド テクノロジを使用して、カスタム ソリューションでデータを抽出できるようにしています。これにより、患者登録フォームを医師の Web サイトにアップロードして、患者を登録できます。Web サイトでは、ドキュメントのデータ バインドによって、登録フォーム内のデータを簡単に使用できます。ドキュメントからの XML データが処理され、バックエンドのデータ ストアに格納されます。一般に、このコンテンツの格納にはデータベースまたは EHR システムが使用されますが、このシナリオでは単純にするために、データを XML 形式で保持します。新しい患者を確認するために、XSLT によって登録の詳細が HTML に変換されてから、医師の Web サイトに表示されます。

図 7. XSLT を使用して患者データを表示用に変換する

このシナリオでは、Contoso は患者に対して診療記録を HL7 CDA 形式で提供しています。HL7 CDA のデータの一部は、患者登録フォームから抽出されたデータで構築されます。HL7 CDA ドキュメントを生成するために必要なものは、抽出された患者データに基づく XSLT 変換だけです。

図 8. もう 1 つの XSLT を使用して患者データを HL7 形式に変換する

もう 1 つ重要な点として、フォームに記入するための最も適切なツールの選択は、シナリオによって異なることに注意してください。ここでは、コンテンツ コントロールの概念を示すために Word 2007 を使用していますが、他のケースでは、Microsoft Office InfoPath 2007 など、他のアプリケーションの方が適切な場合もあります。

XML データ ストアを作成する

名前からもわかるとおり、XML データ アイランドは、Office オープン XML 形式に基づくドキュメント内で、ビジネス関連データを XML 形式で格納しています。これは、カスタム XML パーツの一例です。この XML には、Office オープン XML 形式への参照は含まれていません。これは純粋なビジネス関連データであり、任意の有効な XML ドキュメントを格納できます。XML データ アイランドは、パッケージ内に別個のパーツとして格納されます。このパッケージ パーツは、XML データを見つけることができるように、メイン ドキュメント パーツから特定のリレーションシップ タイプを使用して関連付けられています。

http://schemas.liquid-technologies.com/OfficeOpenXML/2006/default.html

新しい患者フォームには、すべてのフォーム フィールドの XML データを格納する 1 つの XML データ アイランドが含まれています。次に示す XML は、フォームに定義されたメッセージの一部を抜粋したものです。

<?xml version="1.0" encoding="utf-8"?>
<Data xmlns="http://www.example.org/ooxml/healthcare/registrationform">
    <Patient>
    <MaritalStatus>Married</MaritalStatus>
    <BirthDate>2007-05-01T00:00:00</BirthDate>
    <Age>12</Age>
    <Sex>Male</Sex>
    <SSN>123-23-1234</SSN>
    <Name />
    <Address />
    <Contact />
    <Employer />
    </Patient>
    <Insurance covered="false">
        <Subscriber />
    </Insurance>
    <Emergency>
        <Name />
        <Relationship />
        <HomePhone />
        <WorkPhone />
    </Emergency>
</Data>

この患者登録フォームには 1 つの登録しか含まれていませんが、たとえば、過去 1 か月のすべての登録を一覧表示するドキュメントを作成する場合など、複数の登録を表示するフォームも作成できます。これらの登録フォームを 2 つ結合する場合、XML データ アイランドを変更する必要はありません。XML データは、プロパティのセットを使用して一意に識別できます。また、これらのプロパティを使用して、登録フォーム内のデータを確認するために XML スキーマへの参照をすることもできます。プロパティは、パッケージ内の別のパーツに格納されます。XML データ アイランドは、カスタム XML パーツです。プロパティは、カスタム XML プロパティ パーツと呼ばれます。

図 9. カスタム XML パーツを作成する

カスタム XML パーツ内のデータを、Microsoft Office などの生産性アプリケーションの外部で表示する場合、最も簡単なアプローチは、Open XML Package Explorer (英語) などのパッケージ ビューア アプリケーションを使用することです。このツールを使用して、Office オープン XML 形式に基づく任意のドキュメントを開き、ドキュメントの個々のパーツを表示または編集することができます。

図 10. Package Explorer を使用してドキュメント パーツを表示および編集する

コンテンツ コントロールを使用する

患者登録フォームには、コンテンツの領域を識別する多くのプレースホルダが含まれています。顧客が登録フォームに詳細情報を正しく入力することは重要です。これを容易にするために、サンプル フォームでは、構造化ドキュメント タグを使用してフォームの上部にプレースホルダを作成しています。フォームの下半分では書式ベースのプレースホルダが古いモデルで作成されており、連続する下線 _____ または異なる背景色を使用しています。構造化ドキュメント タグは、フォーム内でコンテンツの領域を定義するための、より表現が豊かで、処理への影響が少ないモデルを提供します。

図 11. コンテンツ フォーム領域を定義する

構造化ドキュメント タグは、ユーザーとの対話を向上させるカスタム ユーザー インターフェイスを提供すると同時に、許可されるデータのタイプを定義する安全なモデルを提供します。このユーザー インターフェイスは、ユーザーがプレースホルダに対して操作を行っているときにだけ表示されます。ドキュメントを表示したときには、通常はコンテンツだけが表示されます。構造化ドキュメント タグでは、視覚的な識別のために、タイトルおよびプレースホルダのテキストを定義できます。

コードを使用して構造化ドキュメント タグを識別するには、タグ名を割り当てます。このタグ名により、ドキュメント内の位置に関係なくプレースホルダを識別できるようになります。タグ名を使用すると、さまざまなソリューションを実現できます。各医師に対して、医師ごとの独自のロゴやスタイルを使用したカスタム登録フォームを作成することを考えます。同じタグ名を使用していれば、登録フォームに対して構築されるアプリケーションでは、各医師に対してコードを修正する必要なしに、そのようなシナリオをサポートできます。

構造化ドキュメント タグのもう 1 つの利点は、ドキュメントを自動化するコードからドキュメント テンプレートの作成を分離できることです。自分でコードを作成しながら、美しいドキュメントを作成する技能を持った人にプレゼンテーション関連の作業を依頼することもできます。知っておく必要があるのは、タグ名と構造化ドキュメント タグのタイプだけです。これらの構造化ドキュメント タグがドキュメント内のどこに位置するかを知る必要はありません。

図 12. WordprocessingML で使用できるドキュメント タグ

構造化タグのほとんどは、単純なドキュメント コンテンツを提供します。特別なタグは、グループ タグとパーツ タグです。グループ タグは、他のドキュメント タグなどのコンテンツをグループにまとめるために使用できます。通常は、ドキュメントの特定の部分をロックして、子ドキュメント タグ内を除いて編集できないようにする場合に使用します。これにより、レイアウトおよびテキストは編集できない一方で、プレースホルダは編集可能であるようなフォームを作成できます。パーツ タグを使用すると、そのコンテンツを、ドキュメント テンプレートで既に定義済みのパーツと置き換えることができます。免責事項や共通文言など、独自の文書パーツを作成できます。

構造化ドキュメント タグを作成するには、sdt 要素を使用します。構造化ドキュメント タグでは、プロパティとコンテンツという 2 つの独立したセクションが使用されます。プロパティ内では、ドキュメント タグのタイプ、タイトル、タグ名などの詳細を定義します。タイプは、<date/> などの特定の子要素を使用して識別されます。タイプを定義する要素内では、各タイプのドキュメント タグの設定をさらにカスタマイズできます。sdtContent は 2 つの用途に使用されます。構造化ドキュメント タグのコンテンツを格納するか、またはプレースホルダ テキストを格納します。showingPlcHdr プロパティに基づき、ユーザーは適切な提供データを決定できます。

図 13. 構造化ドキュメント タグ内のフォームおよびコンテンツに含まれるプレースホルダ テキストの例

次に、テキスト コントロールを作成してテキスト コンテンツを設定する例を示します。

<w:sdt>
    <w:sdtPr>
        <w:alias w:val="Last Name" />
        <w:tag w:val="Last Name" />
        <w:text />
    </w:sdtPr>
    <w:sdtContent>
        <w:r>
            <w:t>Predeek</w:t>
        </w:r>
    </w:sdtContent>
</w:sdt>

カスタム XML ファイルにデータをバインドする

構造化ドキュメントは、患者登録ドキュメントを作成するための重要な最初の手順を提供します。さらにカスタム ソリューションを実現するために、大きな利点をもたらす追加機能があります。このシナリオでは、データがドキュメントから抽出され、医師の Web サイト上のバックエンド データ ストアに XML メッセージとして格納されます。ドキュメント データにアクセスするアプリケーションの作業負荷を軽減するために、構造化ドキュメント タグを XML データ アイランドにバインドできます。これにより、ドキュメントの書式設定とデータとの間で橋渡しをします。

図 14. ドキュメント タグを XML データ アイランドへバインドする

構造化ドキュメント タグは、XPath 式を使用して XML データ アイランドにバインドできます。この式には、名前空間プレフィックスを適用する一般的なモデルを使用して、XML 名前空間を含めることができます。名前空間プレフィックスから XML 名前空間へのマッピングは、構造化ドキュメント タグのプロパティ内に別に保持されます。プロパティには、GUID 識別子を使用して XML データ アイランドの ID を含めることもできます。GUID を使用しない場合、XPath 式はドキュメント内で最初に一致するデータ アイランドに対して評価されます。

<w:sdt>
    <w:sdtPr>
        <w:alias w:val="Last Name" />
        <w:tag w:val="LastName" />
        <w:dataBinding            w:prefixMappings="xmlns:ns0='http://www.example.org/ooxml/…                …healthcare/registrationform'"
            w:xpath="/ns0:Data/ns0:Patient/ns0:Name/ns0:Last"
            w:storeItemID="{A5566E5B-6220-4F8C-BB50-CB2E486681CB}" />
        <w:text />
    </w:sdtPr>
    <w:sdtContent>
        <w:r>
            <w:t>Predeek</w:t>
        </w:r>
    </w:sdtContent>
</w:sdt>

<dataBinding> タグは、Office Word で Microsoft Visual Basic for Applications (VBA) 環境を使用して追加するか、または Package Explorer などのツールを使用して手動で追加できます。ドキュメント内の XML データ アイランドに対する構造化ドキュメント タグのマッピングをさらに簡単に行うには、Content Control Toolkit も使用できます。このツールキットを無料でダウンロードするには、「Word 2007 Content Control Toolkit (英語)」を参照してください。

図 15. Word 2007 Content Control Toolkit

コンテンツ コントロールとそのデータ バインド機能の詳細については、Ted Pattison の OfficeSpace コラム「Office Space: Office オープン XML ファイルを構築する」を参照してください。

オープン XML ファイル形式のデジタル署名

患者が PHR サービスにアップロードした診療記録を、Contoso 内の医師までさかのぼって追跡できるようにするために、各ドキュメントは、その医師または Contoso に対して発行されたデジタル証明書を使用して署名されます。オープン XML は、デジタル署名を使用してドキュメントに署名するための柔軟な環境を提供します。X509 証明書などの業界標準を使用して署名を作成するか、またはカスタム実装を使用することができます。署名は、ドキュメント全体、特定のパーツのみ、およびパーツ間のリレーションシップに対して行うことができます。または、リレーションシップのサブセットだけに署名し、スタイルやテーマは除くことなどもできます。

デジタル署名の概要

デジタル署名とは、メッセージ (この場合はドキュメント) の正規性および整合性の保証に関連したテクノロジの総称です。このアプローチでは、ドキュメントから取得された暗号化ハッシュが ZIP コンテナ内に格納されます。後で、ドキュメントが変更されていないことを証明する必要が生じた場合、または署名者を識別する必要がある場合に、暗号化ハッシュが復号化され、ドキュメントから直接取得された新しいハッシュと比較されます。ハッシュは公開キーを使用して復号化されるため、これらのハッシュが一致すれば、ファイルが正規のものであることを確認できます。ハッシュ値が等しいので、ドキュメントは明らかに変更されていません。Office オープン XML 形式は、ドキュメントに署名するための標準化されたアプローチを提供します。

Open Packaging Convention によるドキュメントの署名

ドキュメントに署名する際の最初の手順は、署名するすべてのパーツの場所の一覧を取得することです。これは、Open Packaging Convention の Package クラスを使用して簡単に実現できます。

PackagePartCollection parts = package.GetParts();
List<Uri> toSign = new List<Uri>();
foreach (PackagePart packagePart in package.GetParts())
{
    toSign.Add(packagePart.Uri);
}

次に、ドキュメントに署名するための X509 証明書が必要です。X509Store クラスを使用して、現在のユーザーの証明書ストアを開き、証明書を抽出できます。このクラスは、他の証明書関連クラスと同様に, .NET Framework の一部です。

X509Store store = new X509Store(StoreLocation.CurrentUser);
store.Open(OpenFlags.OpenExistingOnly);
X509Certificate2Collection certificates = store.Certificates
    .Find(X509FindType.FindByKeyUsage, X509KeyUsageFlags.DigitalSignature, false)
    .Find(X509FindType.FindBySubjectName, keyName, false);

Packaging API では、Office オープン XML 形式で署名を使用するためのインターフェイスとして、PackageDigitalSignatureManager クラスを使用します。このクラスを使用して、ドキュメントに署名し、その署名を確認できます。このコンストラクタには、ドキュメントへの参照が含まれています。

PackageDigitalSignatureManager dsm = new PackageDigitalSignatureManager(package);
dsm.CertificateOption = CertificateEmbeddingOption.InSignaturePart;
dsm.Sign(toSign, certificates[0]);

Office Word 2007 で署名を確認する

診療記録ドキュメントが Open Packaging API を使用して署名された後は、Office Word でドキュメントの正規性を確認できます。このアプリケーションは、通常クライアント側で、ドキュメントへの署名にも使用できます。ドキュメントを開くと、署名は自動的に確認されます。

最初にユーザー インターフェイスが無効になることで、署名が含まれていることがわかります。ドキュメントを編集するとすべての署名が無効になるため、編集に関するコントロールはすべて無効になります。

図 16. デジタル署名付きドキュメントに対するユーザー インターフェイスの無効化

署名が無効である場合は、すぐにフィードバックとして、画面上に警告ウィンドウが追加表示されます。

図 17. デジタル署名が無効な場合の警告

[署名] 作業ウィンドウを使用して、ドキュメント内のすべての署名を表示できます。この作業ウィンドウを開くには、Microsoft Office ボタンをクリックし、[配布準備] グループをポイントします。リスト内の項目のメニューを使用して、[署名] 作業ウィンドウに表示されている各署名を削除できます。

図 18. [署名] 作業ウィンドウの表示

Open Packaging Convention を使用して署名を確認する

Packaging API を使用してドキュメントに署名する以外に、Packaging API を署名の確認にも使用できます。これは、PackageDigitalSignatureManager クラスによって簡単に実行できます。すべての署名が有効である場合、VerifySignatures メソッドは VerifyResult.Success を返します。最初に署名マネージャを使用して取得してから、個々の署名を確認できます。

PackageDigitalSignatureManager dsm = new PackageDigitalSignatureManager(package);
VerifyResult result = dsm.VerifySignatures(false);

まとめ

この記事では、オープン XML ファイル形式が、ドキュメント コンテンツを格納するためのオープンで標準化されたアプローチを提供し、ドキュメント内でビジネス データを使用可能にするモデルを提供することにより、全世界のヘルスケア業界にどのような利点をもたらすかを検討しました。データのポータビリティが高まることで、カスタム ソリューションの作成に新たな可能性が開かれます。これは適切に文書化された標準であり、多くの優れたリソースが提供されていることで、これらのソリューションの構築および保守は簡単になります。HL7 (Health Level Seven) CDA (Clinical Document Architecture) などの業界標準の使用は、オープン XML が業界にもたらす利益の一例にすぎません。保険会社や政府機関など、他にも多くの組織がオープン XML の使用から同様な利益を得ることができ、ドキュメントの交換がより簡単に、より高い透明度で行われるような環境を作成できます。

作成者について

• Ted Pattison は、フロリダ州タンパ在住のライターおよびトレーナーであり、SharePoint MVP でもあります。Ted は、MSDN Magazine の長期にわたるコラムニストであり、「Office Space: Office オープン XML ファイルを構築する」という新しいコラムでは、Microsoft Office SharePoint Products and Technologies および Microsoft Office の開発に焦点を当てています。また、Ted は『Inside Microsoft® Windows® SharePoint® Services 3.0 (英語)』という Microsoft Press の新しい本をちょうど書き終えたところです。Ted Pattison は他の何人かの SharePoint MVP と共に、彼の会社である Ted Pattison Group (英語) を通じて、専門の開発者を対象に SharePoint 2007 の高度なトレーニングを行っています。

• Chris Predeek は、Developmentor (英語) の独立コンサルタントおよびトレーナーであり、2005 年から Office オープン XML にかかわっています。90 年代後半に、Windows オペレーティング システムに対する Microsoft C++ 開発者として、そのソフトウェア開発キャリアをスタートさせました。その後、COM および COM+、そして最終的には Microsoft .NET Framework を通じて、Microsoft テクノロジを使用してきました。最近は、2007 Office system、Office SharePoint Server 2007、および Microsoft BizTalk 2006 を専門としています。

• Wouter van Vugt は、オランダ在住であり、代表的な IT コンサルタント企業の 1 つである Info Support (英語) に勤務しています。最初はコンサルタントとしてスタートし、現在は、Microsoft Visual C#、Microsoft ASP.NET、および SharePoint Products and Technologies を含む .NET Framework に基づいたテクノロジのトレーナーを務めています。Wouter についてさらに詳しく知りたい方は、「Wouter (英語)」をご覧ください。