MediRecords FHIR Implementation Guide
20220926 - ci-build


Home

Introduction

HL7® FHIR® (Fast Healthcare Interoperability Resources) is the future of health data interoperability standard. By adopting FHIR®, healthcare providers can more efficiently share patient data, healthcare organizations can deliver greater value to the members and patients can take better control of their own health record.

MediRecords has proudly enabled FHIR® as a data exchange mechanism to make Patient’s data accessible, usable, and computable across various systems in a secured way.

The following references are recommended to gain a better understanding of FHIR®:

Supported HL7® FHIR® Versions & Dependencies

MediRecords supports FHIR® Release 4 (4.0.1). The FHIR® profiles in MediRecords have been primarily inherited from Australian Base profile and influenced by the Australian Primary Care Data Quality guidelines.

Scope and Roadmap

MediRecords supports the following FHIR® API covering the Patient’s demographic, administrative 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

MediRecords Module REST API Webhook MediRecords Profile
Practices
(Subscription)
Organization   MROrganisation
Users
(Subscription)
Practitioner   MRPractitioner
Health Professionals
(Contacts)
PractitionerRole   MRPractitionerRole
Service Providers
(Contacts)
HealthcareService   MRHealthcareService
Patients Patient patient MRPatient
Past Consultations Encounter encounter MREncounter
Allergies & Reactions AllergyIntolerance allergyintolerance MRAllergyIntolerance
Medical History Condition condition MRCondition
Medications MedicationRequest medication-request MRMedicationRequest
    dispense
notification
coming soon
 
Immunisations Immunization immunization MRImmunisation
Family History FamilyMemberHistory   MRFamilyMemberHistory
Observations Observation observation MRObservationVitalSignBodyHeight
MRObservationVitalSignBodyLength
MRObservationVitalSignBMI
MRObservationVitalSignBodyWeight
MRObservationVitalSignHeadCircumference
MRObservationVitalSignOxygenSaturation
MRObservationVitalSignRespiratoryRate
More coming
Investigations DiagnosticReport
coming soon
diagnostic-report
coming soon
MRDiagnosticReport
MRDiagnosticPathologyReport
MRDiagnosticImagingReport
Correspondence DocumentReference
coming soon
document-reference
coming soon
MRDocumentReferenceIn
MRDocumentReferenceOut

Guidance

In general, the implementers must follow the generic FHIR® guidelines. In addition to that, the system implementers are advised to follow the following guidelines:

Must Support

Must Support flag in this implementation guide is displayed as letter “S” with red background in the Flag column of the Differential Table and Snapshot Table of a profile or extension, as such S.

In MediRecords, ‘mustSupport’ on any data element SHALL be interpreted as follows:

For Implementers:

While creating and sending contents to MediRecords

  • To be conformant, implementers SHALL be able to include ‘mustSupport’ data elements if the data is available within their source system.
For MediRecords:

While sending contents out of MediRecords

  • MediRecords SHALL be able to include ‘mustSupport’ data elements if the corresponding information is available within MediRecords system.

Once received data, MediRecords

  • SHALL be able to process the data element without generating any error.
  • SHALL be able to assert missing information.
  • SHOULD be able to display ‘mustSupport’ data elements in MediRecords App, or processing and storing them for other purposes.

Conformance Requirement:

  • The incoming payload from external system must be conformant to the corresponding FHIR® profile as published by MediRecords. It is expected that the implementers will be following MediRecords profile and implementation guideline while exchanging data with MediRecords.
  • For optional mustSupport data elements, if the data to be included is not available in the implementer’s source system, the data element is omitted.
  • For required coded mustSupport data elements, the following guidelines SHALL be followed:
    • In case of missing data and to support ‘example’, ‘preferred’, or ‘extensible’ binding strengths, if the source systems has text but no coded data, only the text element is used.
    • For ‘required’ binding, use the appropriate code from the ValueSet provided.
  • MediRecords doesn’t support any unknown extension or unknown element in the incoming payload.
  • Implementers must adhere to the terminology binding guidelines published by HL7®.
  • Implementers must adhere to the data privacy and security guidelines as required by MediRecords.

Processing of Data

MediRecords system is able to handle all data that are marked as ‘mustSupport’ and mandatory or any data element that are required to be supported as per FHIR® conformance requirement. If any data is supplied by the client system which doesn’t fall under the above mentioned criteria, MediRecords doesn’t guarantee processing and storing those data elements.

