rjholland2016.files.wordpress.com · web viewthe goal of myhealthcomplete is to provide a...

MyHealthComplete

My Health CompleteAn Electronic Medical Record Storage Solution

Debbie DobrilovicRyan GonzalesRyan Holland

Amala Priyanka ThummaBryan Welsh

Issue: 1.0 Date: 11/26/2014

ID: MHC Page: 1 of 58

MyHealthComplete

Draft Release 1.01. Introduction 4

1.1 Purpose and Scope 4 1.2 Overview 5 1.3 Revision History 5

1.3.1 Issue 1.0, Working Draft 5 1.4 Glossary of Terms 6 1.5 Document Language 7

2. MyHealthComplete 8 2.1 Background and Feature Description 8 2.2 Context of the MHC User Functions 9 2.3 MHC UI 10

3. MHC Use Case Scenarios 13 3.1 Universal User Functionality 13

3.1.1 Managing Preferences 13 3.2 Personal and Insurance User Functionality 14

3.2.1 Login 14 3.2.2 Unlock Locked-Out Account 16

3.3 Personal User Functionality 19 3.3.1 Request Provider Connection 19 3.3.2 Revoke Provide Access 21 3.3.3 View Files 22 3.3.4 Append File 23 3.3.5 Print File 25

3.4 Medical User Functionality 26 3.4.1 Medical User Enters Credentials – Successful 26 3.4.2 Medical User Credentials – Failed 27 3.4.3 Medical User Scans Thumb – Successful 28 3.4.4 Medical User Scans Thumb – Failed 30 3.4.5 Unlock Locked-Out Account 32 3.4.6 View File 34 3.4.7 Edit File 36 3.4.8 Print File 38

3.5 Insurance User Functionality 40 3.5.1 View File 40 3.5.2 Edit File 42

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.5.3 Print File 44

4. Enumerated MHC Requirements 46 4.1 Universal User Functions 46 4.2 Personal and Insurance User Functions 49 4.3 Personal User Functions 49 4.4 Medical User Functions 50 4.5 Security 51 4.6 Error Handling 52 4.7 Operations, Administration and Maintenance 53 4.8 Performance, Resource and Reliability Requirements 54

5. Open Issues 566. Future Considerations 567. Acknowledgments 56

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

1 Introduction

1.1 Purpose and ScopeOn average, medical providers retain patient records for three years and insurance

claims are only accessible online for two years. Medical patients require access to their records throughout their lifetime, for various personal reasons. There are also some valid reasons for maintaining records beyond the patient’s death, such as establishing family histories for their descendants in the case of genetic diseases.

Currently, a patient’s medical history resides in many separate locations with different entities controlling the information. Some information resides with the patient’s medical provider, some at their insurance company, and some in their own files and records. It isn’t even necessarily all paper or all digital. This results in a decentralized medical history, which does not lend itself to easy consolidation when the big picture is needed, such as upon completion of a new patient history record each doctor visit.

The goal of MyHealthComplete is to provide a secured, comprehensive, and centralized electronic database for maintaining patient’s medical history and billing information. This system will retain all pertinent medical information and corresponding financial records in a single, easy-to-navigate, web-based application. The application will be accessible by the patient and any healthcare or insurance providers to whom the patient has authorized access. The patient will also have a consolidated record of their personal medical history which they can append, update, and share with their healthcare providers for additional input. By integrating the patient’s record with the records from the healthcare and insurance providers, a complete and thorough patient history will be available to access with ease at any time from any network connected device. The record will belong to the patient, solving current retention issues, aid with portability concerns, and allow for the collection of all the dispersed pieces into one centralized location.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

1.2 OverviewThis solution is being built for the State of Ohio as a service for its residents. The

state’s internal objective is to provide a secured, comprehensive, and centralized electronic database for maintaining their residents’ medical histories and associated billing and claim information. My Health Complete will also serve as a service for claim, billing and information submissions from insurance companies and healthcare providers, and be secure in order to maintain confidentiality and protect the sensitive contents while supporting patients’ rights to access their medical information.

Major stakeholders are Ohio residents (the patients), doctors, hospitals, insurance companies, and other healthcare providers, such as labs, outpatient facilities, nursing homes and ambulance services.

Competitors include other businesses offering similar, although less comprehensive services, such as CliniSync and Microsoft HealthVault.

1.3 Revision HistoryThis section provides a history of changes to this document. All modification requests (MR) against this document should be included in the table below.

Version Date Reason for Change / MR Changed by

0.1 11/02/2014 Initial Document Everyone

0.5 11/15/2014 Post Review Revisions and Updates Everyone

1.0 11/26/2014 Finalization of Document RH, DD, APT

1.3.1 Issue 1.0, Final Document

