The goal of health information exchange (HIE) is to facilitate access to and retrieval of clinical data to provide safe, timely, efficient, effective and equitable patient-centered care. HIE also can be used by public health authorities to assist in the analysis of the health of populations.
Today's health information exchange mechanisms utilize multiple standards. Direct, HL7 V2, CDA, IHE XD* and FHIR™ are deeply engrained in the way healthcare systems are designed to interoperate today. In order to achieve greater data liquidity, technology solutions must leverage all the available and emerging standards.
The HL7 Version 3 Clinical Document Architecture (CDA®) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange between healthcare providers and patients. Consolidated CDA (C-CDA) is an HL7 Implementation Guide for CDA R2.0 that defines templates for representing several common types of clinical documents (also called Clinical Notes) used to share clinical information between providers, patients, and payers today. The type of C-CDA documents used to share a Patient's medical history over a period of time is called a Continuity of Care document (CCD). EHR support for creating and receiving CCD documents via Direct was first required by ONC and CMS under the Meaningful Use NPRMs.
HL7 V2 is a clinical messaging content and transport standard. It defines a format for representing data about events that occur inside a care organization.
Integrating the Healthcare Enterprise (IHE) is an international standards development organization that develops and maintains interoperability standards for the exchange of information used in all areas of healthcare. They have specified several Cross-Enterprise and Cross-Community specifications that establish standardized ways of querying for and retrieving documents and other forms of clinical information.
The HL7 FHIR® (Fast Healthcare Interoperability Resources) standard defines how healthcare information can be exchanged between different computer systems regardless of how it is stored in those systems. It allows healthcare information, including clinical and administrative data, to be available securely to those who have a need to access it, and to those who have the right to do so for the benefit of a patient receiving care. The standards development organization HL7® (Health Level Seven®) uses a collaborative approach to develop and upgrade FHIR.
FHIR™ is based on internet standards widely used by industries outside of healthcare. In particular, these include the REST approach, which describes how individual packets of information (termed Resources) can be shared easily. By adopting existing standards and technologies already familiar to software developers, FHIR™ significantly lowers the barriers of entry for new software developers to support healthcare needs. Application Interfaces (APIs) developed using FHIR™ are accelerating adherence to ONC and CMS mandates in the Interoperability and Patient Access NPRMs.
Direct Secure Messaging is a way to exchange health care data via an internet-based tool with national encryption standards. Direct is a national encryption standard for securely exchanging clinical healthcare data via the Internet. It is also known as the Direct Project, Direct Exchange and Direct Secure Messaging. Direct was born out of The Direct Project, which began in 2010 as a grass-roots public/private partnership focused on creating a simple and low-cost mechanism for healthcare interoperability.
Direct Secure Messaging is often compared to sending an email. However, Direct exchange is much more secure and can be more integrated into other health IT products. A Health Information Service Provider, or HISP, maintains a SMTP server and is responsible for the information exchange that happens between entities participating in the DirectTrust network. The HISP carries out the encryption/decryption and digital signing of each message and attachment, as the Security/Trust Agent box within each HISP. Each sender and receiver in the DirectTrust network has a unique Direct address associated with an identity proofed account. Direct messages can have any type of file attachment which makes them "payload agnostic". Each message and its attachments are encrypted along the entire route from Sender to Receiver, to protect the privacy of the content as it passes through the internet.
Timely, secure, and trusted exchange of health information is critical to patient care. Direct Secure Messaging provides for that exchange across organizational boundaries. Utilizing the consensus-based Direct Standard™, Direct exchange is simple, secure, and scalable, and everyone participating in the network has a trusted identity. Available through certified EHRs and other organizations known as Health Information Service Providers (HISPs), Direct is readily available for providers to share data with other providers as well as patients, eliminating redundancy of diagnostic testing, reducing the cost of care and easing inconvenience on patients and providers alike. Direct exchange enables healthcare related communications that help patients receive better coordinated care which leads to better outcomes, and ultimately improves patient and provider satisfaction.
Direct Secure Messaging is used for many purposes, including transitions of care from one provider or setting to another, referrals from one provider to another, provider to patient/consumer communication, public health reporting, transferring a patient from EMS to the ER, and many other purposes.
Yes. MaxMD’s security policies meet 100% of the technical and security requirements of 45 CFR Parts 160 and 164, sub parts A and C. Our technical infrastructure is housed at a SSAE 16 Type II Soc 1 certified facility which undergoes annual independent audits. MaxMD is also independently accredited by the Electronic Healthcare Network Accreditation Commission (EHNAC) as a Health Information Service Provider (HISP), Registration Authority (RA), and Certificate Authority (CA). EHNAC performs a comprehensive review of MaxMD’s technical infrastructure, policies and procedures on alternating years. Finally, MaxMD also has an audited business recovery plan.
In 2011, it was decided an organization would be needed to grow a "trust community" to support the standard utilized for Direct Secure Messaging. DirectTrust was launched as a not-for-profit trade association in 2012 to support trusted health information exchange and was funded in part for a few years by a cooperative agreement with the Office of the National Coordinator of Health Information Technology.
As of the first quarter in 2021, over 257,000 organizations with more than 2.63 million Direct addresses were sending and receiving information at the rate of approximately 172 million messages per quarter. The number of Patient Direct addresses had increased from 548,955 in 2020 to over 655,342 in Q1, 2021.
Yes. MaxMD supports access to the DirectTrust.org directory in three ways: a filter tool on the max.md website, the native address book within Hosted Direct mdEmail Version 3.0 accounts, and by calling the directory through a MaxMD API. DirectTrust policy requires that an organization must be a part of the directory in order to access the directory.
Yes. If you have a unique HIT application with a messaging capability or a dedicated mail server, MaxMD can interface our HISP via the EaaS® configuration. If you don’t have an application to leverage, MaxMD provides a standalone Hosted Direct mdEmail® Version 3.0 product. Hosted Direct mdEmail® Version 3.0 is accessible via mobile devices, desktop clients (e.g. Thunderbird or Outlook), or our webmail client which can even be branded with your custom colors and logo.
Yes. MaxMD is interoperable with 100% of the HISPs in the DirectTrust Accredited Trust Bundle. We also allow clients to customize their own Trust Relationships by adding unaccredited HISP’s certificates to their own unique trust bundle with the completion of proper documentation.
Yes. A message notification feature is standard to the Direct mdEmail® Version 3.0 product. Notifications can be either an SMS message to a mobile phone or an email notification to a designated non-direct address. Notifications can be turned on or off through an admin-controlled setting.
DirectTrust operates as a trusted network designed to improve interoperability between disparate systems and improve care coordination between healthcare professionals. Identity proofing requirements of DirectTrust create a spam-proof, spoof-proof network with a foundation of trust-in-identity. DirectTrust policy requires each user of the Direct Protocol to be proofed to specific National Institute of Standards and Technology digital identity guidelines. These guidelines establish the federated proofing rules each HISP/RA/CA in the DirectTrust network must follow.
Yes. Often, Covered Entities perform background checks and vetting when hiring employees. As an EHNAC Accredited Registration Authority, MaxMD can leverage these "antecedent proofing" efforts as allowed in the DirectTrust Certificate Policy. MaxMD can identity proof one individual at an organization as a Trusted Agent who will attest to the identity of all employees designated as authorized users by the organization. This option reduces the administrative burden when getting started with Direct.
MaxMD EaaS® configuration is typically implemented in 10 days or less. The fastest implementation to an inpatient EHR was achieved in 2 hours. The timeline for delivery of Hosted Direct mdEmail® Version 3.0 is within 24 hours of procurement and completion of the MaxMD Implementation Checklist.
Yes. MaxMD adheres to The Direct Project's Applicability Statement for Secure Health Transport Standards which defines certificate backed exchange and establishes how domain names can be used within the DirectTrust network. MaxMD will assist you in creating a sub-domain such as direct.yourdomain.com which can be used for your Direct addresses.
Yes. To satisfy requirements of the Direct Protocol, each provider or practice staff member accessing an organization-, departmental-, or workflow-level address must be identified as a unique authorized user in order to create the requisite audit trail for all activity.