christopher bischoff's List: Healthcare

• Direct Components

   

  An early philosophy of Direct was to build on top of existing standards already ubiquitously deployed. What better way to design an infrastructure that could be quickly implemented and rolled out if a large portion of the work was already done for you? And to add icing to the cake, it was already built for scalability and readily available to a global community. These were driving factors that lead to the final specification of the Direct protocol, defined in a document called the Applicability Statement for Secure Health Transport. Direct is a set of standards, but what are those standards, and how do they translate into tangible components? The standards break out into five concepts:

   
   
   
  • Backbone  transport and universal addressing
   
  • Messaging  gateway
   
  • Security  and trust
   
  • Edge  protocols
   
  • Source  and destination clients

• Health Information Service Providers

   

  Before getting into the nuts and bolts of Direct concepts, a key term needs to be defined. All of the components in the previous section work together to provide the functionality of Direct, but who or what provides and hosts these services? Is there an enchanted black box sitting in the ether waiting to accept your messages and magically transport them to land of data tranquility? As much as it sometimes appears that way, it takes something a little more concrete to achieve technological nirvana. In Direct, this mysterious entity that powers data exchange is called a HISP.

   

  A HISP is a logical concept that encompasses certain services required for Direct data exchange. In a concrete instance, a HISP hosts all of the components and services necessary for a participant in information exchange to send and receive data. In some instances, a HISP is a separate business entity that may or may not have a stake in the information that moves through the system. Another way to think of a HISP is like your internet service provider (ISP). Your ISP hosts and provides you with services such as a network connection, internet address allocation, email, news, and possibly a slew of other multimedia options. A HISP provides a participant in Direct with the same type of value, except the services are Direct concepts such as universal addresses, certificate management, security, trust management, and information transport.

• Backbone Transport

   

  Since a HISP can host services for multiple Direct participants, there are several instances where information is exchanged among participants utilizing the same HISP. But, what about those situations where the participants subscribe to services from different HISPs? An analogy is two email subscribers using services from two different email providers like Hotmail and Gmail. If two subscribers were both using Hotmail, a message could be routed internally by internal proprietary protocols to optimize system performance. However, a message addressed to a Gmail account from a Hotmail account needs to travel between the two providers over a standard communication protocol understood by both parties. In Direct terms, this common protocol between HISPs is called the backbone transport. The backbone transport is the protocol utilized for HISP-to-HISP communication.
• Additional work is currently being done to provide further guidance for HISPs' responsibilities in terms of quality of service. Some use cases utilizing Direct will absolutely require certain levels of message delivery assurance or negative acknowledgement.

• Message Gateway

   

  The message gateway is not so much a concept as it is an implementation detail of the backbone transport. When a message is addressed to a recipient within the same HISP as the sender, the Direct Project does not specify how the HISP routes the message internally. However, if the sender and recipient are not within the same HISP, the message must be transported from the sender's HISP to the recipient's HISP. This is where the message gateway comes into play. The message gateway is the component inside the sender's HISP that is responsible for taking the messages and transporting it to the remote HISP. In the recipient's HISP, the message gateway is responsible for receiving the message from a remote HISP and handing it off to the appropriate internal components that will ultimately deliver the message to the final endpoint. In some deployments the gateway may also be the internal routing and delivery mechanism, but this is specific to the implementation of the HISP.

   

  The message gateway is the outermost component of a HISP in terms of network topology and exchanges messages using SMTP directly over the internet. It is the point of entry and exit of a message to and from a HISP. Using best practices, the message gateway would be an enterprise class SMTP server such as Cisco IronPort. Open source SMTP servers such as Apache James or Courier are capable messaging gateways, but because the message gateway is exposed directly to the public internet, it is susceptible to all sorts of attacks. According to some estimates, roughly 90 percent of all email messages are considered spam. Although the security and trust components described in the next section will filter out spam and untrusted messages, it is much more efficient to use a good spam filter to remove unwanted messages at the HISP's point of entry.

3 more annotations...

