AB 133 Medical Data Security in California: What Every Provider Must Know Now

21 August 2026

AB 133 Medical Data Security in California

California healthcare providers are being pressured to demonstrate that they are not just claiming that the data of patients is secured at every point it is transferred, stored or accessible. AB 133 security of medical data requirements are at the heart of that pressure. They provide the most basic administrative and technical safeguards that the California provider or medical organization or health data provider should have in place and carry serious consequences for companies that view the protection of patient data as an afterthought. If your business is relying on a fragmented system and manual audit logs or an "we've never had a data breach" presumption, AB 133 Medical Data Security in California conformity is a gap you'll need to fill first, prior to a regulator or a breach can close it.

This guide explains exactly how AB 133 Medical Data Security in California obligations entail and who they are applicable to and how they are compared to the baseline HIPAA security measures, and how a California based HITRUST R2 certified partner such as Long Health helps practices meet the requirements without increasing staff.

WhatIs AB 133 Medical Data Security?

AB 133 security for medical information in California refers to the list of obligations for data protection that California healthcare organizations must comply with when they collect, save or transmit data about patient health across systems. In simple terms, it demands that all entities handling patients' data use auditable encryption (in the process and at rest) as well as documented access control dependent on the identity of each user Continuous audit logging and a documented incident response process and not just guidelines that can only be found in paper. This standard is intended to bridge that gap in between what organizations claim they are doing to safeguard data, and what they are able to prove in the course of an audit or following an incident.

For the majority of California practice, the consequence on AB 133 Medical Data Security in California compliance is simple: every device that interacts with patients' records such as your EHR as well as your data exchange partner as well as your scribing tool your record summarization vendor must adhere to the same standards since the compliance chain is only as robust as the weakest link in its system.

WhoMust Comply With AB 133 Medical Data Security in California

Practices and Organizations in Scope

AB 133's medical data security obligations extend far beyond the boundaries of a single hospital system. In scope organizations usually include independently owned practices, multisite medical organizations and Independent Physician Associations (IPAs) as well as personal injury and workers' comp evaluation practices, as well as any third party company that processes the patient's data on a covered entity's behalf including AI software for scribing as well as record summarization platforms and intermediaries in data exchange. If your practice has information with an IPA or special network, or state connected exchange and you are a member of one, your AB 133 security for medical data protection extends to each of these connection points and not just the four walls.

Deadlines and Penalties for Non Compliance

California has been squeezing the timelines for enforcement of the protection of health information in line with the state's overall Data Exchange Framework (DxF) implementation under CalHHS. Practices that don't meet AB 133 Medical Data Security in California requirements are subject to a range of penalties: regulatory as well as breach notification obligations, which carry the associated reporting costs as well as the loss of eligibility to participate in state wide data sharing agreements and, often the most harmful in practice the reputational and operational consequences of a data breach that could have been avoided. Since the deadlines for compliance and enforcement are constantly changing, practices should confirm the current dates directly with CalHHS instead of relying upon the static timetable.

AB133 Medical Data Security vs. Standard HIPAA Compliance

HIPAA defines the federal floor. AB 133 security for medical information obligations layer California specific standards on top of the federal floor, particularly in relation to verified, auditable controls as opposed to self tested ones. The table below highlights the actual distinctions.

Requirement AreaBaseline HIPAAAB 133 Medical Data Security in California
Encryption"Addressable" is must be used unless a substitute alternative is establishedAs a default control, both during transit and in rest in all connected systems
Access ControlsAccess to information based on roles is suggestedAccess controls for each user at the individual level with audit ready identity logs
Audit TrailsRequired, usually reviewed only following an incidentContinuous, verified, and continuous logging will be able to be demonstrated upon request
Third-Party VendorsBusiness Associate Agreements (BAAs) must be signedBAAs, as well as concrete proof that vendor systems are in compliance with the same California security standards for data
State Data ExchangeNot mentionedIt is tied to the CalHHS DxF participation as well as QHIO-mediated exchange expectation

How AB 133 Medical Data Security in California Actually Works in Practice

Encryption,Access Controls, and Audit Trails

