How Product People defined HL7 FHIR requirements for Recare’s patient discharge platform

The Client: Recare Deutschland GmbH

Recare is a healthtech company founded in 2017 in Berlin with the mission of redesigning hospital discharge management. Since its foundation, the team has grown significantly and currently includes ~90 people. With the acquisition of Pflegeplatzmanager GmbH in the summer of 2023, Recare's network will grow to 650 acute-care hospitals, 550 rehabilitation clinics, and 23,000 other service providers from the care and medical supplies and homecare sectors. Recare operates in both Germany and France.

The main solution ISO 27001-certified Recare offers is a SaaS platform connecting hospitals and care providers thereby allowing them to meet the criteria of the Krankenhauszukunftsgesetz (KHZG). Simply put, Recare operates a B2B marketplace. The primary use case works like this: whenever the hospital is about to discharge a patient that requires follow-up care, the hospital can:

• Use the platform to create an anonymized patient profile; for speed and simplicity thehospital has the opportunity to import data via an integration from the HospitalInformation System (HIS).
• Request transfer to care homes or other aftercare providers from the list of connected service providers.
• Transfer the patient upon confirmation by both the care home and the hospital (the patient profile is de-anonymized upon confirmation by both parties).

‍

The Mission: Interim Technical Product Manager

Recare’s main B2B solution consists of 2 web applications: an app for social workers in hospitals looking to discharge patients (Sender App) and an app for the aftercare providers offering services (Receiver App). In addition to its existing B2C solution in the Weser-Ems region(https://gesundheit-weser-ems.de/), the company recently was awarded the project to develop a new B2C application for a German public body. The new B2C solution aims to enable citizens as well as members of consultation services such as “Pflegestützpunkte” and “Fachstellen für pflegende Angehörige” to search for suitable care providers in their vicinity free of charge. The project’s requirements also include the development of an API solution, in line with HL7 Fast Healthcare Interoperability Resources (FHIR) standards and detailed documentation.

• Team Overview: We joined a solid team of five developers and a product manager. A product analyst, QA working student, and product designer were shared with another team. It was a balanced team with diverse expertise that experienced a void left by the temporary absence of a Technical PM, who had previously provided the FHIR expertise.
• Why Product People?: The Technical Product Manager, responsible for defining the FHIR resources and supporting the engineers during implementation, was on parental leave. This absence could have slowed down the design and launch of the new application, but that's where Product People stepped in.
• Company's Vision & Aim: Our primary goal was to understand, define, and document the FHIR resources for the company's new application. By the end of our engagement, we had produced comprehensive documentation of the FHIR implementation landscape used by the company for existing products as well as created an implementation proposal for the new API. Furthermore, we dived into the company’s existing B2B web applications to uncover UX challenges and recommend value-adding platform improvements.
• Champion's Perspective & Expectations: The company's champion had a vision - achieving flawless interoperability based on best HL7 FHIR practices. Documentation was paramount. In addition to the core task, as we provide an external user-centric perspective, we were asked to identify value-adding opportunities for the existing B2B applications. We thereby leveraged potential downtime during the main task into a period of innovation and creativity.

‍

Our Main Quest: Guiding HL7 FHIR Integration for a New App

Launch: Onboarded Very Fast

Recare had 2 product development teams working on 2 existing applications but wanted additional HL7 FHIR expertise to lead the definition of HL7 FHIR resources for the new application. We jumped in quickly, analyzed, and identified how the product requirements could be best reflected by FHIR resources. To avoid extra work for the team and inconsistencies we ensured to develop the proposal in line with the FHIR resources that had been established and implemented for the other apps.

First Deliverables and Results

1. Provided an internal documentation template, based on the expertise and experience of our team members on other interoperability projects, summarizing how the organization implemented FHIR elements in a way that was comprehensive and easily digestible to non-technical stakeholders.
2. Supported the development team by answering FHIR-implementation-related questions, thereby unblocking development tickets and meeting timeline requirements.

‍

Explore and Conquer: Solved for the Client

We started by analyzing the implementation of HL7 FHIR interoperability resources on the existing apps and understanding the product requirements for the new app.

📚 FHIR (Fast Healthcare Interoperability Resources) is an HL7 standard for the electronic exchange of healthcare information, designed to streamline implementation and maintain data integrity across healthcare systems. It utilizes modular "Resources" for effective data communication, ensuring quick and efficient interoperability for both clinical and administrative information. FHIR's significant role in healthcare data exchange is reinforced by regulatory mandates, such as the U.S. Centers for Medicare & Medicaid Services' Interoperability and Patient Access final rule, highlighting its critical importance in advancing healthcare interoperability.
Source: hl7.org

‍

📝 Initiative 1 - Document HL7 FHIR interoperability resources implementation across all Recare Apps

🤓 Problem:

• The team wished for a single source of truth for quickly determining how FHIR resources were implemented throughout the product landscape in Recare applications.
• This would enhance the speed of new product development, especially since the document would provide a North Star. This would mitigate the risk of inconsistencies with regards to the implementation of FHIR resources.

🎉 What we achieved:

• Analyzed all HL7 FHIR resources used across existing Recare applications.
• Developed a structured template, which was accessible to non-technical stakeholders, summarizing all implemented HL7 FHIR resources.
• Suggested improvements and best practices for implementation of HL7 FHIR resources and custom extensions as part of the review.

‍

😍 Initiative 2 - Define a solution to make the new product HL7 FHIR compliant

🤓 Problem:

• Recare had to build a new application, which included an API output in line with HL7 FHIR interoperability standards.
• Since the product requirements had to be mapped to suitable FHIR resources and in some cases, custom extensions (as no FHIR resource was readily available) would have to be determined to enable the team to build the new API.

🎉 What we achieved:

• Leveraged FHIR resources implemented in existing Recare applications to ensure consistency.
• Made recommendations for best practices concerning using custom extensions and further standardizing FHIR resources across the product portfolio.

‍

Discovery Side Quests

As we completed the required work quite quickly, we aligned with the champion in other areas in which we could add value.

Initiative 3 - Analyze two features in the existing Recare B2B applications, uncover potential opportunities, and suggest improvements.

🤓 Problem:

• The Recare product team was looking for opportunities to shorten and simplify the user journeys of the popular sender App features “Messenger” and “Stop Search” to further drive adoption and improve the user experience:
• The “Stop Search” feature allows hospitals to stop ongoing aftercare searches when the service is no longer needed, for example, relatives found a care home place outside of Recare’s discharge management process.
• The “Messenger” feature allows users to have an overview of all interactions between hospitals and aftercare providers for a specific patient search, communicate securely via end-to-end encryption, and exchange documents.

🎉 What we achieved:

• Created detailed User Flows to review the functionalities and highlight confusing UX, and UI inconsistencies, areas of potentially low customer engagement, and drop-out.
• Collected and analyzed customer data to infer pain points in collaboration with the business intelligence team.
• Proposed improvements based on the learnings to the product managers, engineering managers, and product designers.

‍

Initiative 4 - Support day-to-day work on other product teams

🤓 Problems:

• The new B2C app had a lot of new functional requirements and the team wanted to have external input to ensure the requirements were complete and the use stories could be finalized in line with the stringent launch timeline.
• QA due to other priorities specifically had limited testing and documentation capacities.
• The team experienced challenges in implementing efficient Slack communication considering the number of topics and context switches.
• Tools such as User Flows were not regularly used although the team recognized their value.

🎉 What we achieved:

• Critically reviewed >200 functional and non-functional requirements for the new app, and highlighted opportunities for further improvements.
• End-to-end tested the stop search and messenger features and provided detailed user flows with improvement suggestions.
• Created the “Test Register” Notion page to collect existing test cases and fail/pass criteria, thereby improving the visibility of QA work to non-QA team members.
• Wrote “How to…”-style Notion guides on leveraging Slack threads and prompts for more precise communication and creating user flows.

‍

Initiative 5 - Research BITV 2.0 Accessibility Guidelines and document them

🤓 Problem:

• Considering the nature of the project, the new B2C app had to be compliant with BITV2.0 accessibility standards.

📚 The BITV 2.0 standard, aligned with the WCAG 2.0 benchmarks, mandates German institutions to make their websites and applications accessible to people with disabilities. This includes ensuring that digital platforms are perceivable, operable, understandable, and robust for users of assistive technologies.It encompasses websites, mobile apps, intranets, extranets, electronically supported administrative processes, and graphical program interfaces. This regulation is part of Germany's commitment to enhancing digital accessibility under the Equal Opportunity Act (Disability Equality Act – BGG).
‍Source: accessi.org

🎉 What we achieved:

• Researched the accessibility standard with support from QA.
• Evaluated which accessibility test cases and implementations are relevant for the new application, and linked instructions for implementation based on best practices and BITV test cases.
• Set up documentation allowing to easily check which tests to perform.

‍

Mission Achievements: Delivered Outcomes

💡 Pioneered HL7 FHIR implementation framework for new B2C app while ensuring consistency across existing Recare platforms.

💡 Improved user experience by analyzing and revamping key features in existing apps.

💡 Optimized Recare's documentation by introducing a structured FHIR resources template, streamlining QA processes, and establishing best practice guides.