[Solved] SOLVED:Community Patient Portal System (CPPS) Case Study Part 3

CPPS Part 3 Page 1Community Patient Portal System (CPPS) Case Study Part 3Doctors at Community Patient offices are interested in getting access topatient concerns. They envision that patients will be able to access the CPPSfrom mobile devices including smartphone and laptops 24/7 over theinternet. Of course there would have to be some type of secure accessprovided to the web and application server to the new database applicationwith integration to the existing Community Patient system. They also wouldlike patients to electronically self-report data that flows automatically into anEMR note for clinician confirmation or editing, relieving physicians of somedata entry and rote history-gathering tasks. Then clinicians would havemore time to focus on significant issues and patient concerns while alsoincreasing the likelihood that necessary data are gathered and available fordecision-making. They asked their IT consultants to offer several options forsending information to their EMR (electronic medical record) and patientportal applications.Access to medical care is an important concern nation-wide. Due to cuts inreimbursements for clinical services, provider have less time per patient andthus 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 considerseveral integration options and perhaps a prototype of options includingmessaging HL7 (a common medical-based standard), web services, and Java2 Enterprise Edition Connector Architecture (JCA). These are very technicaloptions that are difficult for providers to grasp. So the IT consultants areproviding more detailed information. They suggested a Java-based solutionsince they had little experience with other technologies. They are alsoconsidering an n-tiered architecture as opposed to 2-tier to take advantageof the multi-tier benefits like easier maintainability, updates, patches(software fixes), and greater scalability compared to a 2-tier solution.HL7 OptionThis HL7 interface would enable them to import data into an unsignedprogress note. It primarily is used by transcription services andtelemedicine. By including the Java open source HL7 API (HAPI) in theirapplication, they would be able to place patient-gathered data obtained by aweb-based JSP form into an HL7 message. However HAPI does not haveencryption capability. HAPI uses a low level protocol, MLLP (Minimal LowerLayer protocol used withing the HL7 standard community) and not theinternet protocol. Thus HTTPS is not available to encrypt the transmissions.There are also firewall issues. Also the HL7 interface was not designed foroutbound messages, other than acknowledgements, back to applications.CPPS Part 3 Page 2Web Services OptionAnother solution s might be to use pure web services-based strategy tocreate the web service client application since it handles details like fieldnames, data types, and business rules for the client-side developer who willrely on the details provided by the web service descriptions (WSDL)document. VA web services use plain old java objects, rather than the morecomplex Enterprise Java Beans used by JCA. Web services can provide 2-way encryption using the VA EMR encryption algorithm. Because webservices use internet protocols, web services are firewall-friendly, thusmaking firewall traversal a straightforward process.J2EE connector Architecture (JCA) OptionStill another possibility is the J2EE Connector Architecture (JCA) which is aJava standards-based solution that is scalable, secure, transactional meansto communicate between J2EE applications and legacy systems. It offers 2-way encryption algorithms and can work with different packages. Howevercoding is more complex since it uses Enterprise Java Beans and thedevelopers need to locate field names data types, and appropriate RPCs(remote procedure calls) to assurance compliance with business rules. JCAuses TCP/IP sockets rather than HTTP, so, similar to HL7 messaging, JCA isless firewall-friendly than web services.PrototypeThus they decided to create a prototype the HL7 messaging solution forproof-of-concept prototype since it was easier to code and the interface wasavailable. They used Java Server Pages (JSP) Servlets and Java StandardTag Library (JSTL) using NetBeans IDE (interactive developmentenvironment) then deployed to Tomcat web server. The application sendsform data to the Tomcat web server. The application uses post method aftersuccessful JavaScript form validation. The servlet on the web serverprocesses the data entered by the patient to create a string that is paddedto HAPI. Additional data processed includes patient social security number,gender, date of birth, physician information. A direct socket connection fromTomcat to the EMR HL7 interface was created so thus data is availableimmediately in the progress note. Data can then be corroborated with thepatient and edits made accordingly. They successfully tested the prototype.Patient AuthenticationPatient authentication would be required to ensure the validity of the sourceof the data. Patient portals usually have patients register for a portal duringa face-to-face office visit and thus rely on two-factor authentication forpatient login to the portal. Patient authentication data would need to bestored and accessed in real-time. A workaround if patient authenticationCPPS Part 3 Page 3and credentialing is not available would be to create a single use programwith a globally unique PIN as a session identifier dispersed by the office staffthat would point to the correct patient record and visit in the database for aparticular appointment. This could be available for like 30 minutes and coulduse pointers to the patient visit data of interest. However some facilitiesmay not have sufficient staff to add this task to their responsibilities.Some organizations might use dynamic IP addressing to adjust to changes inthe network and client configuration. For these organizations it would benecessary to communicate between two computers with fixed IP addresses(servers) in order to guarantee message delivery. They could use astandalone Java Swing application (client-server) with the client on a laptop.Later iterations could be web-based and run from a Tomcat server deployedlocally on a laptop. However with this configuration of using a laptop ortable to gather data from patients without an intervening server as sender,dynamic routing of network traffic means that message delivery cannot beguaranteed.The local HL7 interface does not have the capability to handle dynamicrouting, thus the web server needs a fixed IP address. If traversing afirewall is necessary they may need to combine web services with HL7messaging or with JCA. Using a Java web-based application enablesmigration to a patient portal. Pre-visit check-in and data gathering couldoccur in the patients home prior to the visit. Thus patients can be moreactive partners and more involved in their care.They decided to evaluate the application feasibility, usability, andacceptability of these options from both the patient and providerperspectives. They would also gather additional data to use in future studieson the impact on patient care.Any healthcare organization that wants to send patient self-reported datainto an EMR may struggle with similar issues. Also, the existence of an HL7interface does not necessarily guarantee the presence of all necessaryfunctionality in that interface. Use of complex or non-standard data typesmay limit integration options.1.1 Make a listof the equipment that will be required for this new system. Estimate the cost of the equipment. You maywant to use a 3 column table withheadings Location, Equipment, and Cost.1.2Describe any special software that may be needed. The software engineer isdeveloping the application software but no special software is required for connecting the devices or communicationsbetween them.1.3 Develop anetwork diagram showing how all the equipment will be connected. Identify Internet connections,VPNs, and telephony links as appropriate.2. Create astoryboard and dialog based on the use case Make an Appointment. 2.1 Review thediscussion and your solutions for the use case Make an Appointment.

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