FDA approves electronic pills to track individual medication administration

Healthcare Big Data

Part 2: The method

The fun part with designing a big data system is that both ends of the tunnel have a fuzzy light: the data is not in a stable, normalized form, and the intended presentation is itself not clear, mostly because a better idea of what we want is only possible when we start having something.
Coming up with a universal data model that covers all the cases is not possible, for the simple reason that the goals are many, and they are growing and changing.

To address this challenge, I started using a simple analysis methodology:
I separate the scenarios from the use cases, and they both evolve hand in hand.

• Use Cases are the intended actions that rely on the data, independent of the fact that the data may be available.
• Scenarios are the conditions and data that can be available, regardless of their use. 

According to W. H. Inmon (if I’m not misquoting; I lost the reference), the data analysis does not present the information needed for use cases. It represents what we could possibly do with it (In a next post I’ll make a good analogy where this should be clear).
For big data, we can iteratively build up the data model as more use cases are found; and iteratively build up possible uses for the data, as more data becomes available and is integrated / federated into the data model.

These two aspects are synergetic: New use cases can provide need for new data, and availability (or unavailability) of data can determine the uses for that data.

This applies to data and metadata:
Unavailability of some data can be interpreted differently (not having a report of administration of an injection in a hospital has different impact and meaning from a patient’s lack of reporting taking anti-depressive medication).

The information quality may depend on who provides it (for example some cultural factors will influence the customer’s report of use of drugs, contraceptives, etc.)/

When building the model (and very carefully separating it from the use cases), my rule is: keep everything just in case. For example, a cell phone can have an attached device that monitors the patient’s glucose levels. This is not the same as a measurement by a nurse, but we don’t want to waste this information just because a hospital currently does not want to use it.

Healthcare Big Data

 

Part 1: Introduction
When it comes to big data, healthcare is an excellent place to find it.
Data is structured and captured in different manners, there’s lots of data, and it is hard to get any sensible information out of this data put together.
In healthcare, traditionally, data (and models) are split by department; data needed for a department were modelled according to the needs of that department. Most of this data is not shared. But data that represent patient or workflow information could be shared: patient demographics, patient location/status, current attending physician, allergies, wound documentation, which user accesses the patient record...
The need for cross-department (and cross-institution, and cross domain) data is emerging as important e.g. for decision making. This data is important for clinical reasons (informed decision making), and operational reasons (e.g. Meaningful Use in the US, and the growing interest in Europe for operational/efficiency improvements).
Even breaking the boundaries between healthcare domains will be insufficient: Healthcare data is not a silo. Institutions and patients collaborate on health data, but also other institutions can play a role. Work and social environment, demographics information, etc. can be potentially relevant.

Should a person that lives in the mountains and takes many intercontinental flights mention that to the physician that is evaluating the possibility of an ionizing radiation procedure?

Should a patient’s demographics be taken into account in deciding the sensitivity of a procedure?

Should a patient’s social habits considered when recommending a continued treatment?

When prescribing a drug, should we consider the habits of the patient and his surroundings?

Coming down to spaceship earth, within a healthcare organization, information can be captured anywhere, and this information is getting more stretched to be viewed under different perspectives.
Data Interfaces (messages) are usually designed to provide just enough data for continuation of a workflow. And these data are modelled for the specific needs of the originating system. If we want to know a patient’s full history, there will be some collage work, especially if we want the information to be in a usable form.
Here I propose a look at the problem, the possibilities and the goals, and I present a way of jumping across these water lilies. The keyword is: Iterate.

 

Next:

• Part 2: The approach
• Part 3: The delicious analogy

Data are not a byproduct, but the fuel for an operable system

As systems focus more on data, its meaning and its use in different contexts, it seems fair to affirm that while Data was the byproduct of previous software applications, data is presently the circulating blood of applications and system architectures.

System requirements and system specifications

I am putting effort in system delivery - making sure that the product developed really works, and helps!

Observing that software development processes are still clones of "hardware" system design (where one piece is designed in detail for a few months, and implemented in the next months), I have  struggled with one conception that contributes to lack of quality and effectiveness, and - very important - to collaboration between the participants:

The notion that the initial plan is complete and accurate, and deviations are accidents.
or
The idea that once we know the plan, we know the outcome.

The final detailed specifications of a system are changing even after delivery, and the capture of this information can help make a product great, by allowing good knowledge of the product.

This seems essential in complex system design, and in healthcare it is an absolute must.
It also seems essential in Agile development, where the focus is in delivering value time after time, and clinging to an initial plan is not a (good) option.

So, the delivery phase of a system should include documenting any relevant aspects that were not detailed upfront.
- How the screen actually looks like
- What is the impact of the technical choices in functional aspects (like performance constraints, etc.)
- What detailed findings are there that can provide additional info

...and yes,
- What have we learned that can trigger new requirements or ideas.

This seems much better than the exuberance of documents to guess what is going to be the outcome.

In short - it is impossible to know all the details upfront, but this doesn't mean that details are not important.

RFID and tracking of stuff

Going back to hardware days.

Getting myself an RFID reader to start playing with cards, tracking and the corresponding software.

Expensive stuff - will get a cheaper one:
http://www.alibaba.com/product-gs/510277926/13_56Mhz_NFC_RFID_reader_factory.html

- Tracking people
- Tracking things
   - Tracking things that appear with other things, or with people
- Tracking flows of things across places.