Did you already get a chance to start the mission helping you to build a sample app using the SAP Health Data Services for FHIR? See this blog post for more details. In this mission, we guide you through implementing a sample app that can serve as a blueprint for real-world use cases that you could think of.
Below are some other potential use cases for inspiration. We would love to get your thoughts on them and – even better – your own use case ideas.
Use Case #1 “Waiting Time Management”
Background: Patients in the emergency department often have no idea how long it will take to see a physician. An app could calculate an estimated waiting time. It runs on a large monitor visible to all patients and potentially also on their smartphones.
The app would listen to the HL7 v2 stream of the Clinical Information System via SAP Health Data Services for FHIR as shown in the figure below. Those messages would be mapped to FHIR messages in the communication server and then be consumed by the app.
It would use the rules service to define rules that calculate the expected waiting time and visualize them in an appropriate UI that you develop.
Use Case #2 “Bed capacity reporting”
Background: In many countries hospitals have to report their (intensive) bed capacity to a central authority for the purpose of routing ambulances to free beds, and also for statistical purposes. Example DEMIS in Germany (link).
The app would take care of the regular reporting of bed capacity to an authority.
The Information on actual/planned encounters could be read via REST API of the Hospital Information System (HIS) (outbound call to be developed) or via inbound messaging of HIS occupancy data like encounter-created.
The app would take care of the scheduled generation of QuestionnaireResponse instances (based on HIS data), develop a UI to visualize the generated instances and schedule the outbound communication to the centralized solution of the corresponding authority.
Use Case #3 “Hospital Meal Management”
Background: Inpatients typically get three meals daily during their hospital stay. They can choose among different menus or building blocks, which also depends on the planned treatment and their personal preferences and medical restrictions. In addition to the patient, multiple parties are engaged in this process: the hospital caterer defines the base menus, plans and prepares the food based on the patients’ choice, and the nurses distribute the ordered menus.
You could develop multiple apps here for the different personas involved, like an app for the caterer/kitchen to define and plan menus for the next period, an app for patients to order their meals based on their dietary preferences and treatment-based restrictions, an app for nurses to distribute the ordered menus on the ward.
The information on actual encounters and patient's allergies could be read via REST API of the HIS (outbound call to be developed) or via inbound messaging of HIS occupancy data like encounter-created.
You would take this data into account for developing your various apps using the rule service and the core service or inbound messaging service.
Use Case #4 “Patient Selection for Clinical trials”
In the mission we published in the SAP Discovery Center, you can create a sample app for selecting patients eligible for a clinical trial.
Further process support could be offered by an app for enrolling patients in a clinical trial, an app for performing the clinical trial or an app for handling the financial part.
Use Case #5 “Supply Chain for Surgeries”
Background: Material planning and availability check in the context of surgery planning is very important. The necessary materials must be ordered in time and be available for the surgery.
The app could take care of checking the availability of the necessary materials a given number of days before the planned surgery. Depending on the status of the materials, the app could create a material reservation or trigger a purchase request in the hospital’s material management system.
The app would listen to the HL7 v2 stream of the HIS and consume those messages via the inbound messaging service. For the integration with the materials management system, outbound messaging would need to be developped.
Let us know your thoughts, comments, and questions on these use cases. Do you miss a service or component? Do you have any questions on how to implement a certain aspect?
Just get in contact with us by commenting on this blog or by writing an email.