Let’s see what choices you can consider to store and manage health data.
After explaining the data model of FHIR in the first article and discussing the limitations of the nationally preferred coding systems in the second article, let’s see what the alternatives are for the persistence of clinical data. It is very important, when choosing the standard to use, to clearly define the purposes for which the data is to be managed, for example to support clinical practice or for the purpose of research and epidemiological analyses.
openEHR
openEHR is an open standard specification that describes the management and storage, retrieval and exchange of health data in electronic health records (EHR) with a longitudinal approach”one lifetime“, vendor-neutral and person-centred.
The openEHR specifications are maintained by the openEHR Foundation, a non-profit foundation that supports the research, development and implementation of openEHR electronic health records. The specification is based on a combination of 15 years of European and Australian EHR research and development and new paradigms, including what has come to be known as the archetype methodology for content specification.
openEHR is based on four key elements:
the information models (alias “Reference Model”); the formalism of the archetypes the interrogation language of the archetypes; The service models / APIs.
The first two allow for the development of ‘archetypes’ and ‘models’, which are formal models of clinical content that constitute a layer of de facto standards in their own right. The query language allows you to build queries based on database archetypes, rather than the physical schemas, thus decoupling queries from the physical details of persistence. Service templates define access to key backend services, including the EHR service and demographics service, while a growing set of lightweight APIs based on REST and archetype paths are used for application access.
Reference model
The set of information models define the invariant semantics of the Electronic Health Record (EHR), EHR Extract and Demographics models, as well as data types, data structures and identifiers.
Key entities include the ENTRY classes, whose subtypes include OBSERVATION, EVALUATION, INSTRUCTION, ACTION, and ADMIN_ENTRY, as well as the Instruction State Machine, a state machine that defines a standard model of the lifecycle of interventions, including medications, surgery and other therapies.
Archetypes and templates
openEHR decouples the specifics of clinical information from the information model (also known as the “reference model”). Clinical contents are defined through two types of artefacts that are outside the information model.
The first, known as the “archetype”, allows for the formal expression of point data and groups of data that can be reused in different contexts such as, for example, blood pressure or sodium measured in serum. A collection of archetypes composes a “library” of reusable content definitions. The archetypes are expressed with ADL – Archetype Definition Language, a public specification which together with its counterpart AOM – Archetype Object Model – are the basis of the CEN and ISO standard “Archetype Definition Language” (standard ISO 13606-2). The archetypes are managed independently of software implementations and infrastructures, by groups of clinicians.
The second type of artifact are templates that are used to represent a set of data specific to a use case, such as the elements that make up a patient’s discharge letter or a radiology report. Templates include elements of one or more archetypes and are typically created by software developers and clinical analysts.
AQL, the archetype query language
Archetype Query Language (AQL) is a declarative query language developed specifically for searching and retrieving data in archetype-based databases. The examples used in this specification refer mainly to the reference model (RM) and openEHR clinical archetypes, but the syntax is independent of information model, application, programming language, system environment and storage model .
Clinical Knowledge Manager
The Clinical Knowledge Manager is a collaborative, open source tool that allows sharing, discussing and approving archetypes and their structures within the openEHR community. There are several software that perform this role that can be downloaded and installed for free.
openEHR is used by Australia’s National e-Health Transition Authority, the UK’s NHS Health and Social Care Information Center (HSCIC), the Norwegian organization Nasjonal IKT and the Slovenian Ministry of Health. It was also chosen as the data model for the Electronic Health Record of Brazil. Then there are some commercial solutions around the world based on openEHR.
OMOP Common Data Model
The Observational Medical Outcomes Partnership (OMOP) Common Data Model (CDM) is a standard used by the Observational Health Data Sciences and Informatics (OHDSI) association in scientific research to represent the format and content of observational data, so that applications can be used , tools and methods standardized to different clinical datasets. OHDSI maintains an open-source library of analytical tools for research and performance measurement using OMOP CDM. Standardized structured language (SQL) queries are shared in a common open-source repository, and detailed data documentation is freely available online.
OMOP CDM’s patient-centric data structure includes standardized OHDSI vocabularies that define medical terms used in various clinical domains and is managed using relational SQL databases. Using queries, you can perform standardized analyzes that leverage the OHDSI knowledge base to construct exposure and outcome phenotypes and other characteristics for characterization, population-level effect estimation, and patient-level prediction studies.
The current version of the CDM is 5.4 and is used by numerous research institutions around the world, including Italy. Its nature makes it particularly effective in scientific research, but it is less suitable for managing data for clinical practice.
Other clinical models
Several clinical solution manufacturers have developed their own clinical models that interoperate through APIs or popular standards including FHIR. However, the adoption of a proprietary model determines a lock-in of the supplier with all the ensuing consequences.
3 – fine
I like:
Like Loading…