您的公司是否已成為HIPAA業務夥伴？

A Taiwan medtech manufacturer wins a US hospital contract for an AI-enabled diagnostic scanner. The US procurement team sends over a Business Associate Agreement as a standard step in vendor onboarding. Legal reviews it, doesn't flag major concerns, and signs it. Six months later, the hospital's compliance team sends an audit questionnaire. The manufacturer realises, for the first time, that it has been operating as a HIPAA Business Associate with obligations it has never built for — obligations that have been running since the day the BAA was signed.

This is not an unusual scenario. It is becoming more common as Taiwan's medtech manufacturers move from hardware-only products to cloud-connected devices with AI capabilities — a transition that quietly moves companies from the periphery of HIPAA's scope to its centre. And as the use of patient data to train AI models becomes a commercial priority for device manufacturers, the compliance exposure is not just expanding. It is changing in character.

Section 1 — Are You Actually a Business Associate?

The question sounds simple. The answer depends on your device architecture — and the architecture that was common among Taiwan medtech manufacturers five years ago is not the architecture being built today.

Under HIPAA, a Business Associate is any person or entity that creates, receives, maintains, or transmits protected health information (PHI) on behalf of a covered entity — which includes hospitals, health systems, clinics, and health insurers. The test is not whether you control the data. It is whether you handle it. A manufacturer who never sees a patient's name but whose cloud backend processes diagnostic images that can be linked to an identifiable individual is handling PHI. The fact that the hospital owns the data is irrelevant to Business Associate status.

The device architecture spectrum looks like this:

The transition from service/support access to cloud backend is the critical shift — and it is one that has happened incrementally in many organisations without a corresponding update to their HIPAA compliance posture. A company that signed a BAA three years ago for remote support access and has since launched a cloud analytics platform for its device is now operating under a fundamentally different obligation profile. The BAA signed three years ago almost certainly does not cover the current architecture. The compliance programme built for narrow support access is not adequate for a cloud backend handling diagnostic imaging data.

The other category worth flagging is Software as a Medical Device (SaMD). If the software component of your device — firmware, embedded application, or cloud-based analytical module — performs diagnostic analysis rather than merely capturing and transmitting data, the software itself is a medical device under FDA classification and the analytical function is almost certainly processing PHI on behalf of the hospital. The manufacturer of an AI-enabled scanner that identifies disease symptoms from images is not a passive conduit. The software is doing clinical work with patient data. Business Associate status follows directly.

Section 2 — What the BAA Actually Obligates You to Do

A Business Associate Agreement is a contract. It is also a compliance instrument that incorporates HIPAA's substantive requirements by reference — which means signing it without understanding those requirements is signing obligations you may not be able to meet.

The clauses that matter most to a manufacturer:

This is the clause that defines what you are allowed to do with PHI. Standard BAA language limits permitted uses to performing the contracted services — operating the device, providing support, returning results to the covered entity. Uses beyond that scope — including using PHI to train AI models, to develop new products, or to improve services provided to other customers — require explicit authorisation in the BAA. If the permitted use clause does not cover your intended use, the use is impermissible under both the BAA and the HIPAA Privacy Rule.

The BAA requires you to implement administrative, physical, and technical safeguards appropriate to the PHI you handle. This is a reference to the HIPAA Security Rule, which specifies required and addressable safeguard categories. In practice, for a manufacturer operating a cloud backend, this means: access controls, audit logging, encryption at rest and in transit, workforce training, incident response procedures, and a written security programme. It does not mean you need to replicate a hospital's entire compliance infrastructure — but it does mean you need a programme, not an aspiration.

If a breach of PHI occurs, you must notify the covered entity without unreasonable delay and no later than 60 days after discovery. Discovery is defined as the date on which you knew, or by exercising reasonable diligence would have known, of the breach. The 60-day clock runs from discovery — not from the date of the breach itself, and not from the date you complete your investigation. For a manufacturer with no defined breach detection or escalation process, the clock can be running for weeks before anyone internally recognises that a notifiable event has occurred.

Any subcontractor that creates, receives, maintains, or transmits PHI on your behalf must also sign a BAA with you. This obligation flows down the supply chain. Your cloud infrastructure provider — AWS, Microsoft Azure, Google Cloud — is a subcontractor Business Associate if your workloads process PHI. All three offer HIPAA-eligible service agreements and BAA templates, but you are required to execute them. Your analytics vendor, your data labelling provider, your offshore engineering team with production system access — each of these is a potential subcontractor Business Associate that requires a BAA. Most Taiwan manufacturers operating cloud backends have executed none of these agreements, or one of them, but not all.

