Even in modern healthcare products, patient intake is often where the experience starts to feel manual again. Patients are asked to repeat information they already provided elsewhere. Staff members still reconcile incomplete records, insurance details, consent forms, payment preferences, and clinical context across disconnected tools. The result is a workflow that may be digital on the surface but remains operationally heavy behind the scenes. 

This is a common challenge faced by specialty care providers, digital health firms, and healthcare teams. Usually, the aim isn't to overhaul everything but to enhance the aspects of the intake process that cause the most friction for patients, providers, and operational teams.

That is where a more modular approach comes in: building a paperless intake experience around the pieces that matter most, from collecting health information and consent to validating insurance, supporting payment logic, and making patient data easier to reuse and share.

In our Health Builders Jam, we walked through this intake solution live: the full session recording is available below.

Watch: paperless intake in practice

‍

In this session, Vinta's CPO and CTO walk through the complete intake flow live, from verified login and SMART Health Link import to insurance eligibility, coded medical history, consent, and how everything lands in Medplum as structured FHIR. The sections below go deeper into each piece of the architecture.

An open-source layer for patient-shared data

For intake to become truly paperless, patient information needs to do more than move from paper into a web form. It needs to become structured, reusable, and easier to exchange across the care journey. 

That is the direction behind CMS’s Kill the Clipboard initiative: reducing repetitive data entry and making health information easier to access, share, and use through standards-based flows.

Building on our goal of promoting a fully paperless intake process, we've created an open-source TypeScript library called Kill the Clipboard. It's designed to enhance an important part of the experience by making it easier to transform structured patient data into information that patients can safely access and share via SMART Health Links, SMART Health Cards, and QR codes.

Throughout this article, we will demonstrate Vinta’s intake solution to illustrate a paperless workflow. The aim is to present a real-world case, not just a library demo, as part of a comprehensive product experience that providers and healthcare organizations can customize to fit their care models and operations.

The video below shows how the full experience comes together: patients move through a guided intake flow.

‍

We’ll walk through how Kill the Clipboard works and where it fits into our patient intake. We’ll also go under the hood of our solution to show how paperless intake works beyond the sharing layer, from helping patients bring existing health information into the flow.

Want to talk through how this applies to your reality
Get in touch with our specialists.

A product-ready foundation for patient intake

As a healthcare-focused software boutique, Vinta often partners with care providers to improve patient intake flows. In practice, the challenge usually goes far beyond capturing form fields. Providers need to bring health records into the workflow, manage consent, validate insurance information, support payment decisions, reduce repetitive data entry, and streamline intake for both patients and staff.

Based on our experience building healthcare products, we mapped the core capabilities behind a strong modern intake flow and turned them into a modular patient intake solution. Instead of starting from a blank slate, healthcare organizations can use this FHIR-native foundation to add a ready-made intake flow to their product and customize the components that need to reflect their care model, operations, and patient experience.

It offers a faster path than building everything from scratch while remaining more flexible and product-specific than relying on rigid, off-the-shelf EHR workflows.

A common intake hurdle is that patients are asked to manually enter health information that may already exist elsewhere. This creates friction for patients and extra reconciliation work for staff. A better intake experience should help patients bring relevant health information into the workflow while keeping the process clear, guided, and transparent.

This is where the broader CMS Interoperability Framework becomes especially relevant. The framework points to a healthcare ecosystem in which patient information can be retrieved across networks via standardized access patterns, with aligned networks expected to support FHIR APIs and TEFCA-aligned networks.

In our intake solution, this paperless experience starts when the patient chooses to import health data. The workflow prompts for basic identifying information so the system can look for available records from connected sources, such as health information networks or other record-retrieval infrastructure.

Insurance and payment, fully integrated behind the scenes

Insurance and payment are often where intake friction becomes most visible. Before care begins, patients may need to provide insurance details for an eligibility check or add a payment method for future billing. Depending on the care model, this can include submitting an insurance card, confirming payer information, authorizing a co-pay, or providing payment details.

That step can break down quickly. Missing patient information, incorrect payer details, inactive coverage, unclear co-pay expectations, eligibility issues, and disconnected payment flows can all turn intake into operational work, billing delays, denials, and patient frustration.

In our intake process, if patients opt to use insurance, the workflow includes capturing the insurance card, parsing plan details, verifying eligibility, and collecting co-pay when needed. If they choose to proceed without billing insurance, the flow captures payment information for future authorization or billing.

Designing the interface, mapping the user flow, and defining how each intake step should work are already complex challenges. But patient intake goes beyond the visible experience. It also depends on the workflow logic behind insurance capture, payment preferences, eligibility checks, validation, patient data, and the broader provider journey.

Starting from a functional, FHIR-native foundation gives healthcare teams a faster and more reliable path to implementation. It reduces the time spent on development, stabilization, and FHIR modeling and mapping, which usually sit behind intake. Instead of rebuilding this complexity from scratch, teams can focus on adapting the experience to their care model, operations, and business needs.

Structured FHIR data for provider workflows

