Direct Project: クラウド上で医療情報を送信する

Direct Sender を使用して、医療 IT システムの医療記録をセキュアに e-メール送信する

米国連邦政府の医療保険制度改革では、相互運用可能で有意義な EHR (Electronic Health Record: 電子健康記録) システムの使用を促進することを主な目標の 1 つとしています。この改革で最も前途有望なイニシアチブとして挙げられるのが、Direct Project です。機密性の高い患者情報をクラウド上で送信するために設計されたこのピア・ツー・ピア・プロトコルの概要を学び、Java ベースのオープンソース・クライアントである Direct Sender を使用して、医療 IT システムでセキュアな e-メール送信を行う方法を学んでください。

Michael J. Yuan, Chief Scientist, Ringful Health

Photo of Michael YuanYuan 博士は、エンタープライズ・コンピューティングおよび消費者向けモバイル技術の分野で有名な科学技術者であり、消費者主導型医療という新しい分野の先駆者です。ソフトウェア・エンジニアリングに関する著書は 5 冊、同じ分野の開発者向けジャーナルおよび業界ジャーナルでは 40 を超える記事を発表しています。Ringful Health での彼の業績はウォールストリート・ジャーナル、ニューヨーク・タイムス、ロサンゼルス・タイムスなどの国内メディアで広く取り上げられ、認められています。



2012年 12月 06日

クラウド・コンピューティングは、ほぼあらゆる業界でシステムの相互運用性の促進、および IT コストの削減の流れを大きく変えてきていますが、医療 IT 業界においては、クラウド・コンピューティングのパラダイムを導入するのが困難な状態が続いています。現状では、クラウド上で利用される医療 IT は、主に eClinicalWorks や PracticeFusion などの小規模な診療所向けのホスト型 EHR (Electronic Health Record: 電子健康記録) プロバイダーに限られています (「参考文献」を参照)。このようなプロバイダーが重点を置いているのは、データとサービスを (SaaS (Software-as-a-Service) モデルで) ホストすることであり、データの交換には重点が置かれていません。また、大規模な病院システムでは今までのところ、クラウド・コンピューティングが有意義な方法で導入されていません。

医療機関にとって、クラウド・コンピューティングを利用することで実現されるコスト削減は、より効率的でオープンなデータ・インフラストラクチャーに向けた動きを推し進める可能性があります。複数の医療システム全体で医療データをセキュアに共有することができれば、患者にとって、医療への信頼が高まります。そしてソフトウェア開発者にとっての医療 IT は、革新と発見の新たな分野になります。

この記事では、米国連邦政府によって開発され、その導入が推進されている極めて前途有望な機密データ交換プロトコル Direct Project を紹介します。はじめに、医療 IT におけるオープン・データ交換の必要性と、一般に使われているプロトコルに伴う制約事項について概説します。続いて、これまで医療システムがよりオープンなデータ交換プロトコルを導入する障害となっていたセキュリティーとインフラストラクチャーの欠落部を、Direct Project がどのように埋めるのかを説明します。最後に、この Direct プロトコルを実装する Java ベースのオープンソース・クライアントである Direct Sender を使用した単純なプログラミングの例を紹介します。

医療 IT とオープンなデータ交換

病院と医師は、患者データにオンラインでアクセスするのが不得手なことで有名です。2012年の今でさえも、米国の標準的な病院を訪れて自分の医療記録を見せてくれるよう頼むと、病院のスタッフが医療記録を印刷して、コピー料金を請求してきます。医師が患者を別の医療機関に紹介するときには、その機関にファックスを送信するか、電話で連絡を取るのが通常です。このような信頼できないデータ管理は、膨大な無駄が発生することにつながり、さらに悪い場合には医療ミスの原因にもなります。

HIE と Direct Project

医療機関の間でのデータ交換は重要な課題であるため、Direct Project のような特殊な HIE (Health Information Exchange: 医療情報交換) には、政府による助成金が支給されています。「医療情報交換」とは、電子形式による医療関連の情報を電子形式で共有しやすくするインフラストラクチャーとサービスを提供する機構のことです。通常は HIE ごとに、1 つの大都市圏または州の一部を担当します。平均して、1 つの HIE を構築するには 1500 万ドル以上かかり、その運用を維持するには毎年数百万ドルが必要になります。このように医療 IT システムの「閉塞性」のために、莫大な費用がすべての米国民に圧し掛かっています。