The covered entity has the right to audit your HIPAA compliance. Standard BAA audit clauses can be very broad — granting on-site access, requiring production of records and documentation, and imposing no meaningful limitation on scope or timing. These clauses are negotiable. Most Asian manufacturers sign them without negotiation and without considering what a compliance audit would actually require them to produce.

If you materially breach the BAA, the covered entity can terminate the agreement and require the return or destruction of all PHI. For a manufacturer whose product depends on continued data access, the termination clause is an existential risk that deserves careful attention during negotiation.

Section 3 — What OCR Enforcement Against Business Associates Looks Like

A common assumption among Asian manufacturers is that HIPAA enforcement is primarily a US healthcare provider problem — that the Office for Civil Rights (OCR), the HHS division responsible for HIPAA enforcement, focuses its attention on hospitals and health systems rather than technology vendors and Business Associates. That assumption is increasingly inaccurate.

OCR has received over 374,000 HIPAA complaints since 2003 and has pursued enforcement against Business Associates in cases involving exactly the violations most relevant to a medtech manufacturer: inadequate security risk analysis, unsecured servers, and failure to execute BAAs with subcontractors. Two cases from 2023 illustrate the pattern clearly.

The broader enforcement picture reinforces the point. OCR confirmed 22 enforcement actions in 2024 — one of its busiest years — with civil monetary penalties and settlements totalling over USD 9.4 million. The most frequently cited violation across all 2024 enforcement actions was an inadequate risk analysis, which appeared in 13 of the 20 announced matters. OCR has also launched a dedicated Risk Analysis Initiative, signalling that this will remain a priority area. For a manufacturer that has signed a BAA, operates a cloud backend, and has not conducted a formal HIPAA security risk analysis — the enforcement record is a direct read of their exposure.

One further point worth noting: a corrective action plan accompanies every settlement. That means two years of OCR monitoring, mandatory policy development, workforce training, and documented remediation — at the manufacturer's cost and on the manufacturer's time, while the US business relationship continues to depend on demonstrated compliance.

Section 4 — The AI Training Problem

The moment a manufacturer's engineering team proposes using device data to train AI models, three distinct problems arise simultaneously. Most organisations encounter all three and resolve none of them before the training pipeline is built.

A standard BAA authorises the Business Associate to use PHI for the purpose of performing the contracted service. Training an AI model is not performing the contracted service — it is building a commercial capability. Training a model that will improve diagnostic accuracy across all of the manufacturer's customers is creating value for the manufacturer's business, not delivering the contracted service to a specific hospital. Under a standard permitted use clause, this use of PHI is impermissible.

The HIPAA Privacy Rule contains a narrow carve-out allowing Business Associates to use PHI to improve healthcare operations for the covered entity from whom the data was obtained. This carve-out does not extend to improving a commercial product deployed to other customers. The line between "improving the service for this hospital" and "building a commercial AI capability" is precisely where regulators and plaintiff's attorneys are focusing attention in the US healthcare market.

A manufacturer that intends to use device data for AI training needs to negotiate that use into the BAA explicitly — with the hospital's informed agreement, a defined scope of permitted use, and appropriate patient protections. Some US health systems are beginning to approach this as a data licensing negotiation alongside the standard vendor contracting process. A manufacturer that has not had this conversation with its hospital customers and is running an AI training pipeline anyway is operating outside its BAA.

The most common response to the AI training question is: "the data has been de-identified." In the organisations where this response is given, it typically means that an engineering team ran an anonymisation script — removing names, dates of birth, medical record numbers, and other obvious identifiers — and the resulting dataset was treated as no longer subject to HIPAA.

This response conflates technical anonymisation with HIPAA's legal de-identification standard, and the gap between the two is where the liability lives.

HIPAA provides two methods for achieving legally recognised de-identification. The first is the Safe Harbor method, which requires the removal of 18 specifically enumerated identifiers including names, geographic data smaller than a state, dates more specific than year for individuals over 89, phone numbers, device identifiers, and others. The second is Expert Determination, which requires a qualified statistician to analyse the dataset and certify that the risk of identifying any individual is very small.

For medical imaging data — the primary data type in a disease-identification scanner — both methods are harder to satisfy than most engineering teams realise. DICOM files, the standard format for medical imaging, contain metadata headers that routinely carry patient identifiers beyond the obvious fields. Stripping the visible identifiers while leaving DICOM headers intact does not satisfy the Safe Harbor method. A properly de-identified DICOM file requires a purpose-built de-identification process that addresses the full metadata structure, not a general anonymisation script applied to the image itself.

Rare disease cohorts present a different problem. A scanner used to identify a condition that affects a small percentage of the population generates a dataset in which each record is, by its nature, a data point about a rare clinical presentation. Even with all 18 Safe Harbor identifiers removed, the combination of clinical features, anatomical measurements, and imaging characteristics in a small cohort may be sufficient to re-identify individuals — particularly in geographically concentrated patient populations. Expert Determination is designed precisely for this scenario. "We removed the names" is not.

