JP2016157198A - 送信されたヘルスデータの整合性を確認するための方法、装置、およびプログラムが記録された記録媒体 - Google Patents

Abstract

【課題】送信されたヘルスデータの整合性確認を、少ないメモリ使用量で実施する方法、装置及びプログラムを提供する。
【解決手段】ヘルスデータに含まれている複数のセグメントのうち、最上位のセグメントが属する階層を示す階層情報に対応付けられた名称情報を、整合性確認マップ格納部１４に格納されたＯＢＸマップから取得し、ＯＢＸマップから取得された名称情報に対応付けられた、複数のセグメントの各々の名称情報を、整合性確認マップ格納部１４に格納された識別マップから取得する。識別マップから取得された複数のセグメントの各々の名称情報が、受信されたヘルスデータに含まれている、同じ上下関係に関連付けられている各セグメントの各々の名称情報と一致する場合、送信されたヘルスデータが整合していると判定し、一致していない場合、送信されたヘルスデータが整合していないと判定するヘルスデータ整合性確認部１５を備える。
【選択図】図４

Description

この発明は、送信されたヘルスデータの整合性を確認するための方法、装置、およびプログラムが記録された記録媒体に関し、特に、健康管理や健康増進を目的にデバイスによって収集されたヘルスデータを、サーバへ送信した場合に、その送信が正しくなされているのかを確認するための方法、装置、およびプログラムが記録された記録媒体に関する。

最近、健康増進や介護予防を目的として、血圧や歩数などの個人のヘルスデータ（「バイタルデータ」とも呼ばれる）を、血圧計や歩数計のようなヘルスケア・デバイスから取得して、サーバへ送信し、サーバによってデータベースに登録させ、登録されたヘルスデータを用いて、医師や保健師等が、個人の健康管理に活用することがなされている。

この種の技術では、個人のヘルスデータをサーバにおいて一元管理するため、インターネット等の公衆ネットワークを介して、ヘルスデータをサーバに登録するための標準仕様であるＣｏｎｔｉｎｕａのＷＡＮ−ＩＦ（非特許文献１）が用いられている。

ＷＡＮ−ＩＦの基本構成には、送信装置と、サーバ等の受信装置と、データベースとが含まれる。

ＷＡＮ−ＩＦでは、セッション層にＳＯＡＰ（Simple Object Access Protocol）が用いられ、プレゼンテーション層に、保健医療情報交換のための標準規格であるＨＬ７が採用されている。

送信装置では、血圧や歩数などのヘルスデータが、ヘルスケア・デバイスから取得され、ＨＬ７形式に変換される。次に、ＳＯＡＰメッセージが作成され、ＨＬ７形式に変換されたヘルスデータが、ＳＯＡＰメッセージの本体（Ｂｏｄｙ）に組み込まれ、受信装置に送信される。

受信装置では、ＳＯＡＰメッセージが受信され、本体（Ｂｏｄｙ）に組み込まれているＨＬ７形式のヘルスデータが構文解析され、取得される。そして、このように取得されたヘルスデータは、正しく送信されたことが確認された後にデータベースへ格納される。

以下に、この確認方法を説明する。

ＨＬ７形式のヘルスデータＭは、図３に示すように、階層構造をなしている。

図３は、ヘルスデータとして、血圧データを取り扱う場合の例である。図３中においてＯＢＸから始まる各データ行が、ヘルスケア・デバイスから取得されたデータであり、それ以外の各データ行は、例えば認証データのようなデータを示している。

ＯＢＸから始まる各データは、ＯＢＸ−１，ＯＢＸ−２，ＯＢＸ−３，ＯＢＸ−４，ＯＢＸ−５，・・・から構成される。これら各データ項目については、ＨＬ７プロトコルで規定されているので、詳細な説明は省略するが、データ行ａに示すＯＢＸ｜２は、ＯＢＸ−４が（１）となっており、１階層目のデータであることが規定されている。また、データ行ｂに示すＯＢＸ｜３は、ＯＢＸ−４が（１．０．１）となっており、３階層目のデータであることが規定されている。同様に、データ行ｃ、ｄ、ｅ、ｆに示すＯＢＸ｜４は、ＯＢＸ−４がそれぞれ（１．０．１．１）、（１．０．１．２）、（１．０．１．３）、および（１．０．０．１）となっており、４階層目のデータであることが規定されている。

