Complete Guide: Setting Up Electronic Medical Records in Compliance with SNARS & SatuSehat

The implementation of Electronic Medical Records (RME) is no longer an option, but a necessity for healthcare facilities in Indonesia. Especially with the issuance of Minister of Health Regulation (PMK) No. 24 of 2022 concerning Medical Records, as well as the increasingly stringent accreditation demands of the National Hospital Accreditation Standards (SNARS) 1.1 or 2.0 from the Hospital Accreditation Commission (KARS). Many hospitals and clinics face serious challenges in ensuring their RME systems are not only functional, but also fully compliant with these regulations, especially regarding aspects of data security, interoperability, and completeness of information. Errors in RME setup can have fatal consequences, ranging from accreditation failure, regulatory fines, to the risk of patient data leakage that damages reputation and public trust. This article is specifically designed for Hospital IT Managers, clinic owners, operational managers, and decision makers who need practical, in-depth, and actionable guidance. We will thoroughly examine concrete steps in preparing an RME that not only meets SNARS standards, but is also ready to integrate with the SatuSehat platform, with a focus on technical implementation using the FHIR standard and the selection of appropriate technology.

Basic Concepts of RME in Accordance with SNARS and PMK No. 24 of 2022 Regulations

Compliance with SNARS is at the core of quality hospital operations. In the context of RME, SNARS demands more than just digitizing medical records; it requires an integrated, secure, accurate, and accountable system. PMK No. 24 of 2022 serves as the primary legal basis governing the administration of medical records, including RME, in all healthcare facilities. Article 3 of this PMK explicitly states that Healthcare Facilities are required to administer electronic Medical Records. This is not only about storing data digitally, but also ensuring data integrity, confidentiality, and data availability whenever needed.

Several crucial points underlined by SNARS and PMK No. 24 of 2022 regarding RME include: **Accurate Patient Identification**: SNARS underlines the importance of correct patient identification at every point of service. RME must be able to manage at least two unique patient identifiers (for example, Medical Record Number and NIK) and ensure identity verification at every data access. **Data Completeness and Accuracy**: Every entry in RME must be complete, accurate, and real-time. This includes patient progress notes, examination results, drug prescriptions, and care plans. RME must support structured data input to minimize errors and facilitate analysis. **Data Security and Confidentiality**: This is the main pillar. RME must be equipped with security features such as role-based access control (Role-Based Access Control/RBAC), data encryption (both at rest and in transit), as well as an audit trail that records every data access and change activity. PMK No. 24 of 2022 specifically regulates that RME must be stored and kept confidential, and equipped with an adequate security system.

**Data Interoperability**: SNARS encourages integration between departments and even between facilities. An RME that complies must be able to exchange data with other systems such as Laboratory SIM, Radiology SIM, Pharmacy SIM, and the most crucial at present is integration with the SatuSehat platform. The Fast Healthcare Interoperability Resources (FHIR) standard is key in achieving this interoperability. **Data Availability (Availability)**: The RME system must be designed to have high uptime. System redundancy, routine data backup, and a disaster recovery plan (Disaster Recovery Plan/DRP) are vital components to ensure medical data is always available when needed, even under emergency conditions. **User Management and Authorization**: Every RME user must have a unique account with an access level appropriate to their role. Authorization mechanisms must be strict to prevent unauthorized access. The audit log must record who, when, and what was accessed or changed.

As a real example, in the SNARS standards Chapter MIRM (Management of Information and Medical Records), points MIRM 1.1 and MIRM 1.2 specifically discuss the completeness and accuracy of medical records. RME must be designed to guide users to fill in all mandatory data elements, such as patient identification, health history, physical examination, diagnosis, care plan, and implementation and evaluation. The system must have strong input validation to prevent invalid or incomplete data. By understanding these basic requirements, we can build a solid and sustainable RME foundation.

Technical Architecture and Technology Selection for SNARS-Compliant RME

Building an RME that complies with SNARS requires a solid technical architecture foundation and the selection of appropriate technology. A microservices architecture approach is highly recommended over monolithic. Microservices offer better scalability, flexibility, and resilience, enabling independent development and maintenance of modules, which is very important for complex systems like RME. For example, the patient registration module, medical record module, pharmacy module, and laboratory module can run as separate services that communicate with each other through APIs.

