Hospital Information Systems: Components, Interoperability and How to Modernise

Hospitals are among the most complex organisations to support with software. A single patient visit touches registration, scheduling, clinical documentation, orders, laboratory and imaging results, pharmacy, billing and often insurance. A hospital information system (HIS) is the collection of software that supports this work — ideally as a connected whole.

This guide explains the components, standards and obligations that shape hospital software, and how to approach modernisation. It is written for technology and operations leaders, not as clinical or legal advice.

What a hospital information system includes

How the pieces fit together

In practice, few hospitals run one system for everything. A typical landscape has a core EHR and patient administration platform, departmental systems for laboratory, imaging and pharmacy, a billing system and various specialist and patient-facing applications. An integration engine or API layer routes messages and data between them.

The quality of these connections determines whether clinicians see a complete picture or chase information across screens. Duplicate patient records, delayed results and manual re-entry are often integration problems rather than failings of individual modules.

Interoperability standards

• HL7 version 2 messaging remains widely used inside hospitals for admissions, orders and results.
• HL7 FHIR (Fast Healthcare Interoperability Resources) defines resources — Patient, Observation, Encounter, MedicationRequest and many more — exchanged through modern REST APIs. First published in 2013, FHIR reached its first normative content in Release 4 in 2019, and a 2020 US rule made R4 the required standard for health IT certification.
• DICOM governs medical imaging.
• Terminologies such as SNOMED CT, LOINC and ICD codes give data shared meaning.

For new integrations, apps and analytics, FHIR APIs are usually the starting point, with HL7 v2 interfaces maintained where existing systems depend on them.

Security and privacy

Health data is highly sensitive and heavily regulated. In the US, the HIPAA Security Rule requires administrative, physical and technical safeguards, a documented risk analysis and ongoing risk management; documentation must be kept for six years. Other countries have their own health-privacy laws and general data-protection rules.

Practical controls for any HIS component or integration:

• Role-based access with least privilege and break-glass procedures for emergencies.
• Audit trails of every access to patient records, reviewed for inappropriate access.
• Encryption in transit and at rest.
• Strong authentication, including multi-factor authentication for remote and privileged access.
• Network segmentation separating clinical devices, core systems and guest networks.
• Vendor management: business associate agreements or equivalent contracts with any provider handling patient data.
• Resilience: backups, tested recovery and downtime procedures, since ransomware attacks on hospitals can halt care.

Worked example: adding a FHIR-based patient app

A hypothetical private hospital wants a patient app for appointments, test results and pre-admission forms. Its core EHR exposes FHIR R4 APIs; scheduling runs in a separate system with an older interface.

1. Integration layer: an API gateway exposes the EHR’s FHIR Patient, Appointment, Observation and DiagnosticReport resources, and wraps the scheduling system in a FHIR-style Appointment API.
2. Identity: patients log in with verified accounts linked to their record through the master patient index; proxies such as parents get explicitly authorised access.
3. Results release rules: clinicians decide which results appear in the app and when, following hospital policy.
4. Forms: pre-admission questionnaires are captured as structured data and written back to the record for clinical review.
5. Security and audit: every access is logged, sessions expire, and penetration testing precedes launch.

Because the app talks to standard APIs rather than directly to databases, it can survive a future change of scheduling system with limited rework.

Data migration when replacing modules

Replacing a core module is mostly a data and change-management project:

• Inventory data and decide what to migrate, archive or leave read-only in the old system.
• Clean before moving: duplicate patients, inconsistent codes and incomplete records.
• Map codes and terminologies between old and new systems, validated by clinicians.
• Run trial migrations and reconcile counts and samples with clinical and finance teams.
• Plan downtime procedures and paper fallbacks for go-live.
• Keep historic data accessible for clinical and legal reasons.

Benefits worth measuring

Buy, build or extend

Core clinical platforms are typically bought from specialised vendors, because they embody years of clinical content, regulatory features and certification. Building is more common for:

• Patient-facing apps and portals tailored to the hospital’s services and brand.
• Workflow tools that fill gaps between systems, such as bed management dashboards or discharge coordination.
• Integration and data platforms that connect systems and feed analytics.
• Specialised departmental tools where vendor options are weak.

Custom components should integrate through standard interfaces, especially FHIR, rather than proprietary database access.

Where AI fits

AI is entering hospital systems through documentation support, coding assistance, imaging analysis, operational forecasting and grounded assistants for policies and procedures. Our guide to RAG in healthcare explains how to ground assistants in approved content and where regulatory boundaries such as clinical decision support rules apply.

Modernising without disrupting care

1. Map the landscape: systems, interfaces, data flows, owners, contracts and pain points.
2. Strengthen integration: introduce or modernise an integration layer with FHIR APIs and monitoring.
3. Improve data quality: master patient index clean-up and shared terminologies.
4. Deliver visible improvements: patient portal features, scheduling, bed management or mobile access for clinicians.
5. Replace core modules selectively, with careful data migration, parallel running, training and downtime planning.
6. Govern continuously: clinical safety review, security testing and change control for every release.

Frequently asked questions

What is the difference between an HIS and an EHR?

The EHR holds the clinical record. A hospital information system is broader, covering administration, scheduling, departmental systems, billing and reporting as well as the EHR.

Should small hospitals or clinics build their own system?

Rarely for the core record. Proven platforms are safer and more cost-effective; custom development is better spent on integrations, patient apps and workflow gaps.

Is FHIR replacing HL7 v2?

Gradually for new use cases, especially APIs and apps. HL7 v2 will remain in use for many internal interfaces for years.

How long does an HIS replacement take?

Core platform replacements typically take many months to years, including configuration, data migration, training and go-live support. Integration and app projects can deliver results much sooner.