Hospital IT Investment: Measuring ROI & Cost-Benefit Analysis for Sustainability

In the ever-evolving healthcare landscape, hospitals are faced with dual pressure to improve service quality while managing costs efficiently. Investment in information technology, such as Hospital Management Information Systems (SIMRS), Electronic Medical Records (EMR), and integration with national platforms such as SatuSehat or BPJS, has become a necessity. However, often, these investment decisions are made without a clear framework for comprehensively measuring their financial and operational impact. Many IT managers and clinic owners struggle to demonstrate the real value of significant IT spending, making it a 'cost center' rather than a 'value center'. Regulations such as the Minister of Health Regulation (PMK) No. 24 of 2022 on Medical Records demand broader digital adoption, but without proper analysis, such investments risk becoming a burden rather than an asset. This article aims to provide a practical and in-depth guide on how you can effectively calculate Return on Investment (ROI) and conduct Cost-Benefit Analysis (CBA) for every IT project in your hospital, ensuring every rupiah invested delivers maximum value and supports operational sustainability.

Why Are ROI and Cost-Benefit Analysis Vital in Hospital IT Investment?

Investment in information technology in the healthcare sector often involves large budgets, from hardware procurement, software licenses, to implementation and maintenance costs. However, many healthcare organizations still struggle to articulate and measure the real value generated from such investments. It is not only the initial cost that needs to be considered, but also the Total Cost of Ownership (TCO) and how the technology can deliver long-term value. A study by HIMSS (Healthcare Information and Management Systems Society) consistently shows that hospitals that successfully implement and adopt Electronic Medical Records (EMR) or SIMRS optimally can achieve operational efficiency improvements of up to 15-20% in the first few years.

Return on Investment (ROI) is a financial metric that measures the efficiency or profitability of an investment. Simply put, ROI is calculated with the formula: (Net Profit / Investment Cost) x 100%. For example, if a hospital invests Rp 1 Billion to upgrade its billing system and generates savings and increased revenue of Rp 1.5 Billion over three years, then its ROI is ((Rp 1.5 Billion - Rp 1 Billion) / Rp 1 Billion) x 100% = 50%. This figure provides a direct picture of how effective the investment is in generating financial returns.

On the other hand, Cost-Benefit Analysis (CBA) is a more comprehensive approach to evaluating a project. CBA involves identifying and quantifying all costs and benefits associated with a project, both financial and non-financial. The goal is to determine whether the total benefits of a project exceed its total costs. Examples of non-financial benefits often considered in CBA include reduced patient waiting times, improved accuracy of medical data, increased staff satisfaction, or improved compliance with health regulations.

The main difference between ROI and CBA lies in their scope. ROI focuses exclusively on financial metrics and provides a percentage return on investment. Meanwhile, CBA takes a broader view, attempting to quantify qualitative benefits into monetary values where possible, or at least presenting them as part of decision-making. The two are complementary: ROI provides a sharp financial picture, while CBA provides a more holistic understanding of the project's overall value. For example, implementing an integrated SIMRS can result in a 30% reduction in data entry errors and speed up the BPJS claim process by 2 days. Financially, this could mean administrative cost savings of Rp 200 million per year, while qualitatively, it improves patient and staff satisfaction and reduces medical risks.

Practical Steps to Calculate ROI and CBA for Healthcare IT Projects

To ensure accurate ROI and CBA analysis, a systematic approach is essential. The first step is to identify all costs associated with the IT project. These costs include not only direct costs such as hardware purchases (servers, workstations), software licenses (e.g., SIMRS, EMR modules, BPJS/SatuSehat Integration modules), but also indirect costs. Examples of indirect costs are implementation and customization costs (e.g., developing specific modules with Laravel 11.x), data migration from legacy systems, human resource training (doctors, nurses, administrative staff), API integration (such as FHIR R4, HL7 v2.5.1), operational costs (electricity, cooling), and ongoing system maintenance and support costs (e.g., service contracts with vendors or internal teams managing PostgreSQL 16 databases).

The second step is to identify and quantify all expected benefits of the project. Financial benefits can include reduced operational costs (e.g., paper savings due to EMR, staff efficiency), increased revenue (from new services enabled by technology, faster billing), reduced fines or penalties due to non-compliance, or improved efficiency in insurance claim processes. Significant non-financial benefits include improved quality of patient care, increased patient satisfaction, compliance with national regulations such as PMK No. 24 of 2022, improved clinical decision-making based on better data, and enhanced hospital reputation.

