Article

Digital health companies: get paid for your records

By TrustPast

Updated November 7, 2026

A digital health company builds software for a field where every decision gets written down twice. Once because the team needs it, and once because a hospital, an auditor or a regulator might ask. The sprint board, the release notes, the validation records and the security questionnaires pile up year after year. This page is for the company that has built, sold and supported a health product for several years, with 30 or more people on the team now or at its peak.

The thing owners in this field rarely realise is that the operating record has a price without a single patient record in it. A buyer licenses records like these to train AI models, and it pays for how the company worked: how a feature was specified, tested, argued with a clinical adviser and shipped. Patient data is the opposite of what is wanted. The principle is set out, for four trades, on what data buyers want from a trade business, and the same principle holds in a regulated software company.

Here is what such a company keeps, what micro1 says it wants, what stays out, how the price is set, and which programme fits.

The records a digital health company keeps

Our examples, not a buyer’s list. micro1 decides what it licenses.

The product requirements and their history. A requirements document for a medication reminder, a remote monitoring dashboard or a scheduling tool. The first version says what the product manager heard from customers. The comments say what the clinical adviser objected to. Version four is what got built. The edit trail is a record of a team turning a clinical problem into a specification.

The sprint board and the tracker. Every ticket from “intake form loses data on back button” to “add audit log export for enterprise customers.” The tickets carry the estimate, the discussion and the date each one closed. Over five years, that is how the company learned what it could ship in two weeks and what it couldn’t. Our project history page explains why the plan beside the outcome is the valuable part.

The release notes and the change control log. In a regulated product, a change usually needs a reason, a risk assessment and a sign-off before it ships. The change log holds all three. It is the company’s judgment on what was safe to change and when, applied hundreds of times.

The validation and QA records. Test plans, test runs, defects found, the decision to ship with a known issue or to hold the release. A validation record says what “good enough” meant for this product, in writing, release after release.

The incident reviews. The outage at 7 a.m. on a clinic’s busiest day. The timeline, the cause, what was changed afterwards. An incident review is a team being wrong and then getting it right, on the record.

The chat. Engineering channels, the on-call channel, the thread with the implementation team when a hospital’s integration failed on go-live day. The quick decisions that never reached a ticket live here. The chat archives page explains which channels show how the work was done.

The implementation and support records. The onboarding plan for each new customer, the questions their staff asked in week one, the support tickets that followed. A support ticket from a nurse asking why a reading didn’t sync, the diagnosis, the fix and the knowledge-base article written afterwards is a full problem-to-answer cycle.

The compliance paperwork the company wrote itself. Its own policies, its security questionnaire answers, its risk assessments, the review notes on each new contract. These show how a small company met a large customer’s demands.

How a customer request became a shipped feature is the story these records tell together. A health system asks for a new report. The account manager logs it in the CRM. Product writes requirements, the clinical adviser pushes back on one field, and the requirements change. Engineering estimates it at one sprint; it takes three because the database schema needed a change. Validation finds two defects; one is fixed, one is documented and accepted. The release note goes out. A support ticket a month later shows a customer using it in a way nobody planned. The tracker, the chat, the change log and the support queue hold that story between them.

See your estimate

What counts, in the buyer’s own words

micro1 doesn’t publish a page about digital health. Here is what its pages do say.

On who qualifies, micro1’s data partnerships page says: “We’re looking for established companies with 30+ full-time employees, mature business operations, and substantial historical operational data. This can include internal communications, SOPs, project histories, CRM records, support tickets, and other business documentation.” It adds: “Data should be primarily in English. We’re currently prioritizing US companies, followed by other Western markets.”

On what kind of data, the same page says: “We are looking for data that reflects how work is actually performed within an organization.” It lists “standard operating procedures (SOPs), process documentation, internal knowledge bases, workflows, templates, operational frameworks, and other business process artifacts.” And: “The most valuable datasets capture real operational expertise, decision-making processes, and repeatable workflows.”

micro1 groups its examples by function, and several match a digital health company closely. Under software and engineering: “Source code documentation, engineering workflows, bug tracking, product planning, and technical knowledge bases.” Under customer support: “Support documentation, ticket workflows, QA processes, customer operations, and knowledge management.” Under legal and contracts: “Policies, contract workflows, review processes, governance documentation, and compliance procedures.” A health software company’s change control log and validation records sit across all three.

On how much is needed, micro1 says: “There’s no fixed minimum number of files, documents, or terabytes.” It evaluates “the historical depth, breadth, quality, and relevance of the available data,” and “Companies with several years of records across multiple business systems are generally a stronger fit.”

micro1’s announcement of 9 October 2026 explains why it wants records of this kind: “Real business operations involve incomplete information, competing priorities and exceptions that require judgment.” A release held back over a defect, or a requirement changed after a clinician’s objection, is an exception that required judgment.

What is never included

In a health company this section matters more than anywhere else. Our page on what is never included lists what stays out for every company, and our page on health, payment and other regulated data goes into the health rules in more depth.

Patient data. Any record about a patient, from a reading synced from a device to a message sent through the app, stays out of what you describe and out of scope. The federal health privacy rules in 45 CFR define “protected health information” as “individually identifiable health information” that is “Transmitted by electronic media,” “Maintained in electronic media,” or “Transmitted or maintained in any other form or medium.” The same section defines a “business associate” as a person who, on behalf of a covered entity, “creates, receives, maintains, or transmits protected health information” for functions including “data analysis, processing or administration.” Many digital health companies are business associates of their customers. Whether yours is, and what that means for any record, is a question for counsel. Ask counsel before you apply.

What a customer owns. A health system’s data in your platform is held under your contract with it, often with a business associate agreement on top. As our own advice, treat everything you hold for a customer as the customer’s until counsel says otherwise. Our page on client-owned work and NDAs explains how to separate it from your own record.