Issue 0.1, dated 11/02/2014, is the initial draft of this document. It is an incomplete draft for MHC internal review purposes only.Issue 0.5 dated 11/15/2014, is the second draft of this document. It is the result of minor revisions suggested after our review period.Issue 1.0 dated 11/26/2014, is the document after minor revisions to the document. It is a complete document after the internal revision.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

1.4 Glossary of TermsThis section provides a glossary of terms used in this document. It is not meant to be a glossary of all relevant terms used in the product.

Acronym Definition

CDA Clinical Document Architecture

MD5 Message Digest Algorithm 5

EMR Electronic Medical Record

HIPAA Health Insurance Portability and Accountability Act of 1996

HL7 Health Level International 7

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

IP IP Address

IU Insurance User

MAC Address Media Access Control Address

MHC MyHealthComplete

MU Medical User

PU Personal User

TCP Transmission Control Protocol

UA User Authentication

UI User InterfaceTable 1. List of acronyms and their meaning

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

1.5 Document LanguageSpecific language is used in this document to denote whether a statement is informative, required, or has a specific meaning. The following words have these connotations when used to describe actions or items:

shall The use of the term “shall” in this document is intended to precede a required statement. Compliance with “shall” must be demonstrated during design review and system acceptance testing.

is,will,should

Use of the terms “is,” “will,” or “should” in this document is intended to identify guidance or preference. Statements annotated in this manner are to be treated as informative or preference, but not required. Statements following the words “is,” “will,” or “should” are not a mandatory deliverable for the final MHC system.

Lock-out The term “lock-out” refers to the status of an account which has failed to login three consecutive times or properly scan their thumb five consecutive times. An account flagged as “locked-out” is unable to login, even with proper credentials or thumbscan, until they have completed the steps required to unlock their account.

Light, Medium, and Heavy Loads

Use of the terms “light load,” “medium load,” or “heavy load” in this document is intended to identify a quantitative measure of the number of active MHC users at a given point in time. A light load shall be considered any number of concurrent users below 20% of the maximum allowed concurrent users. A medium load shall be considered any number of concurrent users above 20%, and below 60% of the maximum allowed concurrent users. A heavy load shall be considered any number of concurrent users above 60% and at or below 100% of the maximum allowed concurrent users.

Personal,Medical,and InsuranceUsers

Use of the terms “Personal User,” “Medical User,” or “Insurance User” in this document is intended to identify a specific mode of user access. Each user type has its own restrictions on what they can access and modify.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

File list and Patient list

Use of the terms “File list,” or “Patient list” in this document refers to a graphical list display of the files associated with a given user, or to a graphical list display of the patients associated with a medical user.

Table 2. Language Key

2 MyHealthComplete

2.1 Background and Feature DescriptionMyHealthComplete is designed to provide a secured, consolidated, electronic database to the State of Ohio for centralizing and maintaining comprehensive medical histories for the residents of Ohio.

MyHealthComplete will:● Offer an easy-to-navigate web-based application for maintaining medical histories

for Ohio residents.● Provide Ohio residents with a personal user account for their medical records.● allow personal users to authorize medical and insurance providers role-based

access to their medical records.● Securely receive, transmit and store EMRs from the authorized medical providers

for the corresponding personal user account.

Figure 1 illustrates:● Personal users accessing MHC to view, modify, and print their personal medical

histories.● Authorized medical users accessing MHC to view, modify, and print patient

medical records.● Insurance providers accessing MHC to view and edit insurance claim records.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 2.1.1 MyHealthComplete Interactions

2.2 Context of MHC User FunctionsMHC user functions include:

● Modifying preferences, which updates the MHC Subscriber Database.● Granting access, which updates the MHC Subscriber Database.● Viewing files, which reads from the MHC File Database.● Editing records, which updates the MHC File Database.● Printing records, as viewed from the MHC File Database.

Figure 2 illustrates the data flow throughout the various MHC user functions.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 2.2.1 MHC User Functions

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

2.3 MHC UI

Figure 2.3.1 Illustrates the login page for MHC where a user enters their credentials.

Figure 2.3.1 MHC Login Page

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 2.3.2 Illustrates the post-login landing screen for a personal user.

Figure 2.3.2 Personal User Home PageFigure 2.3.3 Illustrates the post-login landing screen for a medical or insurance user.

Figure 2.3.3 Medical/Insurance User Home Page

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 2.3.4 Illustrates the pop-up menu which appears when a user right-clicks.

Figure 2.3.4 Pop-up Menu Mock-up

Figure 2.3.5 Illustrates the preferences menu.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 2.3.5 Preferences Menu Mock-up

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3 MHC Use Case Scenarios

3.1 Universal User FunctionalityAny authorized user can invoke the following functionality in MHC:

3.1.1 Managing preferencesFigure 3.1.1a illustrates an authorized user modifying their preference selections for the following:

i. Lock-out authorization method.ii. List of authorized users.

iii. Current password,Figure 3.1.1b provides a schematic illustration of the procedures for modifying preferences.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.2 Personal and Insurance User FunctionalityAny authorized personal or insurance user can invoke the following functionality in MHC:

3.2.1 Login - SuccessfulA personal or insurance user enters their login credentials, username and password. It is then verified against the MHC Subscriber Database and a login token is set for that device. Figure 3.2.1a illustrates a personal or insurance user becoming a verified user and logging in due to submitting their correct user information.Figure 3.2.1b provides a schematic illustration of the procedures for becoming a verified user and logging in.

Login - FailedIf the login credentials are found unverifiable, the UA server will allow the user to attempt logging in two more times before locking out the account. Figure 3.2.1c provides a schematic illustration of the procedures for a failed login attempt.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 3.2.1a Personal or Insurance User Login Scenario

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 3.2.1b Personal or Insurance User Successful Login Procedures

Figure 3.2.1c Personal or Insurance User Failed Login Procedures

3.2.2 Unlock Locked-Out AccountA personal user or insurance user is prompted to enter a lock-out code sent, via their personal preference, by the MHC UA server. The user will then input the code which is verified by the MHC UA server. The user then inputs their new password. This input is verified, the user’s record is updated, and then a user session is created.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 3.2.2a illustrates a user unlocking their account using the unique code sent to them by MHC.Figure 3.2.2b provides a schematic illustration of the procedures for unlocking a previously locked account.

Figure 3.2.2a Locked-out Personal or Insurance User Account Unlock Scenario

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.2.2b Locked-out Personal or Insurance User Account Unlock Procedures

a. The user enters their login credentials, username and password.b. The Client Device sends the credentials to the MHC UA Server.c. The MHC UA Server verifies the credentials.d. The MHC Subscriber Database returns a locked account.e. The MHC UA Server sends the user a verification code via their chosen method.f. The user inputs the code upon receipt.g. The Client Device sends the lock-out code to the UA Server.h. The MHC UA Server verifies the code.i. The MHC Subscriber Database returns a valid verification code.j. The MHC UA Server requests a new password for the user’s account.k. The user inputs a new password.l. The Client Device sends the password and image to the UA Server.m. The MHC UA server verifies the password and image.n. The MHC Subscriber Database returns valid credentials.o. The MHC UA Server updates the user’s information.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

p. The user is logged in.3.3 Personal User FunctionalityAny authorized personal user can invoke the following functionality in MHC:

3.3.1 Request Provider ConnectionA verified personal user requests to establish a provider connection with a verified medical or insurance user. The verified medical or insurance user accepts the connection request and is added as an authorized provider connected to the personal user account in MHC.Figure 3.3.1a illustrates a verified user sending a request for a specific, verified medical or insurance user to access their account files.Figure 3.3.1b provides a schematic illustration of the procedures for requesting a providers connection.

Figure 3.3.1a Verified Personal User Requesting Provider Connection Scenario

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 3.3.1b Verified Personal User Requesting Provider Connection Procedures

a. The verified PU sends a connection request to MU/IU.b. The client sends the request to the MHC Mail Server.c. The MHC mail server delivers the request to the provider.d. The provider replies to the PU accepting the request.e. The provider is added as an authorized provider for the PU account in the MHC Subscriber database.f. The MHC Mail Server delivers the provider’s response to the PU.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.3.2 Revoke Provider AccessA verified personal user revokes a verified medical or insurance user authorized provider access. This function could occur when changing medical or insurance providers, or when a patient’s procedures are finished. MHC notifies the medical or insurance user of the disconnection and deletes the record from the MHC Subscriber Database record connecting them to the personal user’s account. Figure 3.3.2a illustrates a verified user revoking an authorized medical or insurance user’s access to their account files.Figure 3.3.2b provides a schematic illustration of the procedures for revoking provider access

Figure 3.3.2a Verified Personal User Revokes Provider Access Scenario

Figure 3.3.2b Verified Personal User Revokes Provider Access Procedures

a. The verified PU revokes the MU/IU connection access to the PU’s account.b. The provider is deleted from the list of authorized providers connected to the PU account.c. The client devices sends a notice of revocation to the MHC Mail Server.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

d. The MHC mail server delivers the notice of revocation to the provider.

3.3.3 View filesA verified user selects a file to display by double-clicking or right clicking and selecting view. The file is then displayed in a read-only format.Figure 3.3.3a illustrates a verified personal user opening a file to view it without modifying its contents.Figure 3.3.3b provides a schematic illustration of the procedures for viewing a file.

Figure 3.3.3a A Verified PU Viewing a File Scenario