Quantifying non-financial benefits is often a challenge. However, there are methods to convert them into monetary value. For example, the time saved per nurse or doctor due to process automation can be converted to the value of their salary. The reduction of malpractice risk due to higher data accuracy can be converted into potential avoided litigation costs. The use of interoperability standards such as HAPI FHIR 6.8 for data integration between systems can significantly reduce the time and effort required by IT staff to develop and maintain new interfaces, potentially reducing workload by up to 20% and allowing them to focus on other innovations.

The next step is to determine the analysis period, which typically ranges from 3 to 5 years for IT projects in hospitals. It is also important to consider the time value of money by using a discount rate to calculate Net Present Value (NPV). Projects with a positive NPV are considered financially feasible. If you implement an integrated ERP solution, such as ERP Poultry/Layer for veterinary hospitals, you need to project savings in feed costs, inventory management, and improved animal care efficiency over this period.

Finally, utilize available analysis tools. Spreadsheets such as Microsoft Excel or Google Sheets are basic tools that are very effective for simple calculations. For more complex analysis and data visualization, Business Intelligence (BI) software such as Power BI or Tableau can be integrated directly with your SIMRS database (for example, PostgreSQL or MySQL) to monitor KPIs in real-time. For automation of data collection and processing, programming languages such as Node.js 20 LTS or Python 3.10+ are often used to create custom scripts that can extract, transform, and load data (ETL) into the BI platform.

Example Calculations and Data Analysis Automation

To calculate ROI and CBA accurately, data collection and analysis must be done systematically. Here are two code examples showing how you can calculate ROI using Python and extract relevant data from a database using SQL, which are key components in hospital IT analysis.

This first Python code serves as a simple ROI calculator. It allows you to input initial investment data, total benefits, and operational costs over several years to get a cumulative ROI percentage. This is very useful for getting a quick overview of the project's financial feasibility.

# roi_calculator.py
def calculate_roi(net_benefit, investment_cost):
    """Calculate ROI in percentage."""
    if investment_cost == 0:
        return 0.0
    return ((net_benefit - investment_cost) / investment_cost) * 100

# Example data (in Rupiah)
initial_investment = 1_500_000_000  # Initial investment for SIMRS
total_benefits_year1 = 500_000_000 # Savings/revenue year 1
total_benefits_year2 = 750_000_000 # Savings/revenue year 2
total_benefits_year3 = 1_000_000_000 # Savings/revenue year 3
operational_cost_year1 = 100_000_000 # Operational/maintenance costs year 1
operational_cost_year2 = 120_000_000
operational_cost_year3 = 150_000_000

net_benefits_total = (total_benefits_year1 + total_benefits_year2 + total_benefits_year3) - \
                         (operational_cost_year1 + operational_cost_year2 + operational_cost_year3)

roi_percentage = calculate_roi(net_benefits_total, initial_investment)
print(f"Total Net Benefit (3 years): Rp {net_benefits_total:,.0f}")
print(f"Initial Investment: Rp {initial_investment:,.0f}")
print(f"ROI of SIMRS Project (3 years): {roi_percentage:.2f}%")

# Output:
# Total Net Benefit (3 years): Rp 1,980,000,000
# Initial Investment: Rp 1,500,000,000
# ROI of SIMRS Project (3 years): 32.00%

The Python code above shows a simple way to calculate cumulative ROI over a 3-year period. It takes into account the initial investment as well as the total benefits and operational costs over that period. The net benefit is calculated by subtracting the total operational costs from the total benefits obtained. The ROI result in percentage gives a direct overview of the financial effectiveness of the investment. This script can be run with Python 3.10+ and provides easy-to-read output for initial decision-making.

The following SQL script is designed to extract cost and benefit data from the SIMRS database or related systems. This script uses `UNION ALL` to combine various data sources, which are often spread across multiple tables or schemas in the hospital database (for example, for license fees, training costs, and operational savings). The extracted data can then be used as input for more detailed ROI or CBA calculations.

-- simrs_data_extractor.sql
SELECT
    'SIMRS License Fee' AS cost_item,
    SUM(license_fee) AS total_amount
