Menu Close

Network Security Compliances

SUMMARY OF COMPLIANCES

The BroadStar Core Network dynamically configures L2 GRE Encrypted tunnels providing Secure Hipaa Hl7, SOX and SAS 70 work at home network access for our customers. This Provides Secure Encrypted SSID network access via two layers of protection, MAC address and a unique WPA2-PSK to each customer location. Please see the diagram below for a visual example of how Network Security Compliance is delivered by BroadStar.

BroadStar Network Security Compliance

What is SAS70 compliance?

SAS 70 OVERVIEW

Statement on Auditing Standards (SAS) No. 70, Service Organizations, was a widely recognized auditing standard developed by the American Institute of Certified Public Accountants (AICPA). A service auditor’s examination performed in accordance with SAS No. 70 (also commonly referred to as a “SAS 70 Audit”) represents that a service organization has been through an in-depth examination of their control objectives and control activities, which often include controls over information technology and related processes. In today’s global economy, service organizations or service providers must demonstrate that they have adequate controls and safeguards when they host or process data belonging to their customers. In addition, the requirements of Section 404 of the Sarbanes-Oxley Act of 2002 make SAS 70 audit reports even more important to the process of reporting on the effectiveness of internal control over financial reporting.

In an audit of a user organization’s financial statements, the user auditor obtains an understanding of the entity’s internal control sufficient to plan the audit as required in SAS No. 55, Consideration of Internal Control in a Financial Statement Audit. Identifying and evaluating relevant controls is generally an important step in the user auditor’s overall approach. If a service organization provides transaction processing, data hosting, IT infrastructure or other data processing services to the user organization, the user auditor may need to gain an understanding of the controls at the service organization in order to properly plan the audit and evaluate control risk.

In 2011, Statement on Standards for Attestation Engagements (SSAE) No. 16 took effect and replaced SAS 70 as the authoritative guidance for performing a service auditor’s examination. SSAE 16 established a new attestation standard (AT 801) to contain the professional guidance. You can learn more about SSAE 16 at www.ssae16.com. At the same time, the AICPA also launched a new Service Organization Controls (SOC) reporting framework designed to allow practitioners to provide different types of reports depending on the needs of service organization and their stakeholders. The AICPA has a web page dedicated to providing more information.

What is SOX (Sarbanes Oxley) compliance?

Overview of Sarbanes Oxley (SOX)

The Sarbanes-Oxley Act of 2002, often simply called SOX or Sarbox, is U.S. law meant to protect investors from fraudulent accounting activities by corporations. Sarbanes-Oxley was enacted after several major accounting scandals in the early 2000’s perpetrated by companies such as Enron, Tyco, and WorldCom. So what is SOX? The law mandates strict reforms to improve financial disclosures from corporations and prevent accounting fraud. It also covers issues such as auditor independence, corporate governance, internal control assessment, and enhanced financial disclosure.

The law is named for the two congressmen who drafted it, Paul Sarbanes and Michael Oxley. The U.S. Securities and Exchange Commission (SEC) administers the act.

Though Sarbanes-Oxley does not call out any specific IT requirements, the law does have a great impact on information systems – and in particular the security of those systems – owed to the fact that the financial information covered under the law is processed and stored by IT systems. Section 404 in particular has had very costly implications for publicly-traded companies as it is expensive to establish, maintain, and validate the required internal controls.

Sarbanes-Oxley not only affects the financial side of corporations, but also IT departments charged with implementing and maintaining the internal controls referenced in Section 404. Companies must document, test, and maintain those controls as well as the procedures for financial reporting to ensure their effectiveness. The impact of section 404 is substantial in that a significant amount of resources are needed for SOX compliance.

Modern financial reporting systems are heavily dependent on technology and associated controls. Any review of internal controls would not be complete without addressing controls around information security. An insecure system would not be considered a source of reliable financial information because of the possibility of unauthorized transactions or manipulation of numbers. Thus, Sections 302 and 404 indirectly force the scrutiny of information security controls for SOX compliance.

The SOX regulation doesn’t specify any particular controls to safeguard financial data; this is left to the discretion of the individual company. However, the Public Company Accounting Oversight Board (PCAOB), which assists in implementation and oversight of SOX, has selected the COSO (Committee of Sponsoring Organizations) framework for the purpose of internal control guidance. Following the COSO framework is not mandatory but simply a way to help companies ensure they have adequate controls.

Sarbanes-Oxley does not specifically call for the use of encryption as a control to protect financial data, but its use is considered a best practice. The SANS Institute identifies encryption as a critical security control in its list of the Top 20 Critical Controls.

According to SANS:

“Data resides in many places. Protection of that data is best achieved through the application of a combination of encryption, integrity protection and data loss prevention techniques. As organizations continue their move towards cloud computing and mobile access, it is important that proper care be taken to limit and report on data exfiltration while also mitigating the effects of data compromise. The adoption of data encryption, both in transit and at rest, provides mitigation against data compromise”.

