HHR modelling approach (II) - The CrowdHEALTH paradigm

The main goal of CrowdHEALTH is to provide tools for supporting the development and evaluation of health policies. A key element of the CrowdHEALTH platform is the Holistic Health Record (HHR) model which represents clinical events and laboratory test results, but also properties about lifestyle, social care, personal measurements, environment. Such data may be collected or produced by medical operators, by the citizens themselves or by automatic sensors.

It is well known that there are already plenty of data models adopted in the health domain. Standards for health data exchange, such as CCR, DICOM, HL7 CDA, HL7 RIM, HL7 FHIR, openEHR, CEN/ISO EN13606  covers more clinical information produced by health professionals and are exploited by health institutions worldwide for their EHR (Electronic Health Record) systems. Specific health data models, have also been defined for representing information used for or produced by medical researchers, such as HCSRN’s Virtual Data Warehouse (VDW) and Observational Medical Outcomes Partnership (OMOP) model.

Unfortunately, no one of the aforementioned data models represents alone all kind of information used by CrowdHEALTH use cases. Moreover several standards are focused mainly on data exchange, while the CrowdHEALTH project needs a model to support also data integration and analyses. That is why CrowdHEALTH developed the HHR model.

Is CrowdHEALTH proposing to substitute the existing health data standards with another more complete one? Actually no. Indeed the HHR model is an application of one of the aforementioned standards, that is HL7 FHIR.

A peculiarity of CrowdHEALTH is that a FHIR profile is specified by means of a conceptual model: the HHR model. More precisely, the HHR model is the conceptual model of a FHIR profile.

We refer to the traditional distinction between conceptual, logical and physical schema. FHIR defines a logical schema (because the structure of data is constrained by the characteristics of REST architecture), and a FHIR profile is a set of constraints and extensions on such alogical schema (producing a more specific logical schema). Instead, the HHR model is a conceptual schema, i.e. it is independent from specific implementation architectures. The HHR model is represented using UML, like the FHIR schema, but do not make distinctions that are specific to the REST architecture (e.g. do not distinguish nested objects from referred objects). Moreover, it makes explicit conceptual distinctions that are implicit in the FHIR schema.For instance, the cardinality constraints of the HHR model refer to the existence of relations in the real world instead that into a FHIR repository and it explicitly distinguishes the properties of similar concepts such as a hospitalization encounter froman outpatient encounter.

While a FHIR profile have no standard visual representation, the HHR conceptual model have an UML representation that is more comprehensible also to people that have no knowledge of FHIR.

Being the HHR conceptual model independent from FHIR, this kind of representation allows to produce alternative implementations (i.e. physical models) for the same type of data. Therefore it allows to use a FHIR implementation (e.g. HAPIFHIR), but it is also possible to automatically produce, as done for the HHR manager developed within the project, an alternative Java representation that simplifies the in-memory manipulation of data, produce less verbose serializations, and allows to perform additional semantic checks at static time.

In a similar way, other implementations could be automatically derived from the HHR conceptual model, to improve the performance of specific kind of queries or analytics.