Achieving AB 133 security for medical data standards isn't just a single item to purchase. It's an entire chain of control which must be held each link. The data is secured both when it's being transferred across different systems (in transit) and also while it's in storage (at at rest) thus an unintentional data transmission or compromised drive won't reveal sensitive patient data. Access controls are linked to individuals' credentials and not shared logins, which means that each record edit, view or export can be traced to a particular person. Audit trails track this activity over time and a system can determine precisely who touched the record, and at what time it is the difference between legally enforceable security posture and guesswork.

WhereData Exchange (DxF/QHIO) Fits Into AB 133 Compliance

Since California is simultaneously introducing the CalHHS Data Exchange Framework, the majority of practices will have to address AB 133 security of medical information within California in addition to DxF participation in conjunction rather than as distinct projects. The Qualified Health Information Organization (QHIO) serves as the secure channel for this exchange. Instead of establishing point to point connections to each laboratory, hospital, and other specialist systems it uses in the first place, an QHIO such as Long Health maintains a single certified, HITRUST r2 certified connection to Carequality. Carequality network, using direct messaging as a backup for any records that are not on the Carequality network. This single point of connection is also the place where AB 133 security for medical data controls such as encryption, access logs and identity based permissions are consistently enforced instead of being re implemented by each system that the practice interacts with.

CommonMyths About AB 133 Medical Data Security in California

Myth 1 "AB 133 security of medical information is only applicable for hospitals." In actuality, the obligation extends to independent practices and IPAs, medical legal evaluators as well as any other vendor that processes the patient's data on a healthcare provider's behalf. The scope of the obligations is determined by how data is handled, not size.

Myth 2 "We're HIPAA compliant, so we're covered automatically." HIPAA compliance is essential but it's not enough AB 133 is a medical data security requirement for the auditing process, which is continuous and reliable and access based on identity go well beyond the HIPAA's standard "addressable" terms.

Myth 3: "Connecting to an exchange of state data means the surrender of control over the patient's data." Participating in DxF/QHIO's exchange does not transfer ownership over practices' data; it standardized the way that information flows securely between authorized parties with the practice's access and consent rules controlling who is able to see what data.

How to Evaluate an AB 133 Medical Data Security California Vendor

Do they have the current HITRUST the r2 certification, not just an HIPAA self attestation?

  • Is your data secure both while in transit and when it is at rest, as a default across all connected systems?
  • Can the vendor provide individual level access logs that are audit ready upon request and not only after an incident?

Is the company connected to an immediate Carequality network connection? an alternative for gaps in records not on the network?

The vendor will aid in CalHHS Data Sharing Agreement signing and DxF participation, and not simply make a stand alone tool available?

Does the company's AB 133 medical data security policy extend to all sub systems it utilizes, or just to its own platform?

CaseExample: A California IPA's Path to AB 133 Compliance

A mid-sized, independent physician association located in Southern California was operating across three disjointed EHR systems that had been acquired from a string practices acquired. The patient records were moved between members' practices through email and fax attachments they were not encrypted when stored on the devices receiving them nor were they logged in a central, auditable manner. The moment the IPA began to prepare for its CalHHS DxF deadline for participation its compliance manager discovered that the IPA did not have a way to demonstrate AB 133 security for medical information compliance at these connecting points, and just within the EHRs of each individual.

The IPA linked its member practices using one QHIO mediated exchange layer instead of having separate point to point integrations. Records that previously moved by fax began routing through an encrypted, Carequality connected pathway with centralized, identity based access logging. The usual outcome for organizations who make this change is an auditable, single record for every member practice, instead of three separate ones, which significantly reduced the administrative time spent on manually recording record requests, and an acceptable AB 133 Medical Data Security in California situation that the compliance officer will be able to present upon request instead of reconstructing after the actual.

How Long Health Supports AB 133 Medical Data Security Compliance

Long Health is a California based Qualified Health Information Organization (QHIO) and Carequality implementer built around the state's CalHHS Data Exchange Framework it is not a national system that has been modified to meet California requirements. It is important in terms of AB 133 Medical Data Security in California compliance since the base infrastructure is HITRUST certified r2 and HIPAA conforming through design, with encryption in the transit phase and also at rest for each connected practice.