FROM
    it_investments.licenses
WHERE
    project_id = 'SIMRS_Upgrade_2023'
UNION ALL
SELECT
    'HR Training Cost' AS cost_item,
    SUM(training_cost) AS total_amount
FROM
    it_investments.trainings
WHERE
    project_id = 'SIMRS_Upgrade_2023'
UNION ALL
SELECT
    'BPJS Claim Savings' AS benefit_item,
    SUM(bpjs_claim_savings) AS total_amount
FROM
    operational_benefits.bpjs_claims_efficiency
WHERE
    benefit_date BETWEEN '2023-01-01' AND '2025-12-31'
UNION ALL
SELECT
    'New Service Revenue Increase' AS benefit_item,
    SUM(new_service_revenue) AS total_amount
FROM
    revenue_generation.new_services
WHERE
    service_date BETWEEN '2023-01-01' AND '2025-12-31';

This SQL script, designed for PostgreSQL 16.x, serves to collect cost and benefit data from various tables in the SIMRS database or related systems. By using UNION ALL, we can combine results from different queries to obtain a comprehensive picture of expenses and profits associated with a specific IT project. This data can then be used as input for more detailed ROI or CBA calculations. It is important to ensure that the table structures and column names match your hospital's database implementation. This script can be executed through SQL clients such as DBeaver or pgAdmin.

Data Integration and Issue Handling in Benefit Analysis

In the context of SIMRS, data integration is the backbone for accurately measuring benefits. Imagine patient registration efficiency data taken from the registration module, patient waiting times from the queue module, and patient satisfaction data from internal surveys. All of this must be integrated and accessible for analysis. Interoperability standards such as FHIR R4 (Fast Healthcare Interoperability Resources Release 4) and HL7 v2.5.1 are highly relevant here, enabling different systems to 'talk' to each other.

One real-world example is integration with the SatuSehat platform initiated by the Indonesian Ministry of Health. Patient data from SIMRS must be sent in FHIR R4 format to the SatuSehat platform. Errors in sending data payloads, whether due to incompatible formats, invalid data, or duplication, can hinder the benefit measurement process and even cause data rejection by the SatuSehat system. This results in incomplete data for analysis and potential regulatory non-compliance.

The following is an example of a realistic FHIR R4 payload for the Patient resource, according to the profile used in Indonesia:

{
  "resourceType": "Patient",
  "id": "example",
  "meta": {
    "profile": [
      "https://fhir.kemkes.go.id/r4/StructureDefinition/Patient"
    ]
  },
  "identifier": [
    {
      "system": "http://terminology.kemkes.go.id/CodeSystem/nik",
      "value": "3276010101900001"
    },
    {
      "use": "usual",
      "system": "http://sys-ids.kemkes.go.id/patient/id",
      "value": "100000030009"
    }
  ],
  "active": true,
  "name": [
    {
      "use": "official",
      "text": "Budi Santoso",
      "family": "Santoso",
      "given": [
        "Budi"
      ]
    }
  ],
  "telecom": [
    {
      "system": "phone",
      "value": "08123456789",
      "use": "mobile"
    }
  ],
  "gender": "male",
  "birthDate": "1990-01-01",
  "address": [
    {
      "use": "home",
      "type": "physical",
      "line": [
        "Jl. Merdeka No. 10"
      ],
      "city": "Jakarta Pusat",
      "postalCode": "10110",
      "country": "ID",
      "extension": [
        {
          "url": "https://fhir.kemkes.go.id/r4/StructureDefinition/Provinsi",
          "valueCode": "32"
        },
        {
          "url": "https://fhir.kemkes.go.id/r4/StructureDefinition/Kota",
          "valueCode": "3276"
        },
        {
          "url": "https://fhir.kemkes.go.id/r4/StructureDefinition/Kecamatan",
          "valueCode": "327601"
        },
        {
          "url": "https://fhir.kemkes.go.id/r4/StructureDefinition/Kelurahan",
          "valueCode": "32760101"
        }
      ]
    }
  ],
  "maritalStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/v3-MaritalStatus",
        "code": "M",
        "display": "Married"
      }
    ]
  },
  "contact": [
    {
      "relationship": [
        {
          "coding": [
            {
              "system": "http://terminology.hl7.org/CodeSystem/v2-0131",
              "code": "N"
            }
          ]
        }
      ],
      "name": {
        "use": "official",
        "text": "Siti Aminah",
        "family": "Aminah",
        "given": [
          "Siti"
        ]
      },
      "telecom": [
        {
          "system": "phone",
          "value": "08129876543",
          "use": "mobile"
        }
      ]
    }
  ]
}

