Reference no: EM131015190

Medical Records System Background

The medical records system (MRS) is based on a discussion of an electronic health care system in Tanenbaum & Van Steen (2014, pp. 25-6). However rather than real time monitoring, we will approach it from the view point of an Australian citizen having the right to register and control personal health information in the eHealth system (https://www.oaic.gov.au/privacy-law/other- legislation/e-health-records). Our objective is to see if we can model this distributed computer system and study security scenarios for maintaining privacy.

In our simplified scenario, citizens, for the most part use mobile devices to access MRS. MRS is therefore a "Distributed Pervasive System" (Tanenbaum & Van Steen 2014, p. 24). Citizens can view, amend and save their health information. MRS can extract the metadata and perform analyses on this data and make the results available to registered medical practitioners and researchers. Using medical databases of health records is very important in current biological and medical research. For example, matching of DNA profiles to medical records has pointed to how DNA plays a role in disease.

MRS has administrators who monitor the system and check that privacy is maintained. In this MRS assignment, your team is tasked with producing a working model of MRS without security features implemented. In the next MRS assignment your team will implement security features and rogues who must defeat the security measures to "hack" and "steal" medical information, they could conceivably mount a denial of service attack on MRS. In the final assignment teams will test the security of other MRS models.

In this assignment, your team objective is to produce a model that demonstrates interesting behaviours in MRS and gives useful insights into distributing computing. The only constraint is that your IT manager must be able to run the model on his Windows 10 laptop.

Ethics and Sustainability.

A working definition of sustainability is "doing more with less" and ethics is "doing what ought to be done". How can your team apply these concepts to modelling MRS? It is suggested that the smallest model world with the least code and variable overheads that still demonstrates interesting and useful behaviour should be your goal. In your submission show how you have paid attention to sustainability and discuss the ethical choices involved in the design process.

In modelling, the more complicated the coding, the greater the chance that model behaviour may be an artefact of poor coding and unforeseen variable dependency interactions. Your team need to consider this when making conclusions about observed behaviour.

The heart of MRS is the right to privacy of the individual. Therefore, ethical considerations require close attention to designing, implementing and testing security policies. Making the MRS model complicated for Assignment 2 will increase the difficulty of adding security features in the next assignment.

A Suggested Approach.

You are free to design and implement the NetLogo MRS model to satisfy the assignment objectives in any way subject to time and course constraints. In this and following sections a suggested approach is given for modelling MRS.

A starting point for the following discussion is the wolf-sheep predation model from the installed library. NetLogo uses patches as a sort of background turtle. Figure 1, below shows patches that represent grass (green) and areas depleted of grass (brown).

Figure: olf Sheep Predation Model

In the NetLogo MRS model, a patch represents a Wi-Fi hotspot or local cell in the mobile phone network. A patch may have excellent, good, acceptable, poor or no reception. The patch reception determines the probability of communicating successfully. Not all patches have the same reception and indeed reception changes over time as MRS administrators carry out maintenance. Provide a means of determining patch reception at setup. See examples of models for setting up variables using sliders, switches and entry fields.

There are many examples of calculating probabilities. You IT Manager's personal experience is that all variable declarations should be prominently featured and documented in code so as to help in understanding model issues.

When a citizen crosses a patch they attempt to establish a communication link with MRS. Note that the patch may be congested. In this model, a congested patch has the effect of decreasing the quality of reception. Set a variable slider to control the number of co-located citizens on a patch and how congestion modifies reception. Careful attention should be paid to how all turtles move.

There is information in the tutorials, the manual and models to help you decide how to do this. This movement algorithm, together with other algorithms should be documented by comments.

The question arises as to how often would a citizen wish to enter new data, view existing data and amend their data. It could be assumed that when a citizen enters data for the first time, within a week, they may have three interactions of viewing and/or amending, and there after perhaps interact once a month. On the other hand citizens with health issues would do more frequent checks/edits while others of good health may have few interactions. Setup a slider to control initialisation of MRS behaviour and an algorithm to change behaviours over time. It is foreseen that citizen behaviour will vary according to perceived health issues in their community. For example influenza injections at the start of winter. Include a mechanism for this type of behaviour.

MRS Data and Interaction.

In MRS, a citizen has 3 health information tokens, the first is their private identifying data (T1) and the second is their health data (T2). The third is health metadata (T3) that is generated by MRS. T3 is available to registered health practitioners and researchers for analytical purposes. All three tokens are subject to privacy constraints. Only T1 and T2 may be viewed and edited by a citizen. T1, T2 and T3 may be viewed by an authorised administrator. A practitioner or researched may only view T3.

During an interaction between a citizen and a patch:

1. The patch records a citizen's interaction by counters, it amends the t3 counter when the citizen interaction has occurred.

2. A citizen enters, checks or amends their personal identity and health tokens (increments their own counters).

Each NetLogo step is equivalent to a day. If a citizen has entered their data for the first time, then they could check and amend on a future Netlogo step. Avoid loitering at patches.

In assignment 2, the administrator upon entering a patch increments their personal patch check and the patch count. This signifies a successful check. Note

that an administrator adds to congestion. Your team should decide what a reasonable interaction frequency is for this assignment where there is no security role for the administrators. Patch congestion should be tracked.

The registered practitioner or researcher interacts with a patch on fewer occasions than the administrator to gain access to metadata. Like administrators, practitioner interactions contribute to congestion.

State changes.

In real life MRS use will change and possibly reflect the changes of the health in the population, the amount of money budgeted for administrators and the perceived value of metadata to practitioners and researchers.

In the NetLogo MRS model it is suggested that the health of citizens be changed at intervals determined by a slider, similarly for patch reception, and so on.

What would happen in a (say) influenza epidemic?

In times of budgetary constraints the number of administrators will be decreased. Since administrators monitor security, this will be important for future assignments.

The issue of Time.

Your team needs to consider when or if a models run should terminate. Would this be after an elapsed number of steps? When all (or a nominated percentage of) citizens have entered their information? Or other condition important in their model.

The performance of MRS over time as parameters of the system are changed must be tracked. Teams need consider what amounts to a series of key performance indicators and show them appropriately in a histogram (for example).

Deliverables for Assignment.

The document load parameters of Moodles are currently set at 2 megabytes. This can be raised if required.

1. The exported team model of the Netlogo MRS model.

2. A design document, showing how you made the decisions and alterations to the MRS model as you developed and used the model. As a suggestion, use the Info tab.

3. A "next steps" discussion/plan for implementing security. Use the Info tab, but include comments in the code section where you think changes will be made for implementing security.

Assignment Preview.

In assignment, rogue hackers are introduced. Rogues may interact with all other turtles to gather information for the purposes of hacking MRS. A trust variable will be required to be introduced in all Turtles (including patches) that ranges from low trust (little chance of interaction) to high trust (always interacts).

In the patch, the trust variable represents decisions by the designers on the degree of authentication required to allow interactions with users that is how much do the designers of MRS trust users?

Administrators check for rogue infiltration. They also provide training to citizens (increases their trust in the system and lowers trust towards rogues).

References
Tanenbaum, A.S. & Van Steen, M. 2014, Distributed Systems: Principles and Paradigms, Pearson Education Limited, UK.