In the previous article in our Stories from Estonia’s Health Information System series, we explained why Estonia’s Health Information System is gradually moving from document-based to event-based data exchange. This time, we look at where building such a system actually begins – and why we cannot simply start with the health data that may seem most important at first glance. 

Imagine that a single statement reaches the Health Information System: the patient has a penicillin allergy. 

This is highly valuable information for treatment, but it immediately raises a number of questions. Who does it refer to? Who entered the information, and in what role? At which healthcare organisation and during which encounter? Is it related to the same health issue that brought the patient to the emergency department a week earlier, or is it part of a completely different episode? 

Without those answers, the allergy record is essentially a statement floating in isolation. The fact itself is there, but the context needed to reliably connect it with the person’s other health data – and to use it at the right moment later on – is missing. 

This is exactly why the transition to event-based data exchange did not begin with allergies, diagnoses or other clinical data. Instead, we started with foundational services – data exchange services that provide the context needed for the rest of the health data and link it, for example, to the patient, healthcare organisation, healthcare professional, healthcare encounter and case. In TEHIK’s event-based data exchange model, foundational services are deliberately the first step, because clinical data services can later be built on top of them. 

Foundation first, walls second

In today’s document-based world, much of the necessary context travels together with the document. From the header and content of a discharge summary, we can see who created it, at which organisation and in relation to which episode of care. This works well when we look at a single document as a whole. 

Things become more complicated when we want to treat health data not as separate documents, but as interconnected information. A document essentially gives us a snapshot of something that has already happened, and it is not always possible to determine in a machine-readable and unambiguous way which data across different documents belongs to the same treatment, follow-up or health issue. 

Foundational services

The logic of event-based data exchange allows data to move as smaller, structured datasets at the time they are created, rather than only as large, complete documents. This means that assigning a diagnosis, having an appointment or another relevant event can trigger the transfer of the corresponding information in real time or near real time. 

However, once a large document is broken down into smaller pieces, each dataset must still make it possible to understand who the information concerns, where it comes from, and which healthcare event or case it is connected to. 

Foundational services provide the framework that allows clinical data to be attached to the right context. 

This is also why the order in which services are developed matters. Allergy data, pregnancy-related data, diagnoses and other clinical data flows cannot be built as a coherent whole before we have agreed on how a patient, healthcare encounter and episode are defined, and how these concepts relate to one another. 

The first foundational service is already in place

The first foundational service to be developed is Master Patient Index or MPI (est PÜT). Its purpose is to consolidate a patient’s general data so that healthcare information systems can use information that is as consistent and up to date as possible, rather than each organisation maintaining the same data separately in its own system. 

PÜT is connected, among other sources, to data from the Population Register, the Address Data System and the Social Insurance Board. The service handles information related to patient identification, contact details and several other types of general data. It uses a modern international data exchange standard that also forms the basis for the development of the next services in the event-based Health Information System. Technical specifications and implementation materials for PÜT are available in the TEHIK Information Centre. 

The next foundational services include the definition of the healthcare encounter and the episode of care. This is where the otherwise abstract idea of “providing context” becomes much more practical. 

A healthcare encounter describes a time-bounded interaction during which a healthcare professional assesses a patient’s condition or provides a healthcare service. This could be, for example, an outpatient appointment, a home visit or a period of inpatient care in a hospital department. 

An episode helps bring together encounters related to the management of a particular health issue within the responsibility of a single healthcare provider. For example, repeated encounters with the same family physician or the same specialist for one health issue may belong to the same episode. 

There is an important distinction here: one health issue does not necessarily mean one episode across the entire healthcare system. If a patient is referred from one specialist to another for the same health issue, or moves between different healthcare organisations, separate episodes may arise. In the future, it should also be possible to see the relationships between these episodes more clearly, so that a patient’s care pathway does not remain merely a collection of disconnected episodes. 

The boundaries between encounters and episodes do not emerge automatically. They are agreements that must take into account both international data exchange standards and the realities of healthcare delivery in Estonia. At the same time, we need to avoid the opposite extreme: if every minor action became a separate event, a better data structure could simply create a new form of information overload. 

Foundational services do not solve every problem

Completing the foundational services does not mean that problems related to health data quality will disappear. Incomplete or incorrect information that moves faster is still incomplete or incorrect information. 

What common concepts, machine-readable structures and the transmission of data at the time it is created can provide is a better basis for identifying gaps earlier and for ensuring that information is understood and used consistently across different systems. TEHIK’s 2025 analysis of event-based data exchange and documentation also highlights that technical change alone is not enough: documentation practices need to be harmonised, terminology agreed upon, and the legal framework adapted. 

International terminologies and classifications such as SNOMED CT and ICD-11 also play a role here. Their purpose is to help structure health information and make it more consistently understandable across different systems, supporting better interoperability. Their implementation, however, requires technical preparation, training and substantive agreements. 

And now, back to the penicillin allergy. 

When this type of information reaches the Health Information System through event-based data exchange in the future, it will not simply be an isolated record. It will be accompanied by context indicating who the information concerns, who entered it, at which organisation and in relation to which episode. Only then can an individual data point become part of a more complete picture of the person’s health history. 

Foundational services are therefore not an end in themselves, nor do they solve every challenge related to the use of health data. They are the foundation on which the next services will be built. Without that foundation, it is difficult to reach a situation where healthcare professionals can quickly and clearly access the up-to-date information they need about a patient, without having to search through multiple documents or request information from other parties. 

If you work with health information systems, now is a good time to pay attention

If you are an IT manager or developer at a healthcare provider, or work with health information systems in your organisation, it is worth keeping an eye on the TEHIK Information Centre already now. The descriptions and implementation materials for the Master Patient Index Service are already available there, and information on the next services will continue to be added as development progresses. 

Karin Rääsk

Karin Rääsk

Head of Business Architecture and Analysis Team

[email protected]