If the above payload is sent to SatuSehat and the NIK is already registered, you might receive an error like this:

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "severity": "error",
      "code": "invalid",
      "details": {
        "text": "Identifier with system 'http://terminology.kemkes.go.id/CodeSystem/nik' and value '3276010101900001' is already registered for another patient. NIK must be unique."
      },
      "expression": [
        "Patient.identifier"
      ]
    }
  ]
}

The above error occurs because SatuSehat enforces a uniqueness rule on the NIK identifier. One NIK can only be linked to one Patient resource. If you encounter this case, do not immediately create a new patient with a modified NIK. The correct step is to search for the existing patient resource using search parameters, for example GET [base]/Patient?identifier=http://terminology.kemkes.go.id/CodeSystem/nik|3276010101900001. From that response, take the patient's id and then perform a PUT or PATCH to update the data that actually needs correction. If the NIK was incorrectly entered from the start, correct it on the old resource, not by creating a duplicate. This practice is important so that integration remains clean and does not cause problems in subsequent reporting.

Practical Tips for Managing SatuSehat Integration

First, apply idempotency to every data submission process. Store the mapping between the patient's local ID in the SIMRS and the SatuSehat resource id in a separate table. That way, when a retry occurs due to a timeout or network disruption, your system can check whether the data has already been sent before resending it. This pattern avoids duplication, which is often the source of already registered errors.

Second, build layered validation before submission. Validate the NIK (16 digits, cannot be empty), date of birth format, Kemkes region code, and completeness of required fields such as name, gender, and birthDate. Perform this validation on the application side, not just relying on the server response. In addition, log every OperationOutcome response to a structured log so the IT team can trace the root cause quickly without having to reproduce the case.

Third, prepare a periodic reconciliation mechanism. Schedule a daily or weekly job to compare the number of local patients with the number of resources successfully synchronized. If there is a discrepancy, investigate whether it is caused by a failed submission, duplicate NIK, or data that is indeed incomplete. This approach is far more effective than waiting for error reports to pile up in the support team's inbox.

FAQ

Can the NIK be left empty if the patient does not yet have a NIK?

Yes, but it is better to use another identifier that is still unique, for example an internal medical record number with an agreed-upon system. Do not fill the NIK with placeholder numbers because it risks colliding with other patients' data and complicates reconciliation later on.

What if one patient has two Patient resources due to a previous mistake?

Perform an audit by searching the identifier, then determine which resource to keep. Move references from the duplicate resource to the primary resource, then deactivate or delete the duplicate according to the applicable policy. Make sure this change is recorded in the internal audit log.

Does an OperationOutcome error always mean the data is rejected entirely?

Not always. Some issues are warnings and the data is still partially saved. Read the severity and expression fields to find out which part is problematic. Only issues with severity error or fatal usually cause the entire transaction to fail.

How often does the integration need to be retested?

At minimum every time there is an API version change, an addition of a required field, or an update to validation rules from Kemkes. Also test after an internal SIMRS update, because changes to the local database schema often affect the payload sent.

Conclusion

SatuSehat integration is not merely the work of sending JSON payloads. It demands discipline in identifier management, data validation, and structured error handling. By implementing idempotency, layered validation, and periodic reconciliation, a hospital's IT team can reduce the synchronization failure rate and keep patient data quality consistent.

If your hospital is currently designing or improving a SatuSehat integration and facing obstacles such as duplicate NIKs, validation errors, or unbalanced reporting, our team is ready to help conduct a technical assessment and formulate an improvement strategy that fits your facility's workflow. Contact us for an initial consultation session and make sure the integration runs smoothly without disrupting patient services.

This article is part of the knowledge base of Nugroho Setiawan, an IT consultant in Jogja (Yogyakarta). Related solutions: SIMRS (Hospital Information System) BPJS & SatuSehat Integration. Need a free consultation?