Difference between revisions of "Projects:2015s2-211 Health Visa"
(→Client) |
(→REFERENCES) |
||
(96 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
=TEAM= | =TEAM= | ||
− | + | '''Group Members''' | |
*Samuel Zevenbergen. | *Samuel Zevenbergen. | ||
*Mingjie Qiu. | *Mingjie Qiu. | ||
− | + | '''Supervisor''' | |
*[http://www.adelaide.edu.au/directory/matthew.sorell Matthew Sorell.] | *[http://www.adelaide.edu.au/directory/matthew.sorell Matthew Sorell.] | ||
− | + | '''Client (Canadian)''' | |
− | *[http://www.franciscograjales.com/ Francisco Grajales | + | *[http://www.franciscograjales.com/ Francisco Grajales] |
=BACKGROUND= | =BACKGROUND= | ||
+ | There are an increasing number of people living with serious allergies, medical conditions and specific treatment wishes without the means of communicating this with First Responders and Paramedics in an emergency situation. There have been many situations where poor outcomes such as avoidable injury or death have resulted from medical treatments administered by medical professionals in emergency situations due to a lack of patient medical history.<br> | ||
+ | |||
+ | The purpose of patient care/healthcare is for medical professionals to use their knowledge and experience as well as all available medical information and advanced directives to make a prompt and competent diagnosis leading to appropriate and correct treatment during a medical emergency. Currently it is in the patient's best interest to ensure they can communicate relevant medical information in case of an emergency. It is also the medical professional's obligation to respond in the correct manner to any medical information and reasonable wishes [https://emergencylaw.wordpress.com/2015/ 07/19/ignoring-a-medic-alert-bracelet 1]. | ||
=EXISTING SYSTEMS= | =EXISTING SYSTEMS= | ||
+ | Currently there are many devices and systems, which can be used by patients to communicate their treatment critical information with medical professionals in the case of emergency where they are unable to [1].<br> | ||
+ | |||
+ | Despite the current number of options available, there are still cases where speed of access to information, amount and accuracy of information, language barriers, privacy, authentication, security, community awareness and location of the information have resulted in undesirable outcomes such as medical episodes and even death.<br> | ||
+ | |||
+ | In response to this issue, a number of systems have been created, each with weaknesses around the amount of information available, time required to access information, data privacy and/or security. The below sections highlight the pros and cons of each system. <br> | ||
+ | |||
+ | There are a number of systems available for people to communicate their medical details and treatment wishes with first responders. These include: Medic Alert (jewelry), Medical ID (Apple Inc.), Code4Armour and Key2Life systems. Each of these is described below in regard to their efficacy, language support, access requirements, amount of immediate/delayed information, community awareness, geographical footprint as well as privacy and authentication.<br> | ||
+ | |||
==Medic Alert== | ==Medic Alert== | ||
+ | [[File:MA.png|thumb|500px|center|MedicAlert Examples]] | ||
+ | '''Overview'''<br> | ||
+ | The Medic Alert Foundation was founded in California in 1953, but now has affiliates in 9 other countries. They are the only non-profit organisation that hires ‘highly skilled medical response personnel’. They offer a range of jewelry (bracelets, anklets and necklaces) with medical information, treatment wishes and ID number engraved on them. To get a medic alert tag, you must purchase the jewelry online, create an online profile, specify details to be engraved and pay an annual subscription fee, which are all dependent on the country you live in. If your medical information changes, you have to purchase a new tag or pay for your current one to be smoothed and re-engraved (which can only be done once or twice) [1][2].<br> | ||
+ | |||
+ | '''Pros''' | ||
+ | *MedicAlert has a proven efficacy. | ||
+ | *Significant language translation service available. | ||
+ | *Good community awareness of the system. | ||
+ | *Significant geographical footprint (9 countries in total). | ||
+ | |||
+ | '''Cons''' | ||
+ | *Small amount of immediately available information (only what is engraved on the bracelet). | ||
+ | *There is an extensive delay to obtain further medical information (relayed via phone or fax). | ||
+ | *The system lacks privacy as anyone can access your medical records by reading them off your bracelet. | ||
+ | *There is no authentication required to access the initial information (from your bracelet). | ||
+ | |||
==iPhone Medical ID== | ==iPhone Medical ID== | ||
+ | [[File:IMID.jpg|thumb|150px|center|iPhone MedicalID Example]] | ||
+ | '''Overview'''<br> | ||
+ | Many people have a contact labelled ‘ICE’ - ‘In Case of Emergency’ on their phone, but they have a passcode, which disables anyone from accessing it in an emergency. Apple has developed a medical ID application, which can be enabled on any iPhone with a minimum of iOS-8 installed. This allows anyone to access your medical information such as allergies, blood type and medications as well as your emergency contact details. It also allows them to use your phone to contact your emergency contacts, even if your phone is locked [3].<br> | ||
+ | |||
+ | '''Pros''' | ||
+ | *The amount of information immediately available is significantly greater. | ||
+ | *Exists on a popular phone. | ||
+ | *Significant geographical footprint. | ||
+ | |||
+ | '''Cons''' | ||
+ | *There efficacy of this system has not been proven. | ||
+ | *No language translation support. | ||
+ | *Minimal community awareness. | ||
+ | *This system is lacking privacy. | ||
+ | *No authentication required in order to access medical records. No record of someone accessing your records. | ||
+ | |||
==Code4Armour== | ==Code4Armour== | ||
+ | [[File:C4A.jpeg|thumb|150px|center|Code4Armour Example]] | ||
+ | '''Overview'''<br> | ||
+ | Code4Armour is a new technology in which you buy and wear a passive bracelet on your wrist. To set this up, you pay an annual subscription fee, create an online account and upload your personal, medical and emergency contact details. Anyone with a Near Field Communication (NFC) capable phone and the free Code4Armour™ app can bring up your details on their phone by scanning your bracelet. There are two types of people (general users and first responders who must be verified) [4].<br> | ||
+ | |||
+ | '''Pros''' | ||
+ | *The amount of information immediately available is significantly greater. | ||
+ | *Exists on popular devices. | ||
+ | |||
+ | '''Cons''' | ||
+ | *There efficacy of this system has not been proven. | ||
+ | *No language translation support. | ||
+ | *Minimal community awareness. | ||
+ | *There are specific hardware and software requirements in order to access records. | ||
+ | *This system is lacking privacy. | ||
+ | *No authentication required in order to access medical records. No record of someone accessing your records. | ||
+ | |||
==Key2Life== | ==Key2Life== | ||
+ | [[File:KEY2LIFE.png|thumb|500px|center|Key to Life Examples]] | ||
+ | '''Overview'''<br> | ||
+ | Key2Life is an emerging company offering many medical ID devices, from wearable USB sticks, tags with NFC technology, and cards with magnetic strips and/or QR codes. These systems generally require a once off payment for purchase, with no recurring subscription costs. In a medical crisis where you may be unable to speak for yourself, civilian laypersons and medical physicians can access your information from a computer or a smartphone with NFC/QR reader capabilities. There are some evident hardware and software requirements in order to access the information stored in these devices [5].<br> | ||
+ | |||
+ | '''Pros''' | ||
+ | *The amount of information immediately available is significantly greater. | ||
+ | *Geographical footprint is large, but user base is small. | ||
+ | |||
+ | '''Cons''' | ||
+ | *There can be a significant delay in order to access any information (you may need to plug a USB into a computer for example). | ||
+ | *There efficacy of this system has not been proven. | ||
+ | *No language translation support. | ||
+ | *Minimal community awareness. | ||
+ | *There are specific hardware and software requirements in order to access records. | ||
+ | *This system is lacking privacy. | ||
+ | *No authentication required in order to access medical records. No record of someone accessing your records. | ||
+ | |||
+ | ==Summary of Existing Systems== | ||
+ | From the above summaries of current technologies, it should be clear that many of them are relatively complete, but have downfalls. The below figure is a diagrammatic comparison of the already discussed technologies and the completeness of features, which are most important for an efficient system like this. The key point to be made from this diagram is that all current existing systems have major privacy and authentication issues.<br> | ||
+ | [[File:summary.png|thumb|500px|center|Summary of Existing Systems]] | ||
=HEALTH VISA SYSTEM= | =HEALTH VISA SYSTEM= | ||
− | ==Operational | + | ==System Goals and Objectives== |
− | == | + | The goal of the Health Visa system is to provide as much information which is relevant |
− | == | + | to a user should they find themselves in a medical emergency. |
+ | <br> | ||
+ | The short term objectives of the Health Visa system are listed below: - | ||
+ | <br> | ||
+ | *The system will provide sufficient and relevant medical information, quickly and securely to Medical Professionals and Public Laypersons’ in the event of a medical emergency. | ||
+ | *The system will have a low cost for the end user, facilitating significant growth. | ||
+ | *A positive cost benefit relationship will be apparent to the public. | ||
+ | *The system will be up to date with the relevant and current acts, regulations and standards. | ||
+ | *The empowerment offered to the end-user will be evident as they have full authority and control of their personal information which includes sensitive medical records. | ||
+ | |||
+ | The long term goals of the Health Visa system are listed below: - | ||
+ | <br> | ||
+ | *The reach of the system will increase as time goes on. The system is to be implemented in all considered countries within a small timeframe, with further countries expected to be included in the future. | ||
+ | *All members of the public, including young and old will have the available assistance (if required) to become a registered user of the system. | ||
+ | |||
+ | ==Description of the System== | ||
+ | The fundamental objective of the Health Visa system is to overcome the privacy, authentication and security issues associated with all existing medical information systems. The designed system will work across a range of regulatory boundaries, allowing for secure and prompt access to Registered General Users’ medical records during a medical emergency. | ||
+ | <br> | ||
+ | It should be noted that the focus of the designed Health Visa system focuses on the back-end security and authentication protocols required to satisfy a range of privacy and data laws around the world, in particular the eight countries listed below. | ||
+ | <br> | ||
+ | The Health Visa system will allow for quick access to available medical records during a medical emergency. For example, Paramedics/Medics will have the ability to scan a QR code on a Visa card or bracelet to get access to a Registered General Users’ available medical records. One key aspect to the success of this system is that the user effectively owns their own data, has maximum control over it and thus feels empowered. With this, there will be varying levels of privacy: The user will have the ability to control what information they share with Medical Professionals and Public Laypersons. There will also be a log of who has accessed their information (name, date, location, etc.), which will help discourage abuse and increase accountability for all system users. | ||
+ | <br> | ||
+ | There will be three broad classes of system users: Public Laypersons, Registered General Users and Medical Professionals which includes Primary Care Providers, and Paramedics/Medics. | ||
+ | <br> | ||
+ | The Health Visa system will allow for different authentication methods (some examples include driver's license, QR code on a visa card and biometrics such as: fingerprint, eye recognition, voice recognition, etc. The Health Visa concept design is not concerned with the authentication methods used, but must allow for a sufficient number of methods, which are continually evolving which are expected to change over time. | ||
+ | <br> | ||
+ | Public Laypersons (either Registered General Users or not) will require 2 points of authentication (out of a number of possibilities) in order to access information, whereas Paramedics/Medics only need 1 point. This is because medical professionals generally require information quickly and they are already verified within the system and thus given this privilege. | ||
+ | <br> | ||
+ | Language translation is another useful function which is contained within the Health Visa system. In order to facilitate effective communication of information, especially across countries with differing languages, it is necessary to include automatic translation of medical information. An easy and consistent way to implement this language translation function is to use ICD 10 for direct translations of medical terms, thus ensuring the medical records are interpreted correctly and further reducing any risk [6][7]. | ||
+ | <br> | ||
+ | It should be emphasized that the Health Visa system has been designed to be implemented across the eight considered countries initially, with further expansion expected in the future. Language translation is already pertinent to the initial deployment across these eight countries as there are a minimum of three primary languages (English, Estonian and Korean). | ||
+ | |||
+ | ==Countries of Operation== | ||
+ | *Australia. | ||
+ | *United States of America. | ||
+ | *Canada. | ||
+ | *Estonia. | ||
+ | *Israel. | ||
+ | *New Zealand. | ||
+ | *South Korea. | ||
+ | *United Kingdom. | ||
+ | |||
+ | ==Regulatory Policies and Acts== | ||
+ | '''1. Australia''' | ||
+ | *The Privacy Act, 1988. | ||
+ | *The Spam Act, 2003. | ||
+ | |||
+ | '''2. United States of America''' | ||
+ | *Health Insurance Portability and Accountability Act, 1996. | ||
+ | *Children’s Online Privacy Protection Act, 1998. | ||
+ | *Health Information Technology for Economic and Clinical Health, 2009. | ||
+ | *CAN-SPAM Act, 2003. | ||
+ | |||
+ | '''3. Canada''' | ||
+ | *Personal Information Protection for Electronic Documents Act, 2000. | ||
+ | *Personal Health Information Privacy and Access Act, 2004. | ||
+ | *Personal Health Information Act, 2008. | ||
+ | *Canadian Anti-Spam Legislation, 2009. | ||
+ | |||
+ | '''4. Estonia''' | ||
+ | *Personal Data Protection Act, 2007. | ||
+ | *Electronic Communications Act, 2004. | ||
+ | *EU General Data Protection Directive 95/46/EC, 2000. | ||
+ | *Information Society Services Act, 2004. | ||
+ | |||
+ | '''5. Israel''' | ||
+ | *Human Dignity and Liberty Law (the Basic Law), 1992. | ||
+ | *Protection of Privacy law (the Privacy Law), 1981. | ||
+ | *Protection of Privacy Regulations, 2001. | ||
+ | |||
+ | '''6. New Zealand''' | ||
+ | *The Privacy Act, 1993. | ||
+ | *Health Information Privacy Code (1994) and Commentary Version 2008. | ||
+ | *Unsolicited Electronic Messages Act, 2007. | ||
+ | |||
+ | '''7. South Korea''' | ||
+ | *The Personal Information Protection Act, 2011. | ||
+ | |||
+ | '''8. United Kingdom''' | ||
+ | *The Data Protection Act, 1998. | ||
+ | *The Privacy and Electronic Communications Regulations, 2003. | ||
+ | *EU General Data Protection Directive 95/46/EC, 2000. | ||
+ | <br> | ||
+ | |||
+ | ==Country Specific Regulations== | ||
+ | All Country Specific Relations below were identified from the ‘Data Protection Laws of the World’ document defined in the document referenced [8]. | ||
+ | |||
+ | '''1. Australia''' | ||
+ | [[File:AUS.png|thumb|500px|center|Australia]] | ||
+ | |||
+ | '''2. United States of America''' | ||
+ | [[File:US1.png|thumb|500px|center|America]] | ||
+ | [[File:US2.png|thumb|500px|center|America]] | ||
+ | |||
+ | '''3. Canada''' | ||
+ | [[File:Canada1.png|thumb|500px|center|Canada]] | ||
+ | [[File:Canada2.png|thumb|500px|center|Canada]] | ||
+ | |||
+ | '''4. Estonia''' | ||
+ | [[File:Estonia1.png|thumb|500px|center|Estonia]] | ||
+ | [[File:Estonia2.png|thumb|500px|center|Estonia]] | ||
+ | |||
+ | '''5. Israel''' | ||
+ | [[File:Israel.png|thumb|500px|center|Israel]] | ||
+ | |||
+ | '''6. New Zealand''' | ||
+ | [[File:New_Zealand.png|thumb|500px|center|New_Zealand]] | ||
+ | |||
+ | '''7. South Korea''' | ||
+ | [[File:South_Korea.png|thumb|500px|center|South_Korea]] | ||
+ | |||
+ | '''8. United Kingdom''' | ||
+ | [[File:United_Kingdom.png|thumb|500px|center|United_Kingdom]] | ||
+ | |||
+ | <br> | ||
+ | ---- | ||
+ | |||
+ | The system facilities the flow of medical records across these regulatory boundaries with the user’s consent, such that this information can be accessed in other countries during times of business and/or leisure travel. | ||
+ | |||
+ | [[File:ScopeCountries.png|thumb|500px|center|Scope Countries]] | ||
+ | |||
+ | The figure above highlights all countries which have been considered within the scope of the Health Visa system. These countries contribute approximately 632 million people or 11.3% to the world’s population. It is expected that the designed system would be deemed acceptable in many other countries, but further investigation and design may be required in countries not covered within the design scope [9]. | ||
+ | |||
+ | ==Health Practitioner Regulation Agencies== | ||
+ | All Health Professionals must have their credentials verified in order to become a verified system user. A list of Health Practitioner Regulation Agencies in each country and their associated website link are provided in Table below: | ||
+ | [[File:Relevant_Health_Practitioner_Regulation_Agencies.png|thumb|500px|center|Relevant Health Practitioner Regulation Agencies]] | ||
+ | |||
+ | ==Existing Infrastructure-Cloud Computing Systems== | ||
+ | |||
+ | Amazon Web Services (AWS) is a well-established and trusted cloud computing system that allows users to operate with minimal up-front capital and system maintenance costs. Table below summarizes some key characteristics of the AWS system [10]. Although AWS has been discussed in the context of the Health Visa System, there are many other cloud computing systems which are suitable for implementation of the Health Visa system as it is expected that all system requirements can be satisfied [11][12]. | ||
+ | [[File:CloudComputingSystems.png|thumb|500px|center|Cloud Computing Systems]] | ||
+ | |||
+ | ==Operational Descriptions== | ||
+ | [[File:StakeholderRoles&Responsibilities.png|thumb|500px|center|Stakeholder Roles & Responsibilities]] | ||
+ | The table above summarizes all stakeholders associated with this system and their corresponding classification, influence and power. | ||
+ | |||
+ | ==Stakeholder Modes of Operation== | ||
+ | It should be highlighted that different users will be provided with varying amounts of information as specified by the user themselves. The information specified as available by the user is expected to be influenced by Primary Care Providers advice, however the final decision is in the hands of the user themselves. In medical emergency situations where system users believe there may be additional information within the system, which may result in saving a life; they may assert a ‘Medical Emergency Override’. An outcome of this action is a ‘red flag’ within the system, in which the user themselves receives notification of. It should be noted that a Public Layperson will require a release code (which may be provided by the relevant Emergency Call Service) in order to assert a medical emergency. Figure below illustrates this concept. | ||
+ | [[File:StakeholderModesofOperation.png|thumb|500px|center|Stakeholder Modes of Operation]] | ||
+ | |||
+ | ==Operational Procedures and Sequences of Events== | ||
+ | A number of figures are provided below for purposes of comparing how Operational Procedures and Sequences of Events currently occur in an existing medical information system, and how they are expected to occur in the proposed new Health Visa system. | ||
+ | <br> | ||
+ | <br> | ||
+ | [[File:Becoming_a_Registered_General_User.jpg|thumb|500px|center|Becoming a Registered General User]] | ||
+ | <br> | ||
+ | The above figure illustrates how a typical user becomes a registered user on a typical existing medical information system and on the new Health Visa system. Below is a list of associated benefits pertaining to the new proposed system: - | ||
+ | <br> | ||
+ | *The user can become a verified, active user much quicker. | ||
+ | *The user is empowered as they have full control over their personal medical information by means of access filters. | ||
+ | *All medical records are verified by a qualified Primary Care Provider prior to being a ‘verified’, active user of the system. | ||
+ | |||
+ | ---- | ||
+ | |||
+ | <br> | ||
+ | [[File:Becoming_a_Verified_Professional_User.jpg|thumb|500px|center|Becoming a Verified Professional User]] | ||
+ | <br> | ||
+ | The above figure illustrates how Professional Users (Primary Care Providers and Paramedics/Medics) become registered, verified users on a typical existing medical information system and on the new Health Visa system. It is highlighted that such a user is not recognized with existing medical information systems. These Medical Professionals may phone the 24/7 hotline and state their profession but this is never exclusively checked and verified before disclosing medical records (all they require is the medical information system ID number). The new system includes a mechanism for Medical Practitioners (Primary Care Providers and Paramedics/Medics) to create an account and get their credentials verified prior to having a fully operational account. Below is a list of associated benefits pertaining to the new proposed system: - | ||
+ | <br> | ||
+ | *You must be registered with your relevant Health Practitioner Regulation Agency in order to create a ‘Medical Practitioner’ account, which includes Primary Care Providers and Paramedics/Medics. | ||
+ | *The system will know when your registration expires and ensure that registration is continually renewed, thus reducing risk of abuse by professionals which have had their registration revoked for any reason. | ||
+ | |||
+ | ---- | ||
+ | |||
+ | <br> | ||
+ | [[File:Access.jpg|thumb|500px|center|Accessing a General Users Medical Records in a Medical Emergency]] | ||
+ | <br> | ||
+ | The above figure illustrates how Public Layperson and Medical Professionals may access an individuals’ medical records, both on the existing medical information system and the proposed new Health Visa system. It is evident that existing medical information systems provide minimal medical information up-front, with no authentication required. Additional information can be obtained but typically takes a long time to acquire. Below is a list of associated benefits pertaining to the new proposed system: - | ||
+ | *All medical records can be obtained almost instantly, following required security checks. | ||
+ | *System security is much stronger, with system users being locked out after a set number of invalid attempts. | ||
+ | *The system does not rely on only 1 identifier. For example, someone may access an individuals’ medical records if they possess two of three registered identifiers. | ||
+ | |||
+ | ==System Context== | ||
+ | <br> | ||
+ | [[File:System_Context_Interfacing_with_Existing_System.jpg|thumb|500px|center|Interfacing with an Existing System]] | ||
+ | <br> | ||
+ | The above figure illustrates how the proposed new Health Visa system may be integrated with a typical existing medical information system. The following points summarize the key ideas illustrated in the noted figure: - | ||
+ | <br> | ||
+ | *The existing Customer Support Centre will support users on the existing and new systems. New hardware and software are expected to be required within the Customer Support Centre, followed by staff training before commissioning of the new system. | ||
+ | *New Health Visa Cloud Computing System to be commissioned independently of any existing Server and Database Infrastructure. | ||
+ | *New System shall comprise many compatible identifiers, which are ever evolving and are expected to change in the future. | ||
+ | *Users are either on the existing or new system. They are given the choice to migrate to the new system or remain on the existing system. After an appropriate time period, the existing system can be decommissioned as determined by the acquirer. | ||
+ | |||
+ | ---- | ||
+ | |||
+ | <br> | ||
+ | [[File:System_Context_Operation_of_System.jpg|thumb|500px|center|System Operation Diagram.jpg]] | ||
+ | <br> | ||
+ | The above figure illustrates how the proposed new Health Visa system will operate. The following notes summarize the key points covered in the previously mentioned figure: - | ||
+ | *The Team of Developers will develop and commission the new system. It is expected that a subset of this team will then form the Design and Maintenance Team which will ensure the system is operational and up-to-date. | ||
+ | *The key role of Primary Care Providers is to verify the medical records of Registered General Users, ensuring they are accurate. | ||
+ | *It is understood that the Health Visa Cloud Computing System may be implemented on AWS, however any other system which allows all system requirements be satisfied is acceptable. | ||
+ | |||
+ | |||
+ | ==System Interface Identification and Diagrams== | ||
+ | |||
+ | [[File:Interface_Identification_and_Diagrams.png|thumb|500px|center|System Interface_Identification_and_Diagrams]] | ||
+ | Please note the following abbreviations have been used to describe system attributes in the next sections: -<br> | ||
+ | Team of Developers: TOD <br> | ||
+ | Health Visa Cloud Computing System: HVCCS<br> | ||
+ | Public Laypersons + Paramedics and Medics: User Group<br> | ||
+ | Primary Care Providers: PCC<br> | ||
+ | Design and Maintenance Team: DMT<br> | ||
+ | Customer Support Centre: CSC<br> | ||
+ | Health Practitioner Regulation Agency: HPRA<br> | ||
+ | |||
+ | ---- | ||
+ | <br> | ||
+ | '''Interface 1 : TOD – HVCCS''' | ||
+ | [[File:INT01.png|thumb|500px|center|INT01]] | ||
+ | *The Team of Developers shall complete the initial development of the Health Visa system. They take the System Requirements document, further refine the design and commission the Health Visa system. | ||
+ | *They must have the ability to upload and test code during development. | ||
+ | |||
+ | ---- | ||
+ | <br> | ||
+ | '''Interface 2 : User Group – HVCCS''' | ||
+ | [[File:INT02.png|thumb|500px|center|INT02]] | ||
+ | *Pubic Laypersons and Paramedics/Medics were identified to have similar characteristics. Both user groups can be used to simplistically access medical records, having minimal differing characteristics. | ||
+ | *These users can both obtain personal identifiers, transfer them to the system and be provided with medical records should all verification tests pass. The key difference is that Paramedics and Medics require only one identifiers, while Public Laypersons require two. | ||
+ | |||
+ | ---- | ||
+ | <br> | ||
+ | '''Interface 3 : RGU – HVCCS''' | ||
+ | [[File:INT03.png|thumb|500px|center|INT03]] | ||
+ | *Registered General Users require the ability to create an account, add personal information and medical records and much more. This user type is the most sophisticated and has the most functionality. | ||
+ | |||
+ | ---- | ||
+ | <br> | ||
+ | '''Interface 4 : PCP – HVCCS''' | ||
+ | [[File:INT04.png|thumb|500px|center|INT04]] | ||
+ | *Primary Care Providers require the ability to create an account, access Registered General Users medical records and verify them. The amount of functionality required to access and verify these medical records is significant. | ||
+ | |||
+ | ---- | ||
+ | <br> | ||
+ | '''Interface 5 : DMT – HVCCS''' | ||
+ | [[File:INT05.png|thumb|500px|center|INT05]] | ||
+ | *The Design and Maintenance Team are responsible for the continuous technical support, maintaining, updating and expansion of the Health Visa System. They are the key system user between the Customer Support Centre Staff and the Health Visa Cloud System, providing technical support when required. | ||
+ | |||
+ | ---- | ||
+ | <br> | ||
+ | '''Interface 6 : CSC – HVCCS''' | ||
+ | [[File:INT06.png|thumb|500px|center|INT06]] | ||
+ | *The Customer Support Centre are responsible for the continuous support of all system users. They must be able to access the Health Visa database to provide effective support to all customers. | ||
+ | |||
+ | ---- | ||
+ | <br> | ||
+ | '''Interface 7 : User Group – CSC''' | ||
+ | [[File:INT07.png|thumb|500px|center|INT07]] | ||
+ | *The Customer Support Centre are responsible for the continuous support of all system users. They must be able to access the Health Visa database to provide effective support to all customers. | ||
+ | |||
+ | ---- | ||
+ | <br> | ||
+ | '''Interface 8 : RGU - SCS''' | ||
+ | [[File:INT08.png|thumb|500px|center|INT08]] | ||
+ | *The Customer Support Centre are responsible for the continuous support of all system users. They must be able to access the Health Visa database to provide effective support to all customers. | ||
+ | |||
+ | ---- | ||
+ | <br> | ||
+ | '''Interface 9 : PCP – CSC''' | ||
+ | [[File:INT09.png|thumb|500px|center|INT09]] | ||
+ | *The Customer Support Centre are responsible for the continuous support of all system users. They must be able to access the Health Visa database to provide effective support to all customers. | ||
+ | |||
+ | ---- | ||
+ | <br> | ||
+ | '''Interface 10 : DMT – CSC''' | ||
+ | [[File:INT10.png|thumb|500px|center|INT10]] | ||
+ | *The Customer Support Centre must be able to attain support from the Design and Maintenance Team when issues arise. | ||
+ | |||
+ | ---- | ||
+ | <br> | ||
+ | '''Interface 11 : CSC – HPRA''' | ||
+ | [[File:INT11.png|thumb|500px|center|INT11]] | ||
+ | *The Customer Support Centre must communicate with relevant Health Practitioner Regulation Agencies in order to verify that specific Medical Professionals are credible and therefore hold up-to-date registration. | ||
+ | |||
==Operational Scenarios== | ==Operational Scenarios== | ||
+ | All operational scenarios use examples on an individual’s identity may be verified. For example, by use of a QR code on a Visa card, finger print, facial recognition, etc. It should be highlighted once again that these are used as example identification and verification methods only and does not suggest that these would be implemented. Verification methods of identifying individuals is continually evolving and thus not a key focus of the designed Health Visa system. | ||
+ | <br> | ||
+ | <br> | ||
+ | '''Scenario 1 – Normal Operation''' | ||
+ | <br> | ||
+ | An elderly woman discussed treatment options for her obesity problem. The doctor suggested the option of post-gastric bypass surgery, in which she decided to go ahead with. The woman followed her doctor’s suggestion that she list the operation on her Health Visa account as there was a risk of complications following the surgery. | ||
+ | <br> | ||
+ | A short time later, she was out shopping in a busy shopping mall where she lost consciousness and collapsed. Many members of the public rushed to her aid. During the commotion, a number of medical conditions were mentioned as being possible causes of the medical event. One member of the public scanned her QR code and fingerprint into their smart phone. Before paramedics arrived to treat the woman, this member of the public was able to notify of the woman’s recent surgery. This lead to prompt and accurate treatment, in which she was intubated and fully recovered in hospital. Had this information not been available, wrong or delayed treatment would have likely been a result. This amount of information, verification and timely access does not exist with all existing medical information systems. | ||
+ | <br> | ||
+ | <br> | ||
+ | '''Scenario 2 – Lost Child''' | ||
+ | <br> | ||
+ | During a family holiday to Disney Land, a four-year-old boy becomes separated from his parents in a large crowd. This child, clearly distressed is approached by a staff member and asked if he knows where his parents are. This child does not know where his parents are, let alone their contact details, but states that he is registered on the Health Visa system. This staff member opens the Health Visa application on their smart phone, scans the boy’s finger print and takes a photo of his face for identification and verification purposes. | ||
+ | <br> | ||
+ | After sending this information to the Health Visa system, a match is identified, with the boy’s medical records and emergency contact details being presented to the staff member. This staff member then selected to contact the emergency contact via phone, directly allowing for the parents to quickly find their lost son. | ||
+ | <br> | ||
+ | <br> | ||
+ | '''Scenario 3 – Overseas Travel''' | ||
+ | <br> | ||
+ | A young homosexual, adult male was required to travel on business to Russia in which he was nervous about as he felt that there was a stigma associated with homosexuality within the country. Although he recognized that his sexuality was not illegal in the country, he realized that they still have a law against ‘propaganda of homosexuality’ which made him feel uncomfortable. | ||
+ | <br> | ||
+ | This young man was a registered user on the Health Visa system and had a sexually transmitted disease (STD), which is commonly recognized as being associated with homosexuality. This young man decided to adjust his privacy settings before he travelled to Russia such that this (non critical) infection and his next of kin, who was also a male would not be released to any users of the system. In order to retain an emergency contact, he selected to provide his mother’s contact details in a medical emergency. | ||
+ | <br> | ||
+ | When this man travelled to Russia, he was involved in a serious car crash. The first public layperson at the scene searched the man’s wallet, located and scanned his QR code located on his Visa card. This identification entry along with a photo of his face was sent to the Health Visa system for identification and verification purposes. The public layperson was issued with his available medical information, including serious allergies to certain medications. This allowed him to receive the appropriate care based on his needs, while his non critical illness remained private. | ||
+ | <br> | ||
+ | <br> | ||
+ | |||
+ | =DELIVERABLES= | ||
+ | The key deliverables for this project were a Concept of Operations (ConOps) document and a System Requirements Document (SRD) which both focus on the data privacy, security and regulatory requirements in order to operate across the noted countries. | ||
+ | <br> | ||
+ | The following items were also important deliverables of this project: - | ||
+ | <br> | ||
+ | *A demonstration walkthrough video was also created which clearly shows the operational differences between a typical existing system and the new Health Visa system. | ||
+ | *Pitch deck, which will be used to present the key benefits of the Health System to potential investors. | ||
+ | |||
+ | =REFERENCES= | ||
+ | [1] ‘How the MedicAlert emblem protects.’ [Online]. Available: https://www.medicalert.org.au/Products/How_the_MedicAlert__emblem_protects [Accessed: 08-Apr-2016].<br> | ||
+ | [2] ‘Engraving’ [Online]. Available: https://www.medicalert.org.au/engraving [Accessed: 09-Apr-2016].<br> | ||
+ | [3] J. Tanous, ‘How, Why, and Why Not to Use the iPhone Medical ID’,Mobile, 29-Apr-2015. [Online]. Available: http://www.tekrevue.com/tip/iphone-medical-id/. [Accessed: 08-Sep-2015].<br> | ||
+ | [4] C. A. 4 Inc, ‘How It Works.’ [Online]. Available: https://www.code4armour.com/howitworks. [Accessed: 08-Sep-2015].<br> | ||
+ | [5] ‘EMR Medi-Chip Card.’ [Online]. Available: http://www.sgmscorp.com/safe-guard-medi-systems-corp -product-catalog/key-2-life-emr-category/emr-medi-chip-card/. [Accessed: 08-Sep-2015].<br> | ||
+ | [6] ‘ICD-10.’ [Online]. Available: http://apps.who.int/classifications/icd10/browse/2016/en [Accessed: 08-Apr-2016].<br> | ||
+ | [7] "ICD-10 overview," in MedicAid. [Online]. Available: https://www.medicaid.gov/medicaid-chip-program-information/by-topics/data-and-systems/icd-coding/icd.html. Accessed: Jan. 8, 2016.<br> | ||
+ | [8] pp. 24–29, 66–72, 126–130, 211–215, 324–329, 421–430, 485–490, 491–496. [Online]. Available: | ||
+ | [9] ‘Countries in the world by population (2016).’ [Online]. Available: http://www.worldometers.info/world-population/population-by-country/ [Accessed: 08-Apr-2016].<br> | ||
+ | https://www.dlapiperdataprotection.com/system/modules/za.co.heliosdesign.dla.lotw/functions/export.pdf?country=all. Accessed: Dec. 13, 2015.<br> | ||
+ | [10] ‘About AWS.’ [Online]. Available: http://aws.amazon.com/about-aws/ [Accessed: 28-Apr-2016].<br> | ||
+ | [11] ‘AWS Global Infrastructure.’ [Online]. Available: https://aws.amazon.com/about-aws/global-infrastructure/ [Accessed: 28-Apr-2016].<br> | ||
+ | [12] ‘Just how big is Amazon’s AWS business?’ [Online]. Available: http://www.geek.com/chips/just-how-big-is-amazons-aws-business-hint-its-absolutely-massive-1610221/ [Accessed: 28-Apr-2016].<br> |
Latest revision as of 05:18, 27 May 2016
Contents
- 1 TEAM
- 2 BACKGROUND
- 3 EXISTING SYSTEMS
- 4 HEALTH VISA SYSTEM
- 4.1 System Goals and Objectives
- 4.2 Description of the System
- 4.3 Countries of Operation
- 4.4 Regulatory Policies and Acts
- 4.5 Country Specific Regulations
- 4.6 Health Practitioner Regulation Agencies
- 4.7 Existing Infrastructure-Cloud Computing Systems
- 4.8 Operational Descriptions
- 4.9 Stakeholder Modes of Operation
- 4.10 Operational Procedures and Sequences of Events
- 4.11 System Context
- 4.12 System Interface Identification and Diagrams
- 4.13 Operational Scenarios
- 5 DELIVERABLES
- 6 REFERENCES
TEAM
Group Members
- Samuel Zevenbergen.
- Mingjie Qiu.
Supervisor
Client (Canadian)
BACKGROUND
There are an increasing number of people living with serious allergies, medical conditions and specific treatment wishes without the means of communicating this with First Responders and Paramedics in an emergency situation. There have been many situations where poor outcomes such as avoidable injury or death have resulted from medical treatments administered by medical professionals in emergency situations due to a lack of patient medical history.
The purpose of patient care/healthcare is for medical professionals to use their knowledge and experience as well as all available medical information and advanced directives to make a prompt and competent diagnosis leading to appropriate and correct treatment during a medical emergency. Currently it is in the patient's best interest to ensure they can communicate relevant medical information in case of an emergency. It is also the medical professional's obligation to respond in the correct manner to any medical information and reasonable wishes 07/19/ignoring-a-medic-alert-bracelet 1.
EXISTING SYSTEMS
Currently there are many devices and systems, which can be used by patients to communicate their treatment critical information with medical professionals in the case of emergency where they are unable to [1].
Despite the current number of options available, there are still cases where speed of access to information, amount and accuracy of information, language barriers, privacy, authentication, security, community awareness and location of the information have resulted in undesirable outcomes such as medical episodes and even death.
In response to this issue, a number of systems have been created, each with weaknesses around the amount of information available, time required to access information, data privacy and/or security. The below sections highlight the pros and cons of each system.
There are a number of systems available for people to communicate their medical details and treatment wishes with first responders. These include: Medic Alert (jewelry), Medical ID (Apple Inc.), Code4Armour and Key2Life systems. Each of these is described below in regard to their efficacy, language support, access requirements, amount of immediate/delayed information, community awareness, geographical footprint as well as privacy and authentication.
Medic Alert
Overview
The Medic Alert Foundation was founded in California in 1953, but now has affiliates in 9 other countries. They are the only non-profit organisation that hires ‘highly skilled medical response personnel’. They offer a range of jewelry (bracelets, anklets and necklaces) with medical information, treatment wishes and ID number engraved on them. To get a medic alert tag, you must purchase the jewelry online, create an online profile, specify details to be engraved and pay an annual subscription fee, which are all dependent on the country you live in. If your medical information changes, you have to purchase a new tag or pay for your current one to be smoothed and re-engraved (which can only be done once or twice) [1][2].
Pros
- MedicAlert has a proven efficacy.
- Significant language translation service available.
- Good community awareness of the system.
- Significant geographical footprint (9 countries in total).
Cons
- Small amount of immediately available information (only what is engraved on the bracelet).
- There is an extensive delay to obtain further medical information (relayed via phone or fax).
- The system lacks privacy as anyone can access your medical records by reading them off your bracelet.
- There is no authentication required to access the initial information (from your bracelet).
iPhone Medical ID
Overview
Many people have a contact labelled ‘ICE’ - ‘In Case of Emergency’ on their phone, but they have a passcode, which disables anyone from accessing it in an emergency. Apple has developed a medical ID application, which can be enabled on any iPhone with a minimum of iOS-8 installed. This allows anyone to access your medical information such as allergies, blood type and medications as well as your emergency contact details. It also allows them to use your phone to contact your emergency contacts, even if your phone is locked [3].
Pros
- The amount of information immediately available is significantly greater.
- Exists on a popular phone.
- Significant geographical footprint.
Cons
- There efficacy of this system has not been proven.
- No language translation support.
- Minimal community awareness.
- This system is lacking privacy.
- No authentication required in order to access medical records. No record of someone accessing your records.
Code4Armour
Overview
Code4Armour is a new technology in which you buy and wear a passive bracelet on your wrist. To set this up, you pay an annual subscription fee, create an online account and upload your personal, medical and emergency contact details. Anyone with a Near Field Communication (NFC) capable phone and the free Code4Armour™ app can bring up your details on their phone by scanning your bracelet. There are two types of people (general users and first responders who must be verified) [4].
Pros
- The amount of information immediately available is significantly greater.
- Exists on popular devices.
Cons
- There efficacy of this system has not been proven.
- No language translation support.
- Minimal community awareness.
- There are specific hardware and software requirements in order to access records.
- This system is lacking privacy.
- No authentication required in order to access medical records. No record of someone accessing your records.
Key2Life
Overview
Key2Life is an emerging company offering many medical ID devices, from wearable USB sticks, tags with NFC technology, and cards with magnetic strips and/or QR codes. These systems generally require a once off payment for purchase, with no recurring subscription costs. In a medical crisis where you may be unable to speak for yourself, civilian laypersons and medical physicians can access your information from a computer or a smartphone with NFC/QR reader capabilities. There are some evident hardware and software requirements in order to access the information stored in these devices [5].
Pros
- The amount of information immediately available is significantly greater.
- Geographical footprint is large, but user base is small.
Cons
- There can be a significant delay in order to access any information (you may need to plug a USB into a computer for example).
- There efficacy of this system has not been proven.
- No language translation support.
- Minimal community awareness.
- There are specific hardware and software requirements in order to access records.
- This system is lacking privacy.
- No authentication required in order to access medical records. No record of someone accessing your records.
Summary of Existing Systems
From the above summaries of current technologies, it should be clear that many of them are relatively complete, but have downfalls. The below figure is a diagrammatic comparison of the already discussed technologies and the completeness of features, which are most important for an efficient system like this. The key point to be made from this diagram is that all current existing systems have major privacy and authentication issues.
HEALTH VISA SYSTEM
System Goals and Objectives
The goal of the Health Visa system is to provide as much information which is relevant
to a user should they find themselves in a medical emergency.
The short term objectives of the Health Visa system are listed below: -
- The system will provide sufficient and relevant medical information, quickly and securely to Medical Professionals and Public Laypersons’ in the event of a medical emergency.
- The system will have a low cost for the end user, facilitating significant growth.
- A positive cost benefit relationship will be apparent to the public.
- The system will be up to date with the relevant and current acts, regulations and standards.
- The empowerment offered to the end-user will be evident as they have full authority and control of their personal information which includes sensitive medical records.
The long term goals of the Health Visa system are listed below: -
- The reach of the system will increase as time goes on. The system is to be implemented in all considered countries within a small timeframe, with further countries expected to be included in the future.
- All members of the public, including young and old will have the available assistance (if required) to become a registered user of the system.
Description of the System
The fundamental objective of the Health Visa system is to overcome the privacy, authentication and security issues associated with all existing medical information systems. The designed system will work across a range of regulatory boundaries, allowing for secure and prompt access to Registered General Users’ medical records during a medical emergency.
It should be noted that the focus of the designed Health Visa system focuses on the back-end security and authentication protocols required to satisfy a range of privacy and data laws around the world, in particular the eight countries listed below.
The Health Visa system will allow for quick access to available medical records during a medical emergency. For example, Paramedics/Medics will have the ability to scan a QR code on a Visa card or bracelet to get access to a Registered General Users’ available medical records. One key aspect to the success of this system is that the user effectively owns their own data, has maximum control over it and thus feels empowered. With this, there will be varying levels of privacy: The user will have the ability to control what information they share with Medical Professionals and Public Laypersons. There will also be a log of who has accessed their information (name, date, location, etc.), which will help discourage abuse and increase accountability for all system users.
There will be three broad classes of system users: Public Laypersons, Registered General Users and Medical Professionals which includes Primary Care Providers, and Paramedics/Medics.
The Health Visa system will allow for different authentication methods (some examples include driver's license, QR code on a visa card and biometrics such as: fingerprint, eye recognition, voice recognition, etc. The Health Visa concept design is not concerned with the authentication methods used, but must allow for a sufficient number of methods, which are continually evolving which are expected to change over time.
Public Laypersons (either Registered General Users or not) will require 2 points of authentication (out of a number of possibilities) in order to access information, whereas Paramedics/Medics only need 1 point. This is because medical professionals generally require information quickly and they are already verified within the system and thus given this privilege.
Language translation is another useful function which is contained within the Health Visa system. In order to facilitate effective communication of information, especially across countries with differing languages, it is necessary to include automatic translation of medical information. An easy and consistent way to implement this language translation function is to use ICD 10 for direct translations of medical terms, thus ensuring the medical records are interpreted correctly and further reducing any risk [6][7].
It should be emphasized that the Health Visa system has been designed to be implemented across the eight considered countries initially, with further expansion expected in the future. Language translation is already pertinent to the initial deployment across these eight countries as there are a minimum of three primary languages (English, Estonian and Korean).
Countries of Operation
- Australia.
- United States of America.
- Canada.
- Estonia.
- Israel.
- New Zealand.
- South Korea.
- United Kingdom.
Regulatory Policies and Acts
1. Australia
- The Privacy Act, 1988.
- The Spam Act, 2003.
2. United States of America
- Health Insurance Portability and Accountability Act, 1996.
- Children’s Online Privacy Protection Act, 1998.
- Health Information Technology for Economic and Clinical Health, 2009.
- CAN-SPAM Act, 2003.
3. Canada
- Personal Information Protection for Electronic Documents Act, 2000.
- Personal Health Information Privacy and Access Act, 2004.
- Personal Health Information Act, 2008.
- Canadian Anti-Spam Legislation, 2009.
4. Estonia
- Personal Data Protection Act, 2007.
- Electronic Communications Act, 2004.
- EU General Data Protection Directive 95/46/EC, 2000.
- Information Society Services Act, 2004.
5. Israel
- Human Dignity and Liberty Law (the Basic Law), 1992.
- Protection of Privacy law (the Privacy Law), 1981.
- Protection of Privacy Regulations, 2001.
6. New Zealand
- The Privacy Act, 1993.
- Health Information Privacy Code (1994) and Commentary Version 2008.
- Unsolicited Electronic Messages Act, 2007.
7. South Korea
- The Personal Information Protection Act, 2011.
8. United Kingdom
- The Data Protection Act, 1998.
- The Privacy and Electronic Communications Regulations, 2003.
- EU General Data Protection Directive 95/46/EC, 2000.
Country Specific Regulations
All Country Specific Relations below were identified from the ‘Data Protection Laws of the World’ document defined in the document referenced [8].
1. Australia
2. United States of America
3. Canada
4. Estonia
5. Israel
6. New Zealand
7. South Korea
8. United Kingdom
The system facilities the flow of medical records across these regulatory boundaries with the user’s consent, such that this information can be accessed in other countries during times of business and/or leisure travel.
The figure above highlights all countries which have been considered within the scope of the Health Visa system. These countries contribute approximately 632 million people or 11.3% to the world’s population. It is expected that the designed system would be deemed acceptable in many other countries, but further investigation and design may be required in countries not covered within the design scope [9].
Health Practitioner Regulation Agencies
All Health Professionals must have their credentials verified in order to become a verified system user. A list of Health Practitioner Regulation Agencies in each country and their associated website link are provided in Table below:
Existing Infrastructure-Cloud Computing Systems
Amazon Web Services (AWS) is a well-established and trusted cloud computing system that allows users to operate with minimal up-front capital and system maintenance costs. Table below summarizes some key characteristics of the AWS system [10]. Although AWS has been discussed in the context of the Health Visa System, there are many other cloud computing systems which are suitable for implementation of the Health Visa system as it is expected that all system requirements can be satisfied [11][12].
Operational Descriptions
The table above summarizes all stakeholders associated with this system and their corresponding classification, influence and power.
Stakeholder Modes of Operation
It should be highlighted that different users will be provided with varying amounts of information as specified by the user themselves. The information specified as available by the user is expected to be influenced by Primary Care Providers advice, however the final decision is in the hands of the user themselves. In medical emergency situations where system users believe there may be additional information within the system, which may result in saving a life; they may assert a ‘Medical Emergency Override’. An outcome of this action is a ‘red flag’ within the system, in which the user themselves receives notification of. It should be noted that a Public Layperson will require a release code (which may be provided by the relevant Emergency Call Service) in order to assert a medical emergency. Figure below illustrates this concept.
Operational Procedures and Sequences of Events
A number of figures are provided below for purposes of comparing how Operational Procedures and Sequences of Events currently occur in an existing medical information system, and how they are expected to occur in the proposed new Health Visa system.
The above figure illustrates how a typical user becomes a registered user on a typical existing medical information system and on the new Health Visa system. Below is a list of associated benefits pertaining to the new proposed system: -
- The user can become a verified, active user much quicker.
- The user is empowered as they have full control over their personal medical information by means of access filters.
- All medical records are verified by a qualified Primary Care Provider prior to being a ‘verified’, active user of the system.
The above figure illustrates how Professional Users (Primary Care Providers and Paramedics/Medics) become registered, verified users on a typical existing medical information system and on the new Health Visa system. It is highlighted that such a user is not recognized with existing medical information systems. These Medical Professionals may phone the 24/7 hotline and state their profession but this is never exclusively checked and verified before disclosing medical records (all they require is the medical information system ID number). The new system includes a mechanism for Medical Practitioners (Primary Care Providers and Paramedics/Medics) to create an account and get their credentials verified prior to having a fully operational account. Below is a list of associated benefits pertaining to the new proposed system: -
- You must be registered with your relevant Health Practitioner Regulation Agency in order to create a ‘Medical Practitioner’ account, which includes Primary Care Providers and Paramedics/Medics.
- The system will know when your registration expires and ensure that registration is continually renewed, thus reducing risk of abuse by professionals which have had their registration revoked for any reason.
The above figure illustrates how Public Layperson and Medical Professionals may access an individuals’ medical records, both on the existing medical information system and the proposed new Health Visa system. It is evident that existing medical information systems provide minimal medical information up-front, with no authentication required. Additional information can be obtained but typically takes a long time to acquire. Below is a list of associated benefits pertaining to the new proposed system: -
- All medical records can be obtained almost instantly, following required security checks.
- System security is much stronger, with system users being locked out after a set number of invalid attempts.
- The system does not rely on only 1 identifier. For example, someone may access an individuals’ medical records if they possess two of three registered identifiers.
System Context
The above figure illustrates how the proposed new Health Visa system may be integrated with a typical existing medical information system. The following points summarize the key ideas illustrated in the noted figure: -
- The existing Customer Support Centre will support users on the existing and new systems. New hardware and software are expected to be required within the Customer Support Centre, followed by staff training before commissioning of the new system.
- New Health Visa Cloud Computing System to be commissioned independently of any existing Server and Database Infrastructure.
- New System shall comprise many compatible identifiers, which are ever evolving and are expected to change in the future.
- Users are either on the existing or new system. They are given the choice to migrate to the new system or remain on the existing system. After an appropriate time period, the existing system can be decommissioned as determined by the acquirer.
The above figure illustrates how the proposed new Health Visa system will operate. The following notes summarize the key points covered in the previously mentioned figure: -
- The Team of Developers will develop and commission the new system. It is expected that a subset of this team will then form the Design and Maintenance Team which will ensure the system is operational and up-to-date.
- The key role of Primary Care Providers is to verify the medical records of Registered General Users, ensuring they are accurate.
- It is understood that the Health Visa Cloud Computing System may be implemented on AWS, however any other system which allows all system requirements be satisfied is acceptable.
System Interface Identification and Diagrams
Please note the following abbreviations have been used to describe system attributes in the next sections: -
Team of Developers: TOD
Health Visa Cloud Computing System: HVCCS
Public Laypersons + Paramedics and Medics: User Group
Primary Care Providers: PCC
Design and Maintenance Team: DMT
Customer Support Centre: CSC
Health Practitioner Regulation Agency: HPRA
Interface 1 : TOD – HVCCS
- The Team of Developers shall complete the initial development of the Health Visa system. They take the System Requirements document, further refine the design and commission the Health Visa system.
- They must have the ability to upload and test code during development.
Interface 2 : User Group – HVCCS
- Pubic Laypersons and Paramedics/Medics were identified to have similar characteristics. Both user groups can be used to simplistically access medical records, having minimal differing characteristics.
- These users can both obtain personal identifiers, transfer them to the system and be provided with medical records should all verification tests pass. The key difference is that Paramedics and Medics require only one identifiers, while Public Laypersons require two.
Interface 3 : RGU – HVCCS
- Registered General Users require the ability to create an account, add personal information and medical records and much more. This user type is the most sophisticated and has the most functionality.
Interface 4 : PCP – HVCCS
- Primary Care Providers require the ability to create an account, access Registered General Users medical records and verify them. The amount of functionality required to access and verify these medical records is significant.
Interface 5 : DMT – HVCCS
- The Design and Maintenance Team are responsible for the continuous technical support, maintaining, updating and expansion of the Health Visa System. They are the key system user between the Customer Support Centre Staff and the Health Visa Cloud System, providing technical support when required.
Interface 6 : CSC – HVCCS
- The Customer Support Centre are responsible for the continuous support of all system users. They must be able to access the Health Visa database to provide effective support to all customers.
Interface 7 : User Group – CSC
- The Customer Support Centre are responsible for the continuous support of all system users. They must be able to access the Health Visa database to provide effective support to all customers.
Interface 8 : RGU - SCS
- The Customer Support Centre are responsible for the continuous support of all system users. They must be able to access the Health Visa database to provide effective support to all customers.
Interface 9 : PCP – CSC
- The Customer Support Centre are responsible for the continuous support of all system users. They must be able to access the Health Visa database to provide effective support to all customers.
Interface 10 : DMT – CSC
- The Customer Support Centre must be able to attain support from the Design and Maintenance Team when issues arise.
Interface 11 : CSC – HPRA
- The Customer Support Centre must communicate with relevant Health Practitioner Regulation Agencies in order to verify that specific Medical Professionals are credible and therefore hold up-to-date registration.
Operational Scenarios
All operational scenarios use examples on an individual’s identity may be verified. For example, by use of a QR code on a Visa card, finger print, facial recognition, etc. It should be highlighted once again that these are used as example identification and verification methods only and does not suggest that these would be implemented. Verification methods of identifying individuals is continually evolving and thus not a key focus of the designed Health Visa system.
Scenario 1 – Normal Operation
An elderly woman discussed treatment options for her obesity problem. The doctor suggested the option of post-gastric bypass surgery, in which she decided to go ahead with. The woman followed her doctor’s suggestion that she list the operation on her Health Visa account as there was a risk of complications following the surgery.
A short time later, she was out shopping in a busy shopping mall where she lost consciousness and collapsed. Many members of the public rushed to her aid. During the commotion, a number of medical conditions were mentioned as being possible causes of the medical event. One member of the public scanned her QR code and fingerprint into their smart phone. Before paramedics arrived to treat the woman, this member of the public was able to notify of the woman’s recent surgery. This lead to prompt and accurate treatment, in which she was intubated and fully recovered in hospital. Had this information not been available, wrong or delayed treatment would have likely been a result. This amount of information, verification and timely access does not exist with all existing medical information systems.
Scenario 2 – Lost Child
During a family holiday to Disney Land, a four-year-old boy becomes separated from his parents in a large crowd. This child, clearly distressed is approached by a staff member and asked if he knows where his parents are. This child does not know where his parents are, let alone their contact details, but states that he is registered on the Health Visa system. This staff member opens the Health Visa application on their smart phone, scans the boy’s finger print and takes a photo of his face for identification and verification purposes.
After sending this information to the Health Visa system, a match is identified, with the boy’s medical records and emergency contact details being presented to the staff member. This staff member then selected to contact the emergency contact via phone, directly allowing for the parents to quickly find their lost son.
Scenario 3 – Overseas Travel
A young homosexual, adult male was required to travel on business to Russia in which he was nervous about as he felt that there was a stigma associated with homosexuality within the country. Although he recognized that his sexuality was not illegal in the country, he realized that they still have a law against ‘propaganda of homosexuality’ which made him feel uncomfortable.
This young man was a registered user on the Health Visa system and had a sexually transmitted disease (STD), which is commonly recognized as being associated with homosexuality. This young man decided to adjust his privacy settings before he travelled to Russia such that this (non critical) infection and his next of kin, who was also a male would not be released to any users of the system. In order to retain an emergency contact, he selected to provide his mother’s contact details in a medical emergency.
When this man travelled to Russia, he was involved in a serious car crash. The first public layperson at the scene searched the man’s wallet, located and scanned his QR code located on his Visa card. This identification entry along with a photo of his face was sent to the Health Visa system for identification and verification purposes. The public layperson was issued with his available medical information, including serious allergies to certain medications. This allowed him to receive the appropriate care based on his needs, while his non critical illness remained private.
DELIVERABLES
The key deliverables for this project were a Concept of Operations (ConOps) document and a System Requirements Document (SRD) which both focus on the data privacy, security and regulatory requirements in order to operate across the noted countries.
The following items were also important deliverables of this project: -
- A demonstration walkthrough video was also created which clearly shows the operational differences between a typical existing system and the new Health Visa system.
- Pitch deck, which will be used to present the key benefits of the Health System to potential investors.
REFERENCES
[1] ‘How the MedicAlert emblem protects.’ [Online]. Available: https://www.medicalert.org.au/Products/How_the_MedicAlert__emblem_protects [Accessed: 08-Apr-2016].
[2] ‘Engraving’ [Online]. Available: https://www.medicalert.org.au/engraving [Accessed: 09-Apr-2016].
[3] J. Tanous, ‘How, Why, and Why Not to Use the iPhone Medical ID’,Mobile, 29-Apr-2015. [Online]. Available: http://www.tekrevue.com/tip/iphone-medical-id/. [Accessed: 08-Sep-2015].
[4] C. A. 4 Inc, ‘How It Works.’ [Online]. Available: https://www.code4armour.com/howitworks. [Accessed: 08-Sep-2015].
[5] ‘EMR Medi-Chip Card.’ [Online]. Available: http://www.sgmscorp.com/safe-guard-medi-systems-corp -product-catalog/key-2-life-emr-category/emr-medi-chip-card/. [Accessed: 08-Sep-2015].
[6] ‘ICD-10.’ [Online]. Available: http://apps.who.int/classifications/icd10/browse/2016/en [Accessed: 08-Apr-2016].
[7] "ICD-10 overview," in MedicAid. [Online]. Available: https://www.medicaid.gov/medicaid-chip-program-information/by-topics/data-and-systems/icd-coding/icd.html. Accessed: Jan. 8, 2016.
[8] pp. 24–29, 66–72, 126–130, 211–215, 324–329, 421–430, 485–490, 491–496. [Online]. Available:
[9] ‘Countries in the world by population (2016).’ [Online]. Available: http://www.worldometers.info/world-population/population-by-country/ [Accessed: 08-Apr-2016].
https://www.dlapiperdataprotection.com/system/modules/za.co.heliosdesign.dla.lotw/functions/export.pdf?country=all. Accessed: Dec. 13, 2015.
[10] ‘About AWS.’ [Online]. Available: http://aws.amazon.com/about-aws/ [Accessed: 28-Apr-2016].
[11] ‘AWS Global Infrastructure.’ [Online]. Available: https://aws.amazon.com/about-aws/global-infrastructure/ [Accessed: 28-Apr-2016].
[12] ‘Just how big is Amazon’s AWS business?’ [Online]. Available: http://www.geek.com/chips/just-how-big-is-amazons-aws-business-hint-its-absolutely-massive-1610221/ [Accessed: 28-Apr-2016].