CHIA C Flashcards

1
Q

Data Structure - Array

A

store elements of the same type in a specific order and are accessed by indexing. Arrays may be one dimensional (vectors) or two dimensional (matrices).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Data Structure - Linked lists

A

comprise groups of nodes that together represent a sequence. Each node consists of a datum (an instance of data) and a link to the next node(s) in the sequence. The last node is linked to a terminator used to signify the end of the list.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Data Structure - Stack

A

store elements where the last element in is the first one out (LIFO). New elements are added (‘pushed’) onto the top of the stack, and the first elements to be removed (‘popped’) are also taken from the top since they were the last ones in.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Data Structure - Queue

A

are basically the opposite of stacks, using a first-in, first-out (FIFO) rule. Queues are used where elements are processed in the order they arrive (e.g., a print queue).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Data Structure - Tree

A

start with a root value (parent) and branch out into sub-trees of children, represented as a set of linked nodes. Each node contains a datum and one or more pointers to other nodes.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Data Structure - Graphs

A

comprise sets of ordered pairs called edges/arcs and entities called nodes/vertices. An edge (x, y) is points from x to y.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Data Structure - Table

A

are used to store elements that may, for example, be inserted in the table, searched for or perhaps deleted. Tables are mutable data structures.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Data Structure - Sets

A

store certain values without any particular order and no repeated values. This corresponds to the mathematical concept of a finite set.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Math model for linear vs binary tree search

A

linear = n/2, binary = log2n, always less steps for binary

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Data types and what determine (4)

A

integer, boolean, alphanumeric, strings
- possible values, operations to be performed, meaning of data, ways data can be stored

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Algorithms are:

A

“An algorithm is an explicit, precise, unambiguous, mechanically-executable sequence of elementary instructions”

Algorithms are step-by-step procedures for calculating or problem-solving. They are used to manipulate the data contained in data structures. Commonly used algorithms include searching for particular data items or records, sorting data and performing calculations such as generating body mass indexes from heights and weights.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Algorithms complexities (3)

A
  1. Contitionals (different steps depending on specificed boolean condiution is true/false)
  2. Loops (steps specified once and carried out multiple tiomes, either specified number or until condition is met)
  3. Recursion (solution to a problem depends on smaller instances of the problem)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Abstraction

A

Real-world problems have many superfluous details. An essential step in problem-solving is identifying the underlying abstract problem devoid of unnecessary detail. Once issues are abstracted, it becomes apparent that seemingly different problems are essentially similar

As far as possible, abstract data structures are used to store data, and abstract algorithms are used to manipulate them.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Compiled Language and examples

A

In a compiled language, the programmer writes more general instructions and a compiler (a special piece of software) automatically translates these high-level instructions into machine language. The computer then executes the machine language. A large portion of the software in use today is programmed in this fashion. Examples include “C”, C++, Pascal, Cobol, Fortran, ADA and Java (Holowczak, 2014).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

interpreted programming language

A

In an interpreted programming language, the programmer’s statements are interpreted as the program is running. Examples include Basic, Visual Basic, Perl, Python and shell scripting languages such as those found in the UNIX, Linux and MacOS X environments (Holowczak, 2014).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

History of programing

A
  1. Binary
  2. Syymbolic programing
  3. low level programing
  4. Produrdal programming (split task into smaller tasks)
  5. Structure programming (top down approach)
  6. Function programming (model the problem not solution)
  7. Logic programming (database logical inference)
  8. Object orientated (modular code with object having attributes and behaviours)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Program structure - Pattern

A

Virtually all structured programs share a similar overall pattern – statements to establish the program’s start, declaration of the variables involved and blocks of code (Holowczak, 2014).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Program structure - Variable

A

Variables are named so that they can be referred to and typically store values of a given data type. They are ‘declared’ at the program’s start because the compiler needs to know the type of data stored in it in advance. Different programming languages have slightly different syntax and data types.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Program structure - Blocks of code

A

Blocks of code typically express operations and logic.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Program structure - Boolean logic

A

Boolean logic is two-valued, allowing only two truth values – ‘true’ and ‘false’. A Boolean expression is a set of logical operands (statements that can be proven true or false) and logical operators that connect them (AND, OR, NOT, EQV [logical equivalence] and NEQV [logical non-equivalence]).

