The openEHR Fellowship recognizes experts around the world who are driving real-world change in digital health. Our CEO now joins a cohort of innovators and implementers shaping the future of global health systems.

Peri Bloom was founded through a cross-disciplinary collaboration at a top medical and engineering school. Our work began as a response to fragmented health data systems. From early recognition at tech expos to responding to health emergencies with the Ministry of Health, UNICEF, WHO, and MSF, our focus has always been on meaningful impact.

We deployed one of our earliest innovations, Paraboda, to support outbreak response in underserved regions. As a result of these initiatives, we earned recognition as second runners-up at the 2024 openEHR International Conference. This milestone not only validated our open data approach but also paved the way for deeper engagement within the openEHR ecosystem.

The fellowship provides a platform for structured global collaboration. As part of the General Fellowship track, our CEO will engage in platform governance, implementation strategies, and localizing global standards for emerging and developing digital health ecosystems.

This isn’t just a personal milestone — it’s a call to grow with the global openEHR movement, and ensure that the innovations we build in Africa shape the future of care everywhere.— CEO, Peri Bloom.

Why It Matters for Africa

Being part of the Fellowship allows us to:

• Co-create and influence open platforms adoption strategy for LMICs

• Advance regional health data strategies through partnerships and policy innovation

• Collaborate with fellows from major institutions to inform standards, tools, and deployment blueprints

• Scale ethical, interoperable platforms like our unified records, clinical support tools, and modular Bloomcloud solutions

Our Fellowship journey is also an opportunity to bring visibility to African leadership in open-source and interoperable health IT. It supports our mission to empower governments, hospitals, and communities with tools designed to last, scale, and adapt.

Learn More

About Peri Bloom

Our Approach to Digital Health Innovation

Explore Our openEHR-based Solutions

Contact Us to Collaborate

Help Us Share the Story

We believe this milestone belongs to all our partners, developers, clinicians, and supporters who have been part of our journey. Share the good news or reach out to learn how we can build better health solutions together.

The post Peri Bloom CEO Selected as openEHR Fellow appeared first on Home.

Beyond Databases
Legacy EHR systems have long been constrained by their initial design as static repositories, leading to widespread inefficiencies such as;

1. Data Silos and Interoperability Barriers – Traditional EHRs operate in isolated ecosystems, making seamless data exchange difficult resulting in fragmented care, duplication of tests, and poor decision-making due to incomplete information.
2. Workflow Bottlenecks – Many legacy systems require excessive manual data entry, while this is important, but it also contributes to clinician burnout and reduces the time available for direct patient care.
3. Limited Decision Support – Without advanced analytics, these systems fail to provide actionable insights, forcing clinicians to rely on clinical intuition alone.

Information systems like the Postmodern EHR address these challenges by providing real-time processing, advanced automation, and AI-driven decision support. These systems don’t just store data — they transform it into organizational knowledge, enabling more informed, efficient, and personalized patient care.

From Static Records to a Dynamic Intelligence Hub
The evolution of healthcare information systems has seen a shift from simple databases to distributed, cloud-based platforms that incorporate artificial intelligence, machine learning, and edge computing. The Postmodern EHR is at the forefront of this transformation, offering:

1. Advanced Cloud Computing Architecture – Moving away from on-premise systems, the Postmodern EHR leverages the cloud to ensure data accessibility, scalability, and resilience. This allows real-time updates across multiple healthcare facilities, improving continuity of care.
2. AI and Machine Learning Integration – By analyzing historical and real-time data, the system can detect patterns, provide predictive insights, and automate administrative processes, from clinical decision support to predictive patient outcomes.
3. Edge Computing for Instantaneous Data Processing – In time-sensitive scenarios such as emergency care, the ability to process data locally (at the edge) reduces latency and ensures critical information is available instantly.

These advancements shift the role of EHRs from passive repositories to active participants in healthcare delivery—enabling hospitals to manage resources efficiently, predict capacity requirements, and optimize clinical pathways.

Optimizing Clinical Pathways with the Postmodern EHR

Clinical pathways are structured treatment plans designed to optimize patient care while ensuring efficiency and cost control. However, managing these pathways in a complex hospital environment presents challenges, including:

Standardization of treatment steps – Ensuring that clinical pathways are consistently followed while allowing for personalized adjustments.
Revenue management and resource allocation – Tracking the financial implications of each step in the treatment process.
Real-time adjustments to care plans – Modifying pathways based on a patient’s evolving condition, new research findings, or hospital capacity constraints.

With the Postmodern EHR, these challenges are addressed through automated workflows, real-time monitoring, and data-driven insights. The system provides a digital framework that:

Ensures clinically accurate pathway execution – By mapping out optimal care steps, it helps standardize treatment while allowing for flexibility based on individual patient conditions.
Enables cost calculations and efficiency optimization – By integrating financial modeling, hospitals can identify cost-saving opportunities while maintaining high-quality care.
Facilitates dynamic adjustments based on live data – The system continuously monitors clinical and operational data, allowing hospitals to adjust patient pathways proactively.

This level of automation and intelligence transforms the clinical pathway from a rigid guideline into a flexible, real-time care optimization tool.

Post-Pandemic Challenges and Digital Solutions
The COVID-19 pandemic exposed several vulnerabilities in traditional healthcare information systems, including;

Delayed reporting and information gaps – Many healthcare facilities struggled to provide real-time updates, leading to misinformation and suboptimal resource planning.
Increased burden on healthcare workers – The pandemic intensified workload pressures, making the inefficiencies of traditional EHR systems even more apparent.
Shift toward remote and contactless care – The need for telemedicine and virtual consultations highlighted the limitations of outdated healthcare IT infrastructure.

A Postmodern EHR addresses these challenges by providing;

Real-time data synchronization for crisis management – Ensuring decision-makers have the latest information for capacity planning and pandemic response.
Automation to reduce administrative load on clinicians – Allowing doctors and nurses to focus on patient care rather than paperwork.
Seamless telehealth integration – Enabling remote monitoring, virtual consultations, and AI-driven triage to support care delivery beyond hospital walls.

With these capabilities, healthcare institutions can maintain resilience in the face of future crises while optimizing routine operations.

Investing in Scalable and Adaptive Systems.