In practice, many companies under the purview of the SOX act actively engage in data protection through a technology stack that includes encryption, regardless of where the data resides, in order to legitimately attest to the fact that the data has not been tampered with or otherwise compromised. Under the penalty provisions of Sarbanes-Oxley, the stakes are high, and it’s critical for companies to know that their data is as secure as possible.

What is HIPAA HL7 compliance?

HL7 Compliance Overview

HL7 stands for Health Level-7, which is an international set of standards that establishes a network for sharing electronic health records (EHRs) between software platforms in the healthcare sector. HL7 standards are de facto standards in healthcare IT. HL7 was created by Health Level Seven International, which is a non-profit organization that strives to provide a comprehensive framework and standards supporting sharing and retrieval of electronic data. It is used by many large institutions in over 55 countries, which agreed upon a standard format for all types of patient data exchange. HL7 was accredited by the American National Standards Institute (ANSI) in 1994 to govern the healthcare system stakeholders and vendors’ standards developed. Health level 7 standards supply formats and frameworks for promoting data exchange in clinical settings.

There are four main HL7 standards: HL7 version 2, version 3 CDA, EHR-PHR, and FHIR.

Four versions of HL7

  • HL7 Version 2 (V2) is the most commonly used messaging standard for the exchange of electronic health records. It is a database query language that helps healthcare providers to send messages asking for and storing patient data.
  • HL7 version 3 (V3) is also emerging and it varies significantly from V2.
  • CDA (Clinical Document Architecture) is an ISO-approved standard creating an exchange model for clinical documents such as discharge summaries and progress notes. CCD and consolidated CDA (C-CDA) are associated with CDA. CCD consists of a record of patient discharge and admission in different facilities. On the other hand, C-CDA is applicable in certified EHRs for consolidating CDA templates into a single document.
  • The EHR-PHR System Functional Models supply standard language parameters used for creating EHR systems and their components.
    Fast Health Interoperability Resources (FHIR) is a Web-based data exchange language that speeds interoperable healthcare applications and makes them simpler and easier.

HL7 represents the seven-layer International Standards Organization (ISO) Communications Model:

  1. It connects the entity to online transmission media
  2. Provides error control between adjacent nodes
  3. Moves data across a network
  4. Provides communication control for the end-users
  5. Tackles other problems apart from communication issues
  6. Converts data into a form that users can interpret
  7. Offers a variety of services to the applications

Why was HL7 developed in the first place?

Past challenges: In the past, data interchange across different healthcare systems took place through customized interfacing systems. These interfaces needed a lot of programming at the sending and receiving applications, which complicated the process. The difficulty with interfaces arises when healthcare teams and software vendors develop new applications. Each of these applications is created with no input or collaboration with other application systems.

The innovation of HL7: Some clinical interface specialists in the healthcare industry decided to invent a better and cost-effective approach for interface applications. Few acute care hospitals and software vendors came together as a volunteer group to innovate a standard way of building interfaces. Their goal was to reduce the price of building interfaces substantially. This is how HL7 came into existence.

Objective of HL7

The main purpose of creating HL7 was to simplify the implementation of interfaces involved between healthcare software applications and various vendors. Doing so would decrease the cumbersomeness and expenditure towards custom interface programming that would support compatible applications. The focus was on making it adaptable to allow simpler data exchange and significantly reduce the costs. Implementing HL7 resolved 80% of the clinical interfacing problem flexibly.

HL7 Integration

A healthcare communications company utilized HL7 integration to obtain inputs from various hospital systems. The data included the EHR, patient care devices, laboratory, radiology, nurse call systems, and much more. This information was communicated to the healthcare teams through various mobile devices, such as smartphones and tablets.

What is the role of HL7 in the healthcare sector?

Healthcare professionals often need to go through multiple electronic data systems for correctly diagnosing patients. This process can become more difficult if the healthcare providers offer services in outpatient clinics separate from the local hospital system. FHIR and HL7 interoperability standards, including HL V2 make things easier for clinicians. These standards provide a common language for handling and sharing patient data across EHRs without risk of misinterpretation or duplication.

What are the Benefits of HL7 implementation?

Besides helping you optimize EHR systems and make them cost-effective, HL7 offers many advantages:

  • Creates a single, flexible, worldwide standard for the movement of clinical data.
  • Allows easy sharing of complex and private patient data, including records, lab reports, test results, etc., through clinical applications.
  • Smoothens the process of electronic data exchange so that the end-uses can interpret the data.
  • Makes integrated healthcare solutions possible, thus improving the care services delivered by healthcare networks.
  • HL7 standards are healthcare-specific formatted messages that support different healthcare system integrations and interoperability.
  • These standards allow EHRs to communicate with many systems operating outside the EHR.