• The Obvious Questions

   

   

  Like any other decision to subscribe to a utility, we think it’s prudent to go through your standard evaluation questions:

   

   

  What is the financial viability of the company offering the HISP services?

   

  Are customer references available?

   

  How are the services priced?

   

  How long has the company running the HISP been in (the health care) business?

   

  How long has the company been in the secure communications line of business?

   

   

  Where you weight these evaluations is dependent upon your organization’s appetite for risk and valuation of communicating via Direct.

• Technologies Used

   

   

  This is a tricky one for us. As software architects and engineers, we’re very curious about how things are accomplished technically. So we have to remind ourselves that this blog post is not about buying/acquiring software to start a HISP business, it’s about gaining access to a set of HISP services. With that in mind, asking whether the HISP uses LDAP or Java seems similar to asking your telecom provider whether they use short-mast cell sites or camouflaged monopoles. It’s probably better to stick to the “what” than to dive into the “how." (Even though we really are curious…)

• Direct Addresses

   

   

  What’s in a name? In our minds, your organization’s “brand” is vitally important for all sorts of reasons, so we’d definitely want to know the answer to:

   

   

  Does the HISP enable you to define your own Direct email domain that is yours to keep?

   

   

  We believe a HISP should offer you the choice of defining and using your own domain name to use in providing a universal, Direct email address to your users.

• Reliability

   

   

  You will count on your HISP to deliver your secure messages, and to let you know when it can’t. With the nature of email, guaranteed delivery of messages can be complicated, especially with the unique security constraints the Direct Project introduces.

   

   

  Does the HISP guarantee delivery of messages?

   

   

  Without storing or analyzing the message content, a HISP should track the actions of every message sent or received through it and relate message delivery notifications (MDNs) and replies to the original message. According to section 3 of the Direct Project Applicability Statement, every HISP must send a processed MDN once trust has been verified. If a HISP does not receive a processed MDN in a timely manner, it should proactively send standard email bounce messages to the sender to inform them of the inability to deliver; therefore restoring the typical email system quality of service your end users expect.

   

   

  How does the HISP guarantee messages have been accepted by the recipient's HISP?

   

   

  We also recommend email clients and end users take advantage of standard read receipt functionality. When used by both the sender and receiver, this provides additional validation the message was received.

   

   

  Does the HISP audit all messages?

   

   

  Every message sent or received through a HISP should be logged and be available for audit in a secure way. In addition, if the HISP offers a user interface to manage messages, it should include auditing for HIPAA disclosure and security. Audit events should be logged when messages are sent, read, printed, exported, and when attachments are opened.

   

   

  Does the HISP provide reports on message throughput?

   

   

  Message throughput reporting provides you useful insight into the communication patterns occurring in your community. Can the prospective HISP provide the capability to review information like number of messages sent, number of messages received, percentage of 1 way messages vs. 2 way conversations, etc.?

• Leadership and Experience

   

   

  We feel it’s important to align yourself with a utility provider that possesses the knowledge to help you lead effective and complete information exchange efforts. We’d also prefer our HISP to be involved in standards setting and proving. Ask these types of questions to determine whether the company can deliver:

   

   

  Is the HISP part of the Direct Project Implementation Group?

   

  Did the HISP participate in any Direct Project pilots?

   

  Does the HISP contribute code or expertise to the .Net or Java reference implementations?

   

   

  Selecting a partner that has a wide range of services and experience within the interoperability space will help you better meet the varied needs of your organization, regardless of where it is on the technology adoption spectrum.

3 more annotations...

• Direct specifications state that all messages on the backbone protocol have a MIME content type of application/pkcs7-mime – the content type of an encrypted S/MIME message. The security and trust agent is responsible for encrypting and decrypting all outgoing and incoming messages, respectively, using PKI and X509 certificates. For the purpose of S/MIME, certificates contain the keys that are used to encrypt and decrypt messages.
• Every endpoint in Direct is associated with one or more X509 certificates. When a message is addressed to a recipient, the message is encrypted using the recipient's public key contained in the associated certificate using S/MIME standards