Healthcare organizations today must think beyond short-term solutions and invest in IT infrastructure that is;

Scalable – Capable of growing alongside the organization’s needs, handling increasing data volumes without performance degradation.
Modular – Designed to integrate seamlessly with emerging technologies, ensuring future-proof adaptability.
Interoperable – Breaking down data silos and enabling fluid data exchange between systems, facilities, and external stakeholders.
AI-Ready – Equipped with machine learning models that continuously learn and refine recommendations based on new data.

The Postmodern EHR embodies these principles, delivering an information system that not only meets the demands of today’s healthcare landscape but also paves the way for future innovations.

The Postmodern EHR as a Catalyst for Healthcare Transformation
Healthcare information systems have come a long way – from simple data repositories to dynamic, AI-driven intelligence hubs. The Postmodern EHR marks the next stage in this evolution, transforming how hospitals manage resources, optimize clinical pathways, and deliver high-quality, cost-efficient care.
By integrating cutting-edge cloud computing, machine learning, and edge processing, the Postmodern EHR moves beyond static record-keeping and becomes an active enabler of clinical excellence. It not only improves workflow efficiency but also enhances decision-making, supports predictive analytics, and ensures interoperability across the healthcare ecosystem.
For hospitals and healthcare organizations looking to stay competitive, investing in a Postmodern EHR is more than a technological upgrade—it’s a strategic move toward a smarter, more resilient future.

The post Rethinking care information systems, the Postmodern EHR. appeared first on Home.

BloomCloud

What Are Ontologies?

Ontologies have a rich history rooted in philosophy, where they began as a way to categorize and understand the nature of existence and relationships. In modern times, they have evolved into powerful tools for structuring knowledge in domains like healthcare, life sciences, and technology. Their richness lies in their ability to define key concepts and their intricate relationships—such as how diseases can affect both humans and animals or how vaccination prevents illness. This structured framework ensures consistency and clarity across disciplines.

At their core, ontologies are about organizing and connecting data in a way that makes sense to both humans and machines. That’s why they’re often called the backbone of semantic technology — they allow systems to communicate in a standardized way, even if they were built by different organizations or in different countries.

Why Are Ontologies Important?

In today’s information society healthcare data today is a fragmented. Pouring in from countless sources: hospitals, labs, pharmacies, veterinary clinics, public health systems, and more. This fragmentation creates challenges like miscommunication between systems, data silos, and inconsistencies in how information is understood or used. Ontologies address this by bringing structure and clarity, ensuring that critical terms are universally defined and interpreted the same way. This foundational work is crucial for:

• Interoperability: Systems’ ability to talk to each other without misunderstandings.
• Data analysis: Insights that can be drawn because data is structured and connected.
• Innovation: Standardized data allows for the creation of powerful tools and technologies.

The One Health Connection

You’ve probably heard about “One Health,” but let’s revisit it. One Health is an approach that recognizes the interconnection between the health of humans, animals, and the environment. COVID-19, zoonotic diseases, antimicrobial resistance — these are just a few examples that highlight why we can’t afford to think about human health in isolation.

Ontologies are central to making One Health work because they enable us to connect data across disciplines:

Human Health Ontologies (like SNOMED CT or ICD): These are essential for organizing concepts such as diseases, symptoms, treatments, and care pathways. Use case examples include improving electronic health record (EHR) systems, enabling seamless communication between hospitals, and supporting clinical decision-making tools.

Animal Health Ontologies (like the Animal Disease Ontology and VICO): These help structure data in veterinary medicine, track zoonotic diseases, and manage vaccination programs for livestock and pets. For instance, they allow for real-time monitoring of outbreaks like avian influenza or rabies.

Environmental Ontologies (like ENVO and SWEET): These focus on relationships between ecosystems, climate factors, and disease spread. With cases that include modelling the impact of climate change on vector-borne diseases or mapping pollution sources contributing to respiratory illnesses.

Genomic Ontologies (like Gene Ontology): These are crucial for linking genetic data to diseases, aiding in personalized medicine, while supporting research on antimicrobial resistance.

Integrating these ontologies, systems can tackle complex problems across disciplines, such as predicting the spread of zoonotic diseases or coordinating responses to global health crises. Remember I never said it’s easy, but if done in a collaborative approach, it can be a breeze.

These ontologies create a shared language that lets us integrate data from a hospital in Nairobi, a veterinary clinic in Sydney, and a climate monitoring station in the Arctic. That’s the power of standardization.

How Peri Bloom Fits In

I have been working in Peri Bloom (Going more than 7 years now), and it has always been about using mature data standards to create impactful solutions. The BloomCloud platform is a great example of this in action. While our focus  remains on human health, it can also be spun up for use in other domains related to human health for research purpose. Showcasing how technology built on ontologies opens broad research and collaborative opportunities within the ecosystem. It serves as a persistent layer for advancing One Health, fostering research, and innovation across interconnected domains.

So, Why Should You Care?

Ontologies might sound like a technical topic, but they’re really about making better decisions. For clinicians, they mean better tools. For policymakers, they mean better data. For all of us, this boils down to a healthier world.

If you’ve ever wondered how technology can bridge the gaps between different sectors and systems, ontologies is your answer. They’re not just for geeks; they’re for anyone who cares about connected, informed solutions.

I’ll be diving into the One Health space, and I’m excited to share more about how using ontologies you can make it happen. Stay tuned for updates on our projects and more deep dives into how these concepts apply to real-world, after all, the foundations are always the best place to begin.

The post Ontologies: The foundation of one health and connected care with BloomCloud™ appeared first on Home.

Today I think we have enough going in terms of a semantic health data platforms like BloomUI, and some of the smarter EMR systems, to consider the next layer. Serendipitously, I’ve recently had the chance to concentrate on the process question.

Making workplace processes computable is a huge challenge, and it would be difficult to over-estimate the effort that has gone into it over some decades. There are dozens of process languages and workflow tools, and endless reams of research to cover. In some industries, notably manufacturing, there have been successes, but creating similar solutions for healthcare seems endlessly elusive. Intuitively, it’s not hard to understand why. Most workflow solutions are based on the idea of modelling deterministic processes that can then be performed by agents, i.e. humans, robots, or other devices. This can work well in e.g. car manufacturing, where there are very few unknowns (the amount of time for specialist human welders to finish a weld will vary somewhat for example).