医療 IT でのインターネット技術の導入が遅れている理由はさまざまにあります。例えば、導入を促す経済的誘因が立場によってばらばらであること、EHR 市場が極めて細分化されていること、EHR ベンダーがベンダー・ロックインの状況を作り出していること、プライバシーに関する規制があること、データ交換標準が厳格でない上に細分化されていることなどの理由です。このような障害があるために、これまで医療 IT の世界には、クラウド・コンピューティングによる影響がほとんど及んでいません。EHR を実施している医療機関でさえ、データを内部でホストして、できるだけ外部アクセスを制限するのが一般的なプラクティスとなっています。

Direct Project の歴史

米国連邦政府が当初開発したのは、DoD (Department of Defense: 国防総省) と VA (Veterans Affairs: 退役軍人局) 病院を接続し、負傷した軍人が VA 病院全体でより良い治療を受けられるように改善することを目的とした医療情報交換用ネットワークです。このシステムは、NHIN (National Health Information Network: 国家医療情報ネットワーク) と名付けられました。NHIN はその後、ONC (Office of the National Coordinator for Health Information Technology: 国家医療 IT コーディネーター室) に引き継がれ、国全体での医療情報交換用テンプレートの役割を果たすオープソース・プロジェクトとしてリリースされました。このプロジェクトは、ONC によって NwHIN (Nationwide Health Information Network: 全国医療情報ネットワーク) と名付けられ、その後改名されて EHE (eHealth Exchange) となっています。

米国連邦政府の HIE ネットワークのコアは、Java ESB をベースとした CONNECT と呼ばれる SOA (Service-Oriented Architecture: サービス指向アーキテクチャー) システムです (「参考文献」を参照)。このネットワークに属する医療機関は、それぞれのシステムをバスに接続できるようになっています。CONNECT ネットワークは階層という形で編成することができますが、実際には、このシステムは保守するにもスケーリングするにも極めて複雑なものになります。

CONNECT の限界を認識して ONC が次に開発したのは、スケールダウンした Direct と呼ばれる HIE インフラストラクチャーです。CONNECT とは異なり、Direct はピア・ツー・ピアとなるように設計されています。Direct のオープンなピア・ツー・ピア・データ交換モデルは、情報をファックスでやりとりするのに慣れている医療機関にとって馴染みがあることから、より広く採用されることが見込まれます。

e-メールのセキュリティーと医療 IT

医療 IT システムに保管されている患者データには、HIPAA (Health Insurance Portability and Accountability Act: 医療保険の相互運用性と説明責任に関する法律) および HITECH 法 (Health Information Technology for Economic and Clinical Health (HITECH) Act: 経済的および臨床的健全性のための医療情報技術に関する法律) などの厳格なプライバシーおよびセキュリティーに関する規制が適用されます。これらの規制によって、データの保管および送信方法、そしてデータ侵害に対する責任を持つ担当者が定義されています。

インターネットで文書を交換するための手段として最も広く使用されているのは、e-メールです。e-メールは普及しているものの、医療記録や専門医への紹介などといった機密データを送信するには十分なセキュリティーがありません。e-メール・アドレスが偽造されたり、e-メールの内容が受信側の受信箱に到達する前に、インターネット上の複数のサード・パーティーのメール・サーバーを通じて平文で渡されたりする可能性があるためです。このような事実は、HIPAA および HITECH 法のセキュリティー・ルールに反しています。

HIPAA と HITECH 法

HIPAA と HITECH 法の法的文脈や、これらの法律が医療 IT に与える影響について詳しく学ぶには、「クラウドでの患者データのプライバシーとセキュリティー」(Erin Gilmer 著、developerWorks、2012年 10月) を読んでください。

けれども、e-メールの普及は、大きな魅力にもなっています。それを最初に発見したのは、金融業界です。医療 IT が登場するはるか以前に、金融業界では、機密性の高い金融情報をインターネット・バンキングのユーザーと共有するためのセキュアな e-メールがすでに開発されています。IETF RFC 3851 (Secure/Multipurpose Internet Mail Extensions (S/MIME) Message Specification) は、PKI (Public Key Infrastructure: 公開鍵基盤) プロトコルを使用して e-メールの添付ファイルを暗号化する方法を定義している文書です。RFC 3851 で規定しているように、S/MIME 添付ファイルに e-メール・メッセージ全体を含めれば、パブリック・インターネット上に e-メールで機密データを送信することができます。

