Naive REST interactions with a FHIR server may not fit more complex scenarios. We plan to discuss possible alternative patterns and protocols. During the meetup want to do a deep dive into FHIR implementers’ experiences and discuss how they are currently employing async and queue patterns in their real-world projects.
FHIR Async for CRUDS Interactions & Operations
Josh Mandel, Chief Architect, Microsoft Healthcare and SMART Health IT
FHIR’s current Asynchronous Request Pattern defines a request pattern designed for interactions that take a long time to perform and produce large volumes of data
The general interaction pattern is:
1. Kick off a request
2. Receive a “status” endpoint
3. Poll the status endpoint until the request has completed
4. Upon successful completion, receive a Bulk Data Manifest with links to FHIR NDJSON files (* these are suitable for large, unordered piles of data)
Why doesn’t this work for CRUD interactions and many operations? Bulk Data Manifests are designed to support bulk $export scenarios or other interactions that produce big piles of FHIR resources that clients need to copy wholesale.
Josh Mandel, Chief Architect, Microsoft Healthcare and SMART Health IT
Josh C. Mandel, MD is a physician and software developer working to fuel an ecosystem of health apps with access to clinical and research data. As Chief Architect for Microsoft Healthcare, Chief Architect for SMART Health IT, and Lecturer at the Harvard Medical School Department of Biomedical Informatics, Josh works closely with the standards development community to lay the groundwork for frictionless data access, authorization, analytics, and app integration. He led development of the SMART specification and launched the Clinical Decision Support Hooks project. As a member of the national Health IT Standards Committee, Josh showed a special interest in tools and interfaces that support software developers who are new to the health domain.
Queues for server to server integrations
Nikolay Ryzhikov, CTO, Health Samurai
CRUDSS (search, subscriptions) REST protocol works well client-server interactions where the server is the source of truth and client lifetime is short: get data from server, do something (render, modify), write back to server.
It does not work so good for server to server interactions, where we want to replicate data between servers reliably. Queue-based protocols and messaging paradigm works better for this circumstances.
Nikolay Ryzhikov is a CTO at Health Samurai and FHIR-first applications development visionary. With Health Samurai’s team of 10 engineers, Nikolay has developed a cloud inpatient EHR and implemented it in three California hospitals. Since 2012 has been an active contributor to the FHIR workgroup. He is leading the development of FHIR solutions including FHIRbase, FHIR.js, and Aidbox FHIR platform.
Join our subscribers list to get educational materials, updates and interesting articles about Aidbox & HL7 FHIR.
FHIR® is the registered trademark of HL7 and is used with the permission of HL7. This event is not sponsored by HL7. The FHIR trademark does not constitute endorsement of the content of the products and/or presentations presented by HL7.