従来、受信装置は、図３に示すようなＨＬ７形式のヘルスデータＭを受信すると、ＯＢＸ−３とＯＢＸ−４とが正しい組み合わせであるか否かをチェックすることによって、送信されたデータの整合性の確認を行っている。受信装置は、この整合性確認のために、図９に示すように、ＯＢＸ−３とＯＢＸ−４との対応付けが予め明記された整合性確認用テーブルＴを準備している。

そして、受信装置は、図３に例示されるようなＨＬ７形式のヘルスデータＭを受信すると、データ行ａ、ｂ、ｃ、ｄ、ｅ、ｆのそれぞれにおいて、ＯＢＸ−３とＯＢＸ−４とが、図９に例示される整合性確認用テーブルＴに記載されている内容と一致しているか否かを確認する。そして、不一致がなければ、送信されたヘルスデータは、正しいヘルスデータであると判定して、データベースに登録している。

このように、従来は、整合性確認用テーブルＴを用いた整合性確認を行うことにより、不正なデータがデータベースに格納されないようにされている。

特開2007-318289号公報 特開2014-006734号公報 特開2009-187100号公報 特開2006-323468号公報 特開2006-305216号公報 特開2006-260082号公報 特開2006-255028号公報 特開2006-085609号公報

H.810 Interoperability design guidelines for personal health systems Version Endorphin plus Errata (CDG 2014)

しかしながら、このような従来の整合性確認方法では、以下のような問題がある。

すなわち、従来の整合性確認方法では、図９に例示されるような整合性確認用テーブルＴが使用されている。

そして、この整合性確認テーブルＴは、多くのメモリを必要とするという問題がある。整合性確認を要するデータ行の数（以下、「ＯＢＸセグメント数」と称する）をｎとすると、２ｎ個のデータを格納する整合性確認テーブルＴのためのメモリが必要となる。例えば、ＯＢＸセグメント数が６である場合、図９のように、１２個ものデータを格納する整合性確認テーブルＴのためのメモリが必要となってしまう。

したがって、受信装置のメモリを増設することが必要になる場合もある。これは、コストアップにつながる。

この発明は上記事情に着目してなされたもので、その目的とするところは、送信されたヘルスデータの整合性確認を、できるだけ少ないメモリ使用量で実施することが可能な方法、装置、およびプログラムが記録された記録媒体を提供することにある。

上記目的を達成するためにこの発明の第１の観点は、以下のような構成要素を備えている。

すなわち、本発明の第１の観点は、送信されたヘルスデータの整合性を確認するための装置、方法、およびプログラムが記録された記録媒体である。ここで、ヘルスデータは、互いに上下関係を有する複数の階層のうちの何れかに属する複数のセグメントを含み、同じ上下関係に関連付けられている各セグメントは、属する階層を示す階層情報に、共通の情報を含んでいる。

また、同じ上下関係に関連付けられている複数のセグメントのうち、最上位のセグメントが属する階層を示す階層情報と、最上位のセグメントの名称情報とを対応付けてなる第１のマップと、同じ上下関係に関連付けられている複数のセグメントの各々の名称情報と、最上位のセグメントの名称情報とを対応付けてなる第２のマップとを予め設けておく。

そして、送信されたヘルスデータを受信と、受信されたヘルスデータに含まれている複数のセグメントのうち、最上位のセグメントが属する階層を示す階層情報に対応付けられた名称情報を、第１のマップから取得し、第１のマップから取得された名称情報に対応付けられた、複数のセグメントの各々の名称情報を、第２のマップから取得し、第２のマップから取得された複数のセグメントの各々の名称情報が、受信されたヘルスデータに含まれている、同じ上下関係に関連付けられている各セグメントの各々の名称情報と一致する場合、送信されたヘルスデータが整合していると判定し、一致していない場合、送信されたヘルスデータが整合していないと判定する。

そして、一致していると判定された場合、前記送信されたヘルスデータを、データベースに書き込む。

また、この発明の第１の観点は以下のような態様を備えることを特徴とする。

すなわち、送信されたヘルスデータは、ＨＬ７形式のヘルスデータとすれば、セグメントは、ＯＢＸセグメントであり、名称情報は、ＯＢＸ−３において定義され、共通の情報は、ＯＢＸ−４において定義される数値情報となる。

このように、付加データを用いてヘルスデータの送信を効率的に行うことは、上記特許文献１乃至８の何れによってもなされていない。