De-identification is a defined standard here. The rule at 45 CFR 164.514 says health information “that does not identify an individual and with respect to which there is no reasonable basis to believe that the information can be used to identify an individual is not individually identifiable health information.” It sets out two routes, one through an expert determination and one through removing a listed set of identifiers that begins with “Names” and geographic subdivisions smaller than a state. We cite it so you know the standard exists, not as advice on meeting it. Ask counsel.

Payment and staff data. Card details, bank details, payroll and HR files. Not how the product was built.

Support tickets with patient details in them. A support ticket can carry a screenshot with a patient’s name. As our own advice, raise the support queue with micro1 and counsel specifically, rather than assume it is clean.

How de-identification works

micro1 publishes its approach on its data partnerships page. Before any participation, it says, the two sides confirm four things: “U.S. and allied buyers only,” “Data segregation,” “De-identified before sharing,” where “Personal and identifying information is removed or transformed before your data is shared with third parties,” and “Defined retention periods,” where “Raw data is deleted according to an agreed schedule.”

On protection, micro1 says “Personally identifiable information (PII) is removed when relevant, access is restricted to a limited number of authorized team members, and customer data is processed through isolated pipelines that prevent it from being commingled with other engagements.” It adds that “companies have the opportunity to review representative samples before use, and deletion requests are honored according to the terms of the engagement.”

micro1 also says some data is rewritten: “certain datasets may undergo synthetic rewrites that preserve workflow structure while reducing direct ties to original records.” And a company does not need to do this work first. Asked whether a company must anonymize its data before transferring it, micro1 answers: “No, micro1 has processes for de-identifying and transforming sensitive information.”

For a health company, the order matters. micro1’s process is for removing personal details that turn up inside operating records, such as a staff member’s name in a ticket. It is not a reason to put patient records in scope. Our page on how de-identification works explains the steps in general.

What decides the price

micro1 publishes three tiers on its data partnerships page. “$100K-500K” for “Qualified Enterprise Data Partnerships” (indicative, not an offer). “$500K-3M” for “Large-scale operational datasets or ongoing participation across multiple teams and business functions” (indicative, not an offer). And “$3M+” for “Highly unique, proprietary operational data” (indicative, not an offer).

On what moves a company within those tiers, micro1 says: “Factors considered include dataset size and volume, workflow complexity, data quality, domain expertise represented, and the uniqueness of the operational knowledge contained within the dataset.” Its payout page adds that its own calculator is an “Indicative estimate only. Final payout is determined based on data sources, volume, quality, access terms, and due diligence.”

Read against a digital health company: domain expertise is the clinical reasoning in the requirements and the change log. Workflow complexity is the validation and release process. Due diligence is where the patient data question comes back. That is our reading, not micro1’s: records that are clearly the company’s own and clearly free of patient data should be the simpler ones to approve. Our page on what decides the price goes through each factor.

On payment, micro1 says: “We pay in full within 30 days of acceptance.” Its FAQ sets out the sequence: “Once your company transfers its data, micro1 has 30 days to review and approve it. After the data is approved, we’ll ask your company to submit an invoice, and payment will be made within 30 days of invoicing.”

Which programme fits

micro1 is the programme for companies with 30 or more people, now or at their peak, and for companies of any size outside the US. Its referral page lists the Enterprise Data Partnership requirements as “30+ employees,” “US and Western markets,” “English” and “All industries.” Our estimate asks how many people work at the company and names the programme that fits your headcount; the programme page for 30 or more sets out the line.

A digital health company that has closed still has its record. micro1’s referral page carries a Defunct Company Data Partnership card: “We are acquiring data from companies that are no longer operating.” Its listed requirements are “30+ employees,” “10+ Countries,” “English” and “All industries,” with company compensation of “$100K-$3M+ for approved data packages” (indicative, not an offer). For a closed health company, the question of who can sign, and what happened to customer data at the wind-down, comes first; our page for closed companies goes through it.

Under micro1’s published terms, “Companies retain ownership of their underlying data.”

Some other companies keep a record shaped much like this one. AI product companies run the same tracker, release and incident machinery, usually with fewer rules around it. Game studios ship in versions and patch after launch, with a bug tracker at the centre of the record. And video production studios keep rounds of review and sign-off on every piece of work, much as a regulated product keeps them on every release.

TrustPast

Questions and answers

Does any patient data go to the buyer?

It should never be in scope. micro1 says personal and identifying information is removed or transformed before data is shared with third parties; as our own advice, keep patient records out of what you describe at all, and ask counsel how the federal health privacy rules apply to your company.

Do we need 30 employees?

micro1 says it is looking for established companies with 30+ full-time employees, mature business operations and substantial historical operational data. Our estimate asks how many people work at the company and names the programme that fits.

Which of our records count?

micro1 lists internal communications, SOPs, project histories, CRM records, support tickets and other business documentation, and says the most valuable datasets capture real operational expertise and decision-making processes. micro1 decides what it licenses.

Do we have to de-identify the data ourselves?

No. micro1 says it has processes for de-identifying and transforming sensitive information, so a company does not need to anonymize its data before transferring it.

How much does micro1 pay?

micro1 publishes tiers from $100K-500K for qualified enterprise data partnerships to $3M+ for highly unique, proprietary operational data (indicative, not an offer). Each partnership is evaluated individually.

Do we keep ownership of our records?

Yes. micro1 says companies retain ownership of their underlying data.

Our company has shut down. Does it still count?

micro1’s referral page has a Defunct Company Data Partnership: “We are acquiring data from companies that are no longer operating.” Its requirements include 30+ employees and English.