A paperless intake flow is only useful if the information collected can actually support the provider workflow. That means intake data should not live only as a PDF, a disconnected form submission, or a static record that staff still need to interpret manually. It should be structured to make it easier to review, validate, route, and eventually connect with the systems the care team already uses.

This is why our approach treats intake as part of a broader operational flow. The patient-facing experience matters, but so does what happens after submission: staff visibility, tracking of incomplete sections, reminders, structured review, and the ability to connect the intake record to EHR or provider-side workflows.

FHIR also matters here. By structuring health data around modern interoperability standards, intake becomes easier to integrate, reuse, and extend across different product architectures.

This is where the intake solution becomes more than a nice form. It becomes a foundation for better patient onboarding, cleaner operational handoff, and more reliable downstream workflows.

Paperless intake, aligned with modern interoperability standards

The final step brings the paperless intake experience back to the patient. Once the patient’s information is collected and structured, the intake solution should generate a SMART Health Link and QR code connected to the health information they entered during intake. Instead of ending intake as a one-time submission, that information becomes easier to access and share across future care interactions.

At the end of the flow, patients receive a unique SMART Health Link, a passcode, and a QR code. This gives them a practical way to share their information again, whether with another provider, another system, or a care team that can view the data through a compatible experience.

This is where Kill the Clipboard fits directly. The open-source library helps implement the QR-based sharing layer using SMART Health Cards, SMART Health Links, and FHIR-based data exchange.

That is the value of Vinta’s intake solution. It provides healthcare organizations with a faster, more predictable foundation for launching modern intake flows while maintaining enough flexibility to accommodate different care models, operational rules, and patient journeys.

Building on this foundation

Patient intake does not become better just by turning forms into screens. The real improvement comes from connecting the pieces that usually stay fragmented: records, consent, insurance, payments, structured data, patient-shared health information, and the provider workflows around them.

In our Health Builders Jam, we walked through how these components work together, from the patient-facing experience to what lands in the provider's system as structured FHIR. The full session is available above.

If your team is working on patient intake and wants to talk through how this foundation could apply to your product, we're happy to get on a call.

Want to talk through how this applies to your reality
Get in touch with our specialists.

FAQ - Frequently Asked Questions

At the end of the session, we opened the floor for questions. The Q&A covered some common points that come up when teams start thinking about building or adopting a paperless intake flow.

Q: What authorization and access controls ensure you can only fetch the right patient's data? How do you handle consent and HIPAA requirements?

Flavio: If this is about the SMART Health Link, the link holds the data that the patient chooses to share. In the workflow we demonstrated, we generate a full SMART Health Link — but the plan is to provide a patient portal where patients can create different links with different subsets of their data. That way, a patient can share specific information with one provider and a different subset with another.

SMART Health Link is a standard — not something we invented. CMS is actively pushing healthcare organizations to implement it. The protection mechanism is the passcode, and the link itself can be cryptographically secured with verifiable information baked in. What gets shared is ultimately controlled by the patient.

On HIPAA compliance: that comes down to making sure the entire software stack is compliant. Everything we use — databases, infrastructure — needs to meet that bar. Medplum, for example, is a certified EHR and is HIPAA compliant from day one if you use their cloud offering. Vinta is also a Business Associate and works with covered entities. It's about getting both the infrastructure side and the compliance side right.

Q: In our intake flow, patients only enter payment information at checkout, after the service is provided. Can the workflow be customized to support that order of steps?

Flavio: Yes. What we showed is a sample — we can support different workflow configurations. The eligibility check and the credit card step are both flexible. In the demo, we're not charging the card directly; it's a pre-authorization only. But since we're using Stripe, we can trigger a charge at any point in the workflow, depending on how the provider side is set up.

Lais: To complement that — our vision is that intake as a whole is a module, and each step within it is also a module. Everything is composable: you can rearrange steps, remove them, or customize them to fit your flow. We built it to be comprehensive, but if your flow has fewer steps, that works too. Flavio mentioned we're not charging at intake in this example, but if your service has a fixed price, we could charge then. Co-pay is also a flow we're planning to cover.

Flavio: And in terms of how quickly we can adapt the modules — we use AI to help accelerate customization, always with code review and a focus on quality. In technical terms, everything is built as true building blocks: we have a design system, all components are independent, and they can be combined in different ways.

Q: In your Stedi integration, are you using coverage eligibility or discovery?

Flavio: Right now we're using real-time eligibility check.

Q: I already have my own FHIR server and EHR. Can we use just the paperless intake flow as a front end sending data to our existing backend?

Flavio: Yes. This is a FHIR-native frontend, compatible with any FHIR-compliant backend. If you have another FHIR-compatible EHR, we can write to it. There may be some edge cases — certain resources used in this intake example might not be writable in some of the larger EHRs — but the core patient information is generally writable, and that's enough to power an intake flow on more traditional EHR systems.

If you already have a FHIR server, we can use that instead of Medplum. We recommend Medplum when teams are building the full patient-provider experience, because it's open source, has a cloud offering that accelerates infrastructure setup, and comes HIPAA compliant out of the box. But if you have your own FHIR server, we can build on top of that instead.

‍