すなわちこの発明によれば、整合性確認に必要なデータの量を低減することによって、送信されたヘルスデータの整合性確認を、できるだけ少ないメモリ使用量で実施することが可能な方法、装置、およびプログラムが記録された記録媒体を提供することができる。

このように、第１のマップと第２のマップとを用いることによって、少ないメモリ使用量でヘルスデータの整合性確認を行う技術は、上記特許文献１乃至８の何れにも開示されていない。

図１は、本実施形態に係るヘルスデータ受信装置１０が適用されたシステム全体の構成例を示す概念図である。 図２は、ヘルスデータ送信装置３４の構成例を示す機能ブロック図である。 図３は、メッセージ作成部３８によって作成されたＨＬ７データＭの一例である。 図４は、ヘルスデータ受信装置１０の構成例を示す機能ブロック図である。 図５は、ＯＢＸマップＰ１の構成例を示す図である。 図６は、識別マップＰ２の構成例を示す図である。 図７は、本実施形態に係るヘルスデータ受信装置１０の動作例を示すフローチャートである。 ヘルスデータの種類と、ＯＢＸセグメントの数（ｎ）との関係を示す一覧である。 従来技術において整合性確認のために使用されている整合性確認用テーブルＴの構成例を示す図である。

以下に、本発明の実施形態に係る、送信されたヘルスデータの整合性を確認するための方法が適用されたヘルスデータ受信装置１０を、図面を参照して説明する。

図１は、本実施形態に係るヘルスデータ受信装置１０が適用されたシステム全体の構成例を示す概念図である。

図１において、ヘルスデータ送信装置３４は、例えばＣｏｎｔｉｎｕａ対応の血圧計等のようなヘルスデバイス３２によって取得されたヘルスデータ（ヘルスデバイス３２が血圧計の場合には血圧、ヘルスデバイス３２が歩数計の場合には歩数、等）を、サーバ２０側に設けられたデータベース２２に格納させるために、ヘルスデータ受信装置１０へ送信する。

ヘルスデータ送信装置３４およびヘルスデバイス３２は、例えば、ユーザの自宅３０に設けられ、サーバ２０は、例えばＷＡＮ４０のような通信ネットワークを介してヘルスデータ送信装置３４と通信可能な状態で、ユーザの自宅３０から遠隔に位置している。

このようなＷＡＮ４０を用いたネットワーク構成では、公衆回線に接続するためのファイアウォール等を適宜備える場合があるが、ここではその図示及び詳細説明を省略する。

図２は、ヘルスデータ送信装置３４の構成例を示す機能ブロック図である。

ヘルスデータ送信装置３４は、ヘルスデータ送信装置３４の全体動作を制御するＣＰＵ３５と、ＣＰＵ３５に接続された通信バス３６を介してそれぞれ接続されたヘルスデータ取得部３７と、メッセージ作成部３８と、メッセージ通信部３９とを備えている。

ヘルスデータ取得部３７は、ヘルスデバイス３２によって取得されたヘルスデータ（ヘルスデバイス３２が血圧計の場合には血圧、ヘルスデバイス３２が歩数計の場合には歩数、等）を、ヘルスデバイス３２から取得する。

メッセージ作成部３８は、ヘルスデータ取得部３７によって取得されたヘルスデータを含むＨＬ７データを作成する。

図３は、メッセージ作成部３８によって作成されたＨＬ７データＭの一例である。

メッセージ通信部３９は、ＳＯＡＰメッセージを作成し、メッセージ作成部３８によって作成された例えば図３に示されるようなＨＬ７データＭを、ＳＯＡＰメッセージの本体（Ｂｏｄｙ）に組み込む。そして、このＳＯＡＰメッセージを、ＷＡＮ４０を介してサーバ２０側へ送信する。

このようにしてサーバ２０側へ送信されたＳＯＡＰメッセージを、サーバ２０のヘルスデータ受信装置１０が受信する。

図４は、ヘルスデータ受信装置１０の構成例を示す機能ブロック図である。

ヘルスデータ受信装置１０は、ヘルスデータ受信装置１０の全体動作を制御するＣＰＵ１１と、ＣＰＵ１１に接続された通信バス１２を介してそれぞれ接続された通信部１３と、整合性確認マップ格納部１４と、ヘルスデータ整合性確認部１５と、ヘルスデータ書込部１６とを備えている。

