Key facts
As of September 2026 Sthenos holds no SOC 2 report, HITRUST certification or ISO 27001 certificate; we build to those controls and hand the client the evidence.
In healthcare software the compliance claim is the product decision, and most buyers are shown the wrong one. “HIPAA compliant” is a self-assessment. SOC 2 Type II, ISO 27001, ISO 13485 and HITRUST involve an independent auditor and produce a report with a date on it. HIPAA has no certifying body, so nothing and nobody can be “HIPAA certified”, whatever a sales page says.
No certifying body exists, so nothing can be “HIPAA certified”, whatever a sales page claims.
An outside auditor, and a report or certificate carrying a date you can ask for. Sthenos holds neither.
FHIR has dialects and HL7 v2 is still everywhere. Test against the instance, not the spec.
Sthenos is not SOC 2 attested. We build to the controls and hand you the evidence trail.
On this page
- What we build for healthcare organisations
- HIPAA compliant patient portal development
- The organisations this work is for
- Interoperability is where healthcare projects actually fail
- Interoperability standards we build to
- What a compliance-ready build actually includes
- HIPAA and SOC 2: what we hold, what we build to, what you receive
- Regulations beyond HIPAA, and who each one binds
- What drives the cost of a healthcare build
- What sets the calendar on a healthcare build
- How to compare healthcare software vendors
- Frequently asked questions
- More about healthcare software
- Working with Sthenos on healthcare software
- Talk to our engineers
What we build for healthcare organisations
- EHR and EMR integration. Getting data in and out of Epic, Cerner and the rest, through HL7 v2, FHIR APIs or, when that is what exists, a nightly file drop.
- Patient-facing applications. Scheduling, intake, portals, messaging and remote monitoring, built so that the accessibility and consent requirements are designed in rather than audited out.
- Clinical workflow tools. Software that sits inside how clinicians already work, because anything that adds clicks to a consultation will not be used regardless of how good it is.
- Revenue cycle and operations. Eligibility, claims, coding support and the reporting that finance actually needs.
- Data platforms. De-identification, analytics and research datasets, with lineage you can show an auditor.
Case studies, delivered with our partner NeoSOFT: EMR solution built for Florida’s largest therapy service provider, improving patient safety, operational efficiency, and communication between therapists and patients. IoT health monitoring application built for an Indian multinational healthcare enterprise, enabling large-scale health data collection, anomaly detection, and timely notifications.
The Sthenos services a healthcare programme draws on
A healthcare build is rarely one service. These are the ones already sold on this site, each with the page that describes it, so you can see what is in scope before the first call.
- Custom software development for the application itself, with the repository and the cloud accounts in your name.
- Cloud for the environment it runs in, including the key management and environment separation a compliance-ready build needs.
- Data and analytics for the de-identified reporting and research datasets, and the lineage that goes with them.
- AI and machine learning and agentic AI where a model or an agent is part of the product rather than a demo.
- Cybersecurity and penetration testing, which is the evidence an auditor and a health system security team both ask for.
- Managed services and helpdesk for the years after launch, which is where most of a system’s life is spent.
- Staff augmentation when you have the plan and the product owner and need the engineers.
- Mobile for patient and field applications, and IoT for connected devices and remote monitoring.
HIPAA compliant patient portal development
A patient portal sits beside the EHR, lab, imaging and telehealth systems, so it is judged on whether it fits the clinical workflow as much as on its features. We build the controls in rather than adding them at the end: access control on every route, audit logging, encryption in transit and at rest, and retention and deletion rules. HIPAA has no certifying body, so no portal can be “HIPAA certified”. What we hand over instead is the evidence: the access control model, the audit log design and the encryption arrangement.
The organisations this work is for
Healthcare is not one buyer. The five below want different things from the same engineering, and the difference shows up first in which systems the software has to talk to.
Health systems, provider groups and practices. The estate is an EHR or EMR with a practice management and scheduling system beside it, a laboratory information system (LIS) and a radiology information system (RIS) feeding results in, an imaging archive, a patient portal, and a telehealth or telemedicine channel. Work here is judged on whether it fits the clinical workflow, because anything that adds clicks to a consultation will not be used.
Payers and plan administrators. The estate is claims, eligibility, member and provider data, and the remittance that closes the loop. X12 837 and 835 traffic is the daily reality, and the auditable trail matters as much as the feature, because the data is used to decide money.
Digital health and healthtech product companies. You are building a product rather than running a hospital, so the gate is somebody else’s security review: EHR app registration, FHIR APIs, and a questionnaire from a health system that will decide whether you have a first customer. The engineering that gets you through that gate is the same engineering described above, done earlier.
Life sciences. Pharmaceuticals and biotechnology, where the record itself is regulated: electronic records and electronic signatures under 21 CFR Part 11, and the possibility that the software is a medical device in its own right rather than a tool beside one.
Government health agencies. Federal, state and local health programmes, where the procurement route decides the project as much as the requirements do. That answer lives on the government IT services page rather than being repeated here.
Interoperability is where healthcare projects actually fail
The engineering problem in this sector is rarely the application. It is that the data lives in a system somebody else controls, under a standard that permits enormous local variation.
Figure 1. Where healthcare data moves, and which standard carries it
Every box and every label on this diagram is a system or a standard named elsewhere on this page. The integration layer is the part you can design; the systems on the left and the reviewers behind them belong to somebody else, which is why access is requested before it is built.
Interoperability standards we build to
Every name below is a public specification with a named publisher, linked so you can read the source rather than take our word for it. We build to them. We are not certified against any of them.
| Standard | Published by | What it covers, in the publisher’s words | Where it lands in a build |
|---|---|---|---|
| HL7 v2 | HL7 International | The Version 2.x messaging standard, described by HL7 as “an Application Protocol for Electronic Data Exchange in Healthcare Environments”. | Intake and results. Admissions, orders and results messages moving through an interface engine, still a large share of real integration work. |
| FHIR R4 | HL7 International | “FHIR is a standard for health care data exchange, published by HL7”. R4 is version 4.0.1 of that specification. | Intake and results. Patient facing applications, app registration with an EHR vendor, and anything built against a modern API rather than a nightly file. |
| USCDI | Office of the National Coordinator for Health IT | “a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange”. | Intake. It is the named data set the national exchange is built around, and the Cures rule’s Standards Version Advancement Process is how health IT developers move their systems to newer versions of it. |
| C-CDA | HL7 International | An implementation guide that “contains a library of CDA templates” and “provides a single source for implementers to find CDA templates for twelve different document types”. | Intake. Referral, discharge and transition of care documents, which arrive as documents rather than as fields. |
| DICOM | NEMA, which serves as the DICOM Secretariat | “the international standard to transmit, store, retrieve, print, process, and display medical imaging information”. | Results. Imaging archives, viewers and any workflow with a study attached to it. |
| X12 837 | X12 | The Health Care Claim transaction set, used “to submit health care claim billing information, encounter information, or both, from providers of health care services to payers, either directly or via intermediary billers and claims clearinghouses”. | Claims. Everything on the submission side of the revenue cycle. |
| X12 835 | X12 | The Health Care Claim Payment/Advice transaction set, used “to make a payment, send an Explanation of Benefits (EOB) remittance advice, or make a payment and send an EOB remittance advice”. | Claims. Remittance posting and the reconciliation nobody budgets for. |
| ICD-10 | World Health Organization, with the US code files published by CMS | WHO states that clinical terms coded with ICD “are the main basis for health recording and statistics on disease in primary, secondary and tertiary care, as well as on cause of death certificates”. CMS states that “ICD-10 applies to all parties covered by the Health Insurance Portability and Accountability Act (HIPAA), not just providers who bill Medicare or Medicaid”. | Claims and reporting. Diagnosis and inpatient procedure coding, and most downstream analytics. |
| CPT | American Medical Association | “a listing of terms and five-digit codes that primarily describe medical services and procedures performed by physicians and other qualified health care professionals”. | Claims. Procedure coding on the outpatient side, and every charge capture screen. |
| SNOMED CT | SNOMED International | “the most comprehensive, multilingual clinical healthcare terminology in the world”, which “enables consistent representation of clinical content in electronic health records”. | Intake and reporting. Problem lists, clinical documentation, and anything that has to be queried by meaning rather than by string. |
| LOINC | Regenstrief Institute | “a universal code system for tests, measurements, and observations”. | Results. Labs and vitals, so that the same test arriving from two sending systems means the same thing on the other side. |
| RxNorm | US National Library of Medicine | It “provides normalized names for clinical drugs and links its names to many of the drug vocabularies commonly used in pharmacy management and drug interaction software”. | Prescriptions. Medication lists, allergy and interaction checking, and any reconciliation across two systems. |
| NCPDP SCRIPT | NCPDP, adopted by CMS at 42 CFR 423.160 | NCPDP describes itself as “the Source of SCRIPT”. For Medicare Part D, the rule states that entities transmitting prescriptions “must utilize the NCPDP SCRIPT standard” in all cases other than temporary or transient network transmission failures. | Prescriptions. New prescriptions, renewals, cancellations and the responses that come back. |
| eCQMs | CMS, through the eCQI Resource Center | “measures specified in a standard electronic format using data electronically extracted from electronic health records (EHRs) and/or clinical information technology (IT) systems to assess the quality of health care provided”. CMS uses them in quality reporting and value based purchasing programmes. | Reporting. The reason a field nobody looks at clinically still has to be captured, and captured in the right place. |
What we actually do with these. Integration and mapping work: reading the sending system’s real messages rather than the specification, mapping segments and code systems onto your data model, writing the translation layer and the tests that prove a message survived it, and building the reconciliation that tells you when one did not. Terminology work is its own job, because two systems can both be conformant and still disagree about which code means which thing. We build to these specifications and hold no certification against any of them.
What a compliance-ready build actually includes
| Requirement | What it means in the code | Cheap now, expensive later |
|---|---|---|
| Access control | Role and purpose-of-use checks on every route, enforced centrally | Retrofitting authorisation across an existing API is close to a rewrite |
| Audit logging | Who saw which record, when, and why, in a store nobody can quietly edit | You cannot reconstruct history you never recorded |
| Encryption | In transit and at rest, with keys managed outside the application | Key rotation designed in later means downtime |
| Data retention | Rules per data class, and deletion that reaches every copy including backups | Deletion requests are the hardest thing to bolt on |
| Business associate agreements | Every subprocessor that touches PHI, enumerated and covered | An unlisted vendor discovered during diligence stalls a deal |
We are explicit about our own posture rather than implying more: Sthenos is not SOC 2 attested, and we will tell you that in the first conversation rather than at procurement. What we do is build to those controls and hand you the evidence trail, so your organisation’s own audit has something to stand on.
HIPAA and SOC 2: what we hold, what we build to, what you receive
HIPAA is a law, and there is no certificate at the end of it. The Department of Health and Human Services answers the question itself: “there is no standard or implementation specification that requires a covered entity to ‘certify’ compliance”, and HHS “does not endorse or otherwise recognize private organizations’ ‘certifications’ regarding the Security Rule”. What the Security Rule does require, at 45 CFR 164.308(a)(8), is a periodic technical and non-technical evaluation of how far your policies and procedures meet the security requirements. So the question worth putting to a vendor is not whether they are certified. It is what they can show you.
SOC 2 is the other kind of thing: an examination, not a claim. The AICPA describes it as reporting on an examination of controls at a service organisation relevant to security, availability, processing integrity, confidentiality or privacy, carried out by a CPA firm. It produces a report carrying the auditor’s name and a date, held by the organisation that was examined, which is why you can ask any vendor to send you theirs rather than accept a logo on a slide.
Our own posture, dated. As of September 2026 Sthenos holds no SOC 2 report, HITRUST certification or ISO 27001 certificate; we build to those controls and hand the client the evidence.
- No certificate existsHHS states there is no standard or implementation specification that requires a covered entity to certify compliance, and that it does not recognise private certifications.
- The rule asks for an evaluation45 CFR 164.308(a)(8) requires a periodic technical and non-technical evaluation of how far your policies and procedures meet the security requirements.
- Controls are built inAccess control on every route, audit logging, encryption in transit and at rest, and retention and deletion rules.
- The evidence is a deliverableThe access control model, the audit log design, the encryption arrangement, the retention and deletion rules, and data lineage you can show an auditor. None of that is an attestation, and it is the material your own audit stands on.
What that evidence is, in the specific. Every item below comes out of the build described in the table above rather than being assembled for a questionnaire:
- The access control model, written down. Which roles and which purposes of use reach which routes, enforced centrally rather than endpoint by endpoint.
- The audit log and the design behind it. Who saw which record, when, and why, in a store nobody can quietly edit.
- The encryption arrangement. In transit and at rest, with the keys managed outside the application.
- The retention and deletion rules. Per data class, and how a deletion reaches every copy, backups included.
- Data lineage you can show an auditor, on the de-identified analytics and research datasets we build.
None of that is an attestation and we will not present it as one. It is the material your own audit stands on.
Regulations beyond HIPAA, and who each one binds
HIPAA is the one everybody names. It is rarely the only one in scope, and the others decide architecture rather than paperwork. Each entry below is tagged the way the rule itself works: mandatory for the parties named, or in scope only when the software does a particular thing.
| Rule | Status, and who it binds | What it says, at the source | What it changes in the build |
|---|---|---|---|
| HITECH Act of 2009 | Mandatory. Covered entities and their business associates. | The Office of the National Coordinator states that the HITECH Act “provides HHS with the authority to establish programs to improve health care quality, safety, and efficiency through the promotion of health IT, including electronic health records and private and secure electronic health information exchange” (healthit.gov). The breach notification rule that followed sits at 45 CFR Part 164 Subpart D, which requires notification “without unreasonable delay and in no case later than 60 calendar days after discovery of a breach”. | A 60 day clock you cannot start until you can tell what happened, which is an argument for the audit log being designed rather than added. |
| 42 CFR Part 2 | Mandatory where it applies. Part 2 programmes and anyone holding their records. | Confidentiality of Substance Use Disorder Patient Records. The regulations “impose restrictions upon the use and disclosure of substance use disorder patient records” maintained in connection with a part 2 programme, and they “prohibit the use and disclosure of records unless certain circumstances exist”. | A second, stricter consent model sitting inside a system already built for HIPAA, and a data class that cannot be treated like the rest of the record. |
| 21st Century Cures Act information blocking rule | Mandatory. Named actors: “healthcare providers, health IT developers of certified health IT, and health information exchanges (HIEs)/health information networks (HINs)”. | The Office of the National Coordinator states that the Cures Act “made sharing electronic health information the expected norm in health care”, and defines information blocking as “a practice by an ‘actor’ that is likely to interfere with the access, exchange, or use of electronic health information (EHI), except as required by law or specified in an information blocking exception”. The exceptions are at 45 CFR Part 171 (healthit.gov). | Export, access and API behaviour become compliance surfaces. A feature that quietly makes data hard to get out is no longer only a product decision. |
| FDA 21 CFR Part 820 | Mandatory for finished device manufacturers. | The Quality Management System Regulation. “Current good manufacturing practice (CGMP) requirements are set forth in this quality management system regulation (QMSR)”, governing “the design, manufacture, packaging, labeling, storage, installation, and servicing of all finished devices intended for human use”. Section 820.10 requires a manufacturer to “document a quality management system that complies with the applicable requirements of ISO 13485” (eCFR). | Design controls, design history and traceability become part of how the software is built, not a document produced afterwards. |
| Software as a Medical Device | In scope when the software’s intended use makes it a device. | The FDA uses the International Medical Device Regulators Forum definition: “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device” (FDA). | This is the question to settle before the first sprint, because the answer decides the regulatory pathway and therefore the plan. |
| FDA 21 CFR Part 11 | Mandatory for FDA regulated records kept electronically. Life sciences, laboratories and clinical trial systems. | Electronic records and electronic signatures. The part “set[s] forth the criteria under which the agency considers electronic records, electronic signatures, and handwritten signatures executed to electronic records to be trustworthy, reliable, and generally equivalent to paper records” (eCFR). FDA calls the underlying requirements predicate rules, naming among them the Current Good Manufacturing Practice regulations at 21 CFR Part 211, the Quality System regulation at 21 CFR Part 820, and the Good Laboratory Practice for Nonclinical Laboratory Studies regulations at 21 CFR Part 58 (FDA guidance). | Validation, audit trails, record retention and record copying stop being engineering preferences and become requirements with a named owner. |
| CCPA | Mandatory for businesses that meet its thresholds, including health adjacent products that are not covered entities. | The California Attorney General states that the California Consumer Privacy Act of 2018 “gives consumers more control over the personal information that businesses collect about them and the CCPA regulations provide guidance on how to implement the law”, including the right to know, the right to delete and the right to opt out (oag.ca.gov). | Deletion and access requests have to reach every copy on a deadline, which is the same engineering problem the HIPAA retention row above describes, arriving from a different direction. |
None of these is something a development vendor gets certified against on your behalf, and a vendor who implies otherwise should be asked for the certificate and the date. As of September 2026 Sthenos holds no SOC 2 report, HITRUST certification or ISO 27001 certificate; we build to those controls and hand the client the evidence.
What drives the cost of a healthcare build
We publish rates and a typical project band at the top of this page and we will not publish a price for a build we have not scoped, because the same feature list costs different amounts in two different hospitals. What follows is what actually moves the number, so you can work out which way your own project leans before anyone quotes you.
Core scope
The number of user roles and how far apart they are, whether purpose of use has to be enforced and not just role, how much of the workflow is clinical, and whether the software could be a medical device.
Integration
The number of systems and who controls each one, which standard each interface actually speaks, how much terminology mapping is in scope, and data migration.
Operational
Environment count and separation, retention and deletion, the evidence an auditor asks for, and who supports it afterwards.
Core scope.
- The number of user roles, and how far apart they are. Every distinct role is an access control decision, a set of screens and a test matrix. Clinical, administrative, billing and patient are four different products sharing a database.
- Whether purpose of use has to be enforced, not just role. Checking who someone is costs far less than checking why they are looking at this record.
- How much of the workflow is clinical. Software a clinician uses during a consultation carries a usability bar that administrative software does not, and that bar is paid for in iterations.
- Whether the software could be a medical device. Settle this first. It decides the regulatory pathway, and therefore the plan, before it decides the price.
Integration.
- The number of systems, and who controls each one. An integration you own is engineering. An integration into a system somebody else controls is engineering plus a negotiation, and the negotiation is the slower half.
- Which standard each interface actually speaks. A modern FHIR API, an HL7 v2 feed through an interface engine and a nightly file drop are three different amounts of work behind the same word.
- How much terminology mapping is in scope. Mapping local codes onto SNOMED CT, LOINC or RxNorm is its own workstream, and it is the one most often discovered late.
- Data migration. Volume matters less than how bad the source data is, and nobody knows how bad it is until it is profiled.
Operational.
- Environment count and separation. Production, staging and a safe place to test with data that is not real, each with its own keys and its own access list.
- Retention and deletion. Rules per data class, and a deletion that reaches backups, cost more to design than to run, and far more to retrofit.
- Evidence. The access model, the audit log design and the test results are deliverables, and producing them for an auditor is work whether or not it is in the estimate.
- Who supports it afterwards. The run cost is a design input, not a footnote, and it is the part of the total nobody asks about until year two.
What sets the calendar on a healthcare build
We deliver in two week sprints and you get working software every two weeks. We do not publish a duration per solution type, because we have not measured one and a made up number would be the least useful thing here. What we can tell you is which items decide the date, in the order they usually bite.
- Integration access, granted by someone elseA sandbox, an interface engine slot and a willing counterpart at the vendor are the long pole on a healthcare project, and they are requested rather than built. Start that request before the project starts.Someone else decides
- The security review on the other sideA health system’s questionnaire, a penetration test and the remediation that follows are a sequence, not a single event, and each step waits on a reviewer who does not work for you.Sequence, not an event
- Data migration and profilingThe schedule risk is not the volume, it is what profiling finds in the source, and profiling has to happen before anyone can size the cleanup.Profile before sizing
- Clinical validationAnything that sits in a consultation gets tested by clinicians whose time is scheduled in advance and is not yours to move.Scheduled in advance
- Change windowsGo live in a hospital happens when the organisation allows a change, which is a calendar with its own owner.Owned by the hospital
Every one of these is knowable early. The estimate we can defend is the one written after they have been checked, which is why the first conversation is about them rather than about a number.
How to compare healthcare software vendors
| Axis | Ask this | Why the answer separates vendors |
|---|---|---|
| Certification | Which certifications are audited and which are self-declared | Then ask for the report date. This one question separates most of the field. |
| Integration | What they have integrated with, by name and version | “Epic experience” and “we have been through an Epic App Orchard review” are different claims. |
| People | Who on the team has worked under a BAA before | Handling PHI is a habit, not a policy document. |
| Deletion | How they handle a deletion request | Watch whether backups come up unprompted. |
| Location | Where the engineers physically are | Data residency and BAA coverage both depend on it. |
We published the side-by-side of what the visible firms in this category actually publish about themselves: healthcare software development companies, compared, with the gaps marked rather than filled.
Frequently asked questions
Is Sthenos HIPAA certified?
No, and neither is anybody else. HIPAA has no certifying body, and HHS states that it does not endorse or recognize private organizations’ certifications regarding the Security Rule. A HIPAA certificate tells you nothing about the software you are buying.
Does Sthenos have a SOC 2 report?
No. As of September 2026 Sthenos holds no SOC 2 report, HITRUST certification or ISO 27001 certificate; we build to those controls and hand the client the evidence. We say so in the first conversation rather than at procurement.
Who owns the code and the cloud accounts?
You do, entirely, from the first commit. The repository and the cloud accounts are in your name, with no licence back to us and no dependency on us continuing to exist.
What does a compliance-ready build include?
The table above lists five requirements: access control on every route, audit logging of who saw which record and when and why, encryption in transit and at rest, retention and deletion rules per data class, and business associate agreements covering every subprocessor that touches PHI. Each is far cheaper built in than retrofitted.
What is FHIR, and is it the same as HL7?
FHIR is one of several standards published by HL7 International, which describes it as “a standard for health care data exchange”. It is not a replacement for HL7 v2, the older pipe delimited messaging standard. As this page says above, HL7 v2 is still a large share of real integration work, so a project can need both.
What is USCDI and who requires it?
The Office of the National Coordinator for Health IT defines it as “a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange”. ONC states it follows the Cures rule’s Standards Version Advancement Process, which is how developers move to newer versions. Name it in a data contract rather than describing fields in prose.
Do you build HIPAA compliant applications?
We build software to support HIPAA: access controls on every route, audit logging, encryption in transit and at rest, and retention rules per data class. HIPAA compliance is shared across your organisation, your hosting and your operations, and there is no certificate at the end of it for anybody. We engineer our part and hand you the evidence.
Can you integrate with Epic and Cerner?
Yes. Getting data in and out of Epic, Cerner and the rest is the EHR and EMR integration work described above, through HL7 v2, FHIR APIs or, when that is what exists, a nightly file drop. Ask any vendor what they have integrated with by name and version, because experience with a product and a completed vendor review are different claims.
Is a business associate agreement required?
The HIPAA Security Rule at 45 CFR 164.308(b) says a covered entity may let a business associate handle electronic protected health information only if it obtains satisfactory assurances that the information will be safeguarded, documented “through a written contract or other arrangement”. The obligation sits with the covered entity, and it reaches down the chain to subcontractors.
More about healthcare software
Services. Healthcare software development and healthcare IT services.
Standards. What HIPAA-compliant software is and what SOC 2 compliance means. We build to both and hold no attestation of our own against either.
Insights. AI in healthcare software, and healthcare software development companies, compared.
Working with Sthenos on healthcare software
Sthenos Technologies builds healthcare software for organisations across Maryland and the Washington DC region, delivered through an established engineering partnership with NeoSOFT. If you are scoping an integration, a patient-facing product, or an audit trail you will have to defend, talk to our engineers. Related: what SOC 2 compliance actually requires and the production readiness checklist.