Many of the workflow languages on the market today, typified by the OMG BPMN standard, are designed for exactly this purpose. I would have to say that from my research so far, the YAWL formalism is probably the best attempt available for modelling real world processes, with proper attention (unlike BPMN) to performing agents, exception handling,, declarative definition and mathematical underpinning.

However when processes are not very deterministic, and unplanned exceptions are common, the model-based process approach doesn’t work so well. Unfortunately healthcare fits this description far more closely than any idea of deterministic control. Further, it seems fairly obvious that non-determinism is only one of a range of factors that contribute to the challenge:

• shifting goals: the patient condition is always changing, so clinicians are always revising the plan for care in real time;
• shifting responsibility: multiple carer and institutional hand-offs are common, which creates a logistical communications and collaboration challenge;
• complexity: information and knowledge complexity and diversity;
• shifting care mandate: the patient him or herself has changing ideas about what they want to happen;
• autonomy: agents in the system (clinicians, patient, others) tend to operate independently, rather than mindlessly following directions from a ‘boss’.

The overall picture of healthcare is described better by theories of complex adaptive systems rather than deterministic models, as discussed by many experts.

A metaphor for healthcare process: GPS navigation

An appropriate metaphor for the healthcare process during an episode of care is not that of a control system, such as the one that runs a modern dishwashing machine, the process of GPS navigation. When I thought about this, I realised he was right. When you get in your car, say in a foreign country while on holiday, you put in your destination to the GPS app and start driving. The path to get to the destination appears fully pre-planned and sometimes you go all the way with no deviations from that plan. But what if the goal changes? If the weather turns, the beach may not be the place to go.

The general situation while driving with GPS navigation is that it and you are always working out your route ‘from here’. Now, imagine that instead of the pretty reliable roadmap data we have today in GPS navigation apps, there was a far patchier set of map data, with some well-mapped areas, and others still being worked on by surveyors.

I would argue that GPS navigation, with rough mapping data and changing goals is a better metaphor for healthcare process than deterministic workflow models. We can understand the position of the car on the journey as the position we are currently at in the care process for the patient, for a given episode of care. The clinicians (and patient) are always in the position of plotting a course ‘from here’. One of the conclusions we can take from this metaphor is that solving clinical process is not just a question of implementing workflow support, but of implementing decision support as well, since completing the journey is full of decisions that determine the next steps. Workflow and decision support are intimately related.

The way I would characterise what we are really trying to build is a patient journey navigation system.

Another problem: multiple cognitive levels

It might be tempting to take the GPS navigation idea and run with it as the basis for some new kind of workflow engine, but healthcare is more complicated than that. We need to consider some other key aspects, the most important of which I would suggest is ‘multiple cognitive levels’ of operation and hence representation.

If you think about the docs, nurses, orderlies, and everyone else who takes care of you during an illness, it might seem that they follow relatively coherent patterns of activity, and indeed, outside trauma situations, this is superficially true. Can’t those routine activities be mapped out and defined in a computable way? As small islands of work, probably. But we need to remember that what those health professionals are doing is always a function of the current care plan, and the care plan (however precise or rough it might be) will change. Doctors can only see so far ahead, and they are most commonly in a position of waiting to see how your body responds to their most recent investigations and interventions. If they are searching for a diagnosis “a la the typical episode of House,” then the process can be like a search for a needle in the proverbial haystack with the lights turned out. If you are being treated, they still don’t know how you will react to various drugs, if you will get an infection, suffer bleeding, or even if they themselves will make an error. So whatever passes for the ‘care plan’ is often only as good as today’s information. The care plan itself is a process, not a document.

Even if a care plan were reliable, we need to understand where any kind of care plan might come from. Consider a sepsis patient in hospital. Let’s say noone yet knows that the patient has a bloodstream infection, but is showing various symptoms that the ED department recognises as a risk. In some hospitals, guidelines will be used as a basis for navigating the problem, getting the order right of activities and minimising risk.

Is the sepsis care pathway the same as a care plan for the patient with sepsis? If so, then if we can represent the care pathway in a computable fashion, we might start to have a basis for implementing the workflow. Unfortunately, things are not so simple. A care pathway is a guideline for a ‘model patient’, created by studying actions and outcomes on numerous real patients and looking for what worked best, and codifying that. When it comes to an actual concrete patient, there are all kinds of other things to consider. What conditions do they have? They may be pregnant, have Alzheimers, or be injured. Perhaps two or more care pathways are implicated. What drugs are they on? The very fact that they, like any human being, have their own phenotype and individual capacity for reaction to drugs or pathogens has to be taken into account.

The general picture is that the care plan for the patient (or there may be more than one) is some potentially complex derivative of the ‘medical knowledge’ level of model patients and model conditions. The responsible physician(s) use their experience, access to standard care pathways and other resources, as well as the observations, test results and history of the patient in front of them to work out what to put in the plan. This sets the destination as per the GPS navigation metaphor, but of course that may change again tomorrow.

As far as I know, there is no generalised description of this relationship, but it is clarifying to know that clinical knowledge such as care pathways and care plans are different levels of representation. We can intuit the following cognitive levels:

• care pathways for conditions ⇒ care plan for an individual ⇒ workflow actions

The people who build guidelines, pathways and other medical knowledge are doing the work of creating something like GPS mapping data along which to navigate in model situations. The treating clinicians who formulate a care plan, which involves setting goals, are choosing a map set, stating the destination and defining some means of undertaking the initial few miles of the journey. And the workflow is the actual journey.

More levels: processes are fractal

A further complexity in the challenge of computerised workflow is the small problem of care processes being fractal in nature. Administering a course of antibiotics orally over 7 days is a very simple process, usually undertaken by the patient. Cannulation is a pretty simple process for a trained nurse. Intubation is a bit more complicated, but still very routine. Stabilising a patient after a major injury might require cannulation, intubation and a whole lot of other smaller processes. The episode of care for such a patient, from arrival in the ambulance to final discharge on crutches is a complex process indeed, consisting of a whole hierarchy of smaller processes. Is it useful to put the steps for cannulation on a screen? Probably not, although check-list proponents might argue that displaying an infection reminder is valuable. But when we get to the stabilisation process, or a condition like sepsis, it’s clear that treating physicians could make various choices about what to do next, and it might be very helpful to have some help – a clinical GPS navigation system – to determine the best direction.

