Modernizing the healthcare enterprise, A beginners guide for startups

The healthcare industry is huge — literally. It concerns every one of us who has ever existed and ever will exist.

Over the years, the industry has undergone sweeping changes. The flow and ebb of human technology and scientific progress remain deeply intertwined with the fate of the healthcare sector. And yet, despite entering the digital age in the 1970s, why does it still feel like the healthcare industry is firmly rooted in the past?

Truth be told, healthcare is a different beast.

Surrounded by laws and regulations, the Silicon Valley “move fast, break things” mentality simply doesn’t work here cough cough, Theranos. A rough analogy: if we accidentally drop a database table in a social media startup, we’re just ruining someone’s cozy night-in binge-watching Netflix. In healthcare, we might quite possibly be killing a patient. There are real risks involved.

The good news? You don’t have to modernise healthcare — it’s already been done. All the interoperability standards and technologies have been developed, standardised, and are in use today.

The bad news? There’s a lot — like, a metric truckload of things you’ve got to know.

Since this is more of a blog article than a reference manual, we’ll only focus on the bare basics. Otherwise, we’d be here a while.

Part 1: First things first. The standards, the words, the jargon

• IHE
• FHIR
• HL7
• DICOM
• EHR
• PACS
• SNOMED CT

Healthcare industry really loves their acronyms all right. Lets break them down. There’s a lot more, but this should be enough to get you going. DICOM, HL7, IHE, FHIR and PACS are especially important — if you’re planning to do anything patient facing that is.

IHE: The playbook

IHE stands for Integrating the Healthcare Enterprise. You can think of IHE like the rulebook for how different standards interact with each other. There are many different standards of information interchange in the healthcare industry. IHE ensures interoperability between the standards.

Example scenario

Say two hospitals want to share patient medical documents securely

IHE XDS.b

defines how to store and share clinical documents ( like discharge summaries or lab reports ) using standard formats ( FHIR, DICOM, etc)

Step Actor IHE Role Description 1 Hospital A Document Source Publishes a clinical summary as a CDA XML document to the repository. 2 Repository Document Repository Stores the document and sends metadata to a registry. 3 Registry Document Registry Indexes metadata (patient ID, author, date, document type). 4 Hospital B Document Consumer Searches registry for patient documents and retrieves them from the repository.

IHE defines the workflow and roles; it reuses HL7 CDA for document format.

HL7: The language

You may be thinking okay, so not JSON or XML or something simple? They just had to invent something of their own. Well no. Not exactly. Think of JSON or XML as the medium of language. When humans talk, its over sound. But there can be different languages. HL7 is kind of like that.

Example scenario When a patient is admitted to the hospital, the Admission/Discharge/Transfer (ADT) system sends a message to the EHR to register the patient.

The following is an extract from a message that would be transmitted. The following is a message from the HL7 v2 standard.

MSH|^~\&|SENDING_APPLICATION|SENDING_FACILITY| RECEIVING_APPLICATION|RECEIVING_FACILITY|20110613083617||ADT^A01|934576120110613083617|P|2.3||||
EVN|A01|20110613083617|||
PID|1||135769||MOUSE^MICKEY^||19281118|M|||123 Main St.^^Lake Buena Vista^FL^32830||(407)939-1289^^^theMainMouse@disney.com|||||1719|99999999||||||||||||||||||||
PV1|1|O|||||^^^^^^^^|^^^^^^^^

MSH — Message header ( contains metadata ) EVN — Event type ( A01 means admit/visit notification)

You get the idea. I’m not going to list everything in the spec here.

FHIR: HL7 on steriods

FHIR was developed by HL7 to fit into the modern web standards.

Now dear reader, you may be thinking, “Hold on, you told us that HL7 is a standard. How can a standard develop another standard?!??”. Ahh.. yes. I lied. HL7 is also a standard and a standards development organisation.

It uses RESTful APIs, JSON/XML, and OAuth2 — just like web apps and mobile services today.

The only thing you have to keep in mind at this stage is that everything is a Resource to the FHIR spec. Patient, Observation, Appointment, Medication, they're all a Resource. FHIR also names standardised endpoints such as /Patient/123 or /Observation?patient=123. Yes keen observer, it also supports URL Search parameters. How cool is that ?

