We use cookies
Agree
Pavel Rozhkov, Ilya Beda
Illustrations: Nikita Nikiforov
Illustrations: Nikita Nikiforov
The implementation of FHIR Structured Data Capture
Low-coding solution for modern medical applications
The problem
With the progress of the Internet, technology, and medicine, a large number of tools appear that allow clinicians to control the process of treating a patient, establishing a diagnosis, patient's parameters monitoring, and so on. Systems such as electronic patient records, medical data management systems, and medical decision support systems are becoming more widespread.
All these systems can be combined into one and are called a medical information system. As clinicians, we can view the health information system as a black box. This black box can take information as input and produce information as output. Logic can be hidden in the box itself; for example the prediction of the disease, the prediction of the course of the disease, the recommendation of drug therapy, etc.
An important part of such systems is the input and output of information for the clinician. The clinician should be able to use fast, smart, and clear data entry tools. If we are talking about a web application, then a web form acts as a tool for entering information. When we consider a form as a subject for development, we must take care of the following aspects: data management and validation at the endpoint on the server side; form management and display on the client side; user input validation control on the client side.
In addition, if we are talking about a medical application, then in such an application it should be possible to create custom forms for the clinician. A custom form can be used as a survey for collecting and saving a patient's history or a survey in a clinical trial.
All these systems can be combined into one and are called a medical information system. As clinicians, we can view the health information system as a black box. This black box can take information as input and produce information as output. Logic can be hidden in the box itself; for example the prediction of the disease, the prediction of the course of the disease, the recommendation of drug therapy, etc.
An important part of such systems is the input and output of information for the clinician. The clinician should be able to use fast, smart, and clear data entry tools. If we are talking about a web application, then a web form acts as a tool for entering information. When we consider a form as a subject for development, we must take care of the following aspects: data management and validation at the endpoint on the server side; form management and display on the client side; user input validation control on the client side.
In addition, if we are talking about a medical application, then in such an application it should be possible to create custom forms for the clinician. A custom form can be used as a survey for collecting and saving a patient's history or a survey in a clinical trial.
Let's imagine that we want to make a classic medical information system. We can use popular development tools such as Python and JavaScript.
To make a medical information system, we need to make a database for which we want to describe the data schema. Next, we must describe the data models that we will manipulate. Perhaps these models will have some complex specialized methods for working with their attributes.
Next, on the backend, we need to write endpoints for manipulating models. So that we can upload, create, edit, and delete instances. It is likely that these endpoints will require writing automated tests to make sure they work correctly and this will allow you to control code regression in the future.
Then we move to the frontend. On the frontend, we need to develop forms for each entity. For each form, we will manually need to describe the fields that these entities use. In addition, you will need to describe the validation scheme, error handling, and so on.
If we are talking about several platforms, for example, Web, Android, and iOS. These steps will have to be repeated for each platform.
In real life, with this approach, we identified a list of concerns:
1. To create a questionnaire, the practitioner have to transfer expert knowledge and requirements to the software developer;
2. If there are several target platforms, then it is required to transfer this knowledge to several software developers;
3. To create a form, the developer have to work with several sources of knowledge: on the frontend (form and validation) and on the backend (endpoint, validation and saving);
4. Manual testing will be available only after the software developers have completed work on the questionnaire. It is possible that after testing all these steps will have to be repeated.
All these problems require the involvement of a large number of specialists. As a result a client has an increased project development time and costs.
So, we decided to review other approaches and chose an optimal one. That's how we found FHIR SDC Implementation guide.
To make a medical information system, we need to make a database for which we want to describe the data schema. Next, we must describe the data models that we will manipulate. Perhaps these models will have some complex specialized methods for working with their attributes.
Next, on the backend, we need to write endpoints for manipulating models. So that we can upload, create, edit, and delete instances. It is likely that these endpoints will require writing automated tests to make sure they work correctly and this will allow you to control code regression in the future.
Then we move to the frontend. On the frontend, we need to develop forms for each entity. For each form, we will manually need to describe the fields that these entities use. In addition, you will need to describe the validation scheme, error handling, and so on.
If we are talking about several platforms, for example, Web, Android, and iOS. These steps will have to be repeated for each platform.
In real life, with this approach, we identified a list of concerns:
1. To create a questionnaire, the practitioner have to transfer expert knowledge and requirements to the software developer;
2. If there are several target platforms, then it is required to transfer this knowledge to several software developers;
3. To create a form, the developer have to work with several sources of knowledge: on the frontend (form and validation) and on the backend (endpoint, validation and saving);
4. Manual testing will be available only after the software developers have completed work on the questionnaire. It is possible that after testing all these steps will have to be repeated.
All these problems require the involvement of a large number of specialists. As a result a client has an increased project development time and costs.
So, we decided to review other approaches and chose an optimal one. That's how we found FHIR SDC Implementation guide.
Solution concept
Questionnaire-based approach for application development
The core of the solution is the FHIR Health Information Exchange Standard. It opens up the possibility for us to use entities called resources. Resources are structures that can be used in all business processes of a medical institution.
To describe the forms, the FHIR suggests using a resource called a Questionnaire. A Questionnaire is an organized collection of questions intended to solicit information from patients, providers, or other individuals involved in the healthcare domain. They may be simple flat lists of questions or can be hierarchically organized in groups and sub-groups, each containing questions.
In addition, FHIR offers a SDC (Structured Data Capture) implementation guide. The Structured Data Capture (SDC) Initiative identifies and recommends standards for the interoperable representation and transmission of the following:
We have designed and developed our open source product, which is based on FHIR SDC.
To describe the forms, the FHIR suggests using a resource called a Questionnaire. A Questionnaire is an organized collection of questions intended to solicit information from patients, providers, or other individuals involved in the healthcare domain. They may be simple flat lists of questions or can be hierarchically organized in groups and sub-groups, each containing questions.
In addition, FHIR offers a SDC (Structured Data Capture) implementation guide. The Structured Data Capture (SDC) Initiative identifies and recommends standards for the interoperable representation and transmission of the following:
- Standard form designs;
- Querying for form;
- Return a form;
- Submit completed form data to an external data repository
We have designed and developed our open source product, which is based on FHIR SDC.
Playground
You can play with Questionnaire on our demo website for better understanding this resource
Development of Questionnaire in SDC IDE
This screencast shows the development process with Questionnaire from a developer's point of view. A questionnaire that is transformed after the user fills in QuestionnaireResponse, which then passes through the Mapper resource and in the end we get the Patient resource with updated information.
PART III
Rendering Questionnaire as a form
Step by step details
Step I. Assemble
Compilation of a large questionnaire from several small ones
Medical information is often very complex and voluminous. To collect high-quality patient history, the doctor needs to fill in a large number of fields that relate to different areas of the patient's life. For example personal data, demographic data, chronic diseases, patient complaints, subjective state of the patient, and objective state of the patient.
In this case, one questionnaire may include up to 50 or more questions. In the future, such questionnaires will be difficult to maintain and understand what is happening in them at all.
This stage is primary when loading and forming the form on the client side.
For such cases, we use the assemble operation that allows you to embed questionnaires into other questionnaires. In this case, we can create several small questionnaires, for example for personal data, chronic diseases, and current patient complaints. And connect these questionnaires to the main questionnaire, which will be used, for example, at a patient's appointment in a hospital.
This approach opens up the following pros for medical organizations:
1. Convenient management of small questionnaires;
2. Possibility of reuse in the future for other parts of the system. For example, some parts of a large "doctor's appointment" questionnaire can be used in other forms: editing patient data, receiving patient complaints in a call center, and so on.
In this case, one questionnaire may include up to 50 or more questions. In the future, such questionnaires will be difficult to maintain and understand what is happening in them at all.
This stage is primary when loading and forming the form on the client side.
For such cases, we use the assemble operation that allows you to embed questionnaires into other questionnaires. In this case, we can create several small questionnaires, for example for personal data, chronic diseases, and current patient complaints. And connect these questionnaires to the main questionnaire, which will be used, for example, at a patient's appointment in a hospital.
This approach opens up the following pros for medical organizations:
1. Convenient management of small questionnaires;
2. Possibility of reuse in the future for other parts of the system. For example, some parts of a large "doctor's appointment" questionnaire can be used in other forms: editing patient data, receiving patient complaints in a call center, and so on.
Step II. Populate
Using Existing Data to Control Form Behavior
Populate operation scheme
The populate function allows us to pre-populate data that already exists in the system. Here are some examples of how populate functionality can be used:
1. We want to make a form for editing the patient's demographic data, such as mobile phone, email address, etc. This data is available to the developer in the Patient resource. In this case, we can pass the patient as a LaunchContext and use it in the questionnaire as initialization data.
2. We want to make some kind of regular questionnaire that the patient should take. And let's say there will be a situation when the patient did not answer all the questions, for whatever reason. We can save the QuestionnaireResponse resource and use the data from it as data for initialization.
3. Form behavior control. We can control what kind of form it will be. For example, we want the form to be read-only or, for example, this form will be only for editing a resource. In this case, we can pass specialized pointer flags to the LaunchContext in order to use them in the form later.
The populate function performs a very important function. It allows you to initialize the basic data in the questionnaire, which saves time and reduces the number of potential data entry errors.
1. We want to make a form for editing the patient's demographic data, such as mobile phone, email address, etc. This data is available to the developer in the Patient resource. In this case, we can pass the patient as a LaunchContext and use it in the questionnaire as initialization data.
2. We want to make some kind of regular questionnaire that the patient should take. And let's say there will be a situation when the patient did not answer all the questions, for whatever reason. We can save the QuestionnaireResponse resource and use the data from it as data for initialization.
3. Form behavior control. We can control what kind of form it will be. For example, we want the form to be read-only or, for example, this form will be only for editing a resource. In this case, we can pass specialized pointer flags to the LaunchContext in order to use them in the form later.
The populate function performs a very important function. It allows you to initialize the basic data in the questionnaire, which saves time and reduces the number of potential data entry errors.
Step III. Expand
Applied use of medical terminology systems
Expand operation scheme
Medicine is a field of knowledge-rich in terminology. For each action of a doctor or business process in a hospital, clinic, intensive care unit, etc., there are predefined terms that help doctors better understand each other, regardless of the place of residence and language.
Here are some use-cases where you need clinical terminology::
1. The doctor prescribes some medication to the patient;
2. The patient indicates the existing chronic diseases;
3. The nurse indicates what medical manipulation is being performed at a given time.
To make such forms, you will need to prepare a large number of choices in the form. Embedding these choices into the form causes the following issues. It is hard to control the correctness of these terms. Each terminology update requires a form definition update. The FHIR resource called ValueSet comes to the rescue.
To put it simply, this is a resource that stores a set of medical terminology concepts. To use it, it is enough to indicate its identifier in the questionnaire. In this case, the questionnaire will retain a minimalistic appearance, but when the questionnaire is displayed on the client side, the specialized expand function transforms the questionnaire and makes it possible to select options from this ValueSet.
Here are some use-cases where you need clinical terminology::
1. The doctor prescribes some medication to the patient;
2. The patient indicates the existing chronic diseases;
3. The nurse indicates what medical manipulation is being performed at a given time.
To make such forms, you will need to prepare a large number of choices in the form. Embedding these choices into the form causes the following issues. It is hard to control the correctness of these terms. Each terminology update requires a form definition update. The FHIR resource called ValueSet comes to the rescue.
To put it simply, this is a resource that stores a set of medical terminology concepts. To use it, it is enough to indicate its identifier in the questionnaire. In this case, the questionnaire will retain a minimalistic appearance, but when the questionnaire is displayed on the client side, the specialized expand function transforms the questionnaire and makes it possible to select options from this ValueSet.
Step IV. Constraint check
Using the validation logic directly in the questionnaire
Constrain check operation scheme
The correctness of the entered data is an integral part of any business process, including medicine.
Questionnaires contain a large number of input data. Since these data are entered by people, this implies the possibility of an error when filling out.
For example, we want the user to be sure to answer some question, or we want the data that he entered could only be of a certain type: integer, text, and so on. In addition, there may be tricky cases where we want to verify that the user has entered a unique email address or that they are at least the minimum required age.
For such cases, we use a special operation called constraint check. This feature allows developers to use simple and complex conditions to validate data. These conditions can be easily described using FHIRpath and validated by the system. In addition, it is possible to specify an error for the developer and for the client to display a convenient human-readable error.
With this approach, developers do not need to write special validation methods on the server side, everything can be described in one Questionnaire file.
Questionnaires contain a large number of input data. Since these data are entered by people, this implies the possibility of an error when filling out.
For example, we want the user to be sure to answer some question, or we want the data that he entered could only be of a certain type: integer, text, and so on. In addition, there may be tricky cases where we want to verify that the user has entered a unique email address or that they are at least the minimum required age.
For such cases, we use a special operation called constraint check. This feature allows developers to use simple and complex conditions to validate data. These conditions can be easily described using FHIRpath and validated by the system. In addition, it is possible to specify an error for the developer and for the client to display a convenient human-readable error.
With this approach, developers do not need to write special validation methods on the server side, everything can be described in one Questionnaire file.
Step V. Extract
The step at which data makes sense
Extract operation scheme
The questionnaire may contain a large amount of information:
1. Patient's personal data;
2. Chronic diseases;
3. Current complaints;
4. Subjective and objective states;
5. Prescribed medications;
6. Future consultations.
The QuestionnaireResponse resource is not the best option to store data. It is not search-friendly and it is challenging to analyze unstructured QuestionnaireResponse data. It is more suitable to operate with FHIR resources like Patient, Condition, Observation, MedicineStatement, Appointment, etc.
To do it, we should transform the data from the QuestionnaireResponse and create, edit or delete FHIR resources.
In this case, the Mapper resource comes to the rescue, which allows you to describe in a declarative form the data that you want to take from the QuestionnaireResponse and the actions that you want to perform with this data.
This approach allows us to declaratively specify what information we expect and what we want to do with it.
1. Patient's personal data;
2. Chronic diseases;
3. Current complaints;
4. Subjective and objective states;
5. Prescribed medications;
6. Future consultations.
The QuestionnaireResponse resource is not the best option to store data. It is not search-friendly and it is challenging to analyze unstructured QuestionnaireResponse data. It is more suitable to operate with FHIR resources like Patient, Condition, Observation, MedicineStatement, Appointment, etc.
To do it, we should transform the data from the QuestionnaireResponse and create, edit or delete FHIR resources.
In this case, the Mapper resource comes to the rescue, which allows you to describe in a declarative form the data that you want to take from the QuestionnaireResponse and the actions that you want to perform with this data.
This approach allows us to declaratively specify what information we expect and what we want to do with it.
Debugging of the Patient's Mapper in SDC IDE
This screencast shows the process of debugging a mapper. As you can see, the developer uses a form to enter data. As a result, the developer will receive a transaction that will be used as a result of the mapper. In this case, a patient will be created with the data entered in the form.
Step IV. Form configuration
It is important to use a user-friendly, branded design for forms. SDC provides the ability of widget customization. You can use any tool you want to configure input components. We prefer the StoryBook This tool allows you to develop and test your components in an isolated environment. You can test inputs and outputs, configure props, and so on.
Add support for date type question via StoryBook
In this example, we are adding support for the DateTime question type for the Questionnaire form
By using the Questionnaire based approach with FHIR SDC you get stable, fast and smart forms on any target platform.
PART IV
Summary
Let's revise issues from the start of this article and take a look at how SDC solves those issues.
The Questionnaire FHIR resource is a standard way of describing a form that is applicable to medical profile tasks. It is convenient, logical, and well documented. And now, instead of transferring their expertise to software developers, the practitioner can use this resource to prepare the form. With this approach, it is not necessary to involve additional software developers to prepare the form for other platforms. Because Questionnaire will work the same for web, mobile and desktop. With FHIR SDC, no longer need to work with multiple sources of knowledge. The only sources of knowledge now are Questionnaire and Mapper. These FHIR resources have everything you need for correct functionality of the Form. Questions, their types, data to populate, validation rules and information about how and where this data should be saved. In addition, there are many FHIR compatible tools for creating questionnaires. The doctor can create, edit questionnaires and visually see the result.
We successfully apply this approach in all projects. With this approach, we have significantly reduced the time and cost of developing medical information systems of any complexity.
We successfully apply this approach in all projects. With this approach, we have significantly reduced the time and cost of developing medical information systems of any complexity.
Sources
- ReferenceDescriptionFHIR is a standard for health care data exchange, published by HL7®.
- ReferenceDescriptionThe base FHIR specification defines these resources but doesn't provide much guidance around how they should be used, nor does it set minimal expectations for interoperation.
- DescriptionSDC spec implementation as Aidbox application
- ReferenceDescriptionDemonstration of our tooling for working with questionnaire forms
Appendix
Video materials
Get free consultation
If you already have a project in mind or just want to talk about an idea you have, just drop us a line to hi@beda.software and we'll be happy to chat.