Boolean expressions often also involve comparison operators that can be evaluated to determine true or false. Comparison operators include >, <, ≥ and ≤.

Boolean and comparison operators are written differently in different programming languages.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Control statements “control” which code sections in a program are executed. There are three general types of control statements

A

• Sequential – the default ordering of program execution.
• Decision (conditional) – controls which block of code is executed from alternatives based on ‘if… then …else’ logic. The ‘ if ‘ block of code is executed when the ‘if’ statement equates to ‘true’. If it equates to ‘false’, the code associated with the ‘else’ statement is executed.
• Iterative – controls how many times a block of code is executed. The two main iteration categories are FOR and WHILE/DO loops.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Iterative Control statements - FOR, WHILE, DO

A

Simple FOR loops iterate a specific number of times the loop is executed based on counting up (or down) on an integer variable. Generally, the three parts of a FOR loop are the initialisation (the initial or starting value), the condition (the condition under which the loop will stop), and the increment or decrement.

WHILE and DO loops are also used to repeat a code section a number of times. However, where FOR loops specify some count, WHILE and DO loops repeat while a condition is true. The condition is a Boolean expression that we can evaluate as ‘true’ or ‘false’. As soon as the condition evaluates to ‘false’, the loop ends.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Benefits of life cycle management

A
  1. Planning for logevity (system level)
  2. Optimise value (system level)
  3. portfolio management (organisation levelZ)
  4. Risk Management (organistaion level)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Information system lifecycle - Defining

A

The information system lifecycle and information system projects begin with the emergence and acknowledgement of a business issue.
The issue at hand must be identified, explored and defined before an information system solution is considered. There may well be other approaches that do not involve information systems at all.

25
Q

Information system lifecycle - Planning

A

Three key elements of the planning phase warrant particular attention – analysing requirements, architecting solutions and planning the systems lifecycle.

26
Q

Information system lifecycle - Obtaining

A

Three key activities in the obtaining phase include analysing procurement options, acquisition or development, and testing

27
Q

Information system lifecycle - Implementing

A

Critical elements of the implementation phase include building capacity, deploying and post-implementation review.
Implementations always involve changing how things happen and provide opportunities to leverage change windows to optimise improvements. But, to state the obvious, change is the only way that either benefit is realised or, as unfortunately happens from time to time, damage is done.
Change, in any circumstance, is rarely uni-directional. Different stakeholders may have different perspectives, and even overwhelmingly positive changes usually have some downsides.

28
Q

Information system lifecycle - Operating and maintaining

A

As for any asset, optimising the return on investment on information systems, whether quantitatively, qualitatively, or both, involves maximising benefits and minimising ongoing costs while ensuring that the system remains sustainable. As the system is used, it must be assessed periodically to ensure that it meets stakeholders’ initial needs and that value – whether anticipated or not – is being realised. Inevitably, new issues arise, and stakeholder needs evolve, which may necessitate adaptations to the system.

29
Q

Information system lifecycle - Disposal

A

Disposal aims to remove substantial parts of a system or close it down entirely. There are two significant activities – decommissioning and disposal.

Decommissioning
For this Guide (others may see it differently), decommissioning includes:
• Deciding to close (parts of) the system should be undertaken after evaluation and should be coherent with plans to replace or enhance the system’s functionality if required.
• Planning for orderly transition or exit. There are various approaches to transition – as described in Table C.3 above. Transition includes preserving key information about the system so that some or all of it may be reactivated in the future if necessary and key information from the system that can continue to be used. A decommissioning and disposal plan should identify how, when, where, why the termination and preservation (where required) of the system and the data will be undertaken, and who will do what.
• Data migration or archival.
• Removal of the system from active use.

Disposal
This activity comprises the physical disposal of depreciated assets (hardware, software, data, etc.), leading to either reuse in another context/by different stakeholders, or destruction. It must be borne in mind that there are numerous examples of accidental loss or exposure of sensitive data – totally unacceptable and avoidable issues.
A post disposal report should be compiled to ensure that the decommissioning and disposal plan has been followed and that issues have been satisfactorily addressed.

