元の記事の著者について簡単に説明すると、 Adam BosworthはBorlandでキャリアを開始し、 Quattroスプレッドシートシステムに取り組みました。 マイクロソフトに移り、XMLの作成と宣伝に関与するWebDataチームのリーダーを含む、さまざまなリーダーシップの役職を務めました。 さらに、彼はAccessとコードネームTridentの Internet Explorer 4.0エンジンに取り組みました。 マイクロソフトを去った後、Adamは一連の買収の後、Crossgainの共同設立者の1人になり、その主要製品はOracle Workshop for WebLogicに変わりました。 2004年から2007年にかけて、ボスワースはGoogleの製品開発担当副社長を務め、Google Docsに携わり、Google Healthの開発を指揮しました( 2012年1月1日から閉鎖 、かつてハブでそれについて書いた )。 Googleを離れた後、彼はソーシャルネットワークとゲームの要素を使用して健康を改善するKeasスタートアップを設立しました。
今週、標準に関する政府の会議(1)に専門家として参加するように頼まれました。 この時点で私は通常眠りますが、適切な瞬間に、睡眠不足を嫌悪しているにもかかわらず、起きて電話に座っていました。 私がこれをしたのはなぜですか? 彼らは、医療データを実際に透明にする方法について議論しました。 そのようなデータを結合するには、どの標準を使用する必要がありますか?
私自身の驚きとある程度の苦痛に、いくつかの標準の開発に参加することができました。 それらの1つは、データベースとスプレッドシートやAccessなどのユーザーアプリケーションとの間でデータを交換するために使用されました。 それはODBCと呼ばれ、最初はいくつかの困難にもかかわらず、非常によく機能しました。 もう1つは、現在AJAXと呼ばれるものの標準で、Gmailのような複雑でインタラクティブなWebページを作成します。 おそらく最も重要なのはXMLでした。 これらはすべて成功です。 失敗がありました。 ODBCを置換/置換したいOLE DBを特によく覚えています。 成功と失敗の危機にbalancingしているバランスの1つは、 XMLスキーマでした。 これらすべての努力の結果、私はあなたと共有しようとするいくつかの教訓を学びました。 彼らは何ですか?
1.基準を非常にシンプルかつ愚かにします。 失敗の確率は、少なくとも標準の複雑さの2乗です。 成功する標準は、通常、シンプルで、焦点を当て、読みやすいものです。 医学の世界では、これはまず、人口統計学的パラメーター、テスト結果、薬物など、一意にエンコードできるデータに焦点を合わせる必要があることを意味します。 あらゆる分野の医療データをすべて網羅する必要はありません。 さまざまなデータへのパートナーのアクセス権に集中する必要はありません(以下の段落2、3、および4を参照)。
2.交換されるデータは、人間が判読可能で理解できるものでなければなりません。 標準の運命は、それらをコードに変換するエンジニアに依存します。 彼らは、標準を簡単に理解し(上記参照)、テストできる場合にのみこれを行います。 そのため、過去15年にわたって、HTTP、HTML、XMLなどのテキスト標準が勝利を収めています。 開発者は、任意のエディターで受信/送信されたデータを表示し、すべてが正常に機能することを確認できます。 ティムバーンズリーがインターネットの作成にこのアプローチを最初に適用したとき、ほとんどの「真剣な」ネットワークプロフェッショナルは、HTTPでテキストを使用するのはおかしいと考えていました。 しかし、それは非常にうまくいきました。 明らかに、XMLの場合、同様に機能しました。 これから特定の結論を導き出すことができます。 「XML」と言うだけでは十分ではありません。 平均的なエンジニア(標準を実現する)は、この形式を見て理解できるはずです。 コンピューターに優しいXML文法のみを見ると、それらが広く使用されないことがすぐに予測できます。 私の意見では、 RDFなどの抽象知識モデル内にXMLを隠すいわゆるXML文法がいくつかあり、それらは読み/理解がはるかに難しく、広く使用されていません。 私の意見では、 Hl7はこれに苦しんでいます。
3.焦点を合わせた標準が最適です。 近隣地区への旅行用に大型トラックを建設しないでください。 複雑な目標(条項1を参照)および明確性(条項2を参照)をテストするための作業バージョンを作成せずに、さまざまな複雑な目標を持つ委員会が機能するため、標準は失敗することが非常に多い。 Webの天才の一部は、Tim Berners-Leeが、ブラウザが表示するもの(HTML)からプロトコル(HTTP)を正しく分離したことです。 手紙を封筒から分離するようなものです。 これが基本です。 そして必要。 貧弱なエンジニアはすべてを理解する必要があるため、レイヤーまたはレベルが1つの大きなエンティティに絞り込まれる標準は失敗する傾向がありますが、実際には1つのことだけを理解する必要があるため、ボイコットを発表しています。 医療では、これは、データをエンコードし、データにアクセスし、セキュリティを確保するために、1つの標準にルールを含める必要がないことを意味します。 私がエンジニアとして、患者に処方された薬のリストをエンコードし、彼が本当に必要な場所に送るだけでよい場合、他のことを強制することはありません。 結果のXMLは、薬剤リストのように見えるはずです。 何かがうまくいかない場合は、同僚に電話して、5分で正確に何が悪いのかを調べることができます。 ほとんどの場合、電話帳のような仕様を勉強する必要はないので、数日で問題を解決できます。 「抽象データモデル」を理解する必要はありません。 元のXML仕様の大部分はごくわずかでした。 意図的に。 ヘルスケアの情報標準を簡素化する試みについて、それを下げるのではなく「標準のレベルを上げる」べきだとsomeoneするような誰かが言うのを聞いた。 これは、子供が外に出られるように飛ぶ方法を教えるという要件に似ています。 すべての成功した標準の特徴は、究極の複雑さではなく、極端なシンプルさでした。
4.標準には、正確なエンコード規則を含める必要があります。 ODBCはデータ型を正確に定義しました。 テキスト内の文字をエンコードするための正確なルールであるユニコードを除き、XML記述ではすべてが簡潔でした。 エンコードの精度を保証するため、これはおそらく標準の最も重要な部分です。 これは、医療では、規格が薬物、テスト結果、人口統計データ、患者の状態データをエンコードするためのルールを明確に定義し、誰もがロイヤリティを支払うことなくこれらのルールを使用できるようにする必要があることを意味します。 政府は、医師の行動に関するすべてのデータにNPI 、すべての患者状態データにSNOMED CT 、すべての検査データにLOINC 、すべての薬物( NDC 、 rxNorm、またはFDB )の特定のコーディング規則を要求し、これらのルールの使用は常に無料です。
5.実際には、標準を構築するときに実際に考慮される実装が常に存在する必要があります。 何もしなければ、それが機能して工学的に意味があるかどうかを理解することは非常に困難です。 ODBCを作成するとき、私たちの多くはODBCをプロセスに実装しました。 ヘルスケアの世界では、私たちの多くがCCRの作成プロセスでCCRを開発および使用し、何が機能し、何が特に有用でないかをすぐに理解し、医療データを統合するための優れた使いやすい標準にしました。 通常のエンジニアは、数週間で標準の実装を理解できるはずです。
6.予期しない状況の可能性を考慮してください。 ネットワーク標準はこれについて非常に良い仕事をします。 HTTPで受信者が理解できないものがある場合、それは無視されます。 壊れません。 HTMLでブラウザに理解できないものがある場合、それは無視されます。 壊れません。 ポステルの法律を考慮に入れてください。 予期しないものを許可します。 誤った精度は、成功した標準の墓地です。 この点でXMLスキーマは非常に悪く、CCRははるかに優れています。
7.標準自体を無料にし、多くの簡単な例を使用してオンラインで公開します。 エンジニアも人間です。彼らは例から学ぶのが最も簡単であり、標準が上記の原則に従っていれば、例は明確で明白になります。 通常、Webサイトに明確な説明と簡単で理解可能な例がある場合、標準の成功をすぐに予測できます。 HL7の複雑さ、一般化、抽象性は、サイトを訪れた普通の人を完全に驚かせます 。 彼女も私を混乱させます。 間違いなく、エンジニアはごくわずかな時間しかない普通の人々です。 それらのほとんどは学位を持っていません。
正直なところ、ほとんどの標準はまったく互換性があるようには設計されていません。 一部は、既存の地位を保護するか、知的財産から利益を得るように設計されています。 他にも独自に存在し、標準の本体の無限の存在をサポートし、著者が標準の作業の詳細を貧しいエンジニアに説明することで非常に良いお金を稼ぐことを可能にします。 おそらく誰もが、そのような標準は良いとは言えないことに同意するでしょう。 医療データの互換性は非常に重要であるため、私たち全員がこのアプローチの餌食になりません。
注:
1.会議の説明へのリンクが機能しません。 それが公開されたブログももうありません。 リンクの名前から、それはFACAのブログであると見なすことができます(アメリカの詳細を知らない)-1972年の法律に基づいて作成され、政府機関と大統領に公開勧告を行うように設計された特別な審議組織の1つ