• Certificate Discovery

   

  I have made several references to certificates being "discovered" for encryption, decryption and signature operations. PKI can be difficult to implement, and certificate discovery is just one small piece of the puzzle. There are two use cases of certificate discovery in Direct: private and public discovery. Private discovery refers to accessing a certificate along with its private key and is only applicable to addresses maintained by a HISP. It is up to the HISP to implement proper protection of private keys and the methods to access them. Direct implements a few certificate resolvers for discovering private certificates, but they do not meet policy requirements of legitimate PKIs (more on policy later).

   

  Public discovery refers to finding certificates that are not managed by the HISP and is a much more interesting problem. Public discovery has three problems to overcome:

   
   
  • Where a certificate is stored
   
  • What protocol to use
   
  • How to uniquely identify the certificate with a query
   
   
   

  Additionally, a universal discovery method is desirable to reduce variance and ensure interoperability. Because Direct wanted to use existing and ubiquitous standards, DNS using CERT-type records was originally selected as the preferred method. LDAP was added later as a secondary method and standardized by the S&I Framework initiative. HISPs can utilize either DNS or LDAP servers to publish Direct certificates, but they must support both discovery methods from a client perspective.

• Trust

   

  Arguably the most important aspect of the security and trust specification is the trust model. The encryption and message signature algorithms ensure a message is securely transported from one location to another without being compromised or tampered with, but what value is a message if you do not trust its contents? In theory, anyone can set up a HISP, create certificates, and claim to have some type of authoritative credential, such as being a covered entity. Message sources may be able to irrefutably attest to their identity assigned to them by their HISP using a certificate, but how does a receiving participant know that they can trust the content of the dialog? In other words, if I receive a message from Dr. Bob, how do I know the public certificate that signed the message actually represents Dr. Bob? The attributes in the certificate say it is Dr. Bob, but is the HISP that gave Dr. Bob that certificate actually trustworthy? What if the Dr. Bob in question is really a malicious hacker who stood up his own HISP to spoof the real Dr. Bob's legitimate healthcare organization
• The security and trust model allows HISPs to filter and accept messages only from other HISPs that they deem trustworthy. Transitively, a HISP should only allow the creation of addresses for participants that they deem trustworthy. This leads into the subject of identity proofing, certificate policies and PKI trust frameworks. These are outside the scope of the trust model as defined by the applicability statement, but there are efforts in the Direct community solely focused on this topic. However, as a rule of thumb, only HISPs that follow and can prove to abide by good certificate practices and identity proofing procedures should be deemed trustworthy. Trust is not an absolute indicator of truth, but subjective only in how much a recipient wants to trust a sender. In the context of health care data, trust of a message's content can result in a life-changing decision, and in the extreme, a case of life or death.

3 more annotations...

• The reference implementation comes with a standard deployment model and software components such as the security and trust agent, the messaging gateway, a certificate store and a simple web or command line tool for configuration. However, the model does not meet the requirements of an industry-class production system, such as high availability, failover, scalability and disaster recovery. The only edge protocol supported is XD and POP/SMTP, and although this may work well for email clients, innovative edge clients and workflows may need other protocols such as REST, SOAP, and custom authentication and authorization modules.

   

• Identify Proofing

   

  Like so many other topics in Direct, identity proofing concepts and procedures could make up an entire book. Grossly over-simplified, identity proofing is the process of assuring that an entity really is what it says it is. Entire workgroups are dedicated solely to the practice and policies of identity proofing, and adherence to these policies is a requirement of a HISP.

   

  In Direct there are two types of entities that are identity proofed: individual users and organizations. In the case of users, a certificate is issued to each email address. For organizations, a single certificate is issued for an entire institution or larger entity, generally at the email domain level though that’s not always the case. Only the organization is identity proofed for the purpose of certificate issuance, and the organization is responsible and liable for the vetting of each email address that is issued.