For databases, **PostgreSQL 16** is an excellent choice. PostgreSQL is known for its robustness, strong ACID compliance capabilities, and native support for the JSONB data type, which is highly relevant for storing FHIR resources efficiently. Features such as replication and data partitioning also support scalability and high availability. Alternatively, MongoDB or Cassandra can be considered for very large and unstructured data scenarios, but PostgreSQL is often a more balanced choice for EMR needs that require high data consistency.

On the backend side, we recommend **Laravel 11.x (PHP)** or **Node.js 20 LTS (with Express.js or NestJS)**. Laravel offers a mature ecosystem, comprehensive documentation, and built-in security features that facilitate the development of secure RESTful APIs. For Node.js, its asynchronous performance is very suitable for applications that require fast responses and lots of I/O, such as integration with various external systems. Both frameworks have large communities and many supporting libraries for authentication (e.g., JWT), data validation, and database management.

For interoperability, the **FHIR R4** standard is the primary choice mandated by the Indonesian Ministry of Health through the SatuSehat platform. You can implement the FHIR API custom or use a FHIR server such as **HAPI FHIR 6.8 (Java)**. HAPI FHIR provides a complete and well-tested FHIR server implementation, accelerating the development process. If there is a need for integration with legacy systems that still use **HL7 v2.5.1**, ensure your EMR has a bridging module to translate HL7 v2 messages to FHIR R4 and vice versa. This is important to ensure data communication continues without disrupting existing operations.

Integration with the **SatuSehat Platform** is an absolute necessity. This means your EMR must be able to send and receive FHIR resources (such as Patient, Encounter, Condition, Observation, MedicationRequest, etc.) in accordance with the profiles specified by the Ministry of Health. Authentication to SatuSehat uses OAuth 2.0 with client credentials, and every data transaction must go through an HTTPS connection with TLS 1.2 or higher to ensure security. Use UUID v4 for local resource IDs before mapping to the IHS Number from SatuSehat. This choice of technology and architecture will ensure your EMR not only functions but also meets high compliance and interoperability standards.

FHIR API Implementation for Patient Data and SatuSehat Integration

In the context of an EMR that complies with SNARS and is integrated with SatuSehat, managing the `Patient` resource is a fundamental step. Every patient must have a consistent unique identification both in the internal system and on the SatuSehat platform. The FHIR R4 standard allows rich representation of patient data, including identity, demographics, contacts, and organization management status. The following is an example implementation of the `Patient` model in Laravel that maps internal data to the FHIR format, as well as an example controller in Node.js to send the `Patient` resource to SatuSehat.

First, let's see how the `Patient` model in Laravel can be set up to facilitate conversion to the FHIR format. This model will store basic patient data and have a `toFhirPatient()` method to generate an array that conforms to the FHIR structure.

<?php
namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;

class Patient extends Model
{
    use HasFactory;

    protected $table = 'patients';

    protected $fillable = [
        'ihs_number',
        'nik',
        'name',
        'gender',
        'birth_date',
        'address',
        'phone_number',
        'mrn'
    ];

    protected $casts = [
        'birth_date' => 'date',
    ];

    public function toFhirPatient()
    {
        return [
            'resourceType' => 'Patient',
            'identifier' => [
                [
                    'system' => 'http://ihs.kemkes.go.id/identifier',
                    'value' => $this->ihs_number // IHS Number dari SatuSehat jika sudah ada
                ],
                [
                    'system' => 'http://terminology.kemkes.go.id/CodeSystem/nik',
                    'value' => $this->nik
                ],
                [
                    'system' => 'http://terminology.kemkes.go.id/CodeSystem/mrn',
                    'value' => $this->mrn // Nomor Rekam Medis Internal
                ]
            ],
            'name' => [
                [
                    'use' => 'official',
                    'text' => $this->name
                ]
            ],
            'gender' => $this->gender, // male | female | other | unknown
            'birthDate' => $this->birth_date->format('Y-m-d'),
            'address' => [
                [
                    'use' => 'home',
                    'text' => $this->address
                ]
            ],
            'telecom' => [
                [
                    'system' => 'phone',
                    'value' => $this->phone_number,
                    'use' => 'mobile'
                ]
            ]
        ];
    }
}