PKI は広く支持されているインターネット・セキュリティーの標準ですが、以下のように、PKI を利用したセキュアな e-メールを使用するにはいくつかの大きな障害があります。

  1. PKI では、メッセージの送信側と受信側が、確立された権威によって発行されたデジタル証明書を持つことが要件となります。デジタル証明書は、共有メッセージの暗号鍵と復号鍵を提供します。さらに重要なことに、誰もメッセージを偽造できないようにするために、送信側と受信側の身元の確認を行います。けれども、個人の証明書を取得するプロセスは、大抵の場合、時間も費用もかかるプロセスです。
  2. 送信側と受信側がそれぞれのデジタル証明書を受け取った後は、インターネット上でそのデジタル証明書を見つけられるようにする必要があります。送信側と受信側が証明書を交換するまでは、両者の間で e-メールを送信できないためです。この問題は、公にディスカバリー可能な DNS サーバーに e-メール証明書を保管する新しい DNS 標準が作成されたことによって部分的に解決されています。しかし、インターネット上のほとんどの DNS サービスでは、この機能を実装していません。
  3. 送信側と受信側の両方が、S/MIME 暗号化および DNS 証明書のディスカバリーをサポートしている e-メール・クライアントを使用する必要があります。

以上の障害は、コンシューマーにとって、セキュアな e-メール導入の大きな妨げとなってきました。それでも、医療機関と患者との間でセキュアに文書を交換するという特定の状況には、Direct プロトコルが最適です。


医療 IT における状況

医療業界で一般的となっている文書の交換方法の 1 つは、医療機関の間で患者情報を交換するというものです。交換される文書には、専門医への紹介、医療履歴、保険情報、検査結果、投薬リストなどがあります。現在、医療機関はこのような文書をファックスで送信していますが、これらの文書はセキュアな e-メールで送信したほうが理にかなっています。

医療 IT では、医療機関が記録を直接患者に送信するケースも一般的です。このケースについて、Direct Project では金融業界の戦略を参考にしています。具体的には、e-メールを直接患者に送信する代わりに、Direct プロトコルでは、医療機関に医療システムの患者ごとの e-メール・アカウントを作成させ、セキュアな e-メールが到着した時点で通知メールを患者の通常のアカウントに送信させるようにしています。通知メールを受け取った患者には、医療システムの患者ポータルにログインして、Web メールのようなインターフェースで自分宛のセキュアなメッセージをチェックさせます。この場合、セキュアな e-メールは、医療機関の内部 e-メール・システムで送信されることになります。

Direct を使用したセキュアな e-メールの送信

ここまでのセキュアな e-メールと Direct Project の背景についての簡単な説明で、医療 IT システムに Direct プロトコルおよびインフラストラクチャーを実装する利点を理解していただけたようであれば幸いです。ここからは、このセキュアな e-メールを送信するためのインフラストラクチャーをセットアップする方法を説明します。このインフラストチャーをセットアップするには、Direct e-メール・メッセージを受信できる宛先 e-メール・アドレスが必要になります。幸い、あらゆる個人に Direct サポートを提供する Microsoft HealthVault を利用することができます (「参考文献」を参照)。まずは、http://direct.healthvault-stage.com にある Microsoft HealthVault ステージング・サーバーにアカウントを作成してください。アカウントの作成が完了すると、your_id@healthvault-stage.com で Direct 対応のセキュアな e-メール・アドレスを使用できるようになります。そのアドレスに e-メールを送信することで、これから作成するコードをテストすることができます。

Microsoft HealthVault について

Microsoft HealthVault は、PHR (Personal Health Record) システムの 1 つです。この PHR システムでは、患者つまり利用者が自分の医療記録を管理したり、自分の医療記録に入力したりできるようになっています。HealthVault は、複数の大規模な病院システムの医療記録に接続されます。

