The single most consequential decision in medical software is made before any code: whether what you are building is a regulated device function or an administrative tool. Everything downstream, the process, the documentation, the price and the timeline, follows from that, and getting it wrong in either direction is expensive.
Classification is not the agency's call
Whether software is a device function depends on what it does and what happens if it is wrong, and that determination belongs with your regulatory function rather than with a development firm in a sales meeting. Settle it before taking fixed price quotes, because a bidder pricing an administrative tool and a bidder pricing a device function are pricing different projects. A firm that offers to tell you your classification has told you something about itself.
What medical software developers work under on the regulated side
Device manufacturers work under 21 CFR part 820, the quality management system regulation, which means requirements, design decisions, verification and validation evidence, change control and supplier oversight are maintained as controlled records as the work happens rather than reconstructed afterwards. A proposal to build first and document later is a proposal you cannot use, and the retrofit usually costs more than the original build.
Privacy obligations apply to custom healthcare software development solutions either way
Regulatory approval and privacy are separate stacks. Where protected health information is involved the technical safeguards at 45 CFR 164.312 require access control, audit controls, integrity, authentication and transmission security whichever side of the device line you are on. If the project involves research or analytics, the de-identification standard at 45 CFR 164.514 is the reference for what has to be removed before data stops being protected health information.
Choosing healthcare software consulting on the right evidence
Ask whose quality management system the work is performed under, because someone must own it and the answer changes your obligations. Ask for a redacted traceability matrix from previous work. Ask how a requirement change after verification has begun is handled. Teams that have shipped regulated software answer immediately and in detail; strong general firms answer in principle, and that gap is exactly what you are paying to detect.
Questions people ask about medical software development
What decides whether custom medical software is a medical device?
What it does and what happens if it is wrong, determined by your regulatory function rather than your development firm. Settle it before taking fixed price quotes, because the two sides of that line are entirely different projects.
What does the regulated side add to software development healthcare industry projects?
A quality management system under 21 CFR part 820: requirements, design decisions, verification and validation evidence, change control and supplier oversight kept as controlled records as the work happens, not reconstructed later.
Do privacy rules apply if we are not a device?
Yes. Where protected health information is involved the technical safeguards at 45 CFR 164.312 apply regardless, and for research or analytics the de-identification standard at 45 CFR 164.514 defines what has to be removed.