通信部１３は、ＳＯＡＰメッセージを受信すると、受信したＳＯＡＰメッセージをヘルスデータ整合性確認部１５に渡すとともに、ＷＡＮ４０を介してヘルスデータ送信装置３４へ応答メッセージを返信する。

ヘルスデータ整合性確認部１５は、通信部１３からＳＯＡＰメッセージを渡されると、ＳＯＡＰメッセージの本体（Ｂｏｄｙ）に組み込まれているＨＬ７データＭを取得する。そして、ＨＬ７データＭに含まれるヘルスデータが、ヘルスデータ送信装置３４から正しく送信されたものであるか否かを、整合性確認マップ格納部１４に格納された２つのマップ、すなわち、ＯＢＸマップＰ１と識別マップＰ２とを用いて判定する。

ＯＢＸマップＰ１は、例えば図５にその構成例を示すように、ＨＬ７データＭにおけるＯＢＸ−４の最上位の数値（左列）と、それに対応するＯＢＸ−３（右列）とを示している。図３に示すＨＬ７データＭの例では、ＯＢＸ−４の最上位は、データ行ａのように、ＯＢＸ｜２である１階層目であり、その値は“１”であるので、ＯＢＸマップＰ１の左列には“１”が記載される。また、それに対応するＯＢＸ−３は、“５２８３９１＾ＭＤＣ＿ＤＥＶ＿ＳＰＥＣ＿ＰＲＯＦＩＬＥ＿ＢＰ＾ＭＤＣ”であるので、ＯＢＸマップＰ１の右列にはそれが記載される。

また、識別マップＰ２は、例えば図６にその構成例を示すように、ＨＬ７データＭにおけるＯＢＸ−３（左列）と、ＯＢＸ−４の最上位に対応するＯＢＸ−３（右列）とを示している。図３に示すＨＬ７データＭの例では、データ行ａ、ｂ、ｃ、ｄ、ｅ、ｆのように、６つの階層構造をなすＯＢＸが存在する。なお、ＯＢＸ｜１であるデータ行ｇもＯＢＸであるが、ＯＢＸ｜１のＯＢＸ−４は（０．０．０．１）となっている。ＨＬ７データＭでは、同じ上下関係に関連付けられているＯＢＸは、先頭の数値が同一となる。したがって、ＯＢＸ−４の先頭の数値が何れも“１”であるデータ行ａ、ｂ、ｃ、ｄ、ｅ、ｆは、同じ上下関係に関連付けられている一方、ＯＢＸ−４の先頭の数値が“０”であるデータ行ｇは、同じ上下関係に関連付けられていないので、図６に記載される対象とはならない。

よって、図６に示す識別マップＰ２の左列には、図３に示すＨＬ７データＭの例では、データ行ａ、ｂ、ｃ、ｄ、ｅ、ｆに記載されたＯＢＸ−３が記載される。また、図６に示す識別マップＰ２の右列には、ＯＢＸ−４の最上位に対応するＯＢＸ−３が記載される。図３に示すＨＬ７データＭの例では、ＯＢＸ−４の最上位は、データ行ａのように、ＯＢＸ｜２である１階層目であり、それに対応するＯＢＸ−３は、“５２８３９１＾ＭＤＣ＿ＤＥＶ＿ＳＰＥＣ＿ＰＲＯＦＩＬＥ＿ＢＰ＾ＭＤＣ”であるので、ＯＢＸマップＰ１の右列にはそれが記載される。すなわち、識別マップＰ２の右列は、対応するＯＢＸマップＰ１の右列と同一となる。

ヘルスデータ整合性確認部１５は、ＨＬ７データＭを取得すると、ＨＬ７データＭから、ＯＢＸ−４の最上位の数値情報を取得する。図３に示すＨＬ７データＭの場合、ＯＢＸ−４の最上位の数値は、データ行ｂに示されるＯＢＸ｜２である１階層目であるので“１”となる。

ヘルスデータ整合性確認部１５は次に、整合性確認マップ格納部１４に格納されているＯＢＸマップＰ１を参照する。そして、ＯＢＸマップＰ１を用いて、前述したように取得されたＯＢＸ−４の最上位の数値である“１”（左列）に対応するＯＢＸ−３（右列）を取得する。図５に示す例では、ＯＢＸ−４の最上位の数値である“１”（左列）に対応するＯＢＸ−３は“５２８３９１＾ＭＤＣ＿ＤＥＶ＿ＳＰＥＣ＿ＰＲＯＦＩＬＥ＿ＢＰ＾ＭＤＣ”（右列）である。