次に必要なのは、e-メール・メッセージにデジタル署名を付けるために使用する、公開鍵デジタル証明書を作成することです。公開鍵デジタル証明書により、e-メールの受信者に対して、受信したメッセージが本当に送信者本人からのものであることが保証されます。デジタル証明書は、送信者のアドレスごとに必要です。1 つの方法として、Verisign などの認証局から信頼できるデジタル証明書を入手して DNS レコードに保管し、受信者がそのデジタル証明書を見つけられるようにすることができます。HealthVault ではさらに簡単にデジタル証明書を用意できるように、自分で自己署名証明書を作成し、それを hvbd@microsoft.com に e-メールで送信できるようになっています。すると、HealthVault チームがその証明書を信頼できる証明書としてロードします。自己署名証明書を使用すれば、開発者は至って簡単に Direct システムを実験することができます。

秘密鍵と公開鍵のペア、そしてデジタル証明書は、Apple Keychain のようなツールを使用して簡単に生成することができます。リスト 1 に、よく使われている openssl によるコマンドを記載します。このツールは、一般的なオペレーティング・システムのほぼすべてで使用できるようになっています。

リスト 1. openssl で公開鍵と秘密鍵のペアを作成する
openssl req -new -newkey rsa:2048 -nodes -keyout private.key

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout private.key -out public.crt

openssl pkcs12 -export -in public.crt -inkey private.key -out bundle.p12

リスト 1 の最初のコマンドは、メッセージの署名および暗号化に使用できる秘密鍵を作成します。2 番目のコマンドは、受信者が受け取ったメッセージを復号して検証するために使用する、公開鍵デジタル証明書を作成します。3 番目のコマンドで作成しているのは、アプリケーションで使用する際に便利な、秘密鍵/公開鍵ペアの PKCS12 バンドルです。アプリケーションで使用する場合、バンドルに含まれる秘密鍵の名前とパス・コードの入力を求められる場合があります。

これらのコマンドで作成した public.crt ファイルを Microsoft HealthVault に e-メールで送信すると、Microsoft HealthVault システムは、上記コマンドで作成した秘密鍵で署名されたメッセージを信頼するようになります。

Direct Sender

Direct Sender は、Direct メールを簡単に送信できるようにするために私が作成したオープンソース・ライブラリーです。Direct Sender がホストされている GitHub に、Quick Start チュートリアルも用意しておきました。このライブラリーは e-メール送信をさまざまな方法でサポートします。例えば、自分自身でホストする SMTP サーバーを使用することも、Gmail サーバーや、特化したトランザクション e-メール・サービス (Amazon Web Service Simple Email Service や SendGrid など) を使用することもできます。このライブラリーを使用すれば、例えば Gmail でセキュアな e-メール・メッセージを送信するのに必要なコードは、ほんの数行で済みます (リスト 2 を参照)。

リスト 2. Gmail でセキュアなメッセージを送信する
Client client = new GmailClient (
                username, password,
                "/bundle.p12", keyname, keypass);

client.sendMessage(from, to, subject, body);

リスト 2usernamepassword は、セキュアな e-メールを送信するために使用する Gmail アカウントの資格情報を指します。bundle.p12 は、リスト 1 で作成した PKCS12 ファイルです。このファイルを、必ずアプリケーションのクラス・パスに含めてください。keynamekeypass は、バンドルに含まれる秘密鍵の名前とパス・コードです。

セキュアなメッセージを送信した後、受信箱に新着メッセージがあることを知らせる HealthVault からの通知メールを受信します。この通知を受け取ったら、HealthVault にログインしてメッセージを確認してください。

Direct Sender の内部処理

Direct Sender ライブラリーの使用方法を説明したところで、次は、Direct 対応のフォーマットでメッセージを暗号化して送信するときに、その内部で何が行われているのかを説明します。内部では、以下のオープンソースの Java ライブラリーが Direct Sender のために大変な作業を行っています。

  • Bouncy Castle: JCE (Java Cryptography Extension) の有名なオープンソース実装であるこのライブラリーは、Java プラットフォームでの PKI サポートに必須のツールを提供します。また、S/MIME 暗号化ユーティリティーなどのアドオンも提供します。
  • javamail.crypto: JavaMail Transport API への S/MIME 添付ファイルの組み込みをサポートするライブラリーです。
  • dnsjava: これは、Java ベースの DNS クライアントです。DNS レコードに保管された e-メール・アドレスのデジタル証明書を照会することができます。

