Healthcare software engineering is the discipline of building software clinicians and patients can trust: HIPAA as an engineering constraint, DICOM / HL7 / FHIR as the languages, architecture and DevSecOps as the practice. It is the field. It is not how you ship a web app, not a generic SDLC, and not IEC 62304 / SaMD.
If you meant how to build a healthcare web app → healthcare web application development. If you meant how to run the project / SDLC → medical software development process. If you meant IEC 62304 / SaMD → medical device software development. If you meant device Phase 0–5 → medical device development process. If you meant imaging-software stack → medical imaging software development. If you meant device-to-EHR → medical device integration. If you meant interop vendor list → healthcare interoperability solutions.
If the work is a web DICOM viewer or imaging model, PYCAD is the imaging stack, not a generic healthcare-software house.
What the discipline is
A hospital is a building with a foundation, specialized wings, and a records vault. The software is the same job in code: it has to hold millions of files, be fast enough for the ER, and be closed enough that a stranger cannot read a chart. A line of code can change a clinical decision or leak a name. That is why this is a discipline, not “we also do healthcare.”
Three promises sit under every design:
- Security. Patient data is an ethical and legal duty, not a feature flag.
- Interoperability. Devices and systems have to speak the same language so a CT and a history land in one view.
- Regulation as engineering. HIPAA is not a PDF you attach at the end. It is access control, encryption, and an audit trail you can show.
Those three are the field. How you run the project (requirements, SRS, test, 510(k) as a step) is 525. How you ship a browser app is 404.
HIPAA as engineering
In the US, HIPAA is the law of the land for Protected Health Information. For an engineer it is three concrete controls, not a slogan:
- Minimum-necessary access. A nurse, a radiologist, and a billing clerk see different slices of the same chart. Role-based access is the implementation.
- Encryption. Unreadable at rest and in transit. No “we’ll turn TLS on later.”
- Audit trail. Who touched PHI, what they did, when. You cannot investigate a breach you did not log.
The transfer how-to (BAAs, in-flight PHI, vendor hops) is HIPAA compliant data transfer. This page is why those controls exist in the architecture.
| Rule | Where | What the engineer actually builds |
|---|---|---|
| HIPAA | United States | Access, encryption, audit on PHI. “Minimum necessary” is a permission model, not a policy PDF. |
| GDPR | European Union | Consent, purpose limitation, a path to erase or export. HIPAA-ready is not GDPR-ready. |
| ISO 13485 | International (QMS) | Design and manufacture under a quality system — if the software is (or is in) a medical device. The 62304 lifecycle itself is 700. |
FDA 510(k) / PMA as a submission path is FDA medical device approval process, not a second chapter here.
DICOM, HL7, FHIR — three languages
Interoperability here is engineering: get the systems to speak. It is not a vendor list (693) and not device-to-EHR plumbing (701).
| Standard | Job | What it carries | Failure mode |
|---|---|---|---|
| DICOM | Medical images | Pixels plus study / patient / device metadata. Not a JPEG. | A viewer that strips the header. A “PNG export” that loses the study. |
| HL7 v2 | Hospital bus | ADT, orders, labs, observations. Pipe-delimited messages. | A new app that cannot parse the feed the hospital already runs. |
| FHIR | Web / mobile clients | The same clinical facts as REST resources (JSON / XML). | Asking for a whole v2 dump when you needed one Observation. |
A DICOM file is a study, not a picture. Building a viewer that treats it as a JPEG is how you leak PHI and lose the series. The imaging-software stack (pipeline, classify-before-you-code) is 678. The viewer how-to is DICOM viewer software.
Architecture and DevSecOps
A defense-in-depth stack is the default: network perimeter, application auth, data encryption. A firewall alone is not a hospital.
Cloud-native (AWS / Azure / GCP) is how you absorb an ER spike without buying a rack for a quiet Tuesday. Microservices are how you update a viewer without taking the chart down. That is the architecture chapter of the discipline. The browser/cloud how-to for shipping a web app is 404.
DevSecOps means security is in the pipeline, not a gate on Friday. Automated tests against regressions. Load the imaging path the way a floor will — many readers, large studies — and keep it up. Monitor after go-live so you see a failure before a clinician pages you. The test and validation packs for device software are 700 testing and 700 validation; this page is the engineering culture, not those packs.
AI on images is a model sitting on this stack, not a second article. Bias in the training set is a patient-safety bug. The listicle of “AI devices” is not this URL.
FAQ
Is a DICOM viewer just an image viewer?
No. A JPEG is pixels. A DICOM object is pixels plus PHI and study metadata, and it has to load at clinical speed. That is why the imaging piece is its own craft.
Why FHIR if HL7 already runs the hospital?
HL7 v2 is the bus that already moves ADT and labs. FHIR is how a modern client asks for one resource without parsing a batch. You usually need both. FHIR-as-an-API is API for healthcare.
Where does PYCAD sit?
The imaging stack — a web DICOM viewer or a model — not a healthcare-software-engineering consultancy and not a house that ships EHR, telehealth, or “all healthcare software.”