Explanation of the code above: This `Patient` model defines the basic columns needed for patient data, including `ihs_number` (ID from SatuSehat), `nik`, `name`, `gender`, `birth_date`, `address`, `phone_number`, and `mrn` (internal Medical Record Number). The `toFhirPatient()` method is responsible for converting this data into a JSON structure according to the FHIR R4 standard for the Patient resource. It is important to note how `identifier` is used to store various patient IDs, including IHS Number, NIK, and internal MRN, each with the appropriate `system`. This is crucial to ensure interoperability and compliance with patient identification standards.

Next, we will look at an example controller in Node.js (using Express.js and Axios for HTTP requests) that serves to create or update the Patient resource on the SatuSehat platform. This process involves authentication to obtain an access token and then sending the FHIR payload to the SatuSehat Patient endpoint.

const axios = require('axios'); const { v4: uuidv4 } = require('uuid'); const SATUSEHAT_BASE_URL = process.env.SATUSEHAT_BASE_URL; // e.g., https://api-satusehat.kemkes.go.id/fhir-r4/v1 const SATUSEHAT_AUTH_URL = process.env.SATUSEHAT_AUTH_URL; // e.g., https://api-satusehat.kemkes.go.id/oauth2/v1 const CLIENT_ID = process.env.CLIENT_ID; const CLIENT_SECRET = process.env.CLIENT_SECRET; const ORGANIZATION_ID = process.env.ORGANIZATION_ID; // ID Organisasi Fasyankes dari SatuSehat let accessToken = ''; let tokenExpiry = 0; async function getAccessToken() { if (accessToken && Date.now() < tokenExpiry) { return accessToken; } try { const response = await axios.post(SATUSEHAT_AUTH_URL + '/accesstoken?grant_type=client_credentials', null, { headers: { 'Content-Type': 'application/x-www-form-urlencoded' }, params: { client_id: CLIENT_ID, client_secret: CLIENT_SECRET } }); accessToken = response.data.access_token; tokenExpiry = Date.now() + (response.data.expires_in * 1000) - 60000; // Buffer 1 menit sebelum expired return accessToken; } catch (error) { console.error('Error getting access token:', error.response ? error.response.data : error.message); throw new Error('Failed to get SatuSehat access token'); } } exports.createPatient = async (req, res) => { try { const token = await getAccessToken(); const patientData = req.body; // Data pasien dari sistem internal Anda const fhirPatient = { "resourceType": "Patient", "meta": { "profile": [ "https://profile.kemkes.go.id/fhir/r4/StructureDefinition/Patient" ] }, "identifier": [ { "use": "official", "system": "http://terminology.kemkes.go.id/CodeSystem/nik", "value": patientData.nik }, { "use": "usual", "system": "http://terminology.kemkes.go.id/CodeSystem/mrn", "value": patientData.mrn } ], "name": [ { "use": "official", "text": patientData.name } ], "telecom": [ { "system": "phone", "value": patientData.phone_number, "use": "mobile" } ], "gender": patientData.gender, "birthDate": patientData.birth_date, "address": [ { "use": "home", "type": "physical", "line": [patientData.address_line1], "city": patientData.city, "postalCode": patientData.postal_code, "country": "ID" } ], "maritalStatus": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/v3-MaritalStatus", "code": patientData.marital_status_code, "display": patientData.marital_status_display } ] }, "contact": [ { "relationship": [ { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/v2-0131", "code": "N" } ] } ], "name": { "text": patientData.emergency_contact_name }, "telecom": [ { "system": "phone", "value": patientData.emergency_contact_phone, "use": "mobile" } ] } ], "managingOrganization": { "reference": `Organization/${ORGANIZATION_ID}` } }; const response = await axios.post(`${SATUSEHAT_BASE_URL}/Patient`, fhirPatient, { headers: { 'Content-Type': 'application/fhir+json', 'Authorization': `Bearer ${token}` } }); res.status(201).json(response.data); } catch (error) { console.error('Error creating patient:', error.response ? error.response.data : error.message); res.status(500).json({ message: 'Failed to create patient', error: error.response ? error.response.data : error.message }); } }; 

