Where your data lives, and where the boundary is.
This page includes the limits as well as the protections. You are buying software that holds patient information — you should know both before you decide, not after.
Your data stays yours
EasyDME is a Windows desktop application talking to a SQL Server database you own and host — on the workstation itself, or on a server in your own practice. There is no EasyDME cloud, no hosted tenant, and no telemetry. Patient information does not travel to us because there is nowhere for it to go.
Data leaves your network only where you direct it: to your clearinghouse when you submit a claim, to your own SMTP server when you send a statement, and to a shared folder you nominate for invoices, delivery tickets and EDI batches.
What is protected, and how
- Passwords are stored as PBKDF2-SHA256 digests with the iteration count recorded inside the digest, so it can be raised later without invalidating existing accounts. Repeated failures lock the account for a period.
- Secrets — the database connection string, clearinghouse credentials, API keys — are DPAPI-encrypted per Windows account and never written into configuration files.
- The audit trail is append-only in practice. Nothing anywhere in the application deletes or edits an audit row.
- Decisions are recorded rather than implied. A worked denial, a resolved credit, a revoked power of attorney and a withdrawn commission run all require a written reason, because each is read years later by somebody who was not there.
- Nothing is destroyed to tidy up. Sales reps, shipping routes, kits, consents and authorities are retired or revoked with a date, never deleted — a historic record must still resolve.
- The last active administrator cannot be demoted, disabled or deleted, so an installation cannot lock out its own owner.
Disclosure and consent
Consent to contact a patient is recorded per destination, not per patient: consent to text one number is not consent to text whatever replaces it, and a recycled mobile reaching a stranger is a disclosure. Withdrawal is kept and dated rather than deleted, because that date is what answers "you kept contacting me after I said stop".
Where consent is absent, the application refuses to send anything carrying patient information. That is deliberately the opposite of how it treats a payer: an unreachable payer is inconclusive, but absent consent is a no. A message that does not go costs a phone call; one that should not have gone is a disclosure.
Who may be told about a patient's account is recorded and dated. A healthcare proxy speaks about treatment and not about a bill; an emergency contact is not authority to hear anything at all. The screen says so before somebody speaks rather than after.
Text messages
SMS is capped at content carrying no patient information, and that cap does not move. This is TCPA rather than caution: damages are statutory and per message, and the FCC's healthcare exemption expressly does not reach account, billing or debt-collection content. Email and fax can be raised once you have a business associate agreement in place. There is deliberately no equivalent switch for SMS.
The limits, plainly
Two things are worth knowing before you decide who gets a workstation.
Roles are a usability boundary, not a security one. EasyDME is a thick client talking straight to SQL Server. Anybody who can reach the connection string has full database access whatever role you gave them in the application. Closing that gap needs either a server tier or per-role SQL Server permissions, and neither is a small change. In practice this means treating a workstation with EasyDME on it the way you would treat direct database access.
The local error log can contain patient information. It records exception text, and an exception raised mid-operation may name a patient. It is written per Windows user under the local application data folder and inherits that account's permissions.
On HIPAA
We do not claim a certification, because there is no such thing as "HIPAA-certified software". HIPAA compliance is a property of your practice — your policies, your training, your agreements and your infrastructure — and software is one input to it.
What we can tell you is exactly how this application handles data, which is what the rest of this page is for. Because EasyDME is installed on your own hardware and we hold none of your data, we are not acting as your business associate in the ordinary course of licensing it. If a support arrangement would give us access to your systems, that changes, and a business associate agreement should be in place first. Ask us and we will put one in front of you.
Backups
Backup uses SQL Server's own BACKUP DATABASE rather than copying files, because a database file copied while the engine is running is not a backup — it is a file that restores sometimes. The dashboard counts days since the last one, and shows "never" rather than zero when there has not been one, because zero reads as "backed up today".
Restore drops the database to single-user first and returns it to multi-user in every case, so a failed restore cannot lock a practice out of its own data.
Questions we are happy to answer
- Where exactly does each kind of file get written, and who can reach it?
- What does the audit trail capture, and how would we produce it for a survey?
- What would a business associate agreement with you look like?
- How do we get our data out if we stop using EasyDME?
That last one has a short answer: it is your SQL Server database and your folders. Nothing is encrypted in a format only we can read, and nothing is held anywhere you cannot reach.
Ask us the awkward questions.
We would rather answer them now than have you find out later.