Figure 3.3.3b Verified PU File Viewing Procedures

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.3.4 Append FileA verified personal user selects their file to edit by right-clicking and selecting edit. The MHC File Server will check the user and file permissions and display the editable sections of the file. The user can then append comments or additional data which are saved as made, updating the file in the database. Figure 3.3.4a illustrates a verified personal user opening a file and appending its contents based on their permissions.Figure 3.3.4b provides a schematic illustration of the procedures for a verified personal user to append a file.

Figure 3.3.4a A Verified PU Appending a File Scenario

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 3.3.4b Verified Personal User Appends File Procedures

a. The user right clicks to select their editable file.b. The MHC File Server requests the editable file.c. The MHC File Server checks both the user and files permissions.d. The MHC File Database returns the editable file.e. The MHC File Server displays the editable selections of the file.f. The user can then append the file and save it.g. The MHC File Server receives the edits.h. The MHC File Database then updates the file accordingly.i. The user can close the file window.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.3.5 Print FileA verified personal user selects a file to print by right clicking the file, then selecting print from the pop-up context menu. The file will then be displayed as read only at which point the user can choose to print the file.Figure 3.3.5a illustrates a verified user printing a file.Figure 3.3.5b provides a schematic illustration of the procedures for printing a file.

Figure 3.3.5a A Verified Personal User printing a file scenario.

Figure 3.3.5b Procedures for a Personal User to Print a File

a. The verified personal user selects the file they want to print.b. The MHC File Server requests the selected file.c. The MHC File Server checks the user and file permissions.d. The MHC File Database returns the selected file.e. The MHC File Server sends the returned file to the client device.f. The user sends a print order to the printer.g. The printer system prints the file.h. The user can close the file.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.4 Medical User FunctionalityAny authorized personal user can invoke the following functionality in MHC:

3.4.1 Medical User Enters Credentials - SuccessfulA medical user enters their login credentials, username and password. It is then verified against the MHC Subscriber Database and a thumbscan is requested. This flags the user as partially authenticated, meaning they’ve completed the first of two authentication procedures.Figure 3.4.1a illustrates a medical user entering in their login credentials to be verified.Figure 3.4.1b provides a schematic illustration of the procedures for entering credentials.

Figure 3.4.1a Medical User Enters Login Credentials Scenario

Figure 3.4.1b Procedures for a Medical User to Enter Their Login Credentials

a. A medical user enters the login credentials, username and password.b. Client device transmits the entered credentials to the MHC UA server.c. The MHC UA server then checks whether or not the credentials are valid via the MHC Subscriber

Database.d. The MHC Subscriber Database returns valid credentials.e. The MHC UA server sends request for thumbscan to the client device.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.4.2 Medical User Credentials - FailedA medical user enters their login credentials, username and password. It is then checked and found unverified. The MHC UA Server will allow them to try entering their credentials two more times before it locks them out.Figure 3.4.2a illustrates a medical user enters incorrect login credentials.Figure 3.4.2b provides a schematic illustration of the procedures for failing to enter legitimate login credentials.

Figure 3.4.2a A medical user failing to login scenario

Figure 3.4.2b Procedures for Medical User Failed Login Credentials

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.4.3 Medical User Scans Thumb - SuccessfulThe partially-authenticated medical user places their thumb on the scanner. The newly made image is verified, a login token is set, and the user’s personal user list is displayed.Figure 3.4.3a illustrates a partially-authenticated medical user scanning their thumb.Figure 3.4.3b provides a schematic illustration of the procedures for scanning a thumb.

Figure 3.4.3a Medical User Scans Thumb for Login Scenario

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 3.4.3b Procedures for Medical User Scanning Thumb for Login

a. The partially-authenticated medical user scans their thumb print.b. The client device transfers the image to the MHC UA Server.c. The MHC UA Server verifies the image.d. The MHC Subscriber Database returns an invalid thumbprint.e. MHC UA server itself sets the login token.f. The MHC UA server fetches permissions from MHC Subscriber Database.g. MHC Subscriber Database grants the user permissions.h. The MHC UA Server sets the user permissions.i. MHC UA server creates a user session.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.4.4 Medical User Scans Thumb - FailedA partially-authenticated medical user places their thumb on the scanner. The newly made image is checked and found unverified. The MHC UA server will allow them to try four more times before locking out their account.Figure 3.4.4a illustrates a partially-authenticated medical user fails to properly scan their thumbprint.Figure 3.4.4b provides a schematic illustration of the procedures for failing to properly scan a thumb.

Figure 3.4.4a A Medical User fails the Thumbscan Scenario

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.4.4b Procedures for Medical User Failed Thumbscan

a. The user scans their thumb print.b. The Client Device transfers the image to the MHC UA Server.c. The MHC UA Server verifies the image.d. The MHC Subscriber Database returns an invalid thumbprint.e. The MHC UA Server will request the user re-enter their credentials and repeat the above process four more