HL7 v2 is still used in a lot of hospitals to this day by the way. But newer installations tend to focus more on FHIR.

Okay lets look at an example and get a better idea.

Lets GET some patient info. The patient ID will be 47958444. ( You can actually try this yourself. HAPI is a fully FHIR compliant backend coded in Java. They have some dummy data for testing )

GET http://hapi.fhir.org/baseR4/Patient/47958444

Here’s the response

{
 "resourceType": "Patient",
 "id": "47958444",
 "meta": {
   "versionId": "1",
   "lastUpdated": "2025-06-19T19:28:45.469+00:00",
   "source": "#VuociAlICXqhYDiI"
 },
 "text": {
   "status": "generated",
   "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><div class=\"hapiHeaderText\">Nuñez <b>KARLA </b></div><table class=\"hapiPropertyTable\"><tbody><tr><td>Date of birth</td><td><span>02 January 1980</span></td></tr></tbody></table></div>"
 },
 "name": [ {
   "family": "Karla",
   "given": [ "Nuñez" ]
 } ],
 "gender": "female",
 "birthDate": "1980-01-02"
}

DICOM: The language of images. And getting them places.

DICOM is both a file format standard and a communication protocol for storing and transmitting medical images. DICOM ensures that all medical imaging equipment can speak the same language, much like what HL7 and FHIR does for text based data. A DICOM file might contain both pixel data and metadata regarding patient name, patient ID, age, etc..

DICOM files have the filetype .dcm

See? Just like a PDF. Simple. Well.. If PDF also had a communication protocol but you get the idea.

What about the DICOM protocol? DICOM uses a client-server model where systems communicate using the DICOM protocol over TCP/IP.

Key services include:

• C-STORE — Upload (store) an image to another system (e.g., from scanner to PACS).
• C-FIND — Query for patient or study information.
• C-MOVE — Request image transfer to another device.
• C-GET — Retrieve images.
• C-ECHO — Test communication (similar to a “ping”).

These sound like HTTP’s GET and POST but don't be fooled. Remember, HTTP works on top of TCP/IP and likewise, DICOM also works on top of TCP/IP. There's no HTTP in between DICOM and TCP/IP. DICOM procotol sends data in binary over TCP/IP.

Confused? Hold on a bit.

What are DICOM service classes?

In DICOM, a Service Class defines a type of operation or workflow that one device (a Service Class User, SCU) can perform with another device (a Service Class Provider, SCP).

And each service class, has their own DICOM commands. For example,

Service Class Purpose Typical Commands (Operations) Storage Service Class Store images or data objects on a remote system (e.g., scanner → PACS). C-STORE   Query/Retrieve Service Class Search and retrieve patient/study/image data from PACS. C-FIND, C-GET, C-MOVE

Okay those are the 4 elephants in the room. We’ll rapid-fire the rest since they’re not that hard to grasp

PACS: The image library

PACS is a software system (and storage server) used by hospitals to store, retrieve, distribute, and view medical images.

It uses the DICOM standard for all its image storage and communication. Its basically a glorified hard drive for DICOM images.

EHR: The recordbook

EHR stands for Electronic Health Record. It stores patient health information — diagnoses, medications, allergies, lab results, etc…

The EHR uses all the protocols listed above to achieve its task. It uses FHIR for communicating with servers to get the health data. It uses PACS to store the lab imaging. It uses DICOM to read, transmit and process the images.

SNOMED CT: The dictionary

This is just the global standard terminology for clinical terms (diseases, symptoms, findings)

Go on now. Create a health-tech startup

Just kidding. This is just the beginning of your journey. You’ll need to learn a lot more than this. But this’ll get you going. Run along now.

Part 2: So You Want to Build a Health-Tech Startup (For Real This Time)

Alright, so now you know your FHIRs from your DICOMs and your PACS from your SNOMEDs. But theory only gets you so far. Let’s get our hands dirty. How do you actually build something in healthcare that works — and doesn’t accidentally summon the compliance gods?

Step 1: Pick Your Battlefield — or in Plain English, Your Use Case

