MediRecords FHIR Implementation Guide
1.4.2 - release


REST API

Introduction

MediRecords has designed a comprehensive set of FHIR API’s that allows third party developers to build applications by creating, modifying, and querying patient and clinical data stored in MediRecords EHR.

The API’s returns JSON responses that are formatted according to FHIR standards . FHIR is a HL7 specification for seamless transfer of healthcare information electronically. The standardized resource types make application development simpler.

Note an account is required to access this feature. Contact Us to create a customer account.

FHIR API Capability

MediRecords supports the following FHIR® API covering the Patient’s demographic and clinical details.

The table below will be updated periodically as MediRecords publishes new APIs:

Legend: C - Create, R - Read, U - Update, D - Delete, S - Search

FHIR® Resource REST API Webhook MediRecords Profile
AllergyIntolerance CRUDS CUD MRAllergyIntolerance
Condition CRUDS CUD MRCondition
Consent R CU MRConsent
DiagnosticReport RS CUD MRDiagnosticReport
MRDiagnosticImagingReport
MRDiagnosticPathologyReport
DocumentReference CR CUD MRDocumentReferenceIn
MRDocumentReferenceOut
MRDocumentReferenceOutWrite
MRDocumentReferencePrescription
MRDocumentReferenceConsultation
MRDocumentReferenceAdmission
MRDocumentReferenceConsent
MRDocumentReferenceAttachment
Encounter CRUDS CU MREncounter
EpisodeOfCare R CUD MREpisodeOfCare
FamilyMemberHistory CRUDS   MRFamilyMemberHistory
HealthcareService R   MRHealthcareService
Immunization RS CUD MRImmunisation
Location R   MRLocationAdmission
MedicationAdministration R CU MRMedicationAdministrationAdmission
MRMedicationAdministrationAdmissionIV
MedicationRequest CRS CUD MRMedicationRequest
Observation RS CUD MRObservationVitalSignBodyHeight
MRObservationVitalSignBodyLength
MRObservationVitalSignBMI
MRObservationVitalSignBodyWeight
MRObservationVitalSignHeadCircumference
MRObservationVitalSignOxygenSaturation
MRObservationVitalSignRespiratoryRate
Organization R   MROrganisation
MROrganisationServiceProvider
Patient CRUDS CUD MRPatient
Practitioner R   MRPractitioner
PractitionerRole R   MRPractitionerRole
MRPractitionerRoleContact
ServiceRequest R CUD MRDiagnosticRequest
Task R   MRDiagnosticRequestFulillmentTask

Authentication

The MediRecords API uses OAuth 2.0 bearer token authentication to authenticate requests. To use your OAuth bearer token, you need to assign it to your request header as an authentication value.

Example. If your OAuth bearer token is db3efb4e-82bb-4bbb-997b-b5a3c39ce7e2, send this token in each request in your request header.

All API requests must be made over HTTPS. Calls made over plain HTTP will fail. API requests without authentication will also fail.

Contact Us to create a customer account.

Updating a Resource: GET-then-PUT Pattern

MediRecords APIs use PUT for updating resources. PUT is a full-replacement operation — the entire resource is replaced with the payload you provide. Any fields omitted from the payload will be treated as null and will overwrite existing data.

⚠️ Partial payloads will cause data loss. If you send a PUT request with only a subset of fields, all omitted fields will be cleared on the record.

The Correct Approach

Always follow the GET-then-PUT pattern when updating a resource:

  1. GET the current state of the resource
  2. Modify only the fields you wish to change
  3. PUT the complete payload — including all unchanged fields — back to the API
Example: Updating a Patient’s Date of Birth

Step 1 — Retrieve the current record

GET {API_URL}/v1/Patient/{patient_id}

READ Response:

{
  "resourceType": "Patient",
  "meta": {
    "profile": [
      "https://fhir.medirecords.com/StructureDefinition/mr-patient-core"
    ]
  },
  "active": true,
  "name": [
    { "use": "official", "family": "Patient", "prefix": [ "Mr" ] }
  ],
  "telecom": [
    { "system": "phone", "value": "0402111223", "use": "mobile" }
  ],
  "gender": "male",
  "birthDate": "1998-05-04",
  "managingOrganization": { "reference": "Organization/ade47c8c-9eed-11ea-a6fa-3f7e286deed9" }
}

Step 2 — Modify only the fields you need to change

In this example, we want to correct the patient’s date of birth, so we change birthDate from 1998-05-04 to 2000-05-04.

Step 3 — PUT the full payload back

PUT {API_URL}/v1/Patient/{patient_id} PUT Request:

{
  "resourceType": "Patient",
  "meta": {
    "profile": [
      "https://fhir.medirecords.com/StructureDefinition/mr-patient-core"
    ]
  },
  "active": true,
  "name": [
    { "use": "official", "family": "Patient", "prefix": [ "Mr" ] }
  ],
  "telecom": [
    { "system": "phone", "value": "0402111223", "use": "mobile" }
  ],
  "gender": "male",
  "birthDate": "2000-05-04",
  "managingOrganization": { "reference": "Organization/ade47c8c-9eed-11ea-a6fa-3f7e286deed9" }
}

✅ All fields are included — only birthDate has changed.

Common Mistake to Avoid

Incorrect — partial payload:

{
  "resourceType": "Patient",
  "meta": {
    "profile": [
      "https://fhir.medirecords.com/StructureDefinition/mr-patient-core"
    ]
  },
  "active": true,
  "name": [
    { "use": "official", "family": "Patient" }
  ],
  "telecom": [
    { "system": "phone", "value": "0402111223", "use": "mobile" }
  ],
  "gender": "male",
  "birthDate": "2000-05-04"
}

❌ This payload will clear any fields that were not included. In the above example managingOrganization and name.prefix would be cleared. Do not send partial payloads to a PUT endpoint.

Following this GET-then-PUT pattern ensures no unintended data loss during updates.

API End Point

For Prod, API_URL is: https://api.medirecords.com/fhir