Java の Client 抽象クラスは、基本的な署名機能、暗号化機能、S/MIME e-メールの作成機能をサポートしています。リスト 3 では、最初に秘密鍵でメッセージに署名した上で、受信者の公開鍵証明書を使用してメッセージを暗号化していることに注目してください。受信者がこのメッセージを受け取ると、HealthVault は受信者のアドレスの秘密鍵を使用してメッセージを復号した後、送信者の公開鍵 (これが HealthVault に e-メールで送信済みであることが前提) を使用して、送信者の身元を確認します。

リスト 3. クライアントによるメッセージの署名と暗号化の処理
public abstract class Client {
    
    protected String p12KeyStore;
    protected String priKeyName;
    protected String priKeyPass;
    
    public void sendMessage (String from, String to, String subject, String body) 
      throws Exception {
        byte [] pubKeyCer = lookupCertificate (to);
        if (pubKeyCer == null || pubKeyCer.length == 0) {
            throw new Exception ("Cannot find public key certificate for " + to);
        }
        
        Session session = createSession ();
        
        MimeMessage msg = new MimeMessage(session);
        msg.setFrom(new InternetAddress(from));
        msg.setSender(new InternetAddress(from));
        msg.addRecipient(javax.mail.Message.RecipientType.TO, new InternetAddress(to));
        msg.setSubject(subject);
        msg.setText(body);
        
        msg = signMsg(session, msg);
        msg = encryptMsg(session, msg, pubKeyCer);
        msg.saveChanges();
        
        transport(session, msg);
    }
    
    public void sendMessage (String from, String to, String subject, Multipart multipart) 
      throws Exception {
        byte [] pubKeyCer = lookupCertificate (to);
        if (pubKeyCer == null || pubKeyCer.length == 0) {
            throw new Exception ("Cannot find public key certificate for " + to);
        }
        
        Session session = createSession ();
        
        MimeMessage msg = new MimeMessage(session);
        msg.setFrom(new InternetAddress(from));
        msg.setSender(new InternetAddress(from));
        msg.addRecipient(javax.mail.Message.RecipientType.TO, new InternetAddress(to));
        msg.setSubject(subject);
        msg.setContent(multipart);
        
        msg = signMsg(session, msg);
        msg = encryptMsg(session, msg, pubKeyCer);
        msg.saveChanges();
        
        transport(session, msg);
    }
    
    protected byte [] lookupCertificate (String email) {
        try {
            String domain = email.replaceAll("@", ".");
            
            CERTRecord cx = null;
            Record [] records = new Lookup(domain, Type.CERT).run();
            for (int i = 0; i < records.length; i++) {
                cx = (CERTRecord) records[i];
            }
            
            if (cx == null) {
                return null;
            } else {
                return cx.getCert ();
            }
            
        } catch (Exception e) {
            e.printStackTrace ();
            return null;
        }
    }
    
    protected MimeMessage encryptMsg(Session session, MimeMessage msg, byte [] pubKeyCer) 
      throws Exception {
        EncryptionUtils encUtils = EncryptionManager.getEncryptionUtils
          (EncryptionManager.SMIME);
        
        CertificateFactory cf = CertificateFactory.getInstance("X.509");
        X509Certificate cert = (X509Certificate)cf.generateCertificate
          (new ByteArrayInputStream(pubKeyCer));
       
        // wrap certificate in BouncySMIMEEncryptionKey 
        BouncySMIMEEncryptionKey smimekey = new BouncySMIMEEncryptionKey();
        smimekey.setCertificate(cert);

        return encUtils.encryptMessage(session, msg, smimekey);
    }
    
    protected MimeMessage signMsg(Session session, MimeMessage mimeMessage) throws 
    Exception {
        // Getting of the S/MIME EncryptionUtilities.
        EncryptionUtils encUtils = EncryptionManager.getEncryptionUtils
          (EncryptionManager.SMIME);

        // Loading of the S/MIME keystore from the file (stored as resource).
        char[] keystorePass = priKeyPass.toCharArray();
        EncryptionKeyManager encKeyManager = encUtils.createKeyManager();
        encKeyManager.loadPrivateKeystore(Client.class.getResourceAsStream(p12KeyStore), 
          keystorePass);

        // Getting of the S/MIME private key for signing.
        Key privateKey = encKeyManager.getPrivateKey(priKeyName, keystorePass);

        // Signing the message.
        return encUtils.signMessage(session, mimeMessage, privateKey);
    }
    
