Personal Health Record System (PHRS)

3y ago
18 Views
3 Downloads
1.06 MB
46 Pages
Last View : 16d ago
Last Download : 2m ago
Upload by : Madison Stoltz
Transcription

Personal HealthRecord System (PHRS)Info 620Fall, 2009Dr. SongSam ChenkinChris GraboskyJohn Misczak

Info 620 :: Term PaperPersonal Health Record System (PHRS)ContentsIntroduction . 4Overview . 5The Problem Statement . 5Goals . 5Context & Importance . 5Scope. 5Requirements . 6Functional Requirements . 6Data Requirements . 6Business Rules and Logic. 6Non-Functional Requirements . 7Hardware & Software . 7Assumptions . 7Use Case Model . 8Actors and Their Goals . 8Use case diagram . 9Use case description . 10Update Emergency Info on Server (John) . 10View Emergency Medical Info (Sam) . 12Read Records from Device (Chris) . 14Activity diagrams . 17Update Emergency Info on Server (John) . 17View Emergency Medical Info (Sam) . 18Read Records from Device (Chris) . 19Discussion. 20Class Model . 22TCM table . 22Class diagram . 23Class Definitions . 23Association Definitions. 24Discussion. 24System Design . 26System Sequence Diagrams . 26Update Emergency Info on Server (John) . 26View Emergency Medical Info (Sam) . 27Read Records from Device (Chris) . 28Full Sequence Diagrams . 29Update Emergency Info on Server (John) . 29View Emergency Medical Info (Sam) . 30Read Records from Device (Chris) . 31Design Class Diagram . 32Validation & Discussion. 33Sequence Diagrams. 33Design Class Diagram . 34May 3, 2011 :: Version 1.0 (Draft)P a g e 2

Info 620 :: Term PaperPersonal Health Record System (PHRS)Summary . 35Physical Design . 37ERD . 37Database Schema . 38Validation & Discussion. 38Entity Relationship Diagram . 38Physical Database Diagram . 39Evaluation of Analysis & Design . 40Summary and Lessons learned . 42John’s Experience . 42Sam’s Experience . 43Chris’ Experience . 44Bibliography . 45Appendix . 46Division of the work among team members. 46May 3, 2011 :: Version 1.0 (Draft)P a g e 3

Info 620 :: Term PaperPersonal Health Record System (PHRS)IntroductionWith the growing complexity of health care options in the United States, it is becoming clear that a newway of handling patient records is needed. In the current model, most records are stored on paper. Thismeans that the records are hard and expensive to move to new care facilities and the records areultimately controlled by the health care facilities rather than the patients. To resolve this, there needs tobe a mechanism to digitize these records and return control to the patient.This problem is very complex and has many possible solutions. Our team has decided to peruse onespecific aspect of the electronic health care system: returning control to the patient. In the systemdeveloped and described in this document, the team has outlined the steps needed and, using UML,described the process to make a system that allows record portability.Records are still stored at each health care facility in their health record systems. However a copy isstored on a portable device a patient can carry. This device is fully encrypted but will allow healthinstitutions to import any or all records into their systems securely.The need being met by the team's system is not for urgent care facilities but instead meant for when apatient switches primary physicians or sees a new specialist. In these situations, all old records can beread and imported with ease. However urgent care facilities do play a role with the device. In the eventof an emergency, a hospital can look at a small portion of records stored on the device. These includeemergency contact information, family history, allergies, prescriptions, and preexisting conditions. Thisinformation will prove vital in saving lives while still maintaining some level of privacy for all otherrecords.To outline all aspects of the system potential use cases were developed and diagrammed. These werefurther expanded with high level and detailed use case descriptions. These early tasks allowed the teamto outline how users would interact with the system. In doing so, all actors were identified early into thedevelopment process.The next step was to develop class diagrams. This was done with both the TCM approach as well as aniterative approach. TCM allowed the team to immediately identify potential classes and remove othersfrom scope. Then for each class's interaction, diagrams were made and modified until the final classdiagram was made. Class diagrams allowed for system sequence diagrams, more detailed systemdiagrams, and state diagrams.May 3, 2011 :: Version 1.0 (Draft)P a g e 4