ヘルスデータ整合性確認部１５は次に、整合性確認マップ格納部１４に格納されている識別マップＰ２を参照する。そして、識別マップＰ２を用いて、前述したように取得された、ＯＢＸ−４の最上位の数値に対応するＯＢＸ−３（左列）に属するＯＢＸ−３（右列）を取得する。

そして、ＨＬ７データＭに含まれる各ＯＢＸセグメント（すなわち、データ行ａ、ｂ、ｃ、ｄ、ｅ、ｆ）のＯＢＸ−３が、識別マップＰ２のＯＢＸ−３（左列）に記載されたものと一致するか否かを判定する。

そして、一致していれば、ＨＬ７データＭに含まれるヘルスデータが、ヘルスデータ送信装置３４から正しく送信されたものであると判定し、このヘルスデータをデータベース２２に書き込む。

一方、不一致があった場合には、ＨＬ７データＭに含まれるヘルスデータは、ヘルスデータ送信装置３４から正しく送信されたものではないと判定し、このヘルスデータをデータベース２２に書き込まない。

次に、以上のように構成した本実施形態に係るヘルスデータ受信装置１０の動作について、図７のフローチャートを用いて説明する。

ヘルスデバイス３２によって取得されたヘルスデータは、ヘルスデータ送信装置３４に送られ、そこで、ＨＬ７データＭに変換され、さらに、ＨＬ７データＭが、ＳＯＡＰメッセージの本体（Ｂｏｄｙ）に組み込まれる。そして、このＳＯＡＰメッセージが、ＷＡＮ４０を介してサーバ２０側へ送信される。

このようにして送信されたＳＯＡＰメッセージは、ヘルスデータ受信装置１０の通信部１３によって受信され、通信部１３から、ヘルスデータ整合性確認部１５に渡される（Ｓ１）。これに応じて、通信部１３からヘルスデータ送信装置３４へと応答メッセージが返信される（Ｓ２）。

ヘルスデータ整合性確認部１５では、ＳＯＡＰメッセージの本体（Ｂｏｄｙ）から、ＨＬ７データＭが取得される（Ｓ３）。そして、ＨＬ７データＭに含まれるヘルスデータが、ヘルスデータ送信装置３４から正しく送信されたものであるか否かが、整合性確認マップ格納部１４に格納された２つのマップ、すなわち、ＯＢＸマップＰ１と識別マップＰ２とを用いて、ヘルスデータ整合性確認部１５によって判定される。このようにヘルスデータ整合性確認部１５によってなされる整合性確認処理を以下に説明する。

まず、ヘルスデータ整合性確認部１５によって、ＨＬ７データＭから、ＯＢＸ−４の最上位の数値が取得される（Ｓ４）。図３に示すＨＬ７データＭの場合、ＯＢＸ−４の最上位の数値は、データ行ｂに示されるＯＢＸ｜２である１階層目である“１”となる。

次に、ヘルスデータ整合性確認部１５によって、整合性確認マップ格納部１４に格納されているＯＢＸマップＰ１が参照される（Ｓ５）。そして、ＯＢＸマップＰ１を用いて、ステップＳ４で取得されたＯＢＸ−４の最上位の数値である“１”（左列）に対応するＯＢＸ−３（右列）が取得される（Ｓ６）。図５に示す例では、ＯＢＸ−４の最上位の数値である“１”（左列）に対応するＯＢＸ−３は“５２８３９１＾ＭＤＣ＿ＤＥＶ＿ＳＰＥＣ＿ＰＲＯＦＩＬＥ＿ＢＰ＾ＭＤＣ”（右列）である。

さらに、ヘルスデータ整合性確認部１５によって、整合性確認マップ格納部１４に格納されている識別マップＰ２が参照される（Ｓ７）。そして、識別マップＰ２を用いて、ステップＳ６において取得された、ＯＢＸ−４の最上位に対応するＯＢＸ−３（左列）に属するＯＢＸ−３（右列）が取得される（Ｓ８）。

そして、ヘルスデータ整合性確認部１５によって、ＨＬ７データＭに含まれる各ＯＢＸセグメント（すなわち、データ行ａ、ｂ、ｃ、ｄ、ｅ、ｆ）のＯＢＸ−３が、識別マップＰ２の（左列）に記載されたものと一致するか否かが判定される（Ｓ９）。