times, five total.f. After five invalid thumb print scans the MHC UA Server locks-out the account.g. The MHC UA Server displays instructions regarding unlocking procedures for the user.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.4.5 Unlock Locked-Out AccountAfter having failed to login three times or scan their thumb five times, a medical user will be prompted to enter a lock-out code sent via their personal preference by the MHC UA server. The user will then input the code which is verified by the MHC UA server. The user then inputs their new password and scans their thumb. This input is verified, the user’s record is updated, and then their patient list is displayed.Figure 3.4.5a illustrates a medical user unlocking their account by entering a unique code sent to them by MHC.Figure 3.4.5b provides a schematic illustration of the procedures for unlocking a locked-out account.

Figure 3.4.5a A Medical User Unlocking Their Account Scenario.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 3.4.5b Procedures for a Medical User to Unlock Their Account

a. The user enters their login credentials, username and password.b. The Client Device sends the credentials to the MHC UA Server.c. The MHC UA Server verifies the credentials.d. The MHC Subscriber Database returns a locked account.e. The MHC UA Server sends the user a verification code via their chosen method.f. The user inputs the code upon receipt.g. The Client Devices sends the lock-out code to the UA Server.h. The UA Server verifies the code.i. The MHC Subscriber Database returns a valid verification code.j. The UA Server requests a new password for the user’s account.k. The user inputs a new password.l. The user scans their thumb.m. The Client Device sends the password and image to the UA Server.n. The UA server verifies the password and image.o. The MHC Subscriber Database returns valid credentials.p. The MHC UA Server updates the user’s information.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

q. The user is logged in and shown their patient list.

3.4.6 View FileA verified medical user double-clicks or right clicks on the patient file and selects view from the pop-up context menu. The MHC file server returns the files from the MHC file database for the selected patient. The medical user right clicks on the desired file record and selects view from the pop-up context menu. The requested file record is then displayed in a read-only format.Figure 3.4.6a illustrates a verified medical user views a file without modifying the contents.Figure 3.4.6b provides a schematic illustration of the procedures for viewing a file.

Figure 3.4.6a A medical user viewing a file scenario.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 3.4.6b Procedures for a Medical User to View a File

a. The verified medical user selects a personal user. b. The MHC File Server requests the selected personal user files.c. The MHC File Database returns the list of files for the selected user.d. The MHC File Server displays the personal user’s files.e. The user selects a file record.f. The MHC File Server requests the file record.g. The MHC File Server checks both the user and files permissions.h. The MHC File Database returns the requested file record.i. The MHC File Server displays the file record.j. The user can close the file window.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.4.7 Edit FileA verified medical user double-clicks or right clicks on the patient file and selects view from the pop-up context menu. The MHC file server returns the files from the MHC file database for the selected patient. The medical user right clicks on the desired file record and selects edit from the pop-up context menu. The MHC File Server will check the user and files permissions, then display the sections of the file which are editable for that user. The user can then make edits which are saved as they are made, updating the file in the database.Figure 3.4.7a illustrates a medical user modifying the contents of a file.Figure 3.4.7b provides a schematic illustration of the procedures for editing a file.

Figure 3.4.7b A Verified Medical User Edits a File Scenario

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 3.4.7b Procedures for a Verified Medical User to Edit a File

a. The verified medical user selects a personal user. b. The MHC File Server requests the selected personal user files.c. The MHC File Database returns the list of files for the selected user.d. The MHC File Server displays the personal users files.e. The user selects an editable file record.f. The user right clicks on the file record and selects edit from the pop-up context menu.g. The MHC File Server requests the editable file record.h. The MHC File Server checks both the user and files permissions.i. The MHC File Database returns the editable file.j. The MHC File Server displays the editable selections of the file.k. The user can then edit the file and save it.l. The MHC File Server receives the edits.m. The MHC File Database is updated accordingly.n. The user can close the file window.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.4.8 Print FileA verified medical user double-clicks or right clicks on the patient file and selects view from the pop-up context menu. The MHC file server returns the files from the MHC file database for the selected patient. The medical user right clicks on the desired file record and selects print from the pop-up context menu. The file will then be displayed as read only at which point the user can choose to print the file.Figure 3.4.8a illustrates a verified medical user printing a file.Figure 3.4.8b provides a schematic illustration of the procedures for printing a file.

Figure 3.4.8a A Verified Medical User Prints a File Scenario

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 3.4.8b Procedures for a Verified Medical User to Print a File

