▶ ヒロイック－フェイス メディカル サイエンス カンパニー リミテッドの特許一覧
特表2023-529803デジタル聴診器によって生成された音声データの分析を通じた健康に関する洞察の導出
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-07-12
(54)【発明の名称】デジタル聴診器によって生成された音声データの分析を通じた健康に関する洞察の導出
(51)【国際特許分類】
A61B 5/08 20060101AFI20230705BHJP
A61B 7/04 20060101ALI20230705BHJP
G10L 25/18 20130101ALI20230705BHJP
G10L 25/21 20130101ALI20230705BHJP
G10L 25/24 20130101ALI20230705BHJP
G10L 25/66 20130101ALI20230705BHJP
【ＦＩ】
A61B5/08
A61B7/04 K
A61B7/04 N
G10L25/18
G10L25/21
G10L25/24
G10L25/66
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022570115
(86)(22)【出願日】2021-05-14
(85)【翻訳文提出日】2023-01-16
(86)【国際出願番号】 US2021032595
(87)【国際公開番号】W WO2021231958
(87)【国際公開日】2021-11-18
(31)【優先権主張番号】63/025,395
(32)【優先日】2020-05-15
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＨＤＭＩ
(71)【出願人】
【識別番号】522446063
【氏名又は名称】ヒロイック－フェイス メディカル サイエンス カンパニー リミテッド
【氏名又は名称原語表記】ＨＥＲＯＩＣ－ＦＡＩＴＨ ＭＥＤＩＣＡＬ ＳＣＩＥＮＣＥ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】Ｔｈｅ Ｇｒａｎｄ Ｐａｖｉｌｉｏｎ Ｃｏｍｍｅｒｃｉａｌ Ｃｅｎｔｒｅ，Ｏｌｅａｎｄｅｒ Ｗａｙ，８０２ Ｗｅｓｔ Ｂａｙ Ｒｏａｄ，Ｐ．Ｏ．Ｂｏｘ ３２０５２，Ｇｒａｎｄ Ｃａｙｍａｎ，ＫＹ１－１２０８（ＫＹ）
(74)【代理人】
【識別番号】110002734
【氏名又は名称】弁理士法人藤本パートナーズ
(72)【発明者】
【氏名】チェン，ユアン ルェン
(72)【発明者】
【氏名】シュー，フーシュン
(72)【発明者】
【氏名】ホアン，ジィ－デェ
(72)【発明者】
【氏名】ホアン，シャン－ルァン
【テーマコード（参考）】
4C038
【Ｆターム（参考）】
4C038SS08
4C038SV05
4C038SX05
(57)【要約】
【要約】
本願では、電子聴診器システムによって生成された音声データの分析を通じて患者の健康に関する洞察を導出するためのコンピュータプログラム、及び、関連するコンピュータ実装技術を提示する。診断プラットフォームは、電子聴診器システムによって生成された音声データを検査して、患者の健康に関する洞察を得る役割を担い得る。診断プラットフォームは、機械学習又は人工知能に依存するヒューリスティック、アルゴリズム又はモデルを採用してもよく、それによって、医療専門家による視覚分析に依存する従来のアプローチよりも大幅に優れた方法で聴診を実行し得る。
【選択図】図１Ａ
本願では、電子聴診器システムによって生成された音声データの分析を通じて患者の健康に関する洞察を導出するためのコンピュータプログラム、及び、関連するコンピュータ実装技術を提示する。診断プラットフォームは、電子聴診器システムによって生成された音声データを検査して、患者の健康に関する洞察を得る役割を担い得る。診断プラットフォームは、機械学習又は人工知能に依存するヒューリスティック、アルゴリズム又はモデルを採用してもよく、それによって、医療専門家による視覚分析に依存する従来のアプローチよりも大幅に優れた方法で聴診を実行し得る。
【選択図】図１Ａ
【特許請求の範囲】
【請求項1】
呼吸数を計算する方法であって、患者の肺によって生成された音の記録を表す音声データを取得するステップと、
訓練されたモデルによる分析に備えて前記音声データを処理するステップと、
時間順に並べられたエントリを含むベクトルを生成するために、前記訓練されたモデルを前記音声データに適用するステップであって、
前記ベクトル内の各エントリが、前記音声データの対応するセグメントが呼吸イベントを表しているかどうかを示す、ステップと、
前記ベクトルを検査することによって、（ｉ）第１の呼吸イベントと、（ｉｉ）前記第１の呼吸イベントに続く第２の呼吸イベントと、（ｉｉｉ）前記第２の呼吸イベントに続く第３の呼吸イベントとを識別するステップと、
（ａ）前記第１の呼吸イベントと前記第２の呼吸イベントとの間の第１の期間、及び、（ｂ）前記第２の呼吸イベントと前記第３の呼吸イベントの間との第２の期間を決定するステップと、
前記第１の期間と前記第２の期間に基づいて、呼吸数を計算するステップと
を含む、方法。
【請求項2】
前記ベクトル内の各エントリが、前記音声データの異なるセグメントに対応しており、前記ベクトル内の全てのエントリが、前記音声データの持続時間の等しいセグメントに対応している、請求項１に記載の方法。
【請求項3】
各呼吸イベントが、前記ベクトル内の少なくとも２つの連続するエントリであって、前記音声データの対応するセグメントが呼吸イベントを表していることを示している少なくとも２つの連続するエントリに対応している、請求項１に記載の方法。
【請求項4】
前記処理するステップが、前記音声データにハイパスフィルタを適用するステップと、
前記音声データに基づいて、（ｉ）スペクトログラムと、（ｉｉ）一連のメル周波数ケプストラム係数（ＭＦＣＣ）と、（ｉｉｉ）前記スペクトログラムの異なる周波数帯域にわたって合計されたエネルギーを表す一連の値を生成するステップと、
前記スペクトログラム、前記一連のＭＦＣＣ及び前記一連の値を連結して、特徴マトリクスとするステップと
を含む、請求項１に記載の方法。
【請求項5】
前記処理するステップが、各エントリが０と１との間の値を有するように、前記特徴マトリクスにおいて最小最大正規化を実行するステップ
をさらに含む、請求項４に記載の方法。
【請求項6】
前記ハイパスフィルタのカットオフ周波数によって、前記患者の別の内臓によって生じた音が、前記音声データからフィルタリングされる、請求項４に記載の方法。
【請求項7】
所定の数未満のエントリによって区切られた同じタイプの呼吸イベントに対応する一対のエントリを識別するために、前記ベクトルを検査するステップと、前記一対のエントリが単一の呼吸イベントを表していることを示すように、前記一対のエントリをマージするステップと
をさらに含む、請求項１に記載の方法。
【請求項8】
前記一対のエントリは、前記音声データの対応するセグメントが吸息を表していることを示す、請求項７に記載の方法。
【請求項9】
前記一対のエントリは、前記音声データの対応するセグメントが呼息を表していることを示す、請求項７に記載の方法。
【請求項10】
所定の長さ未満の同じタイプの呼吸イベントに対応する一連の連続エントリを識別するために、前記ベクトルを検査するステップと、前記一連の連続したエントリによって表される呼吸イベントを削除するように、前記一連の連続したエントリ内の各エントリに関連付けられたラベルを調整するステップと
をさらに含む、請求項１に記載の方法。
【請求項11】
前記第１の期間は、前記第１の呼吸イベントの開始から前記第２の呼吸イベントの開始にまで及んでおり、前記第２の期間は、前記第２の呼吸イベントの開始から前記第３の呼吸イベントの開始にまで及んでおり、前記計算するステップは、１２０を前記第１の期間と前記第２の期間の合計で除算することによって、前記呼吸数を確立するステップを含んでいる、請求項１に記載の方法。
【請求項12】
非一時的媒体であって、該媒体には、コンピューティングデバイスのプロセッサによって実行された際に、該コンピューティングデバイスに対して、時間順に並べられたエントリを含むベクトルを取得する操作であって、前記ベクトル内の各エントリが、音声データの対応するセグメントが呼吸イベントを表しているかどうかに関する予測を示す、操作と、
前記ベクトルの前記エントリを検査することによって、（ｉ）第１の呼吸イベントと、（ｉｉ）第２の呼吸イベントと、（ｉｉｉ）第３の呼吸イベントとを識別する操作と、
（ａ）前記第１の呼吸イベントと前記第２の呼吸イベントとの間の第１の期間、及び、（ｂ）前記第２の呼吸イベントと前記第３の呼吸イベントの間との第２の期間を決定する操作と、
前記第１の期間と前記第２の期間に基づいて、呼吸数を計算する操作と
を含む操作を実行させる複数の命令が記憶されている、非一時的媒体。
【請求項13】
各呼吸イベントが、前記患者による吸息である、請求項１２に記載の非一時的媒体。
【請求項14】
前記第１、第２及び第３の呼吸イベントのそれぞれが、前記ベクトル内の一連の連続するエントリであって、（ｉ）所定の長さを超えており、かつ、（ｉｉ）前記音声データの前記対応するセグメントが、呼吸イベントを表していることを示している一連の連続するエントリに対応している、請求項１２に記載の非一時的媒体。
【請求項15】
前記計算する操作が、１２０を前記第１の期間と前記第２の期間の合計で除算することによって、前記呼吸数を確立する操作を含んでいる、請求項１２に記載の非一時的媒体。
【請求項16】
前記操作が、前記音声データに対応するスペクトログラムを含むインタフェースを表示させる操作と、
医療専門家による診断上の決定を容易にするために、前記インタフェースに前記呼吸数を掲示する操作と
をさらに含んでいる、請求項１２に記載の非一時的媒体。
【請求項17】
前記操作が、前記呼吸数を下限閾値と比較する操作と、
前記呼吸数が前記下限閾値を下回っているという決定に応答して、通知を生成する操作と
をさらに含んでいる、請求項１２に記載の非一時的媒体。
【請求項18】
前記操作が、前記呼吸数を上限閾値と比較する操作と、
前記呼吸数が前記上限閾値を超えているという決定に応答して、通知を生成する操作と
をさらに含んでいる、請求項１２に記載の非一時的媒体。
【発明の詳細な説明】
【技術分野】
【0001】
様々な実施形態は、電子聴診器システムによって生成された音声データの分析を通じて患者の健康に関する洞察を導出するためのコンピュータプログラム、及び、関連するコンピュータ実装技術に関する。
【背景技術】
【0002】
歴史的に、音響聴診器は、生体内から発生する内部音を聞くために使用されてきている。このプロセスは「聴診」と称されており、通常、生体系を検査する目的で実施され、それら生体系の内部音からパフォーマンスを推測することができる。通常、音響聴診器は、体に当て置くように設計された共振器を備えた単一のチェストピースと、イヤーピースに接続された一対の中空チューブとを含んでいる。音波が共振器によって捕捉されると、該音波は一対の中空チューブを介してイヤーピースへと向かわされる。
【0003】
しかしながら、音響聴診器にはいくつかの欠点に悩まされている。例えば、音響聴診器は、音源の周波数に比例して音を減衰させるようになっている。そのため、イヤホンに伝わる音が非常に微弱になる傾向があり、それによって状態を正確に診断することが困難になる可能性がある。実際に、耳の感度の違いが原因となって、一部の音（例えば、５０ヘルツ未満の音）が全く聞こえない場合がある。
【0004】
一部の企業は、音響聴診器の欠点に対処するために、電子聴診器（「ステソフォン」とも称される）の開発を始めている。電子聴診器は、音を電子的に増幅することによって、音響聴診器を改善している。例えば、電子聴診器は、生体内で発生する微弱な音について、これらの音を増幅することにより対処し得る。このことを達成するために、電子聴診器は、チェストピースにあるマイクによって検出された音波を電気信号へと変換し、この電気信号を最適な聴音のために増幅する。
【図面の簡単な説明】
【0005】
【0006】
実施形態は、これらの図面において、限定ではなく例として示される。これらの図面は、説明の目的のために様々な実施形態を表しているが、当業者は、代替の実施形態が、本技術の原理から逸脱することなく採用され得ることを認識するであろう。したがって、図面には特定の実施形態が示されているが、本技術は様々な変更を受け入れる余地がある。
【発明の概要】
【0007】
電子聴診器システムは、以下でさらに論じるように、検査中の生体内及び生体外から発生する音を同時にモニタリングするように設計可能である。以下でさらに論じるように、電子聴診器システムは、ハブユニットに接続された１つ以上の入力ユニットを含み得る。各入力ユニットは、生体内で発生する内部音を示す音声データを生成するように構成された少なくとも１つのマイクへ音波を向けるように設計された円錐形共振器を有し得る。これらのマイクは、「聴診マイク」と称されることがある。さらに、各入力ユニットは、生体外で発生する外部音を示す音声データを生成するように構成された少なくとも１つのマイクを含み得る。これらのマイクは、「周囲マイク」又は「環境マイク」と称されることがある。
【0008】
説明の目的で、「周囲マイク」は、「周囲音」を示す音声データを生成可能であると説明されることがある。しかしながら、これらの「周囲音」には、概して、次の３つの異なる音源から生成される外部音の組み合わせが含まれる：（１）周囲環境から発生する音、（２）入力部から漏れる音、（３）検査中の生体を透過する音。外部音の例には、入力ユニットから直接発生する音（例えば、指又は胸で擦れる音）、及び、入力ユニットを透過する低周波環境ノイズが含まれる。
【0009】
内部音と外部音を別々に録音することには、いくつかの利点がある。特に、内部音を電子的に増幅し得ると同時に、外部音を電子的に低減（dampen）、減衰（attenuate）又はフィルタリングし得る。したがって、電子聴診器システムは、内部音及び外部音を示す音声データを操作することによって、検査中の生体内から発生する微弱な音に対処し得る。しかしながら、操作によって望ましくないデジタルアーチファクトが発生し、内部音の解釈が難しくなることがある。例えば、これらのデジタルアーチファクトによって、聴診マイクによって生成された、吸息又は呼息を示す音声データの値のパターンを識別することが、より困難になることがある。
【0010】
本願では、電子聴診器システムによって生成された音声データの分析を通じて患者の健康に関する洞察を導出するためのコンピュータプログラム、及び、関連するコンピュータ実装技術を提示する。診断プラットフォーム（「診断プログラム」又は「診断アプリケーション」とも称される）は、電子聴診器システムによって生成された音声データを検査して、患者の健康に関する洞察を得る役割を担い得る。以下でさらに論じるように、診断プラットフォームは、機械学習（ＭＬ）又は人工知能（ＡＩ）に依存するヒューリスティック、アルゴリズム又はモデルを採用してもよく、それによって、医療専門家による視覚分析に依存する従来のアプローチよりも大幅に優れた方法で聴診を実行し得る。
【発明を実施するための形態】
【0011】
例えば、診断プラットフォームが、患者に接続された電子聴診器システムによって生成された音声データに基づいて、患者の呼吸数を推定する役割を担っていると仮定する。用語「呼吸数」は、１分間に行われる呼吸の数を示す。安静時の成人の場合、毎分１２～２５回の呼吸数が正常と見なされる。安静時の呼吸数が毎分１２回未満であるか、毎分２５回を超えると、その呼吸数は異常と見なされる。呼吸数は健康の重要な指標であるため、「バイタルサイン」と称されることがある。そのため、呼吸数についての知識は、患者に適切なケアを提供するために重要なことがある。
【0012】
上述のように、電子聴診器システムは、内部音を示す音声データと、外部音を示す音声データとを生成し得る。これらの前者は「第１の音声データ」又は「内部音声データ」と称されることがあり、後者は「第２の音声データ」又は「外部音声データ」と称されることがある。いくつかの実施形態では、診断プラットフォームは、第２の音声データを利用して、第１の音声データを改善する。したがって、診断プラットフォームは、第２の音声データを検査して、もし操作するのであれば、外部音の影響を軽減するために第１の音声データをどのように操作するべきかについて決定し得る。例えば、診断プラットフォームが第２の音声データの分析を通じて外部音を発見した場合、診断プラットフォームは、（例えば、吸息、呼息などに対応する）目的となる内部音を歪めることなく外部音を除去するために、第１の音声データを取得して該第１の音声データにフィルタを適用してもよい。該フィルタは、第２の音声データの分析に基づいて診断プラットフォームによって生成されてもよく、第２の音声データの分析に基づいて診断プラットフォームによって（例えば、複数のフィルタの中から）識別されてもよい。
【0013】
次に、診断プラットフォームは、コンピュータ実装されたモデル（又は、単に「モデル」）を第１の音声データに適用し得る。該モデルは、呼吸における別個の段階、すなわち、吸息と呼息とを識別するように設計及び訓練され得る。該モデルは、１つ以上の人工ニューラルネットワーク（又は、単に「ニューラルネットワーク」）に基づくディープラーニングモデルであり得る。ニューラルネットワークは、複雑な入力を処理するために連携する複数のＭＬアルゴリズムのフレームワークである。ニューラルネットワークは、人間や動物の脳を構成する生物学的ニューラルネットワークに触発されたものであり、タスク固有のルールによってプログラムされていなくても、実例を検討することでタスクを実行することを「学習」できる。例えば、ニューラルネットワークは、「吸息」、「呼息」又は「吸息又は呼息なし」としてラベル付けされた一連の音声データを検査することによって、吸息と呼息とを識別することを学習し得る。これらの一連の音声データは、「訓練データ」と称されることがある。訓練に対するこのアプローチによって、ニューラルネットワークは、一連の音声データから、その特徴の存在によって吸息及び呼息を示す特徴を自動的に学習することが可能になる。例えば、ニューラルネットワークは、呼息を示す音声データの値のパターン、並びに、吸息を示す音声データの値のパターンを理解するようになり得る。
【0014】
モデルによって生成された出力は役に立ち得るが、その一方で解釈が難しいことがある。例えば、診断プラットフォームは、患者の監視、検査又は診断を担当する医療専門家によるレビューのために、第１の音声データの視覚的表現（「視覚化」とも称される）を生成し得る。診断プラットフォームは、視覚化の分かりやすさを改善するために、吸息又は呼息を視覚的に強調表示してもよい。例えば、診断プラットフォームは、視覚化にデジタル要素（「グラフィック要素」とも称される）を重ねて、患者が息を吸ったことを示し得る。以下でさらに論じるように、デジタル要素は、モデルによって決定された吸息の開始から、モデルによって決定された呼息の終わりまで及び得る。モデルによって生成された出力をよりわかりやすい方法で説明することにより、診断プラットフォームは、それらの出力に依存する医療専門家との信頼を築くことができる。
【0015】
さらに、診断プラットフォームは、モデルによって生成された出力を利用して、患者の健康に関する洞察を得てもよい。例えば、上記のように吸息と呼息とを識別するために、患者に関連付けられた音声データにモデルが適用されると仮定する。このような状況では、診断プラットフォームは、それらの出力を利用して測定基準を生成することがある。このような測定基準の一例は、呼吸数である。上記のように、用語「呼吸数」は、１分間に行われる呼吸の数を示す。しかしながら、直前の１分間における実際の呼吸数を数えることは、実際的ではない。たとえ限定的な時間の間であっても、患者が酸素欠乏症を被ると、重大な不可逆的損傷が生じることがある。したがって、医療専門家にとっては、ほぼリアルタイムで更新される呼吸数について一貫した洞察を得ることが重要である。これを達成するために、診断プラットフォームは、スライディングウィンドウアルゴリズムを使用して、呼吸数を継続的に計算し得る。大まかに言えば、該アルゴリズムは、音声データの一部を含むウィンドウを定義した後、ウィンドウを継続的にスライドさせることによって、音声データの種々異なる部分をカバーする。以下でさらに論じるように、該アルゴリズムは、所定の数の吸息又は呼息が常にその境界内に含まれるように、ウィンドウを調整し得る。例えば、該アルゴリズムは、ウィンドウの境界内に３回の吸息が含まれるようにプログラムされ得る。このとき、１回目の吸息はウィンドウの「開始」を表し、３回目の吸息はウィンドウの「終了」を表す。続いて、診断プラットフォームは、該ウィンドウに含まれる吸息間の間隔に基づいて、呼吸数を計算することができる。
【0016】
例示の目的で、実施形態は、コンピューティングデバイスによって実行可能な命令のコンテキストで説明され得る。しかしながら、本技術の態様は、ハードウェア、ファームウェア、ソフトウェア又はそれらの任意の組み合わせを介して実装可能である。一例として、モデルは、患者の吸息及び呼息を表す出力を識別するために、電子聴診器システムによって生成される音声データに適用されてもよい。そして、該モデルによって生成された出力に対し、患者の呼吸数を示す測定基準を生成するためにアルゴリズムが適用されてもよい。
【0017】
実施形態は、特定のコンピューティングデバイス、ネットワーク及び医療専門家及び施設を参照して説明され得る。しかしながら、当業者は、これらの実施形態の特徴が、他のコンピューティングデバイス、ネットワーク及び医療専門家及び施設に同様に適用可能であることを認識するであろう。例えば、実施形態は深層ニューラルネットワークの文脈で説明され得るが、診断プラットフォームによって採用されるモデルは、深層信念ネットワーク、回帰型ニューラルネットワーク及び畳み込みニューラルネットワーク等の、別の深層学習アーキテクチャに基づくものであってもよい。
【0018】
用語
本出願を通じて使用される用語、略語及び語句の簡単な定義を以下に示す。
本出願を通じて使用される用語、略語及び語句の簡単な定義を以下に示す。
【0019】
用語「接続」、「結合」及びその任意の変形は、直接的又は間接的な、２つ以上の要素間の任意の接続又は結合を含むことが意図される。接続又は結合は、物理的、論理的又はそれらの組み合わせであり得る。例えば、オブジェクトは、物理的な接続を共有していなくても、互いに電気的又は通信的に接続されていることがある。
【0020】
用語「モジュール」は、ソフトウェア、ファームウェア、ハードウェア又はそれらの任意の組み合わせを介して実装されるコンポーネントを広く示すために使用され得る。概して、モジュールは、１つ以上の入力に基づいて１つ以上の出力を生成する機能コンポーネントである。コンピュータプログラムは、１つ以上のモジュールを含み得る。したがって、コンピュータプログラムは、種々異なるタスクの完了を担う複数のモジュールを含んでいてもよく、全てのタスクの完了を担う単一のモジュールを含んでいてもよい。
【0021】
電子聴診器システムの概要
図１Ａは、電子聴診器システム用の入力ユニット１００の上面斜視図を含む。便宜上、入力ユニット１００は、「聴診器パッチ」と称されることがあるが、聴診に必要なコンポーネントのサブセットのみを含んでいてもよい。入力ユニット１００は、身体の胸部に取り付けられることが多いため、「チェストピース」と称されることもある。しかしながら、当業者は、入力ユニット１００が身体の他の部分（例えば、首、腹部又は背中）にも同様に取り付けられ得ることを認識するであろう。
図１Ａは、電子聴診器システム用の入力ユニット１００の上面斜視図を含む。便宜上、入力ユニット１００は、「聴診器パッチ」と称されることがあるが、聴診に必要なコンポーネントのサブセットのみを含んでいてもよい。入力ユニット１００は、身体の胸部に取り付けられることが多いため、「チェストピース」と称されることもある。しかしながら、当業者は、入力ユニット１００が身体の他の部分（例えば、首、腹部又は背中）にも同様に取り付けられ得ることを認識するであろう。
【0022】
以下でさらに論じるように、入力ユニット１００は、検査中の身体内の生物学的活動を表す音波を収集し、該音波を電気信号に変換し、その後に（例えば、より簡単な伝送のため、より高い忠実度を確実にするため、等の目的で）該電気信号をデジタル化することができる。入力ユニット１００は、剛性材料から構成される構造体１０２を含み得る。通常、構造体１０２は、ステンレス鋼、アルミニウム、チタン又は適切な金属合金等の金属により構成される。構造体１０２を作製するには、典型的には、溶融金属がダイカストされた後、適切な形状に機械加工されるか押し出されることになる。
【0023】
いくつかの実施形態では、入力ユニット１００は、構造体１０２が周囲環境にさらされるのを防止するケーシングを含む。例えば、ケーシングは、汚染を防止したり、洗浄性を向上させたりし得る。概して、ケーシングは、その底面に沿って配置された円錐形共振器を除いて、構造体１０２の実質的に全てを被包する。円錐形共振器については、図１Ｂ～Ｃに関して以下でより詳細に説明する。ケーシングは、シリコンゴム、ポリプロピレン、ポリエチレン又は任意の他の適切な材料から構成され得る。さらに、いくつかの実施形態では、ケーシングは、その添加剤の存在によって微生物の増殖、紫外線（ＵＶ）分解などを抑制する添加剤を含む。
【0024】
図１Ｂ～Ｃは、入力ユニット１００の底面斜視図を含み、入力ユニット１００は、遠位部分１０４及び近位部分１０６を有する構造体１０２を含む。聴診プロシージャを開始するために、ある個人（例えば、医師又は看護師などの医療専門家）は、入力ユニット１００の近位部分１０６を、検査中の身体の表面に対して固定することができる。入力ユニット１００の近位部分１０６は、円錐形共振器１１０の幅広開口部１０８を含み得る。円錐形共振器１１０は、幅広開口部１０８を通して収集された音波を幅狭開口部１１２に向けるように設計されてもよく、これらの音波が聴診マイクに導かれ得る。従来では、幅広開口部１０８は、約３０～５０ミリメートル（ｍｍ）、３５～４５ｍｍ又は３８～４０ｍｍである。しかしながら、本明細書に記載の入力ユニット１００は、自動利得制御機能を有することができるため、より小さい円錐形共振器が使用されてもよい。例えば、いくつかの実施形態では、幅広開口部１０８は、３０ｍｍ、２０ｍｍ又は１０ｍｍ未満である。したがって、本明細書に記載の入力ユニットは、種々異なるサイズを有する円錐形共振器や、種々異なる用途向けに設計された円錐形共振器等の、多種多様な円錐形共振器をサポート可能であり得る。
【0025】
用語「遠位」及び「近位」に関し、別段の指定がない限り、これらの用語は、入力ユニット１００の身体に対する相対的な位置を示す。例えば、身体への固定に適した入力ユニット１００を参照する場合、「遠位」は、デジタル信号を伝達するのに適したケーブルが入力ユニット１００に接続され得る場所に近い第１の位置を示すことができ、「近位」は、入力ユニット１００が身体に接触する場所に近い第２の位置を示すことができる。
【0026】
図２は、電子聴診器システム用の入力ユニット２００の断面側面図を含む。多くの場合、入力ユニット２００は、その構造体２０２内に画定された内部空洞を有する構造体２０２を含む。入力ユニット２００の構造体２０２は、内部空洞内に存在するマイクに向かって音波を向けるように設計された円錐形共振器２０４を有し得る。いくつかの実施形態では、ダイヤフラム２１２（「振動膜」とも称される）は、円錐形共振器２０４の幅広開口部（「外側開口部」とも称される）を横切って延在する。ダイヤフラム２１２は、多くの場合肺によって生成されるような高音を聴音するために使用することができる。ダイヤフラム２１２は、エポキシガラス繊維化合物又はガラス繊維で構成された薄いプラスチックディスクから形成することができる。
【0027】
円錐形共振器２０４によって収集される音波の明瞭さを改善するために、入力ユニット２００は、種々異なる位置から発生する音を同時にモニタリングするように設計され得る。例えば、入力ユニット２００は、検査中の体内から発生する音と、周囲環境から発生する音とを同時にモニタリングするように設計され得る。したがって、入力ユニット２００は、内部音を示す音声データを生成するように構成された少なくとも１つのマイク２０６（「聴診マイク」と称される）と、周囲音を示す音声データを生成するように構成された少なくとも１つのマイク２０８（「周囲マイク」と称される）とを含むことができる。各聴診マイク及び周囲マイクは、音波を電気信号に変換可能な変換器を含み得る。その後、聴診及び周囲マイク２０６，２０８によって生成された電気信号は、ハブユニットに送信する前にデジタル化され得る。デジタル化によって、ハブユニットは複数の入力ユニットから受信した信号を容易にクロッキング（clock）又は同期できる。デジタル化はまた、入力ユニットからハブユニットによって受信された信号が、他の方法によって可能であり得る忠実度よりも高い忠実度を有することを保証し得る。
【0028】
これらのマイクは、あらゆる方向から音を拾うように設計された無指向性マイクであってもよく、特定の方向から来る音を拾うように設計された指向性マイクであってもよい。例えば、入力ユニット２００は、円錐形共振器２０４の外側開口部に隣接する空間から生じる音を拾うように向けられた（１つ以上の）聴診マイク２０６を含み得る。そのような実施形態では、（１つ以上の）周囲マイク２０８は、無指向性マイクであってもよく、指向性マイクであってもよい。別の例としては、ノイズ及び干渉を低減するために高度に指向性である周囲音を捕捉可能な位相配列（phased array）を形成するように、一組の周囲マイク２０８を入力ユニット２００の構造体２０２内に等間隔に配置することができる。これによって、（１つ以上の）聴診マイク２０６は、入ってくる内部音の経路（「聴診経路」とも称される）に集中するように配置され得ると共に、（１つ以上の）周囲マイク２０８は、入ってくる周囲音の経路（「周囲経路」とも称される）に集中するように配置され得る。
【0029】
従来では、電子聴診器は、音波を示す電気信号を、望ましくないアーチファクトをフィルタリングする役割を担うデジタル信号処理（ＤＳＰ）アルゴリズムにかけていた。しかしながら、このようなアクションは、特定の周波数範囲（例：１００～８００Ｈｚ）内のほぼ全ての音を抑制する可能性があり、それによって目的となる内部音（例：吸息、呼息又は心拍に対応する音）を大幅に歪ませることがあった。しかしながら、本明細書では、プロセッサは、聴診マイク２０６によって生成された音声データと周囲マイク２０８によって生成された音声データを別々に検査するアクティブノイズキャンセルアルゴリズムを使用することができる。より具体的には、プロセッサは、周囲マイク２０８によって生成された音声データを解析し、それによって、聴診マイク２０６によって生成された音声データをどのように修正すべきかを決定し得る。例えば、プロセッサは、特定のデジタル特徴が、（例えば、該特徴が内部音に対応しているため）増幅されるべきであること、（例えば、該特徴が周囲音に対応しているため）減衰されるべきであること、又は、（例えば、該特徴がノイズを表しているため）完全に削除されるべきであることを検出し得る。そのような技術は、入力ユニット２００によって記録された音の明瞭さ、詳細及び品質を改善するために使用可能である。例えば、ノイズキャンセルアルゴリズムの適用は、少なくとも１つの入力ユニット２００を含む電子聴診器システムによって採用されるノイズ除去プロセスの不可欠な部分であり得る。
【0030】
プライバシーの目的で、円錐形共振器２０４が身体から離れるように向けられている間に、（１つ以上の）聴診マイク２０６も（１つ以上の）周囲マイク２０８も、記録が許可されないことがある。したがって、いくつかの実施形態では、（１つ以上の）聴診マイク２０６及び／又は（１つ以上の）周囲マイク２０８は、入力ユニット２００が身体に取り付けられるまで、記録を開始しない。そのような実施形態では、入力ユニット２００は、構造体２０２が体の表面に適切に固定されているかどうかを決定する役割を担う１つ以上の取り付けセンサ２１０ａ～ｃを含み得る。
【0031】
入力ユニット２００は、本明細書に示される取り付けセンサの任意のサブセットを含むことができる。例えば、いくつかの実施形態では、入力ユニット２００は、円錐形共振器２０４の幅広開口部の近くに配置された取り付けセンサ２１０ａ～ｂのみを含む。別の例としては、いくつかの実施形態では、入力ユニット２００は、円錐形共振器２０４の幅狭開口部（「内側開口部」とも称される）の近くに配置された取り付けセンサ２１０ｃのみを含む。さらに、入力部２００は、種々異なる種類の装着センサを含み得る。例えば、取り付けセンサ２１０ｃは、円錐形共振器２０４を通して光（例えば、赤外光）を放射すると共に、反射されて円錐形共振器２０４内へと戻る光に基づいて入力ユニット２００と該構造体との間の距離を決定するように設計された、光学近接センサであってもよい。別の例として、取り付けセンサ２１０ａ～ｃは、高周波信号の減衰を決定するようにプログラムされたアルゴリズムの助けを借りて、周囲ノイズ（「環境ノイズ」とも称される）の存在に基づき、構造体２０２が身体の表面に対して確実に封止されているかどうかを決定するように設計された音声センサであってもよい。別の例として、取り付けセンサ２１０ａ～ｂは、印加された圧力の量に基づき、構造体２０２が身体の表面に対して確実に封止されているかどうかを決定するように設計された圧力センサであってもよい。入力ユニット２００のいくつかの実施形態は、これらの種々異なるタイプの取り付けセンサのそれぞれを含む。これらの取り付けセンサ２１０ａ～ｃの出力を前述のアクティブノイズキャンセルアルゴリズムと組み合わせて考慮することにより、プロセッサは、取り付け状態を動的に決定することが可能であり得る。すなわち、プロセッサは、これらの取り付けセンサ２１０ａ～ｃの出力に基づいて、入力ユニット２００が身体に対して封止を形成しているどうかを決定することが可能であり得る。
【0032】
図３は、１つ以上の入力ユニット３０２ａ～ｎがどのようにハブユニット３０４に接続されて電子聴診器システム３００が形成されるかを示す。いくつかの実施形態では、複数の入力ユニットがハブユニット３０４に接続される。例えば、電子聴診器システム３００は、４つの入力ユニット、６つの入力ユニット又は８つの入力ユニットを含んでいてもよい。概して、電子聴診器システム３００は、少なくとも６つの入力ユニットを含むことになる。複数の入力ユニットを備えた電子聴診器システムは、「多チャンネル聴診器」と称されることがある。他の実施形態では、１つの入力ユニットのみがハブユニット３０４に接続される。例えば、単一の入力ユニットは、複数の入力ユニットのアレイをシミュレートするような方法で、身体全体にわたって移動させられ得る。１つの入力ユニットを有する電子聴診器システムは、「単一チャネル聴診器」と称されることがある。
【0033】
図３に示すように、各入力ユニット３０２ａ～ｎは、対応するケーブル３０６ａ～ｎを介してハブユニット３０４に接続することができる。概して、各入力ユニット３０２ａ～ｎとハブユニット３０４との間に対応するケーブル３０６ａ～ｎを介して形成される伝送経路は、実質的に干渉がないように設計される。例えば、電子信号は、ハブユニット３０４への伝送前に入力ユニット３０２ａ～ｎによってデジタル化されてもよく、また、信号の忠実度が、電磁ノイズの発生／汚染を妨げることによって確保されてもよい。ケーブルの例には、リボンケーブル、同軸ケーブル、ユニバーサルシリアルバス（ＵＳＢ）ケーブル、高解像度マルチメディアインタフェース（ＨＤＭＩ）ケーブル、ＲＪ４５イーサネットケーブル、及び、デジタル信号の伝達に適した他のケーブルが含まれる。各ケーブルは、ハブユニット３０４に（例えば、物理ポートを介して）接続された第１端と、対応する入力ユニットに（例えば、物理ポートを介して）接続された第２端とを含む。したがって、各入力ユニット３０２ａ～ｎは単一の物理ポートを含んでいてもよく、またハブユニット３０４は複数の物理ポートを含んでいてもよい。あるいは、入力ユニット３０２ａ～ｎの全てをハブユニット３０４に接続するために、単一のケーブルが使用されてもよい。そのような実施形態では、ケーブルは、ハブユニット３０４とインタフェース可能な第１端と、それぞれが単一の入力ユニットとインタフェース可能な一連の第２端とを含むことができる。そのようなケーブルは、例えば、第２端の数に基づいて、「１対２ケーブル」、「１対４ケーブル」又は「１対６ケーブル」と称されることがある。
【0034】
ハブユニット３０４に接続された入力ユニット３０２ａ～ｎの全てが聴診モードにある際、電子聴診器システム３００は、内部音を周囲音と比較するようにプログラムされた適応利得制御アルゴリズムを採用することができる。適応利得制御アルゴリズムは、対象の聴診音（例えば、正常呼吸音、笛声音（wheezing）、捻髪音、水泡音（crackling）等）を分析して、適切な音レベルが達成されたかどうかを判断し得る。例えば、適応利得制御アルゴリズムは、音レベルが所定の閾値を超えているかどうかを決定し得る。適応利得制御アルゴリズムは、（例えば、２つの異なる段階で）最大１００倍の利得制御を実現するように設計され得る。利得レベルは、入力ユニットアレイ３０８内の入力ユニットの数や、各入力ユニット内の聴診マイクによって記録された音のレベルに基づいて適応的に調整され得る。いくつかの実施形態では、適応利得制御アルゴリズムは、フィードバックループの一部として展開するようにプログラムされる。したがって、適応利得制御アルゴリズムは、入力ユニットによって記録された音声に利得を適用し、音声が事前にプログラムされた強度閾値を超えているかどうかを判断し、その判断に基づいて追加の利得が必要かどうかを動的に判断し得る。
【0035】
電子聴診器システム３００は、後処理プロシージャ中に適応利得制御アルゴリズムを展開することができるため、入力ユニットアレイ３０８は、心臓、肺等によって生じる広範囲の音に関する情報を収集することが可能になり得る。入力ユニットアレイ３０８内の入力ユニット３０２ａ～ｎは、身体の表面に沿った（又は全く異なる身体上の）種々異なる解剖学的位置に配置可能であるため、種々異なるバイオメトリック特性（例えば、呼吸数、心拍数、又は、笛声音（wheezing）、捻髪音、水泡音（crackling）の程度等）に配置することができる）を、電子聴診器システム３００によって同時に監視することができる。
【0036】
図４は、電子聴診器システムの入力ユニット４００及びハブユニット４５０の例示的なコンポーネントを示す高レベルブロック図である。入力ユニット４００及びハブユニット４５０の実施形態は、図４に示されるコンポーネントの任意のサブセットや、ここでは図示されていない追加のコンポーネントを含むことができる。例えば、入力ユニット４００は、（例えば、皮膚の湿度に基づく）発汗、温度等の身体のバイオメトリック特性をモニタリング可能なバイオメトリックセンサを含んでいてもよい。加えて又はこれに代えて、バイオメトリックセンサは、呼吸パターン（breathing pattern）（「呼吸パターン（respiratory pattern）」とも称される）のモニタリング、心臓の電気的活動も記録等を行うように設計されてもよい。別の例として、入力ユニット４００は、ジェスチャ、向き又は位置を導出し得るデータを生成可能な慣性測定ユニット（ＩＭＵ）を含んでいてもよい。ＩＭＵは、オブジェクトの力、角速度、傾斜及び／又は磁場を測定するように設計された電子部品である。概して、ＩＭＵには、加速度計、ジャイロスコープ、磁力計又はそれらの任意の組み合わせが含まれる。
【0037】
入力ユニット４００は、１つ以上のプロセッサ４０４、無線送受信器４０６、１つ以上のマイク４０８、１つ以上の取り付けセンサ４１０、メモリ４１２、及び／又は、電力インタフェース４１６に電気的に結合された電力コンポーネント４１４を含むことができる。これらのコンポーネントは、ハウジング４０２（「構造体」とも称される）内に存在し得る。
【0038】
上述のように、マイク４０８は、音響音波を電気信号に変換することができる。マイク４０８は、内部音を示す音声データを生成するように構成された聴診マイク、周囲音を示す音声データを生成するように構成された周囲マイク、又は、それらの任意の組み合わせを含み得る。電気信号の値を表す音声データは、少なくとも一時的に、メモリ４１２内に格納することができる。いくつかの実施形態では、（１つ以上の）プロセッサ４０４は、ハブユニット４５０に向かう下流への伝送の前に、音声データを処理する。例えば、（１つ以上の）プロセッサ４０４は、デジタル信号処理、ノイズ除去、利得制御、ノイズキャンセル、アーチファクト除去、特徴識別等のために設計されたアルゴリズムを適用し得る。他の実施形態では、ハブユニット４５０に向かう下流への伝送の前に、最小限の処理が（１つ以上の）プロセッサ４０４によって事前に実行される。例えば、（１つ以上の）プロセッサ４０４は、入力ユニット４００のアイデンティティを特定するメタデータを音声データに単純に追加してもよく、マイク４０８によって音声データに既に追加されているメタデータを検査してもよい。
【0039】
いくつかの実施形態では、入力ユニット４００及びハブユニット４５０は、対応するデータインタフェース４１８，４７０間に接続されたケーブルを介して、互いの間でデータを伝送する。例えば、（１つ以上の）マイク４０８によって生成された音声データは、ハブユニット４５０のデータインタフェース４７０への送信のために、入力ユニット４００のデータインタフェース４１８へと転送され得る。あるいは、データインタフェース４７０は、無線送受信器４５６の一部であってもよい。無線送受信器４０６は、ハブユニット４５０の無線送受信器４５６との無線接続を自動的に確立するように構成され得る。無線送受信器４０６，４５６は、近距離無線通信（ＮＦＣ）、ワイヤレスＵＳＢ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ－Ｆｉ（登録商標）、セルラーデータプロトコル（例えば、ＬＴＥ、３Ｇ、４Ｇ又は５Ｇ）、又は、独自のポイントツーポイントプロトコル等の双方向通信プロトコルを介して、互いに通信し得る。
【0040】
入力ユニット４００は、必要に応じて、ハウジング４０２内に存在する他のコンポーネントに電力を供給可能な電力コンポーネント４１４を含み得る。同様に、ハブユニット４５０は、ハウジング４５２内に存在する他のコンポーネントに電力を供給可能な電力コンポーネント４６６を含むことができる。電力コンポーネントの例には、再充電可能なリチウムイオン（Ｌｉ－Ｉｏｎ）電池、再充電可能なニッケル水素（ＮｉＭＨ）電池、再充電可能なニッケルカドミウム（ＮｉＣａｄ）電池等が含まれる。入力ユニット４００は、専用の電力コンポーネントを含んでおらず、そのためハブユニット４５０から電力を受ける必要がある。（例えば、電気接点の物理的接続を介して）電力の伝達を容易にするように設計されたケーブルが、入力ユニット４００の電力インタフェース４１６とハブユニット４５０の電力インタフェース４６８との間に接続され得る。
【0041】
電力チャネル（すなわち、電力インタフェース４１６と電力インタフェース４６８との間のチャネル）及びデータチャネル（すなわち、データインタフェース４１８とデータインタフェース４７０との間のチャネル）は、別個のチャネルとして示されているが、これは例示のみを目的としている。当業者は、これらのチャネルを同一のケーブル内に含めることができることを認識するであろう。したがって、データ及び電力を運搬可能な単一のケーブルが、入力ユニット４００とハブユニット４５０との間に結合されてもよい。
【0042】
ハブユニット４５０は、１つ以上のプロセッサ４５４と、無線送受信器４５６と、ディスプレイ４５８と、コーデック４６０と、１つ以上の発光ダイオード（ＬＥＤ）表示器４６２と、メモリ４６４と、電力コンポーネント４６６とを含むことができる。これらのコンポーネントは、ハウジング４５２（「構造体」とも称される）内に存在し得る。上述のように、ハブユニット４５０の実施形態は、これらのコンポーネントの任意のサブセットや、ここに示されていない追加のコンポーネントを含み得る。
【0043】
図４に示されるように、ハブユニット４５０の実施形態は、検査中の個人の呼吸状態又は心拍数、ネットワーク接続状態、電力接続状態、入力ユニット４００のための接続状態等の情報を提示するためのディスプレイ４５８を含み得る。ディスプレイ４５８は、触覚入力機構（例えば、ハウジング４５２の表面に沿ってアクセス可能なボタン）、音声入力機構（例えば、マイク）等を介して制御され得る。別の例として、ハブユニット４５０のいくつかの実施形態は、ディスプレイ４５８ではなく、操作ガイダンスのための（１つ以上の）ＬＥＤ表示器４６２を含む。そのような実施形態では、（１つ以上の）ＬＥＤ表示器４６２は、ディスプレイ４５８によって提示されるものと同様の情報を伝え得る。別の例として、ハブユニット４５０のいくつかの実施形態は、ディスプレイ４５８及び（１つ以上の）ＬＥＤ表示器４６２を含む。
【0044】
入力ユニット４００のマイク４０８によって生成された電気信号を表す音声データを受信すると、ハブユニット４５０は、着信データの復号化を担当するコーデック４６０に音声データを提供することができる。コーデック４６０は、例えば、編集、処理などに備えて音声データを（例えば、入力ユニット４００によって適用された符号化を逆にすることによって）デコードすることができる。入力ユニット４００内の（１つ以上の）聴診マイクと、入力ユニット４００内の（１つ以上の）周囲マイクによって生成された音声データとを含む。
【0045】
その後に、（１つ以上の）プロセッサ４５４は、音声データを処理することができる。入力ユニット４００の（１つ以上の）プロセッサ４０４と同様に、ハブユニット４５０の（１つ以上の）プロセッサ４５４は、デジタル信号処理、ノイズ除去、利得制御、ノイズキャンセル、アーチファクト除去、特徴識別等のために設計されたアルゴリズムを適用し得る。これらのアルゴリズムのいくつかは、入力ユニット４００の（１つ以上の）プロセッサ４０４によって既に適用されている場合には、不要であってもよい。例えば、いくつかの実施形態では、ハブユニット４５０の（１つ以上の）プロセッサ４５４は、音声データ内の診断に関連する特徴を発見するために（１つ以上の）アルゴリズムを適用するが他の実施形態では、（１つ以上の）プロセッサ４０４の入力ユニット４００が診断に関連する特徴を既に発見している場合には、そのようなアクションは不要であってもよい。あるいは、ハブユニット４５０は、以下でさらに論じるように、分析のために音声データを宛先（例えば、コンピューティングデバイス又は分散システム上で動作する診断プラットフォーム）へと転送することができる。概して、診断に関連する特徴は、所定のパターン定義パラメータにマッチする音声データの値のパターンに対応することになる。別の例として、いくつかの実施形態では、ハブユニット４５０のプロセッサ４５４は、信号対雑音（ＳＮＲ）比を改善するために音声データのノイズを低減するアルゴリズムを適用する一方で、他の実施形態では、これらのアルゴリズムは、入力ユニット４００のプロセッサ４０４によって適用される。
【0046】
電力インタフェース４６８に加えて、ハブユニット４５０は電力ポートを含み得る。電力ポート（「電力ジャック」とも称される）は、ハブユニット４５０を電源（例えば、電気コンセント）へと物理的に接続することを可能にする。電力ポートは、種々異なるコネクタタイプ（例えば、Ｃ１３、Ｃ１５、Ｃ１９等）と接続可能であってもよい。加えて又はこれに代えて、ハブユニット４５０は、外部源から無線で電力を受けることが可能な集積回路（「チップ」とも称される）を有する受電器を含んでいてもよい。同様に、入力ユニット４００は、例えば、入力ユニット４００とハブユニット４５０とがケーブルを介して互いに物理的に接続されていない場合に、外部源から無線で電力を受けることが可能なチップを有する受電器を含んでいてもよい。受電器は、ワイヤレスパワーコンソーシアム（Wireless Power Consortium）によって開発されたＱｉ標準、又は、何らかの他の無線電力標準に従って送信された電力を受けるように構成され得る。
【0047】
いくつかの実施形態では、ハブユニット４５０のハウジング４５２は音声ポートを含む。音声ポート（「音声ジャック」とも称される）は、音声等の信号をヘッドフォン等の付属品の適切なプラグへと伝送するために使用可能なレセプタクルである。音声ポートは、典型的には、適切なプラグが音声ポートに挿入された際に音声信号を容易に伝送可能にする１、２、３又は４つの接点を含む。例えば、ほとんどのヘッドフォンは、３．５ミリメートル（ｍｍ）の音声ポート用に設計されたプラグを含む。加えて又はこれに代えて、ハブユニット４５０の無線送受信器４５６は、音声信号を（例えば、ＮＦＣ、ワイヤレスＵＳＢ、Ｂｌｕｅｔｏｏｔｈ等を介して）無線ヘッドフォンへと直接伝送可能であってもよい。
【0048】
上述のように、入力ユニット４００のプロセッサ４０４及び／又はハブユニット４５０のプロセッサ４５４は、種々異なる機能をサポートするために、様々なアルゴリズムを適用することができる。そのような機能の例には、音声データ内において失われたデータパケットの減衰、ノイズに依存する音量制御、ダイナミックレンジ圧縮、自動利得制御、イコライゼーション、ノイズ抑制、音響エコーキャンセル等が含まれる。各機能は、メモリ（例えば、入力ユニット４００のメモリ４１２又はハブユニット４５０のメモリ４６４）内に常駐する別個のモジュールに対応し得る。したがって、入力ユニット４００及び／又はハブユニット４５０は、減衰モジュール、音量制御モジュール、圧縮モジュール、利得制御モジュール、イコライゼーションモジュール、ノイズ抑制モジュール、エコーキャンセルモジュール又はそれらの任意の組み合わせを含んでいてもよい。
【0049】
いくつかの実施形態では、入力ユニット４００は、マイク４０８によって生成された音声データを、ハブユニット４５０以外の宛先へと直接伝送するように構成されることに留意されたい。例えば、入力ユニット４００は、音声データを、該音声データの分析を担う診断プラットフォームへと伝送するために、無線送受信器４０６へと転送してもよい。音声データは、ハブユニット４５０の代わりに、又は、ハブユニット４５０に加えて、診断プラットフォームへと伝送されてもよい。音声データがハブユニット４５０に加えて診断プラットフォームに転送される場合、入力ユニット４００は、音声データの複製コピーを生成してもよく、その後、それらの個別のコピーをその先に（例えば、診断プラットフォームへと伝送するために無線送受信器４０６へと、ハブユニット４５０へと伝送するためにデータインタフェース４１８へと）転送してもよい。以下でさらに論じるように、診断プラットフォームは、通常、入力ユニット４００に通信可能に接続されたコンピューティングデバイス上に存在するが、診断プラットフォームの態様は、入力ユニット４００又はハブユニット４５０上に存在する可能性がある。
【0050】
電子聴診器システムに関する追加の情報は、米国特許第１０，５５５，７１７号に見られ、参照によりその全体が本明細書に組み込まれる。
【0051】
診断プラットフォームの概要
図５は、診断プラットフォーム５０２を含むネットワーク環境５００を示す。個人は、インタフェース５０４を介して、診断プラットフォーム５０２と対話することができる。例えば、患者が、音声データ、病気、治療及びフィードバックに関する情報が提供され得るインタフェースにアクセス可能であってもよい。別の例として、医療専門家が、適切な診断の決定、健康の監視等の目的で、音声データ及び音声データの分析をレビュー可能なインタフェースにアクセス可能であってもよい。大まかに言えば、インタフェース５０４は、患者又は医療専門家のいずれかのための情報価値のあるダッシュボードとして機能することが意図され得る。
図５は、診断プラットフォーム５０２を含むネットワーク環境５００を示す。個人は、インタフェース５０４を介して、診断プラットフォーム５０２と対話することができる。例えば、患者が、音声データ、病気、治療及びフィードバックに関する情報が提供され得るインタフェースにアクセス可能であってもよい。別の例として、医療専門家が、適切な診断の決定、健康の監視等の目的で、音声データ及び音声データの分析をレビュー可能なインタフェースにアクセス可能であってもよい。大まかに言えば、インタフェース５０４は、患者又は医療専門家のいずれかのための情報価値のあるダッシュボードとして機能することが意図され得る。
【0052】
図５に示されるように、診断プラットフォーム５０２は、ネットワーク環境５００内に存在し得る。したがって、診断プラットフォーム５０２は、１つ以上のネットワーク５０６ａ～ｂに接続され得る。ネットワーク５０６ａ～ｂは、パーソナルエリアネットワーク（ＰＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、セルラーネットワーク、インターネット等を含むことができる。加えて又はこれに代えて、診断プラットフォーム５０２は、Ｂｌｕｅｔｏｏｔｈ、ＮＦＣ、Ｗｉ－Ｆｉ Ｄｉｒｅｃｔ（「Ｗｉ－Ｆｉ Ｐ２Ｐ」とも称される）等の短距離無線接続技術を介して、１つ以上のコンピューティングデバイスに通信可能に結合することができる。
【0053】
インタフェース５０４は、ウェブブラウザ、デスクトップアプリケーション、モバイルアプリケーション又はオーバーザトップ（ＯＴＴ）アプリケーションを介してアクセス可能であり得る。例えば、医療専門家は、患者に関する情報を入力可能なインタフェースにアクセス可能であってもよい。そのような情報には、名前、生年月日、診断、症状又は投薬が含まれ得る。あるいは、該情報は、診断プラットフォーム５０２によって（例えば、ネットワークアクセス可能なサーバシステム５０８内に格納されたデータに基づいて）インタフェース内に自動的に入力されてもよく、一方で、医療専門家は、必要に応じて該情報を調整することが許可されていてもよい。以下でさらに論じるように、医療専門家は、音声データ及び音声データの分析をレビューのために提示し得るインタフェースにアクセス可能であり得る。この情報によって、医療専門家は、患者の状態（例えば、呼吸しているか呼吸していないか）を容易に確立したり、（例えば、笛声音（wheezing）、捻髪音、水泡音（crackling）などの存在に基づいて）診断を下したり等を行うことが可能であり得る。したがって、インタフェース５０４は、モバイルワークステーション（「医療用カート」とも称される）、パーソナルコンピュータ、タブレットコンピュータ、携帯電話、ウェアラブル電子デバイス、及び、仮想又は拡張現実システム等のコンピューティングデバイス上で視認され得る。
【0054】
いくつかの実施形態では、診断プラットフォーム５０２の少なくともいくつかのコンポーネントが、ローカルでホストされる。すなわち、診断プラットフォーム５０２の一部は、インタフェース５０４のうちの１つにアクセスするために使用されるコンピューティングデバイス上に存在し得る。例えば、診断プラットフォーム５０２は、医療専門家に関連付けられた携帯電話上で実行されるモバイルアプリケーションとして実装され得る。しかしながら、モバイルアプリケーションは、診断プラットフォーム５０２の他のコンポーネントがホストされるネットワークアクセス可能なサーバシステム５０８に通信可能に接続されてもよいことに留意されたい。
【0055】
他の実施形態では、診断プラットフォーム５０２は、例えば、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅ（登録商標）、Ｇｏｏｇｌｅ Ｃｌｏｕｄ Ｐｌａｔｆｏｒｍ（登録商標）、又は、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅ（登録商標）によって運営されるクラウドコンピューティングサービスによって、その全てが実行される。そのような実施形態では、診断プラットフォーム５０２は、１つ以上のコンピュータサーバを備えたネットワークアクセス可能なサーバシステム５０８上に存在していてもよい。これらのコンピュータサーバは、モデル、（例えば、音声データの処理、呼吸数の計算等のための）アルゴリズム、患者情報（例えば、プロフィール、資格情報、及び、年齢、生年月日、地理的位置、疾患の分類、病状、医療提供者等の健康関連情報等）、及び、その他のアセットを含むことができる。当業者であれば、該情報が、ネットワークアクセス可能なサーバシステム５０８と１つ以上のコンピューティングデバイスの間で分散されることもあり、ブロックチェーン等の分散ネットワークインフラストラクチャにわたって分散されることもあることを理解するであろう。
【0056】
図６は、患者の健康状態の変化の検出、診断及びモニタリングに役立つ出力を生成するように設計された診断プラットフォーム６１０を実装可能なコンピューティングデバイス６００の例を示す。以下でさらに論じるように、診断プラットフォーム６１０は、呼吸イベント（respiratory event）（「呼吸イベント（breathing event）」又は「呼吸（breath）」とも称される）の発生を識別するために、患者に関連付けられた音声データに対してモデルを適用し、続いて、患者の健康状態を把握するために、それらの呼吸イベントに対してアルゴリズムを適用することができる。用語「呼吸イベント（respiratory event）」及び「呼吸イベント（breathing event）」は、吸息又は呼息を示すために使用される場合がある。例えば、アルゴリズムは、以下でさらに論じるように、呼吸数を表す測定基準を出力し得る。したがって、診断プラットフォーム６１０は、診断に関連する音声データの値のパターンを発見することだけでなく、患者の現在の健康状態を理解するのに役立つ方法でそれらのパターンの視覚化を生成することも行い得る。例示の目的で、実施形態は、電子聴診器システムによって生成される音声データの文脈で説明され得る。しかしながら、当業者であれば、該音声データは別のソースから取得され得ることを認識するであろう。
【0057】
通常、コンピューティングデバイス６００は、医療専門家又はヘルスケア施設に関連付けられる。例えば、コンピューティングデバイス６００は、病院の手術室に配置されたモバイルワークステーションであってもよく、患者にサービスを提供しながら医療専門家がアクセス可能な携帯電話又はタブレットコンピュータであってもよい。あるいは、コンピューティングデバイス６００は、電子聴診器システムのハブユニットであってもよい。
【0058】
コンピューティングデバイス６００は、プロセッサ６０２と、メモリ６０４と、表示機構６０６と、通信モジュール６０８とを含むことができる。これらの各コンポーネントについては、以下でより詳細に論じる。当業者であれば、コンピューティングデバイス６００の性質に応じて、これらのコンポーネントの種々異なる組み合わせが存在し得ることを認識するであろう。
【0059】
プロセッサ６０２は、汎用プロセッサと同様の一般的な特性を有することが可能であり、又は、コンピューティングデバイス６００に制御機能を提供する特定用途向け集積回路（ＡＳＩＣ）であってもよい。図６に示されるように、プロセッサ６０２は、コンピューティングデバイス６００の全てのコンポーネントに対して、通信のために直接的又は間接的に接続され得る。
【0060】
メモリ６０４は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、電気的消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ又はレジスタ等の任意の適切なタイプの記憶媒体から構成され得る。プロセッサ６０２によって実行可能な命令を格納することに加えて、メモリ６０４は、（例えば、診断プラットフォーム６１０のモジュールを実行する際に）プロセッサ６０２によって生成されたデータを格納することも可能である。メモリ６０４は、記憶環境の単なる抽象的な表現であることに留意されたい。メモリ６０４は、実際のメモリチップ又はモジュールで構成され得る。
【0061】
表示機構６０６は、情報を視覚的に伝達するように動作可能な任意のコンポーネントであり得る。例えば、表示機構６０６は、ＬＥＤ、有機ＬＥＤ、液晶素子又は電気泳動素子を含むパネルであり得る。コンピューティングデバイス６００が電子聴診器システムのハブユニットを表す実施形態では、表示機構６０６は、ディスプレイパネル（例えば、図４のディスプレイ４５８）であってもよく、ＬＥＤ表示器（例えば、図４のＬＥＤ表示器４６２）であってもよい。いくつかの実施形態では、表示機構６０６は接触感知式である。したがって、個人は、表示機構６０６と対話することによって、診断プラットフォーム６１０に入力を提供可能であり得る。表示機構６０６が接触感知式でない実施形態では、個人は、キーボード、物理的要素（例えば、機械的なボタン又はノブ）又はポインティングデバイス（例えば、コンピュータのマウス）等の制御デバイス（図示せず）を使用して、診断プラットフォーム６１０と対話可能であり得る。
【0062】
通信モジュール６０８は、コンピューティングデバイス６００のコンポーネント間の通信を管理する役割を担ってもよく、他のコンピューティングデバイス（例えば、図５のネットワークアクセス可能なサーバシステム５０８）との通信を管理する役割を担ってもよい。通信モジュール６０８は、他のコンピューティングデバイスとの通信チャネルを確立するように設計された無線通信回路であり得る。無線通信回路の例には、セルラーネットワーク（「モバイルネットワーク」とも称される）のために構成されたアンテナモジュール、及び、ＮＦＣ、ワイヤレスＵＳＢ、Ｂｌｕｅｔｏｏｔｈのために構成されたチップ等が含まれる。
【0063】
便宜上、診断プラットフォーム６１０は、メモリ６０４内に常駐し、プロセッサ６０２によって実行されるコンピュータプログラムと称されることがある。しかしながら、診断プラットフォーム６１０は、コンピューティングデバイス６００に実装されるかコンピューティングデバイス６００にアクセス可能であるソフトウェア、ファームウェア又はハードウェアから構成され得る。本明細書に記載の実施形態によれば、診断プラットフォーム６１０は、訓練モジュール６１２と、処理モジュール６１４と、診断モジュール６１６と、分析モジュール６１８と、グラフィカルユーザインタフェース（ＧＵＩ）モジュール６２０とを含み得る。
【0064】
訓練モジュール６１２は、診断プラットフォーム６１０によって使用されるモデルを訓練することを担い得る。訓練は、教師あり、半教師あり又は教師なしの方法で行われ得る。例えば、訓練モジュール６１２が、音声データ中の呼吸イベントを識別するモデルを訓練するための要求を示す入力を受信すると仮定する。そのような状況では、訓練モジュール６１２は、訓練されていないモデルを取得し、続いて、例えば「呼吸イベント」又は「呼吸イベントなし」とラベル付けされた音声データを使用して該モデルを訓練し得る。したがって、ラベル付けされた音声データは、モデルがどのようにして呼吸イベントを識別するかを学習するように、訓練データとして該モデルへと提供され得る。通常、モデルは、呼吸イベントを示す音声データの値のパターンを識別することを学習することになる。
【0065】
処理モジュール６１４は、診断プラットフォーム６１０によって取得された音声データを、他のモジュールに適したフォーマットとなるように処理することができる。例えば、処理モジュール６１４は、診断モジュール６１６による分析に備えて、音声データに対してルール、ヒューリスティック又はアルゴリズムを適用し得る。別の例として、処理モジュール６１４は、分析モジュール６１８による分析に備えて、診断モジュール６１６によって生成された出力に対してルール、ヒューリスティック又はアルゴリズムを適用することができる。したがって、処理モジュール６１４は、適切なデータが診断プラットフォーム６１０の他のモジュールにアクセス可能であることを確実にする役割を担い得る。さらに、処理モジュール６１４は、診断プラットフォーム６１０の他のモジュールによって生成された出力が、（例えば、メモリ６０４内への）格納、又は、（例えば、通信モジュール６０８を介しての）伝送に適することを確実にする役割を担い得る。
【0066】
診断モジュール６１６は、診断プラットフォーム６１０によって取得された音声データに適用するための適切なモデルを識別する役割を担い得る。例えば、診断モジュール６１６は、音声データ、患者又は電子聴診器システムの属性に基づいて、適切なモデルを識別してもよい。これらの属性は、音声データに付随するメタデータ内で指定され得る。一例として、適切なモデルは、内部音が記録されている解剖学的領域に基づいて識別され得る。あるいは、診断モジュール６１６は、分析モジュール６１８によって生成される測定基準に基づいて、適切なモデルを識別してもよい。一例として、分析モジュール６１８が呼吸数を計算する役割を担う場合には、診断モジュール６１６は、続いて呼吸イベントを発見可能なモジュールを識別し得る。所望の（１つ以上の）測定基準は、医療専門家によって指定されてもよく、診断プラットフォーム６１０によって決定されてもよい。
【0067】
概して、診断モジュール６１６によって音声データに適用されるモデルは、メモリ６０４に維持される複数のモデルのうちの１つである。これらのモデルは、種々異なる呼吸イベント、病気等に関連付けられ得る。例えば、第１のモデルは、設計された後に吸息と呼息を識別するように訓練され、第２のモデルは、設計された後に、笛声音（wheezing）又は捻髪音、水泡音（crackling）のインスタンスを識別するように訓練され得る。
【0068】
大まかに言えば、各モデルは、音声データに適用される際に、患者の健康状態に関する洞察を提供し得る情報を伝達する出力を生成するアルゴリズムの集合（collection）を表し得る。例えば、診断モジュール６１６によって適用されるモデルが吸息及び呼息を識別する場合、該出力は、患者の呼吸が正常であるか異常であるかを確立するのに有用であり得る。別の例として、診断モジュール６１６によって適用されるモデルが笛声音（wheezing）又は捻髪音、水泡音（crackling）の事例を識別する場合、該出力は、患者が所与の疾患に罹患しているかどうかを確率するのに有用であり得る。
【0069】
いくつかの状況では、診断モジュール６１６によって適用されるモデルによって生成される出力は、それ自体では特に有用ではない。分析モジュール６１８は、これらの出力のコンテキストをより全体論的な意味で考慮する役割を担い得る。例えば、分析モジュール６１８は、診断モジュール６１６によって適用されるモデルによって生成された出力に基づいて、患者の健康を表す１つ以上の測定基準を生成し得る。これらの測定基準は、モデルによって生成された出力の完全な分析又は認識を必要とすることなく、患者の健康に関する洞察を提供し得る。例えば、診断モジュール６１６によって適用されるモデルが、音声データの分析に基づいて呼吸イベントを識別すると仮定する。呼吸イベントの知識は有用であり得る一方で、医療専門家は呼吸数などの測定基準により関心を示すことがある。分析モジュール６１８は、診断モジュール６１６によって識別された呼吸イベントに基づいて呼吸数を計算し得る。
【0070】
ＧＵＩモジュール６２０は、表示機構６０６上におけるレビューのために情報を提示する方法を確立する役割を担い得る。表示機構６０６の性質に応じて、様々なタイプの情報を提示が提示可能である。例えば、医療専門家に対して表示するために、診断モジュール６１６及び分析モジュール６１８によって導出され、推測され又は取得された情報がインタフェース上に提示され得る。別の例として、患者がいつ健康の変化を経験したかを示すために、視覚的フィードバックがインタフェース上に提示され得る。
【0071】
図７は、音声データの分析がレビューのためにインタフェース上に表示される前に、診断プラットフォームによって取得された音声データがバックグラウンドサービスによってどのように処理されるかを示すワークフロー図の例を含む。図７に示すように、データは診断プラットフォームの「バックエンド」によって取得及び処理される一方で、そのデータの分析は、診断プラットフォームの「フロントエンド」によって提示される。医療専門家や患者等の個人もまた、フロントエンドを介して診断プラットフォームと対話可能であり得る。例えば、コマンドは、ディスプレイに表示されたインタフェースを介して発行される。さらに、診断プラットフォームは、以下でさらに論じるように、通知を生成可能であり得る。例えば、患者の呼吸数が所定の閾値を下回っていると診断プラットフォームが判断した場合、診断プラットフォームは、アラームとして機能する通知を生成してもよい。該通知は、ディスプレイを介して視覚的に提示され得る、及び／又は、スピーカーを介して聴覚的に提示され得る。
【0072】
呼吸数を確立するためのアプローチ
呼吸数を計算する従来のアプローチには、いくつかの欠点がある。
呼吸数を計算する従来のアプローチには、いくつかの欠点がある。
【0073】
いくつかのアプローチは、吸息及び呼息を、比較的長い時間間隔で観測することに依存している。この「観測間隔」は、６０秒以上続くことも珍しくない。この観測間隔が非常に長いため、これらのアプローチでは、無呼吸のような短命のイベントを説明することができない。その結果、観測間隔全体にわたる呼吸数への影響がほとんどないため、医療専門家は、全く気付かないとは限らないが、呼吸の一時的な停止にほとんど気付かないおそれがある。呼吸の停止には即座に対処する必要があり得るため、呼吸数に対する理解を誤ると、重大な危害が生じる可能性がある。
【0074】
他のアプローチは、胸部の動き又は呼気空気中の呼気終末二酸化炭素（ＣＯ2）のモニタリングに依存している。しかしながら、これらのアプローチは、多くの事態において実際的又は適切ではない。例えば、胸部の動きは、特に患者が全身麻酔下にある又は医療イベント（発作など）を経験している場合において、呼吸イベントの正確な指標にならないことがあり、患者がマスクを着用していない場合には、呼気空気の組成が不明であることがある。
【0075】
本明細書では、音声データの分析を通じて呼吸数を計算することによって、これらの欠点に対処するアプローチを提示する。上述のように、このアプローチは、吸息及び呼息が一貫した正確な方法で検出されることに依存している。聴診では、これらの呼吸イベントは、医療専門家による診断決定のために重要である。
【0076】
大まかに言えば、このアプローチは、２つの段階、すなわち、吸息及び呼息が検出される第１の段階と、これらの吸息及び呼息が呼吸数を計算するために使用される第２の段階とを包含する。第１の段階は「検出段階」と称され、第２の段階は「計算段階」と称される。
【0077】
Ａ．呼吸イベントの検出
図８は、検出段階の間に診断プラットフォームによって採用され得る計算パイプラインの概要を示す。この計算パイプライン（「計算フレームワーク」とも称される）の利点の１つは、そのモジュール設計である。各「ユニット」は、個別にテストされた後、最高の全体的なパフォーマンスを達成するために調整されることができる。さらに、一部のユニットの出力は、複数の目的に使用され得る。例えば、前処理中に生成されたスペクトログラムは、入力としてモデルに提供されること、及び／又は、リアルタイムレビューのためのインタフェースに掲示されることができる。
図８は、検出段階の間に診断プラットフォームによって採用され得る計算パイプラインの概要を示す。この計算パイプライン（「計算フレームワーク」とも称される）の利点の１つは、そのモジュール設計である。各「ユニット」は、個別にテストされた後、最高の全体的なパフォーマンスを達成するために調整されることができる。さらに、一部のユニットの出力は、複数の目的に使用され得る。例えば、前処理中に生成されたスペクトログラムは、入力としてモデルに提供されること、及び／又は、リアルタイムレビューのためのインタフェースに掲示されることができる。
【0078】
単純化のため、このフレームワークは、前処理、分析及び後処理の３つの部分に分けられている。前処理は、音声データを処理することだけでなく、特徴エンジニアリング技術を採用することをも含み得る。分析は、呼吸イベントを識別するために訓練されたモデルを採用することを含み得る。上述のように、モデルは、出力として、単一の検出（例えば、分類又は診断）ではなく一連の検出（例えば、呼吸イベント）を生成するように設計されたニューラルネットワークを含み得る。各検出は、モデルによって独立して行われる個別の予測を表すことがある。最後に、後処理は、モデルによって生成された検出を検査及び／又は分割することを含み得る。通常、前処理は処理モジュール（例えば、図６の処理モジュール６１４）によって実行され、分析は診断モジュール（例えば、図６の診断モジュール６１６）によって実行され、後処理は分析モジュール（例えば、図６の分析モジュール６１８）によって実行される。
【0079】
各部分に関するさらなる詳細は、以下に一例の文脈において提供される。当業者であれば、以下に提供される数字が例示のみを意図していることを認識するであろう。フレームワークの重要な側面の１つはその柔軟性であり、そのため、他の状況では他の数値が適用可能又は適切であり得る。
【0080】
Ｉ．前処理
この例では、肺によって生じた内部音の記録を表す音声データを、４キロヘルツ（ｋＨｚ）に相当するサンプリング周波数で処理した。次に、この音声データに対してハイパスフィルタを次数１０、カットオフ周波数８０Ｈｚで適用し、電気的干渉（約６０Ｈｚ）、及び、心臓（約１～２Ｈｚ）又は別の内臓によって生じた内部音を除去した。これによって、診断プラットフォームは、目的でない別の内臓によって生じた音をフィルタリングするのに十分なカットオフ周波数を備えたハイパスフィルタを適用し得る。このフィルタリングされた音声データを、短時間フーリエ変換（ＳＴＦＴ）を使用して処理した。この例では、ＳＴＦＴは、ウィンドウサイズ２５６のハミングウィンドウと、オーバーラップ率０．２５とを有していた。これによって、約１５秒の信号を、９３８×１２９サイズの対応するスペクトログラムへと変換することができた。目的となる内部音のスペクトル情報を活用するために、診断プラットフォームは、（ｉ）スペクトログラム、（ｉｉ）メル周波数ケプストラム係数（ＭＦＣＣ）、及び、（ｉｉｉ）エネルギー合計を抽出した。この例では、スペクトログラムは、１２９ビンの対数振幅スペクトログラムであった。ＭＦＣＣについては、診断プラットフォームは、２０の静的係数、２０のデルタ係数及び２０の加速係数を抽出した。これを行うために、診断プラットフォームは、０～４，０００Ｈｚの周波数範囲内において、４０のＭｅｌバンドを使用した。デルタ係数及び加速係数の計算に使用される幅は、９フレームであった。これにより、フレームあたり６０ビンのベクトルが生成される。一方で、診断プラットフォームは、０～２５０Ｈｚ、２５１～５００Ｈｚ及び５０１～１，０００Ｈｚの３つの異なる周波数帯域のエネルギー合計を計算し、それによってフレーム毎に３つの値を得た。
この例では、肺によって生じた内部音の記録を表す音声データを、４キロヘルツ（ｋＨｚ）に相当するサンプリング周波数で処理した。次に、この音声データに対してハイパスフィルタを次数１０、カットオフ周波数８０Ｈｚで適用し、電気的干渉（約６０Ｈｚ）、及び、心臓（約１～２Ｈｚ）又は別の内臓によって生じた内部音を除去した。これによって、診断プラットフォームは、目的でない別の内臓によって生じた音をフィルタリングするのに十分なカットオフ周波数を備えたハイパスフィルタを適用し得る。このフィルタリングされた音声データを、短時間フーリエ変換（ＳＴＦＴ）を使用して処理した。この例では、ＳＴＦＴは、ウィンドウサイズ２５６のハミングウィンドウと、オーバーラップ率０．２５とを有していた。これによって、約１５秒の信号を、９３８×１２９サイズの対応するスペクトログラムへと変換することができた。目的となる内部音のスペクトル情報を活用するために、診断プラットフォームは、（ｉ）スペクトログラム、（ｉｉ）メル周波数ケプストラム係数（ＭＦＣＣ）、及び、（ｉｉｉ）エネルギー合計を抽出した。この例では、スペクトログラムは、１２９ビンの対数振幅スペクトログラムであった。ＭＦＣＣについては、診断プラットフォームは、２０の静的係数、２０のデルタ係数及び２０の加速係数を抽出した。これを行うために、診断プラットフォームは、０～４，０００Ｈｚの周波数範囲内において、４０のＭｅｌバンドを使用した。デルタ係数及び加速係数の計算に使用される幅は、９フレームであった。これにより、フレームあたり６０ビンのベクトルが生成される。一方で、診断プラットフォームは、０～２５０Ｈｚ、２５１～５００Ｈｚ及び５０１～１，０００Ｈｚの３つの異なる周波数帯域のエネルギー合計を計算し、それによってフレーム毎に３つの値を得た。
【0081】
これらの特徴を抽出した後、診断プラットフォームは、これらの特徴を連結して９３８×１９３の特徴マトリクスを形成した。次に、診断プラットフォームは、各特徴に対してｍｉｎ－ｍａｘ正規化を適用し、正規化された特徴の値が０～１の間の範囲に及ぶようにした。
【0082】
ＩＩ．分析
上述のように、前処理中に抽出された特徴を、入力として、呼吸イベントを識別するように訓練されたいくつかのモデルに提供した。最適なモデルを確立するために、抽出された同じ特徴を使用して６つのモデルをテストした。これらのモデルは、単方向回帰型ニューラルネットワーク（Ｕｎｉ－ＲＮＮ）、単方向長短期記憶ニューラルネットワーク（ｕｎｉ－ＬＳＴＭ）、単方向ゲート付き回帰型ユニットニューラルネットワーク（Ｕｎｉ－ＧＲＵ）、双方向回帰型ニューラルネットワーク（Ｂｉ－ＲＮＮ）、双方向長短期記憶ニューラルネットワーク（Ｂｉ－ＬＳＴＭ）、及び双方向ゲート付き回帰型ユニットニューラルネットワーク（Ｂｉ－ＧＲＵ）を含んでいた。総じて、これらのモデルは「ベースラインモデル」と称される。
上述のように、前処理中に抽出された特徴を、入力として、呼吸イベントを識別するように訓練されたいくつかのモデルに提供した。最適なモデルを確立するために、抽出された同じ特徴を使用して６つのモデルをテストした。これらのモデルは、単方向回帰型ニューラルネットワーク（Ｕｎｉ－ＲＮＮ）、単方向長短期記憶ニューラルネットワーク（ｕｎｉ－ＬＳＴＭ）、単方向ゲート付き回帰型ユニットニューラルネットワーク（Ｕｎｉ－ＧＲＵ）、双方向回帰型ニューラルネットワーク（Ｂｉ－ＲＮＮ）、双方向長短期記憶ニューラルネットワーク（Ｂｉ－ＬＳＴＭ）、及び双方向ゲート付き回帰型ユニットニューラルネットワーク（Ｂｉ－ＧＲＵ）を含んでいた。総じて、これらのモデルは「ベースラインモデル」と称される。
【0083】
これらのベースラインモデルのアーキテクチャを図９に示す。ベースラインモデルは、音声データの分析に基づいて呼吸イベントを検出できるように設計した。第１及び第２の層は回帰層であって、ＲＮＮ、ＬＳＴＭ又はＧＲＵであり得る。これらの回帰層は、特徴の時間情報を取り扱う。呼吸は通常周期的であるため、これらの回帰層は、ラベル付けされた例（「訓練データ」とも称される）から呼吸サイクルの性質を学習することができる。音声データ内における呼吸イベントの開始時間及び終了時間を検出するために、診断プラットフォームは、時間分散型全結合層を出力層として使用した。このアプローチによって、単一の検出ではなく、一連の検出（例えば、吸息又はアクションなし）を出力可能なモデルが得られた。シグモイド関数は、時間分散型全結合層の活性化関数として使用した。
【0084】
各ベースラインモデルによって生成された各出力は、サイズ９３８ｘ１の検出ベクトルであった。このベクトルの各要素は、その値が閾値を超えた場合、対応する時間セグメントに吸息又は呼息が存在したことを示す１に設定され、それ以外の場合、その値は０に設定された。この例では、単一タスクの学習アプローチをベースラインモデルに使用したが、マルチタスクの学習アプローチもまた使用可能であった。
【0085】
ベンチマークモデルでは、適応モーメント推定（ＡＤＡＭ）をオプティマイザとして使用した。ＡＤＡＭは、深層学習及び機械学習において重要なプロセスである確率的最適化を使用して、パラメータの適応学習率を計算する方法である。検証損失が１０エポックの間に減少しなかった際、開始学習率をステップ減衰（０．２ｘ）で０．０００１に設定した。この学習プロセスは、５０回連続して改善が見られなかった際に停止した。
【0086】
ＩＩＩ．後処理
ベースラインモデルによって生成された検出ベクトルは、別の目的のためにさらに処理することができる。例えば、診断プラットフォームは、医療専門家によるリアルタイムモニタリングにて使用するために、各予測ベクトルをフレームから時間へと変換し得る。さらに、図９に示すように、ドメイン知識が適用され得る。呼吸は生体によって行われることが知られているため、呼吸イベントの持続時間は、通常は一定範囲内にある。検出ベクトルが、短い間隔で連続する呼吸イベント（例えば、吸息）があることを示す際に、診断プラットフォームは、これらの呼吸イベントの連続性を検査した後に、それらの呼吸イベントをマージするかどうかを決定することができる。より具体的には、診断プラットフォームは、呼吸イベント間の間隔がＴ秒より小さい際に、ｊ番目とｉ番目の呼吸イベントの間のエネルギーピークの周波数差（｜ｐ＿ｊ－ｐ＿ｉ｜）を計算することができる。この差が所定の閾値Ｐより小さい場合に、これらの呼吸イベントを単一の呼吸イベントとしてマージする。この例では、Ｔを０．５秒に設定し、Ｐを２５Ｈｚに設定した。呼吸イベントが０．０５秒より短い場合には、診断プラットフォームはその後、単に呼吸イベントを完全に削除することができる。例えば、診断プラットフォームは、呼吸イベントが発生しなかったことを示すために、対応する（１つ以上の）セグメントに適用される（１つ以上の）ラベルを調整し得る。
ベースラインモデルによって生成された検出ベクトルは、別の目的のためにさらに処理することができる。例えば、診断プラットフォームは、医療専門家によるリアルタイムモニタリングにて使用するために、各予測ベクトルをフレームから時間へと変換し得る。さらに、図９に示すように、ドメイン知識が適用され得る。呼吸は生体によって行われることが知られているため、呼吸イベントの持続時間は、通常は一定範囲内にある。検出ベクトルが、短い間隔で連続する呼吸イベント（例えば、吸息）があることを示す際に、診断プラットフォームは、これらの呼吸イベントの連続性を検査した後に、それらの呼吸イベントをマージするかどうかを決定することができる。より具体的には、診断プラットフォームは、呼吸イベント間の間隔がＴ秒より小さい際に、ｊ番目とｉ番目の呼吸イベントの間のエネルギーピークの周波数差（｜ｐ＿ｊ－ｐ＿ｉ｜）を計算することができる。この差が所定の閾値Ｐより小さい場合に、これらの呼吸イベントを単一の呼吸イベントとしてマージする。この例では、Ｔを０．５秒に設定し、Ｐを２５Ｈｚに設定した。呼吸イベントが０．０５秒より短い場合には、診断プラットフォームはその後、単に呼吸イベントを完全に削除することができる。例えば、診断プラットフォームは、呼吸イベントが発生しなかったことを示すために、対応する（１つ以上の）セグメントに適用される（１つ以上の）ラベルを調整し得る。
【0087】
ＩＶ．タスクの定義及び評価
この例では、２つの異なるタスクが診断プラットフォームによって実行された。
この例では、２つの異なるタスクが診断プラットフォームによって実行された。
【0088】
第１のタスクは、音声データのセグメントの分類であった。これを達成するため、各呼吸イベントの記録を、まずはスペクトログラムへと変換した。スペクトログラムの時間分解能は、上述のように、ウィンドウサイズとＳＴＦＴのオーバーラップ率とに依存する。便宜上、これらのパラメータを、各スペクトログラムが９３８ｘ１２８のサイズのマトリクスになるように固定した。したがって、各記録を９３８セグメントに分割して、図１０に示すように、各セグメントを正解ラベル（ground truth label）に基づいて自動的にラベル付けした。
【0089】
記録の前処理及び分析が行われた後、診断プラットフォームは、９３８ｘ１のサイズのシーケンシャル検出により対応する出力にアクセスできるようになる。この出力は、「推論結果」と称されることがある。シーケンシャル検出を正解セグメント（ground truth segment）と比較することにより、診断プラットフォームは、真陽性（ＴＰ）、真陰性（ＴＮ）、偽陽性（ＦＰ）及び偽陰性（ＦＮ）を定義することができる。続いて、これらのセグメントを分類するために使用されるモデルの感度及び特異性を計算することができる。
【0090】
第２のタスクは、音声データ内の呼吸イベントの検出であった。モデルによって行われたシーケンシャル検出を取得した後、診断プラットフォームは、同じラベルを持つ接続されたセグメントを、対応する呼吸イベントとなるように組み立てることができる。例えば、診断プラットフォームは、接続されたセグメントが、吸息、呼息又はアクションなしに対応することを特定し得る。さらに、診断プラットフォームは、組み立てられた各呼吸イベントの開始時間及び終了時間を導出し得る。この例では、モデルによって予測された１つの呼吸イベントが正解イベントと正しくマッチするかどうかを決定するために、ジャカードインデックス（ＪＩ）を使用した。ＪＩの値が０．５を超えた場合、診断プラットフォームは、組み立てられた呼吸イベントをＴＰイベントとして指定した。ＪＩの値が０を超えたが０．５を下回った場合、診断プラットフォームは、組み立てられた呼吸イベントをＦＮイベントとして指定した。ＪＩの値が０の場合、診断プラットフォームは、組み立てられた呼吸イベントをＦＰイベントとして指定した。
【0091】
パフォーマンスを評価するために、診断プラットフォームは、各ベースラインモデルの精度、感度、陽性の予測値及びＦ１スコアを検査した。全ての双方向モデルが、単方向モデルよりも優れていた。この結果は、主として双方向モデルの複雑さ（及び、訓練可能なパラメータの数）の増加に起因している。全体として、Ｂｉ－ＧＲＵがこれらのベースラインモデルの中で最も有望であったが、他のベースラインモデルがＢｉ－ＧＲＵよりも適している事態もあり得る。
【0092】
Ｂ．呼吸数の計算
呼吸数の信頼できる推定は、様々な病気の早期発見に重要な役割を果たす。異常な呼吸数は、種々異なる病気や、他の病理学的又は心因性の原因を示唆している可能性がある。呼吸数を継続的に確立するための臨床的に許容可能な正確な技術を探索することは、とらえどころのないものであることが判明している。上記のように、この臨床的ギャップを埋めるためにいくつかのアプローチが開発されてきたが、医療専門家から標準治療になるほどの十分な信用を得られたものはない.
呼吸数の信頼できる推定は、様々な病気の早期発見に重要な役割を果たす。異常な呼吸数は、種々異なる病気や、他の病理学的又は心因性の原因を示唆している可能性がある。呼吸数を継続的に確立するための臨床的に許容可能な正確な技術を探索することは、とらえどころのないものであることが判明している。上記のように、この臨床的ギャップを埋めるためにいくつかのアプローチが開発されてきたが、医療専門家から標準治療になるほどの十分な信用を得られたものはない.
【0093】
図１１Ａは、呼吸数を推定するためのアルゴリズムアプローチの大まかな図を含む。図１１Ａに示すように、このアルゴリズムのアプローチは、診断プラットフォームに採用されているモデルによって予測される呼吸イベントに依存している。呼吸イベントを適切に識別することは、呼吸数を推定するための鍵となるため、検出段階及び計算段階は、一貫して高い精度で完了する必要がある。さらに、検出段階及び計算段階は、呼吸数がほぼリアルタイムで（例えば、３０～６０秒毎ではなく、数秒毎に）推定されるように、継続的に実行し得る。
【0094】
大まかに言えば、このアルゴリズムアプローチは、呼吸イベントの発生を追跡し、続いてスライディングウィンドウを使用して呼吸数を継続的に計算することに依存している。まず、診断プラットフォームによって実行されるアルゴリズムは、分析のために取得された音声データの一部を含むウィンドウの開始点を定義する。次に、診断プラットフォームは、ウィンドウの終了点を定義するために、上述したようなモデルによって推測された呼吸イベントをモニタリングすることができる。ウィンドウの開始点及び終了点は、所定数の呼吸イベントがその境界内に含まれるように定義され得る。ここでは、例えばウィンドウは３つの呼吸イベントを含むが、他の実施形態では、３つより多くの又は少ない呼吸イベントがウィンドウ内に含まれ得る。ウィンドウが３つの呼吸イベントを含むようにプログラムされた実施形態では、ウィンドウの開始点は、ウィンドウに含まれる第１の呼吸イベント１１０２の開始に対応し、ウィンドウの終了点は、第４の呼吸イベント１１０８の開始に対応する。第４の呼吸イベント１１０８がウィンドウの終了点を定義する一方で、第４の呼吸イベント１１０８は、最初はウィンドウ内に含まれない。
【0095】
図１１Ａに示すように、診断プラットフォームは、ウィンドウに含まれる吸息間の間隔に基づいて呼吸数を計算することができる。ここで、ウィンドウは、第１の呼吸イベント１１０２と、第２の呼吸イベント１１０４と、第３の呼吸イベント１１０６とを含む。上述のように、第４の呼吸イベント１１０８は、ウィンドウの終了点を定義するために使用され得る。「Ｉ」によって表される第１の期間は、第１の呼吸イベント１１０２の開始と第２の呼吸イベント１１０４の開始との間の時間間隔によって定義される。「ＩＩ」によって表される第２の期間は、第２の呼吸イベント１１０４の開始と第３の呼吸イベント１１０６の開始との間の時間間隔によって定義される。「ＩＩＩ」によって表される第３の期間は、第３の呼吸イベント１１０６の開始と第４の呼吸イベント１１０８の開始との間の時間間隔によって定義される。
【0096】
各期間は、フレームの数（すなわち、時間間隔）に対応する。例えば、診断プラットフォームによって取得された音声データが合計１５秒の記録であり、処理中に記録が９３８セグメントに分割され、それぞれのセグメントの持続時間が約０．０１６秒であると仮定する。用語「セグメント」は、用語「フレーム」用語と交換可能に使用されることがある。ここで、第１、第２及び第３の期間の長さは約５秒であるが、第１、第２及び第３の呼吸イベント１１０２，１１０４，１１０６は、セグメント及び秒に関してそれぞれ異なる長さである。しかしながら、当業者は、呼吸イベント間の期間が互いに同一である必要がないことを認識するであろう。
【0097】
図１１Ａに示すように、呼吸数は、これらの期間に基づいてフレーム毎に計算することができる。一例として、「Ａ」で表される１５秒を考慮する。この時点では、第３の呼吸イベント１１０６がまだ開始していないため、第３の期間はまだ定義されていない。呼吸数は、１２０を秒単位における第１の期間及び第２の期間の合計で除算することによって計算され得る。「Ｂ」で表される１６秒目から開始して、診断プラットフォームは、第３の呼吸イベント１１０６を認識する。したがって、１６秒目から開始して、呼吸数は、１２０を秒単位における第２の期間及び第３の期間の合計で除算することによって計算され得る。
【0098】
通常、診断プラットフォームは、追加の呼吸イベントが識別されると、呼吸数を継続的な方式で計算する。換言すれば、呼吸数は、新しい期間が識別された際に「ローリング」方式で計算することができる。呼吸イベントが識別される（したがって、新しい期間が定義される）たびに、診断プラットフォームは、直近の期間を使用して呼吸数を計算する。一例として、第１及び第２の期間が、それぞれ５秒及び７秒に対応すると仮定する。この状況では、呼吸数は、１分あたり１０回の呼吸（すなわち、１２０／（Ｉ＋ＩＩ）＝１２０／（５＋７））となる。別の一例として、第１及び第２の期間が、それぞれ４秒及び４秒に対応する仮定する。この状況では、呼吸数は１分あたり１５回の呼吸（すなわち、１２０／（Ｉ＋ＩＩ）＝１２０／（４＋４））となる。別の期間（すなわち、第３の期間）が識別された後は、呼吸数は、第１及び第２の期間ではなく、第２及び第３の期間を使用して計算され得る。
【0099】
上述のように、呼吸は生体が行うことが知られているため、呼吸イベントの持続時間は、通常は一定範囲内にある。したがって、呼吸数を計算するために診断プラットフォームによって使用されるアルゴリズムは、特定のフレーム数又は秒数内に新たな呼吸イベントが推測されない場合、分母を増加させるようにプログラムされ得る。図１１Ａでは、アルゴリズムは、新たな呼吸イベントが６秒以内に発見されなかったという決定に応答して、分母を増加させるようにプログラムされている。したがって、「Ｃ」で表される２２秒では、診断プラットフォームは、１２０を第２の期間＋６の合計で除算することによって、呼吸数を計算し得る。一方、「Ｄ」で表される２３秒では、診断プラットフォームは、１２０を第２の期間＋７の合計で除算することによって、呼吸数を計算し得る。図１１Ａに示すように、診断プラットフォームは、新たな呼吸イベントが発見されるまで、１秒ごとに分母を増加させ続けることができる。
【0100】
このようなアプローチによって、呼吸数をほぼリアルタイムで更新し、それによって患者の健康状態の変化を反映することが確実になる。患者が完全に呼吸を停止した場合、診断プラットフォームによって計算された呼吸数は即座に０にはならないことがあるが、呼吸数はほぼ瞬時に減少傾向を示すことになり、このことが医療専門家への警告として役立つ。
【0101】
診断プラットフォームによって計算された呼吸数が異常に低い又は高い状況に対処するために、アルゴリズムは、第１の閾値（「下限閾値」とも称される）と第２の閾値（「上限閾値」とも称される）を用いてプログラムされ得る。呼吸数が下限閾値を下回った場合、アルゴリズムは、診断プラットフォームによって警告が提示されるべきであることを示し得る。さらに、診断プラットフォームが、呼吸数が下限閾値を下回っていることを決定した場合、診断プラットフォームは、あたかも呼吸数が実際に０であるかのように機能し得る。このようなアプローチによって、診断プラットフォームが、呼吸数が実際に０に達することを必要とすることなく、長期間にわたって呼吸イベントが発見されなかった状況に容易に対応可能になることが確実になる。同様に、呼吸数が上限閾値を超えている場合、アルゴリズムは、診断プラットフォームによって警告が提示されるべきであることを示し得る。下限閾値及び上限閾値は、患者や、患者に提供されるサービス等に基づいて、手動又は自動で調整され得る。例えば、小児患者の場合、下限閾値及び上限閾値はそれぞれ４及び６０であり得、成人患者の場合、下限閾値及び上限閾値はそれぞれ４及び３５であり得る。
【0102】
単純化のために、レビューのために（例えば、図１３Ａ～Ｂに示すインタフェースに）掲示される呼吸数は整数値であり得るが、呼吸数は、小数点第１位又は第２位まで（つまり、１０分の１又は１００分の１まで）計算されてもよい。このことは、特に緊急事態において、医療専門家及び患者の混乱を避けるのに役立ち得る。上述のように、レビューのために掲示される呼吸数は、下限閾値を下回った又は上限閾値を超えた場合には、視覚的に改変され得る。例えば、呼吸数が下限閾値を下回った場合、診断プラットフォームは、呼吸数が検出不可能であることを示す代替要素（例えば、「－」又は「－－」）を掲示してもよい。呼吸数が上限閾値を超えた場合、診断プラットフォームは、呼吸数が異常に高いことを示す別の代替要素（例えば、「３５＋」又は「４５＋」）を掲示してもよい。多くの事態において、医療専門家は、呼吸数が正確であることよりも、呼吸数が異常に高い時を知ることに関心がある。
【0103】
概して、診断プラットフォームは、記録時にほぼリアルタイムで取得される音声データのストリームを処理する。換言すれば、診断プラットフォームは、上述のように新しい呼吸イベントが発見される際に、呼吸数を継続的に計算し得る。しかしながら、いくつかの実施形態では、診断プラットフォームは、処理リソースを節約しようとするために、単一のフレーム毎には呼吸数を計算しない。代わりに、診断プラットフォームは呼吸数を定期的に計算し得るが、その場合であっても、呼吸数は通常、医療専門家が患者の健康状態の変化を確実に認識できるように、頻繁に（例えば、数秒毎に）計算されることになる。
【0104】
図１１Ｂは、診断プラットフォームが、所定の頻度（例えば、２、３又は５秒毎）で更新される所定の長さ（例えば、１２、１５又は２０秒）の記録にわたってスライディングウィンドウを使用して、どのようにして呼吸数を計算し得るか示す。図１１Ｂでは、境界ボックスは、音声データが処理されるスライディングウィンドウの境界を表す。所定の時間が経過した後、スライディングウィンドウの境界がシフトする。ここで、例えば、スライディングウィンドウは１５秒をカバーしており、３秒シフトされるため、以前のスライディングウィンドウに含まれていた音声データの１２秒が保持される。このようなアプローチにより、使用可能な処理リソースを過度に消費することなく、呼吸数を頻繁に（例えば、スライディングウィンドウの境界がシフトされるたびに）計算することが可能になる。
【0105】
呼吸数を計算する別のアプローチは、聴診を実行するために、ＭＬやＡＩではなく自己相関に依存する。大まかに言えば、用語「自己相関」は、信号が、遅延の関数としての信号の遅延したコピーと相関するプロセスを示す。自己相関の分析は、繰り返しパターンを識別するための一般的な数学的ツールであるため、繰り返しイベントに関する情報を導出又は推測するためにデジタル信号処理においてよく使用される。
【0106】
診断プラットフォームが検出のために自己相関を使用する実施形態では、診断プラットフォームは、上述のように音声データの記録をスペクトログラムに変換するためにＳＴＦＴを使用する。次に、図１２に示すように、吸息と呼息との間の間隔を決定するために、自己相関係数が計算されて、記録のためにプロットされる。まず、診断プラットフォームは、ノイズを低減するために自己相関係数を正規化し得る。次に、閾値（例えば、１５Ｈｚ）を下回るものを排除するために、自己相関係数にハイパスフィルタが適用され得る。さらに、診断プラットフォームは、自己相関係数をさらに改良するため、トレンド除去修正を実行し得る。
【0107】
自己相関係数を処理した後、診断プラットフォームは、６０を１次ピークと２次ピークの間の呼吸間隔（ＲＩ）で除算することによって呼吸数を計算することができる。呼吸数指数によって、どのピークが選択されるかが決定され得る。例えば、呼吸数指数が高いことが好ましい。概して、約０．６未満の呼吸数指数は、不安定な呼吸数を示すものであるため、診断プラットフォームによって破棄されることがある。
【0108】
図１３Ａ～Ｂは、診断プラットフォームによって生成され得るインタフェースの例を含む。図１３Ａは、医療専門家による診断決定を容易にするために、診断プラットフォームによって生成されたスペクトログラムがどのようにしてほぼリアルタイムで提示されるかを示す。一方、図１３Ｂは、患者の健康に関する追加の洞察を提供するために、デジタル要素（「グラフィック要素」とも称される）がどのようにスペクトログラムを重ね合わせるかを示す。ここでは、例えば、診断プラットフォームが呼吸イベントに対応すると決定したスペクトログラムの部分に、垂直バンドが重なっている。いくつかの実施形態では、これらの垂直バンドは呼吸サイクル全体（すなわち、吸息及び呼息）をカバーするが、他の実施形態では、これらの垂直バンドは呼吸サイクルの一部のみ（例えば、吸息のみ）をカバーすることに留意されたい。
【0109】
呼吸数は、医療専門家によるレビューのために（例えば、右上隅に）掲示され得る。診断プラットフォームが、呼吸数が異常であると決定した場合、掲示される値は、何らかの方法で視覚的に改変され得る。例えば、掲示される値は、医療専門家の注意を引くために、別の色で描画されたり、別の（例えば、より大きいサイズ）で描画されたり、「点滅」するように定期的に削除された後に再掲示されたりし得る。診断プラットフォームは、値が下限閾値（例えば、４、５又は８）を下回ったか上限閾値（例えば、３５、４５又は６０）を超えた場合に、呼吸数が異常であると決定し得る。あるいは、診断プラットフォームは、所定の時間（例えば、１０、１５又は２０秒）内に呼吸イベントが検出されていない場合に、呼吸数が異常であると決定し得る。
【0110】
図１３Ｂに示すように、インタフェースは、診断プラットフォームによってサポートされる種々異なる機能に関連付けられた様々なアイコンを含み得る。記録アイコン１３０２は、選択された際に、インタフェース上に示されるコンテンツの記録を開始し得る。例えば、記録は、任意のデジタル要素と共にスペクトログラムを含んでいてもよく、また対応する音声データを含んでいてもよい。フリーズアイコン１３０４は、選択された際に、インタフェースを現在の表示のままフリーズさせ得る。したがって、フリーズアイコン１３０４が選択された際は、追加のコンテンツがインタフェースに掲示されないことがある。コンテンツは、フリーズアイコン１３０４がもう一度選択された後に、インタフェース上に再び表示され得る。制御アイコン１３０６は、選択された際に、インタフェースの様々な態様を制御し得る。例えば、制御アイコン１３０６は、（例えば、半永久的又は一時的にさらなる変更を防止するために）インタフェースをロックすること、インタフェースのレイアウトを変更すること、インタフェースの配色を変更すること、インタフェースについての入力機構（例えば、タッチか音声か）を変更する等を医療専門家に許可し得る。補足情報もまた、インタフェース上に表示されてもよい。例えば、図１３Ｂでは、インタフェースは、アクティブノイズキャンセル（ＡＮＣ）、再生、及び、接続された電子聴診器システムの状態に関する情報を含む。したがって、医療専門家は、診断プラットフォームが存在する（及び、インタフェースが示されている）コンピューティングデバイスが、音声データの生成を担う電子聴診器システムに通信可能に接続されているかどうかを容易に観測可能であり得る。
【0111】
呼吸数の計算方法
図１４は、音声データの分析を通じて呼吸イベントを検出し、続いてそれらの呼吸イベントに基づいて呼吸数を計算するプロセス１４００のフロー図を示す。まず、診断プラットフォームは、患者の肺によって生成された音の記録を表す音声データを取得することができる（ステップ１４０１）。いくつかの実施形態では、診断プラットフォームは、電子聴診器システムから音声データを直接受信する。他の実施形態では、診断プラットフォームは、記憶媒体から音声データを獲得する。例えば、患者は、自分で録音した音声データを記憶媒体にアップロードすることが許可されていてもよい。別の例として、医療専門家は、自分で録音した音声データを記憶媒体にアップロードすることが許可されていてもよい。
図１４は、音声データの分析を通じて呼吸イベントを検出し、続いてそれらの呼吸イベントに基づいて呼吸数を計算するプロセス１４００のフロー図を示す。まず、診断プラットフォームは、患者の肺によって生成された音の記録を表す音声データを取得することができる（ステップ１４０１）。いくつかの実施形態では、診断プラットフォームは、電子聴診器システムから音声データを直接受信する。他の実施形態では、診断プラットフォームは、記憶媒体から音声データを獲得する。例えば、患者は、自分で録音した音声データを記憶媒体にアップロードすることが許可されていてもよい。別の例として、医療専門家は、自分で録音した音声データを記憶媒体にアップロードすることが許可されていてもよい。
【0112】
次に、診断プラットフォームは、訓練されたモデルによる分析に備えて、音声データを処理することができる（ステップ１４０２）。例えば、診断プラットフォームは、音声データにハイパスフィルタを適用することによって、フィルタリングされた音声データに基づいて、（ｉ）スペクトログラム、（ｉｉ）一連のＭＦＣＣ、及び、（ｉｉｉ）スペクトログラムの種々異なる周波数帯域にわたって合計されたエネルギーを表す一連の値を生成し得る。診断プラットフォームは、これらの特徴を連結して、特徴マトリクスとしてもよい。より具体的には、診断プラットフォームは、これらのスペクトログラム、一連のＭＦＣＣ及び一連の値を連結して、訓練されたモデルに入力として提供され得る特徴マトリクスとしてもよい。いくつかの実施形態では、特徴マトリクスに対してｍｉｎ－ｍａｘ正規化を実行し、各エントリが０～１の間の値を有するようにする。
【0113】
続いて、診断プラットフォームは、時間順に並べられたエントリを含むベクトルを生成するために、訓練されたモデルを音声データ（又は、音声データの分析）に適用することができる（ステップ１４０３）。より具体的には、診断プラットフォームは、上述のように、訓練されたモデルを特徴マトリクスに適用し得る。該ベクトル内の各エントリは、訓練済みモデルによって生成された、音声データの対応するセグメントが呼吸イベントを表すかどうかを示す検出を表し得る。該ベクトル内の各エントリは、音声データの異なるセグメントに対応し得るが、該ベクトル内の全てのエントリは、同じ持続時間の音声データのセグメントに対応し得る。例えば、診断プラットフォームによって取得された音声データが、持続時間の合計が１５秒の記録を表していると仮定する。前処理の一部として、この記録は、同じ持続時間の９３８セグメントに分割され得る。これらのセグメントのそれぞれについて、訓練されたモデルは、音声データの対応する部分が呼吸イベントを表しているかどうかについての検出を表す出力を生成し得る。
【0114】
その後、診断プラットフォームは、上述のように該ベクトル内のエントリの後処理を実行し得る（ステップ１４０４）。例えば、診断プラットフォームは、該ベクトルを調査し、それによってエントリの所定の数よりも少ない数で区切られた同じタイプの呼吸イベントに対応する一対のエントリを識別した後、該一対のエントリが単一の呼吸イベントを表すことを示すように該一対のエントリをマージする。このことは、モデルが呼吸イベントを示さなかったセグメントが存在することが原因で呼吸イベントを見逃さないようにするために行われ得る。加えて又はこれに代えて、診断プラットフォームは、該ベクトルを調査し、それによって所定の長さよりも短い同じタイプの呼吸イベントに対応する一連の連続エントリを識別した後、該一連の連続するエントリによって表される呼吸イベントを削除するように該一連の連続エントリの各エントリに関連付けられたラベルを調整する。このことは、所定の長さ（例えば、０．２５、０．５０又は１．００秒）未満の呼吸イベントが認識されないようにすることを確実にするために行われ得る。
【0115】
次に、診断プラットフォームは、該ベクトルを調査することによって、（ｉ）第１の呼吸イベントと、（ｉｉ）第２の呼吸イベントと、（ｉｉｉ）第３の呼吸イベントとを識別することができる（ステップ１４０５）。第２の呼吸イベントは、第１の呼吸イベントに続き得ると共に、第３の呼吸イベントは、第２の呼吸イベントに続き得る。各呼吸イベントは、音声データの対応するセグメントが呼吸イベントを表していることを示す、該ベクトル内の少なくとも２つの連続するエントリに対応し得る。連続するエントリの数は、診断プラットフォームによって課される呼吸イベントの最小の長さに対応し得る。
【0116】
続いて、診断プラットフォームは、（ａ）第１の呼吸イベントと第２の呼吸イベントとの間の第１の期間、及び、（ｂ）第２の呼吸イベントと第３の呼吸イベントとの間の第２の期間を決定することができる（ステップ１４０６）。上述のように、第１の期間は、第１の呼吸イベントの開始から第２の呼吸イベントの開始まで及び得ると共に、第２の期間は、第２の呼吸イベントの開始から第３の呼吸イベントの開始まで及び得る。その後、診断プラットフォームは、第１及び第２の期間に基づいて呼吸数を計算することができる（ステップ１４０７）。例えば、診断プラットフォームは、呼吸数を確立するために、１２０を第１及び第２の期間の合計で除算し得る。
【0117】
図１５は、患者の肺によって生じる音を含む音声データの分析に基づいて呼吸数を計算するためのプロセス１５００のフロー図を表す。まず、診断プラットフォームは、時間順に並べられたエントリを含むベクトルを取得することができる（ステップ１５０１）。大まかに言えば、該ベクトルの各エントリは、音声データの対応するセグメントが呼吸イベントを表しているかどうかに関する検出を示し得る。上述のように、該ベクトルは、音声データに適用されるモデル、又は、診断プラットフォームによる音声データの分析によって、出力として生成され得る。
【0118】
次に、診断プラットフォームは、該ベクトルのエントリを調査することによって、（ｉ）第１の呼吸イベントと、（ｉｉ）第２の呼吸イベントと、（ｉｉｉ）第３の呼吸イベントとを識別することができる（ステップ１５０２）。通常、このことは、該ベクトルを調査し、それによって同じタイプの呼吸イベントに関連付けられた連続したエントリを識別することによって達成される。例えば、診断プラットフォームは、該ベクトルを解析し、それによって同じ検出（例えば、図９に示すように「吸息」又は「アクションなし」）を備えた連続したエントリを識別し得る。したがって、各呼吸イベントは、（ｉ）所定の長さを超えており、かつ、（ｉｉ）前記音声データの前記対応するセグメントが、呼吸イベントを表していることを示している一連の連続するエントリに対応し得る。上述のように、診断プラットフォームは、偽陽性及び陰性が呼吸イベントを識別する能力に影響を与えないことを確実にするために、後処理を実行し得る。
【0119】
続いて、診断プラットフォームは、第１の呼吸イベントと第２の呼吸イベントとの間の第１の期間、及び、（ｂ）第２の呼吸イベントと第３の呼吸イベントの間との第２の期間を決定することができる（ステップ１５０３）。図１５のステップ１５０３は、図１４のステップ１４０６と同様であり得る。その後、診断プラットフォームは、第１及び第２の期間に基づいて呼吸数を計算することができる（ステップ１５０４）。例えば、診断プラットフォームは、呼吸数を確立するために、呼吸数を確立するために、１２０を第１及び第２の期間の合計で除算し得る。
【0120】
いくつかの実施形態では、診断プラットフォームは、音声データに対応するスペクトログラムを含むインタフェースを表示させるように構成されている（ステップ１５０５）。そのようなインタフェースの例は、図１３Ａ～Ｂに示されている。そのような実施形態では、診断プラットフォームは、医療専門家による診断決定を容易にするために、呼吸数をインタフェースに掲示し得る（ステップ１５０６）。さらに、診断プラットフォームは、上述のように呼吸数を閾値と比較し得（ステップ１５０７）、その後、比較の結果に基づいて適切なアクションを取り得る（ステップ１５０８）。例えば、診断プラットフォームが、呼吸数が下限閾値を下回っていることを決定した場合、診断プラットフォームは、そのことを示す通知を生成し得る。同様に、診断プラットフォームが、呼吸数が上限閾値を超えていることを決定した場合、診断プラットフォームは、そのことを示す通知を生成し得る。通常、該通知は、呼吸数が掲示されているインタフェース上に表示される。例えば、呼吸数は、下限閾値を下回った又は上限閾値を超えたという決定に応答して、視覚的に改変されてもよい。
【0121】
物理的な可能性に反しない限り、上記のステップは、様々な順序及び組み合わせで実行され得ることが想定される。
【0122】
例えば、プロセス１５００は、追加の呼吸イベントが発見された際に呼吸数が継続的に再計算されるように繰り返し実行されてもよい。しかしながら、上述のように、診断プラットフォームは、呼吸イベントが発見されない場合、分母を増加させる（それにより、呼吸数を減少させる）ようにプログラムされ得る。
【0123】
別の例として、呼吸数は、２つを超える期間を使用して計算されてもよい。概して、単一の期間を使用して呼吸数を計算することは、医療専門家の役に立てるには値が比較的短期間で大きく変化しすぎるため、望ましくない。しかしながら、診断プラットフォームは、３つ以上の期間を使用して呼吸数を計算し得る。例えば、診断プラットフォームが、４つの呼吸イベントによって定義される３つの期間を使用して呼吸数を計算する役割を担うと仮定する。そのような状況では、診断プラットフォームは、図１４～１５を参照して上述したようなステップのほとんどを実行し得る。しかしながら、診断プラットフォームは、１８０を第１、第２及び第３の期間の合計で除算することになる。該プロセスのほとんどが同じままである一方で、呼吸数を計算するために、診断プラットフォームは、「Ｎ」（ここで、「Ｎ」は期間の数である）の６０倍を、それら「Ｎ」個の期間の合計で除算することになる。
【0124】
他のステップもまた、いくつかの実施形態では含まれ得る。例えば、呼吸異常の存在等の診断に関連する洞察が、インタフェース（例えば、図１３Ｂのインタフェース）に掲示され得るか、患者に関連付けられたプロファイルを表すデータ構造内に格納され得る。したがって、診断に関連する洞察が、対応する患者に関連付けられた音声データでエンコードされたデータ構造内に格納されてもよい。
【0125】
電子聴診器システムと診断プラットフォームの使用例
中等度から重度の麻酔の需要は、従来の挿管手術よりも徐々に大きくなっており、麻酔は医療施設における主流の治療法となってきている。しかしながら、呼吸停止や気道閉塞のリスクは、依然として排除することができない。患者の呼吸状態を直接的かつ継続的に監視する方法が不足しており、上述の聴診主導のアプローチは、この問題の解決策となる。
中等度から重度の麻酔の需要は、従来の挿管手術よりも徐々に大きくなっており、麻酔は医療施設における主流の治療法となってきている。しかしながら、呼吸停止や気道閉塞のリスクは、依然として排除することができない。患者の呼吸状態を直接的かつ継続的に監視する方法が不足しており、上述の聴診主導のアプローチは、この問題の解決策となる。
【0126】
世界保健機関（ＷＨＯ）によって発行された手術安全ガイダンスによると、中等度の非挿管麻酔は、担当の医療専門家による一貫した監視が必要とされている。このことは、従来では聴診に基づく換気の確認、呼気終末ＣＯ2のモニタリング、患者との口頭でのコミュニケーションを含む、いくつかの方法によって達成されてきた。しかしながら、これらの従来のアプローチは、不可能ではないにしても、多くの事態では非現実的である。
【0127】
上記の聴診主導のアプローチは、これらの従来のアプローチには適さない事態において採用することができる。例えば、聴診主導のアプローチは、痛みを軽減するために鎮静剤が使用されることが多い形成外科、消化器内視鏡検査及び歯科的処置などの事態において使用され得る。別の例として、聴診主導のアプローチは、病気が伝染するリスクが高い事態（例えば、呼吸器疾患のある患者の治療）において使用され得る。ここで説明するアプローチの最も重要な用途の１つは、気道が閉塞していることを聴診によって迅速に発見できることである。電子聴診器システムと診断プラットフォームとを組み合わせることによって、医療専門家は、患者の呼吸音を人力で評価する必要なく、患者を継続的にモニタリングすることが可能になる。
【0128】
Ａ．形成外科
鼻形成術等の特定の処置では、必要なマスクを患者が着用できなくなるため、呼気終末ＣＯ2を使用して呼吸状態をモニタリングすることが妨げられることになる。周辺機器の酸素濃度計には固有の遅延があり、酸素飽和度があるレベルを下回った際にしか通知を生成できない。
鼻形成術等の特定の処置では、必要なマスクを患者が着用できなくなるため、呼気終末ＣＯ2を使用して呼吸状態をモニタリングすることが妨げられることになる。周辺機器の酸素濃度計には固有の遅延があり、酸素飽和度があるレベルを下回った際にしか通知を生成できない。
【0129】
Ｂ．消化器内視鏡検査
従来では、消化器内視鏡検査中の患者の呼吸状態を監視するために、末梢血酸素濃度計と呼気終末ＣＯ2モニタとが使用されてきた。これら２つのアプローチには固有の遅延があり、酸素飽和度低下量又は呼気終末量が少なくとも一定量変化した際にしか通知を提供できない。
従来では、消化器内視鏡検査中の患者の呼吸状態を監視するために、末梢血酸素濃度計と呼気終末ＣＯ2モニタとが使用されてきた。これら２つのアプローチには固有の遅延があり、酸素飽和度低下量又は呼気終末量が少なくとも一定量変化した際にしか通知を提供できない。
【0130】
Ｃ．歯科的処置
歯科的処置の間は、医療専門家がバイタルサインを継続的にモニタリングすることは困難である。歯科的処置が行われている間は、高い集中力が求められるだけでなく、医療専門家が１人か２人しかいないことも珍しくない。さらに、患者は自分の唾液によって簡単に吐き気を催したり窒息したりする可能性があり、これらの患者が麻酔の影響下にある場合には特にリスクが高い。
歯科的処置の間は、医療専門家がバイタルサインを継続的にモニタリングすることは困難である。歯科的処置が行われている間は、高い集中力が求められるだけでなく、医療専門家が１人か２人しかいないことも珍しくない。さらに、患者は自分の唾液によって簡単に吐き気を催したり窒息したりする可能性があり、これらの患者が麻酔の影響下にある場合には特にリスクが高い。
【0131】
Ｄ．防疫
病気の伝染を防ぐために、患者が隔離されることはよくある。隔離が必要な場合、医療専門家が従来の聴診を行うのは危険な場合がある。さらに、医療専門家は、防護ガウンやマスク等の個人用保護具（ＰＰＥ）を着用している間は、聴診を行うことができないことがある。単純に言えば、隔離とＰＰＥとの組み合わせによって、患者の呼吸状態を適切に評価することが困難になる可能性がある。
病気の伝染を防ぐために、患者が隔離されることはよくある。隔離が必要な場合、医療専門家が従来の聴診を行うのは危険な場合がある。さらに、医療専門家は、防護ガウンやマスク等の個人用保護具（ＰＰＥ）を着用している間は、聴診を行うことができないことがある。単純に言えば、隔離とＰＰＥとの組み合わせによって、患者の呼吸状態を適切に評価することが困難になる可能性がある。
【0132】
電子聴診器システム及び診断プラットフォームは、呼吸イベントを視覚化する手段を提供するだけでなく、聴診音の再生を開始して、瞬時に通知を生成するために使用することができる。医療専門家は、図１６に示すように、聴診音を聞いて呼吸イベントを確認することができ、これを使用して、気道が部分的に閉塞しだした時点、又は、呼吸数が不安定になってきた時点を確立することができる。
【0133】
処理システム
図１７は、本明細書に記載の少なくともいくつかの動作を実施可能な処理システム１７００の例を示すブロック図である。例えば、処理システム１７００のコンポーネントは、診断プラットフォームを実行するコンピューティングデバイス上でホストされ得る。コンピューティングデバイスの例には、電子聴診器システム、携帯電話、タブレットコンピュータ、パーソナルコンピュータ及びコンピュータサーバが含まれる。
図１７は、本明細書に記載の少なくともいくつかの動作を実施可能な処理システム１７００の例を示すブロック図である。例えば、処理システム１７００のコンポーネントは、診断プラットフォームを実行するコンピューティングデバイス上でホストされ得る。コンピューティングデバイスの例には、電子聴診器システム、携帯電話、タブレットコンピュータ、パーソナルコンピュータ及びコンピュータサーバが含まれる。
【0134】
処理システム１７００は、プロセッサ１７０２と、メインメモリ１７０６と、不揮発性メモリ１７１０と、ネットワークアダプタ１７１２（例えば、ネットワークインタフェース）と、ビデオディスプレイ１７１８と、入力／出力デバイス１７２０と、制御デバイス１７２２（例えば、キーボード、ポインティングデバイス又はボタン等の機械的入力）と、記憶媒体１７２６を含むドライブユニット１７２４と、バス１７１６に通信可能に接続された信号生成デバイス１７３０とを含む。バス１７１６は、適切なブリッジ、アダプタ又はコントローラによって接続される１つ以上の物理バス及び／又はポイントツーポイント接続を表す抽象化として示されている。したがって、バス１７１６には、システムバス、周辺機器相互接続（ＰＣＩ）バス、ＰＣＩ－Ｅｘｐｒｅｓｓバス、ＨｙｐｅｒＴｒａｎｓｐｏｒｔバス、業界標準アーキテクチャ（ＩＳＡ）バス、小型コンピュータシステムインタフェース（ＳＣＳＩ）バス、ＵＳＢ、集積回路間（Ｉ２Ｃ）バス、又は、電気電子技術者協会（ＩＥＥＥ）標準１３９４に準拠したバスが含まれ得る。
【0135】
処理システム１７００は、コンピュータサーバ、ルータ、デスクトップコンピュータ、タブレットコンピュータ、携帯電話、ビデオゲームコンソール、ウェアラブル電子デバイス（例えば、時計又はフィットネストラッカー）、ネットワーク接続（「スマート」）デバイス（例えば、テレビ又はホームアシスタントデバイス）、拡張現実又は仮想現実システム（例えば、ヘッドマウントディスプレイ）、又は、処理システム１７００によって行われる（１つ以上の）アクションを指定する一連の命令（シーケンシャル又はその他）を実行可能な別の電子デバイスのアーキテクチャと同様のコンピュータプロセッサアーキテクチャを共有し得る。
【0136】
メインメモリ１７０６、不揮発性メモリ１７１０及び記憶媒体１７２６は、単一の媒体として示されているが、用語「記憶媒体」及び「機械可読媒体」は、１つ以上の命令セット１７２８を格納する単一の媒体又は複数の媒体を含むものと解釈されるべきである。用語「記憶媒体」及び「機械可読媒体」はまた、処理システム１７００による実行のための一連の命令を格納、符号化又は運搬可能な任意の媒体を含むと解釈されるべきである。
【0137】
概して、本開示の実施形態を実施するために実行されるルーチンは、オペレーティングシステム、又は、特定のアプリケーション、コンポーネント、プログラム、オブジェクト、モジュール若しくは一連の命令（まとめて「コンピュータプログラム」と称される）の一部として実装され得る。コンピュータプログラムは、典型的には、様々な時点でコンピューティングデバイス内の様々なメモリ及び記憶デバイス内に設定される１つ以上の命令（例えば、命令１７０４，１７０８，１７２８）を含む。プロセッサ１７０２によって読み取られて実行される際、これらの命令は、本開示の様々な態様を実行するための動作を処理システム１７００に実行させる。
【0138】
実施形態は、完全に機能するコンピューティングデバイスの文脈で説明したが、当業者であれば、様々な実施形態が様々な形態のプログラム製品として配布可能であることを理解するであろう。本開示は、実際に配布を行うために使用される機械又はコンピュータ可読媒体の特定のタイプに関係なく適用される。機械可読媒体及びコンピュータ可読媒体のさらなる例には、揮発性メモリ、不揮発性メモリ１７１０、リムーバブルディスク、ハードディスクドライブ（ＨＤＤ）、光ディスク（例えば、コンパクトディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）及びデジタルバーサタイルディスク（ＤＶＤ））等の記録可能媒体、クラウドベースの記憶媒体、並びに、デジタル及びアナログ通信リンク等の伝送タイプのメディア等が含まれる。
【0139】
ネットワークアダプタ１７１２は、処理システム１７００が、ネットワーク１７１４内のデータを、処理システム１７００及び外部エンティティによってサポートされる任意の通信プロトコルを介して、処理システム１７００の外部にあるエンティティと仲介することを可能にする。ネットワークアダプタ１７１２には、ネットワークアダプタカード、ワイヤレスネットワークインタフェースカード、スイッチ、プロトコルコンバータ、ゲートウェイ、ブリッジ、ハブ、レシーバ、リピータ、又は、（例えば、Ｂｌｕｅｔｏｏｔｈ又はＷｉ－Ｆｉ経由の通信を有効にする）集積回路を含む送受信器が含まれ得る。
【0140】
備考
本技術の様々な実施形態についての前述の説明は、例示及び説明の目的で提供されている。それらの説明は、網羅的であることや、特許請求された主題を開示の厳密な形式に限定することは意図されていない。
本技術の様々な実施形態についての前述の説明は、例示及び説明の目的で提供されている。それらの説明は、網羅的であることや、特許請求された主題を開示の厳密な形式に限定することは意図されていない。
【0141】
数多くの修正及び変形は、当業者にとって明らかであろう。実施形態は、本技術の原理及びその実際の応用を最もよく説明するために選択及び説明されており、それによって、関連技術の当業者が、特許請求された主題、様々な実施形態及び特定の用途に適した様々な修正を理解することを可能にするものである。
【図1A】
【図1B】
【図1C】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11A】
【図11B】
【図12】
【図13A】
【図13B】
【図14】
【図15】
【図16】
【図17】
【国際調査報告】