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^®:

• FHIR^® Getting Started
• HL7^® International FHIR Wiki

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	Inbound Notification
Subscription - Practices	Organization		MROrganisation MRHealthcareService
Subscription - Users	Practitioner		MRPractitioner MRPractitionerRole
Contacts - Health Professionals	PractitionerRole		MRPractitionerRoleContact
Contacts - Service Providers	Organization		MROrganisationServiceProvider
Patients	Patient	patient.*	MRPatient
Consultations	Encounter	encounter.*	MREncounter
	DocumentReference	document-reference-consultation.*	MRDocumentReferenceConsultation
	DocumentReference	document-reference-attachment.create	MRDocumentReferencetAttachment
Allergies & Reactions	AllergyIntolerance	allergyintolerance.*	MRAllergyIntolerance
Medical History	Condition	condition.*	MRCondition
Medications	MedicationRequest	medication-request.*	MRMedicationRequest	MedicationDispense
	DocumentReference	document-reference.created	MRDocumentReferencePrescription
Immunisations	Immunization	immunization.*	MRImmunisation
Family History	FamilyMemberHistory		MRFamilyMemberHistory
Observations	Observation	observation.*	MRObservationVitalSignBodyHeight MRObservationVitalSignBodyLength MRObservationVitalSignBMI MRObservationVitalSignBodyWeight MRObservationVitalSignHeadCircumference MRObservationVitalSignOxygenSaturation MRObservationVitalSignRespiratoryRate
Case Management	EpisodeOfCare	episode-of-care.*	MREpisodeOfCare
Correspondence	DocumentReference	document-in-reference.* document-out-reference.*	MRDocumentReferenceIn MRDocumentReferenceOut
Investigations	ServiceRequest Task	diagnostic-request.*	MRDiagnosticRequest MRDiagnosticRequestFulillmentTask
	DiagnosticReport	diagnostic-report.*	MRDiagnosticReport
Admissions	Location		MRLocationAdmission
	Encounter	encounter-admission.*	MREncounterAdmission
	DocumentReference	admission.note.*	MRDocumentReferenceAdmission

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

The REST API 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 REST API 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 REST API specification for more details.