onsdag den 5. august 2009

Welfare Technology – Architectural Considerations

(The Continua Architecture for Tele Health Care)
In this blog let us try to get a closer look at the requirements for an architectural approach to ‘Welfare Technology’. Without this and without a set of well defined open standards and standard interfaces, this area will soon become a jungle. It is already crowded with non-communicating gadgets, robots, semi-automatic toilets, showers, pets and various pieces of kitchen equipments.
First, we need a conceptual framework for which purposes we are pursuing when we are talking ‘welfare’.
Welfare has (at least) the following attributes:

1. Autonomy – to be able to manage your own life, movements and daily activities – also for impaired person
2. Safety/security – feeling secure from crime, intrusion, natural catastrophes, accidents in your home and when moving around
3. Wellness – being able to exercise physically and mentally
4. Socially accepted and included – communicate with peers, family, colleagues and be part of a community
5. Disease self Management – being able to control chronic (or other diseases)

If you look at ‘welfare’ in this context, it is obvious that Tele Medicine is only a fraction of this picture, even if the importance of managing own diseases of course should not be underestimated - in particular as more than half the population over 65 years of age suffer from one or more chronic diseases and soon will consume more than 80% of the total health care costs in the Western Societies.

For each of the 5 Welfare Attributes, a different set of Stakeholders becomes visible beside the citizen/patient herself: Those providing services (nurses, health assistants, doctors, social service providers, fitness centres etc.), stakeholders that sell equipment and SW, the payers (the citizen herself, the municipality or the insurance company), peers (friends, family, community members).
It is likewise obvious that stand-alone devices only account for a few of the potential number of devices, monitors, instruments and gadgets that provide the arsenal of welfare technology.

Each set of stakeholder has a specific set of needs regarding the information measured, communicated, analyzed and presented for them: The Doctor needs to have a reliable set of measurements and correlation data with historic medical record as well as a range for possible future developments in key health indicators. The fire brigade and the rescuing team only need a confirmed, fast alert before they move out to help. The patient/citizen herself need to have a simple yet trustworthy user interface that is adapted to her capabilities, experience and physical and mental condition; The social network involving friends, family and community need varying degrees of signal quality and possible same time capacity.
So the following principles for the technical solution should be respected:

- User Interfaces in accordance with the receivers skill and level of comprehension
- ‘Need to know’ tailored to the stakeholder
- Integration with back end services and data bases where needed and presented in context
- Logging and tracing in accordance with audit rules and regulations
- Compliant with security and privacy regulations
- Open interfaces to allow for constant adoption of new technologies

This has led the CONTINUA organisation http://www.continuaalliance.org/ to launch the recommendation for a generic architecture, that meets their overall objective for Welfare Technology:
“Fostering independence through establishing a system of interoperable personal telehealth solutions that empower people and organizations to better manage health and wellness.”
The Continua Architecture can be studied at this link: http://continuaalliance.org/static/cms_workspace/The_Continua_Health_Alliance-_The_Impact_of_a_Personal_Telehealth_Ecosystem.pdf

Also vendors of Bluetooth technology have adhered to the demand for interoperability using open standards. These standards are described as Principles of Health Interoperability in HL7 and SNOMED definitions.
But the Continua Architecture in my opinion does not cover the more holistic approach to Welfare Technology which we are discussing; CONTINUA is focusing too much on the technical interoperability between the components and not on the semantic and logic interoperability between the stakeholders, which play a very important role in the total configuration of a complete solution.
In fact, collaboration and hence web 2.0 connection functionality is a cornerstone of a practical solution, where the client/patient/citizen needs to exchange view points with a variety of assisting helpers.
While portal technology and SOA principles makes a lot sense primarily for the professional participants in the Welfare Network, the community side, in particular private persons, relatives, NGO’s and peers has a clear need of collaboration tools and techniques otherwise known from Web 2.0.

Hence I propose the following generic Welfare Technology Architecture, which also meets the requirements of CONTINUA, HL7 and SNOMED.

And if you try to look for web 2.0 solutions in healthcare, you will be amazed!
Here is just a small sample: http://www.feedmyapp.com/web_20_health_applications_sites

In a later blog we will discuss the economic impact and experiences of Welfare (and Health) Technologies.