Info 620 :: Term PaperPersonal Health Record System (PHRS)OverviewThe Problem StatementThe United States health care providers currently lack a universal and efficient way to transfer andsynchronize records. While multiple proprietary systems and formats currently exist, the lack of onecommon format or the ability to reliably and securely transfer information between institutions, as wellas the ability for a patient to digitally carry his/her own records, leads to confusion or delays. Thesecomplications limit access to critical patient health information and can have detrimental effects onpatients.GoalsThe goal of the Personal Health Record System (PHRS) is to simplify and modernize the way thatindividuals and medical establishments manage health data. Such a revision in the way thathealth information is created, updated, and shared will help to improve the efficiency of thehealth care industry, saving both time and money for all parties involved. PHRS hopes to offer aunified common interface to health care providers and patients without forcing each party tooverhaul their existing digital patient management systems and methodologies.Context & ImportanceThe current healthcare industry has several different types of systems for managing patient andhealth data, ranging from traditional paper-and-pencil methods to electronic record keeping.However, few of these systems are interoperable, and all consider the records to be the propertyof the maintaining intuition rather than the patient. The Personal Health Record System solutionwill put health records back in the hands of the patient and allow for improved communicationand flexibility between previously disengaged parties.ScopeIn-ScopeThe PHRS will allow for information relevant to and carried by a particular patient to besynchronized with a doctor’s or hospital’s existing patient management system. The system willprovide for secure transmission of information up to the system’s endpoints at the applicationlevel. PHRS offers a reliable and safe interchange of patient information regardless of whichdigital patient record tracking system the endpoints employ.Out-ScopeThe system will not be concerned with the network used for transmitting patient and healthinformation from system endpoint to system endpoint. Moreover, PHRS will not replace adoctor’s or hospital’s existing patient management system, billing system, or other systems usedto interact with insurance providers and other medical institutions.The system will not maintain a proprietary format for storing patient data. It will instead use aninternationally recognized standard. The system is not concerned with the specific format forMay 3, 2011 :: Version 1.0 (Draft)P a g e 5

Info 620 :: Term PaperPersonal Health Record System (PHRS)storing data; it is format agnostic. Instead, PHRS provides a method for exchanging andprotecting standardized records.The system shall now attempt to ascertain the validating of a participating medical facility. Thisverification will be accomplished outside of the system.RequirementsFunctional Requirements The system shall maintain basic patient information and permissions on a central server The system shall allow patients to create new accounts The system shall allow users to store critical information such as allergies and conditionson a central server The system shall allow certified emergency medical facilities to access critical informationsuch as allergies and conditions as needed The system shall maintain full patient medical records in an encrypted format on apatient’s personal storage device The system shall provide a common API for health information systems to update andread records The system shall allow patients to specify entities with permission to access their data The system shall allow approved certified health providers to append information to theencrypted storage device The system shall allow patients to view all records stored on the device The system shall allow patients to update basic and insurance information on the device The system shall allow patients to access real-time access logs via a web browserData Requirements Patient Contact Information Patient Global Unique Identifier for use in external medical records systems Patient Emergency Information Patient Insurance Information Patient Billing Information Patient Medical Records Patient Medical Records Permissions Encryption Keys Patient Medical Record Access RecordsBusiness Rules and Logic Each personal device has one patient’s information on it – that of the owner Only the patient may edit contact information, billing information, and insuranceinformation Only certified medical facilities may append medical records to the device A specific system station “checkpoint” at a doctor’s office or hospital can only interfacewith one personal device at a time. The office or hospital can have multiple system checkpoints in order to interface withmultiple patients’ devices concurrently. Medical records are only appended, never modified.May 3, 2011 :: Version 1.0 (Draft)P a g e 6

Info 620 :: Term PaperPersonal Health Record System (PHRS)Non-Functional RequirementsPatients Can Update personal information on their device through a screen-based softwareapplication installed on their computers which communicates to the device over USBHealth Care Providers Can Access the system through a screen-based software application The patient health information systems used by health care providers will inform thePHRS system of changes to patient records via a common published API. If PHRS is failing, the current patient management system must be unaffected If the health care institution’s patient management system us failing, PHRS must beunaffected Encryption is employed on all files, transfer links, and backupsHardware & SoftwareSoftware: Hospital/Doctor’s Office/MedicalEstablishmento Proprietary software system forpatient management systemo Key plugin/module that tiespatient management system toPHRSo PHRS softwareo Windows XP/Vista/7 or Mac OSX 10.5-10.6 for personalcomputers inside establishmentPatiento Windows XP/Vista/7 or Mac OSX 10.5-10.6 for home computero PHRS software to allow homesynchronizationHardware: Hospital/Doctor’s Office/MedicalEstablishmento Existing computers and serversthat run patient managementsystemo Endpoint stations that interfacewith personal patient devicesPatiento Handheld device that interfacesvia USB to computer or stationAssumptions Existing patient management systems will implement the PHRS API.Doctor’s offices, hospitals, and other medical establishments will limit access to the devices andstations that interface with the PHRS, and will not allow unsupervised access to said devices.All data, forms, records, and other information used by medical establishments will beformatted according to health industry standardsMay 3, 2011 :: Version 1.0 (Draft)P a g e 7