30
Q

Information system lifecycle -

A

.

31
Q

PESTLE is a commonly used approach to environmental analysis, explicitly considering the problems in terms of:

A

Politics – small and large “p”.
Economics.
Social dimensions.
Technologies.
Legalities.
Environment and sustainability

32
Q

The main steps in reference class forecasting are to

A

• Select a reference class by identifying important requirements to compare and then identifying projects/scenarios with similar needs.
• Investigate those reference sites and prepare a distribution of outcomes reflecting differing contexts.
• Use the information derived to validate or critique the forecasts in the current study.
The strength of reference class forecasting

33
Q

Common issues with cost-benefit analysis

A

• Costs are underestimated, or only initial (development) costs are considered.
• Benefits are over-estimated, or the period required for their realisation under-estimated.

34
Q

Information system lifecycle - Planning - Requirements

A

Since it is the requirements against which success is ultimately assessed, it is imperative to:
• Identify, articulate, test and validate them.
• Ensure they reflect the consensus or negotiated views of key stakeholders, where a key stakeholder is defined as one whose involvement is material to the success or failure of the project.
• Articulate them unambiguously.
• Have agreement amongst the key stakeholders on how their satisfaction will be determined.
However, inadequate requirement analysis features in many ‘challenged’ projects

35
Q

Information system lifecycle - Planning - Operational Concept

A

operational concept document generally includes a narrative concerning:
• The goals and objectives of the system under consideration.
• Drivers, strategies and constraints that will affect the system and its operation.
• Relevant actors and activities and the relationships and interactions between them.
• Specific operational processes relating to the system.
• Processes for initiating, developing, maintaining and retiring the system. (Note: it describes a methodology for realising the goals and objectives for the system – it is not an implementation or transition plan.)

36
Q

Information system lifecycle - Planning -Specifications of Requirements (15)

A

Desirable characteristics of requirements include the following, based largely on the work of Posthumus (2011). Each requirement should be:
• Traceable to authoritative documentation.
• Objective - containing agreed “facts”, not subjective opinions.
• Unitary – it should address only one aspect of the system.
• Complete – fully stated in one place with no missing information.
• Constrained – any relevant constraints or conditionality associated with the requirement are articulated.
• Consistent – it does not contradict other conditions specified for the system.
• Compliant – consistent with other authoritative documentation such as legislation, policies, etc., relevant to the subject.
• Coherent – consistent with requirements specified for other related systems.
• Current – still valid.
• Unambiguous – concisely stated and tested to ensure that various stakeholders/ perspectives understand the same thing.
• Sufficiently detailed and formal for each audience.
• Implementation free means stating what is required, not how the requirement should be met.
• Verifiable – implementation can be objectively, reliably and consistently demonstrated through inspection, demonstration, test or analysis.
• Feasible within the constraints of the project.
• Declared mandatory (representing a characteristic whose absence will result in a deficiency that cannot be ameliorated) or desirable (representing a characteristic whose presence is preferred but whose absence can be managed). [Note: some commentators argue that requirements can only be mandatory – they are either required or not.]

37
Q

The IT management paradox

A

The IT management paradox is that in the early stages of a project, there are many degrees of freedom concerning the specification of requirements for an information system, but stakeholders often show insufficient understanding of requirements and their implications. However, when the information system is operational, and the implications have become clear, significant modifications are likely to be expensive and may not even be possible. In other words, a deep understanding of requirements and the capacity to respond to them often move in opposite directions.

38
Q

Information system lifecycle - Planning - Architecture

A

Having defined the business issue(s), assessed the feasibility of resolution, identified preferred course(s) of action and determined the organisation’s requirements, the system lifecycle then turns to fleshing out the preferred course of action. The preferred solution is ‘architected’ – planned and designed to be soundly and efficiently implemented to meet stakeholder needs and be compatible with its environment.

this represents architecting at either the segment or capability level. The outputs from this activity will include:
• Description of the current system and its operation.
• Any constraints.
• Relevant architectural principles.
• Implications of the requirements for solutions and technologies.
• Candidate solutions (based on market scanning).

39
Q

Information system lifecycle - Planning - Lifecycle

A