• Certificate Management

   

  Certificate management refers to the policy and procedures used to manage the lifecycle of a certificate. These include issuance, revocation, renewal and rekeying. It can also refer to the procedures used to protect the integrity of the PKI. This mainly covers protecting private keys, backing up keys and auditing access to keys. Many of these procedures are outlined in a CPS and handled by the certificate authority. In the case of HISPs, issued certificates and their keys are held by the HISP, not the actual entities. This model is slightly different from most PKIs, where the entities hold their own certificates and private keys. Because the HISP is the steward of the keys, it must take proper care in managing and protecting keys from unauthorized access or malicious attacks.

1 more annotation...

• One example where Simple Interop could immediately provide value is the electronic sending of documents over telephone lines. Tech elders would recognize this as faxing. Several different instances of the exchange of health care information could take advantage of this, including:

   
   
  • Primary  care provider referring a patient to a specialist including summary care  record
   
  • Sending  of lab results to an ordering provider
   
  • Provider  sending health information to a patient
   
  • Primary  care provider sending a patient's immunization data to public health  entity
   
   
   

• The Direct Project

   

  Simply put, the Direct Project is a set of specifications and standards. It specifies a simple, secure, scalable, and standards-based method for participants to send authenticated, encrypted health information directly to known, trusted recipients over the internet. At its core, it defines a security and transport protocol for exchanging information independent of exchange payload content. Combined with pre-negotiated, structured payloads between endpoints, innovative workflows can be implemented on top of Direct to meet requirements of Stage 1 and Stage 2 Meaningful Use.

• Direct is a set of standards, but what are those standards, and how do they translate into tangible components? The standards break out into five concepts:

   
   
   
  • Backbone  transport and universal addressing
   
  • Messaging  gateway
   
  • Security  and trust
   
  • Edge  protocols
   
  • Source  and destination clients
• but who or what provides and hosts these services? Is there an enchanted black box sitting in the ether waiting to accept your messages and magically transport them to land of data tranquility? As much as it sometimes appears that way, it takes something a little more concrete to achieve technological nirvana. In Direct, this mysterious entity that powers data exchange is called a HISP.
• A HISP is a logical concept that encompasses certain services required for Direct data exchange. In a concrete instance, a HISP hosts all of the components and services necessary for a participant in information exchange to send and receive data. In some instances, a HISP is a separate business entity that may or may not have a stake in the information that moves through the system. Another way to think of a HISP is like your internet service provider (ISP). Your ISP hosts and provides you with services such as a network connection, internet address allocation, email, news, and possibly a slew of other multimedia options. A HISP provides a participant in Direct with the same type of value, except the services are Direct concepts such as universal addresses, certificate management, security, trust management, and information transport.

• Message Gateway

   

  The message gateway is not so much a concept as it is an implementation detail of the backbone transport. When a message is addressed to a recipient within the same HISP as the sender, the Direct Project does not specify how the HISP routes the message internally. However, if the sender and recipient are not within the same HISP, the message must be transported from the sender's HISP to the recipient's HISP. This is where the message gateway comes into play. The message gateway is the component inside the sender's HISP that is responsible for taking the messages and transporting it to the remote HISP. In the recipient's HISP, the message gateway is responsible for receiving the message from a remote HISP and handing it off to the appropriate internal components that will ultimately deliver the message to the final endpoint. In some deployments the gateway may also be the internal routing and delivery mechanism, but this is specific to the implementation of the HISP.

   

  The message gateway is the outermost component of a HISP in terms of network topology and exchanges messages using SMTP directly over the internet. It is the point of entry and exit of a message to and from a HISP. Using best practices, the message gateway would be an enterprise class SMTP server such as Cisco IronPort. Open source SMTP servers such as Apache James or Courier are capable messaging gateways, but because the message gateway is exposed directly to the public internet, it is susceptible to all sorts of attacks. According to some estimates, roughly 90 percent of all email messages are considered spam. Although the security and trust components described in the next section will filter out spam and untrusted messages, it is much more efficient to use a good spam filter to remove unwanted messages at the HISP's point of entry.

4 more annotations...

• The two basic goals of the original Direct Project charter were to:

   

  1. replace the use of fax/phone/paper, with a simple and secure point-to-point communication over the Internet, and 
  2. do so in such a way that did not require creation of a new legal framework; rather relying on existing organizational legal policies and procedures covered under HIPAA.