The healthcare universe is massive. Don’t try to build an EHR from scratch on day one (that’s like deciding your first coding project will be “Windows 12”). Instead, find a focused niche:

• Appointment scheduling for clinics
• Patient lab report viewers
• Medical image sharing between doctors
• AI-powered symptom checker

Each of these uses a subset of the standards you just met. Knowing which ones matter saves you months of headache.

Step 2: Get a FHIR Server Up and Running

FHIR is the heart of modern health data exchange. The easiest way to start is to use a ready-made open source FHIR server. The HAPI FHIR server (Java) is the go-to option.

You can:

• Spin it up locally with Docker:
  docker run -p 8080:8080 hapiproject/hapi
• Or use their public test instance at
  https://hapi.fhir.org/baseR4

Once it’s up, you can hit it with REST calls like:

GET /Patient/123
POST /Observation

Congratulations, you just spoke fluent healthcare.

If you’re a Python person, check out fhir.resources or fhirclient.They help you work with FHIR objects natively.

Step 3: Handle Authentication Like an Adult

If you’re building a health app, OAuth2 and OpenID Connect are your new best friends. Why? Because healthcare systems don’t hand over patient data to “random app from the internet dot com.”

Most modern FHIR servers integrate with SMART on FHIR, an authentication layer built on top of OAuth2. It standardizes how apps get access tokens and permissions (called scopes), like:launch/patient
patient/*.read
patient/Observation.write

You’ll need to register your app, handle redirects, and exchange authorization codes — just like you would with Google or GitHub login. Except this time, you might be logging in through a hospital’s Keycloak instance.

Step 4: Play Nice with Legacy Systems

Let’s face it — most hospitals are still running ancient systems that look like they were built on Windows 95. They speak HL7 v2, not FHIR. You’ll need a translator.

Enter: Integration Engines.

Tools like Mirth Connect, OpenHIM, or NextGen Connect can transform HL7 v2 messages into FHIR resources.

Think of them as the universal plug adapter between old and new healthcare tech:HL7 ADT^A01 (Patient Admitted)
  ↓
FHIR Patient + Encounter Resources

With this bridge, your shiny modern web app can talk to hospital software from 2003 like they’re old buddies.

Step 5: Respect the Rules — Privacy & Compliance

Healthcare isn’t like fintech or social media. Here, privacy is law, not preference.

Depending on where you operate:

• In the US, it’s HIPAA
• In the EU, it’s GDPR + MDR
• In Sri Lanka or India, it’s PDPA-style local laws Every country has its own flavor, but the gist is the same: don’t leak patient data.

Use:

• HTTPS everywhere
• Encrypted storage (AES-256 or bust)
• Audit logs (FHIR even has an AuditEvent resource!)
• Access control (FHIR supports Consent resources for this)

Trust is your most valuable currency in healthcare. Lose that, and you’re done.

Step 6: Testing in the Wild

Before you even think of touching real patient data, use sandbox environments.

A few free ones:

• HAPI FHIR Public Test Server
• Google Cloud Healthcare API Sandbox
• Microsoft Azure FHIR Server Sandbox
• Inferno Test Suite — to check your FHIR compliance.

These let you experiment safely and verify that your app’s FHIR implementation actually matches the spec (because trust me, hospitals will test that).

Step 7: Ship, But Don’t Sink

Once your prototype works, don’t just “move fast and deploy to production.” Remember: healthcare data is regulated data.

• Pen test your system (and fix what breaks).
• Version your FHIR resources — healthcare data changes, and you’ll need audit trails.
• Monitor uptime — missing a few API calls is one thing, missing a patient’s allergy info is another.

If your app survives this stage without catching fire, congrats. You’re no longer just “building in healthcare.” You’re building for human lives.

Next Steps

From here, you can explore:

• LOINC for lab codes
• OMOP/CDISC for research data
• IHE ATNA for audit trails and security
• FHIR Subscriptions for event-driven updates
• Terminology Servers for SNOMED CT and friends

But that’s for another day. For now, get your FHIR server running, hook up some dummy patients, and start building.

Healthcare is complicated — but with the right tools, you can actually make it better.

Till next time 👋

This article was also published on the Medium