    protected abstract Session createSession ();
    protected abstract void transport (Session session, MimeMessage msg) throws Exception;
    
}

続いてリスト 4 に記載する GmailClient クラスは、Java の createSession() および transport() メソッドを実装します。この 2 つのメソッドが、Gmail サーバーを介して e-メールを送信できるようにサポートします。

リスト 4. Gmail を介したセキュアな e-メール
public class GmailClient extends Client {

    String username, password;
    
    public GmailClient (String username, String password, String p12KeyStore,
     String priKeyName, 
      String priKeyPass) {
        super.p12KeyStore = p12KeyStore;
        super.priKeyName = priKeyName;
        super.priKeyPass = priKeyPass;
        
        this.username = username;
        this.password = password;
    }
    
    protected Session createSession() {
        Properties props = new Properties();
        props.put("mail.smtp.host", "smtp.gmail.com");
        props.put("mail.smtp.socketFactory.port", "465");
        props.put("mail.smtp.socketFactory.class", "javax.net.ssl.SSLSocketFactory");
        props.put("mail.smtp.auth", "true");
        props.put("mail.smtp.port", "465");
 
        return Session.getDefaultInstance(props,
                new javax.mail.Authenticator() {
                    protected PasswordAuthentication getPasswordAuthentication() {
                        return new PasswordAuthentication(username, password);
                    }
                }
        );
    }

    protected void transport(Session session, MimeMessage msg) throws Exception {
        Transport transport = session.getTransport("smtp");
        transport.connect();
        Transport.send(msg);
        transport.close();
    }
       
}

Direct e-メールの受信

Direct Sender クライアントと併せてセキュアな e-メール用の Direct プロトコルを使用することで、医師がオフィスから簡単かつセキュアに専門医への紹介や検査結果を病院および患者に送信できるようになります。さらには、モバイル医療 (mHealth) アプリケーションを使って、患者から収集したデータをその患者のデジタル医療記録に送信できるようにもなります。多くの医療アプリケーションには、Direct e-メールを送信する機能だけが必要ですが、極めてまれな場合には、アプリケーションがセキュアな e-メールを受信できることも必要になってきます。

大規模な病院 EHR の大半は、ビジネスおよび技術に関する広範に及ぶ監査をせずに、患者の医療記録を送信することはないため、小規模な医療 IT システムがセキュアな e-メールを受信することは通常ないはずですが、別の電子医療記録システムからセキュアな e-メールを受信するとなると、セキュアな e-メールを送信する場合よりも事態は複雑になってきます。医療記録を病院 EHR から受信するには、おそらく、HL7 (Health Level Seven International) フレームワーク (「参考文献」を参照) のような標準技術を使用して、XML-over-HTTPS による直接接続を確立することになります。

別の医療機関から Direct e-メールを受信するためのインハウス・インフラストラクチャーを開発する必要がある場合には、少なくとも以下の作業が必要になります。

  1. データの送信側医療機関との「事業提携契約」を作成すること。これは時間のかかるプロセスになる場合もありますが、事業提携契約によって両者の法的責任が構成されます。
  2. 受信 e-メール・メッセージの自動的な復号および検証に対応できる e-メール・インフラストラクチャーをセットアップし、ファイアウォールの内側で受信者にメッセージを提示すること。

最初に記載した要件はビジネス要件であり、2 番目の要件は技術要件です。IT 管理者が独自の Direct e-メール・インフラストラクチャーをセットアップできるように、Direct Project では、Direct メッセージを処理可能な e-メール・ゲートウェイ・サーバーのオープンソース・リファレンス実装をサポートしています。また、Java EE、Microsoft .Net、PHP などのフレームワーク用のリファレンス実装も提供しています (「参考文献」を参照)。

まとめ

