SAP IDoc ファイルの使用 |
SAP IDoc は、セグメントにグループ化されたデータのフィールドで構成されています。 セグメントは相互に関係のある階層構造になっています。
医師が入院患者に出した処方箋を院内の薬局に届ける必要があるとします。 これは、病床プログラムから薬局のプログラムに IDoc を送信すると可能になります。 IDoc に 4 レベルのセグメントの階層構造があると想定します。
患者名: Johnson
診断: クループ
診断: 脛骨の骨折
診察タイプ: 入院
医薬品: コデイン
医薬品: アドミール
診察タイプ: 再診
医薬品: ナプロシン
レベル 1: 患者の名前や住所など、長年にわたり変更されないデータが含まれます。
レベル 2: 特定の疾病期間中は変らないものの、病気に応じて変化するデータが含まれます。主治医や診断などです。 特定の患者に対して、複数の二次的レベルが存在することもあります。
レベル 3: 特定の外来診察の間のみ変化せず、診察ごとに異なるデータが含まれます。入院や再診などの診察タイプ、担当医などです。 患者は疾病期間中、複数の診察を受ける場合もあります。
レベル 4: 各処方箋に応じて変化するデータが含まれています。処方箋を出している医師、医薬品、用量などです。 特定の診察での特定の患者に対して複数の医薬品が処方されることもあります。
System, Application, and Products in Data Processing (SAP) は、サードパーティアプリケーションと互換性のないデータベースが情報を交換し、大企業の注文処理、納品、顧客サービス、サプライチェーン管理、在庫管理システムを自動化するために設計されたワークフローアプリケーションです。
SAP の Auto-ID Infrastructure (AII) を使用して XML スクリプトを作成する。
Intermediate Document (IDoc) ファイルを作成する。
IDoc は、相互に階層関係を持つセグメントにデータグループのフィールドをグループ化する方法の名前です。 SAP では、ファイル種類のライブラリが維持されますが、必要に応じてカスタム IDoc ファイル種類を作成できます。
SAP は、SAP Aktiengesellschaft の商標です。
IDoc はメッセージなので、プログラムの送受信は特定の IDoc で各データを検索する時期について共通の規則を満たす必要があります。 このため、SAP AG は数百種の IDoc と多数のセグメント種類を定義しています。
送信プログラムは、この定義に基づいて特定種類の IDoc を構築する必要があります。同様に、受信プログラムも IDoc を解析する際に定義に一致しなくてはなりません。
IDoc の種類には、6 文字と 2 つの数字から成る名前が付けられます。 SHPMNT01 は、出荷に関するメッセージを含む IDoc です。 SAP は時折、IDoc の定義を改定します。名前の最後に付けられた 2 つの数字が改定を示します。
セグメント名は、3 桁のバージョン番号で終了することもあります。 たとえば、E2KNA1M001 は DEBMAS02 (カスタマーマスター) IDoc 種類のセグメントです。
SAP オーナーは、独自のカスタム IDoc タイプとセグメント タイプを作成で��ます。
SAP AG によって定義されるセグメントの名前は常に "E" で始まります、カスタムデザインされたセグメントの名前は常に "Z" で始まります。
パーサファイルは、[IDoc 種類の定義] ダイアログの特定の IDoc 種類に関連付けられます。
子セグメントのデータは常に親セグメントのデータに関連付けられているため、最上部のノードから最下部のノードにいたるまで IDoc のツリーを通る非分枝パスは、テーブル形式のデータソースのレコードと同じようなレコードとみなされます。
各セグメントに 1 つのフィールドのみが含まれている以下のデータ階層を例に考えてみます。
患者名: Johnson |
|
|
|
|
診断: クループ |
|
|
|
診断: 脛骨の骨折 |
|
|
|
|
診察タイプ: 入院 |
|
|
|
|
医薬品: コデイン |
|
|
|
医薬品: アドミール |
|
|
診察タイプ: 再診 |
|
|
|
|
医薬品: ナプロシン |
Johnson という名前の患者は、喉頭炎や脛骨の骨折で何度か治療を受けています (Details of the first illness are not depicted.) In the first hospital visit for the fracture the doctor prescribed codeine and amidol. 再診の際には、ナプロシンが処方されました。
脛骨の骨折からナプロシンの処方にいたるまでの経緯は、以下のようなフラットレコードに圧縮できます。
患者名 |
診断 |
診察 |
医薬品 |
Johnson |
脛骨の骨折 |
再診 |
ナプロシン |
他の 2 つの完全な経緯も以下のレコードのように圧縮できます。
患者名 |
診断 |
診察 |
医薬品 |
Johnson |
脛骨の骨折 |
入院 |
コデイン |
Johnson |
脛骨の骨折 |
入院 |
アドミール |
IDoc のデータ階層から生成できる、すべてのレコードの項目を印刷する必要がない場合があります。
マスターセグメントは、設計のニーズに関連のあるデータのみに絞り込まれたセグメントです。
最初の例で使用したデータツリーを考えてみます。 処方する薬品ごとにラベルが必要な病院では、4 番目のレベルでマスターセグメントを設定します。
患者名 |
診断 |
診察 |
医薬品 |
---|---|---|---|
Johnson |
脛骨の骨折 |
入院 |
コデイン |
Johnson |
脛骨の骨折 |
入院 |
アドミール |
Johnson |
脛骨の骨折 |
再診 |
ナプロシン |
病院では診察 1 回ごとに別個のファイルを維持しており、ファイルフォルダ用のラベルを作成するとします。 診察 1 回につき 1 枚のラベルが必要です。
患者名 |
診断 |
診察 |
医薬品 |
---|---|---|---|
Johnson |
脛骨の骨折 |
入院 |
コデインアミドール |
Johnson |
脛骨の骨折 |
再診 |
ナプロシン |
最初のレコードで、 はマスター セグメントの下のレベルから「医薬品」というフィールドを含め、より低いレベルのセグメントからあらゆるデータを連結しました。
この IDoc から構築した項目の標準的なランでは、すべての_____________ごとに 1 つの項目を印刷します。
上記の空欄に「診断」と入れると、3 番目のレベルがマスターセグメントの最適なレベルの選択肢となります。ただし、「処方薬」と入れると、4 番目がよりよい選択肢になります。
関連トピック