Note: Descriptions are shown in the official language in which they were submitted.
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
SYSTEMS AND METHODS FOR CREATING AND MANAGING TRUSTED HEALTH-
USER COMMUNITIES
BACKGROUND
[0001] Today, the field of healthcare is governed by a set of stringent
laws and regulations. One such law is the Health Insurance Portability and
Accountability Act (HIPAA). HIPAA was enacted by the U.S. Congress in 1996.
Title II of HIPAA requires a set of national standards for the maintenance of
certain healthcare related electronic transactions. As a result, the
Department
of Health and Human Services (HHS) has promulgated a set of "Rules" to
implement the requirements of Title II. These five Rules are: the Privacy
Rule,
the Transaction and Code Sets Rules, the Security Rules, the Unique
Identifiers
Rule and the Enforcement Rule.
[0002] The Privacy Rule provides for the use and maintenance of
Protected Health Information (PHI). PHI is generally any information that
pertains to the health and care of individual patients that may be held by
"covered entities". Such covered entities may include a variety of Health Care
Providers ("HCPs") ¨ e.g. hospitals, insurance companies, pharmacies, doctors,
doctor groups and the like.
[0003] As the Privacy Rules provide for the security and privacy of such
PHI, HCPs (such as hospitals) have adopted and/or promulgated very stringent
rules for their doctors, staff and administrators that govern the manner in
which such providers interact with patients or anyone who might have a legally
vested interest in such patients.
[0004] Therefore, HCPs have adequate incentive to provide
authenticated, secure, HIPAA-compliant means of communication that enforce
stringent HCP policies regarding communications between patients and HCPs
and the maintenance of a complete set of electronic health records ("EHRs")
and/or electronic medical repositories ("EMRs") that might result from such
communications.
SUMMARY
1
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[0005] Several embodiments of the present invention comprise systems
and methods of uploading image files of sensitive documents are disclosed to
at least one trusted community of users. The trusted community may be an
automated care pod used by medical providers to treat a patient. The image
files may comprise the individual's patient records. A request for uploading
may be made to the care pod and the care pod may generate a unique
identifying symbol which is sent back to the sender. The care pod or managing
system may receive the image file with the unique identifying symbol
embedded or associated with the image file.
[0006] In another embodiment, an automated extractor/verifier may
process the uploaded image data and extract user information. Said extracted
user information may then be compared against patient information
associated with the care pod. If extracted information and patient information
do not match, an error flag may be sent.
[0007] Other features and advantages of the present system are
presented below in the Detailed Description when read in connection with the
drawings presented within this application.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] Figure 1 shows a high level block diagram of a possible set of
trusted users and possible modules for a system built in accordance with the
principles of the present invention, and more particularly for medical
applications built upon the system.
[0009] Figure 2 depicts the concept of a social pod as made in accordance
with several of the present embodiments.
[00010] Figure 3 shows a flow chart of one embodiment of creating and
authenticating a social pod within the context of a medical application.
[00011] Figure 4 is a high level block diagram of a system architecture
built
according to the principles of the present application.
2
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[00012] Figure 5 shows a flow chart of one embodiment of a multimedia
content engine as made in accordance with several of the present system
embodiments.
[00013] Figure 6 is one embodiment of a present system as built and
hosted using existing network infrastructure.
[00014] Figures 7A and 78 show one embodiment of a present system as
built for the treatment of PTSD for returning military veterans.
[00015] Figures 8A and 88 show one embodiment of a de-identifier
module to de-link information within communications of the social pod that
contains certain data that might identify patients receiving treatment.
[00016] Figure 9 depicts one embodiment of a screen shot showing the
functionality of a treatment plan set up for a patient by a physician.
[00017] Figure 10 shows one embodiment of a program funding module
that enables administrators of a social pod to raise funds for programs via
the
present system.
[00018] Figure 11 depicts a typical transaction that might occur between
two physicians whereby one physician refers a patient to a second physician
and faxes the patient's medical records to the second physician.
[00019] Figure 12 is one embodiment of a system and/or method of
automatically and securely upload medical records or other sensitive
documents to a CarePod.
[00020] Figure 13 is one embodiment of a system and/or method of
automatically extracting and/or verifying patient data from image files and
securely associate such data and/or metadata with the patient's CarePod and
associated records.
[00021] Figure 14 depicts conventional methods where patient medical
and/or physiological data is send from a medical device to the patient's
caregivers.
3
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[00022] Figure 15 is one embodiment of a system and/or method of
enabling secure and authenticated communications of patient medical data
from a device to the patient's CarePod.
[00023] Figure 16 is one embodiment of a system and/or method to
prevent the accidental misdirection of patient medical data from a device to
the patient's CarePod.
[00024] Figure 17 is one embodiment of a system and/or method of
providing secure and authenticated therapeutic treatment to a patient under
guidance from doctors and other caregivers from the patient's CarePod.
[00025] Figure 18 depicts one embodiment of a module for the creation of
a template to capture data from a medical instrument that may be used in the
monitoring of treatment.
[00026] Figure 19 is one embodiment of a system and/or method for
creating a treatment plan for a patient having a condition.
[00027] Figure 20 is one embodiment of a system and/or method of
setting reminders to patients and caregivers during the course of a treatment.
[00028] Figure 21 is one embodiment of a system and/or module for the
capturing of data of a medical instrument monitoring the efficacy of a
treatment of a condition.
DETAILED DESCRIPTION
Introduction
[00029] As hospitals and other HCPs promulgated internal regulations in
response to the requirements of laws and regulations of HIPAA, one
embodiment of the present invention helps HCPs comply with their internal
regulations by providing for a networked system and method of managing the
communications among a number of "trusted" users ¨ e.g. by and between a
physician and a patient.
4
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[00030] In one embodiment, the present system comprises a versatile
cloud computing software platform where doctors and researchers may use
contemporary social networking tools to communicate with patients and the
extended care team online, on tablets and via mobile phones, sharing personal
health information and medical records within a HIPAA privacy and security
compliant environment. The present system may be constructed as a rule-
based computing system that insures that all trusted users and their
interactions are compliant to federal, state and their own non-governmental
(e.g. university, corporate or the like) privacy and security requirements.
The
present system should also be flexible to allow users (i.e. HCPs, issue groups
or
the like) to create specific on-line communities to address particular
conditions, diseases or other health-related conditions or issues.
[00031] In another aspect of the flexibility, one embodiment of the
present system should be to have the system available to users online, on
tablets, and on mobile phones. This may be desirable in order to 'cross the
digital divide' that separates low-income user/patients who do not have high-
speed Internet access from health care and support services from which they
may otherwise be excluded.
[00032] In one aspect, it is desirable to construct the present system in a
versatile manner. For example, the present system may be used to construct
and support many different types of specific-purpose online communities. The
present system may incorporate one or many different types of social
networking tools, including audio and video blogging and video chats, and
other known types of synchronous and asynchronous communications. As
literally hundreds of millions of Facebook, LinkedIn and Twitter users already
know how to use social networking technology, the present system
incorporates a suite of easy-to-use social networking functions, including
audio
and video blogging, text messaging and video chats, within a HIPAA-compliant
online platform. This, in turn, greatly expanding the ability to connect
clinical
services to patients (and research studies to research subjects) in novel
ways,
remotely, cost-effectively, synchronously and asynchronously.
[00033] In addition, it is desirable that the present system incorporate
content files into such communications ¨ e.g. audio, video, medical
application
and any other commonly used documents or applications. The present system
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
handles content files of any size, and content files that are created in
virtually
any underlying application, including the commonly used document, audio,
video and specialized medical applications. It may be desirable for the
present
system to accurately preserve the fidelity of such files and records. The
ability
to use and share information and medical records within specific purpose
communities creates the opportunity to develop new and efficient ways of
using it.
[00034] In addition to the features listed above, it may also be desirable
that the present system include other contemporary technologies to improve
the user experience. For example, the use of avatars and other gaming
technologies may increase the appeal of programs for some users, while other
technologies may improve the user experience for veterans who are blind or
hearing impaired.
Trusted Communities and/or Social Pods
[00035] In one possible aspect, the present embodiment may require that
the physician communicate with a patient who is authenticated at the time of
communication to the patient. In addition, the system stores and/or otherwise
archives the interaction between the physician and the patient to form a part
of the latter's EHR.
[00036] In another possible aspect, the present system may define a set of
"trusted" users of the network. Such trusted users may need to be
authenticated to establish their level of engagement and interaction with the
system. Such authentication may be accomplished by any known method,
manner or system for such authentication. Examples include password
protection, challenge-response interactions, biometrics or the like.
[00037] Figure 1 describes a set of entities that might comprise a
prototypical environment of trusted users. Users (collectively labeled 102)
are
shown interconnectedly with the present system 100 and, possibly, connected
amongst themselves apart from system 100. A set of users might comprise the
following types of individuals: physicians 102a, practice staff and nurses
102b,
6
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
researchers 102c, consulting physicians 102d, payor and donors 102e, patient's
friends and family members 102f, patients 102g and students 102h.
[00038] Each of the users 102 represent entities that may have known
communication and computing devices (not shown) in order to affect a
networked environment. For example, users 102 may variously have smart
phones, cell phones, computers, tablets and the like that may be configured to
run a secure, encrypted software environment, as might be presented in a
browser or in any other known interfaces. It will be appreciated that the
present system encompasses the use of all known devices and means of
networked communication that would facilitate the present system as
described herein.
[00039] The present system may also allow for easy dynamic management
of the social pod. For example, the present system may allow for the addition
and/or deletion of members in a seamless manner. To appreciate the
flexibility of communities that the present system could enable, trusted
communities might comprise one, two, or any number of members depending
on their specific purpose. For mere exemplary purposes, communities may
consist of:
- a single member using a self-directed therapeutic intervention
- doctor + doctor
- doctor to pharmacy
- doctor to health insurance agent, e.g., for utilization review
- doctor + patient
- doctor + patient + family
- doctor + entire care team
- patient + entire care team
- doctor + multiple patients or multiple families
- research team
- research team + participants
7
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
- wellness program enrollees
- medical-educational program enrollees
[00040] The identity of every participant in a community may be
authenticated using one or more conventional identity authentication methods
each time the member signs on to the community or accesses a content file.
The present system may incorporate a variety of conventional authentication
methods; the specific method(s) used to authenticate the members of a given
community may vary as appropriate to its specific purpose.
[00041] Communities may be moderated, or self-directed. One or more
moderators may oversee some types of programs, being able, for example, to
add new members, remove objectionable content, and update content files.
Other types of programs may be completely unsupervised and self-directed.
[00042] Because the present system may ensure HIPAA privacy and
security compliance, communications and medical records that contain
personal health information may be shared among members of the
community, synchronously and asynchronously, online and on tablets and
mobile phones.
[00043] In addition to setting up and populating trusted communities, the
present system may use a number of technical strategies to pre-set and
enforce access rights to ensure the privacy of communications, and
appropriately limit access to certain files. Easy-to-use and redundant methods
assure that the moderator(s) exercise complete and dynamic control over
which communications and medical records, or parts thereof, are available to
everyone, and which are available only to a certain subset of the community.
[00044] System 100 may comprise a set of networked computers and/or
processors ¨ in communications possibly with computers, processors or mobile
devices that are in the possession or under the control of the users 102.
There
are many desirable and optional features that system 100 provides to users
102 and to the various HCP that are connected to the users.
[00045] For example, system 100 may provide the following:
8
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
(1) establish networked infrastructure for programs for health,
education, prevention, wellness, treatment and/or research (104);
(2) enable automated and/or distributed funding of programs from
donors, granting organizations, payors and private payors (106);
(3) establish micro social networks of trusted relationships around the
program;
(4) run programs through engagement and interactions over networks
(e.g. intranets, the internet or the like) and mobile devices; and
(5) analyze de-identified data that flows through system 100 and
optimize programs that are made in accordance with the present system
(112) .
[00046] One embodiment of analysis and optimization of the present
system provides that the interactions of involving users and the present
system
provides a feedback mechanism to sharpen and improve the effectiveness of
the system for treating or servicing its users. For example, one embodiment of
the present system might be a Clinical Care and Education program that allows
providers several means to capture the data about the effectiveness of their
programs. The "social" interactions inherent in the solution may be captured
by the system, for example as unstructured data. The built Query ¨ Response
service allows the system to get explicit feedback in a secure fashion. In
addition, the Therapeutics module might allow the system to capture
responses from their patients and participants e.g. level of pain, mood, etc.,
along with compliance data such as "Did you take all three dosages of the
medicine, on time" etc. This data set allows the system and its designers
(which could be the clinicians and researchers of the program itself) to look
for
correlation among a particular protocol and its effectiveness and make
changes to their programs, be it therapeutics or course material, style of
presentation, etc.
[00047] System 100 may be employed to create a networked
"microcommunity" of users -- a construct called a "social pod". Figure 2
depicts a social pod 200. Social pod 200 is enabled or otherwise hosted by
9
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
system 100 as a set of interconnected computers, processors, mobile devices
or the like. Desirable features of social pod 200 may include: a set of
trusted
connections brokered through the system; a polycommunication service (e.g.
email, SMS, voicemail or the like); short question and response service; and a
viewport and/or an application (called an "anicaport" for purposes of this
application, as described below). This anicaport may act, at a high level, as
a
viewport for downloading, uploading, and/or streaming of content. Such
content may be placed into appropriate formatting and made available to all or
a subset of trusted users, possibly in some universal format. In one
embodiment, a social pod may provide a restricted and secure way for a micro
community of people organized around a specific outcome (e.g. clinical
research, treatment of a medical condition, education for wellness etc.) to
interact, collaborate, capture structured data, etc.
[00048] Figure 3 depicts one embodiment of a method of creating a social
pod. In this embodiment, the system may allow for a multi-part authentication
procedure and mechanism. It will be appreciated, however, other mechanisms
¨ with varying levels of authentication ¨ may be set up and managed. It will
be
appreciated that the following description is merely by way of example and
that other mechanisms and methods may be employed to created trusted
communities and/or social pods.
[00049] Social pod 308 may be created by a provider, a physician or
researcher 304 via the present system. Provider 304 alerts the system that a
new "Care" pod is to be created and provider 304 may populate the pod by
listing individuals (e.g. patient 306) and have the system invite patient 306
via
some identified means of communication (e.g. by providing the patient's email
address to the system) at 310. The system may manage social pod 308 as a set
of data structures and/or routines to affect its creation and dynamic
management. At 312, the system (via social pod 308 or the like) creates the
new "Care" pod and adds patient 306 as a pod member, pending
authentication. Pod 308 may then request the system to create patient as a
User ¨ in this example, via a request to the system's authentication module
302.
[00050] Authentication module 302 may perform such actions as shown at
314. To wit, module 302 may generate a security token and associate the
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
token with the user's email address or any other identifier. Module 302 may
return an invitation to the identified email address of the putative new user
/patient 306. Patient 306 may then (at 316) access her email and confirm the
address, setup a user password and enter other means of communication for
the system (such as mobile phone number or the like). This other means of
communication may be used to receive a second part authentication for the
user. Once initial confirmation is received from patient 306, module 302 may
confirm the token against the previously generated token (at 314) and send a
text message to the mobile phone (or call the phone directly) with a second
part token. Patient 306 may enter the second part token and return to
module 302 for further authentication. If module 302 confirms the second
part token, module 302 may signal to pod 308 that there is a trusted
individual/user at 318.
[00051] Additional authentication means may optionally be set up, as
desired. For example patient 306 may set up a voice recognition match for
further authentication at 320, back to module 302. As time goes forward,
patient 308 is then considered a trusted user and may access the pod with
suitable credentials at 322.
[00052] In one embodiment, the present system may provide flexibility in
setting up trusted relationships. For this, it may be desirable to establish
that
the forms of identifications provided by the user are indeed accessible by the
user. For this, the present system may establish such multi-part
authentication
mechanism as desired. In addition, the administrators or providers of the
system can choose the levels of authentication required for trusted users,
with
a basic minimum possibly designed.
System Architecture
[00053] Having described one aspect of the present system ¨ i.e. the
notion of trusted users and the social pod, one or more suitable architecture
embodiments for the construction of the present system will now be
described. In addition, it will be shown how one embodiment of the present
system may leverage existing internet and other infrastructures for efficient
build-out of the present system.
11
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[00054] Figure 4 depicts one embodiment of an architecture of a system
that may perform in accordance with the teachings of the present invention.
System 400 may advantageously comprise multiple modules for the creation
and dynamic operation of the present system. Such modules may comprise
the following: communication engine 402, multimedia content engine 404,
external ecosystem integration module 406, therapeutic and research
management engine 408, social networking engine 410 and analytic engine
412. Each module/engine will be discussed in turn below.
[00055] Communication engine 402 is the part of system 400 that
comprises sufficient hardware and logic to setup and dynamically manage the
flow of communications between trusted users of the present system.
Communication engine 402 may manage communications from disparate
means and modes of communications ¨ e.g. text messages, chat, email, voice,
video chat and the like.
[00056] Multimedia content engine 404 is that part of the system 400 that
comprises sufficient hardware and logic to create, store, disseminate and
dynamically manage the flow of data in and out of system 400 by and to
trusted users of the system. Submodules of engine 404 might advantageously
comprise: injest submodule, transcoding submodule, presentation submodule,
storage, and delivery submodules.
[00057] External ecosystem integration engine 406 may present a set of
RESTful API, that allows it to exchange its data with third party systems and
using (when applicable) industry standards such as HL7 etc. These API's will
allow external systems to send information to the present system, e.g. a
medical device or EHR system.
[00058] Therapeutics and Research Management Engine 408 is that part of
the system 400 that comprises sufficient hardware and logic to create, store,
disseminate, and dynamically manage treatment plans and pathways for
trusted users on the system. It may be desirable for each trusted user of the
system that is actively being treated via system 400 to be tracked by engine
408 and their progress logged and processed. Submodules of engine 408 may
advantageously comprise: querio dynamic data capture submodule,
12
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
therapeutic library, patient education library, and reminders and compliance
tracking submodule.
[00059] Social networking engine 410 is that part of system 400 that
comprises sufficient hardware and logic to dynamically manage the various
communications and relationships between trusted users of system 400. It
should be appreciated that any known combination of processors, data
structures, storage and communication media ¨ including transport of data
across networks, intranets, the internet ¨ may be utilized to affect the
implementation of the present system, as is known to one skilled in the art.
[00060] One aspect of the present system is the ability to transcode,
store,
deliver and present content of a variety of media types. This would be
desirable in any number of applications and context ¨ and one such application
is in the field of healthcare where patients may thrive better in a treatment
program where use of multiple means of communications and messaging (both
synchronous and/or asynchronous) may be applied. For example, a patient
may not feel like talking directly to a doctor, or writing a lengthy email
about
conditions and results; but the patient might be amenable to uploading an
audio or video file describing such. So, users and applications can use a
multimedia content server/network -- such as "anicaport" to affect solutions.
[00061] It may also be desirable to create an anicaport in such a way as to
build solutions that may have shared content; but it is not desired to
transmit
the files multiple times. With Anicaport, content files of practically any
size can
be shared. The content files that are authored in native formats may be
uploaded and shared, anicaport may transcodes them to ensure that files will
display in Web browser or Mobile device without the need for additional
software. In addition, content files may be streamed and transmitted over
secure, encrypted protocols and designed to be accessible from anywhere on
the globe.
[00062] Figure 5 show one flow chart of the multimedia content engine
("anicaport") in dynamic operation. Anicaport 502, in this embodiment,
comprises injest API 506, transcoding engine 508, presentation API 510,
storage 512, and content delivery network 514. Some application (under user
control or otherwise) 504 may make an injest request at 516 ¨ e.g. a live
13
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
recording or upload or the like. Injest API 506 may, at 518, store any
metadata
(if any) in storage or database and send the file associated with the request
to
storage 520.
[00063] This file or data may be queued for further processing at 522
and/or 524, if needed. If the file or data is a form of a document (e.g.
office,
pdf, etc.), then transcoding engine 508 may process and generate one or more
versions, perhaps in different formats, such as image format (e.g. SVG & PNG).
Any metadata associated with the transcoding, if any, may be updated in a
database or storage. If the file or the data is either an audio or video file,
then
transcoding engine 508 may process it to a different format ¨ e.g. H.264. Any
metadata generated there may also be stored as noted.
[00064] At 526, transcoding engine 508 may then send the processed
data/file to storage (perhaps over SSL) at 528. In addition, the data/file may
be
distributed to content delivery network at 530. If there is any update that is
needed to earlier saved metadata, it may be accomplished at 532.
[00065] Over time, the same or different application 504 may make a
request for a presentation of stored content (to which the user or owner of
the
application has rights to) at 534. Such request may be made to a presentation
API 510, which then may select a presentation player at 536 and initiated
streaming content at 538 from content delivery network at 538. Presentation
API may then oversee such streaming data to application at 534. All of this
may be accomplished with the anicaport or other parts of the system checking
and enforcing authorizations and permissions ¨ matching users/applications to
content.
[00066] One embodiment of code that implements an anicaport is shown
immediately below. It will be appreciated that many different
implementations are possible and are contemplated within the scope of the
present invention.
anicaport / app / controllers
accounts_controller.rb
14
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
application_controller.rb
documents_controller.rb
anicaport / app / models
account.rb
document.rb
user.rb
Source Code
app/models/account.rb
include ApplicationHelper
class Account < ActiveRecord::Base
has_many :documents, :dependent => :destroy
validates :account_name, :presence => true
after_create :create_aws_objects
def create_aws_objects
AWS::S3::Base.establish_connectionq
:access_key_id => aws_access_key_id,
:secret_access_key => aws_secret_access_key
)
AWS::S3::Bucket.create("ilfself.account_namel")
AWS::S3::S3Object.storercrossdomain.xml",
open("#{Rails.root.join("lib/crossdomain.xml")}"), self.account_name,
:access => :public_read)
AmazeSNS.akey = aws_access_key_id
AmazeSNS.skey = aws_secret_access_key
AmazeSNS["#{self.account_name}"].create
AmazeSNS["#{self.account_name}"].subscribeftendpoint=>"#{anicaport
_protocol}://44{anicaport_host_name}/accounts/processfiles", :protocol
=> "Illanicaport_protocoll"})
end
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
end
app/models/document.rb
include ApplicationHelper
class Document < ActiveRecord::Base
belongs_to :account
validates :account, :presence => true
validates :document_name, :presence => true
after_create :processandsend
def reprocess
self.processed = false
self .save
doc_dir = self.document_dir
file_basename = self.document_name.splitC.Ifirst
file_extension = self.document_name.split(1.1).1ast
AWS::S3::Base.establish_connectionq
:access_key_id => aws_access_key_id,
:secret_access_key => aws_secret_access_key
)
if AWS::S3::S3Object.exists?
"#{doc_dir}/#1file_basenameWoriginal/#1file_basenamel.#{file_extensio
n}", "#{self.account.account_name}"
AWS::S3::S3Object.copy
"#{doc_dir}/#1file_basenameWoriginal/#1file_basenamel.#{file_extensio
n}", "#{self.document_name}", "#{self.account.account_name}"
end
processandsend
end
def processandsend
#connect to s3
AWS::S3::Base.establish_connectionq
:access_key_id => aws_access_key_id,
16
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
:secret_access_key => aws_secret_access_key
)
if AWS::S3::S3Object.exists? "#{self.document_name}",
"#{self.account.account_name}"
begin
#start proessing file
doc_dir = self.document_dir
file_basename = self.document_name.splitC.Ifirst
file_extension = self.document_name.split(1.1).last
account_dir =
Rails.root.join("public/system/#1self.account.account_namen.to_s
processing_dir = "#faccount_dirl#Ifile_basenamelr
original_file_path =
"#{processing_dir}originalMself.document_namel"
command "mkdir #faccount_dirl" if File.exists?(account_dir) ==
false
command "mkdir #fprocessing_dirl" if File.exists?(processing_dir)
== false
command "mkdir #fprocessing_dirloriginar if
File.exists?("#{processing_dir}originalr) == false
command "mkdir #fprocessing_dirlprocessedf if
File.exists?("#{processing_dir}processed/") == false
command "mkdir #fprocessing_dirlthumbnair if
File.exists?("#{processing_dir}thumbnair) == false
command "mkdir #fprocessing_dirltmpf if
File.exists?("#{processing_dir}tmpr) == false
#download file
open(original_file_path, "w") do I file I
AWS::S3::S3Object.stream("#{self.document_name}",
"#{self.account.account_name}") do I chunk I
file.write chunk
end
end
17
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
#if video
if is_video?(file_extension)
command "ffmpeg -i #foriginal_file_pathl -acodec libfaac -ab 96k -
vcodec 1ibx264 -vpre slow -crf 22 -threads 0
#{processing_dir}processed/#1file_basenamel.flv"
command "ffmpeg -i #foriginal_file_pathl -vcodec png -vframes 1
-an -f rawvideo -s 320x240 #{processing_dir}tmp/#1file_basenamel.png"
make_thumbnail "#{processing_dir}tmp/#1file_basenamel.png",
"#{processing_dir}thumbnail/#1file_basenamel.png", 1
File.open("#{processing_dir}processed/pagecount.txt", "w") do
If I
f.write("1")
end
toamazon("#{doc_dir}/#1file_basenamel/processed/pagecount.txt",
"#{processing_dir}processed/pagecount.txt")
toamazon("#{doc_dir}/#1file_basenamel/processed/#1file_basenamel.flv
", "#{processing_dir}processed/#{file_basename}.flv")
toamazon("#{doc_dir}/#1file_basenamelithumbnail/#1file_basenamel.p
ng", "#{processing_dir}thumbnail/#1file_basenamel.png")
#if image
elsif is_image?(file_extension)
command "convert #foriginal_file_pathl
#{processing_dir}processed/#1file_basenamel.png"
make_thumbnail
"#{processing_dir}processed/#1file_basenamel.png",
"#{processing_dir}thumbnail/#1file_basenamel.png", 1
File.open("#{processing_dir}processed/pagecount.txt", "w") do
If I
f.write("1")
18
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
end
toamazon("#{doc_dir}/#1file_basenamel/processed/pagecount.txt",
"#{processing_dir}processed/pagecount.txt")
toamazon("#{doc_dir}/#1file_basenamel/processed/#1file_basenamel.p
ng", "#{processing_dir}processed/#{file_basename}.png")
toamazon("#{doc_dir}/44{file_basename}/thumbnail/#1file_basenamel.p
ng", "#{processing_dir}thumbnail/#1file_basenamel.png")
#if office
elsif is_office?(file_extension)
ConvertOffice::ConvertOfficeFormat.new.convert(original_file_path,
"#{processing_dir}tmp/#{file_basename}.pdf")
command "pdf2svg #{processing_dir}tmp/#1file_basenamel.pdf
#{processing_dir}processed/%d.svg all"
@files = Dir.glob("#{processing_dir}processed/*.svg")
File.open("#{processing_dir}processed/pagecount.txt", "w") do
If I
f.write("#1@files.countl")
end
@files.count.times do Iii
command "convert -density 300x300 -resize 1130x989 -quality
90 #{processing_dir}tmp/#1file_basenamel.pdf[44{i}]
#{processing_dir}processed/page-#1i1.png"
end
make_thumbnail
"#{processing_dir}tmp/#1file_basenamel.pdf[0]",
"#{processing_dir}thumbnail/#1file_basenamel.png", @files.count
19
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
toamazon("#{doc_dir}/#1file_basenamel/processed/pagecount.txt",
"#{processing_dir}processed/pagecount.txt")
for file in Dir.glob("#{processing_dir}processed/*.svg")
toamazongzip("#{doc_dir}/#1file_basenamel/processed/#{file.split("/").1
ast}", "44{file}")
end
for file in Dir.glob("#{processing_dir}processed/*.png")
toamazon("#{doc_dir}/#1file_basenamel/processed/#1file.split("/").lastl"
, VINO")
end
toamazon("#{doc_dir}/#1file_basenamelithumbnail/#1file_basenamel.p
ng", "#{processing_dir}thumbnail/#1file_basenamel.png")
#if pdf
elsif file_extension == 'pdf'
command "pdf2svg #foriginal_file_pathl
#{processing_dir}processed/%d.svg all"
@files = Dir.glob("#{processing_dir}processed/*.svg")
File.open("#{processing_dir}processed/pagecount.txt", "w") do
I f I
f.write("#1@files.countl")
end
@files.count.times do Iii
command "convert -density 300x300 -resize 1130x989 -quality
90 #foriginal_file_pathMil] #{processing_dir}processed/page-#1i1.png"
end
make_thumbnail "#{original_file_path}[0]",
"#{processing_dir}thumbnail/#1file_basenamel.png", @files.count
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
toamazon("#{doc_dir}/#1file_basenamel/processed/pagecount.txt",
"#{processing_dir}processed/pagecount.txt")
for file in Dir.glob("#{processing_dir}processed/*.svg")
toamazongzip("#{doc_dir}/#{file_basenamel/processed/#{file.split("/").1
ast}", "44{file}")
end
for file in Dir.glob("#{processing_dir}processed/*.png")
toamazon("#{doc_dir}/#1file_basenamel/processed/#{file.split("/").last}"
, VINO")
end
toamazon("#{doc_dir}/#1file_basenamel/thumbnail/#1file_basenamel.p
ng", "#{processing_dir}thumbnail/#1file_basenamel.png")
end
AWS::S3::S3Object.rename "#{self.document_name}",
"#{doc_dir}/44{file_basename}/original/#1file_basenamel.#{file_extensio
n}", "#{self.account.account_name}"
AmazeSNS.a key = aws_access_key_id
AmazeSNS.skey = aws_secret_access_key
@topic = AmazeSNS[V{self.account.account_name}"]
@topic.create
@topic.publish(V{self.document_name}", "File Processed at
#{self.account.account_name}/#{doc_dirl.")
self.processed = true
self. save
rescue Exception => e
AmazeSNS.a key = aws_access_key_id
AmazeSNS.skey = aws_secret_access_key
21
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
@topic = AmazeSNS[V{self.account.account_name}l
@topic.create
@topic.publish("#{e.message} => #fself.document_namel", "File
Processing Failed at #fself.account.account_namel/#1doc_dirl.")
self.processed = false
self. save
end
command "rm -rf #fprocessing_dirl" if self.processed
end
end
handle_asynchronously :processandsend
def deletefile(uuid, count)
begin
bucket_name = self.account.account_name
doc_dir = self.document_dir
#delete thumbnail
delete_from_s3 "#{doc_dir}/#1uuidlthumbnailMuuidl.png",
bucket_name
delete_from_s3 "#{doc_dir}/#1uuidlthumbnail", bucket_name
#delete processed
count.to_Ltimes do Iii
page_no = i + 1
delete_from_s3 "#{doc_dir}/#1uuidl/processed/page-
#1page_nol.png", bucket_name
delete_from_s3 "#{doc_dir}/#1uuidl/processed/#1page_nol.svg",
bucket_name
end
delete_from_s3 "#{doc_dir}/#1uuidl/processed/#1uuidl.svg",
bucket_name
22
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
delete_from_s3 "#{doc_dir}ittfuuidl/processed/#1uuidl.png",
bucket_name
delete_from_s3 "#{doc_dir}ittfuuidl/processed/#1uuidl.flv",
bucket_name
delete_from_s3 "#{doc_dir}ittfuuidl/processed/pagecount.txt",
bucket_name
delete_from_s3 "#{doc_dir}ittfuuidl/processed", bucket_name
#delete orifinal
delete_from_s3
"#{doc_dir}ittfuuidloriginalMself.document_namel", bucket_name
delete_from_s3 "#{doc_dir}ittfuuidloriginal", bucket_name
delete_from_s3 "#{doc_dir}itt{uuid}", bucket_name
self .destroy
rescue Exception => e
AmazeSNS.a key = aws_access_key_id
AmazeSNS.skey = aws_secret_access_key
@topic = AmazeSNS["#{self.account.account_name}l
@topic.create
@topic.publish("#{e.message} => #fself.document_namel", "File
Deleting Failed at #fself.account.account_namel/#1doc_dirl.")
end
end
handle_asynchronously :deletefile
private
def make_thumbnail(source, destination, number_of_page)
if number_of_page>1
command "convert #{source} -thumbnail 80x80 -bordercolor white -
border 3 -bordercolor grey60 -border 1 -bordercolor none -background
none \\( -clone 0 -rotate 'convert null: -format'%[fx:randO*30-15] info:
\\) \\( -clone 0 -rotate 'convert null: -format 1%[fx:rand()*30-15] info:
\\) \\( -clone 0 -rotate 'convert null: -format 1%[fx:rand()*30-15] info:
23
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
\\) \M -clone 0 -rotate 'convert null: -format'%[fx:randO*30-15] info:
\\) -delete 0 -border 100x80 -gravity center -crop 200x160+0+0 +repage
-flatten -trim +repage -background black \\( +clone -shadow 60x4+4+4
\\) +swap -background none -flatten 44{destination}"
else
command "convert #{source} -thumbnail 80x80 -bordercolor white -
border 3 -bordercolor grey60 -border 1 -bordercolor none -background
none -rotate -0 \\( +clone -shadow 60x4+4-F4 \\) +swap -flatten
44{destination}"
end
end
def toamazon(to,from)
AWS::S3::Base.establish_connection 1(
:access_key_id => aws_access_key_id,
:secret_access_key => aws_secret_access_key
)
AWS::S3::S3Object.store(to, open(from), self.account.account_name,
:access => :private)
end
def toamazongzip(to,from)
AWS::S3::Base.establish_connection 1(
:access_key_id => aws_access_key_id,
:secret_access_key => aws_secret_access_key
)
strio = String10.open(", 'w')
gz = Zlib::GzipWriter.new(strio)
gz.write(open(from).read)
gz.close
AWS::S3::S3Object.store(to, strio.string, self.account.account_name,
:access => :private, "Content-Encoding" => 'gzip' )
end
def delete_from_s3(file, bucket)
AWS::S3::Base.establish_connection 1(
:access_key_id => aws_access_key_id,
:secret_access_key => aws_secret_access_key
24
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
)
AWS::S3::S3Object.delete file, bucket if AWS::S3::S3Object.exists? file,
bucket
end
def is_image?(file_extension)
extensions = %w{jpg jpeg gif png tiff bmp}
extensionsinclude?(file_extension.downcase)
end
def is_office?(file_extension)
extensions = %w{odt sxw rtf doc txt html wiki docx ods sxc xis csv tsv
html xlsx swf odp sxi ppt html pptx}
extensionsinclude?(file_extension.downcase)
end
def is_video?(file_extension)
extensions = %w{fly m4v mov wmv mp4}
extensionsinclude?(file_extension.downcase)
end
def command (str)
logger.info str
system str
end
end
System Infrastructure
[00067] While the architecture of the present system presents one
embodiment for the various modules that may be desirable in such a system,
the present system itself may be hosted in a myriad of ways, to include
leveraging existing infrastructures and the different companies that may
provide services and hardware for such hosting and infrastructure.
[00068] Figure 6 depicts one embodiment of the present system (600) as it
may be hosted over existing infrastructure. Users of the present system may
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
connect by a myriad of communication pathways. For example, users may
connect via phone (602), mobile or otherwise, and by a browser 604 through
standard interfaces 606. Once connected to the present system 600, the
various modules of the present system may be a set of separately hosted
modules that are in communication with one another.
[00069] The embodiment depicted in Figure 6 has modules --
instrumentation and notification module 608, integrated text and/or voice
messaging 610, email service 612, application server and webserver 614,
database 616, media server 618, simple queuing service 620, content
transcoding engine 622, content storage 624 and content delivery network 626
¨ interconnected in a manner in which each module may be separately hosted,
or a set of such modules may be resident on a single site and/or processor.
[00070] In one embodiment, the present system may be built on top of
best of breed infrastructure available from existing companies¨e.g. database
hosting services and cloud computing services. It may be desirable that the
communication framework of the present system integrates with media
servers, SMS gateways and voice capabilities.
[00071] In operation, content transcoding engine 622 may convert content
files that are uploaded to content storage 624 in any format, e.g., Microsoft
Office documents, pdf files, and various image and video formats, preparing
them for direct preview and streaming delivery to computing devices, tablet or
smartphones (without any downloads). The present system may also
advantageously support the sharing of very large image and video content files
such as ultrasounds and MRIs. In addition, the present system may also
support parallel and separate communication threads among various subsets
of a community, ensuring selective and appropriate access to communications,
personal health information, and medical reports. The present system may
automatically deposit every communication and medical record into a EHR and
EMR repository. Notification engine 608 may support therapeutic reminders,
workflows and communications.
Example of Use and Operation
26
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[00072] Having described possible architectures and build-out of the
present system, it will now be described the uses and operation of an
exemplary system, built in accordance with the principles of the present
invention.
[00073] Figures 7A and 7B depict the flow of operation of one such
embodiment of the present system ¨ i.e. a social pod built and maintained for
the management of post-traumatic stress disorder in returning military
veterans. It will be appreciated that this embodiment is offered merely for
exposition of the present system and does not necessarily limit the scope of
invention as claimed below.
[00074] In this embodiment, various users may be in communication with
other users via and through the present system itself. For example, physicians
702, patient 704, consulting physician 706, other trusted users 708 may be in
communication with each other, or various modules of the present system,
such as polycommunication service 710, short question and response service
712 and anicaport 714.
[00075] In this example, patient 704 may post a private message (at 720,
via any known means, e.g. video, web, audio/SMS or the like) meant to be
viewed by physician 702. The message may be received by communications
service 710 (at 722) and relayed to physician 702 (at 724). Physician 702 may
view the post and respond, which is relayed via communication service.
[00076] In following-up, physician 702 may post a consultation request at
726 to communication service 710, from which a notification may be sent to
consulting physician 706 and a message sent to anicaport 714 at 732.
Consulting physician 706 may view the message and content at 730 and then
post results of the review back to physician 702 at 734. Anicaport 714 logs
all
such communications via encrypted content at 732.
[00077] In Figure 7B, physician 702 may invite a new patient 704 and a
new consulting physician 706 (at 742 and 746) to join the social pod (as
described above) and accept invitations at 744. In addition, physician 702 may
decide at 748 to upload certain educational or training materials relating to
PTSD to anicaport 750, which then may be viewed by patient 704 as, e.g.
streamable content.
27
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[00078] Physician 702 may decide to set up a therapeutic regiment for
patient 704 at 750. Short question and response service 712 may be employed
at 752 to provide reminders and capture any other relevant data (e.g. mood,
clinical results, etc.) from the patient at 754. If any alert is triggered by
the
crossing of a threshold (either clinically or via answers or non-compliance
noted by the present system), then an alert may be generated and sent to
physician at 752, 756 and 750. Lastly, physician 702 may review charts and
trends of patient 704 at 752.
De-Identification
[00079] One possible useful feature of a system made in accordance with
the principles of the present invention might be the unlinking of patient data
from the positive identification of the patient herself. As HIPAA requires
that
PHI be disseminated in a controlled fashion, Figures 8A and 88 depict one
embodiment of such a de-identification module.
[00080] As noted above, various users of the social pod may be
communicating with other users or the system via its interfaces. In this
example, physician 802 may be communicating with social pod/system 804.
De-identification module 806 may be implemented within the system on top
of, or in communication with, query module or communication module or the
like. In response, de-identification module 806 may strip out information or
data which may be linked to, and help identify, any given patient.
[00081] At 810, physician may post a message or a response to the social
pod. Such a message, as noted above, may be posted in various forms (e.g.
text, voice or video), and it may be desirable that de-identifier module 806
strip out any such identifying data. At 812, such information passed to the
social pod 804 may be captured by de-identifier 806. In the case of text at
814,
module 806 may parse and remove references to physician and/or patients
and create an object without such references, and subsequently be stored at
816.
[00082] In the case of voice at 818, module 806 may perform speech
recognition to capture information within the message. In addition, module
28
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
806 might use voice altering to de-identify the tonal qualities of the
individual
leaving the message. In the case of video at 822, module 806 may alter pixel
data within an image to obscure facial recognition. In addition, module 806
might alter sound and voice data as noted above.
[00083] Figure 89 depicts data and information as may be viewed by
either a physician who is authorized to know the identity of the data to whom
it is referring ¨ and to others who are not so similarly authorized. The data
which is stripped from the data by the present system is depicted in the third
column of Figure 89.
[00084] In one embodiment, the present system may be constructed to
capture de-identified data in real-time for research purposes. For example,
actual conversations between Physicians/Researchers and Patients (as well as
other structured captured data) are typically stored in an encrypted fashion
to
protect privacy. This however tends to render the data unusable for search
and analysis. In these cases, a social pod may be tagged to be "For research",
in which case, the system logs its data in a de-identified form, with the
pertinent information but the identifiable elements removed.
Therapeutics
[00085] The present system may also provide a more comprehensive and
high engagement support system for better compliance with a therapeutics
module. For example, physicians may easily setup a therapeutic action plan
and, for each of the components, associate a basket of supporting materials
from their online library or record instructions directly through the webcam.
The system, will, if setup, send reminders through one or multiple means such
as email, voice call or text messages and may require the patient to confirm.
[00086] Figure 9 shows an exemplary screen shot 900 of such a
therapeutics interface/module, as may be presented on a web browser or the
like. Tabs 902 may be constructed in a user-friendly fashion and, as described
above, a To Do tab 904 could be one possible interface to affect a more
comprehensive treatment plan for a patient. Possible interfaces might include
therapeutic item box 906, where text may be entered by users regarding
29
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
aspects of the treatment and a set of reminders for treatment may be set in
accordance with the treatment plan (e.g. take medications every day, or
describe symptoms once a week, take and record vital signs once a month or
the like).
[00087] In addition, accessible content may be made available through this
interface at 908. In this example, the patient has access to a document that
describes the medication that she is taking, or the patient may have access to
video/audio file 912 that she uploaded to inquire about treatment aspect. Her
physician may have responded with a video/audio file 914 in response. Such
robust treatment of multimedia content may be delivered as described above.
Donations and Payments
[00088] Another aspect of a present system might be a donation and/or
payment module that improves the flow of donations and/or payments for
programs implemented to address needs of a given social pod. For example,
Figure 10 shows one embodiment of a donation interaction that, in this case,
allows providers to raise funds for, e.g., a health outreach program. Donors,
in
turn, might pledge funds, review outcomes and pay the providers.
[00089] Provider 1002 might set up program and outline program cost and
funds needed to setup and maintain the program at 1010. Provider 1002
might market such program through any number of channels, e.g. via
Facebook or any other social media or outlet at 1012 ¨ or market directly to
donors. Donors 1004 may receive such marketing at 1014 and pledge some
amount at 1016 ¨ via the present system. In addition, donors may be made a
trusted user and a part of the trusted community, with certain rights and
access to materials on the present system. Donor 1004 may make payments at
1018 to payment module 1008 at 1020. To keep the donors informed and
engaged, program metrics 1006 may send such metrics ¨e.g. program
satisfaction scores ¨ to donors at 1024, in order for donors to see their
donation money at useful work.
Overview of Uploading Documents to a Pod
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[00090] The various embodiments of "Pods" (e.g., "CarePods", "SocialPod"
and the like ¨ the terms may be used interchangeably) described herein (and
as further depicted in Figures 1-10) create a unique place (e.g., in the
"cloud")
that unifies communication and tools needed to coordinate, manage and
provide care to a patient. The CarePod has the ability to provide controlled
access to various people involved in the care of a patient within and between
Doctor's offices to the various parts of a CarePod, such as the communication
tools, the charts and records etc. This capability may allow the parties
involved
to have a single and common place to go to find the information they need
about a patient, even if they are physically distant as well organizationally
separated -- i.e., they could be part of two different Healthcare providers in
two different parts of the world. The charts and records portion of the
CarePod, accommodates the storage of records that exists in an electronic
form. This provides the opportunity for healthcare providers to upload files
that are in electronic form into the CarePod. Several embodiments of the
present application herein provide users of CarePods with systems and
methods of sharing paper documents by and between these users.
Embodiments of Paper Records Upload and Sharing to CarePods
[00091] In reference to the discussion below regarding Pods and CarePods
(and as further discussed in reference to Figures 1-10), it will now be
described
various embodiments of the uploading and sharing of paper documents into
CarePods.
[00092] Figure 11 depicts a typical transaction 1100 by which paper files
are shared via facsimile between doctors' offices. Often, a doctor in office
1102 will refer a patient to another physician in a second office 1104. At
that
time, the patient's record (in paper format) 1106 is faxed 1108 (or otherwise
scanned and sent electronically) across by telephone, computer networks ¨
e.g., Internet, or other known means for sending electronic information and
received at 1112. Often times, instead of maintaining the patient records in
electronic format, another second paper copy 1114 of the patient's records is
made at office 1104.
31
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[00093] In one embodiment, systems and methods are provided that
leverage the trusted and secure nature of the Carepod paradigm and structure
to import patient records (usually from paper format) into the Carepod. Figure
12 shows one embodiment of a flowchart of one such possible system and
method. A sender of patient records (Sender 1202) may be a physician, nurse
or someone on staff of an office, practice or hospital. Sender 1202 may be a
registered user and/or caregiver known to the CarePod (e.g. a trusted user),
possibly in relation to a particular patient. If the sender is not yet a
registered
user, such sender may go through appropriate procedures to be included in
the set of registered users.
[00094] At 1208, sender 1202 may login to the CarePod. Thereafter,
sender may either create a new Carepod ¨ or may create a "referral" for the
particular patient at hand. A "referral" may be construed broadly ¨ e.g., to
encompass a general practitioner making a referral to a specialist, or a
hospital
administer making a referral to an insurance company for payment for services
rendered. It should be appreciated that such "referrals" encompass the usual
and typical transactions that may be made with paper ¨ or unsecured and/or
authenticated electronic transactions.
[00095] By creating a new CarePod or a new referral, sender sends the
Carepod ¨ and/or the computing/communications environment that affects
the CarePod ¨ a message at 1210 indicating the intent (e.g. create a
referral).
This message may be received by the CarePod by a communications module
that allows the CarePod to interface with a plurality of devices. Such
communication module would be configured to receive such requests for
uploading an image file.
[00096] Once such a request for uploading is received by the CarePod,
systems and/or methods are affected to securing upload such image files,
correctly associated with the individual associated with the CarePod. In one
embodiment, CarePod 1204 may generate a Global Unique Identifier (GUID)
for the message request. If the request was to create a new CarePod, then a
new CarePod may optionally be made at 1210. Assuming that the request was
to make a referral ¨ and such referral was transfer records in paper format,
then CarePod 1204 may generate a cover sheet (e.g. for facsimile or other
electronic format transfer) that comprises a unique QR code.
32
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[00097] At 1212, sender may download, print or otherwise secure the
cover letter (in print or electronic format). At 1214, the cover letter may
then
be included with the patient record in either paper or electronic format.
Sender may then take whatever appropriate technological steps and measures
to transmit the patient record (or other suitable record to be secured) to the
CarePod.
[00098] At 1216, CarePod may queue the incoming facsimile or other
electronic transmission ¨ and a sequence of other, optional, steps may then
take place. For example, CarePod may encrypt and store the fax image (or
other electronic image format). CarePod may process and/or extract the QR
code from the image file.
[00099] Once the QR code (or any other suitable identifier and/or
watermark) is extracted, CarePod may search and match the database for the
CarePod associated with the patient and/or individual at 1218. Once the
CarePod (or the system that manages multiple CarePods, if more than one
CarePod is available to the system) has made the association between the
image file and the particular patient or individual in question, CarePod may
save and/or otherwise store the image file, together with the unique
identifier
in the database. In addition, the CarePod may save and/or store the CarePod
ID together with the fax and/or image file ID at 1220.
[000100] Once the image file has been properly stored in the CarePod's
database for a particular patient and/or individual, other member's of the
patient's and/or individual's CarePod may view the image file from whatever
browser and/or device that is allowable on the CarePod at 1222. Of course,
there may be a finer granularity of which particular CarePod members may
have access to any particular image file ¨the rules of authorization and
authentication possibly being controlled by the CarePod.
Automatic Extraction and/or Verification
[000101] Once CarePod has stored the image file appropriately for the
associated patient and/or individual, it may be desirable to extract the
33
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
information from the image file on in an automated fashion ¨ and one in which
separate (and possibly automated) verification is affected.
[000102] Figure 13 depicts a flowchart for such an automated extraction
and optional verification. Extractor/verifier 1304 may be called by CarePod,
users or other executables of the CarePod, once an image file (e.g. fax image)
is
stored in appropriate storage 1302. At 1308, extractor 1304 may read the
image from storage. Once such images are available, extractor/verifier 1304
may perform Optical Character Recognition (OCR) and/or any other known
means for extracting information from image files at 1310. Once the image
data is now in another format (e.g. ASCII or other computer readable formats),
extractor/verifier 1304 may start to extract metadata from the computer
readable format at 1312.
[000103] At 1314, extractor/verifier 1304 may inquire whether the
metadata it is extracting has the "look and feel" of data that such a record
may
be expected to comprise ¨ e.g. does the metadata contain or otherwise
comprise a patient name, an age, a Date of Birth (DOB), gender, etc. ? If not,
then the extractor/verifier may either terminate its process ¨ or
alternatively,
alert the CarePod that the image file does not seem to be what it was
expecting to extract.
[000104] If the metadata falls within the parameter of expected data (e.g.
by matching a threshold of expected data, and possibly based on statistical
data, heuristics or other rule-based tests), then the extractor/verifier 1304
may
read patient data from CarePod 1306 at 1316 -- as an additional verification
that the image file at issue accurately corresponds to the particular patient
and/or individual. It should be appreciated that the automated
extractor/verifier may be maintained separately from CarePod (e.g. not share
information with the CarePod or its storage at this point). Such separation
tends to increase the accuracy of the overall system and tends to minimize the
possibility that someone else's sensitive information may be inadvertently
shared to members of the CarePod.
[000105] If the patient information matches at 1318, then
extractor/verifier
1304 may then associate and store the metadata (e.g. the computer-readable
format, and not image format) in the CarePod at 1320.
34
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[000106] Alternatively, if the patient information does not match at this
point ¨ or if any other anomaly occurs ¨ extractor/verifier 1304 may set a
flag
that a problem may have occurred at 1324. As an optional protective
measure, the information extracted may be stored separate and away from
CarePod access. This would also minimize the possibility that patient
confidential information is not compromised.
Embodiments of Real-Time Data Upload to and Sharing Within CarePods
[000107] Medical data ¨ either patient-gathered, medical device-gathered
or biosensor-gathered ¨ should properly be reviewed by physicians or other
health care providers in order to provide proper treatment to the patient. It
may be desirable to review this medical data in a near real-time basis, in
order
to provide timely medical care to the patient.
[000108] Figure 14 depicts a plurality of conventional paths by which
physicians and other care givers may receive health data (e.g., in
substantially
real-time) from either patients (tracking their own health data) or from
medical devices and/or biosensors (either implantable or external) and
possibly gathered from a mobile devices (e.g. iPhone, iPad or the like). In
the
top path, device 1402 may either create data and the data is manually input
into a computer 1404, or may provide the data automatically (via wired,
wireless, telemetry or the like). The data is typically then sent to the
doctor
1406 and/or care giver 1408, via a physical printout or may be provided
electronically to a monitor or the like. In the bottom path, device 1410 may
be
internal or external to the patient and its data may be shared with the doctor
1406 and/or care giver 1408 substantially in real-time. A record (e.g., on
paper or electronically) may be entered thereafter to the patient's record.
[000109] Figure 15 depicts one embodiment of systems and/or methods for
the sharing of real-time data ¨ as might be generated by a medical device,
biosensor or mobile application ¨ with other trusted users of a CarePod.
Device 1502 may be either internal or external to the patient ¨ and device
1502 may represent a whole host of possible devices, measuring any number
of medical and/or physiological conditions (e.g., blood pressure, glucose
level,
EKG, ECG, implantable sensors or devices or the like). Device 1502 may have
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
one or more sensors 1508. Sensors 1508 may be in command and/or
communication connection with communication and/or control module 1504.
In one embodiment, module 1504 may be made in accordance with the secure
and/or HIPAA compliant systems and methods of the present application.
[000110] In one embodiment, sensors 1508 may also comprise active
therapy modules as well, such as defibrillator, stimulation or the like, that
may
be actuated by control signals from module 1504 ¨ possibly automatically
(e.g.,
defibrillation) or possibly sent after sensor data 1520 has been reviewed by
doctor 1522, care giver 1524, patient family member 1526 and/or other
entities within the patient's CarePod 1518.
[000111] In one embodiment, module 1504 may comprise, or otherwise be
in communication with, a communication module 1506. Communication
module 1506 may be wired or wireless communications. As depicted in Figure
15, communication module 1506 may be compliant to any known or potential
wireless standard ¨ e.g., NEC, Bluetooth or the like.
[000112] As mentioned, device 1502 may be either internal or external to
the patient and device 1502 may be collecting medical data derived from the
patient. Such patient information may possibly represent data that should be
controlled in a HIPAA compliant manner. In one embodiment, this patient
medical data may be communicated ultimately to the patient's CarePod via a
communication module 1514. The platform that implements module 1514
may be either a stand-alone communication station (e.g., a desktop,
communications port or the like) or a hand-held device (e.g., a phone, smart
device or the like).
[000113] In one embodiment, module 1514 may also comprises a pairing
communication module 1510 (e.g., a wired port, Bluetooth, NEC or the like) ¨
in order to affect communications with device 1502. Through such paired
communication modules 1508 and 1510, data may be transmitted from device
1502 to communication module 1514¨ e.g., by establishing communication
and/or command connections and read medical data, possibly in a
standardized format and possibly in an encrypted format. This medical data
may also be placed in a format that may be employed by patient's CarePod by
module 1504. In another embodiment, such data may be formatted for
36
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
CarePod further downstream in the communications pathway ¨ via, e.g.,
another module 1512.
[000114] From the communication module 1514, medical data may be sent
to CarePod 1518 via any suitable communication pathway (e.g., depicted as an
encrypted wireless connection in Figure 15; but may be any other suitable
communications pathway that may be capable of transmitting encrypted data,
such as wired networks, wireless networks, the Internet or the like).
[000115] This data may be communicated to a cloud-based structure 1516,
as is known in the art. Cloud structure may comprise various storage and
applications to store and possibly modify the medical data. Cloud structure
1516 may also store a plurality of CarePods ¨which may be constructed for
individual patients and/or individuals. The data arriving from device 1502,
however, is likely meant to be stored with the CarePod 1518 that is unique to
that individual patient.
[000116] In other embodiments, it may be possible to utilize data that is
de-
identified (that is, scrubbed of any identifying indicia of linking the
medical
data to an individual patient). Such de-identified data may be used by other
CarePods or other entities for other purposes ¨ e.g., to supply data for the
efficacy of various treatments or therapies or the like.
[000117] As mentioned, once the data is uploaded to a patient's CarePod
(and possibly in substantially real-time), doctors 1522 and/or care givers
1524
may analyze the data and make treatment decisions in response (e.g. in
substantially real-time). In such a case, suitable commands (if meant for
device
1502) may be channeled along the same communication pathway as before.
Such commands may themselves represent HIPAA compliant data -- in which
case, the secure and authenticated protocols for communication to and/or
from the CarePod would also apply.
Embodiment to Prevent Accidental Misdirection of Data
[000118] In one embodiment of the present application, care may be
desirable in order not to misdirect any sensitive and/or HIPAA compliant
patient data to another CarePod that is not associated with individual
patient.
37
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
Figure 16 depicts one embodiment of a system and/or method to prevent such
misdirection.
[000119] In one scenario, data may be flowing to and/or from device 1602,
via communications module 1604 and ultimately to a cloud structure that
comprises the CarePod of the individual patient associated with the data. The
cloud structure may also comprise other CarePods for other patients (that are
not associated with data). Such cloud structure may be implemented across a
number of entities ¨ e.g. practice clinics, hospitals, care centers or the
like.
[000120] In the present embodiment, communication module 1604 may
send (at 1608) a code capable to pairing the communication module 1604 to
device 1602. Upon receipt of such a code, device 1602 may confirm receipt of
the code. Such code may be used to further secure and authenticate data and
communications.
[000121] Communications module 1604 may further communicate at 1610
with the cloud structure in order to enter the patient information and
authenticate further communications with the CarePod at 1612. CarePod
and/or cloud structure may create a Unique Identifier (GUID) that is read by
communication module 1604. Such GUID may uniquely identify the patient,
the CarePod and/or both ¨ and may be employed to further authenticate
communications further that may comprise sensitive patient data.
[000122] At 1616, communication module 1604 may update device 1602
with the GUID. In addition, device 1602 may send ¨ and/or communication
module 1604 may receive ¨ metadata about the device and data content
and/or format from any processing module embedded within device 1602
meant to affect proper formatting for secure and authenticated
communications with the CarePod.
[000123] At 1618, medical data sensed by device 1602 may be
communicated to communication module 1604. The data may have the GUID
embedded in any known manner within the data ¨which may be validated
against the GUID that is known to the communication module 1604. If the
validation is proper at the communication module 1604, then the data may
then be sent to the CarePod that is associated with the individual patient.
38
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[000124] It will be appreciated that this GUID check may also occur at
other
points along the communications pathway from the device to the CarePod ¨
including within the cloud structure itself. An opportunity to perform this
check may be made at any point of relaying such information.
Embodiments Comprising Therapeutic Treatment
[000125] In many medical situations, patients are admitted to hospital
services under substantially emergency conditions. In such cases, key medical
data about the patient may often not be accessible during these emergent
admissions (e.g., trauma and ICU). In many embodiments of the present
application, systems and/or methods may provide a solution linking many
modalities seamlessly together to aid in medical provision under one
institution, e.g., a Children's Hospital (CH) or the like. Images, lab
reports, etc.
from different hospitals may all be made available real time under one
umbrella.
[000126] In this scenario, the patient may be fitted with various devices
and
sensors and this data (e.g., blood pressure, pulse oximetry, respiration rate)
may be uploaded via wired, wireless, telemetry or the like to a HIPAA
compliant cloud based server, such as described herein. In one embodiment,
doctors may be able to utilize this data (possibly de-identified if desired)
for
research studies. In another embodiment, set trigger points may be set
(either by doctors, care givers or the CarePod on an autonomous or semi-
autonomous basis) to elicit a call to 911, the neurosurgeon on call, the
nurse,
or intensivist on call when a certain threshold value has been reached.
[000127] In other embodiments, medical data may be sent from the sensor
to a mobile device up to the cloud based server. If for example a sensor was
measuring an infant's respiratory rate or EKG, then emergency response
services (via 911) as well as the parent's cell phones may be simultaneously
triggered to notify the ambulance and parents that concerning readings were
being sensed, and that immediate notification and intervention would then be
initiated.
39
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[000128] Figure 17 depicts merely one possible treatment condition that
helps to illustrate the therapeutic nature of various embodiments of the
present application. In this case, the treatment condition depicted is
therapeutic Closed Loop Deep Brain Stimulation (DBS).
[000129] Deep brain stimulation (DBS) is a system where electrodes 1704
are placed within the human brain (under an operative procedure) within very
specific brain regions. Each electrode has 4 leads, and electrical current is
able
to pass through a combination of these leads. The actual shape and intensity
of
the current field is based upon a variety of factors, namely which electrodes
are selected to be activated, the amount of the current, the voltage of the
current, and the impedance within the circuit. This electrical activity
modulates local and general brain function. Primarily, motor function may be
improved in Parkinson's patients, but new studies seem to indicate that severe
depression may show benefits as well as possible cognition improvements in
Alzheimer's. Patients have been noted to show improvements from deep
coma as well.
[000130] In one application, DBS in children may suffer from motor
dyskinesias (abnormal jerky motor movements) as a result of perinatal strokes
(eg. Cerebral palsy). Once children are properly selected for surgery (e.g.,
they
have severe motor abnormalities and/or speech disabilities that greatly impact
their activities of daily living), they may undergo a procedure for DBS
electrode
placement. After surgery, they typically would see a neurologist many times to
fine tune the DBS system's parameters. Small changes may be made, and the
clinician would look for improvements or declines. This is time consuming, and
effects are not always apparent after making changes to voltage, current, and
other characteristics (e.g., unipolar or bipolar current configuration).
[000131] In one embodiment, it may be possible to transmit the data of
charge settings back and forth through a radio device 1710 to a mobile phone
or other smart device and/or communications module 1706 as discussed
above, then this data may be transmitted to a safe, HIPAA compliant cloud-
based server in a manner such as disclosed herein.
[000132] Apart from the valuable data collection, it may be possible for a
neurologist to make changes to the DBS setting remotely, and these changes
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
may be sent via the cloud, to the patient's mobile device, which would then
change the device settings on the child's device. This may be time saving and
desirable as the care provider of the child may keep a substantially real-time
diary and note improvements or worsening of motor function.
[000133] In addition, bracelets 1702 may be placed on the patient's arms
and/or legs, with a motion sensing device within the bracelet. This would
monitor the patient's motor output, and could then be sent to the patient's
mobile device and then to a cloud based, HIPAA compliant computer server. It
could be employed to correlate motor activity with actual DBS settings. It may
thus be possible to monitor change and also see how the patient is doing at
all
hours, as night monitoring would be automatic and may not be depend on
anyone to observe.
[000134] During this remote and automatic monitoring, it may be possible
to include therapeutic steps that would be able to ¨ with constantly
monitoring -- change DBS settings (e.g., within carefully set parameters to
ensure safety). Such embodiment may allow for closed-loop automatic fine
tuning and 24-hour real time adjustments to be made, possibly within pre-set
parameters. It is also possible to note that settings may differ while
sleeping,
after meals, at school; and that DBS changes could be altered accordingly.
Circadian rhythms may also be measured. If these diurnal variations are
important, than this closed loop monitoring system may be able to pick up
these subtleties ¨ and also make the appropriate changes.
[000135] This system may enable optimization of the current DBS paradigm
at an individual patient perspective. From a global standpoint, it may be
possible to study data real time from every child with a DBS, and make
appropriate changes and optimizations to hardware, programming paradigms,
anatomic localization, etc. all based on studying all data from all patients ¨
leveraged by cloud based, HIPAA compliant platforms.
[000136] It will be appreciated that other therapeutic treatments may be
envisioned ¨ e.g. other implantable devices could benefit from a closed loop
approach. Devices monitoring arrthymias (e.g., Holter monitors) and cardiac
pacemakers could also transmit data to the cloud via the above approach. In
addition, it is possible to place DBS for epilepsy and create a closed loop
41
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
system ¨ whereby the wrist or ankle motion detectors may immediately sense
abnormal motor discharge (as in a seizure) and then the DBS current may apply
a different setting to attempt to dissipate or lessen the abnormal neural
discharge, which would cause a generalized seizure to occur.
[000137]
Evidence-Based Analysis of Therapeutic Treatment
[000138] The CarePod has the ability to provide controlled access to
various
people involved in the care of a patient within and between Doctor's offices
to
the various parts of a CarePod, such as the communication tools, the charts
and records etc. This capability may allow the parties involved to have a
single
and common place to go to find the information they need about a patient,
even if they are physically distant as well organizationally separated -- i.e
they
could be part of two different Healthcare providers in two different parts of
the world. The charts and records portion of the CarePod, accommodates the
storage of records that exists in an electronic form. This provides the
opportunity for healthcare providers to upload files that are in electronic
form
into the CarePod. Several embodiments of systems and methods are disclosed
herein that affect the administering, monitoring, gathering evidence of
healthcare interventions and making continuous improvement on intervention
based on the evidence, possibly across large populations of patients
[000139] As described herein, it may be desirable to provide a system that
allows healthcare providers the ability to test administer and do continuous
improvements based on evidences for therapeutic intervention protocols.
Such therapeutic treatments may have any number of clinical and non-clinical
steps, and administered to one or many patients. It may also be desirable to
streamline these activities, and to provide interactions and coordination
required to administer them. Many embodiments herein affect the tracking of
the efficacy of various interventions -- whether in evidence-based medicine or
translational medicine. In many embodiments, the concepts of the CarePod
may provide the coordination, handoffs and the myriad of tools that may
increase accuracy and decrease the cost to perform such analysis.
[000140] In addition, the framework of the CarePod may support and
provide for a Therapeutic Intervention Management (TIM) system. Many
42
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
present embodiments tend to simplify the process of setting up a therapeutic
plan by integrating medical instruments to aid in capturing data, formatting
such data and sharing it to relevant groups of doctors, caregivers and
researchers. Medical instruments and/or devices are either external (e.g.
blood pressure monitor, glucose monitor and the like) or internal (e.g.
defibrillators, other electrodes and the like) and these instruments are
typically
monitoring the medical status of individual patients while they are engaged in
some therapeutic treatment and/or protocol. It is desirable that the data
captured by such instruments and/or devices be placed into a manageable set
of forms and made available to other CarePods ¨ so that data from large
patient populations may be aggregated to perform meaningful (and possibly,
very timely) clinical analysis.
[000141] In many embodiment, systems and methods are provided for the
framing the instruments to capture data, administering the instruments,
sending reminders, capturing data from the patients or devices connected to
the patient and presenting the data. In one embodiment, the information flow
from instruments to doctors/researchers may be designed as "touch-less" ¨
i.e., there does not have to be physical handoffs involved between clinical
staff, patents, caregivers and the data is available substantially in real-
time.
[000142] Often in current practice, clinical research & trials and the
actual
treatment of patients are not tightly integrated. In one embodiment, a tighter
integration may be provided by the framework of the CarePod by providing
access ubiquity and a unified platform wherein the research and practice
occurs in a single continuum ¨ with each providing a flow of information one
to
the other, resulting in continuous improvement and innovation.
[000143] Many embodiments of the present system may be implemented
as a cloud-based platform and may provide a networked model where
combinations of trusted people, patients, their devices and data around the
world may be linked together. Unlike existing enterprise applications such as
EMR tools or clinical research databases, that tend to be silos of information
and may be architecturally limited in its ability to scale, many present
embodiments may allow data from potentially millions of patients to be
aggregated using common instruments and common medical terminology
within the system.
43
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
One Embodiment
[000144] There is increasingly demand for alternatives to hospital based,
skilled nursing home-based, and doctors' office-based care services. Growth in
the prevalence of alternative care services and facilities, e.g., home-based
care
services, visiting nurse and visiting aids services, home-based end-of-life
care
services, home-based maternity and neo-natal care, home-based stroke
rehabilitation services, assisted living facilities, outpatient care programs,
hospice centers, "step down" care facilities, transitional care facilities,
and
other home-based and alternative facilities-based services is being driven by
many factors, including the aging baby boomer population's preferences for
such services, and the critical need to reduce the overall cost of care
services.
[000145] The expansion of these alternative care services is impeded by the
inability of doctors and other care providers to monitor patients' medical
conditions while the patients are outside of traditional care settings.
Further,
the adoption of such services is impeded by the inability of doctors and other
care providers to collect, analyze and use data about patients' evolving
medical
conditions as the basis of better informed, faster, more personalized
decisions
about their patients' on-going treatment outside of traditional care settings.
[000146] Further, doctors and other care providers increasingly need to
track the efficacy of therapeutic interventions for cost justification and
other
purposes. It is especially difficult to fulfill these outcome study
requirements
when patients are receiving their care outside of traditional care settings.
[000147] One embodiment of the present application may enable doctors
and other care providers who work within traditional care settings to share
information and collaborate with their patients and other care providers who
work outside the traditional care settings, including the patients' family
members, caseworkers, home-based care providers, etc. Such persons may be
physically located anywhere in the world. Any number of people connecting to
the Internet through any number of computer networks may collaborate with
each other and share information about a patient's care within the patient's
CarePod.
44
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[000148] The present embodiment may also enable doctors and other care
providers to distribute medical expertise, medical advice and care to patients
and their other caretakers while the patient is at home or at an alternative
care
facility using various previously disclosed means.
[000149] The present embodiment further tends to support the real-time
collection of data about a patient's medical condition gathered from various
sources by various means within a patient's CarePod. For example:
(i) Data emitted by medical devices and biosensors that are collected
within the patient's CarePod;
(ii) Data queries that are delivered to, and responded to by the
patient, his family members or other caretakers within the patient's CarePod;
(iii) Data that are contained in self-initiated reports submitted by the
patient, his family members, or other caretakers within the patient's CarePod;
(iv) Data that are collected by mobile device applications and
gathered within the patient's CarePod;
(v) Data that are gathered with the patient's CarePod about the
patient's genomic, proteinomic, and metabonomic profiles from various
sources.
[000150] The present embodiment may also enable the rapid analysis of
data about a patient's medical condition. In addition, the present application
tends to support the appropriately limited dissemination and display of
patient
information to a patient's various care providers in a HIPAA-compliant manner
using previously disclosed means. For example, it may be necessary for a given
patient's psychiatrist and OB/GYN doctor to receive clinical information
related
to the patient's sexual practices, while it is undesirable for the patient's
cardiologist or home-care nurse to receive such clinical information.
[000151] The present embodiment tends to enable doctors and other care
providers to access and use data collected within the patient's CarePod about
his medical condition to formulate, change, and personalize the patient's
treatment plan. For example, a doctor may:
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
(i) Change a patient's medication based on the patient's report of
deleterious side effects from a pharmacologic agent or a drug combination;
(ii) Order stronger pain medications for an end-of-life cancer patient
based on his family member's report that the patient is experiencing
increasing
levels of pain; and
(iii) Prescribe a dietary prohibition based on metabolic profile data
that relate to the patient's changing ability to metabolize particular foods.
[000152] The present embodiment may also enable doctors to correlate (i)
data that are collected within a patient's CarePod relating to one or more
certain aspects of a therapeutic intervention with (ii) data that are also
collected with the patient's CarePod relating to the patient's concurrent
and/or resultant medical condition. For example, doctors may correlate (i)
varied stimulation levels of electrodes that have been surgically implanted in
a
patient's brain to affect Deep Brain Stimulation ("DBS") therapy with (ii)
data
relating to the patient's involuntary movements collected using ankle- or
wrist-
based motion detectors, and/or data related to the patient's speech disability
leveled collected through application of the Guy's Neurological Disability
Scale.
[000153] The present embodiment may also enable doctors to correlate (i)
data collected within a patient's CarePod relating to the function of a
medical
device with (ii) data that are also collected within the patient's CarePod
relating to his concurrent and/or resultant medical condition. For example,
doctors may correlate (i) data relating to the magnetic settings of a dynamic
compression medical device system for correction of Pectus Carinatum
deformity with (ii) data relating to a patient's medical condition collected
by
performing intermittent manual measurements of the patient's chest
circumference, and/or continuously recording the pressure resistance between
the patient's chest wall and the compression medical device system, and/or
collecting intermittent reports from the patient regarding his relative
satisfaction with his physical appearance.
[000154] Further, doctors may base clinical decisions on such data
correlations, including, for example, adjusting BDS patients' electrode
46
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
stimulation levels therapeutic intervention based on such data correlations,
or
changing the magnetic settings of a dynamic compression system for
correction of Pectus Carinatum deformity
[000155] In addition, since the present embodiment may enable doctors to
monitor a patient's medical conditions with whatever degree of frequency and
accuracy desired within his CarePod. It enables doctors to monitor the effects
of various factors that may affect the efficacy of a given therapeutic
intervention. For example, the present embodiment may enable doctors to
monitor various factors that may affect a patient's response to DBS treatment,
e.g., the sleep vs. wake cycle, posture, etc., in order to devise a better,
more
personalized therapeutic protocol for the patient.
[000156] Further, the present embodiment may enable the conduct of new
clinical research trials that are designed to develop a wide variety of new,
evidence-based therapeutic interventions, e.g., new, improved DBS-based
therapeutic interventions for Parkinson's Disease and other tremor disorders,
and faster, more efficient medical device-mediated interventions for chest
deformities.
[000157] As discussed herein, the present embodiment provides a system
that enables healthcare providers to test administer and do continuous
improvements based on evidences for Therapeutic intervention protocols
having any number of clinical and non-clinical steps, to one or many patients
and streamline the activities, interactions and coordination required to
administer them. Increasingly the health care community has felt the need for
tracking the efficacy of their interventions whether in evidence based
medicine
or translational medicine. However the coordination, handoffs and the myriad
of tools needed to do that effectively makes it cost prohibitive and is
fraught
with inaccuracies.
[000158] The present Therapeutic Intervention Management system
provides a solution to this problem in a single platform. It tends to simplify
the
whole process of setting up a Therapeutic plan, framing the instruments to
capture data, administering the instruments, sending reminders, capturing
data from the patients or devices connected to the patient and presenting the
data. The whole process may be completely touch-less, meaning there are no
47
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
physical handoffs involved between clinical staff, patents, caregivers and all
the data is available in real-time. Current tools and processes separate
Clinical
research & trials and actual practice. The present embodiment tends to
remove this barrier and transform the current approaches through its access
ubiquity and unified platform wherein the research and practice occurs in a
single continuum, each feeding the other, resulting in continuous improvement
and innovation. The present embodiment may be cloud based and the
implementation of the CarePod construct allows it to be a networked model
where any combination of people, patients, their devices and data around the
world can be linked together. Current existing enterprise applications such as
EMR tools or clinical research databases tend to be silos of information and
architecturally limited in its ability to scale. The present embodiment
however
allows data from millions of patients to be aggregated using common
instruments and common medical terminology within the system.
One Exemplary Embodiment
[000159] It will now be discussed one possible exemplary embodiment
made in accordance with the principles of the present application. It should
be
appreciated that the present example is provided merely for its expository
nature ¨ and is not meant to limit the scope of the claimed invention herein.
[000160] In this example, it will be considered a simple intervention and
the
how that intervention is administered and managed using current processes
and tools. Assume a hospital develops a "Post-Operative Discharge"
intervention protocol that has the following steps spread over 6 weeks:
(1) Provide the patient and their family with a checklist of the steps to be
followed.
(2) Provide the patient and their family with education material about the
post-operative care.
(3) Medication management for the first 2 weeks.
48
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
(4) Track of progress that requires them to capture in a form ¨ e.g., their
mood or blood pressure and/or blood glucose.
(5) Have a check-in appointment after 2 weeks.
(6) Continue medication management for another 2 weeks along with
tracking data.
(7) Have another check-in appointment after 4 weeks.
(8) Have a final appointment at 6 weeks.
[000161] In current and typical practice, patients are hand-delivered paper
checklists which have the risk of getting lost. In addition, DVDs may be
burned
for videos if applicable and handed to patients. Medication management and
compliance may be placed in the hands of the patient which risks a lack of
compliance -- one of the key reasons for re-admissions. Side effects may not
be tracked in real time. Timely escalation to physicians for adverse effects
may
or may not happen.
[000162] In addition, typical tracking of progress requires patients to
capture in a form which may incomplete. Data capture may not be consistent
because it is burdensome and patients may forget. This captured data is
typically available to the physician only during the scheduled follow-up
office
visits. Check-in visits usually require a physical trip to the Hospital or a
visit
from the hospital, which tends to be time consuming and expensive. Paper
reports have to collected, collated, filed and possibly manually entered into
a
database by the hospital staff
[000163] By contrast, the above protocol may be streamlined in one
embodiment of the present application. If this streamlined protocol is made
available to new and existing CarePods, then a CarePod -- created for a
patient
¨may begin to automatically seed the Treatment Protocol. Patient educational
material may also be pre-seeded into the Treatment plan. These materials
may be made available to the patient from anywhere location where the
patient can access his/her CarePod.
49
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[000164] For medication management, the patient and their caregivers may
receive automated reminders and compliance may be captured from the
patient directly using their computers or mobile devices or medical devices
(over a wireless or wired link) that use the messaging framework of CarePod.
Data may be automatically stored in the database and data is charted in the
dashboard in real time. Automatic alerts may be sent to physicians if defined
thresholds are crossed.
[000165] Check-in appointments may be performed by using an audio-
visual application that is implemented in the CarePod -- unless a physical
checkup is required by the physician. The patient's charts may be made
directly available to the physician requiring no handoff.
Embodiment of Therapeutic Intervention Management (TIM) System
[000166] In one embodiment, the present system allows for the integration
of data from medical instruments and/or devices into the TIM system and may
be used by CarePods for both the individual treatment of the patient ¨ as well
as for the aggregation of such data across numerous patients. The TIM system
may comprise a number of different modules ¨ designed to create tools for the
designer to manage the TIM system. Such modules will now be discussed
herein and may comprise: (1) Create Instrument Module ¨for the creation of
data structures and forms for the capture of data from various medical
instruments and/or devices; (2) Create Treatment Plan Module ¨ for the
creation of therapeutic treatment protocols; (3) Send Reminder Module ¨ for
the creation of a reminder system for patients who are involved in a treatment
protocol; and (4) Capture Data Module ¨ for the effective capture of medical
data from the patient and any medical device involved in the treatment
protocol.
Create Instrument Module
[000167] Figure 18 depicts a module for the creation and/or integration of
the data from such instruments, possibly by the creation of electronic forms
and/or templates that capture the metadata of such instruments and/or
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
devices. Instrument designer module 1802 (e.g., via a Ul 1808) allows the
healthcare professionals to create templates for instruments ¨ and their
associated medical data that they generate ¨ to be populated electronically
and stored in online library in the patient's CarePod. The instrument designer
allows the author to select from a rich set of data capture attributes that
can
be included in the instruments, possibly with built-in data validations.
[000168] Process 1814 may be used by the designer to create such forms
and/or templates ¨ by adding one or more fields and/or data structures, as
desired. It will be appreciated that process 1814, as shown, is merely given
as
one example of such a process ¨ and that other fields and/or data structures
may be appended to the process, as appropriate and/or as desired to
adequately capture the medical data. Examples of such field additions may
include: Add Entry Item 1816 (e.g. text, numeric data, date or the like), Add
Rating Scale with weights 1820 (e.g., for the capture of possibly subjective
data
from the patient); Add Multiple Choice fields 1822 and 1824 (e.g. for whatever
purpose desired by the designer to capture relevant clinical data); Add Matrix
of Choice 1826 (e.g. for another manner of capturing relevant data).
[000169] In addition to these fields, designers may desire to Add Smart
Attribute 1818. Such a Smart Attribute may be available from Smart Attribute
Module 1804 and an associated database 1810. Smart Attributes allow the
designer to construct Instruments, Forms, Tags, etc. for use within CarePods
that may standardize data attributes and limit them to a potentially finite
and
common list. These Smart Attributes may affect the ability to conduct Big Data
analysis (as described below). For example, it may be possible to have a Smart
Attribute called Pertinent History, and that attribute will have a list of
value of
the Category: Disease and Conditions. This may be synchronized with the
Unified Medical Language System from NIH. Thus, if one of the CarePod
designers uses the Pertinent History smart attribute while customizing a
Patient CarePod, or Creating a Patient Intake form, or a Clinical Trial Case
Report form, or a Research project, then values, that may be entered, will
conform to the standardized language used worldwide.
Create Treatment Plan Module
51
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[000170] Figure 19 depicts one embodiment of a Create Treatment Plan
Module that might allow a caregiver the ability to create a treatment plan
(therapeutic or otherwise) for either a single patient in a CarePod, or a Plan
template to be used by other caregivers for other patients in other CarePods.
Treatment plans tend to address a particular condition of a patient that may
respond to therapy. It will be appreciated that the notion of treatment plan
and condition for treatment may be considered broadly. The condition may be
a disease condition, a congenital condition, a mental condition or any other
possible condition of a patient for which treatment plans may have efficacy.
[000171] Caregiver may use Treatment Plan module 1902 (e.g. via a Ul
1914) ¨ and may access any number of possible other modules and/or
databases to aid the creation of such a Plan. Process 1924, as depicted, may
employ one or more modules to create such a Plan. For example, the creator
may Add Guidance data item 1926, Add Medication data item 1928, Add
Monitor data item 1930 (e.g., data and/or metadata about blood pressure
monitor or glucose monitor, or other Instrument), Add Todo data item 1932
(for providing a checklist or other guidance). These data items may be
optionally added to the Plan (i.e. treatment plan template for the patient
being
treated for a condition). A guidance data item may be an informational data
item for the patient regarding the condition and treatment thereof. The
guidance data item may be any form of media possible or desired to
disseminate the information.
[000172] As mentioned, other modules may be employed to aid in the
Plan's construction. For example, the creator may access Instrument Database
module 1904 and its associated database 1916 to access metadata forms (e.g.
as may have been created using Create Instrument module, discussed above.
In one embodiment, Treatment Plan module may request forms and/or
templates that aid to capture, collect and/or collate data from any
instrument,
device or biosensor that may have relevant data to collect regarding the
treatment (and the efficacy thereof) of the patient.
[000173] To implement a Plan, the creator and/or caregiver may consult a
CarePod Members module 1906 and its associated database 1918 ¨ to provide
a list of CarePod Members for which are authorized to interface with the
CarePod for a particular patient and his/her Plan. In one embodiment, the
52
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
system may reduce the list of CarePod Members to only those who are both
CarePod Members and are relevant to the treatment plan itself. In addition,
the creator and/or caregiver may employ Add Reminder module 1936 ¨ to
provide a scheduled reminder to the patient and/or caregiver for follow-up on
treatment and status.
[000174] If the Plan is complete, then the creator and/or caregiver may
Create Treatment Plan and release it to CarePod Treatment Plan module 1908
and its associated database 1920. In addition, the creator and/or caregiver
may Create Reminders and release to Reminders module 1910 and its
associated database 1922 a set of reminders to patients, caregivers and/or
relevant CarePod Members of treatment events that are incorporated into the
treatment plan. Lastly, the creator and/or caregiver may Create Member
Access List ¨ to the Member Access module 1912 ¨ to ensure secure and
authenticated Plan communications are accurately disseminated to the correct
entities.
Send Reminders Module
[000175] Figure 20 depicts one embodiment of a Send Reminders Module.
This module takes the items that have a reminder and send notifications based
on the methods specified -- e.g through email, push notifications in the
mobile
devices or SMS. It also presents the data capture instruments to users and
stores the information in the database.
[000176] In this embodiment, CarePod Treatment Plan module 2002 and/or
its associated database 2012 may send a Treatment Plan Item to Notifier
Module 2004 at 2018. Such Treatment Plan Item may comprise data and/or
metadata regarding the patient's treatment plan. Such data and/or metadata
may be the entire treatment plan itself or may be a subset of treatment plan
data and/or metadata that is relevant to treatment events.
[000177] Notifier Module 2004 may read a Reminder Schedule ¨ which
may be received from Reminders module 2006 and its associated database
2014. In addition, Notifier Module may read the Access List (at 2020) from
Member Access module 2008 and its associated database 2016. The Access
53
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
List may comprise members who are in the patient's CarePod and are to be
reminded of treatment events within the patient's treatment plan. Further,
Notifier Module 2004 may read Notification Preferences from Member Profile
module 2010 ¨ which may list the preferred manner in which a member may
desire to receive one or means of reminder communications. It will be
appreciated that in other embodiments Member profiles may be included in
the Member Access List.
[000178] From this set of metadata, Notifier Module 2004 may then Sent
Reminders (e.g., at 2024) to Members regarding certain treatment events with
a patient's treatment plan. As depicted, members may receive scheduled
reminders of treatment via email, push notification, SMS or any other suitable
means of communication.
Capture Data Module
[000179] Another possible module in an embodiment of the present
application might be Capture Data Module, as depicted in Figure 21. In this
module, CarePod Treatment Plan 2102 and its associated database 2114 may
monitor medical data from an instrument and/or device associated with the
treatment plan. The forms and or data structures for the storage and
management of data and/or metadata from such an instrument may have
been created by Instrument module 2104 (via a Ul 2116).
[000180] In one embodiment, CarePod Treatment Plan module may send a
monitor request to such Instrument module. In response, the Instrument
module may read the Treatment type and acquire an Access List of Members
from Member Access module 2106 and its associated database 2118. In
addition, the Instrument module may acquire the forms and/or templates to
capture relevant medical and/or clinical data from Instrument Database
module 2108 and its associated database 2120.
[000181] Once this data and/or metadata has been received, Instrument
module 2104 may acquire actual medical and/or clinical data from User/Device
2110. Instrument module may then store the response to the Treatment Plan
into a Response Database 2112.
54
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
[000182] This data may be used in a two-fold manner subsequently. First, it
is possible to tell how well an individual patient is responding to his/her
treatment plan. From that information, caregivers may be able to alter the
Treatment Plan during its course. Secondly, this data may be aggregated
together over a large patient population and be used to discern the overall
efficacy of the Treatment Plan ¨ and possibly use it for predictive measures
for
success of a treatment plan for a given patient.
Big Data Analytics
[000183] As discussed above, therapeutic interventions designed and
administered through the systems and methods of the present application
described herein may be aggregated and scaled to hundreds of thousands
patients from the healthcare providers towards capturing and collating
information. This creates a significantly large database of data also referred
to
as "Big Data". The tagging of data items using standard medical terminology in
the Instrument Designer module makes it conducive to Big Data Analytics,
which is currently a challenge of fragmented data capture and data
interpretation methods. Data collected in this fashion may make it possible to
significantly accelerate the ability to gather information about the efficacy
of
an intervention, leading to quicker correction and refinement of intervention
protocols.
[000184] A detailed description of one or more embodiments of the
invention, read along with accompanying figures, that illustrate the
principles
of the invention has now been given. It is to be appreciated that the
invention
is described in connection with such embodiments, but the invention is not
limited to any embodiment. The scope of the invention is limited only by the
claims and the invention encompasses numerous alternatives, modifications
and equivalents. Numerous specific details have been set forth in this
description in order to provide a thorough understanding of the invention.
These details are provided for the purpose of example and the invention may
be practiced according to the claims without some or all of these specific
details. For the purpose of clarity, technical material that is known in the
CA 02871713 2014-10-27
WO 2012/148817
PCT/US2012/034498
technical fields related to the invention has not been described in detail so
that
the invention is not unnecessarily obscured.
56
