search

LEMON BLOG

Malaysia’s Healthcare Digitalisation Is Moving Forward—But Why Are Hospitals Still Submitting the Same Data Repeatedly?

Malaysia's healthcare system is clearly entering a new phase of digital transformation. Over the past several years, the Government—particularly the Ministry of Health Malaysia, or KKM—has introduced initiatives involving electronic medical records, national health-data repositories, health information exchange, clinical coding, insurance reform, hospital billing transparency and value-based provider payments.

The overall direction is encouraging. Better-quality national healthcare data can support more accurate policymaking, disease surveillance, resource planning, hospital benchmarking and continuity of patient care. From a technology perspective, this is exactly where Malaysia should be heading.

However, from the perspective of private hospital administration, the implementation is becoming increasingly fragmented. Hospitals are being asked to submit overlapping datasets to different platforms, organisations, consultants and project teams—each with its own format, terminology, coding standard, submission template and deadline.

The question many private hospitals are beginning to ask is simple:

Malaysia Has Been Building the Right Digital Foundations

Malaysia's recent healthcare digitalisation efforts did not appear overnight. They form part of a longer journey that has accelerated considerably over the past five years.

Some of the major initiatives include:

Looking at these initiatives individually, each has a reasonable objective. The problem becomes apparent when hospitals are required to support all of them as separate projects.

What Does SMRP Actually Collect?

SMRP is sometimes described simply as a patient census reporting system, but its scope is much broader.

Based on KKM's SMRP 2.0 documentation, the system includes patient demographics, inpatient and daycare encounters, admission and discharge information, ward details, discipline and specialty, health-funding type, billing category, discharge status, diagnosis information and clinical procedures.

Its inpatient discharge module includes diagnosis types, diagnosis descriptions and related coding fields. It also captures surgical and procedural information using ICD-9-CM procedure codes.

SMRP also contains separate reporting functions for:

The ward-census component itself requires facilities to report totals by ward, date and discipline.

In other words, SMRP already receives a considerable portion of the hospital-activity data that is now being requested again for newer initiatives.

DRG Introduces Another Detailed Submission Requirement

Project DRG goes further by linking clinical information to hospital billing.

Through ProtectHealth's Price, Admission and Clinical Electronic Datahub, or PACED, participating private hospitals must submit a minimum dataset containing:

The current coding requirements specify ICD-11 for diagnosis, with ICD-10 temporarily accepted during the transition, and ICD-9-CM for procedures. Hospitals must also submit billing information for all cases and payor categories, including values before and after discounts.

Hospitals can submit through API integration, CSV upload or manual data entry. Although daily or weekly submissions are encouraged, all information for the preceding month is expected to be submitted by the tenth day of the following month.

This is not a small, one-off data exercise. It requires continuous work by medical records, clinical coding, finance, billing and IT teams.

It is also worth clarifying that ProtectHealth is not simply an unrelated commercial vendor. It is a not-for-profit organisation under KKM. Nevertheless, from a hospital's operational perspective, PACED remains a separate platform, submission process and technical specification that must be managed alongside MyHDW and SMRP.

Now Comes Another Billing Restructuring Study

The latest request reaching parts of the private hospital sector is described as the Private Hospital Billing Restructuring Study, reportedly led by IQVIA Consulting.

The initiative appears connected to the broader effort to improve billing transparency, standardise the presentation of hospital charges and understand the structure of private healthcare costs. However, the full terms of reference and appointment details do not appear to be widely available through public sources at the time of writing.

Once again, the objective may be reasonable. A detailed understanding of hospital billing is necessary before meaningful reforms can be introduced.

The concern is that hospitals may now need to extract and prepare yet another dataset containing information that overlaps with:

Each requesting party may ask for slightly different column names, file formats, definitions, reporting periods or billing classifications. The underlying patient encounter, however, remains the same.

One Patient Encounter, Multiple Versions of the Same Data

Consider one inpatient admission.

SMRP may require the patient's admission, discharge, ward, census, diagnosis and procedure details.

Project DRG may require the same admission and discharge information, length of stay, primary and secondary diagnoses, procedures, discharge mode and billing values.

A billing restructuring study may then request itemised hospital charges, charge categories, discounts, payor type, diagnosis, procedure and length-of-stay information.

Insurance and takaful operators may already hold another version of the same case through claims submissions.

The hospital therefore ends up preparing multiple representations of one clinical encounter—not because the original data is unavailable, but because every initiative has established its own collection mechanism.

This is exactly what a national data warehouse should prevent.

MyHDW officially describes itself as a comprehensive and interoperable source of healthcare data operating under the principle of "build once, use many." One of its stated objectives is to reduce the burden of data collection and processing.

That principle is excellent. Unfortunately, the hospital-side experience is increasingly becoming "build once, reformat many times."

The Hidden Operational Cost to Hospitals

Government agencies and project teams may see data submission as a matter of uploading a spreadsheet or connecting an API. Inside a hospital, it is considerably more complicated.

Before information can be submitted, the hospital may need to:

Hospitals that rely on third-party HIS or EMR providers may have to raise paid change requests for new reports, database fields, interfaces or API integrations. A system vendor may consider every new national initiative a separate development project because every initiative comes with a different technical specification.