Longitudinal data compounds this further. A device used on the same patient population over multiple visits generates a sequence of records that are collectively far more re-identifiable than any single record. An AI training dataset built from longitudinal imaging data is a different de-identification problem from a one-time cross-sectional dataset, and requires a different level of analysis to certify.

Finally, the trained model itself is a potential disclosure risk. Membership inference attacks — techniques that can determine, with meaningful probability, whether a specific individual's data was used in training a model — are an established area of machine learning security research and an emerging regulatory concern. De-identifying the training data does not eliminate this risk. A model trained on a small, distinctive dataset can encode individual-level information in its weights in ways that can be extracted by a sophisticated adversary.

For manufacturers seeking FDA clearance for AI-enabled SaMD, the provenance and handling of training data is becoming a due diligence question in the regulatory review process. FDA's evolving framework for AI/ML-based Software as a Medical Device requires manufacturers to document the data used to train and validate algorithms, demonstrate that training data is representative of the intended use population, and in some cases submit a Predetermined Change Control Plan that addresses how the algorithm will be updated as new data becomes available. A training dataset assembled from PHI obtained under a BAA that does not authorise training use, or from data whose de-identification is not adequately documented, creates regulatory exposure that extends beyond HIPAA into the product approval process.

Section 5 — The Three Gaps Manufacturers Haven't Built

A manufacturer that has signed a BAA and is operating a cloud backend has legal obligations that are running continuously. Most Taiwan manufacturers in this position have not built the operational infrastructure to meet those obligations. The gaps cluster in three areas.

Section 6 — The BAA Negotiation You Didn't Know You Could Have

US hospitals send standard BAA templates as a routine step in vendor onboarding. The templates are drafted to protect the hospital. They are not drafted with the manufacturer's operational reality in mind. And they are negotiable — a fact that most Asian manufacturers do not realise, because the BAA arrives attached to a commercial contract and the implicit message is that both documents are take-it-or-leave-it.

They are not. A BAA is a contract. The terms that matter most for a manufacturer operating a cloud backend with AI capabilities:

If you intend to use device data for AI model training, this use must be explicitly included in the permitted use clause before the training pipeline is built. Negotiating a permitted use for AI training requires defining the scope — what data, in what form, for what purpose, subject to what patient protections. This conversation is uncomfortable to initiate with a hospital customer. It is far less uncomfortable than disclosing, after the fact, that you have been using patient data for purposes not covered by your BAA.

Negotiating reasonable notice periods — typically 30 days for planned audits — scope limitations, and procedures for handling confidential business information during an audit is standard commercial practice. It is not obstructing compliance. It is ensuring that an audit, if it occurs, is conducted in a way that is workable for both parties.

The BAA should specify the internal escalation procedure, the format of breach notification, and the contact persons on both sides. Standard templates often leave these details undefined, which creates confusion in the event of an actual incident. A well-negotiated BAA converts the statutory 60-day ceiling into a practical protocol that both parties understand before an incident occurs.

When the relationship ends, what happens to the PHI in your cloud backend? What happens to models trained on that data? Standard termination clauses require return or certified destruction of PHI — but models trained on that data occupy a legal grey zone that is not addressed in most standard BAA templates. If your AI capability depends on models trained on a specific hospital's patient data, the termination clause is a question you need to have answered before you sign.

The right time to negotiate a BAA is before signing. After an incident, after an audit, or after a compliance dispute, the leverage and the goodwill required for productive negotiation are both significantly diminished.

Section 7 — Where to Start

For most Taiwan medtech manufacturers reading this article, the immediate priority is not building a comprehensive HIPAA compliance programme from scratch. It is answering three questions honestly — and then deciding what to do about the answers.

These three questions are the starting point. The answers will define the scope of what needs to be built — and the sequence in which to build it. The manufacturer with a well-matched BAA, a clear PHI data map, and a tested breach protocol is in a fundamentally different position from the one that signed a support-access BAA five years ago and has been running a cloud AI platform ever since.

The Conversation Worth Having Before the Next Contract

HIPAA is not a US-only problem for Taiwan medtech manufacturers. It is a market access problem. The US healthcare market is one of the largest and most valuable in the world for medical device companies. Accessing it requires operating as a compliant Business Associate — and the standard of compliance expected by US hospital procurement and compliance teams is rising, not falling.

The manufacturers who navigate this well are not the ones with the most elaborate compliance programmes. They are the ones who understood their obligations before they signed, built what they needed to build before an incident occurred, and negotiated BAA terms that reflected their actual operating model. That understanding starts with knowing where your device architecture sits on the spectrum, what your BAA actually says, and what you have — and have not — built for.