連邦政府および多数の医療システムによるサポートによって、Direct Project は、専門医への紹介、保険情報、検査結果、医療履歴などの単純な医療関連文書を交換する際のデファクト・スタンダードとなるべく絶好の位置にあります。Direct Project は、すでに普及している e-メール・インフラストラクチャーをベースとしていますが、これを導入するかどうかは、セキュアな e-メール標準をサポートするために IT システムを更新する医療機関次第です。医療 IT 業界で働くソフトウェア開発者は、いずれすぐに、Direct プロトコルが電子医療記録をセキュアに送信する上で不可欠な手段であることを認識するようになるでしょう。

Direct や、GitHub でホストされている Java ベースの Direct Sender セキュア e-メール・クライアントについての詳細を学ぶには、「参考文献」を参照してください。

参考文献

学ぶために

  • Direct Project のホーム・ページで、Direct Project およびアクティブなパイロット・サイトに関する詳細を調べてください。
  • Direct セキュア・メッセージの受信がアプリケーション要件の 1 つとなっている場合には、リファレンス実装が、Java プラットフォーム、.Net、および PHP 用に実装された e-メール・サーバーを提供します。
  • アプリケーションを信頼できる Direct e-メールの送信側として Microsoft HealthVault にセットアップする方法の詳細を学んでください。
  • クラウドでの患者データのプライバシーとセキュリティー」(Erin Gilmer 著、developerWorks、2012年10月): HIPAA (Health Information Portability and Accountability Act) および HITECH (Health Information Technology for Economic and Clinical Health) 法の詳細、そしてこれらの規制が医療 IT に与える影響について学んでください。
  • developerWorks に掲載されている Yuan 博士の他の記事を読んでください。
  • developerWorks の Innovations in Health IT に掲載されている Yuan 博士の医療 IT 業界に関するブログも読んでください。
  • The $10M investment in DIRECT from eClinicalWorks」(Michael Yuan 著、Innovations in Health IT、2012年9月) では、eClinicalWorks などの EHR システムが Direct Project にいかに大きな資金を投資しているかを取り上げています。
  • PKI: A primer」(Joe Rudich 著、developerWorks、2000年12月) で、公開鍵インフラストラクチャーについて学んでください。
  • S/MIME を利用して電子メールのセキュリティーを強化する」(Chuck Connell 著、developerWorks、2001年12月) では、Secure Multipurpose Internet Mail Extension プロトコルと、S/MIME 認証における公開鍵暗号の役割を紹介しています。
  • National eHealth Collaborative は、米国において医療情報交換の開発および導入を促進している、官民協働組織です。米国連邦政府による CONNECT プロジェクトと Direct Project の統括組織でもあります。
  • Direct セキュア e-メール標準は、IETF の S/MIME 標準である RFC 3851 をベースとしています。
  • DNS サーバーでのデジタル証明書保管に関する IETF 標準により、セキュアな e-メールの受信側は、送信者の身元を確認することができます。
  • Bouncy Castle は、JCE (Java Cryptography Extension) のオープンソース・プロバイダーです。S/MIME のサポートも提供します。
  • JavaMail-Crypto API は、JavaMail で暗号化 e-メールを管理するため API 拡張です。
  • DNSJava プロジェクトは、DNS サーバーと対話するための Java API を提供します。このプロジェクトには、DNS システムに保管される e-メール証明書に対するサポートも含まれます。
  • Direct メッセージを送信するためのトランスポートとして使用できるトランザクション e-メール・サービスには、Amazon Simple Email ServiceSendGrid の 2 つがあります。
  • Twitter で developerWorks をフォローしてください。
  • developerWorks の on-demand demos で、初心者向けの製品のインストールとセットアップから、熟練開発者向けの高度な機能に至るまで、さまざまに揃ったデモを見てください。

製品や技術を入手するために

  • Direct sender は、Direct プロトコルを実装するオープンソース Java クライアントです。Direct Sender により、医療 IT システムで Direct セキュア e-メールを送信するプロセスが簡易化されます。
  • 代表的な PHR (Personal Health Record) システムの 1 つである Microsoft HealthVault は、Direct プロトコルをサポートしています。
  • OpenSSL は、セキュアな e-メールに必要な秘密鍵と公開鍵のペアおよび証明書を生成するためのオープンソースのツールです。
  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, Java technology, Open source
ArticleID=848024
ArticleTitle=Direct Project: クラウド上で医療情報を送信する
publish-date=12062012