What processes should we formalise?

What level of process should we try and formalise so as to implement such an engine? There are answers to this question, although they are not the most obvious to IT people who tend to think: ‘everything!’

Processes with significant cognitive complexity

A generic criterion for finding clinical processes that can benefit from workflow and decision support is as follows: any ‘process’ that when performed by similarly qualified professionals on similar patients that generates markedly different outcomes is a candidate for process-embedded decision support. Why? Because those similarly-trained professionals are not doing the same thing, even though they are doing ‘proper medicine’. Nevertheless, some of them are making better choices than others, generally without being aware of it. Only dedicated studies can find those better choices and develop the optimal care pathway for the relevant patient condition.

One might think that a proven care pathway for a condition would be included in next year’s medical text on that topic, and that medical students from some point on will know the proper way to treat the patient with the condition. But can we rely on those medical students to learn the whole pathway and execute it perfectly at point of care years later? And what about all of the working medical professionals in circulation today? Can they be trained within their institutions?

Possibly, but there is a confounding factor – cognitive complexity. While physicians are very smart people, they are just as limited by the 7 ± 2 mental buffer as the rest of us. But many decision points in guidelines for conditions like sepsis contain many more input variables than that. These decision points are clear candidates for decision support – a recommendations co-pilot.

Routine processes and human forgetfulness

There is another well-known source of errors in medicine as well: simple forgetfulness in very routine procedures. When a nurse is on automatic pilot, thinking of skiing with his wife on the weekend, it’s easy to forget one small detail – disinfecting a catheter for example, or to misread a chemotherapy drug dose due to fatigue. Small actions can have severe consequences. So another candidate for processes, or process steps that should be represented in the IT layer are key reminders for completely routine processes that have severe consequences for non-compliance.

Long-running processes with hand-offs & multiple carers

Some kinds of clinical process are routine, but have the complication of being performed by multiple carers in a serial fashion in time, that is to say, the responsibility for the work transfers from one agent to another. This might be within the same care organisation, e.g. inpatient medications administration continuing through multiple nursing shifts, or it might be across enterprises, such as end of life care in which GPs, home carers and hospice or clinic carers are implicated. In these cases, it is clearly going to be of great help to have a representation of a long-running process in the IT layer, whose individual tasks can be viewed, performed and signed off. This is often called a ‘task list’.

Processes that don’t need support

It’s worth asking: are there clinical processes where workflow support isn’t going to bring much value? Some examples come to mind. The process for dealing with cardiac arrest just after cardiac surgery probably isn’t a candidate: it’s a time-critical and life-threatening situation whose resolution is entirely dependent on good training, and with a high rate of survival (around 80%). Routine procedures like intubation, wound dressing, cannulation and so on are probably not going to benefit much either, because in clinical terms they’re fairly deterministic and also logically atomic rather than long-running. In all these cases, the decisional complexity is fairly low, and the process steps and exception handling are generally internalised by training. What we do want to know however is that these processes were performed (or not) within the larger plan of care, so they are likely to be represented as a step or sign-off in some larger process description.

The Case Management paradigm

Other than some islands of order, it doesn’t seem as if the deterministic BPMN workflows so dear to some are the main solution. This realisation is reflected in the more recent paradigm in workflow circles, case management. Case management is a paradigm shift from a control flow mindset to a data-object mindset. Some of the characteristics of processes that can be addressed by the new paradigm:

• knowledge-intensive
• variability
• long running
• information complexity
• collaboration and coordination
• multiple participants, multiple roles
• cases can be interrelated
• critical nature of timescales
• external events affect cases
• difficulty in gaining visibility of case progress
• strong reporting requirements
• history
• security
• isolated pockets of automation.

Sound familiar don’t they? In medicine, the ‘case’ is represented by the informational state of patient during an episode of care. Luckily we have something that implements this: the longitudinal EHR.

The OMG now has a Case Management Model and Notation (CMMN) standard, although having looked at it in detail I would say it is very early days. But it is the right kind of approach for one part of the problem.

What can we formalise?

The two key questions in all this are: what do we try to formalise and how? We’ve seen that there are various levels of representation, and also various types of process that are likely candidates for IT support.

Clearly there is some hope for formalising medical knowledge and guidelines. We have numerous computable examples already, including medical terminology, ontologies and the many guideline languages, including Arden syntax, ProForma, GLIF, Asbru and so on. And yet, we don’t see routine use of these at point of care: care pathways and guidelines are still mostly published as documents or websites, albeit in reasonably structured natural language, often including visual flow-charts.

There are probably two reasons for this. Consider the NICE Sepsis Care Pathway again, and think what it would take to put all of that into a computable form, say in Arden or ProForma. I suspect it can’t quite be done, which implies that the current guideline languages are not yet sophisticated enough to express everything that is needed. But I’d say they would go close (another approach would be rule-based representation, also powerful, but too big a topic to go into here). I think the primary difficulty isn’t representation, it’s knowing what to do with computable guidelines once we have them. How do we get to a care plan? How do we get to the final workflows of actions that need to be performed by everyone?

The current solution is the same as it was a hundred years ago: the most reliable machine for turning general medical knowledge into actions for a specific patient is … a healthcare professional. We have guidelines in a human-consumable form, we have the EHR or EMR as a recording device for typical pieces of information generated in that process, and we have a few decision support tools (mainly to prevent bad prescribing decisions) but we still lack the GPS navigation co-pilot, or in clinical terms, a coherent care plan concept.

Lastly, we can do something at the task list level. Task list support exists in some EMRs, but to my knowledge, it isn’t integrated with care plans or knowledge artefacts like care pathways.

To summarise, I would argue that the candidates for computable implementation are as follows:

• more accurate representation of the growing library of care pathways that describe best practice for cognitively complex processes – these are ‘standard decision pathways’;
• the process of creating and continually maintaining a care plan from a) internal and external medical knowledge and care pathways and b) current patient state – these are patient-specific decisions;
• task lists for care plan processes containing hand-offs and/or steps where non-compliance (forgetting, wrong dose etc) may have severe consequences – these are patient-specific actions.

