A well-known Healthcare organization engaged us to create an patient portal on Azure. They were planning on migrating from Salesforce to CRMOL. They were currently using Salesforce and we needed to synchronize Patient records between the CRMOL Patient Portal and Salesforce. We were asked to use the HL7 FHIR standard for all Patient records. Two major requirements that we needed to include were:
Logging of records sent from CRMOL Portal
They needed a way to view any errors that occur within the workflow.
We will take a look at how we solved the problem.
08448380779 Call Girls In Greater Kailash - I Women Seeking Men
Do Logic Apps support error handling?
1. Sponsored & Brought to you by
Do Logic Apps support error handling?
Howard Edidin
https://twitter.com/hsedidin
http://www.linkedin.com/in/hedidin
2. Do Logic Apps support error handling?
Howard S. Edidin
3. Agenda
• Use Cases
• DocumentDB
• The “Skip and Go Naked” design pattern
• Demo
• Next steps
6/28/2016 3
4. Use Case
• Logging
– Log original message from CRMOL.
• A fairly common Use Case in EDI
• Error Handling
– Log Response Errors returned from Receiver
– Viewing the Errors
6/28/2016 4
5. HL7 FHIR – Appointment Resource
• Appointment resources are used to provide information
about a planned meeting that may be in the future or past.
• The resource only describes a single meeting, a series of
repeating visits would require multiple appointment
resources be created for each instance.
• Examples include a scheduled surgery, a follow-up for a
clinical visit, a scheduled conference call between clinicians
to discuss a case, the reservation of a piece of diagnostic
equipment for a particular use, etc.
• The visit scheduled by an appointment may be in person or
remote (by phone, video conference, etc.) All that matters is
that the time and usage of one or more individuals,
locations and/or pieces of equipment is being fully or
partially reserved for a designated period of time.
6/28/2016 5
6. HL7 FHIR – Appointment Resource
• Use Case
– A scheduled conference call between clinicians to
discuss a case
6/28/2016 6
7. JSON Request Template
{
"resourceType" : "Appointment",
// from Resource: id, meta, implicitRules, and language
// from DomainResource: text, contained, extension, and modifierExtension
"identifier" : [{ Identifier }], // External Ids for this item
"status" : "<code>", // R! proposed | pending | booked | arrived | fulfilled | cancelled | noshow
"type" : { CodeableConcept }, // The type of appointment that is being booked
"reason" : { CodeableConcept }, // Reason this appointment is scheduled
"priority" : "<unsignedInt>", // Used to make informed decisions if needing to re-prioritize
"description" : "<string>", // Shown on a subject line in a meeting request, or appointment list
"start" : "<instant>", // When appointment is to take place
"end" : "<instant>", // When appointment is to conclude
"minutesDuration" : "<positiveInt>", // Can be less than start/end (e.g. estimate)
"slot" : [{ Reference(Slot) }], // If provided, then no schedule and start/end values MUST match slot
"comment" : "<string>", // Additional comments
"participant" : [{ // R! Participants involved in appointment
"type" : [{ CodeableConcept }], // Role of participant in the appointment
"actor" : { Reference(Patient|Practitioner|RelatedPerson|Device|
HealthcareService|Location) }, // Person, Location/HealthcareService or Device
"required" : "<code>", // required | optional | information-only
"status" : "<code>" // R! accepted | declined | tentative | needs-action
}]
}
6/28/2016 7
8. JSON Response Template
{
"resourceType" : "AppointmentResponse",
// from Resource: id, meta, implicitRules, and language
// from DomainResource: text, contained, extension, and modifierExtension
"identifier" : [{ Identifier }], // External Ids for this item
"appointment" : { Reference(Appointment) }, // R! Appointment this response relates to
"start" : "<instant>", // Time from appointment, or requested new start time
"end" : "<instant>", // Time from appointment, or requested new end time
"participantType" : [{ CodeableConcept }], // Role of participant in the appointment
"actor" : { Reference(Patient|Practitioner|RelatedPerson|Device|
HealthcareService|Location) }, // Person, Location/HealthcareService or Device
"participantStatus" : "<code>", // R! accepted | declined | tentative | in-process |
completed | needs-action
"comment" : "<string>" // Additional comments
}
6/28/2016 8
10. Demo
6/28/2016 10
1. We will POST an Appointment request to our Logic App
2. Post a new Log Document (record) to a DocumentDB Collection
1. View the Log Document
3. Convert text comments into speech (audio file)
4. Create new DocumentDB Attachment for the audio file
5. Validate for success or failure
6. If Failed, then post Error Document (record) to a DocumentDB Collection
1. View the Error document
7. If Success, create Appointment Response message
1. Post the Response Message back to CRM.
11. Next step
6/28/2016 11
• The complete Logging and Error Handling
tutorial will be published on the Azure Logic
App examples and scenarios page.
• The source code will be available
12. Contact Information
6/28/2016 12
Howard S. Edidin MCTS, MCP, MS
Senior Azure Solution Architect
Microsoft MVP – Azure | Data Platform
Microsoft Integration P-TSP (Healthcare and Life Sciences)
Microsoft Azure Advisory Group
DocumentDB Wizard
100 Menlo Park, Suite 302B, Edison NJ 08837
Office: (732) 474-6844
Cell: (224) 360-3200
Toll Free: (855) VNB CONS
Email : howard.edidin@vnbconsulting.com
Web : www.vnbconsulting.com
HL7 Gold Member