そして、一致していれば（Ｓ９：Ｙｅｓ）、ＨＬ７データＭに含まれるヘルスデータが、ヘルスデータ送信装置３４から正しく送信されたものであると判定され（Ｓ１０）、このヘルスデータが、ヘルスデータ書込部１６によってデータベース２２に書き込まれる（Ｓ１１）。

一方、一致していない場合（Ｓ９：Ｎｏ）には、ＨＬ７データＭに含まれるヘルスデータが、ヘルスデータ送信装置３４から正しく送信されたものではないと判定され（Ｓ１２）、このヘルスデータは、データベース２２に書き込まれない。

上述したように、本実施形態に係るヘルスデータ受信装置１０によれば、送信されたヘルスデータの整合性確認のために、図９に図示されるような整合性確認テーブルＴに代えて、図５および図６に示すようなＯＢＸマップＰ１および識別マップＰ２を用いる。ＨＬ７データＭに含まれるＯＢＸセグメントの数をｎとすると、整合性確認テーブルＴを用いる従来技術では、２ｎ個のデータを格納するメモリ量が必要となる。一方、ＯＢＸマップＰ１および識別マップＰ２を用いる本実施形態では、ｎ＋３個のデータを格納するメモリ量が必要となる。すなわち、ＯＢＸセグメントの数であるｎが、４より大きければ、本実施形態の方が、ヘルスデータの整合性確認のために必要なメモリ量を低減することができる。

本実施形態では、ヘルスデータが血圧の場合であるｎ＝６の例について説明しているが、図８に示すように、ほとんどの種類のヘルスデータについてｎは、５以上である。例えば、グルコース測定では、ｎ＝２０であるので、従来技術では１２０個のデータを格納するメモリ量が必要であった一方、本実施形態によれば、２３個のデータを格納するメモリ量だけで済む。

すなわち、本実施形態によれば、整合性確認に要するメモリの量を低減し、もって、受信装置のメモリに対する負荷を低減しつつ、送信されたヘルスデータの整合性を確認することが可能となる。

なお、この発明は上記実施形態に限定されるものではない。例えば、図７のフローチャートでは、説明を簡略にするために、便宜的に、ステップＳ４以降の整合性確認処理がすべてのＯＢＸセグメントを対象に１回でなされる例を示しているが、ステップＳ４以降の整合性確認処理を、ＯＢＸセグメント毎に実施することを繰り返すようにしても良い。

もちろん、この発明の要旨を逸脱しない範囲であれば、適宜種々変形することによっても、本発明を実施することが可能である。

要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

１０ ヘルスデータ受信装置、１２ 通信バス、１３ 通信部、１４ 整合性確認マップ格納部、１５ ヘルスデータ整合性確認部、１６ ヘルスデータ書込部、２０ サーバ、２２ データベース、３０ 自宅、３２ ヘルスデバイス、３４ ヘルスデータ送信装置、３６ 通信バス、３７ ヘルスデータ取得部、３８ メッセージ作成部、３９ メッセージ通信部

Claims (8)

1. 送信されたヘルスデータの整合性を確認するための装置であって、
   ヘルスデータは、互いに上下関係を有する複数の階層のうちの何れかに属する複数のセグメントを含み、
   同じ上下関係に関連付けられている各セグメントは、属する階層を示す階層情報に、共通の情報を含み、
   前記装置は、
   前記同じ上下関係に関連付けられている複数のセグメントのうち、最上位のセグメントが属する階層を示す階層情報と、前記最上位のセグメントの名称情報とを対応付けてなる第１のマップと、
   前記同じ上下関係に関連付けられている複数のセグメントの各々の名称情報と、前記最上位のセグメントの名称情報とを対応付けてなる第２のマップと、
   前記送信されたヘルスデータを受信する受信手段と、
   前記受信されたヘルスデータに含まれている複数のセグメントのうち、最上位のセグメントが属する階層を示す階層情報に対応付けられた名称情報を、前記第１のマップから取得し、前記第１のマップから取得された名称情報に対応付けられた、複数のセグメントの各々の名称情報を、前記第２のマップから取得し、前記第２のマップから取得された複数のセグメントの各々の名称情報が、前記受信されたヘルスデータに含まれている、前記同じ上下関係に関連付けられている各セグメントの各々の名称情報と一致する場合、前記送信されたヘルスデータが整合していると判定し、一致していない場合、前記送信されたヘルスデータが整合していないと判定する判定手段と、
   を備える装置。