Node.js code explanation: The `getAccessToken()` function handles the authentication process to SatuSehat using `client_credentials` grant type, ensuring the token is always valid before use. The `createPatient` function receives patient data from the internal request body, then converts it into a complete FHIR Patient resource format, including meta profile, identifier (NIK, MRN), name, gender, date of birth, address, marital status, emergency contact, and managing organization. This data is then sent to the SatuSehat `/Patient` endpoint using an HTTP POST request with headers `Content-Type: application/fhir+json` and `Authorization: Bearer [access_token]`. This code also includes basic error handling for HTTP requests. This implementation ensures that every patient registered in your internal EMR is also registered and updated in SatuSehat according to FHIR standards, fulfilling one of the SNARS interoperability requirements.

Handling Sensitive Data, Validation, and Error Handling

Medical data is highly sensitive data. Incorrect handling can have serious impacts on patient privacy and regulatory compliance. Therefore, an EMR that complies with SNARS must have robust mechanisms for handling sensitive data, input validation, and comprehensive error handling. One of the FHIR resources that often contains sensitive data is `Observation`, which includes laboratory results, vital signs, or other clinical examination results. It is important to ensure that every data element in `Observation` is sent with the correct terminology code (for example, LOINC for laboratory tests) and accurate values.

Below is an example FHIR `Observation` payload for blood glucose results. Notice how the `code`, `valueQuantity`, `subject`, `encounter`, and `performer` elements are filled with specific references and terminology, all of which are crucial for SNARS compliance in terms of data completeness and accuracy.

