Is ndd EasyOne Connect Spirometry Software HIPAA Compliant for Pulmonary Function Labs?

Software Integration with EMR and EHR Systems

Your HIPAA posture starts with clean, secure data flow between the spirometry platform and your EMR/EHR. Verify that ndd EasyOne Connect supports HL7 interoperability and, where applicable, FHIR-based exchanges so orders, results, and patient demographics map correctly without manual re-entry.

Ask how the software links tests to the right encounter and patient identifiers to avoid mismatches in Protected Health Information (PHI). Confirm that interface engines and APIs enforce data integrity verification so transferred values (e.g., FEV1, FVC, loops) are complete and unaltered.

Key integration checks

• Standards: HL7 v2.x messages, FHIR resources, and MLLP/REST transport as needed.
• API security protocols: OAuth 2.0/OpenID Connect scopes, signed tokens, and rate limits.
• Error handling: acknowledgments, retries, and reconciliation queues to prevent data loss.
• Field mapping: consistent units, reference ranges, and LOINC where supported.

Data Security and Encryption Practices

Confirm that PHI is encrypted in transit with current TLS (1.2/1.3) and at rest using strong encryption standards such as AES‑256. Require encryption of databases, application files, logs containing identifiers, and all backups—including offsite and removable media.

Evaluate key management: unique keys per environment, rotation schedules, and restricted access to key vaults or HSMs. Ask about file- and field‑level encryption for especially sensitive attributes (e.g., SSN if collected), plus checksum or hash-based data integrity verification for stored test results.

Operational safeguards

• Hardened endpoints and servers, limited administrative access, and secure update channels.
• Malware protection and allowlists on acquisition workstations connected to spirometers.
• Secure disposal of temporary files and audit data containing PHI.

Compliance with HIPAA Privacy Rule

HIPAA does not “certify” software; instead, you must implement the software in a way that meets the Privacy Rule’s requirements. Confirm that ndd EasyOne Connect supports minimum‑necessary access, role‑based data views, and clear separation of test data from nonessential identifiers.

Ensure the product enables timely access and amendment of records, supports disclosure tracking when applicable, and offers configuration options to limit use and disclosure of PHI. When sharing de‑identified data, verify support for the Safe Harbor approach or expert determination workflows your policies require.

Audit and Access Controls

Robust compliance audit trails are essential. Require immutable logs that capture user ID, timestamp, workstation, patient/test context, action taken (view, edit, export, delete), outcome, and source/destination for transmissions.

Logs should be tamper‑evident, retained per policy, and exportable to your SIEM for correlation and alerting. Use user access controls to enforce least privilege, periodic entitlement reviews, and break‑glass workflows with enhanced monitoring.

Recommended audit practices

• Daily exception review of failed logins, privilege changes, and bulk exports.
• Quarterly verification of log completeness and clock synchronization across systems.
• Documented procedures for incident triage and breach assessment.

User Authentication Mechanisms

Authentication should align with your enterprise standards. Look for MFA support, strong password handling aligned to NIST 800‑63B, and session controls (idle timeouts, re‑auth for sensitive actions). Centralized SSO via SAML 2.0 or OpenID Connect improves consistency and auditability.

Use granular roles to limit ordering, testing, interpreting, and exporting privileges. Validate that emergency access can be granted with auditable justifications and that dormant accounts are automatically disabled.

Data Transmission Standards

For network communications, require TLS 1.2/1.3 with modern cipher suites and certificate pinning or mutual TLS where feasible. For batch workflows, use secure protocols (SFTP/FTPS) with integrity checks such as SHA‑256 digests.

When exchanging with EMR/EHRs, confirm HL7 interoperability over MLLP for v2.x messages or HTTPS for FHIR APIs. Ensure API security protocols include scoped OAuth tokens, short lifetimes, and signed JWTs. Use acknowledgments and retries to guarantee delivery and data integrity verification end‑to‑end.

Vendor Compliance Documentation

Before declaring ndd EasyOne Connect “HIPAA compliant” in your environment, obtain and review the vendor’s documentation. At minimum, secure a Business Associate Agreement (BAA) and a current security whitepaper describing architecture, encryption standards, and operational controls.

• HIPAA Security Risk Analysis and risk management plan relevant to the software.
• Independent assessments (e.g., SOC 2 Type II) and recent penetration test summaries.
• Vulnerability management cadence, SBOM or component inventory, and patch timelines.
• Disaster recovery/RTO-RPO targets, backup/restore testing evidence, and data retention.
• Employee HIPAA training, access provisioning procedures, and incident response process.

Summary

ndd EasyOne Connect Spirometry Software can be used in a HIPAA‑aligned manner when it is integrated securely, configured with strong user access controls, protected by modern encryption standards, and supported by verifiable vendor documentation. Your lab’s compliance ultimately depends on how you deploy, manage, and monitor the software within your own policies and technical safeguards.

FAQs

What security features does ndd EasyOne Connect include?

Expect support for encryption in transit and at rest, role‑based user access controls, MFA and/or SSO, detailed compliance audit trails, secure APIs with modern API security protocols (such as OAuth 2.0 and signed JWTs), and mechanisms for data integrity verification. Always confirm exact features and versions in the vendor’s security documentation.

How does the software handle patient data encryption?

Best practice is TLS 1.2/1.3 for data in transit and AES‑256 (or equivalent) for PHI at rest, including databases and backups. Keys should be stored in restricted vaults, rotated regularly, and never embedded in application code. Ask the vendor whether field‑level encryption is available for especially sensitive elements.

Is the software regularly audited for HIPAA compliance?

HIPAA has no official certification program. Instead, vendors typically perform periodic HIPAA Security Risk Analyses and may undergo third‑party audits (e.g., SOC 2 Type II) and penetration tests. Request current reports and remedial action summaries to evaluate ongoing controls.

How can labs verify the software’s compliance status?

Obtain a signed BAA, review the HIPAA risk analysis, encryption standards, and audit logging capabilities, and assess independent attestations and test results. Validate HL7 interoperability and API behavior in a staging environment, perform your own risk assessment, and document that user access controls and data integrity verification meet your policies.