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.
There are acknowledged risks associated with rending pdf content from outside sources whose handling of the pdf may not be trusted fully. For example, a pdf document could contain malicious code which, when rendered, activates that code to negatively impact the recipient’s environment. For that reason, HL7 chooses not to provide the capability to render an attached pdf document directly from the body of a CDA document using the xslt stylesheet.
Implementers can implement the following process to render the non-xml-body content to support human review of this included material:
Following this process allows the stylesheet to generate proper HTML tag (<img>, <iframe> etc) to render the content at the link.
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.
A digital signature takes the concept of a traditional paper-based document signature and turns it into a digital lock and key with a recorded fingerprint to boot. This "lock and key" is unique to both the document and the signer and binds the two together. The digital fingerprint makes is possible to determine if anything about the document or the signature has changed. A digital signature therefore ensures the identity of the signer and the authenticity of the document. Any change made to the document after it is digitally signed invalidates the "fingerprint" thereby protecting the document (and the signer) against information forgery or tampering.
An electronic signature is not a digital signature although it is implemented for digital documents. The term "electronic signature" (or e-signature) refers to all types of digital attestations of a signature event which may take the form of a graphic representation of a signature, a person’s voice attesting to the signing act, or the application of a digital signature which locks and fingerprints the signed information. Electronic signatures may take the form of a symbol added to the file that is being signed. It can be an attached sound or JPEG file to represent a signature. Or it can involve digitally signing the information with specialized digital signature mechanisms. An electronic signature process logically associates a person’s intent to sign the record or document with the record or document itself.
An electronic signature conveys the act of signing a digital artifact. However, all e-signatures do not convey trusted identities or maintain integrity and security for the information being signed. There is nothing to prevent one individual from typing another individual's name. And, there is no mechanism to detect if the material affixed to the electronic signature has been altered.
Only digital signatures offer this level of trust and protection. Digital signatures provide the highest form of signature authenticity and content integrity as well as universal acceptance.
Digital signatures technology is based on Public Key Infrastructure (PKI) and is a result of a cryptographic operation that guarantees signer authenticity, data integrity and non-repudiation of signed documents. The digital signature cannot be copied, tampered or altered. In addition, because they are based on standard PKI technology, digital signatures made within one application (e.g. Microsoft® Word, Adobe® PDF) can be validated by others using the same applications.
On the other hand, an electronic signature uses a proprietary format, such as a digitized image of a handwritten signature, a symbol, voiceprint, etc., that identifies the author(s) of an electronic message. There is no standard for electronic signatures.
An electronic signature is vulnerable to copying and tampering, making forgery easier. An electronic signature which is not digital signature often requires proprietary software to validate the signature. Further, electronic signatures are not legally binding where digital signatures are.
Public Key Infrastructure (PKI) forms the basis for the digital signature today. PKI provides each user with a pair of keys, a Private Key and a Public Key, used in every signed transaction. The Private Key, as the name implies, is not shared and is used only by the signer to electronically sign documents. The Public Key is openly available and used by those that need to validate the signer’s electronic signature. PKI encompasses different components which include a Certificate Authority (CA), end-user enrollment software, and tools for managing, renewing, and revoking keys and certificates.
Organizations adopt digital signature solutions to cut operational costs, automate and expedite business processes reduce the production or consumption of paper, and most importantly, to meet legal compliance requirements and limit liabilities.
A study at a medical practice in Sacramento, California showed moving to a paperless workflow save over $4000 USD per month. When factoring copying, scanning, archiving, routing, and retrieving lost documents, the associated costs of wet signatures are estimated at $6.50 each. The average authorized employee signs 500 documents a year at a total cost of $3,250.
In recent years, most countries worldwide have adopted legislation and regulations that recognize the legality of a digital signature and deem it a binding signature. In addition to governments, many industries have established regulations (e.g., FDA 21 CFR Part 11 in the Life Sciences industry) that define digital signatures as a replacement for handwritten signatures.
Since MaxSignatures is a digital signature solution--the secure form of e-signature--it provides legal compliance in the most tightly regulated industries and geographies. MaxSignatures meets the requirements of the Federal Information Processing Standards Publication (FIPS) FIPS 140-2 Level 3 certified and is based on the Digital Signature Standard (FIPS 186-2). With the proper standard operating procedures in place, MaxSignatures also complies with ESIGN, EU Directives and VAT law, FDA 21CFR part 11, HIPAA and SOX.
LegislationImportant milestones in the acceptance of digital signature solutions took place in 1999 and 2000 respectively, when the EU passed the "EU Directive for Electronic Signatures" and President Clinton signed into law the Electronic Signatures in Global and National Commerce Act ("ESIGN").
Furthermore, legal precedents are being established that confirm the validity of electronic documents and contracts. Following are a few examples:Yes. Standard digital signatures "seal" documents in a way that permits any change to be detected. They provide evidence of user authenticity (verifies the signer’s identity), guarantee data integrity (data has not been altered since the document was signed), ensure non-repudiation of signed digital documents, and comply with regulations and standards such as the HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release standard for CDA.
While both the handwritten and digital signature are legally-binding, only the digital signature ensures non-repudiation of documents. For example, any changes made to an electronically signed document are clearly indicated and will immediately invalidate the signature, thereby protecting against forgery. Nicholas Leeson forged handwritten signatures of his boss and caused the collapse of Barings Bank, the United Kingdom's oldest investment bank. Digital signatures help to guard against this type of risk.