MIRAssist FAQ

Frequently Asked Questions Regarding Data Recovery

What is MIRAssist?

MIRAssist is a fully managed medical backup solution that automatically stores local and offsite backups of patient studies, EMR records and other important configuration information from your servers and workstations. MIRAssist will configure, monitor and maintain all backup sets to ensure that all patient data is properly backed up without errors.

Why do I need MIRAssist?

In accordance with HIPAA requirements: 164.312(a)(2)(ii), 164.312(c)(1), doctors must institute a mechanism to ensure the accessibility and integrity of all electronic patient information in the event of an emergency. An emergency is defined as a natural disaster, system failure, etc. MIRAssist provides protection in the event of hard drive failure, operating system (OS) failure or data corruption. Downtime can be minimized with the MIRAssist Bridge network restore in under 30 minutes.

Am I only limited to health records?

Absolutely not, though MIRAssist was established for Patient Medical Records from EMR, PACS and Acquisition Stations. We do have facilities that also use the service for the doctors’ laptops and/or workstations (both at the office and for remote locations) for their business operations.

How many servers or computers can be utilized under MIRAssist?

MIRAssist is based on the amount of annual data and licenses per device (server, computer, etc.).
You may purchase any number of individual licenses for each device and simply build a plan to accommodate the combined amount of data from all devices.

Can I use Carbonite or Amazon type SLA companies for backing up my patient medical records?

In short, yes. However, the responsibility rests with you for managing the platform, any lost data and rebuilding your solution in case of a disaster.

Services rendered under an SLA (Service Level Agreement) are not comparable to MIRAssist. Below are a few points of comparison:

  • SLAs may not be HIPAA Compliant. A user may need to utilize the business level package. This is due to the fact the data is recoverable without a private encryption key and password. This violates HIPAA with regards to maintaining the integrity and security of patient data. With this established, we can now compare the SLA Business package to Datalink.

  • SLA business does offer a valet installation of their product, as does MIRAssist. However, an SLA does not offer the configuration of backup sets needed to properly restore the system. This setup of the backup jobs and schedule is the sole responsibility of the end user.

  • There is no maintenance or monitoring of backup jobs completed with an SLA. This is also the sole responsibility of the end user. All the MIRAssist subscribers are fully managed under notifications – Green (In full and Proper Operation), Yellow (Possible underlying issues to be resolved, reaching threshold, etc.) and Red (Down network, failed backup, etc.)

  • Make sure that there is NO hidden service fee to have your data exported by an SLA for a “staged restore”.  Same with a ‘staged import”. Note that the only fee from MIRAssist in this type of situation is the storage media, i.e. external USB hard drive. There is no storage fee for staged import, just shipping.

  • SLAs may have the ability to backup databases, but it is an additional charge and the maintenance and setup is passed on to the end user. This is critical to a successful restore of Medlink products because all the software is built around databases.

  • SLAs may provide remote assistance with restores as far as using their software. They cannot support the overall solution and ensure all components are functioning properly.

    There are other little differences but the bottom line is our product is more than software and storage. It is a complete turnkey solution. MIRAssist takes away all the guesswork and day-to-day operations of the backup plan. It is a tested and proven solution accompanying the Medlink digital solution offerings.

    Furthermore, MIRAssist is the supported Medlink solution for combating system failures, data loss and OS issues for Medlink digital solutions. The use of any other third party product is to be considered outside of the standard support agreement. Any assistance in setup, validation or restoring with anything other than MIRAssist will be a billable service.

Questions? Call us!

Note: It is always recommended to utilize our MIRAssist Bridge device.

What are the HIPAA Technical Safeguards?

The Security Rule defines technical safeguards in § 164.304 as “the technology and the policy and procedures for its use that protect electronic protected health information and control access to it.”

The Security Rule defines access in § 164.304 as “the ability or the means necessary to read,
write, modify, or communicate data/information or otherwise use any system resource. (This
definition applies to “access” as used in this subpart, not as used in subpart E of this part [the
HIPAA Privacy Rule]).”

ACCESS CONTROLS § 164.312(a)(1)

  1. EMERGENCY ACCESS PROCEDURE (R) – § 164.312(a)(2)(ii)
    “Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.”
    These procedures are documented instructions and operational practices for obtaining access to necessary EPHI during an emergency situation. Access controls are necessary under emergency conditions, although they may be very different from those used in normal operational circumstances.
    Procedures must be established beforehand to instruct workforce members on possible ways to gain access to needed EPHI in, for example, a situation in which normal environmental systems (such as electrical power) have been severely damaged or rendered inoperative due to a natural or man-made disaster.
  2. ENCRYPTION AND DECRYPTION (A) – § 164.312(a)(2)(iv)
    “Implement a mechanism to encrypt and decrypt electronic protected health information.”
    There are many different encryption methods and technologies to protect data from being accessed and viewed by unauthorized users.
    AUDIT CONTROLS § 164.312(b)
    The next standard in the Technical Safeguards section is Audit Controls. This standard has no
    implementation specifications. The Audit Controls standard requires a covered entity to:
    “Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.”
    INTEGRITY § 164.312(c)(1)
    The next standard in the Technical Safeguards section is Integrity. Integrity is defined in the
    Security Rule, at § 164.304, as “the property that data or information have not been altered or
    destroyed in an unauthorized manner.” Protecting the integrity of EPHI is a primary goal of the
    Security Rule.
    The Integrity standard requires a covered entity to:
    “Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.”
    Workforce members or business associates may make accidental or intentional changes that improperly alter or destroy EPHI. Data can also be altered or destroyed without human intervention, such as by electronic media errors or failures. The purpose of this standard is to establish and implement policies and procedures for protecting EPHI from being compromised regardless of the source.
  3. MECHANISM TO AUTHENTICATE ELECTRONIC PROTECTED HEALTH
    INFORMATION (A) – § 164.312(c)(2)
    Where this implementation specification is a reasonable and appropriate safeguard for a
    covered entity, the covered entity must:
    “Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.”
    TRANSMISSION SECURITY § 164.312(e)(1)
    The final standard listed in the Technical Safeguards section is Transmission Security. This
    standard requires a covered entity to:
    “Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.”
  4. INTEGRITY CONTROLS (A) – § 164.312(e)(2)(i)
    Where this implementation specification is a reasonable and appropriate safeguard for a covered entity, the covered entity must:
    “Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.”
  5. ENCRYPTION (A) – § 164.312(e)(2)(ii)
    Where this implementation specification is a reasonable and appropriate safeguard for a
    covered entity, the covered entity must:
    “Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.”