2. 前記第１のマップと前記第２のマップとを格納する格納手段、をさらに備える請求項１に記載の装置。
3. 前記判定手段によって、一致していると判定された場合、前記送信されたヘルスデータを、データベースに書き込む書込手段、をさらに備える請求項１または２に記載の装置。
4. 前記送信されたヘルスデータは、ＨＬ７形式のヘルスデータであり、前記セグメントは、ＯＢＸセグメントであり、前記名称情報は、ＯＢＸ−３において定義され、前記共通の情報は、ＯＢＸ−４において定義される数値情報である、請求項１乃至３のうち何れか１項に記載の装置。
5. 送信されたヘルスデータの整合性を確認するための方法であって、
   ヘルスデータは、互いに上下関係を有する複数の階層のうちの何れかに属する複数のセグメントを含み、
   同じ上下関係に関連付けられている各セグメントは、属する階層を示す階層情報に、共通の情報を含み、
   前記同じ上下関係に関連付けられている複数のセグメントのうち、最上位のセグメントが属する階層を示す階層情報と、前記最上位のセグメントの名称情報とを対応付けてなる第１のマップと、
   前記同じ上下関係に関連付けられている複数のセグメントの各々の名称情報と、前記最上位のセグメントの名称情報とを対応付けてなる第２のマップとを予め備え、
   前記送信されたヘルスデータを受信し、
   前記受信されたヘルスデータに含まれている複数のセグメントのうち、最上位のセグメントが属する階層を示す階層情報に対応付けられた名称情報を、前記第１のマップから取得し、
   前記第１のマップから取得された名称情報に対応付けられた、複数のセグメントの各々の名称情報を、前記第２のマップから取得し、
   前記第２のマップから取得された複数のセグメントの各々の名称情報が、前記受信されたヘルスデータに含まれている、前記同じ上下関係に関連付けられている各セグメントの各々の名称情報と一致する場合、前記送信されたヘルスデータが整合していると判定し、一致していない場合、前記送信されたヘルスデータが整合していないと判定する、方法。
6. 前記送信されたヘルスデータは、ＨＬ７形式のヘルスデータであり、前記セグメントは、ＯＢＸセグメントであり、前記名称情報は、ＯＢＸ−３において定義され、前記共通の情報は、ＯＢＸ−４において定義される数値情報である、請求項５に記載の方法。
7. 送信されたヘルスデータの整合性を確認するためのプログラムを記録したコンピュータ読取可能な記録媒体であって、
   ヘルスデータは、互いに上下関係を有する複数の階層のうちの何れかに属する複数のセグメントを含み、
   同じ上下関係に関連付けられている各セグメントは、属する階層を示す階層情報に、共通の情報を含み、
   前記同じ上下関係に関連付けられている複数のセグメントのうち、最上位のセグメントが属する階層を示す階層情報と、前記最上位のセグメントの名称情報とを対応付けてなる第１のマップと、前記同じ上下関係に関連付けられている複数のセグメントの各々の名称情報と、前記最上位のセグメントの名称情報とを対応付けてなる第２のマップとを予め記録し、
   前記コンピュータに、
   前記送信されたヘルスデータを受信する手順と、
   前記受信されたヘルスデータに含まれている複数のセグメントのうち、最上位のセグメントが属する階層を示す階層情報に対応付けられた名称情報を、前記第１のマップから取得する手順と、
   前記第１のマップから取得された名称情報に対応付けられた、複数のセグメントの各々の名称情報を、前記第２のマップから取得する手順と、
   前記第２のマップから取得された複数のセグメントの各々の名称情報が、前記受信されたヘルスデータに含まれている、前記同じ上下関係に関連付けられている各セグメントの各々の名称情報と一致する場合、前記送信されたヘルスデータが整合していると判定し、一致していない場合、前記送信されたヘルスデータが整合していないと判定する手順と、を実行させるためのプログラムを記録したコンピュータ読取可能な記録媒体。
8. 前記プログラムはさらに、前記一致していると判定された場合、前記コンピュータに、前記送信されたヘルスデータを、データベースに書き込む手順を実行させる、請求項７に記載のコンピュータ読取可能な記録媒体。