Info 620 :: Term PaperPersonal Health Record System (PHRS)Use Case ModelActors and Their GoalsActorGoalPatient Manage Personal Account Manage data on Device Manage Permissions Manage Personal Emergency InfoEmergency Medical View emergency medical information of a patientFacility EmployeeNon-Emergency Medical Initiate sync with in house medical records systemFacility EmployeeInHouse HIS Interact with health information deviceMay 3, 2011 :: Version 1.0 (Draft)P a g e 8

Info 620 :: Term PaperPersonal Health Record System (PHRS)Use case diagramMay 3, 2011 :: Version 1.0 (Draft)P a g e 9

Info 620 :: Term PaperPersonal Health Record System (PHRS)Use case descriptionUpdate Emergency Info on Server (John)USE CASE #1USE CASE NameUpdate Emergency Info on ServerACTORPatientGoalTo update the patient’s emergency information for view and use by medicalestablishments, doctors, emergency workers, and insurance companies.Overview and scopeShows the process that the patient undertakes in order to update his or heremergency information on the central server. This information is whatemergency workers and medical workers and facilities use in the event of anurgent situation, when the patient is injured or able to speak for him orherself.LevelPrimaryPreconditionsPatient has created an account for use with the Person

digital patient record tracking system the endpoints employ. Out-Scope The system will not be concerned with the network used for transmitting patient and health information from system endpoint to system endpoint. Moreover, PHRS will not replace a doctor’s or hospital’s existing patient management system, billing system, or other systems used

Related Documents:

Title: What’s Really Going On? or PHRs, Platforms, & Consumer Trends Author: John Moore Created Date: 3/19/2009 7:55:33 PM

Keywords Personal health records, eHealth, Barriers, Bias, Disadvantage, Structured review INTRODUCTION There is an increasing focus on personal electronic health records (PHRs) as a part of the implementation of ehealth

2 Motivations for secondary use of clinical data Many “secondary uses” or re‐uses of electronic health record (EHR) data, including (Safran, 2007) – Personal health records (PHRs) – Clinical and translational research –generating hypotheses and

AQIS SPICES User Manual 3 Icons for the Buttons Sr. No. Icon for Button Meaning 1 Save Record 2 New Record 3 Delete Record 4 Search Record 5 Expand 6 List of record 7 Navigation to next record in list 8 Navigation to previous record in list 9 Navigation to next set of records in list 10 Navigation to first set of records in list 11 Navigate to last record

August 2020 8 of 23 5. Student Course Registration EIS Default Name: xxxxreg.asc Where xxxx is the school/division number. Record Type Description H Course Registration Header Record 1 record per file I Identifier Record 1 record per student D Course Detail Record (follows identifier record) 1 record per course

World Records gained with Napier Lion Engine Power 1919 - Height record of 30,000 feet 1929 - Land Speed Record at 231.3 mph 1929 - Air Speed Record at 336.3 mph 1930 - Water Speed Record at 100.13 mph 1931 - Land speed record at 246.1 mph 1932 - Land speed record at 253.9 mph 1933 -Air Long Distance Record at 5,309 miles

Field Fiesta Filreco Fiskana Flair Flash Flecha Flint Flip Folk Dancer Folk Music Inc Folkraft Folkways Fonit Fonotipia . Peerless Peerless Record Pennington Perfect Perfection Record Perla Personal Personal Record Personnal Record . Remington Remington-Morse Reneyphone Republic Resona

Financial Accounting Working Papers, Robert F. Meigs, Jan R. Williams, Sue Haka, Susan F. Haka, Mark S Bettner, Jun 1, 2000, Business & Economics, 400 pages. . Accounting Chapters 1-14 The Basis for Business Decisions, Robert F. Meigs, Jan R. Williams, Sue Haka, Susan F. Haka, Mark S. Bettner, Sep 1, 1998, Business & Economics, . The Study Guide enables the students to measure their progress .