The hospital may also require additional medical-records staff, coders, finance personnel, data analysts or IT support. Existing employees may need to perform this work on top of their normal responsibilities.

Most importantly, these are recurring monthly operating costs, not temporary implementation expenses.

Eventually, Someone Has to Absorb the Cost

Not every compliance cost is automatically transferred directly to patients. Hospitals may initially absorb some of it through existing operational budgets.

However, recurring costs cannot simply disappear.

They must eventually be:

When multiple initiatives introduce additional systems, staffing, coding, integration and reporting requirements, they contribute to the overall cost of delivering healthcare.

This creates an uncomfortable contradiction. Some of these projects are intended to control healthcare expenditure, yet a fragmented implementation can create new administrative costs that ultimately place additional pressure on hospitals—and potentially on patients.

More Pressure During an Already Difficult Hospital–Payor Debate

Malaysia is already dealing with a difficult debate involving private hospitals, insurance companies, takaful operators, medical inflation and rising premiums.

The Government established the RESET Strategy precisely because these issues cannot be resolved by blaming only one party. Its five strategic areas cover insurance reform, price transparency, digital health, cost-effective healthcare options and transformation of provider-payment mechanisms.

Hospitals are being asked to explain and restructure their charges. Insurers and takaful operators are under pressure to manage claims and keep premiums sustainable. Patients are worried about both hospital bills and the affordability of medical coverage.

In this environment, imposing several overlapping data exercises can add further tension.

Hospitals may feel that they are repeatedly required to prove, justify and repackage the same information. Insurers may believe more granular data is necessary to identify cost drivers. Consultants may require their own dataset to complete an assigned study. Regulators need reliable evidence before making policy decisions.

Every party has a reason. What is missing is a single national data architecture connecting all those reasons together.

The Better Model: Submit Once, Use Through Authorised Modules

Malaysia does not necessarily need to exclude private-sector expertise. Government platforms are often developed, supported or enhanced by external technology companies and consultants.

The better approach would be for KKM to remain the owner of the national architecture, standards and governance while allowing different vendors to develop specialised modules within that architecture.

For example:

Hospitals would submit the core information once through a standard API or standardised file.

Different authorised modules could then use the appropriate fields according to their legal purpose and access rights. Where a project genuinely requires additional fields, those fields could be added to an extended module without rebuilding the entire submission process.

This would be much closer to MyHDW's own "build once, use many" philosophy.

Government Must Own the Standards, Even When Vendors Build the Technology

A single platform does not mean only one vendor must perform every function.

When the existing vendor lacks a particular capability, KKM could appoint another company to build a new module. However, the vendor should work within the same national architecture rather than creating an entirely separate data island.

To protect the public interest, contracts should clearly establish that:

There should also be a clear record of which organisation requested each data element, why it is required, how long it will be retained and whether the same information already exists within another government-controlled platform.

The Risk of Opportunism Must Be Monitored—Not Assumed

External consultants and technology companies can provide valuable specialist expertise. It would therefore be unfair to assume that every private organisation involved in a government healthcare project is acting improperly.

Nevertheless, the risk of opportunism must be taken seriously whenever multiple companies are appointed to collect, host, process or analyse overlapping national healthcare datasets.

The concern is not merely about consultancy fees. It includes:

These risks should be managed through transparent procurement, publication of project scopes, conflict-of-interest declarations, independent technical audits, strong data-governance agreements and measurable project outcomes.

Hospitals should also be informed how a new project differs from existing initiatives and why the required information cannot be obtained through MyHDW or another existing government platform.

Final Thoughts

Personally, I strongly support the Government's effort to modernise Malaysia's healthcare infrastructure. A connected national health system, interoperable medical records, reliable clinical coding and better-quality data can improve patient safety, policy planning and the overall sustainability of healthcare.

My concern is not the direction. My concern is the fragmentation of its implementation.

Hospitals should not have to submit almost identical information separately to SMRP, Project DRG, insurance-related initiatives, billing studies and various appointed project teams. Every additional specification requires IT development, data cleaning, validation, clinical coding, finance reconciliation and manpower—and the requirement returns again every month.

Malaysia already has MyHDW, a platform whose stated purpose is to become a trusted, integrated national healthcare-data source while reducing the burden of repeated data collection. That should become the central umbrella.

Where additional expertise is needed, other vendors and consultants can still be appointed—but they should develop modules under the same national ecosystem, standards and governance framework.

The Government's digital ambitions are moving in the right direction. The next step is to ensure that the implementation itself reflects the same principles it promotes: integration, interoperability, efficiency, transparency and one trusted source of truth.

Codeberg Draws a Firm Line Against LLM Training an...
How Compromised GitHub Repositories Turned Packagi...

Related Posts

 

Comments

No comments made yet. Be the first to submit a comment
Monday, 27 July 2026

Captcha Image

LEMON VIDEO CHANNELS

Step into a world where web design & development, gaming & retro gaming, and guitar covers & shredding collide! Whether you're looking for expert web development insights, nostalgic arcade action, or electrifying guitar solos, this is the place for you. Now also featuring content on TikTok, we’re bringing creativity, music, and tech straight to your screen. Subscribe and join the ride—because the future is bold, fun, and full of possibilities!

My TikTok Video Collection