Commissioning Healthcare Software: The Compliance Questions to Settle First

A healthcare software development company settles compliance through answers to specific questions, and you can put those questions to every vendor before the build starts.

B
Burhani Technologies TeamOctober 18, 2026
Commissioning Healthcare Software: The Compliance Questions to Settle First

A healthcare software development company settles compliance through answers to specific questions, and you can put those questions to every vendor before the build starts. Vendor pages claim compliance in general terms. Comparison pages tabulate laws without turning them into anything a buyer can ask. The post turns the rules into eight questions, each tied to a provision you can open and read. The limits are stated plainly: the post is general information, and a lawyer advises on compliance. The list of questions comes first.

What should you settle with a healthcare software development company first?

Settle who handles patient data, under which law and with what controls, before any design work. Start early. Put eight questions to the vendor covering consent capture, role-based access, audit logs, retention, interoperability, de-identification, data processing terms, and breach handling. Written answers go into the contract.

A lawyer should review the contract and advise on which laws apply to your organization. The questions below prepare the conversation, and they make no promise that any system is compliant.

Buyers search for healthcare software development services under many labels, including custom healthcare software development, and the label says little about how patient data is handled. The eight questions work on any vendor, whatever the label, and they work on a single consultant and on a large firm alike. Send them in writing, and request written replies. A verbal answer in a meeting disappears, while a written one can be attached to the contract and checked at acceptance. Brochures do not count. Insist.

Which compliance questions should you ask a healthcare software development company?

Ask about consent capture, role-based access, audit logging, data retention, interoperability, de-identification, the data processing contract, and breach handling. For each, ask what the system does and where it is documented, because a good answer names the feature, the rule it serves, and who tests it.

Question

Why it matters

A good answer contains

Question: How is consent captured and withdrawn?

Why it matters: Consent must be free and specific, and withdrawable

A good answer contains: A consent record and a withdrawal path

Question: How is access limited by role?

Why it matters: Staff should see only what they need

A good answer contains: Roles and permissions, plus a test of each

Question: What does the audit log record?

Why it matters: Audit controls track activity in the system

A good answer contains: User; action; time for each access

Question: How long is data kept?

Why it matters: Retention differs by rule and record type

A good answer contains: A schedule and a deletion step

Question: Which exchange standards are supported?

Why it matters: Systems need to share records

A good answer contains: Named standards and a test plan

Question: How is data de-identified?

Why it matters: Some uses need records without identity

A good answer contains: A method and a re-identification check

Question: What does the data processing contract say?

Why it matters: A processor needs a valid contract

A good answer contains: Purpose; safeguards; erasure terms

Question: What happens in a breach?

Why it matters: Notice duties apply to the data holder

A good answer contains: A response plan with named owners

Every one of the healthcare software development companies on your list gets the same eight questions. Identical questions make the answers comparable. A gap in one reply shows up beside a complete reply from another firm. That contrast is the point.

Keep the cells in your own copy free of promises, since a good answer describes what the system does and who tests it. A vendor cannot settle compliance for you, so an answer that simply says the system is compliant is a warning.

Does HIPAA compliance cover India's data protection law?

No. The two laws apply separately. HIPAA covers protected health information held by covered entities and their business associates in the United States. Section 3 of India's DPDP Act 2023 covers digital personal data processed in India, and processing abroad linked to offering services to people in India. Meeting one does not satisfy the other.

The text, as published by MeitY in the DPDP Act 2023, applies the Act to digital personal data processed within India. That covers data collected in digital form, plus data collected otherwise and digitised later. The Act also reaches processing outside India that is connected with offering goods or services to people in India.

A vendor serving both markets needs a design for each law. Take an illustrative case: a US hospital group and an Indian clinic chain share a software vendor, and each carries its own duties. One build can serve both, but the controls must be documented for each regime.

Commencement and the rules under the DPDP Act are developing matters, so check the current status with your lawyer before you rely on any date.

This section is general information and gives no legal advice. A qualified lawyer should review it for your case.

How should consent, role-based access and audit logs work?

Under section 6 of the DPDP Act, consent must be free and specific, informed, unconditional, and unambiguous. A person can withdraw it. HIPAA's security rule requires mechanisms that record and examine activity, and procedures to verify who is accessing records. Together they point to a consent record, role-based access and an audit log.

Start with consent. Sub-section (1) of section 6 asks for a clear affirmative action, limited to the personal data necessary for the stated purpose. The right to withdraw consent at any time follows in the same section. In the system, that means a stored consent record with a purpose and a date, plus a withdrawal path that changes what the software does next. Role-based access answers the question of who sees what. 45 CFR 164.312 asks for procedures to verify that a person seeking access to electronic protected health information is the one claimed. A role model, with a test for each role, turns that into a build element.

