MedRPM: An Open Source Framework for constructing iPhone-based Remote Patient Monitoring Solutions Larry Suarez Grid Research Group Agent Health, Inc. Abstract Remote patient monitoring (RPM) is an important aspect of patient management and support. RPM is becoming critical due to rising medical costs, the shortage of medical personnel, and the increasing number of individuals with chronic diseases. MedRPM is a software and hardware framework that allows medical vendors to quickly construct commercial RPM solutions based on the Apple iPhone. The system is unique in that it can support the triad of patient monitoring: health, safety, and environment. The iPhone acts as the central patient management system collecting patient and environmental monitoring data. An iPhone application called iRPM allows the iPhone to receive wireless monitoring data from a number of sources and for patients to interact with the iPhone to provide clinically relevant information. MedRPM is intended to spur the adoption of RPM solutions in the medical industry. All software in the framework is open sourced. Remote Patient Monitoring Remote Patient Monitoring (RPM) refers to the monitoring and management of patient health conditions. The monitoring occurs within a remote environment (remote from the care provider) such as the patient’s home. Devices such as weight scales, glucometers, pH sensors, temperature sensors, and blood pressure monitors transmit patient monitoring data to a collection station within the patient’s environment. The data is then transmitted to care providers who analyze the data to determine new treatment regimens, modify existing regimens, treat declining health conditions, or diagnose patient status. Home health solutions have been the early adopters of RPM solutions. However, RPM solutions will see their greater need in the area of chronic care and disease detection. Within this paper, we also include medical studies within the RPM umbrella. A medical study is the remote monitoring of a patient for a pre-determined amount of time (for example, twenty-four hours) to determine the presence or absence of a medical condition. A typical RPM architecture is shown in Figure 1: Example RPM Architecture. The patient’s home contains a computer server that receives data transmitted from monitoring devices in the home and/or worn by the patient. The devices contain a wireless transmitter which sends patient condition information using any number of industry communication protocols such as Bluetooth or Zigbee. The server receives the
Transcript
MedRPM: An Open Source Framework for constructing iPhone-based Remote Patient Monitoring Solutions
Larry Suarez Grid Research Group Agent Health, Inc.
Abstract
Remote patient monitoring (RPM) is an important aspect of patient management and support. RPM is becoming critical due to rising medical costs, the shortage of medical personnel, and the increasing number of individuals with chronic diseases. MedRPM is a software and hardware framework that allows medical vendors to quickly construct commercial RPM solutions based on the Apple iPhone. The system is unique in that it can support the triad of patient monitoring: health, safety, and environment. The iPhone acts as the central patient management system collecting patient and environmental monitoring data. An iPhone application called iRPM allows the iPhone to receive wireless monitoring data from a number of sources and for patients to interact with the iPhone to provide clinically relevant information. MedRPM is intended to spur the adoption of RPM solutions in the medical industry. All software in the framework is open sourced.
Remote Patient Monitoring
Remote Patient Monitoring (RPM) refers to the monitoring and management of patient health conditions. The monitoring occurs within a remote environment (remote from the care provider) such as the patient’s home. Devices such as weight scales, glucometers, pH sensors, temperature sensors, and blood pressure monitors transmit patient monitoring data to a collection station within the patient’s environment. The data is then transmitted to care providers who analyze the data to determine new treatment regimens, modify existing regimens, treat declining health conditions, or diagnose patient status. Home health solutions have been the early adopters of RPM solutions. However, RPM solutions will see their greater need in the area of chronic care and disease detection. Within this paper, we also include medical studies within the RPM umbrella. A medical study is the remote monitoring of a patient for a pre-determined amount of time (for example, twenty-four hours) to determine the presence or absence of a medical condition.
A typical RPM architecture is shown in Figure 1: Example RPM Architecture. The patient’s home contains a computer server that receives data transmitted from monitoring devices in the home and/or worn by the patient. The devices contain a wireless transmitter which sends patient condition information using any number of industry communication protocols such as Bluetooth or Zigbee. The server receives the
The MedRPM System 2
Agent Health, Inc. 4/24/2010
data, stores it, and later transmits the data to another server based at the care provider’s location. Patient monitoring data is typically analyzed at the care provider’s location although minimal analysis may also be done within the patient’s environment. The patient’s cellular phone is used for communication with the care provider using cellular, instant messaging, and email. Monitoring is provided only at the patient’s environment. Once a patient leaves the environment, support is suspended. There are now RPM solutions (including MedRPM) which do support patient monitoring outside the patient’s environment.
Figure 1: Example RPM Architecture
The MedRPM framework is unique. It uses the Apple iPhone as the primary “server” both within and outside the patient’s environment. The iPhone becomes the central device that supports data collection, data processing, minimal data analysis, and patient-physician communication. Figure 2: MedRPM Architecture shows the general architecture of the MedRPM framework.
Figure 2: MedRPM Architecture
With the iPhone as the central server, the framework is very quick to deploy. Patients download the vendor iRPM application from the Apple App Store onto their iPhone and they are ready for monitoring. The architecture allows patients to enter other medical environments which have been enhanced for monitoring and immediately participant in those environments. In the future, all hospitals will be enhanced for wireless patient monitoring and a patient, by merely entering the hospital, will be recognized, monitored, and even superficially treated before seeing any care provider. The iPhone represents the first consumer cellular solution that supports enough computing power to be truly viewed as a server.
The MedRPM System 3
Agent Health, Inc. 4/24/2010
MedRPM is intended to spur the adoption of RPM solutions in the medical industry. MedRPM has two goals: first, enable medical vendors to quickly construct RPM solutions with minimal cost. Reducing the cost of constructing RPM solutions (and hence the consumer cost of the resulting solution) is paramount to RPM adoption; second, enable the inclusion of advanced core features for RPM solutions. By providing core features in MedRPM, medical vendors can concentrate their expertise on providing focused disease management solutions.
RPM solutions consist of both hardware and software components. The software components can be provided free of cost through open source initiatives. The hardware components are much different because they are provided by medical vendors. MedRPM is attempting to provide a number of free smart motes that can be used immediately by the patient. The patient will distribute the smart motes in their environment per care provider instructions. The smart motes will immediately form a network and communicate with the iRPM iPhone application. Other devices used to monitor the patient must be purchased separately by the care provider or the patient.
There are a number of issues with RPM that are slowing full adoption including:
Cost. The cost of specialized RPM equipment is expensive such as enhanced
weight scales that support wireless communication.
Intrusive. Reviewing captured patient monitoring data requires the time of a care
provider. Time which is in greater demand in today’s medical environment. The required time does not fit well within the hectic office workflow of a care provider.
Reimbursement. Healthcare payers are reluctant to reimburse costs related to
RPM without clear evidence of the patient benefits.
Lack of Supporting Software. Lack of effective patient management software to
process patient monitoring data.
The MedRPM framework takes advantage of the current trends in software computing which will drive the effectiveness of RPM solutions and hopefully address the above issues. With the current trends of open source software, new analytical and supporting software for RPM solutions will be free. This will remove a large part of the cost burden to care providers. In addition, smart phone technology has now reached a point in which they can replace existing dedicated RPM patient devices. Smart phones can now support complex software, support numerous networking capabilities including Bluetooth and Wi-Fi, have onboard sensors, cameras, and audio recording capabilities. Smart phone features are being added at a mesmerizing pace much faster than medical vendors using specialized patient devices.
In the sensor market, smart motes are a new technology that is rapidly reaching maturity. Smart motes are small computers (typically one inch square) that have sensors. Smart motes can be sprinkled throughout a patient environment and provide visibility into the environment including temperature, appliance usage, and security. Smart motes are also replacing simple wireless transmitters found in today’s medical devices to enable the devices to take on more tasks. Sensors are advancing at a rapid pace. There are now sensors which can measure vital signs and specific symptoms in a patient. These sensors are getting smaller, smarter, cheaper, and less intrusive.
The MedRPM System 4
Agent Health, Inc. 4/24/2010
The MedRPM Framework
MedRPM consists of four major components: the Apple iPhone docking shell, the iPhone application called iRPM, the web application server called MedView, and a collection of smart motes. Aside from the smart motes that monitor environmental data, the MedRPM framework does not include wireless monitoring devices. Patients and care providers must purchase the necessary monitoring devices related to their disease and support requirements. MedRPM provides a list of devices that currently work with the framework. It is expected that medical vendors using the MedRPM framework to create commercial RPM solutions will expand on that list. Figure 3: The MedRPM Framework shows the components of the MedRPM system.
Figure 3: The MedRPM Framework
The iPhone docking shell contains sensors, an additional battery, and a smart mote. The embedded smart mote allows the iPhone to converse with Zigbee-based wireless medical monitoring devices. Zigbee is an industry standard communication protocol that provides a number of advanced features for small wireless devices. We expect Zigbee to become the dominate protocol in the medical industry for wireless devices. The MedRPM framework does support other communication protocols such as Bluetooth. The iPhone slides into the docking shell which connects to the iPhone 30 pin connector. It should be noted that Apple is very restrictive in the use of the 30 pin connector and Bluetooth. A vendor must be part of the Apple “Made for iPod” program in order to create devices that use the 30 pin connector and Bluetooth.
The MedRPM framework provides the following core features:
Alert System. Both the iRPM application and the MedView application server
contain early detection and intervention features. MedRPM can alert care providers and patients as to issues that require immediate attention. For example, if a patient’s heart rate exceeds a defined threshold then an alert would be generated and sent to the care provider and the patient.
Data Integration. Data integration is the ability of MedRPM to exchange data
with existing medical data systems. Data integration is an important aspect of
The MedRPM System 5
Agent Health, Inc. 4/24/2010
patient support which may involve multiple care providers. The MedView application server can send and receive patient information in any number of industry data formats such as HL7, Microsoft Excel spreadsheets, and XML. MedView can send and receive the information in any number of network protocols such as web service calls, SOAP, HTTP, FTP, and email.
Timers. The iRPM iPhone application supports multiple timers to schedule major
patient regimen tasks such as when to take medication, when to create a diary entry, and when to create a data entry. These timers are necessary to ensure the patient follows specific regimens created by their care provider. iRPM will notify the care provider if a specific scheduled task is not accomplished by the patient.
Data capture. MedRPM supports data capture from a myriad of medical devices
including anticipated next generation devices. Data capture is the most important aspect of any RPM solution.
Patient education. Both the iRPM application and the MedView application
server can provide focused patient information for disease management, nutrition, and exercise recommendations. Patient information is the cornerstone of any medical regimen.
Social interaction. The MedView application server supports a patient blog to
allow patients to interact to share advice, experiences, and thoughts.
Patient Safety. The MedRPM framework includes a collection of smart motes for
monitoring patient safety in their environment. Smart motes are used to monitor environmental temperature, appliance usage, and security such as monitoring doors and windows. The iPhone sensors are used to detect patient falls while the GPS unit is used to track the location of patients. Patient location monitoring is important for patients with forms of dementia.
Physician-Patient Communication. A care provider can communicate directly
with their patient in the form of “notes” or messages using the Apple Push Notification system. The patient’s iPhone will vibrate and an indicator will appear on the phone to tell the patient that a message has been received from their care provider. Communication is also supported using the standard iPhone capabilities such as email, text messaging, and cellular.
Remote Data Analysis. An embedded rule system in the iRPM application will
interpret patient monitoring data as it arrives to the iPhone. The rule system will alert the care provider via email immediately if the data exceeds normal thresholds or any other criteria defined by the care provider. New threshold or analysis rules can be uploaded to the patient’s iPhone in real-time.
Simulation Mode. The iRPM application can execute in a special “simulation
mode” in which the application will “play” a previous session to allow patients and physicians to participate in “Human Computer Interaction” (HCI) studies. These studies do not require medical monitoring devices freeing the participants to concentrate on HCI issues.
Data Visualization. Ability to graphically display patient monitoring data both
on the iPhone and the MedView application server.
Real-time Update. Ability to upload to the patient’s iPhone in real-time new
information such as analysis rules, patient background information, session
The MedRPM System 6
Agent Health, Inc. 4/24/2010
details, event types, data types, and patient education material. This can be done without patient participation.
HCI Features. Advanced “Human Computer Interaction” (HCI) features to allow
patients to communicate with the iPhone with minimal effort. For example, patients can double-tab the iPhone screen and the iPhone begins recording a ten second audio memo without the patient having to view the iPhone.
Data Capture
Data capture is the primary task of any RPM system. The care provider needs quality monitoring data to ensure they have a good understanding of the patient’s status. Without good data, proper patient support is impossible. Data may come from a number of sources. Figure 4: Patient Data shows the possible sources of clinical data for MedRPM.
Figure 4: Patient Data
In addition to patient monitoring data from wireless medical devices, the iRPM application provides a screen for patients to manually input data including temperature, heart rate, blood pressure, and weight. For example, a timer in the iRPM application would notify the patient that it is time to take vital signs. The patient would then enter the vital sign data values manually into iRPM. The physician can add or remove data types such as “heart rate” from the iPhone to fit the RPM solution. Patients can enter reactions, events, and symptoms through a diary component. Finally, patients can create audio memos for the care provider. Support for manual patient monitoring data entry is important for situations where wireless enabled medical devices are too expensive or unavailable. Studies have shown that manual data entry is not as intrusive as one would suspect. Patients welcome the fact that someone is watching out for their safety and data entry is a reminder of that fact.
Care providers can send patient monitoring data directly to the iPhone either locally through Wi-Fi or remotely through the Apple Push Notification system. Patient visits to their non-primary care providers may generate data which needs to be added to their
The MedRPM System 7
Agent Health, Inc. 4/24/2010
iPhone. Chronic care patients typically have more than one care provider. Not all the care providers are enabled for patient monitoring. Having access to the patient’s iPhone allows all involved care providers to directly contribute to patient support.
The MedRPM system is designed to support the use of wireless medical sensors. Many embedded sensors in the industry support wireless communication protocols such as Bluetooth and Zigbee. These sensors may talk directly to the iPhone or indirectly through other devices (for example, smart motes). The iRPM application will evolve to support an ever increasing myriad of devices. New updates to the iRPM application will be made available through the Apple App store. The new updates will not affect monitoring data currently stored on the patient’s iPhone so the updates can be applied even during active patient monitoring sessions. Many consumer health devices have embedded wireless transmitters. The data can be transmitted directly to the iPhone for storage and processing. An example consumer health device is a weight scale. An ever increasing number of medical devices such as heart monitors and blood pressure monitors now have wireless capabilities. The data can be transmitted directly to the iPhone for storage and processing. Finally, smart motes (very small computing systems) distributed within the patient’s environment can communicate directly with the iPhone through the smart mote embedded in the docking shell.
The iPhone is unique from other cellular devices in that it contains onboard sensors. The sensors provide an opportunity to use the iPhone to automatically generate patient monitoring data in support of RPM. For example, the iPhone accelerometer can be used to determine if the patient has fallen or is in a supine position. Research is needed to determine the effectiveness of the accelerometer for RPM but it does provide some interesting possibilities. The iPhone proximity sensor is used for Human-Computer Interaction (HCI) purposes. Swiping the proximity sensor can automatically generate specific diary events or specific patient monitoring data. It is envisioned that the docking shell will contain additional sensors such as a heart rate sensor. A patient will be able to press their thumb onto the docking shell and the shell will automatically generate heart rate data.
Location information via the iPhone GPS capabilities is paramount in the support of patient conditions such as dementia. The iRPM application can track the patient to ensure they remain within their environment geographical boundaries. iRPM can generate “out of boundary” patient events while at the same time notifying the patient’s care provider. Care providers can track patients once they leave their environment. Diary events can be created automatically if patients are tracked within the geographic boundaries of known restaurants. Location tracking can be intrusive however for critical care patients its support is paramount.
Smart Motes
Although this paper presents a superficial discussion on the subject, smart motes are destined to become a major enabling technology for the medical industry. Smart motes are sometimes referred to as sensor networks. Smart mote networks are collections of distributed wireless devices that observe and respond to events within an environment. Smart motes have evolved from simple sensors to full fledge computer systems able to execute software solutions. A smart mote typically consists of five components on a small (1 inch square) platform: a microprocessor, memory, a transceiver (transmitter and
The MedRPM System 8
Agent Health, Inc. 4/24/2010
receiver), sensors, and a battery. Smart motes will initially be used to monitor patient environmental conditions such as temperature. Next generation solutions will have smart motes embedded in all wireless medical devices where they will carry on complex tasks and participate in patient monitoring networks.
Patient Data Format
Data traveling between MedRPM components can exist in a number of formats from proprietary to medical standards like HL7. MedRPM defines its own data format for data that travels between the iPhone and the MedView web application server. The following is an example MedRPM XML data value sent from iRPM to MedView.
The iRPM iPhone application is designed to understand a number of data formats. Over time, the iRPM application will support additional data formats driven mostly by the available sensors in the market. Figure 5: Data Formats in MedRPM shows the protocols supported among components in the MedRPM framework. Realize that data traveling through the network consists of not just patient monitoring data. iRPM also accepts data concerning patients, analysis rules, patient events, and sessions. The intent is not to have the MedRPM framework impose any data format constraints on vendors using MedRPM to create commercial solutions.
Figure 5: Data Formats in MedRPM
The MedRPM System 9
Agent Health, Inc. 4/24/2010
In Figure 5: Data Formats in MedRPM, notice that the communication is bi-directional for smart motes. Smart motes are able to form networks with other smart motes including the one embedded in the MedRPM iPhone docking shell. This is very important since a smart mote is much like a small computer which can run software and store data. Future enhancements to the MedRPM framework will support the updating of smart mote software in real-time. iRPM will be able to send data and software directly to a specific smart mote. Smart motes will be able to run data analysis software alleviating some of the work of the iRPM iPhone application and reducing the amount of wireless network traffic.
The iRPM iPhone Application
iRPM is an iPhone native application designed to support RPM solutions. The patient is able to interact with the iPhone via the iRPM application to input clinically relevant information such as meals, symptoms, and monitoring data. The iRPM application can exchange patient data with the MedView application server.
The main screen for the iRPM application is the patient dashboard. The dashboard provides important information about the patient including the number of active alerts, last received patient monitoring data value, the current active session, the number of unread patient memos, and a care provider emergency contact button. The emergency button allows the patient to quickly contact their care provider with minimal effort.
A session is a fundamental concept in the iRPM application. A session is a means of
organizing patient monitoring data. All monitoring data stored in the iPhone is stored within the context of a session. MedRPM makes no requirements as to when to create sessions or how many. A typical session would include data for a specific study or data defined for reimbursement under the patient’s healthcare plan. Sessions can be created on the iPhone through the iRPM application or sessions can be uploaded onto the iPhone by the care provider using the MedView application server. A session may be "active" which means it is currently the session of focus. Or "not active" which means either it is an older session or the session is being defined. iRPM can manage and store any number of sessions but only one session may be active at any one time. When a session is active, it will be displayed on the patient dashboard and all created memos, diaries, and patient monitoring data will be related to the active session.
A patient participates in a session under the supervision of a care provider. As part of the setup process for a session, the care provider must define the patient(s) within iRPM. iRPM can store any number of patients. To indicate that the patient participates in a particular session, the physician must link the two (session and patient) via the Session Detail screen in iRPM. The general attributes of a patient include the patient’s first and last name, the patient identifier (if applicable), gender, height, weight, and an iPhone device token value. An iPhone device token value is used when pushing data from the MedView application server to the patient's iPhone.
A great feature of the iRPM application is the ability for patients to create audio memos for the care provider. Audio memos provide an effective means of communication between a patient and their care providers. There are no restrictions as to the size or length of an audio memo except for the physical data limits of the patient’s iPhone. Patients may create as many memos as needed for the session.
The MedRPM System 10
Agent Health, Inc. 4/24/2010
Care providers define medical rules that run on the iPhone. These rules attempt to analyze patient monitoring data as it arrives to the iPhone. An example threshold rule would be "if the pH value is below 2.0 then alert the patient to change their current behavior". Patient experiences from previous sessions are incorporated into new medical rules thus creating sophisticated RPM solutions. Rules may create alerts to the patient which either informs or instructs the patient. The Alert feature may be turned off using the iPhone Settings application. A value appears on the iRPM dashboard indicating the number of alerts that have occurred while the session was active. An Alert detail page will provide further details to the patient. An example instruction would be for the patient to create a new diary event. Doing so will allow the physician to understand why the alert occurred. Some alerts will also automatically notify the physician using email or instant messaging.
Physicians can send digital notes to patients using the Apple Push Notification system. This is much like instant messaging but the notes are delivered directly to the iRPM application and do not use the user's SMS facility. The Physician Notes feature may be turned off using the iPhone Settings application. A value appears on the patient dashboard indicating the number of notes that have occurred while the session was active. A Physician Note detail page will provide further instructions to the patient if required. An example instruction would be to ask a patient to immediately contact their physician.
The capturing of patient monitoring data from medical devices is an important aspect of RPM. But just as important is the numerous events that occur during a session. Example patient events include coughing spells, heartburn occurrences, and wheezing. iRPM supports a patient diary where patients can add events during a session. Analysis software can later correlate the patient’s data to events. The iRPM application attempts to add diary events automatically when they can be deduced through the iPhone sensors or the MedRPM docking shell sensors. An event consists of an event type and duration. MedRPM defines a number of event types such as "Cough", Heartburn", and "Meal". iRPM allows physicians to define any number of additional event types per session. Or they may choose to remove any number of the pre-defined event types for a particular session. Those enhanced event types will show up on the Diary detail page. The event types are managed using an Event Type Detail screen.
MedRPM will continually add features to the iRPM application to advance the way patients interact with the application. This is related to a branch of research known as "Human Computer Interaction" or HCI. This is the study of how humans interact with a computer (or application in this situation). The iPhone provides a number of novel features which allows different ways for people to interact with applications. For example, the ability of the iPhone to vibrate, to create audio sounds, the accelerometer, push notification, and the proximity sensor. MedRPM has added a number of features to support advance HCI including the Alert facility and the Physician Note facility. All HCI related features can be enabled or disabled using the iPhone Settings applications.
Patients are expected to predominately use the audio memos features on pHWear as a way to communicate information to the physician during a session. Manually creating an audio memo can be difficult at times when the patient is focusing on another task or when it is dark and difficult to focus on the iPhone. The Auto Memo feature solves these problems by allowing the patient to record a memo merely by tapping twice anywhere on the patient dashboard screen of the iRPM application. When the screen is double
The MedRPM System 11
Agent Health, Inc. 4/24/2010
tapped, the Audio Memo screen appears and the patient is asked to record their memo. The recording will last for 10 seconds at which time iRPM will automatically stop the recording and return to the patient dashboard screen. This requires no additional work on behalf of the patient except for the initial double tap.
Additional HCI features will be added as experience is gained with the iRPM application.
The iRPM application provides a screen to manually input many types of patient monitoring data including temperature, heart rate, blood pressure, and weight. The care provider can add or remove “data types” from the iPhone to fit the RPM solution. This can be done in real-time.
The MedView Application Server
The MedView application server is the main interaction point for care providers. Care providers use MedView to manage and support their patients. MedView has two major tasks:
Main collection point for patient monitoring data.
Patient monitoring data analysis.
To enable communication from the patient’s iPhone to MedView, a patient’s iPhone is configured to indicate the location (Web URL) of the corresponding MedView application server. That server becomes the collection point for the monitored patient. When requested, the iRPM application will send patient monitoring data to the MedView server. To enable communication from MedView to the patient’s iPhone, MedView stores the device token for the patient’s iPhone. MedView uses the Apple Push Notification Service (APNS) to communicate with patient iPhones. Payloads for APNS are intended to be small. MedView messages are limited to alerts, physician memos, and “data available” alerts. “Data Available” alerts tell the patient’s iPhone that data is available on the MedView application server and that it should begin uploading the data. This relieves the iRPM application from having to poll the MedView application server periodically for data availability.
MedView is also used by patients although the main interaction point for patients is the iRPM application. Patient features in MedView include education, socializing with other patients through the patient blog, and communicating with their care provider.
MedView is a web-based application which can be installed on a hosted server (cloud), a local server, or even a laptop computer. MedView is accessed using standard web browsers. Figure 6: MedView Application Server shows a few of the many features supported by MedView.
The MedRPM System 12
Agent Health, Inc. 4/24/2010
Figure 6: MedView Application Server
MedView receives patient monitoring data from the iRPM iPhone application and stores the data for analysis. MedView can request data from a specific iRPM application which instructs the application to start the download process. If the patient’s iPhone is on the same network as the MedView application servicer, MedView can download the data directly without having to instruct the application.
MedView contains a robust rule engine and rule database defined by experts in the medical field. These rules can be applied to patient monitoring data to determine any issues that require attention.
Chronic care patients typically have more than one care provider. These providers need to share information. The MedView application server can send filtered patient monitoring data to any location using a number of network protocols including web services, SOAP, HTTP, FTP, and email. In addition, MedView can convert patient monitoring data to any number of data formats including XML, Microsoft Excel spreadsheets, and HL7.
MedView contains an event-correlation engine. This implies that with proper setup, the engine can take patient events and derive the possible reasons why the events occurred. Care providers can take the information and complete the diagnosis with minimal effort. The event correlation engine is intended to help alleviate the demands of RPM on care providers. This will speed the adoption of RPM in the medical community.
After an analysis of patient monitoring data, the care provider must derive patient regimens. The regimens are in the form of medical workflows that have been predefined by the medical community and the care provider. MedView provides a graphical medical workflow designer. The medical workflows may cause new information to be sent to the patient’s iPhone such as new analysis rules, patient educational information, and new timer values for scheduling medications.
The MedRPM System 13
Agent Health, Inc. 4/24/2010
Conclusion
MedRPM is one of the first open source RPM frameworks that we have seen in the medical industry. The MedRPM novel approach to constructing RPM solutions will hopefully speed the adoption of RPM solutions. Creating MedRPM as an open source solution will allow medical software developers around the U.S. to contribute to the success of MedRPM. This should accelerate the quality and capabilities of MedRPM much faster than would be the case if MedRPM was a vendor proprietary solution. The experiences in evolving MedRPM will contribute greatly to other sensor-based solutions in the medical industry such as hospital sensor networks.
