Digital Health solutions are more complicated than they first appear! Don’t start from scratch… Build for the future, using this Data Model as the foundation for your health data.
There are many healthcare problems that require many different solutions. Modern Digital Health solutions can’t exist in isolation. They need to exchange data with other systems and this data exchange (also known as Interoperability) needs to be done in a standard way so that different systems can interpret the data consistently with its original and intended meaning. The most widely adopted standard globally is HL7 (Health Level Seven) FHIR (Fast Healthcare Interoperability Resources) and it’s a standard that is already mandated in multiple countries.
However, the HL7 FHIR standard is quite complex and difficult to work with. For example, OutSystems doesn’t natively support the flexible nature of the FHIR resource data definition (e.g. recursive nested structures). In addition, many of the attributes require specific values from value sets defined by various coding systems. All of these add complexity and can severely slow down the development and delivery speed we are used to when building low-code applications with OutSystems. It also increases the risk of errors and exceptions that are often only discovered late in the process, or worse… in Production.
We created the Interoperable Health Data Model to make it a lot easier to implement modern digital health solutions with OutSystems, that are built for the future and are “Interoperable by Design”.
Interoperable by Design simply means that the Data Model included with this component is designed with healthcare interoperability in mind. The goal is to structure your data in a way that is easier to work with today, while making sure that full interoperability can be achieved when required.
Practically speaking, if you store data in the provided data structures and use valid values from the provided lists of options where applicable, then your data is able to be translated to and from HL7 FHIR resources when needed. This translation is enabled by our Healthcare Interoperability Components for OutSystems.
The Interoperable Health Data Model includes data structures and lists of valid options that have been designed to be compatible with the HL7 FHIR R4 standard.
For example, if you want to work with Patient data, then you’ll want to use the Patient_v2 data structure.
Please refer to the component’s Description for an up to date list of all the healthcare data structures currently included. This list will grow as we add more data structures in future versions. If there is something in particular that you need in your project, and it is not already included, please contact us here or post a support discussion in the forum.
Some of the attributes should only have values from specific lists of options in order to be interoperable (i.e. able to be translated to semantically coded HL7 FHIR elements). The attributes where this restriction applies will have instructions in the attribute description pointing you to the action you should use to get all the valid options for that attribute.
For example, the Patient_v2.MaritalStatus attribute has a corresponding Patient_MaritalStatuses service action which has been noted in the attribute’s description. This action allows you to get the DropdownOptions List containing valid interoperable values.
Simply because we believe that health data sharing leads to better patient outcomes and a huge relief to the administrative burden of the healthcare systems involved. We are big advocates for healthcare interoperability and want to enable more digital health solutions to be interoperable.
Unfortunately, in most healthcare projects we’ve seen so far (hopefully this will change over time), interoperability is not a Version 1 requirement, if it is even considered at all at the start.
At KRE8 IT, we specialise in Healthcare Interoperability, so we created these building blocks as the data foundation we use for building digital health solutions with OutSystems, even if interoperability is not yet in scope, because we know it will be sooner or later.
We decided to share this foundational data model with the OutSystems community for free, so you too can build modern digital health solutions that are interoperable by design. You’re welcome!
The IHDM Sample App is a demonstration of how one might build a simple “list and detail” CRUD application, focusing on the Encounter Structure as its domain model. We might imagine this application being the centrepiece of the administrative workflow at a primary care clinic, where Patients’ bookings, appointments and interactions with clinicians are captured.
The IHDM Sample App demonstrates how to
As you explore the IHDM Sample App, look out for the following patterns:
Saving Data
Specific actions are responsible for creating and updating data for each of the structures. For example, the SaveEncounter action should exclusively be used to create and update Encounter_v2 data in the database, while the SavePatient should be used in the same manner for the Patient_v2 structure.
Fetching a single record
Retrieving a record from the database, where its GUID identifier is known, should be done using actions such as ReadEncounter, ReadPatient, and so on for other structures in the Interoperable Health Data Model.
Notice that the input and output parameters for all of the Read<Structure> and Save<Structure> actions mentioned above only exchange data using structures from the Interoperable Health Data Model, rather than directly using database entities titled “Patient_Summary” or “Encounter_Summary” as would typically be done in an OutSystems application.
Fetching and filtering a list of records
The main purpose of the Read<Structure> and Save<Structure> actions is to store, version and retrieve the Structures in their full, nested and self-contained form, using data stored in the ResourceVersion entity. In addition to this, certain key attributes from each Structure are summarised on a separate entity, for ease of use in aggregates. For example, the Patient_v2 Structure has a corresponding entity Patient_Summary, while the Encounter_v2 Structure has a corresponding entity called Encounter_Summary.
These “summary” entities do not contain all of the data associated with their Structure counterpart; instead, select data that might be useful for filtering, sorting, grouping or joining is populated on the summary entity whenever a particular Save<Structure> action is called. Once the desired summary record has been filtered and retrieved, its GUID identifier may be used to retrieve the full record using Read<Structure>.
Important:
Populating a dropdown with valid options
Some attributes in the Interoperable Health Data Model are said to be “bound” to a set of values. This means that such an attribute has a particular list from which its values should be drawn. For example, the Encounter_v2 structure has an attribute called Status which, despite the fact that it can technically accept any Text value, should only take one of the following values: “planned”, “arrived”, “triaged”, “in-progress”, “onleave”, “finished”, “cancelled”, “entered-in-error”, “unknown”.
These values are defined as part of the FHIR specification, and using them correctly is the secret to ensuring that other systems will be able to easily consume data from your application, without a tedious process of data mapping. In addition to these values, FHIR also provides human-readable labels and definitions which, is the case of Encounter_v2.Status, look like:
Source: https://hl7.org/fhir/R4/valueset-encounter-status.html
Often, the most intuitive way for an application to accept data from a list of values is to use a dropdown list - in OutSystems, this might be a Dropdown, Dropdown Tags or Dropdown Search widget. To aid in this, the Interoperable Health Data Model application provides a collection of “options” Server Actions, one for each set of values required by an attribute, which return a DropdownOption List containing all of the values and labels. On the front-end, this list may be fetched using a Data Action, and used as an input parameter to any of the dropdown widgets provided by OutSystemsUI.
To find the correct “options” action for an attribute, see the end its description for the name of the correct action to use, e.g. for Encounter_v2.Status:
…Only use options from the Encounter_Statuses action.
All such actions can be found in the InteropHealthData_Lib module under the folder corresponding with the data structure (e.g. ‘Encounter’ folder).