Clinical Information Modeling (or just Clinical Modeling) is a key area on any Health Informatics project. This process is needed to determine which information will be managed by Information Systems, and how it will be stored, processed, visualized, used, shared and integrated in an wider eHealth Platform.
Clinical information is not only important for health care, it is important to derive health care costs, enable better clinical decision support, allow correct epidemiological analysis, calculate indicators for better management, and enables clinical research and education. Bad clinical information models play against all these factors and needs, and reduce the system's capacity to interoperate and provide timely clinical decision support for better health care quality.
For these reasons we need to look for a systematized approach, based on standards and best practices for clinical information modeling. An approach to generate good models to allow getting the most out of Health Information Systems.
Today most companies don't give much importance and don't dedicate enough time to design good clinical information models when developing new systems, negatively affecting the whole software architecture in the long term. There are other companies that dedicate more resources to the clinical information modeling process, but the process is lead and executed by IT professionals, who are not trained on areas like clinical records, processes and terminology, that are needed to design good information models. On the other hand, clinicians know these areas very well, but are not trained on information modeling, that implies analysis, abstraction, classification and organization, areas IT professionals are trained on.
As you can guess, Clinical Information Modeling should be a multidisciplinary process, where we need to apply the formal methodologies of Information Modeling, but specific to a domain so vast and complex as Health Care is. Considering this, the first recommendation is to have a team of modelers, with at least one clinician with a Medical Informatics profile with knowledge on standard terminologies like SNOMED CT and LOINC, and one IT professional with experience in Health Care, and specifically on Information Modeling methodologies like Object-Oriented Modeling and UML.
Context
Before talking about the Clinical Modeler role, and the tasks included in the Clinical Information Modeling process, we need to know that:
1. Clinical information is heterogeneous (structures can vary a lot depending on the requirements)
2. Clinical information is complex (there are a lot of different types and structures, a lot)
3. The needs for recording and consuming clinical information varies between different medical specialties, type of care and level of care.
So, Clinical Modeling is not an easy task, requires a lot of knowledge and experience to create good models for each need and context.
The Clinical Modeler role
The Clinical Modeling Team will be in charge of all the Clinical Modeling tasks needed before developing any Clinical Software. The models, documentation, and other materials and artifacts generated during this process, will be the main input resources for Software Architects and Engineers to design the different components of Clinical Software for recording, processing, visualizing and sharing clinical information. These components go from databases, to screens and interfaces between systems. Software architectures usually include some kind of Interoperability Platform where information is shared between different components, and Clinical Modeling will determine the representation of all the information that will be shared ver this platform.
With those designs, Software Developers can create concrete software implementations of all the specifications created by the Clinical Modelers and the Engineering Team. They will do all the testing and integration work, but all is based on the initial Clinical Information Models. Again, good models can enable better quality of care through the developed software, and bad models can generate barriers. Take into account, the whole development process is based on the initial models, and nobody wants bad foundations.
Clinical Modeling Tasks
Before modeling, it is recommended to do a requirement gathering for each specialty, to understand information recording and consumption needs, and to detect common information points between specialties. These information points will be specified as Clinical Concepts. These are some examples of Clinical Concepts:
+ Blood Pressure
+ Heart Rate
+ Diagnosis
+ Reason for Encounter
+ Laboratory Results
+ Medication Prescription
Clinical Modelers will try to come up with all the Clinical Concepts during the requirement gathering phase. This initial conceptual modeling doesn't require to have each data point specified inside each concept, but to identify all the concepts, we'll have time to refine concepts later. It is important to detect which concepts can be reused between different specialties, to help standardize all the clinical information independently of who and where the recording is done.
From this point we'll follow the openEHR standard methodology, in which each concept is classified in the openEHR Reference Information Model, and then each concept is specified as an openEHR Archetype, a formal model to represent standardized clinical data structures about one specific Clinical Concept.
Archetypes are semantic definitions of Clinical Concepts, that include the purpose, context, data structures, constraints, associated terminologies, and translations for multiple languages. Archetypes are specified in the Archetype Definition Language (ADL) syntax, that can be processed by software, and there are free modeling tools for archetype editing.
Having archetypes for all the concepts in our clinical records, is a formal and standard way of systematizing the Clinical Information Model for the whole system or platform, achieving a complete, detailed, high quality and easily maintainable specification. Model maintainability is key in Health Information Systems, since new information requirements appear all the time, and archetypes can be modified and versioned to add changes in a controlled way.
You might think that creating archetypes for each new project can be a huge effort. First, Clinical Modelers don't need to create every single archetype. The openEHR community has an international archetype repository that can be used as a starting point. Also, all the archetypes created for specific projects will work for future projects, so each company also creates its own local archetype repository of reusable Clinical Concepts, and maintaining this archetype repository is also a task for Clinical Modelers. As a recommendation, Clinical Modelers can also contribute their archetypes to the international repository, helping the community to grow, and allowing other providers to have compatible clinical records. Yes, using archetypes from the international repository allows global interoperability.
Another aspect related to the local archetype repository, is that software will change a lot during several years of working, maintenance, system reengineering, migrations will happen, even some technologies will be outdated or obsolete. But whatever the technology platform is, the technology stack is totally isolated from the Clinical Models, and our models will survive many generations of technological changes, even last 100's of years. This is key since the clinical information should live at least as long as a patient lives, independently from changes on technology. This is a huge paradigm change in terms of how we see and think about information systems in health care. And of course, maintaining the Clinical Models through all those technology changes is part of the tasks assigned to the Clinical Modeling team. Knowing that there will be a migration of clinical information between different technologies through time, having all the data represented in a standard format (the openEHR Information Model) allows seamless data migrations, maintaining data quality (completeness, consistency, no data loss, etc). Currently data migrations are painful, costly and error prone.
All of these can be achieved with a formal methodology, strong use of standards, technological independence, and trained professionals, and is almost impossible to accomplish with current approaches for developing health information systems.
Now we have all the archetypes, what's next?
Clinical Modelers will combine many Archetypes to create models of Clinical Documents. Documents are containers of all the information managed in Health Information Systems: clinical encounters, procedures, treatments, medication prescriptions, laboratory orders, among other types of documents. The openEHR standard defines another element that handles this part: the Template. For instance, a Template that represents a simple Medical Encounter can contain these Archetypes:
+ Reason for Encounter
+ Vital Signs (Blood Pressure, Heart Rate, Weight, ...)
+ Physical Exploration
+ Diagnosis
We could see Templates as big Archetypes, and different Templates can share the same Archetypes because those documents contain the same Clinical Concepts. For instance, if we have an Emergency Care document, we could use some of the Archetypes contained in the Medical Encounter Template, and add more, for instance we could add the Triage (patient prioritization) Archetype. When creating new Templates, there are many Archetypes that will be reused, this causes data on different documents to comply with the same definitions, enabling highly standardized and consistent clinical databases. As we mentioned, changes on technology won't affect the Clinical Models or the Clinical Data already recorded in the systems, assuring the information can be managed in a controlled way, and will live as long as it is needed, sometimes 100's of years. This is a huge benefit provided by the openEHR methodology.
Templates are the final modeling element that is used directly in software, in the form of Operational Templates (OPT), a single XML file that contains all the clinical document specification, including referenced archetypes, data structures and constraints.
Training on this methodology
Even though openEHR has 15+ years, there are no much training offerings on this approach to help training Clinical Modelers on the methodological and technological areas related to Clinical Modeling. At CaboLabs we designed a full online course about this approach, including the whole modeling process, from initial conceptual analysis, modeling techniques, tools, the openEHR specifications, archetypes, templates and how templates are used in software.
We believe this approach has a lot of value and should be widely known, and we a trying to widespread it.
On our training program page you can find the Clinical Modeling Course Program, alongside with our courses and workshops on Health Informatics, Standards and interoperability.