Navigation

• ↩️ Back to Articles
• ↩️ Back to Research

Extended Description (section by section)

0. Context and Stake

In this article (2011), starting from the LUMIR experience, I tried to formulate an evolution direction for medical informatics systems: moving from an assembly of heterogeneous applications and local databases to a digital health ecosystem, centered on the patient and continuity of care. The practical stake is reducing fragmentation: the same person traverses, over time, different institutions and specialties, and relevant information must circulate with clinical meaning and responsibility.

In the background, I had two simple ideas: (1) interoperability is not just document transport, but a "conversation" among actors with roles; (2) the record should not be viewed only as an archive, but as an entity capable of supporting care coordination, notification, and case-oriented synthesis.

1. The Practical Problem: System Fragmentation and Continuity of Care

The starting point is an organizational reality: clinical information is produced in the contact between the patient and services (hospital, clinic, laboratory, emergency room), but is stored in silos. Each local system has its own structure, its own codes, and its own "habits" of documentation. In practice, continuity of care means that a clinician must quickly reconstruct a longitudinal context, and this reconstruction is often costly and incomplete.

From here derive the requirements we pursued: integration between organizations, controlled access, notification of relevant events, and the possibility to obtain different "views" of the same history (depending on role and responsibility).

2. LUMIR and the Regional Environment: What We Aimed to Unify

We described LUMIR in its regional context as an integration project that does not start "from scratch", but must work with already existing applications (legacy), with different practices, and with unequal levels of digitalization. The overall picture of the environment and the relationships among the involved actors is summarized in Fig. 1.

In this type of situation, success is not just given by a technical platform, but by the way a common model can "translate" between systems without losing clinical significance. That is why we insisted on modeling and defining a "common language" at the semantic and operational level.

3. Why the Strictly Documentary EHR is Not Enough

We critically discussed the strictly document-centric approach: documents are indispensable (and remain an important vehicle of interoperability), but they are not an optimal form for longitudinal synthesis and for queries oriented towards continuity. The document is the final product of a contact; its clinical meaning appears in context and in relation to the episodes of care.

That is why we considered it necessary to complete the "document archive" with a representation closer to the reality of the clinical process: events, contexts, temporal relations, and notification mechanisms. In the article's terms, this shift prepares the role of the VHR as an active entity.

4. Clinical Events: Contact and Episode of Care

An essential conceptual step was to treat the "encounter" as a unit of meaning: Contact (the punctual encounter/episode) and Episode of Care (the care thread that aggregates several contacts into a clinical problem/intention). In practice, this structuring allows linking data and documents to reason, time, actors, and consequences, avoiding an amorphous collection of files.

In the article, I suggested that without these anchors (Contact/Episode), interoperability remains "content transport", not clinical knowledge integration. This is also the basis for notifications (what happened, where, when, with what impact) and for role-oriented "views".

5. Semantic Interoperability: Conceptual Model and M1/M2 Messages

We approached interoperability as a semantic and organizational problem, not just a technical one. Instead of assuming that all applications will adopt the same schema, we proposed an intermediate "standard space", based on a common conceptual model. A partial view of the model is presented in Fig. 2.

At the communication level, we used messages that carry not only data, but also intentionality (e.g., inform, request, notification). The structure of the M1 message is outlined in Fig. 3. In the same logic, the notification (M2) is treated as an operational coordination mechanism in the ecosystem: we don't just "store", but we also "announce" relevant changes to entitled actors.

6. VHR: The Record as an Active Entity in the Ecosystem

A core part of the article is the definition of the Virtual Healthcare Record (VHR) as a longitudinal, coherent, and authorized representation of information, capable of supporting collaboration. We treated the VHR not as a simple container, but as an entity that integrates, organizes temporally, exposes role-based "views", and supports ongoing processes (care plans). The VHR is illustrated in Fig. 4.

In this vision, documents remain accessible, but they are re-anchored to events (Contact/Episode) and the evolution of a case. This re-anchoring is, for me, the minimal condition to reduce manual reconstruction and make collaboration more robust.

7. Architecture and Incremental Evolution: p0 → LUMIR 1 → LUMIR 2

We described the evolution as an implementation strategy with controlled risk. In the article, there are three steps: an initial prototype (p0) to validate the concepts, then LUMIR 1 as a component-based SOA implementation, and LUMIR 2 as a direction for transitioning to a multi-agent model through gradual "agentification" of the components.

At the internal architecture level, we included the component diagram for LUMIR 1 (Fig. 5) and an interaction scenario showing the flow of messages and the role of notification (Fig. 6). We then placed this architecture into a broader context of a digital ecosystem (Fig. 7), and the synthesis of the LUMIR system architecture is presented in Fig. 8.

The underlying idea was to maintain fidelity to the real distribution of actors and resources: an ecosystem does not have total central control, and the architecture must accept this reality (hence the argument for agents, mediation, and incremental evolution).

Links

• 📄 Full PDF (2011)
• ➡️ Medical Informatics (context)
• ➡️ Artificial Intelligence (context)
• ⬅️ Back to Articles