2. Safe Harbour Statement
● Both the speaker and the host are organizing this meet-up in individual capacity only. We are
not representing our companies here.
● This presentation is strictly for learning purposes only. Organizer/Presenter do not hold any
responsibility that same solution will work for your business requirements.
● This presentation is not meant for any promotional activities.
2
3. A recording of this meetup will be uploaded to events page within 24 hours.
Questions can be submitted/asked at any time in the Chat/Questions & AnswersTab.
Make it more Interactive!!!
Give us feedback! Rate this meetup session by filling feedback form at the end of theday.
We Love Feedbacks!!! Its Bread & Butter for Meetup.
Housekeeping
3
6. 6
Agenda
● What is FHIR and Why to use it?
● Why MongoDB Atlas?
● Why MuleSoft?
● Error Handling
● Correlation ID
● Customer Story
● Demo
7. 7
● Supports RESTful architectures: seamless
exchange of information using messages
or documents, and service based
architectures
● XML, JSON or Turtle as the data
transmission format
● A strong focus on implementation – fast
and easy to implement.
● Independent of any one EHR vendor,
health system, or other for-profit health
entity
8. 8
● MongoDB Atlas is a fully-managed cloud database
● Atlas handles all the complexity of deploying,
managing, and healing MongoDB deployments on
the cloud service provider of your choice (AWS,
Azure, and GCP).
● MongoDB and FHIR both support the JSON format,
which is extensively used in modern application
development due to its’ ability to support rich data
structures and objects prevalent in healthcare, such
as patients, claims, policies, treatments and so on
9. 9
● Provides plug and play connector for HL7 and MongoDB Atlas.
● Provides a large number of operations and configurations on the data and the
database.
● Can work on simple request and response mechanism where a user/application can
send a request to MuleSoft integration and expect an operation to be done to their
FHIR data
Why MuleSoft?
10. 10
Error Handling in MuleSoft
● Requirement :
○ Stop the processing if there is any error while converting one format to another.
○ Do not retry until the error in the input data is fixed.
○ Send an email notification mentioning the error.
● On Error Propagate:
○ All processors in the error handling scope are executed but at the end :
■ The rest of the flow that threw the exception is not executed which means nothing will be
added to MongoDb
■ The error is re-thrown up to the next level and handled there.
11. 11
Correlation ID
● Common Identifier to all requests, messages and
responses in each transaction.
● A Correlation ID with a log entry helps in implementing
auditing.
● On failure, we just need to check the logs as per
correlation ID to get combined transactional activity
among all microservices.
● In the screenshot on the right you can see the
CorrelationID being forwarded to all Microservices.
● Screenshot below shows how in the logs we can find audit
trail of any transaction using CorrelationID.
12. Customer Story
● Customer tried building the converter in Java but it was a very long process.
● Customer was looking for various ways to store FHIR data for example smileCDR, which is
expensive and since it is third party, it is not completely under your control.
12
15. Take a stand !
18
●Nominate yourself for the next meetup speaker and suggest a topic as well.
16. 20
● Share:
○ Tweet using the hashtag #MuleSoftMeetups
○ Invite your network to join: https://meetups.mulesoft.com/nashik
● Feedback:
○ Fill out the survey feedback and suggest topics for upcoming events
○ Contact MuleSoft at meetups@mulesoft.com for ways to improve the program
What’s next?