a. The verified medical user selects a personal user. b. The MHC File Server requests the selected personal user files.c. The MHC File Database returns the list of files for the selected user.d. The MHC File Server displays the personal user’s files.e. The user selects a file record.f. The MHC File Server requests the file record.g. The MHC File Server checks both the user and files permissions.h. The MHC File Database returns the requested file record.i. The MHC File Server displays the file record.j. The user sends a print order to the printer.k. The printer prints the file.l. The user can close the file window.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.5 Insurance User FunctionalityAny authorized personal user can invoke the following functionality in MHC:

3.5.1 View FileA verified insurance user double-clicks or right clicks on the insured member’s personal user file and selects view from the pop-up context menu. The MHC file server returns the files from the MHC file database for the selected insured member. The insurance user right clicks on the desired claim record and selects view from the pop-up context menu. The requested claim record is then displayed in a read-only format.Figure 3.5.1a illustrates a verified insurance user viewing a file without modifying its contents.Figure 3.5.1b provides a schematic illustration of the procedures for an insurance user to view a file.

Figure 3.5.1a A verified Insurance User edits a file scenario.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 3.5.1b Procedures for a Verified Insurance User to View a File.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.5.2 Edit FileA verified insurance user double-clicks or right clicks on the insured member’s user file and selects view from the pop-up context menu. The MHC file server returns the files from the MHC file database for the selected insured member. The insurance user then right clicks on the desired claim record and selects edit. The MHC file Server will check the user and files permissions, then display the sections of the record which are editable for that user. The user can then make edits which are saved as they are made, updating the file in the database.Figure 3.5.2a illustrates a verified insurance user modifying the contents of a file.Figure 3.5.2b provides a schematic illustration of the procedures for editing a file.

Figure 3.5.2a A verified insurance user edits a file scenario.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 3.5.2b Procedure for a Verified Insurance User to Edit a File

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

3.5.3 Print FileA verified insurance user double-clicks or right clicks on the insured member’s personal user file and selects view from the pop-up context menu. The MHC file server returns the files from the MHC file database for the selected insured member. The insurance user then right clicks on the desired patient file and selects view from the pop-up context menu. The requested claim record is then displayed in a read-only format at which point the user can choose to print the file.Figure 3.5.3a illustrates a verified insurance user printing a file.Figure 3.5.3b provides a schematic illustration of the procedures for printing a file.

Figure 3.5.3a A verified insurance user prints a file scenario

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Figure 3.5.3a Procedures for a verified insurance user to print a file

a. The verified insurance user selects the file to be displayed by the insured member.b. The MHC File Server requests the PU files from the MHC billing database.c. The MHC billing database returns the requested PU files.d. The MHC File Server sends the list to the client device to be displayed.e. The verified IU selects the files to be displayed by the patient.f. The MHC file server requests the patient files from the MHC billing database.g. The MHC billing database returns the requested patient files.h. The MHC File server sends the patient files to the client device to be displayed.i. The verified IU selects the billing records to be displayed by the claim number.j. The MHC file server requests the claim record from the MHC billing database.k. The MHC File Server checks both the user and the file permissions.l. The MHC billing database returns the requested claim recordm. The MHC file server sends the file to be displayed to the client device.n. The user sends a print order to the printer.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

o. The printer prints the file.p. The user can close the file window.

4 Enumerated MHC Requirements

4.1 Universal User Functions<MHC -UUF-010>MHC shall allow a new user to change their password, create their thumbprint scan, and set their lock-out authorization method when they first log in, activating their account.<End of MHC -UUF-010>

<MHC –UUF-020>MHC shall allow a verified user to change their password from the preferences menu.<End of MHC–UUF-020>

<MHC –UUF-030>MHC shall send a unique authorization code to a user, based on their lock-out method, when the user selects change password from the preferences menu.<End of MHC–UUF-030>

<MHC –UUF-040>MHC shall allow a verified user to input the unique code they have received, their old password, and their new password in order to update their password.<End of MHC–UUF-040>

<MHC –UUF-050>MHC shall allow an unverified user to change their password from the login page by clicking “Forgot Password”.<End of MHC–UUF-050>

<MHC –UUF-060>MHC shall send a unique authorization code to a user, based on their lock-out method, when the user selects “Forgot Password” on the login page.<End of MHC–UUF-060>

<MHC –UUF-070>MHC shall allow an unverified user to input the unique code they have received, and a new password in order to update their password.

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

<End of MHC–UUF-070>

<MHC –UUF-080> MHC shall send a unique code to a user via their preferred lock-out authorization method when the locked-out account attempts to login next.<End of MHC–UUF-080>

<MHC –UUF-090> MHC shall allow a locked-out user to submit their lock-out authorization code, username, and password in order to verify their identity after attempting to log in.<End of MHC–UUF-090>

<MHC –UUF-100> MHC shall unlock a user’s account which has been verified as belonging to that user, and then display their file list.<End of MHC–UUF-100>

<MHC -UUF-110>MHC shall retrieve all files from the MHC File Database using HL7 Protocol Version 3.