• Identifying and clarifying the roles and responsibilities of various stakeholders over the entire system lifecycle.
• Building a road map for this and related future investments.
• Ensuring that the business case evolves to provide ongoing benchmarks against which project performance can be measured to check whether key objectives and benefits are being met.
• Ensuring that the current state is baselined so that the extent of achievement of objectives can be assessed.
• Planning the organisation’s capacity to execute change - system investments can involve significant transformation or re-engineering. This should include explicitly assessing the organisation’s current change management capacity, realistically assessing the capabilities required, identifying the gaps
• Validating the organisation’s ongoing capacity to operate, maintain and review the system throughout its lifecycle.
• Planning for the realisation of benefits.

40
Q

UK Office of Government Commerce’s Gateway Review Process™ and 6 gates

A

Gateway aims to improve the delivery of major projects. It comprises short, intensive reviews at up to six critical stages of the project lifecycle (noting that systems lifecycles extend beyond the project stage) by experienced peer reviewers who are not associated with the project.
The six “gates” are:
• Gate 0 - Business Need
• Gate 1 - Business Case
• Gate 2 - Procurement Strategy
• Gate 3 - Investment Decision
• Gate 4 - Readiness for Service
• Gate 5 - Benefits Realisation

41
Q

Information system lifecycle - Obtaining - Analysing procement options

A

The core decision concerning acquiring system functionality is whether to adopt, adapt or develop..

• Strategy and competitive advantage. Where does the solution fit within the systems investment portfolio? Is it an ancillary function that may lend itself to a more industry-standard solution or, at the other end of the spectrum, a set of requirements upon which the organisation’s strategic positioning is dependent? The former suggests that market solutions may be available and that there may be advantages in adopting/adapting them: excellence in ancillary functions may benefit from an alliance with other system users. The latter may suggest that development should be considered to advance and protect the organisation’s position.
• Core vs non-core. This is similar but different and perhaps best demonstrated by example. An organisation may seek competitive advantage or seek to implement a new and additional strategy over a point in time but retain a core mission. There is at least a temporal issue here – strategy and the quest for competitive advantage may be or become core but are not necessarily long-term core at any point in time. Operations that are core to the organisation’s success are less prone to compromise.
• Fitness for purpose. Do the market offerings meet requirements to the extent that will satisfy stakeholders and are verifiable. If not, adapt or develop should be considered.
• Architectural fit. Do the market offerings provide the requirements in a way that preferably enhance and at least “do no harm” to the relevant enterprise architectures. If not, adapt or develop could be considered.
• Lifetime cost. What are the respective costs and opportunity costs of adopting, adapting, and developing options? It must be borne in mind there may be different degrees of confidence associated with these options, which must be reflected in relevant analyses.
• Scale and complexity versus expertise and maturity. What is the relative balance between the satisfaction of requirements and the capability of the organisation to develop these?
• Commoditisation, flexibility and change. Ceteris paribus, the more unique the requirements, the less likely it is that the mass market will satisfy requirements. The more flexibility and change is required, the less likely it will be that the mass market will be willing to accommodate local needs.
• Time. Ceteris paribus, there is some evidence to suggest the market can deliver more rapidly than “build your own” methods
• Risk. Detailed and multi-perspective risk analysis of each option is required.
• Support structure. From where can the solution be best supported throughout its lifecycle, especially considering that healthcare is a relatively low investor in healthcare, meaning that lifecycles may be quite extended.
• Operational factors. Are there day to day factors that influence the acceptability of the option, such as whether the system is operationally or intuitively familiar to users (e.g., Windows)?
• Intellectual property. Are there aspects of the system for which the organisation would prefer to secure the intellectual property, and if so, what is the best approach?
• Acquisition policy. Are there policies and practices or contractual agreements that restrict the organisation’s freedom in terms of acquisition?

42
Q

Generic processes for acquisition include (4)

A
  1. Request for information or EOI
  2. Request for proposal or Request for Tender
  3. Evaluation of proposals
  4. Closure
43
Q

Common acquisition issues and challenges include the following

A
  1. Maintaining fairness and transperancy
  2. Lack of commercial accument
  3. Contract or relationship management
  4. Unproven tech
44
Q

Generic process for development - Waterfall

