Easy To Use Patents Search & Patent Lawyer Directory
At Patents you can conduct a Patent Search, File a Patent Application, find a Patent Attorney, or search available technology through our Patent Exchange. Patents are available using simple keyword or date criteria. If you are looking to hire a patent attorney, you've come to the right place. Protect your idea and hire a patent lawyer.
PROTECTED HEALTH INFORMATION IMAGE CAPTURE, PROCESSING AND SUBMISSION FROM
A MOBILE DEVICE
Abstract
A system and method that permits a user to utilize a means of capturing
and managing one or more images containing protected health information
(PHI) on a mobile device, as disclosed herein. The user of the system and
method may be required to undergo authentication and authorization to
access the system and use the method.
19. A charge capture client device comprising: a transceiver for
communicating with a charge capture manager device via a connection to a
network; a controller coupled to the transceiver; an imaging device
coupled to the controller, the imaging device configured to capture an
image including protected health information (PHI): and a memory coupled
to the controller, the memory including instructions to configure the
controller to: generate a new bill graphical display for facilitating
user entry of a new patient data set, the new bill graphical display
including: an image graphical interface, wherein an image input interface
is generated when the image graphical interface is selected for selecting
an image captured by the imaging device so that the PHI information can
be parsed from the image, the image graphical interface including a
thumbnail image of the image after the image is selected; a diagnosis
selection graphical interface, wherein a diagnosis selection display is
generated when the diagnosis selection graphical interface is selected,
the diagnosis selection display subsequent in hierarchy to the new bill
graphical display, the diagnosis selection display including: an open
text field for receiving diagnosis related information; and a results
display for displaying a plurality of diagnosis codes returned as results
based upon the diagnosis related information; an evaluation and
management (E/M) code selection graphical interface; and a procedure code
selection graphical interface, wherein a procedure code selection display
is generated when the procedure code selection graphical interface is
selected, the procedure code selection display subsequent in hierarchy to
the new bill graphical display, the procedure code selection display
including: an open text field for receiving procedure code related
information; and a results display for displaying a plurality of
procedure codes returned as results based upon the procedure code related
information.
20. The charge capture client device of claim 19, wherein: the imaging
device is a camera or video sensor; the image graphical interface
includes a patient sticker image graphical interface and a patient
facesheet graphical interface; a patient sticker image input interface
for inputting a patient sticker image is generated when the patient
sticker image graphical interface is selected, the controller configured
to parse the PHI information from the patient sticker image and change
the patient sticker image graphical interface to include a thumbnail
image of the patient sticker image; and a patient facesheet image input
interface for inputting a patient facesheet image is generated when the
patient facesheet graphical is selected, the controller configured to
parse the PHI information from the patient facesheet image and change the
patient facesheet graphical interface to include a thumbnail image of the
facesheet.
21. The charge capture client device of claim 19, wherein: an E/M code
selection display is generated when the E/M code selection graphical
interface is selected, the E/M code selection display subsequent in
hierarchy to the new bill graphical display, the E/M code selection
display including a plurality of selectable Current Procedural
Terminology (CPT) codes or Systematized Nomenclature of Medicine (SNOMED)
descriptors that map to the CPT codes; the plurality of procedure codes
of the procedure code selection display are CPT codes and descriptors or
SNOMED descriptors that map to the CPT codes; and the plurality of
diagnosis codes are International Classification of Diseases (ICD) codes
and descriptors or SNOMED descriptors that map to the ICD codes.
22. The charge capture client device of claim 19, wherein the controller
is further configured to generate: a voice input graphical interface,
wherein a voice input display subsequent in hierarchy to the new bill
graphical display is generated when the voice input graphical interface
is selected, the voice input display including a record control graphical
interface for indicating recording or streaming over the network data
representing voice utterances including PHI information when selected.
23. The charge capture client device of claim 22, further comprising: a
microphone device for capturing the voice utterances, wherein the
controller is further configured to initiate the microphone device to
capture the voice utterance when the record control graphical interface
is selected, and to generate one or more voice files including the voice
utterances and temporarily store the one or more voice files in the
memory.
24. The charge capture client device of claim 19, wherein: the open text
field for receiving diagnosis related information receives transcribed
voice utterance as the diagnosis related information; the open text field
for receiving procedure code related information receives transcribed
voice utterance as the procedure code related information; the controller
is further configured to initiate a query based upon the diagnosis
related information and the procedure code related information to be sent
to the charge capture manager device, and to return billing codes based
upon a response from the charge capture manager device.
25. A charge capture client device comprising: a transceiver for
communicating with a charge capture manager device via a connection to a
network; a controller coupled to the transceiver; an imaging device
coupled to the controller, the imaging device configured to capture an
image including protected health information (PHI): and a memory coupled
to the controller, the memory including instructions to configure the
controller to: generate a resource request including an authentication
credential associated with a user to be sent to the charge capture
manager device; generate a data set including the PHI parsed from the
image; store one or more diagnoses in the data set; store one or more
evaluation and management codes in the data set; store information about
a procedure performed on the patient and a procedure billing code
associated with the procedure in the data set; encrypt the data set and
store the encrypted data set in the memory to be transmitted to the
charge capture manager device; and delete the encrypted data set from the
memory after receiving an acknowledgment message indicating successful
transmission from the charge capture manager device.
26. The charge capture client device of claim 25, wherein the storing of
the one or more diagnoses further comprises: receiving voice data
including diagnosis related information and returning a plurality of
diagnosis codes based upon the diagnosis related information; and
receiving an indication of a selection of one or more of the plurality of
diagnosis codes as the one or more diagnoses, wherein the plurality of
diagnosis codes are International Classification of Diseases (ICD) codes
or SNOMED codes and descriptors that map to a ICD codes.
27. The charge capture client device of claim 25, wherein the storing of
the one or more evaluation and management codes includes: receiving voice
data including evaluation and management related information and
returning a plurality of evaluation and management codes based upon the
evaluation and management related information; and receiving an
indication of a selection of one or more of the evaluation and management
codes as the one or more evaluation and management codes, wherein the
evaluation and management codes are Current Procedural Terminology (CPT)
codes or SNOMED codes and descriptors that map to CPT codes.
28. The charge capture client device of claim 25, wherein the storing of
the procedure includes: receiving voice data including procedure related
information and returning a plurality of procedure billing codes based
upon the procedure related information; and receiving an indication of a
selection of one of the plurality of procedure billing codes as the
procedure billing code, wherein the procedure billing code is a CPT code
or a SNOMED code that maps to a CPT code.
29. The charge capture client device of claim 25, wherein the controller
is further configured to generate a bill history display based upon data
received from the charge capture manager device in response to the
resource request, wherein the bill history display includes one or more
patient identifications for patients which bills have been created
associated with the user or a group of which the user is a member, a
medical record number and facility for each of the one or more patient
identifications, diagnosis, evaluation and management and procedure
billing code information, date information regarding when a charge was
submitted, and a current status of the charge.
30. The charge capture client device of claim 25, wherein the controller
is further configured to parse the PHI from the image.
31. The charge capture client device of claim 25, wherein the imaging
device is a camera or video sensor; wherein the controller is further
configured to encrypt the image and send the encrypted image to the
charge capture manager device where the encrypted image is decrypted and
PHI is parsed from the image, and the controller is further configured to
decrypt encrypted PHI received from the charge capture manager device.
32. A charge capture manager device comprising: a transceiver configured
to receive a resource request from a client device remote from the charge
capture manager device, the resource request including authentication
credentials associated with a user name; a controller operatively coupled
to the transceiver; and one or more memory sources operatively coupled to
the controller, the one or more memory sources including a charge
database, billing code database and instructions for configuring the
controller, wherein the instructions configure the controller to: add a
new bill data set in response to a request received from the client
device to a bill history and set a status flag associated with the new
bill data set to indicate new charge, the new bill data set including
patient identification information, one or more diagnoses, one or more
evaluation and management codes, one or more procedure billing codes,
date information and user information in the data set; generate an
acknowledgment message indicating successful transmission of the new bill
data set to be sent to the client device; delete a data set indicated in
a request from the client device; and execute a billing code query in
response to an authenticated and authorized user request from a charge
capture client device.
33. The charge capture manager device of claim 32, wherein the controller
is further configured to: generate a notification message to be sent to
an authorized and authenticated third party user indicating that the new
bill data set has been stored; modify the status flag associated with the
data set in response to a resource request received from the another
remote client device including a request to change the status flag; and
maintain an activity log of all access to resources on the charge capture
manager device.
34. The charge capture manager device of claim 32, wherein the controller
is further configured to determine the bill history in the charge
database that is associated with the user name to be sent to the client
device during the secure communication session by the transceiver, the
bill history including one or more data sets, each of the one or more
data sets including a patient identification of a patient for which a
bill has been created, a medical record number and facility, date
information regarding when a charge was submitted and medical service was
provided, diagnosis, evaluation and management and procedure billing code
information and a current status of the charge.
35. The charge capture manager device of claim 32, wherein the controller
is further configured to decrypt an encrypted image received from the
client device, parse protected health information (PHI) from the
decrypted image and encrypt and send the parsed PHI to the client device.
36. The charge capture manager device of claim 32, wherein the controller
is further configured to decrypt voice data received from the client
device, generate a transcript from the decrypted voice data and send the
transcript to the remote client device as encrypted data.
37. The charge capture manager device of claim 32, wherein the controller
is further configured to search for and obtain billing codes for each of
the one or more diagnoses, the one or more evaluation and management
codes, and the one or more procedure billing codes in the billing code
database based upon information included in the request from the client
device, and return the obtained billing codes to the client device.
38. The charge capture manager device of claim 32, wherein the bill
history includes PHI information parsed from an image.
Description
STATEMENT OF RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional Patent
Application No. 61/806,186 having a filing date of 28 Mar. 2013.
BACKGROUND
[0002] 1. Technical Field
[0003] The present application generally relates to heath information,
data and images and more specifically to the capturing, processing, and
submission of this information, data, and images from a mobile device.
[0004] 2. Prior Art
[0005] Protected Health Information is defined by the US Health Insurance
Portability and Accountability Act (HIPAA). Interpretations of what PHI
might include can be found on Wikipedia,
http://en.wikipedia.org/wiki/Protected_health_information as accessed
Mar. 28, 2013; HIPAA.com,
http://www.hipaa.com/2009/09/hipaa-protected-health-information-what-does-
-phi-include/ as accessed on Mar. 28, 2013; and from many other 3.sup.rd
party information sources.
[0006] The US government generally requires that systems accessing
electronic health records need to be configured to grant access to PHI
only to people who need to know it. If PHI is accessed by a person not
authorized to access it, then this could indicate a violation of both the
HIPAA Privacy and Security Rules. Under certain circumstances, such an
incident may have to be reported to the US Department of Health and Human
Services (HHS) and/or a state agency as a breach of unsecured protected
health information. Having good access controls and knowledge of who has
viewed or used information (i.e., access logs) can help to prevent or
detect these data breaches.
BRIEF SUMMARY
[0007] Briefly, a system including a charge capture client device and
manager device according to various embodiments provides a mobile
technology solution that enables healthcare providers and health care
provider organizations to improve provider workflow, capture more revenue
and obtain payment faster by automating steps in the revenue cycle and
eliminating inefficiencies, interim steps, and delays in information
gathering (from multiple sources and physical locations) and submission.
The client device can include multiple modalities for enabling on-the-go
healthcare providers to capture and submit information about services
rendered from any location. By using the technology, health care
providers and healthcare provider organizations can accelerate clinical
and administrative workflows, leading to more streamlined and timely
medical claim generation and submission.
[0008] For example a small private practice doctor can transmit billing
information from the hospital to his or her back office by taking a
photograph of the patient identifiers/insurance information and
annotating that with speech derived data and manual data entry (i.e.,
annotate with billing codes or description of services provided) without
the need for the implementation of a costly integration between a
hospital information system and his back office (practice management)
information system. According to an exemplary embodiment, this can be
done on a mobile device and in a way that is secure and in compliance
with HIPAA privacy and security regulations. As such, the hospital can
feel comfortable in that the provider is using a secure means to do this.
In fact, users of the system may be the hospital's own employees and they
may simply be transmitting data from one area or business unit or
operation of the hospital to another (i.e., from the clinical side at the
point of care to the billing operations in the back office). The hospital
may prefer this system be used as opposed to simply having users doing
this via renegade unapproved and non-secure means, such as taking
photographs on their phone that end up stored unencrypted and
non-password protected or texting protected patient information in clear
text via SMS texting.
[0009] According to an embodiment, the client device is implemented in a
mobile device such as a smart phone which can be operated by a user as
follows:
[0010] 1. Use an image recording device on the mobile device to take a
photograph of the key demographics of the patient (name, date of birth,
account number, medical record number, gender, etc. or generally patient
identification information), often from a patient sticker or a hospital
facesheet;
[0011] 2. Allow a user to make additional annotations to this information
(description of services rendered and/or the actual diagnosis and billing
codes, location of the services, etc.);
[0012] 3. Securely parse this patient identification information
(potentially initially locally on the device but in the long run remotely
in a data center and NOT on the device, i.e., wipe it from the device)
and transmit it to a charge capture manager device at a back end system
where it is stored securely at rest in a charge database;
[0013] 4. Process this information via a combination of machines with or
without human quality assurance, with the process being turning the data
in the image to structured data persisted in data transport objects (data
sets) in some sort of data repository (charge database); and
[0014] 5. Transmit, provide access to, or present the information for
consumption in a downstream business process, i.e., creating a medical
claim. This can range from allowing an employee or medical billing staff
member to pull up the information (i.e., look at it on a screen) from the
charge database via the charge capture manager device to sending the
information via an application programming interface or via a standard
communications protocol like HL7 or Electronic Data Interchange (EDI)
transaction (i.e., an EDI 5010 transaction) to a downstream system (i.e.,
a practice management software or a claims clearing house).
[0015] Accordingly, there is a need for a system and method for capturing,
processing, and submission of this information, data, and images from a
client device in a simple and secure manner, thereby simplifying the
information collection and billing process for professionals, such as
physicians. It is to this need and other needs that the present invention
is directed.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] FIG. 1 illustrates an example of a provider capturing patient
demographics from a hospital patient sticker or wrist band (in order to
send it to their billers/coders in their health care organizations or
practice's `back office`) using a mobile device.
[0017] FIG. 2 illustrates an example of a provider capturing patient and
health insurance data on a hospital face sheet (in order to send it to
their billers/coders in their health care organizations or practice's
`back office`) using a mobile device.
[0018] FIGS. 3-23 illustrate an example application or "app" on a smart
phone, showing a series of screen captures during use.
[0019] FIG. 24 depicts more traditional interfaces for data exchange
between organizations or within organizations.
[0020] FIG. 25 depicts an application of the present invention in a
medical context where a mobile provider is using his or her mobile device
at some point of care (i.e., a hospital) and in the course of his or her
activity is capturing data necessary to document, bill for, and
memorialize the services or procedures rendered for one or more patients.
[0021] FIG. 26 is a block diagram illustrating exemplary portions of a
client device and manager device at the organization in an exemplary
operating environment.
[0022] FIG. 27 is a flow diagram showing exemplary operations performed by
the client device and the manager device.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
[0023] Generally, the present disclosure concerns a HIPAA compliant
component of a mobile technology solution that enables healthcare
providers and health care provider organizations to improve provider
workflow, capture more revenue and obtain payment faster in the revenue
cycle and eliminating inefficiencies, interim steps, and delays in
information gathering (from multiple sources and physical locations) and
submission.
[0024] The focus of the technology is to address challenges presented by a
mobile provider workforce that sees patients within and across complex
healthcare organizations (many which have multiple locations and are on
different information systems) which are frequently remote from the
location where the healthcare insurance reimbursement claims are prepared
and submitted.
[0025] The technology accomplishes this by enabling on-the-go healthcare
providers to capture and submit information about services rendered from
any location via multiple modalities available on a client device such as
a mobile device, including, but not limited to, computer vision and
speech. For example, a physician lounge, a physician's residence, a
physician's desk in their office, or a point of care where a patient can
be seen including, but not limited to, the patient's home, a nursing
home, an ambulatory or outpatient surgery center, a non-hospital based
clinic or office where a patient is seen on an outpatient basis, a
hospital unit or area, including, but not limited to, an intensive care
unit, medical or surgical floor, step down unit, emergency room,
pre-operative area, post operative area or post anesthesia care unit,
procedure area, ambulatory clinic, operating room, etc. By using the
technology, health care providers and healthcare provider organizations
can accelerate clinical and administrative workflows, leading to more
streamlined and timely medical claim generation and submission.
[0026] The mobile technology solution is a component of a broader platform
that includes backend endpoints that communicate with mobile devices
equipped with multiple peripherals including, but not limited to, a
graphical user interface and touch screen, a means of image capture
(camera), a means of voice capture (microphone), a transceiver,
controller and instructions for configuring the controller stored in a
memory.
[0027] The platform enables on-the-go healthcare providers to immediately
or in a queued or batched process submit via a client device data
including, but not limited to, patient demographic, diagnosis, and
billing information to a charge capture manager device at a backend
endpoint that enables (i) staff members in a back office location (where
financial and administrative operations are carried out for the
healthcare provider organization) to access, edit, and further annotate
the data set via another client device; (ii) a 3.sup.rd party system (for
example, a practice management software, a claims clearing house, or a
payor organization) to securely access or be sent all or a subset of the
data; and (iii) the data to be sent on for further downstream processing
by a machine and or human. Such data can include, but is not limited to,
medical diagnosis and billing codes, health insurance information,
charting related to what service(s) were rendered, etc.
[0028] Example Usage of Technology
[0029] An example of how the technology might be used allows physicians
and other healthcare providers to `Touch, Talk, and Submit` billing data
eliminating the need for paper-based billing cards and manual data entry.
In this example, the client device 10 is a mobile device. The application
(mobile device app) is installed in the memory 1006 of the mobile device.
The controller 1004 is configured according to the mobile device app
stored in the memory 1006. Patient demographics, diagnosis information,
and detail about the services rendered needed for billing can be captured
via image and voice. Billing codes can be picked from a list returned
from a voice query. The data is encrypted, and instantaneously or in a
batch fashion, delivered to the provider organization's billing staff or
a 3.sup.rd party company that does billing on behalf of the provider and
ultimately to the payor via a connection to a network 15. As shown in,
for example, FIG. 9, the mobile device app may present a template for
providers to follow regarding what information is needed and provide the
ability to securely capture patient demographics and healthcare insurance
billing information with a camera (leveraging computer vision) on the
client device 10 from a wristband, a computer screen showing the
patient's demographics or insurance information, a sticker or paper with
the patient's demographics and/or healthcare insurance information,
and/or digital or paper face sheet. The solution eliminates the need for
paper based charge capture processes, which result in lost revenue,
errors, and significant delays in claim generation and submission.
[0030] Referring to FIG. 27, operations performed by the charge capture
client device 10 and manager device 20 (system) for providing protected
health information image capture, processing and submission will be
briefly described: [0031] A system that permits a user to utilize a
means of capturing and managing one or more images containing protected
health information (PHI) on a client device (2702). The system may
require the user to undergo authentication and authorization to access
this resource (2704) [0032] Permit none or some user and/or
hardware/software driven post PHI image capture processing on the client
device (2706) [0033] Send encrypted PHI image(s) and/or the meaningful
content of the PHI image(s) derived after post PHI image capture
processing via a secure wired or unwired communication medium and/or
protocol (if and when a connection is confirmed to be available) in
real-time or via a queued or batched process either standalone or as
annotation to a broader dataset (2708) [0034] Securely receive PHI
image(s) at a manager device at a wired or remote backend endpoint (2710)
[0035] Maintain an encrypted copy of PHI image(s) for some period of time
on local (mobile) device or securely remove and/or destruct and/or
overwrite all data related to the PHI image(s) from the local (mobile)
device after confirming successful transmission of the PHI image(s) to
the manager device at the remote backend endpoint (2712) [0036] Permit
none or some authenticated and authorized user and/or hardware/software
driven post PHI image receipt processing of PHI image(s) on a machine
and/or by an authenticated and authorized user via a secure user
interface affiliated with the manager device at the wired or remote
backend endpoint (2714) [0037] Securely store PHI image(s) and/or some or
all of the meaningful content of the PHI image derived after post PHI
image processing at a database associated with the manager device [0038]
Securely log (for future audit purposes) any and all access to or
transmission of PHI image(s) and/or some or all of the meaningful content
of the PHI image derived after post PHI image processing (2716) [0039]
Process may stop here or a means may be provided to: [0040] Securely
render the PHI image(s) and/or the meaningful content of the PHI image(s)
derived after post PHI image capture processing in a user interface on
user client device (2718) [0041] Securely pass PHI image(s) and/or the
meaningful content of the PHI image(s) derived after post PHI image
capture processing to a downstream internal process [0042] Securely route
or make available the PHI image(s) and/or the meaningful content of the
PHI image(s) derived after post PHI capture processing to an
authenticated and authorized 3.sup.rd party system via some application
programming interface (2720) [0043] Securely remove and/or destruct
and/or overwrite all data related to the PHI image(s) from the manager
device at the backend endpoint after receiving instructions either
programmatically or from an authenticated and authorized user with a role
that has data deletion privileges (2722)
[0044] Following is a disclosure of an illustrative application of the
invention, presented in the form of a demonstration and referring to the
figures.
[0045] According to one embodiment, an application is installed and
executed on a client device such as a smart phone or the like. The
physician simply verbally provides information about the care rendered to
a patient and then they hit submit. The application is HIPAA compliant.
Voice and computer vision on the smart phone are leveraged to get
information into the system, thus eliminating a need to integrate the
system in the hospital, although a hybrid strategy of back end hospital
system integration and image based data recognition is envisioned.
[0046] Currently, the status quo process of how physicians capture charges
today for the work they do, namely, the patient care they provide, in a
hospital, in an office, in an ambulatory surgery center, or in a nursing
home. After a patient is seen, for example an obese hypertensive patient
with hypertension who came into the office for treatment of an ankle
sprain, the doctor charts in the medical records system, be it paper or
electronic. That is either in the facility's record system or if in the
doctor's office, in the doctor's own records system. Associated with that
visit, the doctor needs to translate that care into billing codes.
Billing codes consist of diagnosis codes as well as codes for the
evaluation and management and any procedures that may have been done.
Here at the top of the currently used form, often termed a superbill,
there is a space where basic demographics can be captured. Name, date of
birth, date of service, account number, and sometimes medical record
number. Immediately beneath that, the doctor can write down the diagnosis
codes, such as International Classification of Diseases (ICD)-9 codes and
soon to be ICD-10. The rest of the form is dedicated to capturing
evaluation and management charges about the visit. Those are called
Current Procedural Terminology (CPT) codes. If this were an office visit,
the doctor can look under outpatient services and they simply check off
what they did and what the related diagnosis was.
[0047] These forms are typically created with the most common billing
diagnosis and billing codes that doctor might use. By having the most
common codes on the forms, the doctor can simply check off the form to
indicate to the billing staff in the back office, which of the codes is
correct. Above the diagnoses on a typical superbill form are the CPT
codes, whether for a new patient, an established patient, a consult, a
post-operative visit. These are the codes with a straightforward low,
moderate, or high complexity, etc., diagnosis or treatment. The doctor
checks off the appropriate codes, and the related diagnoses. The typical
form has a box for patient label. In the hospital there are frequently
stickers that the doctors can pick up to quickly provide and capture the
demographics for the care by attaching the sticker on the form. The use
of such stickers allows the various forms to contain much of the same
evaluation and management codes for the inpatient setting so the doctor
can check them off. Using the stickers also can allow for the capture of
where the patient was seen and what physician rounded on that patient.
There are multiple examples of stickers, such as bracelets or wristbands
that are worn by the patient to confirm before pills are provided, before
a procedure is done, that the patient is indeed the correct patient to be
receiving that procedure, diagnosis, or medication. Doctors always
capture these stickers to know who they saw in the hospital.
[0048] There are many varieties of the paper work or paper types that
doctors use to capture charges in the hospital. For example, on such a
form, a doctor would attach a sticker on and then the doctor would place
a check next to the appropriate CPT code. Here the doctor can indicate
what facility they are seeing the patient at, and write in their name as
far as which physician saw the patient. That is the current process. It
is a paper driven process and the doctor is responsible for carrying the
form or superbill and placing it in a bin or delivering it personally to
the back office so that charges can then be generated in the form of
claims that go off to the payor. Some doctors simply carry around a piece
of paper during the course of their day and attach stickers on the paper.
In that way the doctors have a record of who they saw, and they did not
have to write anything down.
[0049] The other important piece of paper work is one that originates in
the hospitals and skilled nursing facilities if the doctor is doing
nursing home rounds. This is often referred to as a face sheet. The
primary important information beyond the basic demographics that the face
sheet has includes information on the admission, information about who
the guarantor is on the insurance, and the insurance information that
shows who the payor is and what the related group number and policy
numbers are, all of which is information that is required so that
physicians can do their billing.
[0050] The physician revenue cycle all starts with a patient being seen.
After that patient is seen, on the administrative side in so far as the
billing, one of these paper forms must then make it to the biller. This
is the front end of the revenue cycle. This is where this paper, such as
the superbill, billing card, or encounter form, is filled out. This is
also where delays can accrue if the physician takes a long time to turn
in the paper work. Once those charges are in the back office, a biller
can then process them and enter the claims into the practice management
software. At that point, the charges on the claim go off to the payor
through a claims clearing house and if everything goes well, there will
be a payment that comes out of the back end of the revenue cycle process.
[0051] A charge capture client device 10 and manager device 20 according
to various embodiments eliminates the front end of the charge cycle,
taking the charge lag of the physician revenue cycle from 10-30 days down
to zero days. The client device 10 can be implemented by a mobile device
such as smart phone or application on a desktop computer. The physician
opens the mobile device or desktop app (application) and logs in.
Particularly, the controller 1004 of the client device 10 executing the
application generates a resource request including an authentication
credential associated with the physician (user) to be sent to the charge
capture manager device 20 via a connection to the network 15. Upon
logging in, one option the physician has is to view their bill history
where they can see which patients (one or more patient identifications)
they have created bills on, what the medical record number and facility
were for those patients, when the charge was submitted and the current
status of the charge, whether the biller has posted the charge to the
practice management software and sent the charge off to the claims
clearing house and then the payor, or whether the charge is still a new
charge, thus allowing the doctor to have some direct visibility into the
revenue cycle.
[0052] Most of the time, the provider is logging into the application on
the client device 10 to do one thing, that is, create a new bill or
charge. This is accomplished via the primary bill creation
interface/workflow (new bill graphical display 300) for the doctor. This
process can start with the ability to leverage the patient sticker or
patient identification bracelet or wristband in the hospital to capture
the demographics using computer vision. Referring to FIG. 3A, the new
bill graphical display 300 includes an image graphical interface (for
taking photo of patient sticker 310A), (for taking photo of facesheet,
etc. 310B), wherein an image input interface (for patient sticker shown
FIG. 1, for facesheet shown in FIG. 2) is generated when the image
graphical interface 310A, 310B is selected for receiving an image
including patient identification information. The doctor simply takes a
photo of patient sticker after the doctor is prompted to take a picture
of the patient sticker by the app. For example, the doctor centers the
lens over the sticker and once satisfied, they take the picture. The
doctor then has the opportunity to review the photograph, to perform
quality assurance, to ensure that it is not blurry, etc. The doctor is
prompted: `can you read this?` If the doctor is satisfied and approves of
the image quality, the doctor clicks the use (approve image) button and a
thumbnail image of that patient sticker is then added to the bill. The
thumbnail of the patient sticker image would then appear in the area of
the image graphical interface 310A, 310B as shown in FIG. 3B.
[0053] If the doctor does not happen to be around or near a sticker, the
doctor can always speak or type in the patient demographics. If the
medical provider prefers voice to text technology, this can be used to
create or capture the patient's basic demographics without touching the
typewriter or keyboard on the device at all. The new bill graphical
display 300 includes a voice input graphical interface (for inputing
patient demographics 312A), (for inputting bill/memo 314B), wherein a
voice input display (FIG. 3C for inputting patient demographics and FIGS.
6-8 for inputting bill/memo) subsequent in hierarchy to the new bill
graphical display 300 is generated when the voice input graphical
interface 112 is selected. The voice input display can include a record
control graphical interface (FIG. 8) for recording voice utterances
including patient identification information when selected; a transcript
display portion for displaying a transcript of the voice utterances; and
a plurality of template graphical interfaces for categorizing information
included in the voice utterances to extract the patient identification
information. An example of a doctor speaking a fictional patient's name
and basic demographics would be "Jane . . . next field (navigating the
data capture form in the user interface) . . . Doe . . . next field . . .
female (adding the patient's gender) . . . next field . . . Nov. 1, 1942
(adding the patient's date of birth) . . . next field . . . 305862
(adding the patient's medical record number) . . . 688922 (adding the
patient's account number)" The software application on the mobile device
or desktop then transcribes the provider's verbal utterances. Once that
process has been completed, those basic patient demographics have been
populated in the app.
[0054] The provider then has the opportunity to select the related
diagnoses for the visit, either by speaking into the client device or by
selecting matching billing codes from a list of results that the software
application returns in response to the doctor's verbal utterances. The
new bill graphical display includes a diagnosis selection graphical
interface 314, wherein a diagnosis selection display shown in FIG. 6 is
generated when the diagnosis selection graphical interface 314 is
selected, the diagnosis selection display subsequent in hierarchy to the
new bill graphical display, the diagnosis selection display including: an
open text field (FIGS. 19-20) for receiving diagnosis related
information; and a results display (FIGS. 22-23) for displaying a
plurality of diagnosis codes returned as search results based upon the
diagnosis related information. For example, if the doctors speaks or
selects "hypertension", a list of billing code search results is returned
in response and then the doctor selects matching billing code. Here again
the doctor can leverage voice to text to verbally look up the desired
billing codes by speaking. The doctor can enter or add as many of the
diagnosis billing codes as they need to by speaking or selecting, for
example, "diabetes", and a list of billing code search results is
returned in response. The doctor can continue with additional diagnoses
to accurately capture what is going on with the patient ("obesity",
"sprained right ankle", etc.).
[0055] Returning to FIG. 3A, then the doctor can select the evaluation and
management (E/M) code selection graphical interface 316 to create or add
an evaluation and management billing code, such as "new inpatient
consultation". When the E/M code selection graphical interface 316 is
selected, an E/M code selection display (FIG. 7) subsequent in hierarchy
to the new bill graphical display is generated, the E/M code selection
display including a plurality of selectable CPT codes. Anything in the
billing code database (on the client device 10 or on the charge capture
manager device 20) that matches what the physician has said or selected
will be returned in the list of results in the pick list shown in the
user interface in response to the physician's input. The doctor can then
select the correct billing code. Again under ICD-9 not only is the ICD-9
diagnosis billing code provided, but also the corresponding ICD-10
diagnosis billing code. The present inventive solution is ICD-10 ready,
which is a major issue, the transition from ICD-9 to ICD-10, facing
hospitals and physicians. ICD-10 is slated to go live in October of 2014.
[0056] Finally, if a procedure was done on the patient during the
encounter with the provider, the provider can select the procedure code
selection graphical interface 318 so that the procedure code selection
display (FIG. 7) subsequent in hierarchy to the new bill graphical
display is generated. The procedure code selection display including: an
open text field for receiving procedure code related information; and a
results display for displaying a plurality of procedure codes returned as
results based upon the procedure code related information. The provider
can use the procedure code selection to add the procedure information and
the associated CPT billing code in the same manner, by speaking or
selecting the appropriate procedure. If the returned procedures are
incorrect, the doctor can initiate the verbal billing search again
without selecting a result from the list of billing codes returned in the
last verbal billing code query. When the correct code is returned, it can
be selected. Once the doctor is satisfied with the face sheet image
quality after the provider's human quality assurance review, the approved
image is then appended to the bill. If a doctor wants to add a memo, this
also can be done verbally. For example, the doctor can speak "biller,
please make sure we have captured the appropriate charges for the ankle
splint that was provided to the patient period." The doctor then approves
and saves the memo.
[0057] The next step is review of the bill information. The date of
service is defaulted to today by the app. The date of admission can be
added to the bill. The name of the doctor currently logged in is added.
If the software user is billing for someone else, another doctor can be
selected. The name of the facility can be added. The name of the
referring doctor can be added. Once the user has entered the referring
provider, the referring provider goes into the user's list of providers
that are referring the user patients.
[0058] At this point the user is done and the user can hit submit. That
bill goes into the user's bill history. The charge just created with its
annotations, including images actually uploads in the background. The new
charge is flagged as a new charge in the user interface. All charge data,
including images, is securely transmitted and processed--structured data
deriving from the patient information in the image submitted is created.
The billing information is sent to the charge capture manager device 20.
[0059] After entry of information by the doctor, the biller can be
notified that there are new charges. The biller logs in to the system
(charge database in memory 2006 on the charge capture manager device 20)
via a web browser and can see the charge the provider just created for
`jane doe.` The image derived patient demographics have been generated
and the user can search, sort and filter the charges that users in the
account have submitted based on the patient demographics and/or other
information captured. The record from the list of submitted charges in
the account provides a detail view of all of the information provided by
the provider, including the transcript that was created by the provider
for the billing staff. The billing staff has the opportunity to filter
the bills based on status, and can change the status of the bills, can
change what information is displayed and they can filter by user.
[0060] Thus, by using the mobile device, a doctor can improve workflow,
capture more revenue and obtain payment faster by automating steps in the
revenue cycle and eliminating inefficiencies, interim steps, and delays
in information gathering (from multiple sources and physical locations)
and submission. The invention accomplishes this by enabling on-the-go
healthcare providers to capture and submit information about services
rendered from any location via multiple modalities available on a mobile
device. By using the technology, health care providers and healthcare
provider organizations can accelerate clinical and administrative
workflows, leading to more streamlined and timely medical claim
generation and submission.
[0061] The system permits the collection of data utilizing multiple
peripherals on a client device 10 such as a mobile device (including, but
not limited to the microphone, accelerometer, video sensor, global
positioning system, touch screen, keyboard) or peripherals that may be
tethered to a mobile device or wirelessly communicate with a mobile
device (i.e., a signal from another piece of electronic equipment) or
utilizing the mobile device's ability to communicate (wirelessly or via
wired connection) with an in house or third party information system. One
potential application of the system is to collect data that documents and
memorializes the occurrence of a billable medical encounter or episode of
care between a provider and a patient or a billable service including but
not limited the interpretation of a diagnostic study or review of the
results from a diagnostic study. The system safely manages data that may
contain personally identifiable health information that needs to be
managed consistent with the HIPAA security and privacy rules and
regulations
[0062] Data Collection
[0063] The data collected may be any combination of a multitude of types
including, but not limited to: [0064] All or a subset of the
information that is necessary to collect for the purpose of activities
including but not limited to: billing for medical services or procedures,
assembling a medical claim, documenting the performance of medical
services or procedures, preparing a report for presentation internally,
to a third party, or to a patient, for record keeping and compliance
purposes, for accreditation, for executing safety surveillance or quality
improvement efforts, for participation in medical research or
pharmaceutical post marketing surveillance; [0065] Image based data that
may contain written (handwritten or typescript) text or language that
originated from a hard copy (i.e., a physical print out on a piece of
paper) or a soft copy (i.e., an image rendered on a computer screen). For
example, text data that might appear in clinical charting, diagnostic
study reports, patient registration and insurance data, patient
identification, legal contracts (i.e., advanced directives, procedure
consent forms), questionnaires or feedback data provided by a person
(i.e., a patient or a consultant); [0066] Image based data that is the
output of some diagnostic procedure such as a radiograph including, but
not limited to one or a collection of plain film x-rays, computed
tomography scans, magnetic resonance imaging scans, electrocardiograms,
electroencephalograms, nuclear medicine studies, read outs rendered on
the screen of various monitoring devices or a hardcopy thereof of, data
plotted on axes of some sort to demonstrate trends such as for example
the change in the value of a vital sign over time, soft or hard copy
reports and images from machines that may analyze a specimen originating
from a patient (i.e., cluster of differentiation based immunophenotyping)
or the amplification of a specimen from a patient (an example of the
latter being a polymerase chain reaction and gel electrophoresis); [0067]
Image based data of a person, group of persons, or a particular part of a
person or their anatomy or the condition thereof, including but not
limited to an intraoperative image of a surgical site either with or
without magnification (i.e., an image from an intraoperative microscope),
image of a catheter, tube or line in place on a patient, image of a
post-operative wound, image of a skin condition, image of a specimen
(i.e., a surgical biopsy) either in gross or under low or high-power
magnification such as that of an light microscope or electron microscope
with or without staining, immunohistochemistry, immunofluorescence, etc.;
[0068] Verbal, or text data created generated by the end user of the
technology (i.e., by using voice to text, handwriting, typing, searching
a database of data on the client device 10, at the manager device 20 or
another remote device and selecting items from the results to be added as
annotations to the data being collected such as for example a medical
diagnosis, evaluation and management, or procedure code); [0069] Actively
entered data (for example, information a user may provide by typing it
into a form, by speaking, by interacting with and providing data via a
software user interface via touch, voice or gestures) or passively
collected data that the user has opted into providing or that the user is
authorized to collect (i.e., the recording of a conversation, the users
location as provided by global positioning system, the users movement
such as that which may be provided by an accelerometer, etc.); and [0070]
Information that is pulled from an information system that the user is
authorized to access, that the user's mobile device (client device 10) is
authorized to access and that the user's mobile device is able to connect
to via a wired or non-wired connection. Examples may be accessing and
pulling in patient or provider data from a hospital, a payor, a third
party vendor system (i.e., credit scoring service, insurance validation
service, etc.), pharmaceutical company database, a research database, an
ontology database such as for example a database containing SNOMED data,
using key words or search terms, or using record locators or identifiers
captured by the mobile device's video sensor, captured by manual data
entry (i.e., by typing or voice) by an end user, captured using physical
characteristic or biometric data (i.e., image of an individual's face, a
finger print, a retinal scan, using deoxyribonucleic acid, a protein
sample, or analysis thereof).
[0071] The data captured via the various modalities can be temporarily
securely stored on the client device 10 or transmitted, immediately or at
a later date decided by the user or based on programmatic instructions,
via a wired or non-wired connection in a secure fashion consistent with
any organizational policies, HIPAA, or any other privacy or security
laws.
[0072] The data may be transmitted securely to a (charge capture manager
device 20) residing in a data center or another location. The data is
securely managed by commercially reasonable means both in transmission
and at rest in a fashion consistent with organizational policies, HIPAA,
or any other privacy or security laws.
[0073] The data collected or a summary or subset thereof may at some point
be transmitted securely to populate a third party system via an API or
via a standard messaging protocol, including but not limited to Health
Level Seven--HL7 messaging. An example of this might be transmission of
the data to a practice management software being used to prepare claims
to bill a payor for a medical service or procedure or transmission to a
claims clearing house, in the case where the data has been organized and
assembled into a medical claim.
[0074] The data can be organized, annotated, processed, analyzed, and
synthesized throughout the process (i.e., during collection or after
transmission, etc.). Feedback may be provided to the user about the data
initiated by a machine driven by logic or feedback from a remote party
interpreting or reviewing the data during or after its collection.
Feedback might include but would not be limited to feedback on the
quality of the data or the completeness of the data (i.e., notification
about missing or outstanding data that still needs to be collected),
conclusions determined and arrived at via analysis of the data collected
and some other logic (business rules, clinical decision support, or any
other algorithms), and/or suggestions about next steps that should be
taken. Feedback may be delivered by a multitude of modalities via the
mobile device including tactile, audio (speaker), visual (user interface)
or other means
[0075] A Data Transmission Interface
[0076] As shown in FIG. 24, traditional means of data exchange or
interfaces between organizations consist of in person verbal
communication, wired telephone and facsimile communication, paper based
communication (i.e., mail or courier service), or email communication,
text messaging, an application programming interface, among others.
[0077] One of the manners in which the inventive system described can be
employed is as a means or interface between two organizations that need
to securely transfer information including protected health information
driven by a human or machine actor using a mobile device. The data
transfer may be necessary for any authorized need including but not
limited to a business need (i.e., medical billing and medical claims
preparation), a compliance need, a quality monitoring need, an
accreditation reporting need, a research need, and other needs. The
current invention describes a new data exchange interface driven by an
authorized human or machine actor using mobile technology whereby the
actor can collect data from multiple data sources utilizing the mobile
device and its peripherals.
[0078] Data may be actively captured or passively captured. Data may
include, but is not limited to, data collected from manual data entry,
from verbal data, from global positioning system data that may or may not
be correlated with an action of the actor, from the current time (i.e.,
the actor's location where and time when a particular action was carried
out or the location and time at which a particular event occurred), from
images, such as, for example, snapshots of textual, graphical or
pictorial data that is on a hard copy medium like paper, snapshots of
similar information that is presented on a graphical user interface of
some sort like a computer or workstation monitor, snapshots of a person,
a part of a person, or a pathology of interest, snapshots of analytical
readouts from specimens obtained from a patient or images of the patient
specimen(s) under magnification with or without special dying or
immunohistochemical staining, and/or snapshots of imaging studies (i.e.
diagnostic imaging studies) that may be presented on a physical printout
or as an image rendered on a computer or picture archival communications
system (PACS) workstation).
[0079] Data may be collected at any location in one sitting, session, or
episode or over a series of sessions, sittings, or episodes. Data
collection locations might including but are not limited to, an office or
business location, a residence, a skilled nursing facility, an acute care
hospital, a rehabilitation hospital, an ambulatory surgery center, an
outpatient clinic, a motor vehicle, a mobile clinic, a retail location,
or other location.
[0080] Data may be collected by one individual or machine actor or
collaboratively by multiple individuals and/or machine actors using
mobile devices. Individuals may include, but are not limited to be
employees of an organization, business associates and contractors of an
organization, customers or patients of an organization, medical
providers, among others.
[0081] Data is collected, annotated, assembled/organized, analyzed,
processed, and submitted using various gestures (i.e., touch gestures) or
verbal commands.
[0082] FIG. 25 depicts an application in a medical context where a medical
service provider is using his or her mobile device (client device 10) at
some point of care (i.e., a hospital) and in the course of his or her
activity is capturing data necessary to document, bill for, and
memorialize the services or procedures rendered for one or more patients.
The mobile device 10 is equipped with multiple peripherals that enable
data collection of numerous types, both passive (i.e., GPS position and
event time) and active (snapshot images taken with the video sensor or
data keyed in or added verbally as annotations to data collected). The
actor (mobile healthcare provider) can utilize the video sensor on the
device 10 to capture textual, graphical or pictorial data that may appear
on a piece of paper (i.e., a hospital form or report like a `patient
sticker` or a patient `face sheet` with patient identifiers and patient
insurance information needed to bill the services), that may be in the
form of a note that the healthcare provider hand wrote or typed and
placed in the patient's paper or electronic medical record `chart`, that
may be in the form of a snapshot of a patient, a wristband the patient
may be wearing with personal identifiers and record locators, a part of
the patient (face, surgical wound, site with a pathology that is being
managed by the medical provider), or the patient in the midst of a
procedure (i.e., an intraoperative image or snap shot of a fluoroscopic
intra-procedure image that documents some aspect of the care--such as the
procedure being done at a particular and correct anatomical site), that
may be in the form of a diagnostic imaging or other study being reviewed
on a workstation monitor or a hard copy on a light box (i.e., a film
showing a particular finding on an imaging study). The actor may also
annotate the images and other data with manual data entered into the
mobile device 10 by voice, by typing on the device keyboard or by
interacting with the software (stored in the memory 1006) on the mobile
device 10 via the touch screen (i.e., adding some details of the services
provided, adding a memo to be reviewed by a staff member or medical
biller in the back office, searching for appropriate codes and then
adding or annotating the data set with the diagnostic or procedure codes
for the services provided). According to the above embodiments, the actor
can use a client device 10 such as their own mobile device or an employer
issued mobile device to collect, assemble, annotate and subsequently
transmit this data (via transceiver 1002) to a data center in a remote
location (charge capture manager device 20) where the information will be
used by other actors or machines to execute downstream business
processes. The manager device according to the above embodiments can
securely manage (collecting, persisting, transmitting) the data set
collected which, in this example would include personal health
information and patient identifiers that need to be protected and managed
securely by law.
[0083] The charge capture manager device 20 in the remote location
includes a transceiver 2002 configured to receive a resource request from
the client device 20. The resource request includes authentication
credentials associated with a user name. The manager device 20 includes a
controller 2004 operatively coupled to the transceiver 2002 and one or
more memory sources (depicted by 2006) operatively coupled to the
controller 2004. The one or more memory sources 2006 include a charge
database and instructions for configuring the controller 2004. The
instructions configure the controller 2004 to add a new bill data set
received from the client device to a bill history and set a status flag
associated with the data set to indicate new charge, the new bill data
set including patient identification information, one or more diagnoses,
one or more one or more evaluation and management codes, a procedure
billing code, date information and user information in the data set. The
instructions configure the controller 2004 to generate an acknowledgment
message indicating successful transmission of the new bill data set to be
sent to the remote client device 10; delete a data set indicated in a
request from the client device 10, generate a notification message to be
sent to another remote client device such as the biller indicating that
the new bill data set has been stored; modify the status flag associated
with the data set in response to a resource request received from the
another remote client device including a request to change the status
flag as shown in FIG. 8; and maintain an activity log of all access to a
data set in the charge database.
[0084] The controller 2004 can be further configured to determine the bill
history in the charge database that is associated with the user name to
be sent to the remote client device 10 during the secure communication
session by the transceiver 2002, the bill history including one or more
data sets, each of the one or more data sets including a patient
identification of a patient for which a bill has been created, a medical
record number and facility, date information regarding when a charge was
submitted, and a current status of the charge.
[0085] The foregoing detailed description of the preferred embodiments has
been presented only for illustrative and descriptive purposes and is not
intended to be exhaustive or to limit the scope and spirit of the
invention. The embodiments were selected and described to best explain
the principles of the invention and its practical applications. One of
ordinary skill in the art will recognize that many variations can be made
to the invention disclosed in this specification without departing from
the scope and spirit of the invention.