Areas to review before launching healthcare applications based on Infermedica API.
Security & legal requirements
- App ID and App key are hidden from the end-user
- Legal disclaimers and Terms of Service are confirmed with legal experts
and available for end-users. - Avoid misleading communication with end-users.
Example: Avoid keywords or phrases suggesting a “medical diagnosis” is being made. Instead, say Infermedica API provides “symptom assessment” and “triage”.
Interview flow
- Sex and age attributes are two required elements of every request to ‘/diagnosis’.
Sex and age are passively accounted for and used to automatically instantiate corresponding risk factors that may alter the base prevalence of medical conditions in Infermedica’s model. Make sure to use the age attribute when using the ‘/parse’ and ‘/suggest’ endpoints. GET requests for: ‘/symptoms’, ‘/conditions’, and ‘/risk_factors’ should also use the age attribute. Use the sex parameter for the ‘/suggest’ endpoint. Details here. - The scope of age is narrowed to the user's group.
Even though Infermedica API allows any range of ages to be set up, configuring the age range for adults to between 18 and 120 and for children to between 1 day and 18 years old is recommended. - The “should stop” feature is enabled.
Your application is required to use the stop condition feature. This feature determines when the interview should end, which is usually once the right number of initial symptoms has been collected. This is required to use the API properly. Details here. - Common risk factors are added to the interview flow.
This includes chronic conditions, lifestyle habits, events, and recent travel. Details here. - Common risk factors are related to patient demographics.
This is an additional mode in the ‘/suggest’ endpoint, which has risk factors related to the given patient’s age and sex. Details here. - Initial symptoms are marked as "source": "initial".
Using this attribute is highly recommended for evidence reported before the interview starts. We recommend having at least two initial symptoms. Details here. - The "related symptoms" feature is used.
This feature can be added with the ‘/suggest’ endpoint (related symptoms).
Adding it will likely shorten the interview and improve the accuracy of the results. The application should make use of ‘/suggest’ after collecting the initial symptoms and before going into the ‘/diagnosis’ flow. We recommend showing this question only when there are more than two possible symptoms. Details here. - Related symptoms are marked with "source": "suggest".
By tagging the evidence with its source, the engine can mark the exact stage of the interview in which the evidence was collected. The engine can thereby provide a more relevant interview, a more accurate triage level, and a better final list of possible conditions. Details here. - The output from ‘/diagnosis’ displays common names.
If the end-user is not a health professional, displaying each condition’s ‘common_name’ instead of ‘name’ is recommended. - Interview-ID.
Including a custom HTTP header Interview-ID is recommended as it will help us find and analyze a particular case should there be questions or concerns regarding a specific interview. Additionally, it helps to improve Infermedica’s statistical models. Details here.
Additional features
- Data from the ‘/triage’ endpoint is used.
Infermedica API provides a ‘/triage’ endpoint that is complementary to the ‘/diagnosis’ endpoint. It can categorize the provided patient cases based on the seriousness of reported observations and the severity of likely conditions. Details here. - Data from ‘/rationale’ endpoint is used.
The rationale feature gives more transparency and insight into the internal logic of the question selection process. Such information can be displayed to the end-user during the interview to improve the user’s understanding and confidence in the process. Details here. - Data from the ‘/explain’ endpoint is used.
This endpoint allows you to display how reported observations are linked with the final results. For example, you can use this endpoint in the results page to display "reasons for" and "reasons against" particular conditions. This feature provides insights into why certain conditions were considered by the reasoning engine and increases the credibility of the results presented to the end-user. Details here. - Data from the ‘/enable_explanations’ endpoint is used.
The purpose of this option is to provide additional descriptions of selected questions to make them easier to understand for users. Details here. - Data from the ‘/enable_third_person_questions’ endpoint is used.
This option allows you to create an interview scenario in which users can answer questions on behalf of someone else, e.g. "Does she have a headache?". Details here. - Data from the ‘/recommend_specialist’ endpoint is used.
This endpoint extends the ‘/triage’ recommendation by providing the most appropriate specialist and communication channel as a part of the next step of advice. Details here.
User experience
- User needs are answered.
Think about the users. What are their goals? How can this application help them? In our experience, apps that solve a real problem
perform best. - Navigation is seamless.
Make sure that the navigation in the application is intuitive and consistent.
If the application consists of more than one screen, it’s good practice to design a progress bar. - Application styles are consistent.
We recommend creating a style guide, or at least defining the basic styles for the application. The typography, colors, and components (buttons, inputs, etc.) should be used consistently. Every element that serves the same purpose should look the same. If the application is embedded in a larger system, adjust the styles of both parts. - Icons and visual language are used.
Adding custom icons and illustrations to the application is recommended. People like to use products that are usable and look great. - Additional content is added.
The application is enriched with additional content, such as a welcome message, triage level descriptions, next steps to take, etc. - Accessibility is good.
The application should be accessible to a wide range of people, including those with disabilities. Don’t know where to start? Follow the WCAG 2.1 recommendations. - Mobile users have access.
Make sure that the application is responsive and works on mobile devices,
even those with a poor internet connection. - Copywriting is optimized.
Most of the time, the application will communicate with users through text. How can you ensure this is done right? A good rule of thumb is to be concise and efficient, yet friendly and polite. - Analytics tools are implemented.
Use analytics tools (e.g. Google Analytics) to measure the application's performance. If you’re building a symptom checker for patients, we recommend tracking at least one indicator – the conversion rate. That way, if you notice a drop in conversion on a particular screen, you can improve that screen.
More detailed information is available on our Developer's Portal at: developer.infermedica.com.
AKw, NBo