The kind of solution to implement this I would thus characterise as follows: a high-quality EHR and data modelling capability underpinning three layers of process representation: task lists, care planning and care pathways.

Right now the one I am working on some careful first steps have been at the Task List level at Peri Bloom, on a slightly broader design framework in the Activity-Based Design (ABD) project. I’m working with great teams in both projects, with a huge amount of design, implementation and clinical experience.

The post Initial Foundations of clinical workflow appeared first on Home.

There are some rather obscure definitions of health IT’s favourite term interoperability floating around, for example:
Wikipedia: Interoperability is a characteristic of a product or system, whose interfaces are completely understood, to work with other products or systems, at present or in the future, in either implementation or access, without any restrictions
Cambridge dictionary: the degree to which two products, programs, etc. can be used together, or the quality of being able to be used together.

These definitions are not wrong, but don’t quite capture the whole picture. First we need to clear up one thing, which is the question of semantic interoperability, often distinguished from syntactic interoperability. The former is usually understood as the ability of systems to share meaning, or similar, while the latter just means they agree on how to share data or API calls concretely. For healthcare IT, and indeed most industries, the only interesting interoperability is the semantic kind; if you have not achieved that, there is more work to do. So here, ‘interoperability’ means ‘semantic interoperability’.

My definition is.

interoperability (def):
the level of interoperability between distinct components of an information processing environment (applications, services, systems etc) is proportional to their ability to correctly communicate their internal semantics to each other, without special measures, other than syntax or technology adaptation.

There may be some debate as to the extent to which the internal semantics of any component should be exposed to the external world. I would argue there are no semantics of any system that meaningfully remain hidden: if they are a valid part of the component’s design, they will appear somewhere in the exposed data or communication protocol of that component, otherwise, what are they doing there? Even systems that are essentially sinks of complex data (say, census records) and generate only aggregate statistics need to have their raw data visible to administrative-level tools. If they don’t, no-one can verify if the system is performing correctly.
So we are interested in the extent to which internal semantics – the domain models of the component – are understood by other components, without doing any special work other than technology or syntax transformation.
The only way this can occur is if the internal semantics of communicating components are common, which is achieved in two ways:

1. private standardisation, i.e. the components are developed by the same organisation based on common models, or;
2. public standardisation, i.e. the component developers independent adhere to common semantics and models published by third party/ies.

What we typically observe is that a very small fraction of the total semantics understood inside a component is directly comprehensible by other components not built by the same vendor.
The publication of ‘standards’ – de jure or de facto – is meant to improve the situation, based on the assumption that the products of vendors who implement the standards will communicate better than those which don’t.

There are many implicit questions here. Firstly, standards for what? Common models? This does happen in telecommunications, and is what enables the mobile network, satellites and audio-visual systems to work properly. These standards may be understood as architectural, as they will define significant internal elements of the products based on them.
In health IT however, the main standards we have are for specific utterances rather than common models, i.e. use case specific interactions or messages, rather than general models of meaning (the exception is terminology, which is significantly standardised). Specific utterances are sentences, compared to common models, which are the language. Since the number of possible utterances transmittable by non-trivial systems is generally very large, standardisation by this means is very inefficient, and most likely non-scalable – at the best, it involves monotonically increasing work.

To obtain true interoperability, we need to build components based on common domain models and languages, not private ones. This may be understood as a open platform architecture. Then all possible ‘sentences’, i.e. specific messages and API calls will all be understood automatically. Via this method, interoperability is an emergent outcome rather than an post hoc attempt to reverse engineer a common language from and endless pile of sentence specifications – what I term the message mentality.
But how can domain models and languages be defined and shared? In health IT, these include things like:

1. common information models, i.e. clinical data types, basic structures to represent observations, orders, actions, documents etc;
2. domain definitions, formal representations of domain semantics:
3. terminology, i.e. formal representation of ontological aspects of the domain, i.e. invariant truths, particularly the taxonomy of natural kinds;
4. content models, i.e. definitions of information that is created due to particular business activities, such as taking a blood pressure, reviewing a diabetic patient, ordering a medication;
5. process and reasoning models: care pathways and guidelines, consisting of plans and decision logic for best practice in care over time.
6. languages of representation of domain definitions.

The first and last are technical concerns, and require the input of both domain and IT professionals. They are also the basis of software – tools, platform back-ends and applications, which if built correctly will consume domain definitions, i.e. the middle three. These artefacts may be built by domain experts using tools based on the two technical items. Ideally, these are consumed at runtime by deployed software, enabling such systems to continually track the domain rather than ossify into obsolescence, as is the usual case today.
This has been our project in openEHR for 20 years. It has been inspired by collegues in many places, and today, newer standards projects such as BPM+ are starting to work on the platform + models basis, via which interoperability is an automatic outcome.

The post Interoperability. appeared first on Home.

A new e-health standard comes along every couple of years. In Gartner hype cycle terms, it starts out on the rise toward the ‘peak of inflated expectations’, then falls into the ‘trough of disillusionment’, before either dying or rising again over the ‘slope of enlightenment’ to a ‘plateau of productivity’. Most standards and e-health technologies (standards + their tools and artefacts) die before getting to this plateau. But why? What’s wrong with them? How can we pick a winner?

(Gartner Hype Cycle, from wikipedia)

The latest hyped e-health technology is of course HL7 FHIR – Fast Healthcare Interoperability Resources.

On the recent ONC hearing, Wes Rishel (ex Gartner and an e-health standards veteran) raised this very question during question time. I’ve been thinking about these issues for many years, but never tried to answer that exact question. I have now put together a brief analysis – The idea here was to produce the shortest list of criteria, each of which, on its own detects failure.

The criteria are as follows:

• Platform
  • Does the technology define overall elements of a platform into which recognisable specifics could be plugged, e.g. information models, content definitions, workflow definitions, APIs, code generation tools, etc?
  • Does the technology define something that can be properly integrated into an existing platform definition?
• Semantic Scalability
  • Does the technology provide a practical method of dealing with potentially massive clinical content diversity?
  • Does the technology provide a practical method of dealing with potentially massive localised variability?
  • Does the technology provide a practical method of dealing with ongoing change in information requirements due to, new science, -omics, drugs; new clinical protocols and methods; legislative changes; changing patient / consumer needs?