• The term “HISP” (Health Information Service Provider) describes an outsourced email service provider that follows Direct Project standards and represents the mechanism used to provision users with a universal, Direct email address. The HISP provides its users with an infrastructure that can manage message encryption, the “circles of trust” as to who can be communicated with, and the incorporation of appropriate policies and procedures necessary to ensure a level of confidence in provisioning members on the network appropriate to healthcare.
  
  Direct Project standards can be used to support a variety of “meaningful" use cases such as referrals, lab results and provider-patient communication. The Direct Project is not meant as a replacement for all the other methods for which data is electronically exchanged today, rather it was designed to supplement existing protocols and to create an eventual path to more sophisticated levels of interoperability.

• The technical aspect of "meaningful use" is specified more precisely when associated with interoperability, functionality, utility, data confidentiality and integrity of the data, security of the health information system in general.

• Security vendors market solutions for Protected Health Information (PHI) because HIPAA and HITECH impose data security and privacy requirements
• Tokenization is one of the technologies being discussed to help secure medical information, based on its success with payment card data, but unfortunately protecting PHR is a very different problem.
• A few firms have adopted tokenization to substitute for personal information – usually a single token that represents name, address and Social Security number – with the remainder of the data in the clear. But this use case is a narrow one. The remainder of the health-related data used for analysis – age, medical conditions, medications, zip code, heath care, insurance, etc. – can be used while the patient (theoretically) remains anonymous.
• So while there is a lot of hype around tokenization for PHI, here’s why the model does not work. It’s a ‘many-to-many’ problem: we have many pieces of data which are bundled in different ways to serve many different audiences. For example, PHI is complex and made up of hundreds of different data points. A person’s medical history is a combination of personal attributes, doctor visits, complaints, medical ailments, outsourced services, doctors and hospitals who have served the patient, etc. It’s an entangled set of personal, financial, and medical data points. And many different groups need access to some or all of it: doctors, hospitals, insurance providers, drug companies, clinics, health maintenance organizations, state and federal governments, and so on. And each audience needs to see a different slice of the data – but must not see PHI they are not authorized for.
• The problem is knowing which data to tokenize for any given audience, and maintaining tokens for each use case. If you create tokens for someone’s name and medical condition, while leaving drug information exposed, you have effectively leaked the patient’s medical condition. Billing and insurance can’t get their jobs done without access to the patient’s real name, address, and Social Security number. If you tokenized medical conditions to ensure patient privacy, that would be useless to doctors. And if you issue the same tokens for certain pieces of information (such as name & Social Security number) it’s fairly easy for someone to guess the tokenized values from other patient information – meaning they can reverse engineer the full set of personal information. You need to issue a different token for each and every audience, and in fact for each party which requests patient data.
• Can tokens work in this ‘many-to-many’ model? It’s possible but not recommended. You would need a very sophisticated token tracking system to divide up the data, issuing and tracking different tokens for different audiences. No such system exists today. Furthermore, it simply does not scale across very large databases with dozens of audiences and thousands of patients.

4 more annotations...

• NAHIT Has Defined EMR and EHR
   The NAHIT has produced the following definitions for EMR and EHR:

   

  EMR: The electronic record of health-related information on an individual that is created, gathered, managed, and consulted by licensed clinicians and staff from a single organization who are involved in the individual’s health and care.

   

  EHR: The aggregate electronic record of health-related information on an individual that is created and gathered cumulatively across more than one health care organization and is managed and consulted by licensed clinicians and staff involved in the individual’s health and care.

   

  By these definitions, an EHR is an EMR with interoperability (i.e. integration to other providers’ systems).