HL7 Implementation for CDA Release 2 Documentation<End of MHC–UUF-110>

<MHC -UUF-120>MHC shall allow a verified user to view a valid file in read-only mode by double-clicking the file.<End of MHC–UUF-120>

<MHC -UUF-130>MHC shall allow a verified user to view a valid file in read-only mode by right-clicking the file, then selecting view from the pop-up context menu, Figure 2.3.4 Pop-up Menu Mock-up<End of MHC–UUF-130>

<MHC –UUF-140> MHC shall allow a verified user to edit sections of a valid file, based on their permissions, by right-clicking the file, then selecting edit from the pop-up context menu.<End of MHC –UUF-140>

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

<MHC –UUF-150>MHC shall allow a verified user to print a valid file by right-clicking the file, then selecting print from the pop-up context menu.<End of MHC–UUF-150>

<MHC –UUF-160> MHC shall allow a verified user to view their list of connected accounts from the preferences menu.<End of MHC–UUF-160>

<MHC –UUF-170> MHC shall allow a verified user to view their account lock-out authorization method from the preferences menu, Figure 2.3.5 Preferences Menu Mock-up<End of MHC–UUF-170>

<MHC –UUF-180> MHC shall allow a verified user to modify their account lock-out authorization method to either:

i. Send unlock code to specified phone number.ii. Send unlock code to specified email address.

from the preferences menu.<End of MHC–UUF-180>

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

4.2 Personal and Insurance User Functions<MHC-PIUF-010> MHC shall verify a personal or insurance user’s submitted login credentials.<End of MHC –PIUF-010>

<MHC-PIUF-020> MHC shall flag a personal or insurance user as verified and display their file list if their credentials are valid.<End of MHC –PIUF-020>

<MHC-PIUF-030> MHC shall request a personal or insurance user to re-enter their credentials if their entered credentials are invalid.<End of MHC –PIUF-030>

<MHC-PIUF-040> MHC shall flag a personal or insurance user account as locked-out after three consecutive, failed login attempts.<End of MHC –PIUF-040>

4.3 Personal User Functions<MHC –PUF-010> MHC shall allow a verified personal user to authorize a medical or insurance user to view and modify their account files, connecting them.<End of MHC –PUF-010>

<MHC –PUF-020> MHC shall allow a verified personal user to revoke an authorized medical or insurance user’s access to their account files, disconnecting them.<End of MHC –PUF-020>

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

4.4 Medical User Functions<MHC-MUF-010> MHC shall verify a medical users submitted login credentials.<End of MHC –MUF-010>

<MHC-MUF-020> MHC shall flag a medical user as partially-authenticated if their credentials are valid.

● A partially authenticated user is one which has successfully entered their username and password, but not yet scanned their thumb.

<End of MHC –MUF-020>

<MHC-MUF-030> MHC shall request a medical user to re-enter their credentials if their entered credentials are invalid.<End of MHC –MUF-030>

<MHC-MUF-040> MHC shall flag a medical user account as locked-out after three consecutive, failed login attempts.<End of MHC –MUF-040>

<MHC-MUF-050> MHC shall verify a medical user’s submitted thumbprint scan.<End of MHC –MUF-050>

<MHC-MUF-060> MHC shall flag a medical user as verified if their thumbprint is valid.<End of MHC –MUF-060>

<MHC-MUF-070> MHC shall request a medical user re-scan their thumb if the thumbprint is invalid.<End of MHC –MUF-070>

<MHC-MUF-080> MHC shall flag a medical user account as locked-out after five consecutive, failed thumbprint scanning attempts.<End of MHC –MUF-080>

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

4.5 Security<MHC –SEC-010> MHC shall encrypt all data which is transmitted through its processes. <End of MHC –SEC-010>

<MHC –SEC-020> All forms transmitted via MHC shall be formatted and transferred according the CDA standard.

● Outlined Categories and Attributes for the CDA Standard. ● CDA Release 2 Documentation

<End of MHC –SEC-020>

<MHC –SEC-030>MHC shall encrypt all subscriber account information using the MD5 hashing algorithm, as well as salting all computed hashes.<End of MHC –SEC-030>

<MHC –SEC-040>MHC shall identify user accounts by the user ID, determined by the order in which the accounts were added to the Subscriber Database.

● User IDs start at 000000001 and increase by one for new each account.<End of MHC –SEC-040>

<MHC –SEC-050>MHC shall encrypt all data stored in the secondary, backup databases using the MD5 hashing algorithm.<End of MHC –SEC-050>

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

4.6 Error Handling<MHC –ERR-010> MHC shall flag an account as locked-out if a user attempts to login with a valid username but invalid password three consecutive times.

● Error Code: 01 <End of MHC –ERR-010>

