Community Patient Portal System (CPPS) Case Study Part 3

CPPS Part 3 Page 1
Community Patient Portal System (CPPS) Case Study Part 3
Doctors at Community Patient offices are interested in getting access to
patient concerns. They envision that patients will be able to access the CPPS
from mobile devices including smartphone and laptops 24/7 over the
internet. Of course there would have to be some type of secure access
provided to the web and application server to the new database application
with integration to the existing Community Patient system. They also would
like patients to electronically self-report data that flows automatically into an
EMR note for clinician confirmation or editing, relieving physicians of some
data entry and rote history-gathering tasks. Then clinicians would have
more time to focus on significant issues and patient concerns while also
increasing the likelihood that necessary data are gathered and available for
decision-making. They asked their IT consultants to offer several options for
sending information to their EMR (electronic medical record) and patient
portal applications.
Access to medical care is an important concern nation-wide. Due to cuts in
reimbursements for clinical services, provider have less time per patient and
thus in office visits are shorter. Reporting mandates have increased also.
Thus the PPCS would be helpful in providing some alternatives.
The IT consultants are recommending that Community Patient consider
several integration options and perhaps a prototype of options including
messaging HL7 (a common medical-based standard), web services, and Java
2 Enterprise Edition Connector Architecture (JCA). These are very technical
options that are difficult for providers to grasp. So the IT consultants are
providing more detailed information. They suggested a Java-based solution
since they had little experience with other technologies. They are also
considering an n-tiered architecture as opposed to 2-tier to take advantage
of the multi-tier benefits like easier maintainability, updates, patches
(software fixes), and greater scalability compared to a 2-tier solution.
HL7 Option
This HL7 interface would enable them to import data into an unsigned
progress note. It primarily is used by transcription services and
telemedicine. By including the Java open source HL7 API (HAPI) in their
application, they would be able to place patient-gathered data obtained by a
web-based JSP form into an HL7 message. However HAPI does not have
encryption capability. HAPI uses a low level protocol, MLLP (Minimal Lower
Layer protocol used withing the HL7 standard community) and not the
internet protocol. Thus HTTPS is not available to encrypt the transmissions.
There are also firewall issues. Also the HL7 interface was not designed for
outbound messages, other than acknowledgements, back to applications.
CPPS Part 3 Page 2
Web Services Option
Another solution s might be to use pure web services-based strategy to
create the web service client application since it handles details like field
names, data types, and business rules for the client-side developer who will
rely on the details provided by the web service descriptions (WSDL)
document. VA web services use plain old java objects, rather than the more
complex Enterprise Java Beans used by JCA. Web services can provide 2-
way encryption using the VA EMR encryption algorithm. Because web
services use internet protocols, web services are firewall-friendly, thus
making firewall traversal a straightforward process.
J2EE connector Architecture (JCA) Option
Still another possibility is the J2EE Connector Architecture (JCA) which is a
Java standards-based solution that is scalable, secure, transactional means
to communicate between J2EE applications and legacy systems. It offers 2-
way encryption algorithms and can work with different packages. However
coding is more complex since it uses Enterprise Java Beans and the
developer’s need to locate field names data types, and appropriate RPC’s
(remote procedure calls) to assurance compliance with business rules. JCA
uses TCP/IP sockets rather than HTTP, so, similar to HL7 messaging, JCA is
less firewall-friendly than web services.
Prototype
Thus they decided to create a prototype the HL7 messaging solution for
proof-of-concept prototype since it was easier to code and the interface was
available. They used Java Server Pages (JSP) Servlets and Java Standard
Tag Library (JSTL) using NetBeans IDE (interactive development
environment) then deployed to Tomcat web server. The application sends
form data to the Tomcat web server. The application uses post method after
successful JavaScript form validation. The servlet on the web server
processes the data entered by the patient to create a string that is padded
to HAPI. Additional data processed includes patient social security number,
gender, date of birth, physician information. A direct socket connection from
Tomcat to the EMR HL7 interface was created so thus data is available
immediately in the progress note. Data can then be corroborated with the
patient and edits made accordingly. They successfully tested the prototype.
Patient Authentication
Patient authentication would be required to ensure the validity of the source
of the data. Patient portals usually have patients register for a portal during
a face-to-face office visit and thus rely on two-factor authentication for
patient login to the portal. Patient authentication data would need to be
stored and accessed in real-time. A workaround if patient authentication
CPPS Part 3 Page 3
and credentialing is not available would be to create a single use program
with a globally unique PIN as a session identifier dispersed by the office staff
that would point to the correct patient record and visit in the database for a
particular appointment. This could be available for like 30 minutes and could
use pointers to the patient visit data of interest. However some facilities
may not have sufficient staff to add this task to their responsibilities.
Some organizations might use dynamic IP addressing to adjust to changes in
the network and client configuration. For these organizations it would be
necessary to communicate between two computers with fixed IP addresses
(servers) in order to guarantee message delivery. They could use a
standalone Java Swing application (client-server) with the client on a laptop.
Later iterations could be web-based and run from a Tomcat server deployed
locally on a laptop. However with this configuration of using a laptop or
table to gather data from patients without an intervening server as sender,
dynamic routing of network traffic means that message delivery cannot be
guaranteed.
The local HL7 interface does not have the capability to handle dynamic
routing, thus the web server needs a fixed IP address. If traversing a
firewall is necessary they may need to combine web services with HL7
messaging or with JCA. Using a Java web-based application enables
migration to a patient portal. Pre-visit check-in and data gathering could
occur in the patient’s home prior to the visit. Thus patients can be more
active partners and more involved in their care.
They decided to evaluate the application feasibility, usability, and
acceptability of these options from both the patient and provider
perspectives. They would also gather additional data to use in future studies
on the impact on patient care.
Any healthcare organization that wants to send patient self-reported data
into an EMR may struggle with similar issues. Also, the existence of an HL7
interface does not necessarily guarantee the presence of all necessary
functionality in that interface. Use of complex or non-standard data types
may limit integration options.
1.1 Make a list
of the equipment that will be required for this new system. Estimate the cost of the equipment. You may
want to use a 3 column table with
headings Location, Equipment, and Cost.
1.2
Describe any special software that may be needed. The software engineer is
developing the application software but no special software is required for connecting the devices or communications
between them.
1.3 Develop a
network diagram showing how all the equipment will be connected. Identify Internet connections,
VPNs, and telephony links as appropriate.
2. Create a
storyboard and dialog based on the use case "Make an Appointment". 2.1 Review the
discussion and your solutions for the use case "Make an Appointment".







2.2 Use a
presentation tool like PowerPoint to create a storyboard and dialog to support the use case. You would use
the storyboard to explain the use case to users of the application. You can put
the dialog text in the PowerPoint file
in the notes section or include it in a separate Word file.