IT Consultant in Yogyakarta: How to Choose the Right SIMRS Implementation Partner

Type C hospitals in Sleman that buy SIMRS from out-of-town vendors often experience the same pattern: the contract is signed in November, the inpatient module only becomes active in February, and BPJS VClaim bridging still fails when the first claim is submitted. It is not because the application is bad, but because no party truly understands the IGD workflow, support services, INA-CBG coding, and staff habits in the field. In DIY, the number of healthcare facilities continues to grow while internal IT teams average only 1–3 people who also handle other work. As a result, all implementation risk depends on the partner. Choosing the wrong partner is not only about losing a license fee of Rp150–400 million, but also claim waiting time, patient data that is inconsistent between units, and staff trust that is lost and hard to restore. This article discusses how to select one technically, not based on brochures and testimonials on a landing page.

Map it first: core SIMRS, bridging, and supporting modules are different

Many management teams view SIMRS as one large package. In practice, there are three layers that must be separated from the start: (a) transactional core — registration, electronic medical records, pharmacy, billing, cashier; (b) external integration — VClaim and BPJS queue, SatuSehat FHIR R4, LIS via HL7 v2.5, PACS via DICOM; (c) managerial modules — accounting, inventory, HR, e-office. Ask prospective partners to map what they truly build themselves, what is OEM from another vendor, and what is done by subcontractors. Evasive answers at this point usually end in finger-pointing at go-live.

For SIM Klinik, the scope is more concise — generally 3–5 modules — but SatuSehat integration remains mandatory for clinics that cooperate with BPJS. A competent consultant can mention which modules are worth customizing and which should actually be left alone. Example: do not put tariff logic inside the core code; use a rule engine or configuration so that the next version upgrade does not break billing calculations.

A real example from a SIM Klinik project in Magelang with 4 polyclinics and 60 visits per day: registration waiting time dropped from 7 minutes to 2.5 minutes after the registration flow was streamlined and payer master data was cleaned — 1,200 duplicate rows deleted, 38 payer codes standardized. That is not the result of advanced technology, but the result of process mapping. Therefore, ask prospective partners to show process as-is/to-be documents, not just an interface demo.

If the hospital or clinic has business units such as a retail pharmacy, café, or medical equipment sales, ask specifically about their POS and ERP experience: how stock between warehouses is synchronized, how COGS is calculated when there are discounts and returns. Partners that are only strong in SIMRS often falter when they have to combine hospital pharmacy stock with retail pharmacy stock in one report.

Test technical competence: BPJS bridging, SatuSehat, and FHIR

Bridging is the most common failure point. Ask partners to explain their architecture: separate middleware or code embedded inside SIMRS. Separate middleware — for example, a Node.js 20 service or Laravel 11 with a Redis queue — is safer because retry, logging, rate limiting, and reconciliation can be managed without touching the application core. Also ask about behavior when the BPJS endpoint is down: whether it uses an outbox pattern so transactions remain recorded and are resent, or transactions fail immediately in front of registration staff.

For SatuSehat, the requirement is FHIR R4 with resources such as Patient, Encounter, Condition, Observation, and MedicationRequest. Partners must understand the difference between sandbox and production, the use of NIK as an identifier, and ICD-10, LOINC, and KFA terminology for the pharmacy dictionary. Ask for a demonstration of sending one complete Encounter from registration until the resource is sent, not a slide presentation.

# Uji cepat endpoint sandbox SatuSehat (butuh curl + jq)
curl -s -X POST "https://api-satusehat-stg.dto.kemkes.go.id/oauth2/v1/accesstoken" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET" > token.json
curl -s -H "Authorization: Bearer $(jq -r .access_token token.json)" \
  "https://api-satusehat-stg.dto.kemkes.go.id/fhir-r4/v1/Patient?identifier=$NIK"