A

In the waterfall method, system development flows through stages of requirements analysis, design, implementation, verification and testing, and deployment and maintenance, although there may be iterations of these stages.

The waterfall method has a strong engineering heritage and is best suited to scenarios in which:
o Requirements are well known and stable.
o The requisite technologies are available and stable.
o The system development time frame is not too extended.
Waterfall’s disadvantages include the need for detailed requirement specifications, inflexibility, lack of progressively earned value (results come late in the process), and the possibility that

45
Q

Generic process for development - Thowaway prototyping

A

The main purposes of throw-away prototyping are to validate or determine requirements that are not clear at the start by providing visualisation of possible solutions and/or to provide proof of concept. A throwaway is not a final product. The throwaway prototype method must be coupled with a way to arrive at the final product.

46
Q

Generic process for development - Evolutionary prototyping

A

In evolutionary prototyping, the system concept progresses by iterating and evolving the prototype. Advantages of this method include its ability to solidify unclear requirements and demonstrate earned value throughout the development process. It may, however, be difficult to estimate the timeframes and some costs associated with evolutionary prototyping.

47
Q

Generic process for development - Evolutionary development

A

Some commentators regard evolutionary development and evolutionary prototyping as the same thing. Others argue that evolutionary prototyping is appropriate when requirements are unclear, while evolutionary development requirements are better developed and the way these are satisfied benefits from iteration. In other words, the subtle difference pertains to the certainty of requirements, with the implications being that timing and costs may be easier to fix because a predefined number of iterations can be scheduled.

48
Q

Generic process for development -Incremental development

A

incremental development plans to deliver the system in agreed increments, where each increment or package yields a defined part of the required functionality. Requirements are prioritised, and the highest priority requirements are delivered early. Once an increment is developed, the requirements are frozen so that later increments can continue to evolve.

49
Q

Types of testing

A

• Unit testing is typically undertaken by the developer within the development process. It aims to check that individual system parts are functioning as expected.
• Integration testing ensures that the modules that need to work together are doing as expected.
• System testing involves end to end testing of the complete and fully functioning product.
• Stakeholders typically perform acceptance testing to confirm that the system conforms to the agreed requirements. It validates the end to end business flow.

50
Q

Information system lifecycle - Implementing - Builing capacity

A

Capacities that are usually required and often challenging to build include:
• Influencing stakeholders, many of whom are somewhat autonomous agents in healthcare. Stakeholder engagement and motivation is always one of the most critical challenges in system implementation.
• Recruiting skilled and experienced staff across the whole continuum of resources required. The Victorian Auditor-General notes that:
“Very often … key positions are assigned to inexperienced staff that lack the capabilities to deliver; … much of the project management is done by contractors, and only limited knowledge is held by agency staff; and agencies do not require contractors to effectively transfer knowledge” (Victorian Auditor General’s Office, 2013, p.44).
• The reskilling, reorientation and/or replacing of operational staff and users. User training and support are key to data quality and return on investment in quality patient care.
• Knowledge management, traditionally captured (but often not maintained) in the form of paper documentation but increasingly embedded in the systems themselves or the intuitiveness of human interfaces

51
Q

Information system lifecycle - Implementing - Deploying

A

Deployment essentially comprises putting the new system into production, confirming that requisite data are quality-assured and available, implementing work process changes and transitioning system support from development teams to operations staff.
This is where ‘the rubber hits the road’. From here on in, issues will not occur within an insulated project environment but may carry operational and/or financial implications into the organisation’s running.

52
Q

Deployment methodologies (4)

A
  1. Cutover
  2. Parallel operation
  3. Piloting
  4. Phased
53
Q

Information system lifecycle - Implementing - Post implementation review

A

.A post-implementation review reviews how the project has been defined, planned, and implemented. It occurs as the initiative ceases to be a project and is being operationalised. It focuses on how the project has been undertaken and the project outputs and outcomes.
A post-implementation review does not evaluate the initiative’s outcomes and the realisation of benefits since these largely occur through the system’s operation in the next phase. Rather, a post-implementation review aims to identify what went well and what did not go so well, capturing the learning which will assist in planning, managing and meeting the objectives of future projects.

54
Q

