Which of the two do you actually need?

What changes depending on which side you land on?

• Computer software assurance (CSA), the FDA final guidance of 3 February 2026 against Computer system validation (CSV), the traditional practice of scripted testing and verification at each stage of the life cycle

  What FDA's computer software assurance guidance removes from a validation file, what it leaves in place whichever method you use, and who inside your company now signs the risk judgement.

  Moving to CSA changes which testing methods you may use and how much test-plan detail you write in advance. It changes neither the validation obligation, nor the elements of the record an investigator reads, nor the fact that a named person signs the risk judgement behind every one of them.

• EU MDR software requirements against FDA premarket software requirements

  The two regimes read the same intended use statement for opposite purposes, scope the package by different instruments, and run on different clocks. What that costs a company selling into both.

  The test runs can serve both files. The arguments wrapped around them cannot, because the EU scopes the package from the class your own claim produces and FDA scopes it from a documentation level and a predicate. Decide the claim once, in front of both readers.

• HIPAA Security Rule against HITRUST certification

  One is federal law with no certificate and no expiry date. The other is a purchased certificate with a fixed expiry date. What each does to your evidence, your timeline and your liability.

  A HITRUST certificate clears a customer's procurement gate on a date you can put in a contract, and it lapses. The HIPAA obligation answers to a regulator, follows ePHI onto every platform that holds it, and cannot be handed to an assessor.

• HL7 v2 messaging against FHIR R4 RESTful API

  The two do not replace one another. What a fact loses crossing from a message to a resource, which end decides, and why a green report on one side is silent about the other.

  A conformance pass on the v2 feed and a conformance pass on the FHIR endpoint can both be genuine while the same patient reads differently on the two sides. The mapping between them is a third artefact, it is Trial Use, and no validator on either side is pointed at it.

• IEC 62304 against ISO 13485

  One standard is audited on your company and the other is filed per product. What that costs, which regulator opens which, and what an ISO 13485 certificate does not say about your code.

  An ISO 13485 certificate carries a presumption of conformity on the quality system side and none on the software lifecycle, because no software standard appears in the MDR harmonised list. The lifecycle evidence is filed per product, and the parts of it that name a build cannot be written afterwards.

• In-house QA team against Outsourced QA supplier

  Which testing obligations change hands when the work goes outside, which of them cannot be handed to anyone, and what each arrangement leaves in front of an auditor.

  Outsourcing moves who runs the test. It leaves the record, the risk analysis and the release decision where they were, and it generates an audit task about the supplier that an in-house team never generates.

• Manual testing against Automated testing

  FDA's assurance guidance splits testing into scripted and unscripted, and puts automation inside one branch. Which IEC 62304 clauses no script closes, and what automating the wrong half removes.

  Automating a scripted case changes who executes it and nothing about the class of evidence it produces. Moving work out of the unscripted branch removes the testing IEC 62304 expects somebody to evaluate, and the file keeps every repeated assertion while losing its judgement clauses.

• Verification against Validation

  Which evidence each activity produces, why a fully verified build can still fail validation, and the protocol labelled validation that proves only that the build matches its own specification.

  A complete IEC 62304 file is verification evidence. The standard's own scope excludes device validation, so a team can close every clause it binds and still have written nothing about intended use.