C# and .NET in Healthcare Software: 
Where the Microsoft Stack Shows Up in Clinical Systems

If a radiation therapy department wants its plan-approval checks automated, someone in that department writes the automation, and it runs on Microsoft .NET. RayStation's scripting interface uses IronPython with direct access to .NET and Windows Presentation Foundation. Anything too specific to one clinic to ship inside the product tends to end up there.

That is one of three places C# healthcare software shows up in the clinical stack. Microsoft's open-source FHIR Server implements HL7 FHIR in .NET, down at the interoperability layer. The Firely .NET SDK sits above it, at the library layer. RayStation's scripting interface sits at the top, nearest the clinic. Every layer asks something different of the team that picks it, and plenty of teams commit to all three under the impression they made one decision.

Three layers of the Microsoft stack in healthcare software: the interoperability layer (Microsoft FHIR Server for Azure), the library layer (Firely .NET SDK) and the automation layer (RayStation scripting on IronPython and .NET).

Microsoft's FHIR Server for Azure is published as open source. The repository describes it as a .NET Core implementation of the HL7 FHIR standard designed for the Microsoft cloud, and it states that the platform-as-a-service FHIR servers offered in Azure are backed by that same open-source project.

That lineage does practical work for an engineering lead. Reading the implementation behind a managed service changes three ordinary tasks:

• Evaluation. The behaviour of the service can be checked in source before a contract gets signed, rather than inferred from a datasheet.
• Debugging. A surprise in production traces back to a commit instead of a support thread.
• Local work. The server runs on the team’s own infrastructure for development and testing, on the same codebase.

Healthcare infrastructure sold as a managed service rarely arrives with that option attached, which makes it worth weighing before the vendor comparison closes.

Teams doing FHIR .NET work can start by reading the repository itself: github.com/microsoft/fhir-server. The interoperability layer is also where a stack decision stops being only a stack decision. Interoperability requirements, security review and compliance evidence land on the same architecture, and they land here first.

The Firely .NET SDK is Firely's official SDK for working with HL7 FHIR on the Microsoft .NET platform, providing parsing, serialization, validation, profiling and FHIRPath support. It is a C# codebase; the solution file lists projects such as Hl7.Fhir.Core, Hl7.Fhir.Serialization and Hl7.Fhir.Specification. Broken out, the SDK covers:

• Parsing and serialization of FHIR resources in JSON and XML
• Validation and profiling against the specification and against custom profiles
• RESTful API calls against a FHIR server
• FHIRPath evaluation
• Support for STU3, R4, R4B and R5

A team building C# medical software either writes that layer or inherits it. The two paths cost different things.

The question looks like architecture on the slide and gets settled as staffing in the budget. That is the frame most engineering leads are already working in, and the library layer is where the two meet most directly.

Firely also publishes usage figures for the SDK on its own site. Vendor self-description belongs in a technical evaluation with the attribution attached, or it belongs out of the evaluation. The repository is at github.com/FirelyTeam/firely-net-sdk.

RayStation is a treatment planning system for radiation therapy, in use at cancer centres internationally. RaySearch's white paper on RayStation scripting states that the scripting language is IronPython, a Python variety that allows access to .NET, and that scripts use an interface to Microsoft .NET and Windows Presentation Foundation to:

• create windows with graphical components
• generate PDF reports
• drive other scriptable applications

The same white paper describes what clinics do with that interface. It points to checklists executed manually at stages in the clinical process, and it gives quality-related properties checked in a plan before approval as its own example. Those procedures vary by clinic and cannot be fully supported out of the box, so scripting is where clinic-specific versions of them get built.

The person writing that code is often a clinical physicist rather than a software engineer. The surface they write against is the .NET runtime, inside a product carrying regulatory obligations. Stack evaluations rarely account for that reader, and in radiation oncology departments that reader does a large share of the automation.

Why RayStation belongs at the automation layer

The documented relationship covers the scripting interface. RaySearch's white paper describes how scripts reach .NET and Windows Presentation Foundation. It does not describe what RayStation itself is implemented in, and no primary source consulted for this post does. So the supportable claim is that RayStation's automation surface runs on .NET. The claim that RayStation is a .NET application stays unmade.

The line the automation layer sits on, and the side of it RayStation is documented on.

Reading the second as the first is how a technology inventory fills up with confident entries that no source supports. Anyone building a stack case internally will be asked for sources, and the person asking usually starts with the most surprising line on the page.

Three layers, three commitments. The interoperability layer settles what a team can inspect in the infrastructure it depends on. The library layer settles how much of the FHIR specification the team owns as code. The automation layer settles who writes clinical automation, and against which runtime. A stack choice that treats the three as one decision gets defended later with claims that no source supports.

Softwarium is a software engineering and IT staff augmentation company with twenty-five years of delivery behind it and engineering micro-hubs across Europe. Its Microsoft stack record in regulated environments includes a customized SharePoint build for a life science organisation, where regulatory constraints set the architecture before feature scope did. The pattern matches the three layers above: compliance requirements arrive early and narrow what the engineering team gets to choose.

Healthcare engineering leads reach that kind of engagement at one of two moments.

• Capacity. A dedicated development team or distributed engineers join an existing product group and work inside the client’s process.
• Compliance boundary. A co-managed engineering team takes work with regulatory constraint running through it, while the client keeps architectural control and engineering capacity scales without a hiring cycle.

In healthcare, architecture and headcount move together. A team that inherits FHIR handling still needs engineers who have read the specification closely enough to debug a validation failure. A team that writes its own needs more of them, for longer, and needs them to stay.

Engineering leads comparing a healthcare software development company for Microsoft stack work can start with Softwarium's healthcare engineering practice.