The second question that I would like to cover in this HIT series is how technology can improve the lives of patients during and after hospitalization.
These are some examples of situations that I have witnessed in the last couple of months where I believe better use of technology could have improved my personal experience and, maybe even, the medical outcome:
1) During hospital stay:
a. Changes in medication or treatment – The doctor would visit me during his daily rounds and we would discuss any treatment changes required. After he finished his round (and visited over a dozen patients), he would enter all changes into the hospital’s IT system with a clear risk of forgetting some of the necessary changes. Why not directly enter changes into a connected tablet while doing his round?
b. Questions to doctor – Unless there was an emergency, I only had access to the doctor during his rounds. Why not allow me to send him secured messages with questions / requests, that he could check and reply at his convenience?
2) During convalescence period:
a. No communication between hospital and GP – The day after I was released from hospital I went to see my GP. He had not received any information during the many weeks I spent there. I had to give him copies of all the medical reports and test results for him to review and enter into his IT system for future reference. Why not have the hospital communicate directly with him?
b. Logging my ‘symptoms’ – I had many things to control the first few weeks out of hospital (blood sugar levels, temperature, heart rate, amount of exercise…). I logged all the information in an Excel sheet that I would share with all my doctors during visits. Why not log data into an app directly connected with the doctors’ IT systems?
Are there any industry-wide initiatives to promote the use of technology to cover these issues and the many other experienced by patients every day? There are, indeed, a number of initiatives but the one that seems most promising to me is the SMART program.
SMART stands for ‘Substitutable Medical Apps, Reusable Technology’ and is backed by the U.S. Department of Health and Human Services (DHHS), the US government principal agency for protecting the health of all Americans and providing essential human services.
The concept was initially described by Kenneth D. Mandi, MD, MPH, and Isaac S. Kohane, MD, PhD in an article published in The New England Journal of Medicine in 2009. They envisioned a ‘flexible information infrastructure that facilitates innovation in wellness, health care, and public health.’ To achieve this vision, they advocated a platform approach to software design that would support an extensive ecosystem of apps similar to those developed on the iPhone or Android platforms. Such an easy-to-use, flexible and robust platform could certainly support an ecosystem that would solve all the issues I described above and many more.
The key characteristic of such platform would be:
1) Liquidity of data – Clear APIs that would allow apps to easily access all available data across systems.
2) Substitutability of apps – A primary care provider should be able to readily use a billing system from one vendor and a prescription-writing program from another. Furthermore, he/she should be able to change from one billing system to another with minimal effort to ensure the creation of a competitive and vibrant marketplace for apps.
3) Open standards – The platform should be built to open standards, accommodating both open-source and closed-source software.
Mandi and Kohane also envisioned the DHHS having a key role, particularly in the following areas:
1) Regulation – Although the platform would support a free marketplace of products and ideas, the DHHS should ensure that the dominant driving force is the maximization of health and that adequate privacy protection is in place.
2) Incentives – The DHHS should offer incentives to providers to make use of HIT to improve quality of care.
This idea was picked up by the DHHS and it is being implemented through its SHARP Program (Strategic Health IT Advanced Research Projects).
Although the platform, data models and API are not yet finalized, app developers can start to experiment with a preliminary API and data model that have been made public, along with sample code and development tools and support. In fact, in order to motivate developers to collaborate, the Office of the National Coordinator for Health Information Technology lead by Dr. Farzad Mostashari has launched a number of challenges targeting the development of specific apps that are viewed as key starting points to build a proof of concept of the ecosystem.
Furthermore, as proof that this approach could be applied not just across the US but across the world, one of the entries into the UK’s National Health Service first NHS Hack Day on May 26th-27th was an app implementing a portion of the SMART API to expose the HES dataset showing a data grid and radar chart for patient problems. More important than the app itself are the strategic implications of this development. Co-developer Rob Tweed explained that ‘The technology clearly works and is applicable to use in the UK just as in the US. This is a set of wheels that the NHS can avoid re-inventing.’ Indeed, it is a set of wheels that many countries around the world could re-use. Could this mean global interoperability in health care?
These are some examples of situations that I have witnessed in the last couple of months where I believe better use of technology could have improved my personal experience and, maybe even, the medical outcome:
1) During hospital stay:
a. Changes in medication or treatment – The doctor would visit me during his daily rounds and we would discuss any treatment changes required. After he finished his round (and visited over a dozen patients), he would enter all changes into the hospital’s IT system with a clear risk of forgetting some of the necessary changes. Why not directly enter changes into a connected tablet while doing his round?
b. Questions to doctor – Unless there was an emergency, I only had access to the doctor during his rounds. Why not allow me to send him secured messages with questions / requests, that he could check and reply at his convenience?
2) During convalescence period:
a. No communication between hospital and GP – The day after I was released from hospital I went to see my GP. He had not received any information during the many weeks I spent there. I had to give him copies of all the medical reports and test results for him to review and enter into his IT system for future reference. Why not have the hospital communicate directly with him?
b. Logging my ‘symptoms’ – I had many things to control the first few weeks out of hospital (blood sugar levels, temperature, heart rate, amount of exercise…). I logged all the information in an Excel sheet that I would share with all my doctors during visits. Why not log data into an app directly connected with the doctors’ IT systems?
Are there any industry-wide initiatives to promote the use of technology to cover these issues and the many other experienced by patients every day? There are, indeed, a number of initiatives but the one that seems most promising to me is the SMART program.
SMART stands for ‘Substitutable Medical Apps, Reusable Technology’ and is backed by the U.S. Department of Health and Human Services (DHHS), the US government principal agency for protecting the health of all Americans and providing essential human services.
The concept was initially described by Kenneth D. Mandi, MD, MPH, and Isaac S. Kohane, MD, PhD in an article published in The New England Journal of Medicine in 2009. They envisioned a ‘flexible information infrastructure that facilitates innovation in wellness, health care, and public health.’ To achieve this vision, they advocated a platform approach to software design that would support an extensive ecosystem of apps similar to those developed on the iPhone or Android platforms. Such an easy-to-use, flexible and robust platform could certainly support an ecosystem that would solve all the issues I described above and many more.
The key characteristic of such platform would be:
1) Liquidity of data – Clear APIs that would allow apps to easily access all available data across systems.
2) Substitutability of apps – A primary care provider should be able to readily use a billing system from one vendor and a prescription-writing program from another. Furthermore, he/she should be able to change from one billing system to another with minimal effort to ensure the creation of a competitive and vibrant marketplace for apps.
3) Open standards – The platform should be built to open standards, accommodating both open-source and closed-source software.
Mandi and Kohane also envisioned the DHHS having a key role, particularly in the following areas:
1) Regulation – Although the platform would support a free marketplace of products and ideas, the DHHS should ensure that the dominant driving force is the maximization of health and that adequate privacy protection is in place.
2) Incentives – The DHHS should offer incentives to providers to make use of HIT to improve quality of care.
This idea was picked up by the DHHS and it is being implemented through its SHARP Program (Strategic Health IT Advanced Research Projects).
Although the platform, data models and API are not yet finalized, app developers can start to experiment with a preliminary API and data model that have been made public, along with sample code and development tools and support. In fact, in order to motivate developers to collaborate, the Office of the National Coordinator for Health Information Technology lead by Dr. Farzad Mostashari has launched a number of challenges targeting the development of specific apps that are viewed as key starting points to build a proof of concept of the ecosystem.
Furthermore, as proof that this approach could be applied not just across the US but across the world, one of the entries into the UK’s National Health Service first NHS Hack Day on May 26th-27th was an app implementing a portion of the SMART API to expose the HES dataset showing a data grid and radar chart for patient problems. More important than the app itself are the strategic implications of this development. Co-developer Rob Tweed explained that ‘The technology clearly works and is applicable to use in the UK just as in the US. This is a set of wheels that the NHS can avoid re-inventing.’ Indeed, it is a set of wheels that many countries around the world could re-use. Could this mean global interoperability in health care?
RSS Feed