If the partner team cannot explain the meaning of the access_token field, expires_in, the refresh mechanism, and the backoff strategy when receiving HTTP 429, that is a serious red flag. Also ask how many times retry is allowed at maximum and how the idempotency key is used so that one visit is not sent twice to SatuSehat.

Small details show whether a team has been in production or only done demos: library versions (Guzzle 7.x on PHP 8.2, Symfony HttpClient 7, or Axios 1.x), timeout handling, SSL certificate validation, and log format. Partners that mention concrete numbers — a 15-second timeout, 3x retry with exponential backoff — usually have actually handled incidents.

Contract, timeline, and evidence after go-live

SIMRS implementation for a hospital with 100 beds realistically takes 16–24 weeks, not 4 weeks. Ask for a phase breakdown: analysis and master data cleanup 3 weeks, configuration and migration 4 weeks, UAT per unit 4 weeks, pilot of one unit 2 weeks, rollout 4 weeks, then hypercare 4–8 weeks with on-site support.

Contract points that must be present: response SLA (P1 maximum 2 hours, P2 maximum 8 working hours), access to source code or at minimum escrow, API documentation in OpenAPI 3.1 format, training at least two batches per user role, and a data ownership clause — patient data belongs to the hospital, the partner must hand over an encrypted dump upon contract termination.

Verify references in a tangible way: the name of the hospital or clinic, the number of active users, and permission to contact its IT manager. Avoid vague references such as several hospitals in Java. For the Yogyakarta, DIY, and Magelang areas, direct visits to reference sites are still very feasible and should really be done before signing.

Regarding budget, a reasonable implementation cost is in the range of 15–30% of the license value. Offers that are much cheaper usually mean training is cut, data migration is handed over to hospital staff, and there is no hypercare.

Best Practices

1. Request a live bridging demo in a sandbox, not a video recording: send one new patient from registration until Encounter SatuSehat is sent.
2. Test data quality before the contract: count duplicate NIKs and payer codes in the old database; if it is above 2%, budget for a dedicated cleansing phase.
3. Lock the SLA and source code escrow into the contract, including obligations for API documentation and database schema.
4. Run a pilot in one unit for at least 2 weeks with clear metrics (waiting time, bridging error rate, cashier closing time).
5. Agree in writing on the definition of go-live and the hypercare exit criteria so there is no hanging handover.

FAQ

How long does SIMRS implementation take for a small clinic?

For a clinic with 3–5 polyclinics and 50–80 visits per day, a reasonable timeline is 6–10 weeks: 2 weeks for analysis and master data, 3 weeks for configuration and bridging, 2 weeks for UAT, then 1–3 weeks of assistance. Under 4 weeks almost always means data migration and training are sacrificed.

Is it mandatory to use separate middleware for bridging?

It is not mandatory, but it is highly recommended. Separate middleware allows retries, message queues, and monitoring without touching the SIMRS core. If bridging is embedded in the core code, any BPJS disruption can potentially block the registration flow and make application upgrades riskier.

How do you test a vendor's claim that they are experienced?

Ask for three contactable references, then ask about the number of active users, the modules actually used daily, and the last incident they handled. Add a technical session with a developer directly, not just sales, to discuss architecture and error handling.

What should be done if a partner stops in the middle of a project?

Ensure from the start that there is source code escrow, database schema documentation, and access to the hospital-owned repository. That way, another partner in Yogyakarta or Magelang can continue without rebuilding from scratch, and patient data remains safe with the healthcare facility.

Choosing an IT consultant for SIMRS implementation is not about who offers the lowest price or gives the most convincing presentation, but about who can prove technical competence in BPJS and SatuSehat bridging, has a measurable data migration plan, and is willing to be bound by an SLA and documentation handover. Start with mapping internal processes, prepare the list of technical questions above, and verify references directly. If you are preparing a SIMRS, SIM Klinik, ERP, POS, or website implementation for a healthcare facility in Yogyakarta, DIY, and Magelang, consult your needs to get an architecture assessment and a realistic timeline estimate before the contract is signed.

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?