What a long-horizon clinical registry needs from its software

A device company decides to follow its implants for ten years. A surgeon group wants to know how its patients are doing at five. A research team needs outcomes data clean enough to publish. All three are building a clinical registry, and for a device company it is usually an implant registry. All three will live with the software for longer than most companies keep a CRM. This guide covers what that software has to get right, drawn from the standard references for registry design and from building one that is meant to run for a decade. It is written for small healthcare and device companies in the United States. It is not legal or regulatory advice. A few words used throughout: the sponsor is the company that owns and pays for the registry, a site is a hospital or practice that contributes cases, and a revision is a repeat surgery to replace or fix the implant.

The short answer

A registry is not a database with a form in front of it. It is a commitment to collect the same things, the same way, from many people, across years in which the implants, the forms, the staff, and the rules will all change. The software has to make the right data easy to enter, make follow-up hard to miss, absorb change without corrupting what came before, keep patient data where it belongs, and hand the results to a statistician in a shape they can use. Get those five right and the registry outlives everyone who started it. Miss one and the gap usually shows up years later, when it is expensive to fix.

Decide what the registry is for before you build it

The AHRQ registry user's guide, the standard reference in this field, starts with purpose, because purpose decides everything downstream: which data you collect, how often you follow up, how clean the data has to be, and who is allowed to see it. A registry can serve more than one purpose, but each one adds requirements, and it is far cheaper to add them at the start than to retrofit them.

• Post-market safety surveillance, meaning watching how a device performs once it is on the market. For an implant, this is often the reason the registry exists. The FDA can order post-market surveillance under section 522 for devices implanted for more than a year, and a well-run registry is one way to meet that. Even without an order, the FDA's real-world evidence guidance, finalized in December 2025, describes registries as a source that can inform post-market decisions and sometimes premarket ones. That is only true if the data was collected to a standard the FDA recognizes, which means deciding on that standard up front.
• Publications. Surgeons want to publish, and a registry that feeds papers earns loyalty from the sites that contribute. That needs a data dictionary, consistent definitions, and an export a statistician can trust.
• Product development. Which sizes get used, what gets revised and why, where surgeons deviate from the technique guide. Useful, but keep it separate from the clinical purpose so nobody later argues the registry was marketing in disguise.
• Claims. If the company ever wants to say "95 percent survivorship at five years" in a brochure, the registry has to have been built to support that sentence, with follow-up completeness and a defined analysis. Decide now whether that is a goal, because it raises the bar on everything.

Build the data around the case report form

The case report form is the list of everything to record about one patient, on paper or on screen. AHRQ's guide treats it as the basis of the registry's data structure, and that is the right way to think about it. Decide what a complete case looks like, on paper, with clinicians in the room. Then build the software to match the form, not the other way around.

• Collect less than you want. Every field is a cost paid at every site on every case for ten years. Fields that nobody will analyze get entered badly, and bad fields drag the good ones down. The guide's advice is to tie every element to a planned analysis.
• Validate at entry. Ranges, required fields, dates that make sense in order, implant combinations that are physically possible. A rule enforced at entry prevents years of cleanup later.
• Use controlled vocabularies. A dropdown of approved diagnoses, not a free-text box. Free text is where "revision for infection" becomes six spellings and one abbreviation nobody can decode.
• Record the implant precisely. Most devices sold in the US carry a unique device identifier on their label, and the device portion of it can be looked up in the FDA's public AccessGUDID database. Capture it, along with lot and serial numbers where the site can read them. Years from now, "which version of the stem was that" is the question that matters most, and it is the one nobody can answer after the fact.
• Capture outcomes patients report. Several standard outcome scores are questionnaires patients fill in themselves, and they can do that at home if the software lets them. That removes the single biggest burden on the surgeon's staff and is often the difference between follow-up that happens and follow-up that does not.

Plan for ten years of post-market follow-up

Follow-up is where registries succeed or fail. Sponsored implant studies commonly schedule visits at one, two, five, seven, and ten years. One university hospital's reverse shoulder replacement registry reported losing 18 percent of patients by two years, 22 percent by five, and 53 percent by ten. Those numbers are not unusual, and they are what the software is fighting.

• Schedule from the surgery date, automatically. The moment a case is entered, every future visit exists as a due item with a window. Nobody should be computing follow-up dates by hand.
• Make the overdue list the home page. The most useful screen in a registry is the one that says which patients are due this month, which are overdue, and who at the site is responsible.
• Reach the patient directly. Reminders by text or email, and a way for the patient to answer the outcome questionnaire from a phone. Every visit that depends on a clinic appointment is a visit you can lose.
• Record why a patient was lost. Died, moved, declined, revised elsewhere, unreachable. A statistician needs to know the difference, because a patient who died is not the same as one who stopped answering.
• Measure completeness per site. Follow-up rates by site, visible to the sponsor and to the site. Sites tend to improve when they can see their own number.

Treat change as normal

Over ten years the form will change, the protocol will be amended, the implant line will get a new generation, a site will join late, and a regulator or journal will ask for a field nobody collected. Software that assumes the data model is fixed breaks on the first of these.

