The Data COUNTS™ (Collect Data Once, Use Numerous Times)

Active

Contract Opportunity

Description

This is a Request for Information (RFI). This is NOT a solicitation for proposals, proposal abstracts, or questions. The purpose of this RFI is to obtain knowledge and information for project planning purposes. The Government does not intend to award a contract on the basis of the RFI or otherwise pay for the information requested. Responses will be treated as information only and not as a proposal.

The NIH seeks information on technologies and capabilities to further the objectives of the Data COUNTS program. The Data COUNTS™ (Collect Data Once, Use Numerous Times) effort is built on collaboration between patients and advocates, government, health systems, technology companies, and the private sector. The Data COUNTS program enables the NIH’s Real-World Data initiative and will provide high quality, standardized data that is provenanced and available through approved access to the research community. The contemplated capability will initially perform requested and approved extraction from Healthcare Partner EMR systems and should be modular and extensible to other authorized source systems such as laboratory information systems, pharmacy information systems, picture archiving and communication systems, vendor-neutral archives, and specialty systems. The Data COUNTS program requires that source data, and source provenance metadata, permissions, and source ontology fields will be preserved without modification or loss. This program will not create or standardize ontology mappings.

Technical Requirements of Interest:

Address availability and technologies that enable the following features:

1. A durable, Healthcare Partner Leave Behind Technology capability that remains at the Healthcare Partner site after contract completion and can be operated by trained staff without ongoing involvement. The technology should be available and free for use by Healthcare Partners while in the Data COUNTS program. Describe any installation and configuration documentation, operational runbooks, site-controlled credential-transfer procedures, documented dependencies, major-release update procedures, and training that enable independent site operations.
   
   
   
   1. Deep query for approved extraction from Healthcare Partner electronic medical records (EMR) systems and other authorized source systems.
   
   
   2. Capture timestamps and provenance for all data at extraction and maintain an immutable provenance chain.
   
   
   
   


2. The architecture consumes a machine-readable, version-controlled, authorized, and approved Data Request Specification defining cohort logic, requested source systems, data domains and fields, date range, full or incremental extraction mode, refresh cadence, and applicable authorization and permission rules. Describe how the solution validates data availability against the specification, identifies unavailable or ambiguous fields, avoids silent substitutions, associates the request identifier with each batch and output, and supports reproducible reruns when source data have not changed.


3. An initial automated data quality check validating completeness, uniqueness, data types, date sequencing, and records-per-patient. All anomalies must be reported before any permitted corrections are applied. Sourced data will not be modified


4. De-identification per 45 CFR §164.514(b): remove all 18 direct identifiers; document a consistent de-identification pathway; and apply a per-patient date-shifting specification that preserves temporal order.


5. Privacy Preserving Record Linkage (PPRL) tokenization capabilities for cross-site linkage using an approved, on-premises within the institutional trust boundary PPRL platform that generates consistent, irreversible patient tokens. Describe validation and Healthcare Partner approval before the first live transmission. Describe how token consistency is achieved across independently deployed, site-local PPRL instances, without introducing a shared trust boundary outside the Healthcare Partner site.


6. Describe how the solution preserves all source provenance metadata, permissions information, and ontology fields (e.g. SNOMED CT, LOINC, ICD-10, RxNorm, UCUM, etc.) without modification or loss, excluding authorized de-identification transformations performed under Section 4. The DSP will not create or standardize ontology mappings. Metadata must be additive, clearly identified, and each output value must be traceable to the source and authorized transformation.


7. Describe how the solution consumes authoritative eligibility supplied by the Healthcare Partner and applies it before transmission; records the governing authorization or permission version for each dataset; distinguish cohort exclusions from permission exclusions; and apply revocations so that revoked records are absent from all subsequent refreshes.