The core products of Long Health are directly mapped onto the areas of a practice's information environment that are most vulnerable under AB 133 Medical Data Security in California rules:

  • DxF and QHIO Secure healthcare data exchange that is compliant in the California Data Exchange Framework, with the direct Carequality network connection as well as direct messaging fallback to record gaps.
  • AI Scribe real time transcription of medical conversations in organized SOAP notes, based on the same secure infrastructure as the other non audited, untested software.
  • Summarization of Medical Recordsan AI driven extraction of the most important information from complex or lengthy patient histories without leaving a safe environment.
  • EvalPath is an AI platform specifically designed to assist in medical legal assessments, from the review of records through impairment rating services to doctor ready reports, which are for QMEs, AMEs and personal injury/workers' compensation practices.
  • EHR Data Migration Integration / Migration consolidating patient data across systems to a healthcare provider's EHR without the security risks caused by ad hoc transfers of files.

Long Health is also a participant in NVIDIA Inception and supports California practices directly in CalHHS Data Sharing Agreement signing and DxF grant applications/practices must confirm the current deadlines and grant amounts directly with CalHHS since they update them regularly.

Frequently Asked Questions

What is AB 133 Medical Data Security in California needed physician practice?

It must be verified as encrypted during transit and in rest, individualized identity based access security controls that are continuously audited logs and documented incident response protocols for every system that interacts with patient information not only the core EHR.

Does AB 133 Medical Data Security in California apply to independent small practices?

Yes. Scope is determined by the degree to which a company is able to collect, store or send out health information, not the size of the practice smaller practices, IPAs and medical legal evaluators all fall included in the range.

What makes AB 133 medical data security different from HIPAA?

HIPAA provides a standard for federal use with a few "addressable" security measures; AB 133 Medical Data Security in California requires verifiable and continuous evidence based controls, especially around encryption defaults and auditable access logs.

How can connecting to QHIO QHIO assist with AB 133 medical data security conformity?

A QHIO similar to Long Health provides a single exchange point that is HITRUST r2 certified rather than a multitude of unmanaged point to point connections. This makes security, encryption and audit logs consistent and centrally verified.

What is the consequence of what happens if the California practice fails to meet AB 133 medical data security specifications?

The consequences of exposure include regulatory penalties, breach notification obligations, the possibility of losing of state agreements on data sharing, as well as the operational costs associated with the response to a data breach.

Does Long Health help with both AB 133 medical data security and DxF/QHIO security at the same time?

Yes, as Long Health's technology is based on California's Framework, DxF participation, QHIO connectivity, and AB133 medical data security measures are all handled through the same infrastructure, not being separate projects.

KeyTakeaways

  • AB 133, the medical data security law in California requires verifiable encryption access controls based on identity and continuous audit logging not a self assailable policy.
  • The scope of the program extends beyond hospitals, to independent practices and IPAs, medical legal evaluators and any other vendor who has access to patients' information.
  • Requirements exceed the HIPAA's base requirements, focusing on the default encryption, and auditable access.
  • AB compliance with 133 and CalHHS DxF/QHIO compliance should be dealt with together via one connected infrastructure.

Evaluation of the vendor must verify HITRUST R2 certification, audit log security, encryption defaults and direct Carequality connectivity.

  • Long Health is a California based QHIO certified by HITRUST which supports AB Medical security for data across data exchange AI Scribe, record summary, EvalPath, and EHR migration.

Conclusion and Next Step

AB 133 security for medical information in California is no longer a future requirement; practices are able to defer it; it's a current compliance requirement that is tied to the way the patient's data is transferred through each system that a practice uses. Practices that tackle it with individual, ad hoc fixes often end up re-building the same security controls over each new system. Practices who address it with one, HITRUST certified exchange layer will have a consistent and auditable position beginning from the first day.

Speak to us about the onboarding process for DxF/QHIO, CalHHS Data Sharing Agreement assistance, and areas where your current systems might not be up to the task.