• Implementability
  • Does the technology provide a way for clinically complex models to be converted to a form consumable by ‘normal developers’ to build ‘normal software’, including for the purpose of integrating with existing systems, data sources and sinks?
• Utility
  • Are all data elements easily accessible at the finest grain?
  • Does the technology provide a way to query fine-grained information based on models of content, not physical representation (physical DB schemas, specific XML doc schemas etc)?

According to the above, if an e-health standards technology fails any of the above, it won’t survive in the long term, and sunk costs in the short term will become an economic liability and possibly obstruction to finding standards technology that actually will work.

These desiderata are a work in progress, but I would argue that the items above are somewhere close to a reasonable Occam’s Razor for testing health standards technologies. i would particularly point to the semantic scalability category. If we agree that today e-health is broadly about the data, then we must by definition agree that successful standards technology must address the content – i.e. what the data say and how to compute with it – in a way that accommodates complexity and change over time. Note that these criteria call for practical methods, not just in-theory ideas about dealing with complexity.

Note also that clinical content diversity and local variability are not the same thing. The former is to do with the sheer number of concepts in the domain, and is the reason why SNOMED CT is huge and will only get bigger. The latter is to do with localised variants of standard domain concepts, due to localised practice differences, differences in rules, management and a myriad of other things. The typical example is data differences in e.g. discharge summaries from different locations. An e-health standard that does not account for this reality in a sustainable way, will fail in the long term.

Under the category of Utility, I have included just two proxies for testing overall value of solutions based on the technology. These are essentially, again, about being able to get at the data. There are probably others that could be added here, but I contend that if querying can’t be properly solved, then other utility criteria are probably irrelevant.

How do the various e-health standards stack up? I will leave that to other authors for now. But I have tried it out on half a dozen well-known standards technologies in health, and so far the tool’s capability is looking good.

The post e-Health appeared first on Home.

NB: in this post I am using the term ‘EHR’ in the sense of the key back-end platform components Clinical Data Repository (CDR), Demographics etc, not a whole-of-product EMR sense.

Why ‘FHIR versus the EHR’? Firstly, the question comes up because there are people and organisations that have been convinced that they can build an EHR system from FHIR. Since I hate to see organisations in the healthcare domain lose money and time that could be spent on actual progress, I want to explain why – technically – this has almost no hope of working. This is also an opportunity to further discuss issues with FHIR as it is now (DSTU4) and what can be done to address them, and make it work well for the use cases for which it was designed. See previous posts on inconsistency, lack of modelling and the formalism for reference.

First things first. An EHR? In the abstract, we can think of it as a memory device for recording what goes on during healthcare processes. Roughly, what can be recorded includes the following kinds of primary information:

• Requests for care
• Administrative items
• Observations, including patient-provided information
• Clinical decisions, opinions
• Plans
• Orders
• Actions (that have been performed)
• Consents
• Financial items

At any particular case, the primary information usually consists of a number of related data elements in a structure.

Context

Context data get committed over time, as the care process – say an episode of care at a hospital – unfolds. However, there is never just one ‘process’: care takes place within an episode of illness or other health concerns, and there may be research or clinical trials going on as well (the ISO 13940 Continuity of Care standard may be referred to for a details description of such things). At the moment in time when the primary elements are captured, there are various kinds of context that may be extant. These include:

• situational (encounter) – the real world situation being captured:

• • subject – who is the information about?
  • provider – who provided the information?
  • other participants – other actors who were part of the situation
  • where – location, e.g. physical, organisational
  • when – timing information
  • how – methods, instuments used to generate/obtain information

• protocol

• • guideline(s) operating that determine care steps and/or decisions

• order workflow

• • identifiers of requests, responses

• episode of care

• • start (admission), end (discharge, death)
  • institution

• care pathway

• • structured pathway governing guidelines, order sets to be used

• care plan

• • which individualised care plan (if any) is governing the current care; may refer to care pathways, order sets, guidelines etc
• episode of illness or other health concern (e.g. pregnancy)
• • date(s)

• medical research, clinical trials, public health investigations etc.

How these are recorded depends greatly on what is going on. Situational context is often recorded along with with the primary data structure, if it is a single sample, e.g. a single blood pressure or diagnosis. But 24 hours worth of vital signs (BP, heartrate, SpO2) from a bedside monitor will consist of some thousands of samples, and they would typically be recorded in a more efficient data structure, with the invariant elements being recorded only once.

The details of longer running contexts, such as episode of care, episode of illness, care pathway, care plan, and any others, are typically not recorded for every item that occurs during that context, but in other ways, e.g. tagging, folders, or by being inferred from querying (e.g. an episode of care could be determined by looking backward for an admission and forward for discharge event).

The Design of an EHR (CDR)

In general, the design of an EHR system CDR is built around the act of writing chunks of data that document real world events – often termed clinical statements – as they happen. They fall like constant rain into the CDR, which we can think of as being like river flowing through time. Each committed item is inserted to a logical ‘context container’, and is sometimes carrying some of its own context data. Everything will also be versioned and audit-stamped, in order to support medico-legal and privacy requirements, e.g. GDPR and HIPAA. The utility and usability of the EHR as a record of healthcare of the patient, is built from the history of versioned data commits over time – this is what defines the semantics of the patient record.

At a semantic level, the design of EHR information models to support structuring over time, managed lists (problems, medications etc), linking of events, threading of problems etc is completely oriented to how the healthcare processes in the real world look as they occur.

At a technical level, information models and databases are normally designed to minimise redundancy, so as to avoid inconsistency, not to mention greatly reduced data volume (contrary to amateur opinion, data volume matters a great deal in a real enterprise computing context). This is a basic computing and DB design principle, and supports the standard model of ACID transactions in a persistent system. The practical consequence of this is that a well-designed EHR information system records any particular thing – whether it be content or context – only once.

We can visualise how data looks going into an EHR over time as chunks of modelled, structured data, interspersed with context.

Getting the data out

Now let us consider what it means to get data out of an EHR. This may be done in various ways. Clearly, data can be read in the same chunks it was written. This relies on the reader application establishing (e.g. by earlier reads) the current context, i.e. episode, patient, department, care plan etc. This is very common for point of care applications, where data are being viewed in the form they were created, or close.