{ "resourceType": "Observation", "id": "example-lab-glucose", "meta": { "profile": [ "https://profile.kemkes.go.id/fhir/r4/StructureDefinition/Observation" ] }, "status": "final", "category": [ { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "laboratory", "display": "Laboratory" } ] } ], "code": { "coding": [ { "system": "http://loinc.org", "code": "2339-0", "display": "Glucose [Mass/volume] in Blood" } ], "text": "Glukosa Darah" }, "subject": { "reference": "Patient/{{patient_ihs_id}}", "display": "Nama Pasien Contoh" }, "encounter": { "reference": "Encounter/{{encounter_ihs_id}}", "display": "Kunjungan Rawat Jalan 2023-10-27" }, "effectiveDateTime": "2023-10-27T10:30:00+07:00", "issued": "2023-10-27T11:00:00+07:00", "valueQuantity": { "value": 95, "unit": "mg/dL", "system": "http://unitsofmeasure.org", "code": "mg/dL" }, "referenceRange": [ { "low": { "value": 70, "unit": "mg/dL", "system": "http://unitsofmeasure.org", "code": "mg/dL" }, "high": { "value": 100, "unit": "mg/dL", "system": "http://unitsofmeasure.org", "code": "mg/dL" }, "type": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/referencerange-meaning", "code": "normal", "display": "Normal Range" } ] } } ], "performer": [ { "reference": "Organization/{{organization_ihs_id}}", "display": "RS Contoh Sehat Laboratorium" } ] } 

This payload shows how observation data, from status, category, LOINC code, subject (patient), encounter (visit), effective time, to value quantity and reference range, should be structured. The use of `{{patient_ihs_id}}` and `{{encounter_ihs_id}}` shows the importance of referring to resources already registered in SatuSehat. Any mismatch with the FHIR profile specified by Kemenkes will cause an error.

An example error message that often occurs from SatuSehat or a FHIR server is `HTTP 400 Bad Request`, which indicates an invalid payload. For example:

{ "resourceType": "OperationOutcome", "issue": [ { "severity": "error", "code": "invalid", "details": { "text": "The 'gender' element must be one of 'male', 'female', 'other', 'unknown'. Provided value: 'M'" }, "location": ["Patient.gender"] } ] } 

This error indicates that the `gender` value sent ('M') does not match the enumerated values allowed by the FHIR standard ('male', 'female', 'other', 'unknown'). Effective handling methods include: **Server-Side Input Validation**: Implement strict validation in the backend using libraries such as Joi or Yup in Node.js, or Form Request in Laravel. This will catch format errors before data is sent to SatuSehat. **Detailed Error Logging**: Every API error must be logged in detail, including the request payload, response from the external API, and stack trace. These logs are crucial for debugging and auditing. **Retry Mechanism**: For temporary errors (for example, `HTTP 500 Internal Server Error` from SatuSehat), implement a retry mechanism with a backoff strategy. **Admin Notification**: Send automatic notifications to the IT team or admin if a critical error occurs that requires manual intervention. **Data Transformation**: Ensure internal data is properly converted to the FHIR standard. For example, mapping internal gender codes to the appropriate FHIR codes (`M` to `male`). With this approach, your EMR will be more robust and compliant.

Best Practices for Implementing an EMR that Complies with SNARS and SatuSehat

1. Strict Data Governance Management: Develop and implement comprehensive data governance policies, covering the data lifecycle from acquisition, storage, access, to retention and deletion. Ensure these policies align with PMK No. 24 of 2022, especially regarding the confidentiality and integrity of patient data. Conduct routine audits to ensure compliance.
2. Prioritize End-to-End Cybersecurity: Implement data encryption both at rest in the database and in transit using HTTPS/TLS 1.2+ for all communications. Implement a firewall, Web Application Firewall (WAF), Intrusion Detection/Prevention System (IDS/IPS), and conduct regular penetration testing (pentest) (at least once a year) by an independent third party to identify and patch security vulnerabilities.
3. Full Adoption of FHIR R4 Interoperability Standards: Make FHIR R4 the backbone of your RME data integration. Use the FHIR profiles recommended by the Ministry of Health for SatuSehat. In addition, adopt standard terminologies such as LOINC for laboratory results, SNOMED CT for diagnoses and procedures, and ICD-10/ICD-9-CM for disease and procedure coding, to ensure consistency and understanding of data across systems.
4. Robust Multilayer Data Validation: Implement data input validation across multiple application layers: on the frontend (UI/UX), on the backend (API), and at the database layer. This validation must cover data types, formats, value constraints, and the presence of required data in accordance with SNARS requirements and the FHIR schema. This will prevent invalid or incomplete data from entering the system.
5. Comprehensive Testing and Accreditation Scenarios: Perform unit, integration, and system testing extensively. Most importantly, conduct User Acceptance Testing (UAT) with scenarios that directly replicate SNARS requirements. For example, test the patient registration flow, medical record documentation, medication requests, through to data submission to SatuSehat, and ensure every step meets accreditation criteria.
6. Effective User Training and Change Management: Provide ongoing training for all staff (medical, paramedical, administrative) on the use of RME and the importance of compliance with SNARS. Educate them on how to enter accurate data, maintain confidentiality, and understand the impact of every action in the system. Effective change management will reduce resistance and accelerate RME adoption.
7. Continuous System Monitoring and Audit Logs: Implement a real-time RME performance monitoring system (for example, using Prometheus and Grafana) to identify bottlenecks or issues. Enable audit logs at all levels, recording every access, change, or deletion of data. These logs are crucial for security incident investigation, compliance audits, and accountability.
8. Design for Scalability and High Availability: Plan your RME architecture to accommodate future growth in data volume and number of users. Use techniques such as load balancing, database clustering/replication, and containerization (Docker, Kubernetes) to ensure the system remains responsive and available even under high load, in line with SNARS expectations for information availability.

FAQ: Common Questions About Electronic Medical Records and SNARS Compliance

1. What is SNARS and why is RME compliance with SNARS so important?

   SNARS is the National Hospital Accreditation Standard established by KARS to assess the quality of hospital services in Indonesia. RME compliance with SNARS is very important because RME is the backbone of health information management. SNARS ensures that RME meets standards for completeness, accuracy, security, and data interoperability, which in turn will improve patient service quality, operational efficiency, and support better clinical decisions. Without this compliance, hospitals risk not being accredited or losing accreditation, which affects operations and public trust.

2. How does the SatuSehat platform connect with SNARS compliance requirements for RME?

   SatuSehat is a national health data interoperability platform built on the FHIR R4 standard. RME compliance with SNARS implicitly requires interoperability capability, and SatuSehat is the primary mechanism for achieving this in Indonesia. By integrating your RME with SatuSehat, you not only meet the interoperability aspect of SNARS, but also ensure that patient data can be exchanged securely and in a standardized way among other health facilities that are also connected to SatuSehat, supporting continuity of service and coordination of patient care.

3. What is the estimated cost required to implement an RME that complies with SNARS and SatuSehat?

   The cost of implementing an RME that complies with SNARS and is integrated with SatuSehat varies greatly, depending on the scale of the facility (clinic, type C, B, A hospital), the complexity of desired features, the level of customization, technology choices (open-source vs. proprietary), and infrastructure requirements (server, network, security). For a medium-sized hospital, the investment can range from hundreds of millions to billions of rupiah, covering software licenses, custom development, hardware infrastructure, training, and maintenance costs. It is important to conduct a thorough needs analysis and feasibility study to obtain a more accurate estimate.

4. Can existing legacy RME be upgraded to comply with SNARS and be integrated with SatuSehat?

   Yes, most legacy RME can be upgraded, but the process may require significant refactoring. The steps include auditing the existing system to identify SNARS compliance gaps and FHIR readiness, migrating data to a structure more compatible with FHIR, developing FHIR integration modules for SatuSehat, improving security features, and retraining users. Sometimes, the cost and complexity of an upgrade can approach or even exceed the cost of implementing a new system, so careful evaluation is needed whether an upgrade or a new implementation is the best option.

5. What are the main challenges often faced in the process of implementing RME that complies with SNARS?

   The main challenges include: **Business Process Changes**: RME requires fundamental changes in the workflows of medical and administrative staff, which often triggers resistance. **Human Resources**: Lack of IT personnel who understand FHIR standards and health regulations, as well as lack of digital literacy among staff. **Cost**: Large initial investment and ongoing maintenance costs. **Interoperability**: Complexity of integration with other systems and the SatuSehat platform. **Data Security**: Ensuring RME is safe from cyber threats and complies with PMK No. 24 Tahun 2022. Overcoming these challenges requires strategic planning, top management support, and adequate resource commitment.

6. How can patient data security in RME be ensured so that it remains in accordance with SNARS and PMK No. 24 Tahun 2022?

   Ensuring patient data security is a top priority. The steps include: **Encryption**: Implementing data encryption in the database (data at rest) and during transmission (data in transit) using the TLS 1.2+ protocol for all communications. **Access Control**: Implementing strict Role-Based Access Control (RBAC), ensuring each user can only access data according to their role. **Audit Trail**: Recording every activity of access, change, or deletion of data in detail for audit and forensic purposes. **Backup & Disaster Recovery**: Implementing a routine data backup strategy and a tested disaster recovery plan. **Regulation & Policy**: Formulating and implementing a clear information security policy, in accordance with PMK No. 24 Tahun 2022, and conducting regular staff training on data security practices.

Implementing Electronic Medical Records that comply with SNARS and are integrated with SatuSehat is indeed not an easy task, but it is a strategic investment that will provide long-term benefits for your healthcare facility. With the right architectural foundation, selection of appropriate technology, accurate implementation of FHIR standards, and commitment to data security and validation, you will not only meet accreditation requirements, but also improve operational efficiency, data accuracy, and overall patient service quality. This process requires careful planning, meticulous execution, and in-depth understanding of regulations and technical standards. If you need further consultation or professional assistance in designing, developing, or implementing a Hospital Management Information System (SIMRS), Clinic Information System (SIM Klinik), or specific integration with SatuSehat and FHIR standards, do not hesitate to contact our team. We are ready to be your partner in realizing a compliant and innovative digital health transformation.

This article is part of the education of Nugroho Setiawan, IT consultant in Jogja. Related solutions: SIMRS SIM Klinik Integrator Bridging SatuSehat. Need free consultation?