<MHC –ERR-020>MHC shall flag a medical user’s account as locked-out if a partially-authenticated user fails to correctly scan their thumb five consecutive times.<End of MHC –ERR-020>

<MHC –ERR-030> MHC shall deny a user the ability to login if it has reached its maximum amount of allowed concurrent users, 20% of MHCs total subscriber amount.<End of MHC –ERR-030>

<MHC –ERR-040> MHC shall store its error records in a separate physical location than the subscriber and file databases.<End of MHC –ERR-040>

<MHC –ERR-050> A record shall be kept of system failures and crashes in the Error Log Database for a minimum of three years.<End of MHC –ERR-050>

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

4.7 Operations, Administration and Maintenance<MHC –OAM-010> MHC shall allow the administrators, the State of Ohio, to manually create and load user account files into the MHC Subscriber Database.<End of MHC –OAM-010>

<MHC –OAM-020> The MHC administrators, the State of Ohio, shall distribute user account and login information to its citizens via mail.<End of MHC –OAM-020>

<MHC –OAM-030> MHC shall reassign control of an account to its administrators, the State of Ohio, upon the death of the user by changing the account password to a standard password for all deceased residents.<End of MHC –OAM-030>

<MHC –OAM-040> MHC shall allow the administrators, the state of Ohio, to assign user account permissions which abide by HIPAA regulations, by manually updating the necessary fields in the MHC Subscriber Database files.

HIPAA Privacy Guidelines<End of MHC –OAM-040>

<MHC –OAM-050> MHC shall consider an on-screen object to be valid for a given user based on their account permissions.<End of MHC –OAM-050>

<MHC –OAM-060> When a user right-clicks a valid object, MHC shall display a pop-up context menu with the following options:

i. View.ii. Edit.

iii. Print.iv. Cancel.

<End of MHC –OAM-060>

<MHC –OAM-070>

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

Maintenance of MHC shall be carried out no more than once a month for non-emergency situations.<End of MHC –OAM-070>

4.8 Performance, Resource and Reliability Requirements<MHC –PRR-010>MHC shall have space for ten-million accounts.<End of MHC –PRR-010>

<MHC –PRR-020>The maximum number of concurrent users shall be no more than 20% of MHCs total subscriber amount.<End of MHC –PRR-020>

<MHC –PRR-030>MHC shall have a Subscriber Database with a table for user credentials and a table for user information.

User Credentials: ID#, username, salted password.User Information: ID#, first name, last name, age, address, city, zip code, DOB, login token, authorization method, authorization method value, list of authorized connections.

<End of MHC –PRR-030>

<MHC –PRR-040>MHC shall have a File Database with a table relating each stored file to an identifiable user.

Attributes: Owner ID#, file name, type (EMR, personal, insurance), date last modified, date added, size.


<MHC –PRR-050>MHC shall have an Error Log Database which stores information relating to any errors encountered by the system.

Attributes: Date & time of error, error type, critical, error description.<End of MHC –PRR-050>

<MHC –PRR-060> MHC shall return a read-only file in less than 200ms under a medium or light load. <End of MHC –PRR-060>

Issue: 1.0 Date: 11/26/2014


MyHealthComplete

<MHC –PRR-070> MHC shall return a read-only file in less than 500ms under a high load. <End of MHC –PRR-070>

<MHC –PRR-080>MHC shall return an editable file in a given period of time based on the user type:

i. Medical less than 100ms.ii. Insurance less than 500ms.

iii. Personal less than 1s.Time doubled under heavy load.<End of MHC –PRR-080>

<MHC –PRR-090>MHC shall be down for no more than four hours during scheduled maintenance periods.<End of MHC –PRR-090>

<MHC –PRR-100>The primary system shall be rebooted in no more than six hours in non-emergency situations.<End of MHC –PRR-100>

<MHC –PRR-110>MHC shall backup all files to the secondary databases in real time, mirroring the primaries, with a full physical backup each day.<End of MHC –PRR-110>

<MHC –PRR-120>MHC shall switch control to its secondary server and databases in the event that the primary system fails.<End of MHC –PRR-120>

<MHC –PRR-130>MHC shall have an availability standard that supports:

i. A MTBF rate of 4377 hours.ii. A maximum MTTR at 6 hours for non-scheduled maintenance.


Issue: 1.0 Date: 11/26/2014


MyHealthComplete

5 Open Issues● Enabling medical and insurance billing through MHC.● Enabling medical users to schedule appointments with their patients.

6 Future Considerations● Increasing the capacity of the databases to handle the growing population.

7 AcknowledgmentsWe would like to thank the State of Ohio for allowing us to design MHC so that it can improve medical care for all of Ohio.

Issue: 1.0 Date: 11/26/2014


rjholland2016.files.wordpress.com · web viewthe goal of myhealthcomplete is to provide a...

Documents