Blog

It may come as a bit of a surprise—maybe not—but there are actually two types of SOC reports. Upon examination, the service organization is responsible for specifying whether or not a “Type 1” or “Type 2” will be performed. It’s important to note the specific use of “Type” as a distinguisher--not “SOC 1” or “SOC 2,” as the different specified “types” are options for both the SOC 1 and SOC 2 reports. For those of you that are now thinking, “that’s confusing,” I agree 100% with you. In fact, “Type 2” and “SOC 2” are not at all the same thing, and the “type” of each SOC examination presents important differences for service organizations.

When you think of a data breach, what comes to mind? It’s probably the image of a hacker stealing data from a large business or company that stores an abundance of customer data—like Target, for instance. Data breaches are expanding from companies and healthcare organizations and are also becoming a real concern for law firms.

Surprisingly, business leaders—not IT departments—are the driving force behind six out of 10 migrations to the cloud. These leaders are often bothered by the nagging question, “Is the cloud secure?” This question is usually followed by a series of debates about just how secure the cloud is.

Despite years of preparation and billions of dollars in spending, today’s businesses still aren’t prepared for cyber-attacks. Just turn on the evening news and you’ll be greeted with the name of the latest company to suffer an attack.

NOTE:  Schellman recently updated this content to be more in-depth and address how an organization may choose its report type. You can find that information here.  There are two types of SOC 1 reports. The service organization is responsible for specifying whether or not a “Type 1” or “Type 2” will be performed.

Imagine, for a moment, that you are sick and require a major operation. Among the many thoughts that would immediately cross your mind would be the need to find “the best” doctor available. What criteria would you use when selecting the best doctor? I bet that the following attributes would weigh heavily in your decision:

On Monday, we posted an article announcing that the DEA had issued new regulations for “Electronic Prescriptions of Controlled Substances.” Since then we have further reviewed the ruling and also spoken with many clients and prospects that have contacted us on the subject. The following points provide additional context and background for any service provider (ASP, SaaS, etc) that provides an application for generating and fulfilling prescriptions of controlled substances. The primary goals of ruling are to 1) maintain a protected “closed system” for prescription fulfillment 2) reduce the risk prescription forgery and diversion and 3) promote the use of Electronic Health Records (EHR) building on the incentives and goals outlined in the Health Information Technology for Economic and Clinical Health (or HITECH) Act components within the American Recovery and Reinvestment Act of 2009 (a.k.a. the Recovery Act). Controlled substances make up approximately 10% of all prescriptions. That said, the classifications of controlled substances approved for medical use (schedules II through V) are carried by most major pharmacies. The control requirements, highlighted below, as well as the third-party audit requirements are focused on electronic prescription applications, which can be installed on a standalone basis or hosted by an Application Service Provider (ASP). A medical provider (i.e. doctor) or pharmacy is not required to undergo a third-party audit unless it develops the e-Prescriptions software itself. It is also worth noting that requirements for identity management and access control not only aim to protect access to data but to restrict who can generate, approve, and fulfill a prescription thus reducing the risk of unauthorized fulfillment of controlled substances (referred to as diversion). e-Prescription technologies have been available for some time and there are standards for the communication of prescription data between a medical provider and a pharmacy. For instance the SCRIPT standard (currently in version 10 release 6) specifies the data field requirements such that the data can be shared across different applications. The DEA clearly noted that it has “not been able to identify any organization that sets standards for or certifies pharmacy applications for security issues.”

With the medical industry quickly moving towards electronic records and transactions, why wouldn’t pharmacies do the same?