The audit log supplies the other half. Subsection (b) of the same rule asks for mechanisms that record and examine activity in systems that contain or use electronic protected health information. An audit log records the user, the action, and the time for each access, so activity can be examined later.

Features alone never make a system compliant. They support the controls that a lawyer and a data protection lead assess, so they judge the whole system.

How long should healthcare software keep records?

Retention rules differ by record type and law. Section 8(7) of the DPDP Act requires erasure once the purpose is served, unless another law requires retention. Under 45 CFR 164.316(b)(2), HIPAA security documentation is kept for 6 years, while clinical record periods come from separate rules, so confirm them with counsel.

The 6-year rule is narrow. The rule applies to the documentation of security policies and procedures, plus related actions, and it sets nothing on how long a hospital keeps a patient's clinical record. Reading it the second way is easy. The vendor and buyer should both check what the rule covers.

Request a retention schedule and a deletion step from the vendor. The schedule lists each record type and its period, and the deletion step says how erasure happens and who confirms it. With neither, data stays forever by default.

Breach handling completes the list. The DPDP Act, in section 8(6), asks the business to give the Board and each affected person intimation of a personal data breach, in the form and manner prescribed. The vendor's response plan should name who detects a breach, who informs you, and how fast. Get it in writing.

Interoperability and de-identification belong near this decision, because records leave the system. Both need a test. Find out which exchange standards the software supports and how the vendor tests them. Then establish how identity is removed for uses that do not need it, and how the vendor checks that a record cannot be traced back.

This section is general information and gives no legal advice. A qualified lawyer should review retention duties for your records.

Where does Burhani Technologies fit among healthcare software development companies?

Burhani Technologies builds custom software shaped around clinical and administrative workflows, with structured records that reach the clinical team. Burhani makes no compliance certification claim. Your lawyer and your data protection lead should review every healthcare project, ours included.

Burhani's AI-Powered Healthcare CRM and Monitoring case serves a healthcare provider in the United States. The system tracks vitals and activity, shows patient dashboards, gives doctors review interfaces, and surfaces AI-supported insights and alerts. The insights support review by the clinical team, and doctors make the decisions.

The case, AI-Powered Healthcare CRM & Monitoring, connects patient records to a clinical team in a usable form. The build links structured patient information to dashboards that doctors review. The AI-supported insights are one feature among several. They sit beside the vitals and activity tracking.

The case makes no claim about diagnosis, accuracy scores, or certifications, and nothing here implies any. Burhani's role was to build custom software around the provider's workflow. Responsibility for care stays with the clinicians.

→ Describe the workflow, the users and the data you hold, and book a free consultation.

FAQs on choosing a healthcare software development company

What does a healthcare software development company do?

A healthcare software development company builds systems for patient records and for scheduling, with monitoring and review tools. The work also covers consent, access control, audit logging, and data handling. Ask what each system does with the data. Bring the eight questions in this guide to each vendor, and ask for written answers that you can attach to the contract.

Is HIPAA the same as India's DPDP Act?

No. HIPAA covers protected health information in the United States, held by covered entities and their business associates. The DPDP Act covers digital personal data processed in India, plus some processing abroad, and meeting one law does not mean meeting the other.

What is an audit log in healthcare software?

An audit log is a record of who accessed what and when. It captures the user, the action, and the time. 45 CFR 164.312(b) asks for mechanisms that record and examine activity in systems containing electronic protected health information. The log makes that examination possible.

How should consent be captured?

The DPDP Act asks in section 6 for consent that is free and specific, informed, unconditional, and unambiguous, given by a clear affirmative action. The system should store a consent record with its purpose and date, and offer a way to withdraw. The software then acts on the withdrawal.

How long must healthcare data be kept?

The period depends on the record type and the rule. The HIPAA 6-year requirement in 45 CFR 164.316(b)(2) covers security documentation only. Clinical records follow separate rules, and the DPDP Act requires erasure once the purpose is served unless another law requires retention. Confirm each period with counsel.

What is de-identification?

De-identification removes identifiers so that a record cannot be traced to a person. Request the method from the vendor, and a check that re-identification is not possible. Uses such as analysis often need records without identity. Document and test the method.

Which of the eight questions will you ask first?

Bring the eight questions to every vendor and keep the written answers with the contract. File them together.

→ Share the workflow and the data it handles, and get in touch.

Let's talk

Ready to build something like this?

Tell us what your team is dealing with and we'll map out what a working system would look like.

Book a free consultation