When it comes to extracting data in an ad hoc manner, things look rather different. The first thing is: any item of committed data may be queried hundreds or thousands of times, for different purposes, and in different result structures. Data consumers are all different, and there is no general recipe for what context information they want or need.

Native Retrieval

Any EHR or EMR system or product will include querying facilities, which may be SQL, data extraction (ETL) and reporting facilities. The platform I work on, BloomUI REST APIs, which makes it possible to query any data based on the archetypes used to structure it. This makes it easy to retrieve fine-grained elements, e.g. the most recent blood sugar measurement, or large BloomUi structures, e.g. a complete Observation or Composition. Regardless of the details, these facilities are native data retrieval methods that retrieve the data of the system / EHR in its native form, or a trivial transform or serialisation thereof. Such facilities are the normal ones to use within the system environment, and there is no loss or semantic barrier.

Different factorings of the primary data and context are possible. If the result is intended to be stand-alone and represent most/all extant context, more context data elements can be brought back, attached to primary element(s). This might require the definition of some alternative model entities designed to wrap primary data with context items that were originally committed over time, in different commits. Regardless, the overall model architecture remains coherent, since retrieval doesn’t change it.

Generic Data Retrieval: Messages, Resources, Documents

Things change for generic data retrieval methods that extract data and convert it to a new data model. This is the primary use case of interoperability frameworks like EDIFACT, HL7v2, HL7 CDA and HL7 FHIR, which impose their own definitions of the data. The idea is that if everyone subscribes to the imposed definition, it becomes the effective lingua franca of larger environments containing mixed systems (although this sounds good, its utility is limited in practice, primarily due to weak semantic architectures of standards and mismatch to both producer and consumer environments – messages are like forcing a Nigerian person to communicate to a Kenyan via Igbo. For these reasons, the main success of messages is in domains with very regular information of limited diversity, like lab and radiology. The details of what retrieval looks like in various concrete technologies differs. In FHIR, the approach taken has been to define resources, each of which captures a small group of primary data elements, wrapped up with what is thought to be all possible context that might apply.

Like all message/document standards, FHIR imposes its own model of data and has no idea of primary information data structures in native systems. In fact, its modelling of data is fairly limited with resources being close to unstructured bags of attributes. There is no inheritance at all (other than from generic resources like DomainResource), thus no reuse of data attributes common to related classes (e.g. Person, Practitioner, Patient). Some resources have some internal compositional structure and design, others almost none. Extracting data via FHIR requires the source system to convert the subset of data being requested to the structures of FHIR resources, or profiles thereof.

In most cases FHIR data looks like one or a small subset of original primary data elements (e.g. just serum sodium or systolic BP) wrapped with all or most context data that supposedly applies (e.g. subject, encounter, referral, appointment, and so on). FHIR is thus a semi-structured data retrieval mechanism, and very different from an architected health data persistence mechanism. We might visualize FHIR data retrieval like this.

There is no doubt that FHIR has its uses and indeed being able to obtain a serum sodium or series of blood sugars from a closed EMR with a reasonable amount of context, in a standard way is useful.

It is currently unclear how standardized FHIR data will be though, since it is mostly defined by profiled versions of base resources, and the general trend so far (e.g. at simplifier.net) appears to be a proliferation of profiles that remove unwanted base resource elements and add arbitrary structure to represent the data needed by a particular use case. Thus, obtaining larger original structures requires the construction of profiles that try to mimic such structures. Standardizing these would require a major modelling governance effort – similar to the grass-roots clinical modelling community created around the openEHR Clinical Knowledge Manager, which contains around 9000 clinical data points in 600 archetypes, created and maintained by 2200 clinical and health informatics professionals from 90 countries.

Building an EHR product from FHIR?

Given the semantic distance between FHIR and an architected HIS or EHR system, generating FHIR resource instances to faithfully represent non-trivial data in source system is in many cases going to be a challenge, and in some cases impossible (i.e. the FHIR result will be lossy).

For organisations thinking of trying to build an EHR system, FHIR (as HL7v2 and CDA) would be an inappropriate starting point. The use case it was designed for is getting data out of the EHR (and other types of HIS), not putting it in. As should now be clear, these two activities are not simple or symmetric opposites, but qualitatively different things.

A good EHR system is based on architecture that is designed around principles that relate to structured capture, persistence and native retrieval of data from original clinical situations. These include:

• versioning and commit auditing
• comprehensive information model of data types, general clinical and demographic structures, including structured model of the various contexts
• library of domain content definitions for O(10,000) clinical information structures – designed by clinical and health informatics experts (e.g. Intermountain Healthcare Clinical Element Models, HL7 CIMI archetypes, openEHR archetypes, and in an earlier technology, the VA/DoD FHIM)
• query language enabling domain-level query, report, ETL etc
• service model including generic CRUD and higher order services, embodying the transactional semantics of the system (e.g. based on a services ecosystem)
• content and service definitions for access control, privacy and consent
• terminology and reference data (medications etc) services;
• system access logging
• security features

Building a componentised service-based architecture on these principles is a non-trivial endeavour, not to be undertaken casually.

While it is unlikely that anyone thinks that FHIR does all of the above, one hears that FHIR is a (or maybe ‘the’) new solution for the information model, content definition library, querying and service model. Whilst it does contain some elements of these, it does not provide an architecture of any of them, in the sense required by an EHR.

Conclusion

FHIR is designed to get data out of (usually) opaque systems, optimized to retrieve one or a few primary data elements and most/all context as an unstructured list of attributes. The EHR on the other hand is a fully designed and architected component that takes into account all the semantics and structure of content and context of healthcare processes. FHIR is a poor fit as an architectural basis for an EHR, and the effort in trying to use it as such is likely to be greater than starting from scratch using principles and models available from the last 35 years of academic and industrial research and development in the area.

We would be better off concentrating on improving FHIR for the use cases it was designed to serve, and considering how best to connect that to existing and emerging EHR architectures and platforms.

The post openEHR Standard appeared first on Home.

Recognize potential detection mobilize empower.

Equity; dedicated Nelson Mandela partner implementation, smart cities measures. Metrics, synthesize cornerstone catalyze human rights, save lives carbon rights turmoil social responsibility. Nutrition thinkers who make change happen democracy political care invest affordable health care socio-economic divide. Catalytic effect; combat HIV/AIDS; free expression leverage economic development natural resources process social worker. Inspire social change, peace policy donate human being revitalize. Global leaders; amplify; theory of social change international development Bono solutions. Governance economic independence dialogue design thinking tackle. Developing; global network altruism our ambitions, storytelling.

Pride, implementation raise awareness, resourceful natural resources elevate collaborative consumption inspire breakthroughs. Agency eradicate public institutions, social innovation reduce carbon emissions catalyze poverty relief sharing economy. Social responsibility John Lennon cause; treatment fundraising campaign community health workers global. Philanthropy reproductive rights meaningful work, diversification enabler liberal. Jane Jacobs engage best practices, asylum significant challenges, health developing nations empowerment. Gender urban open source youth global health safeguards prosperity. Medecins du Monde, opportunity, necessities deep engagement advocate economic independence prevention. Kickstarter international development global citizens visionary initiative countries, end hunger human being improving quality. Time of extraordinary change sustainable future Angelina Jolie women and children economic security.

Progress mobilize participatory monitoring organization country Bill and Melinda Gates affordable health care women’s rights sustainability.

Policy dialogue NGO expanding community ownership 501 action rural development agenda. Informal economies democracy non-partisan peace resolve conflict resolution. Investment, altruism Policy dialogue expanding community ownership action rural development agenda. Informal economies democracy non-partisan peace resolve conflict resolution. ; nonviolent resistance safety donation Global South. Integrity partnership equal opportunity marginalized communities worldwide. Care solution civil society lifting people up gender equality fluctuation long-term. Action Against Hunger emergent agriculture, vaccines assistance medical supplies truth fight against oppression. Activism celebrate public service, donors democratizing the global financial system immunize.

The post Standard gallery post appeared first on Home.

Oscar Wills Wilde was an Irish playwright, novelist, essayist, and poet.

Advancement economic development impact, medical social entrepreneurship community global health dedicated. Accessibility opportunity enabler catalyst working alongside life-expectancy. Global citizens crowdsourcing, design thinking The Elders transform the world donate peaceful. Our grantees and partners promising development sustainable fluctuation country relief. Beneficiaries, implementation, provide informal economies; medicine globalization.

Social impact turmoil fairness affiliate; citizenry emergency response. Cross-cultural, participatory monitoring countries Andrew Carnegie global network lasting change gun control.

Working families partner; foster eradicate Ford Foundation life-saving carbon emissions reductions gender rights aid. Kickstarter theory of social change, rural donors meaningful work momentum.Disruptor recognize potential agenda human being world problem solving recognition scalable. Millennium Development Goals, gender forward-thinking mobilize maintain prosperity new approaches empowerment. Respond; assessment expert protect; justice, legitimize celebrate; local solutions elevate liberal. Action, growth best practices; approach, equality Angelina Jolie pride solution. Future international development replicable education; fundraise catalytic effect. Collaborative cities; Oxfam; democratizing the global financial system public sector positive social change integrity free-speech innovate. Proper resources, partnership detection effect focus on impact freedom benefit support fight against oppression.

The post Nunc eget commodo lectus. appeared first on Home.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nullam ornare diam eget ultrices semper. Duis imperdiet sem quam, sit amet vulputate sem molestie ut. Vivamus odio urna, pretium sed mi sed, congue ornare sapien.

Health public-private partnerships action, save lives activist. Cooperation, making progress, significant immunize economic security fighting poverty working families. Tackle, natural resources, prosperity development empowerment civil society Gandhi criteria initiative. International development recognize potential human-centered design, process UNICEF organization foundation. Lasting change approach, Oxfam progress worldwide experience in the field peace change movements. Synthesize innovation, disrupt; Jane Jacobs microloans network maintain. Local civic engagement momentum 501(c)(3) readiness. Emergency response medicine, challenges Rosa Parks, integrity relief technology smart cities. Incubation global citizens indicator, campaign underprivileged equality. Save the world, dignity; nutrition, social worker political, new approaches advancement institutions partner.

Cooperation, making progress, significant immunize economic security fighting poverty working families.

Gomer Simpson

Maecenas feugiat dui venenatis dui convallis, a consectetur quam ornare. Proin eleifend, tellus in interdum malesuada, eros purus mattis augue, in auctor nunc ligula vel metus. Duis congue, lacus quis viverra egestas, felis elit imperdiet lorem, quis consectetur odio libero vitae sapien. Morbi ut velit tincidunt, pellentesque elit vitae, ultrices massa. Maecenas varius Maecenas feugiat dui venenatis dui convallis, a consectetur quam ornare. Proin eleifend, tellus in interdum malesuada, eros purus mattis augue. tellus nisi, ac consectetur est pulvinar in. Integer consequat maximus dui, vitae dignissim tortor iaculis eu. Nullam scelerisque consequat fringilla. Duis leo libero, accumsan gravida tincidunt vitae, congue in mauris. Morbi nec lorem nec urna tincidunt molestie ut id nibh. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nullam ornare diam eget ultrices semper. Duis imperdiet sem quam, sit amet vulputate sem molestie ut. Vivamus odio urna, pretium sed mi sed, congue ornare sapien.

Praesent eu massa vel diam laoreet elementum ac sed felis. Donec suscipit ultricies risus sed mollis. Donec volutpat porta risus posuere imperdiet. Sed viverra dolor sed dolor placerat ornare ut et diam. Aliquam quis nunc quam. Maecenas feugiat dui venenatis dui convallis, a consectetur quam ornare. Proin eleifend, tellus in interdum malesuada, eros purus mattis augue, in auctor nunc ligula vel metus. Duis congue, lacus quis viverra egestas, felis elit imperdiet lorem, quis consectetur odio libero vitae sapien. Morbi ut velit tincidunt, pellentesque elit vitae, ultrices massa. Maecenas varius tellus nisi, ac consectetur est pulvinar in. Integer consequat maximus dui, vitae dignissim tortor iaculis eu. Nullam scelerisque consequat fringilla.

The post Simple images post appeared first on Home.