FHIR-Native Application Development
Building applications where FHIR resources are the primary data model rather than mapping to it at an interface boundary, which simplifies exchange later.
Custom Software
Hire Medplum Developers
Medplum developers build healthcare applications on Medplum’s open source FHIR-native platform, either self-hosted or through its managed service. They work with its FHIR data model, access policies, bots, and subscriptions, and they handle the operational responsibility self-hosting carries.
The platform suits teams building clinical applications who want FHIR as the native data model rather than as an interface layer over something else. Being open source means self-hosting is genuinely available, which is valuable for residency requirements and carries operational obligations teams sometimes underestimate. Taction Software is not a Medplum partner or reseller. Our hire dedicated developers hub covers adjacent roles.
Tell Us Your Requirements
Our experts are ready to understand your business goals.
Trusted Partners
Trusted by Industry Leaders Worldwide
Recognition
Awards & Recognitions
What Medplum Developers Build
Work concentrates on building clinical applications with the platform as the record backend, extending it where product requirements exceed what it provides. The work below reflects that, alongside the interface practices in our FHIR API development work.
Access Policy Implementation
Configuring policies that determine what each user and application may reach, since this is the platform’s access control mechanism and must be designed deliberately.
Bot and Automation Development
Building server-side logic that runs on resource changes, which handles the workflow automation clinical applications need without external services.
Subscription and Event Handling
Using subscriptions to trigger downstream processing on resource changes, with the idempotency event-driven processing requires.
External System Integration
Connecting to labs, EHRs, and partner systems, following approaches in our healthcare integration services.
Self-Hosted Deployment and Operations
Deploying and operating the platform in your own infrastructure where residency requires it, including upgrade, backup, and availability management.
Platform Context This Role Requires
The platform’s characteristics cut both ways. FHIR-native modeling simplifies interoperability and constrains how you represent data that does not map cleanly. Open source enables self-hosting and transfers operational responsibility. The context below spans the healthcare work you assign.
01
FHIR Modeling Constrains Product Data
Data without a clean resource representation requires extensions or separate storage. That constraint is worth accepting deliberately rather than discovering later.
02
Access Policies Are the Security Model
Policy design determines what users reach. Poorly scoped policies expose more than intended, and the mechanism requires deliberate design rather than defaults.
03
Self-Hosting Transfers Operational Burden
Running the platform yourself means owning upgrades, availability, backup, and scaling permanently, which is real cost beyond infrastructure.
04
Open Source Means Reading the Code
Behavior can be verified in source rather than inferred, which is genuinely useful and requires developers willing to do it.
05
The Platform Is Not an EHR
It provides record infrastructure rather than clinical workflow. Applications supply the workflow, which is the point and shapes build scope accordingly.
06
Managed Service Removes Operations, Not Design
Using the hosted option eliminates infrastructure work without removing access policy design or data modeling responsibility.
Technical Skills This Work Requires
The differentiating skills are FHIR modeling and access policy design rather than platform API familiarity. The competencies below reflect that, with verification consistent with our quality assurance approach.
FHIR Resource Modeling
Representing clinical and product data as resources with appropriate profiles and extensions, since modeling decisions here shape the entire application.
Access Policy Design and Testing
Building policies that scope access correctly per user and application, with testing that verifies what they permit rather than assuming intent.
Bot Development and Testing
Writing server-side automation with error handling and idempotency, since bots triggered by resource changes run under conditions that repeat.
Subscription Architecture
Designing event-driven processing with duplicate tolerance, since delivery guarantees mean handling repeats rather than assuming single delivery.
Self-Hosted Operations
Deploying, upgrading, backing up, and scaling the platform where self-hosting applies, following practices in our HIPAA engineering guidance.
Application Layer Development
Building the clinical workflow above the platform, since it supplies record infrastructure rather than the user-facing functionality your product needs.
How We Evaluate Medplum Developers
The distinguishing question is how they tested access policies. Developers who verified what policies actually permit found gaps; those who wrote them and assumed correctness may have exposed more than intended. Our assessment centers on policy testing and FHIR modeling. Our delivery process includes review points where you can reassess fit.
Access Policy Verification
We ask how they tested what policies permitted. Developers who assumed intent rather than testing may have granted access beyond what was designed.
FHIR Modeling Decisions
We ask about data that did not map cleanly. Developers who forced everything into resources or abandoned FHIR modeling both created problems.
Self-Hosting Operations Experience
We ask what running the platform involved. Developers who only used the managed service have not confronted upgrade and availability responsibility.
Bot Idempotency Handling
We ask what happened when a bot ran twice. Non-idempotent automation triggered by resource changes creates duplicate effects that are difficult to unwind.
Source Code Investigation
We ask about behavior they verified in the code. Developers who never read source treated an open platform as a closed one.
Verified Platform Experience
We describe which applications each developer built on the platform. We do not claim partnership or certification for Taction or for engineers.
Engagement Options for Platform Work
Engagements should settle self-hosting versus managed early, since that determines operational scope. Structures below reflect that, and our engagement models accommodate project or ongoing arrangements.
Hosting Decision and Data Modeling First
Determining whether self-hosting is required and how your data maps to FHIR resources, since both shape everything built afterward.
A Single Developer for Application Build
Suits building one clinical application on the platform with defined workflow requirements and a settled hosting approach.
Developer With Infrastructure Support
Where self-hosting applies, pairing addresses deployment, upgrade, and availability work that application development does not cover.
Augmenting Your Product Team
Where you own the platform decision, staff augmentation adds development capacity within your existing conventions and policies.
Full Team for Clinical Product Builds
A dedicated healthcare development team suits building a complete clinical product where platform, application, and integration work run together.
Fixed-Scope Application Delivery
Where requirements and hosting are defined, a fixed-scope build delivers the application with access policies, integration, and documentation.
Tell Us Whether You Must Self-Host
Share your residency requirements and operational capacity. Self-hosting is genuinely available and carries permanent responsibility worth deciding deliberately.
Access Control, Data Modeling, and Boundaries
The platform holds clinical data and its access policies are the security mechanism, which makes policy design substantive. We build to HIPAA-aligned practices where HIPAA applies; software cannot be HIPAA certified. Clinical determinations remain with clinicians regardless of what applications present.
01
Policies Tested, Not Assumed
Access policies are verified against what they actually permit, since a policy written with correct intent can grant broader access than designed.
02
Resource-Level Restriction for Sensitive Data
Behavioral health and similar content requires restriction at resource level. We built CHIPSS, a behavioral health system, where such segmentation was foundational.
03
Self-Hosted Environments Governed as Clinical
Where you host the platform, it receives clinical-grade access control, encryption, backup, and audit rather than general application infrastructure treatment.
04
Audit Logging of Record Access
Access to clinical resources is logged in a form supporting investigation, which the platform provides and applications must not bypass.
05
Clinicians Author Clinical Content
The platform stores what applications write. Clinical content and determinations belong to the clinician, with attribution recorded accordingly.
06
Applications We Would Not Build
We would not build applications bypassing access policies with elevated credentials, storing clinical data outside audit coverage, or making clinical determinations.
Cost to Hire Developers and Build
Cost tracks application scope and hosting choice rather than platform complexity. Self-hosting adds infrastructure and operational cost permanently. We publish no figures on development speed, because those depend on your product requirements.
MVP or Single Module
$40,000 to $80,000
One clinical application with FHIR data modeling, access policies, bots where needed, and integration into one external system.
Full Platform Build
$80,000 to $200,000
Complete clinical product with multi-resource modeling, policy architecture, automation, subscriptions, external integration, and self-hosted deployment where required.
Enterprise Deployment
Starting at $200,000
Multi-tenant or multi-facility deployment with isolation, governance documentation, self-hosted operations, and integration across several environments.
Discovery Phase Scoping
Discovery is paid and time-boxed. It produces a hosting recommendation, FHIR modeling assessment, access policy design, and an itemized fixed-scope estimate.
Cost Drivers to Expect
Application scope, FHIR modeling complexity for non-standard data, access policy granularity, self-hosting operational requirements, and external integration count.
Ongoing Support Costs
Self-hosting carries permanent operational cost. Budget for upgrades, availability management, backup verification, and platform version tracking.
Third-party licensing, cloud infrastructure, data subscriptions, and hardware are separate from engineering cost and itemised clearly.
Why Build on This Platform With Taction
Two questions matter. Whether the developer tests access policies, and whether they scope self-hosting responsibility honestly. Taction Software has built healthcare software since 2013, more than twelve years, with over 200 healthcare projects delivered and ISO 27001 certification. Leadership brings more than twenty years of personal experience in the field, which is separate from company age.
No Vendor Relationship Shaping Advice
We are not a Medplum partner or reseller. Our platform recommendations follow your requirements rather than a commercial arrangement.
We Built a Record Platform
We built Voyant Health, an EHR platform, which means we understand clinical data modeling rather than accepting resource structure without examination.
Sensitive Access Experience
We built CHIPSS, a behavioral health system, where resource-level restriction governed access, which is exactly what policy design must achieve.
ISO 27001 Certified Security Management
Taction Software holds ISO 27001 certification covering our information security management practices, described under our certifications and compliance information.
We Test What Policies Permit
Access policies are verified against actual behavior rather than intent, which regularly reveals broader access than the author expected.
We Will State the Self-Hosting Commitment
Running the platform yourself is permanent operational responsibility. We say that before you commit, which occasionally redirects teams to the managed option.
FAQs
Frequently Asked Questions
We settle hosting approach and assess how your data maps to FHIR resources, then present developers with platform experience for your approval.
One application runs $40,000 to $80,000, a complete product $80,000 to $200,000, and multi-tenant deployment starts at $200,000. Hosting and infrastructure are itemized separately.
No. We are not a partner or reseller. We build on the platform as any developer does, so recommendations carry no commercial incentive.
Self-host where residency requirements demand it and you have operational capacity. The managed option removes infrastructure responsibility without removing data modeling and policy design.
No. It provides FHIR-native record infrastructure. Clinical workflow comes from the applications you build on it, which is the point of the architecture.
FHIR developers build interfaces and servers generally. This role builds applications on one platform where access policies, bots, and its data model shape the work.
Share your residency requirements, operational capacity, product scope, data that may not map cleanly to FHIR, and the engagement model you have in mind. We will state self-hosting responsibility plainly before you commit. We do not promise instant matching or guaranteed availability.