• Version the forms. Every case records which version of the form it was entered on. Old cases keep their old fields. New cases get the new ones. Reports know the difference and say so.
• Never destroy, only supersede. A corrected value keeps the original beside it, with who changed it, when, and why. This is a regulatory expectation and a practical one: the question "what did the record say at the time" comes up in audits and in papers.
• Separate the implant catalog from the cases. New sizes and generations get added to the catalog without touching any case. Discontinued ones stay available for the cases that used them.
• Plan the migration before you need it. Adding a field to 5,000 existing cases is routine if the system was built for it and a weekend of risk if it was not.

Patient data and de-identification are the design, not a feature

A registry that tracks real patients over time holds protected health information. Names, dates of surgery, dates of birth, and implant serial numbers are all on HIPAA's list of identifiers. The software has to be built around that from the first screen, and the arrangement between the sponsor, the sites, and whoever builds and hosts the system has to be settled before the first case is entered. Our HIPAA and AI guide covers the agreements in detail. For a registry, the decisions that matter most are these.

• The data lives in the sponsor's own environment. The company's own cloud account, under its own agreements, with the vendor working inside it rather than hosting a copy somewhere else. When the vendor relationship ends, the data does not move.
• Agreements before data. A Business Associate Agreement with whoever builds and operates the system, and agreements with each contributing site that say what they are disclosing and for what purpose. Your counsel and the sites' privacy officers decide the exact form.
• Access by role, and an audit trail of everything. A site sees its own patients. A sponsor analyst sees de-identified data. An administrator sees the system but not the patients. Every view and every change is logged, and the log cannot be edited.
• De-identify in the reporting layer, not by hand. Analysis should never need identified records. The reporting layer strips the identifiers automatically, so a statistician works on a dataset that is not PHI in the first place. HIPAA offers two routes: remove all eighteen listed identifiers, which is called Safe Harbor, or have a qualified expert certify the re-identification risk is very small. Note that Safe Harbor strips device serial numbers and exact dates, which registries care about. Many registries use a middle path HIPAA calls a limited data set, which keeps dates but still drops device serial numbers, and requires a data use agreement with whoever receives it. If the analysis needs the serial numbers themselves, the route is an expert determination, or keeping the data as PHI under the agreements that already cover it. Which route fits is a question for counsel, and the software should support more than one.

Exports a statistician can use

The point of a registry is analysis, and analysis is done by people with their own tools. The software's job is to hand them what they need without a week of cleanup.

• A data dictionary that ships with every export. Field name, meaning, units, allowed values, which form version introduced it. Without it, the export is a puzzle.
• Stable, meaningless identifiers. Each patient and each case gets an identifier that never changes and reveals nothing. The same patient in a 2027 export and a 2033 export has the same identifier.
• Events with dates and reasons. Survivorship analysis, the standard way to report how long implants last, needs the date of surgery, the date of any revision or death, the reason, and the date the patient was last known to be fine. A registry that records "revised: yes" without a date cannot produce a survivorship curve.
• Exports in formats statisticians use, not screenshots of a dashboard. Dashboards serve the sponsor's overview. Analysis needs files.

If the registry supports post-market surveillance or an FDA submission, say so at the start

A registry run for quality improvement or publication has one set of expectations. A registry whose data will go into an FDA submission or satisfy a surveillance order has another. The FDA's rules on electronic records, known as 21 CFR Part 11, expect the system to be validated, the audit trail to be complete and tamper-proof, and electronic signatures to be tied to a specific person. None of that is exotic, but it is far easier to build in than to prove afterward. Decide with your regulatory counsel which category the registry is in before the first line of code, because the answer changes how the software is built and documented.

Who owns the data, and what happens in year eight

Vendors change, and the person who championed the registry moves on. The software should assume both. The sponsor owns the data and should be able to take all of it at any time: every case, every form version, every audit entry, in a documented format, on request. If the vendor would have to build that export when asked, the sponsor does not really control its own data.

Retention rules belong in writing from the start: how long the data is kept, what happens to identified data when the registry closes, and who decides. Agree on that at the beginning, not when the registry is winding down. And the documentation has to be good enough that the new coordinator in year eight can learn the system from what is written, not from whoever is left.

How Skye Road handles this

We built a shoulder surgery registry for an implant manufacturer that started from nothing, with protected health information in scope and an expected life of five to ten years. It runs in the client's own cloud environment under a Business Associate Agreement, with case capture and validation, follow-up tracking, role-based access, an audit trail of who entered and changed what, and de-identification built into the reporting layer so analysis never needs identified records. The clinical results belong to the client. The case study has the outline, our security page has the controls, and the healthcare page has the rest of what we build. We are engineers, not counsel, and the regulatory and privacy decisions above belong with yours.

The bottom line

A registry is a ten-year promise to collect the same data the same way while everything around it changes. The software is what keeps that promise. Decide the purpose, design around the form, make follow-up the center of the product, build for change, keep patient data where it belongs, and hand clean files to the people who will analyze them. Do that and the registry will still be answering questions long after the people who started it have moved on.