System security - why is health valuable and vunerable

A

o It holds highly sensitive personal data and valuable intellectual property.
o Its services are critical, and there is great pressure on health sector organisations to maintain and, if disrupted, rapidly restore business continuity.
o Public trust in health sector organisations, particularly those linked to Government services, is high.

55
Q

Emerging trends in cybersecurity risk (5)

A

o Medical devices connected to the Internet. “The cybersecurity vulnerability of medical devices and the lack of vendor and regulatory oversight has been recognised as a strategic priority by the Australian Therapeutic Goods Administration” (p.565).
o Data confidentiality, privacy and consent. “Health information and medical data are highly valuable assets to patients, healthcare providers and identity thieves alike. Estimates place health data between ten and twenty times more lucrative than credit card or banking details. Credit card or banking details can be changed if stolen. Uniquely identifiable health history or data cannot” (p.565-6).
o Cloud computing. “Cloud models share the cost of data accessibility and management, as well as sharing the cybersecurity risks – the scalability and efficiency of cloud computing mean any potential breach exposes data to a far wider audience “ (p.566).
o Health apps. “A recent Australian study found that over half of government-endorsed apps did not have a privacy policy to inform users how personal information would be collected, retained or shared with others. Patient confidentiality and safety or the security of communications are often not considered by app developers who are largely unregulated in terms of content, authorship or trustworthiness” (p.566).
o Insider threats. “Most insider issues are due to ignorance rather than malice, but accidental error is equally damaging, making the lack of health information technology and cyber-hygiene knowledge an important threat” (p.567).

56
Q

Cybersecurity capabilities, countermeasures and mitigation strategies include (3)

A

Risk assessment and governance. US data suggests the average total cost of a healthcare data breach is 65% higher than any other industry, and the healthcare industry takes longer than any other to identify and rectify violations. This heightens the need for effective cyber security risk assessment and governance.
Health information privacy and security are major concerns for patients/consumers, and this is a significant driver for regulatory and policy oversight. However, “comprehensive policy will not guarantee cybersecurity if not reflective of actual healthcare practice, culture or infrastructure limitations” (p.568).
The Australian healthcare sector “is recognised as having low cybersecurity capability maturity [and] the lack of an Australian healthcare cybersecurity capability model is recognised as a significant security risk” (p.569).

Technological solutions, including cryptographic architectures, are increasingly available. However, some of these require further development before large-scale production implementation.

Cybersecurity culture and education. Interestingly, the need for employee training and education to identify and assess cybersecurity risks is prevalent in the international literature but missing in the Australian material reviewed. This was also the case for developing a proactive cybersecurity culture.

57
Q

Cybersecurity - why is health different

A

O’Brien et al. (2021) argue that healthcare is different from other critical sectors because of its:
• Collection and sharing of sensitive personal data amongst multiple users who operate under extreme pressures, coupled with the potential for significant patient harm.
• Relatively low investment in information technology and cybersecurity, which is often dependent on wider government spending allocations.
• Information imbalance between patients and providers.
• Lack of cybersecurity education and awareness amongst healthcare professionals.

58
Q

The ‘essential eight’ mitigation strategies are, in summary

A
  1. Application control should be implemented on workstations and servers to ensure that a limited set of authorised users can apply powerful software utilities, and allowed and blocked executions are centrally logged.
  2. Patches, updates or vendor mitigations for security vulnerabilities are applied promptly, vulnerability scanners are used regularly to identify missing patches or updates, and applications no longer supported by vendors are removed.
  3. Microsoft Office macro settings are controlled, and allowed and blocked executions are centrally logged.
  4. ACSC or vendor hardening guidance for the use of web browsers, Microsoft Office and PDF software is implemented.
  5. Administrative privileges are restricted.
  6. Patches, updates or vendor mitigations for security vulnerabilities in operating systems of internet-facing services are applied promptly, vulnerability scanners are used regularly to identify missing patches or updates, and operating systems no longer supported by vendors are removed.
  7. Multi-factor authentication is used.
  8. Backups of important data, software and configuration settings are performed and retained in a coordinated and resilient manner per business continuity requirements, recoveries are tested, and only authorised personnel can access, modify or delete backups.