8. Describe how the solution generates full and incremental extracts; maintains stable patient tokens; creates unique snapshot and refresh IDs; supports idempotent reruns; identifies added, updated, deleted, merged, unmerged, corrected, and late-arriving records to the appropriate refresh cycle.


9. Workflow Integrity & Processing Audit: maintain audit records for each stage; timestamp, stage ID, batch ID, record counts, outcome, and reconciliation status. Failed reconciliations or incomplete processing stages must halt transmission until resolved or authorized for reprocessing.


10. Security Posture: Describe the ability to attest to HIPAA Security Rule compliance as a Business Associate;


11. Security Audit Logging to generate SIEM-compatible security logs for authentication, administrative actions, configuration changes, and security events. Record timestamp, user/service account, action, resource, and outcome. Security logs must be protected against unauthorized modification or deletion, and logging must be continuous.


12. Defense-in-Depth Encryption: TLS 1.3 where supported; TLS 1.2 minimum for all data in transit,; application-level encryption of output files and VM-level encryption.
    
    
    
    1. Attack Surface Minimization with no unnecessary ports, services, or network listeners by default. The only authorized external connection is the outbound TLS path to the Data COUNT Program
    
    
    
    


13. Also see Section 1 regarding on-site operation of Leave Behind Technology; this section addresses the boundary for identifiable data processing. Describe how identifiable processing is confined to the Healthcare Partner’s VM and institutional trust boundary; only de-identified, tokenized output is transmitted for the Data COUNTS program; access is integrated with Healthcare Partner identity and access controls and is site-managed and logged; and the deployed solution does not include or permit contractor credentials, contractor remote-access pathways, or contractor remote-management capabilities.


14. Describe supported performance at baseline, 2X, and 5X expected workloads and identify assumed data volumes, throughput, processing time, and Healthcare Partner CPU, memory, storage, network and staffing requirements.


15. Describe how the solution can reliably package, transmit, reconcile, and retry deliveries to the TDB, including package, schema versioning, and error resolution.

Business Information Requested

Please provide information on the following:

1. Details on which capabilities are able to be met
   
   
   
   1. Clarification on which features are commercial off-the-shelf (COTS), and which features would be considered minor modifications, and which features would be considered custom development features
   
   
   
   


2. Billing model and pricing structure and any additional features and their subsequent costs


3. Experience with successful implementation capabilities and list of healthcare partners


4. Experience of similar work with Federal Government agencies


5. Experience of similar work with industries or non-profit organizations


6. Business size and status

Response Format:

Responses must be submitted by September 22, 2026, 3:00 Eastern Standard Time to DataCounts@nih.gov with the subject line Company Name RFI Response. Responses must be submitted in PDF or MS Word format. Organize the responses according to the numbered requests in this RFI. Questions may be submitted by September 15, 2026 to DataCounts@nih.gov.

Government Follow-up

The Government may contact respondents for clarification, additional information, or a capability demonstration. The Government is not obligated to contact any respondent.

Disclaimer and Important Notes. This notice does not obligate the Government to award a contract or otherwise pay for the information provided in response to this notice. The Government reserves the right to use this information provided by respondents for any purpose deemed necessary and legally appropriate. Any organization responding to this notice should ensure that its response is complete and sufficiently detailed. Information provided will be used to assess tradeoffs and alternatives available for potential requirements and may lead to the development of a solicitation. Respondents are advised that the Government is under no obligation to acknowledge receipt of the information or provide feedback to respondents with respect to the information submitted.

Any solicitation resulting from the analysis of information obtained will be announced to the public. However, responses to this notice will not be considered responsive to solicitation.

Confidentiality. No proprietary, classified, confidential or sensitive information should be included in a response. The Government reserves the right to use any non-proprietary technical information in any resulting solicitation.

Attachments/Links include: www.nih.gov/data-counts

Primary Point of Contact

Susan Gregurick

DATACOUNTS@nih.gov

Christopher Ray

Chris.ray@nih.gov

Attachments/Links