MediRecords Data Exchange Model

External client systems can connect to MediRecords using the following integration patterns:

  • Interaction Pattern 1: Registered Client System can interact with MediRecords using JSON based Restful API.
  • Interaction Pattern 2: MediRecords publishes change event (Patient Administration and Clinical mostly) to the subscribed client system using webhook integration.

MediRecords only supports JSON format for all data exchange.

Access Data Using FHIR® API

MediRecords FHIR® API follows ‘RESTful’ specification in which a set of operations (known as “interactions”) on standard FHIR® resources are exposed in the form of API. The FHIR® API in MediRecords follows the following interactions:

Instance Level Interactions

  • read : HTTP GET Request to read a particular instance of a resource compliant to MediRecords profile. The client system must provide a valid instance ‘id’.
  • update: HTTP PUT Request to update a particular instance of a resource compliant to MediRecords profile. The client system must provide a valid instance ‘id’. The ‘id’ provided in the url must match with the instance ‘id’ as found in the request body.
  • delete: HTTP DELETE Request to remove an existing instance of a resource from MediRecords repository. The client system must provide a valid instance ‘id’.

MediRecords doesn’t support retrieval of historical versioned data.

Type Level Interactions

  • create : HTTP POST Request to create an instance of a resource type compliant to MediRecords profile. The client system must not provide any instance ‘id’ in the request payload.
  • search: HTTP GET Request to search matching instances of a resource type based on the allowed filter criteria. Any unknown (not supported by MediRecords API specification) query parameter provided in the search criteria will be ignored.

Whole System Interactions

Support for system level interactions will be enabled in upcoming releases.

Receive Webhook FHIR® Notification Asynchronously.

The Webhook interaction model allows Client system to receive MediRecords data asynchronously in FHIR® format.

  • It is assumed that the Webhook clients are pre-registered to receive the event notifications.
  • Webhook only supports the write events.
  • Once any event occurs through the MediRecords app, the registered client will receive the event. Similarly, if any Clinical Data is received from any external party for which an equivalent event notification must be provided (as per event subscriptions) to the registered client, the same process will be followed.
  • Webhook events are real time and carries data related to specific event only.
  • Event Notification consists of metadata about the event and the actual event payload

API Specification

MediRecords exposes all APIs through the ConnectAPI platform. The ConnectAPI specification provides the following details:

  • The functional details about the API method, what is supported as API signature (query parameter, headers, response structure, request body, Supported Error conditions as per FHIR standard)
  • Relevant webhook (if applicable)
  • The reference to the FHIR profile the API conformant to
  • Sample Request, Response and Error Payloads

FAQ

What are the different data formats supported by MediRecords?

MediRecords only supports JSON format for all data exchange.

Tell us more about the example provided in the IG?

  • The data used in the example doesn’t have any relation with any realtime patient data.
  • The examples must be used for guidance only. The actual implementation imposes business rules on top of the data provided. The example may fail to testify all internal business rules.

Is FHIR® STU3 supported?

MediRecords only supports FHIR® Release 4 (4.0.1).

Are FHIR® extensions supported?

Yes, MediRecords supports extensions on different resources as defined in MediRecords profiles. However, unknown extensions and data elements are not supported by the server.

Do I need to use OAuth to access the MediRecords APIs?

Yes, MediRecords APIs are protected with OAuth 2.0.

Does MediRecords support Smart-on-FHIR?

MediRecords is actively working on enabling Smart-on-FHIR for the existing APIs. Any update on Smart-on-FHIR for MediRecords will be provided here.

How to discover the server Capabilities and Configuration?

MediRecords will publish ‘.well-known/smart-configuration’ and ‘CapabilityStatement’ relative to a FHIR® Server Base URL while enabling Smart-On-FHIR in the upcoming releases. Implementers can refer to the ConnectAPI specification for more details on the APIs supported by MediRecords.

Is FHIR® ‘$everything’ supported?

‘$everything’ will be supported in the upcoming releases.

Is FHIR® Bulk Data Export supported?

MediRecords may consider supporting ‘Bulk Data Export’ in the upcoming releases.

How MediRecords handles error conditions?

MediRecords will return appropriate HTTP code and OperationOutcome when error condition occurs. Refer to ConnectAPI specification for more details.