• A “wicked problem” is one that has the following characteristics:

   
   
  • You don’t understand the problem until you have developed the solution. Essentially the problem is ill defined and “what the problem is” depends on who you ask—different stakeholders will have different views.
   
  • Wicked problems have no stopping rule. Since there is no definitive “problem” there can be no definitive “solution.”
   
  • Solutions to wicked problems are not right or wrong. They are just “better” than others, or “worse” or “good enough”—there is little objective criteria by which they can be judged.
   
  • Every wicked problem is essentially unique and novel. No two organizations are exactly alike, and even different functional units within a given organization may have radically different management styles and/or team dynamics.
   
  • Every solution to a wicked problem is a “one shot operation.” Every attempt made at solving the problem has consequences in terms of time and money spent and therein the “wickedness” is best exposed

• benefits of EHRs. My comments below in italics.

   

  Health information recording and clinical data repository - immediate access to patient diagnoses, allergies, and lab test results that enable better, more timely medical decisions.
  
   Sharing of information, connectivity and interoperability - provides information to caregivers, supports teamwork among caregivers, and helps support continuity of care across the span of a clinical condition.
  
    Accessing information—Results management - provides rapid ability to analyze current and historical test results.
  
    Medication management - a huge benefit because it can provide real-time access information for online ordering lab, radiology, procedures, immunizations, supplies, and education regarding potential adverse drug events.
  
    Order entry and management - provides online entry and storage of physician orders for medications, tests and other services.
  
    Decision support—Office work flow management-Standards of care - Wow this is a huge advantage with real-time access. The ability to capture and use quality medical data for decisions in the workflow of healthcare delivery is essential.
  

• Most IT systems like EMRs, EHRs, and other medical record capture and retrieval products are purportedly designed for physicians but they really are created to improve the hospital administrators' lives, get data to government agencies looking for comparative medicine, push paperwork through to insurance companies so that they can deny claims faster, and many other "features" that don't really do anything for the doctor.

    

  The problem is not that doctors don't like IT, it's that they don't get the same value out it that other participants in the system do.
• EMRs today are like CASE tools were back in the early 90's. Think back to the early- to late-90's and all the talk surround CASE (computer aided software engineering) and how, by automating requirements gathering and coding tasks we would "improve the engineer" and perhaps even get rid of programmers. Pretty soon we realized that programming is a cognitive process not easily modeled or automated -- we realized that the training and tasks performed by programmers and engineers can't easily be improved. Once we gave up on CASE tools (and how to improve programmers' thought processes) we learned that we could improve significant tasks like editing, compiling, testing, etc and the actual application lifecycle.

• The same way CASE tools failed to improve programmers and thus failed as an industry, EMRs that strive to improve physicians' thought processes or try to change how they treat patients will fail as well. That's because physicians are trained in a combined scientific and socratic method -- based on case studies backed by science. Physicians using EMRs will be no better doctors than lawyers would be better lawyers because they use a case management system.

    

  So, how do we get physicians to change their behavior and adopt healthcare IT systems? Easy. You can't in the short term. In the long term, once we figure out that the edges of healthcare (as opposed to the direct patient care) can be easily improved through better operations and automation of routine tasks we'll end up creating useful systems.
• And therein lies the rub: physicians will not adopt systems that do not provide clear and easily understandable value to them (not just their employers). Because most EMRs today have more value to hospitals, government, and insurance firms and little or no innate value across the board to doctors there won't be huge adoption like we're hoping

• Here are some simple questions that doctors will want answered before they adopt anything:

    
   
  • Can I spend more time on my patient's care versus documenting the encounter?
   
  • Can I go home earlier because the system helps me finish my work faster?
   
  • Will my patient be more satisfied because I'm using the system?
   
  • Will the outcome of care be improved because I'm using the system?
   
  • How many more patients per day will I be able to see because of the system?
   
  • How many fewer lawsuits will be filed because I used the system?
   
  • How many more lawsuits will I win because I used the system?
   
  • How will the system be able to increase my patient population or help me market my services better?
   
  • How much faster can I get paid for my services after I'm using the system?
   
  • Can I get access to my data while I'm away from home or the office?
   
    

  These are usually the kinds of questions going through physicians' heads when you're showing them a system. If you're not ready to answer them your solution probably has little value to them and they're not about to change their behavior to adopt it.

3 more annotations...