capacity market survey
TRANSCRIPT
MARKET ANALYSIS
MARKET SURVEY
CAPACITY
Empowering the care staff and
bridging the gaps in care
Stockholm County Council
Information document about Stockholm County Council initiative to
enable the market to implement, combine, or develop a new IT
solution for the perioperative and intensive care, and beyond
1 (36)
Table of Content
1 Summary .............................................................................................................. 3
2 Orientation ........................................................................................................... 4
2.1 Issuing organization ................................................................................................. 4
2.2 3R ............................................................................................................................. 4
2.3 Purpose with this market analysis and dialogue ....................................................... 4
2.4 Definitions ................................................................................................................ 5
3 About Stockholm County Council and Health ................................................. 6
3.1 Healthcare ................................................................................................................ 6
3.1.1 Vårdval Stockholm ........................................................................................... 6
3.1.2 Local medical centres and family doctors ........................................................ 6
3.1.3 Emergency hospitals ........................................................................................ 6
3.2 The Future of Care ................................................................................................... 7
3.2.1 Four pillars ....................................................................................................... 7
4 Communication and administration regarding this market analysis ............ 8
4.1 Responses ................................................................................................................. 8
4.2 Language .................................................................................................................. 8
4.3 Confidential information .......................................................................................... 8
4.4 Costs ......................................................................................................................... 8
4.5 Modifications to or cancelling of the market analysis ............................................. 8
4.6 Contact people .......................................................................................................... 9
4.6.1 Administrative issues regarding the survey ...................................................... 9
4.6.2 Content issues regarding the survey ................................................................. 9
5 The overall need and ambition ......................................................................... 10
5.1 The core care process: The perioperative process and intensive care .................... 10
5.2 Bridging the gaps in care also beyond the perioperative and ICU process ............ 11
6 Strategic needs - Providing capabilities also for tomorrow........................... 12
6.1 Networked based care and Patient Information Continuity ................................... 12
6.2 Patient involvement and the evolution of mHealth provides opportunities ........... 13
6.3 Business and operational agility ............................................................................. 13
7 Summary of core needs ..................................................................................... 15
7.1 Vision ..................................................................................................................... 15
7.2 T5 - The collection and storage of MTD ................................................................ 15
7.3 CAPACITY - A solution enabling the safest care in the world ............................. 16
7.4 Scalability ............................................................................................................... 17
8 CAPACITY ........................................................................................................ 19
8.1 Capabilities of CAPACITY ................................................................................... 19
8.1.1 Decision support ............................................................................................. 20
8.1.2 Context-aware ................................................................................................ 21
2 (36)
8.1.3 Pharmaceuticals .............................................................................................. 21
8.1.4 Efficient ordination to administration process at ICU´s ................................. 22
8.1.5 External capabilities ....................................................................................... 22
9 T5 – the theory behind a central MT data repository and its effect on a
solution ....................................................................................................................... 24
9.1 Embracing the movement towards standardization with IHE ................................ 24
9.2 Requiring standardization ...................................................................................... 25
9.3 Other data producers .............................................................................................. 25
9.4 Other benefits from T5 ........................................................................................... 25
10 Procurement process likely to follow this market analysis ........................... 27
10.1 Background ............................................................................................................ 27
10.2 Preperation for Procurement of Innovation (current phase) .................................. 27
10.3 Possible Procurement of Innovation ...................................................................... 28
10.3.1 Ideas on how to perform an eventual Pre-commercial Procurement.............. 28
10.4 Possible Public Procurement .................................................................................. 29
10.5 Possible Innovation Partnership ............................................................................. 29
10.6 Overview of possible procurement process ............................................................ 29
11 Information about the market survey ............................................................. 31
11.1 Purpose ................................................................................................................... 31
11.2 Important dates ....................................................................................................... 31
11.3 Publishing ............................................................................................................... 31
11.4 Supplying material ................................................................................................. 31
11.4.2 Q & A ............................................................................................................. 32
11.5 One on one meetings .............................................................................................. 32
12 Appendix 1 – Conceptual model of enabling maximum solution flexibility 33
13 Appendix 2 – Our thoughts on “open architecture” ...................................... 34
14 Appendix 3 - Overall description of the core care process..............................36
3 (36)
1 Summary
The hospitals within Stockholm County (SLL) have come together in a program based on the
needs for an IT solution for the perioperative process and intensive care (see 14).
As a part of the internal preparation, the possibilities with and necessity of being able to
flexibly meet the needs of a networked based care within the Stockholm region (see 6.1) and
extending the scope of a solution within the hospital and later also outside of the hospital
(see 6.1 and 6.2) to bridge the gaps in the continuity of care (see 5.2) has been defined as
crucial for the strategy and ambitions with the Future of Care (see 3.2). Also, we believe that
whatever the challenges and possibilities of the future are we must optimize our possibility
to meet such needs with an optimal technical and business model flexibility (see 6.3).
We have engaged in a demand-driven innovation approach, in which our functional (as far as
they are known today) and strategic needs both have been and will continue to be critical for
us to meet.
We have designed and initiated parallel work to prepare for a technical environment in
which we separate the solution into:
Integration, storage, and exposing of patient data being produced in medical
technology devices; T5 (see 9)
Logic and presentation layer (and database for non-T5-data) consuming data from
T5 as well as other system resources within SLL to provide the functionality
requested by the care staff and, potentially, patients or external actors in the care
process; CAPACITY (see 8)
This market analysis and survey is a part of the preparation for a possible procurement
process for CAPACITY (see section 10), which execution and content in part will depend on
the outcome of this survey. For T5, we will most likely issue another market analysis the
coming months.
With this market analysis and dialogue, we invite the market to provide its ideas and
concepts for how SLL best could reach the needs as described in this document. Another
purpose of this analysis and dialogue activity is to identify actors in the market with the
competence, ideas and concepts, and willingness to engage in a process in common pursuit
for the best solution possible.
We want to emphasize that we believe that the needs which we have identified will require a
modern and in part innovative approach to architecture, backend logic and user experience.
We believe that there are competence and solution concepts available on the market to meet
our needs and we will in a possible upcoming procurement process try to enable also for
actors without previous health care experience or references to contribute.
4 (36)
2 Orientation
2.1 Issuing organization
SLL, Registration nr: 232100-0016
The need and thus scope for a new solution covers all hospitals in Stockholm County, which
have been and will continue to be a part of the internal organization as well as a possible
future procurement process.
2.2 3R
Stockholm County Council has for a few years worked together with Region Skåne and
Västra Götaland County Council in a program named 3R, aimed at moving towards a more
coherent and integrated healthcare information environment based on the needs of the
patient, increasing the value for the individual as well as contributing to an enhanced and
safer work environment.
The three regions within 3R make up some 2/3 of the healthcare in Sweden.
This market survey is a part of a Stockholm County Council program which has the directive
to report to the 3R steering group about the progress and recommendations. The other
regions are thus following the outcome of this process although not being a formal part of
the same.
The coordination of how CAPACITY shall relate to a possible 3R environment in terms of
master of data, logic, and presentation will be a task continuously performed as the abilities
of CAPACITY are identified - during the process of which this market analysis is a part -
and the 3R program evolve.
2.3 Purpose with this market analysis and dialogue
The purpose of this market analysis and dialogue process is to:
- Describe SLL overall operational and strategic needs.
- For SLL to receive information about ideas, concepts, technology, and solutions
which could be used to meet our needs.
- For SLL to receive information about our general strategy and any fault or
misunderstanding we might have made or based our strategy on.
- For SLL to get to know the market; specifically possible new actors or consortiums of
different competences such as storage, integration, backend architecture, user
experience, front-end development, human-data-interaction experts etc.
We base this process primarily on the operational and strategic needs as described overall in
this document and our own vision to provide the best possible care but also the important
role for the public sector to spur innovation.
5 (36)
Observe that this is not a part of a procurement process but one activity in a preparation
project within SLL aiming at defining how to best procure a new solution for the defined
needs.
SLL will neither be responsible for continuing the overall process described in this
document nor perform it in the way described herein.
2.4 Definitions
In this document the below definitions are used:
Definition Meaning
MTD Medical Technology Devices, f I patient monitors, ventilation
pumps, and infusion pumps.
SLL Stockholm County Council; Stockholms Läns Landsting
LOU Lagen (2007:1091) om offentlig upphandling; the Swedish
Public Procurement Law
PCP Pre-commercial Procurement (Förkommersiell Upphandling),
which is a process within Procurement of Innovation.
6 (36)
3 About Stockholm County Council and Health
The County Council is responsible for all publicly-financed healthcare and public transport
in Stockholm County. The County Council is also responsible for other overall issues within
the county, such as regional planning and cultural subsidies.
Stockholm County has 2,2 million citizens. In 2013 Stockholm County had a growth rate of
over 35 000 people, standing for 40 % of the total growth in Sweden.
For additional information about SLL, please visit www.sll.se.
3.1 Healthcare
Stockholm County Council is one of Europe's largest healthcare providers, offering
everything from telephone advice about self-care to advanced specialist care at university
hospitals.
The County Council has overall responsibility for caring for the county's inhabitants, and
must meet the targets of the Swedish Health and Medical Services Act, i.e. good health and
care on equal terms for the entire population. Knowledge of the county's inhabitants, such as
age and health, forms the basis for planning this care.
The majority of care is provided under the County Council's own management. Around a
third is dealt with by private care providers, such as family doctors, physiotherapists,
maternity clinics and hospitals.
3.1.1 Vårdval Stockholm
Vårdval Stockholm gives the county's inhabitants the opportunity to choose care providers
on the basis of their own requirements, such as geographic location and opening hours.
Payment is made to these care providers in accordance with inhabitants' choices.
3.1.2 Local medical centres and family doctors
Local medical centres or family doctors' surgeries are the entry point for healthcare. If
patients require specialist care, the doctor refers them onwards. The local medical centres are
part of the County Council's out-patient care service. This also includes some psychiatric and
geriatric care.
3.1.3 Emergency hospitals
Emergency hospitals treat patients with serious emergency conditions. Local emergency
clinics supplement the services offered by local medical centres and emergency hospitals.
Stockholms County (SLL) own and operate five emergency hospitals. SLL also operates a
large part of remaining healthcare in the county, such as primary care facilities (primary
7 (36)
care, f I “vårdcentraler”). A substantial part of the primary care plus one emergency hospital
is operated by private actors, from which SLL buys care.
3.1.3.1 New Karolinska
New Karolinska Solna (NKS) is the project name for the state-of-the-art hospital currently
under construction next to Karolinska University Hospital in Solna. The new university
hospital will open its doors to the first patients at the end of 2016. NKS is being built to be
able to meet the demands of the future in relation to health and medical care – with a greater
focus on the patient's needs, faster provision of care, and increased patient safety with single
rooms for all inpatients.
3.2 The Future of Care
It is estimated that the population within Stockholm County between the years 2010 and
2020 will grow by 350 000 people. In order to meet the demands of the future, Stockholm
County is currently conducting one of the largest investment efforts ever regarding the
healthcare sector. In total, 42 billion Swedish kronor will be invested in extended care
facilities, improved premises and new working methods.
The Future of Care Plan – decided upon in June 2013 – requires the close cooparation
between care providers in the region where also local medical centres, e-health, and primary
care will be important components in a networked based care centered around the patient.
The citizens of Stockholms County will meet a care in which different care providers, such
as hospitals and family doctors, will cooperate in a newtwork around the patient. Are care
providers, no matter type or size, have the same responsibility to contribute and cooperate in
order to provide the patient with the best possible assistance.
3.2.1 Four pillars
The networked based care rest on the four pillars:
The individuals health is in focus at every meeting the healthcare
No matter where the individual turn for assistance, the individual is in the right place
Sufficient and adequate information and competence is present throughout the
healthcare, I e at every care provider instance
The collected need of the patient is the basis for where and by whom the care is
provided
8 (36)
4 Communication and administration regarding this market
analysis
4.1 Responses
We kindly request only written responses to this survey.
Responses, as well as any questions, are to be submitted via www.e-Avrop.com
We look forward to receiving all written responses by the date as defined in section 11.2.
4.2 Language
English or Swedish will be accepted languages for responses and other dialogue in this
market analysis.
SLL will provide all publically published material in English only. However, some pictures
and visual material might be stated in Swedish.
4.3 Confidential information
Documents related to the pre-procurement phase or to any market survey prior to
procurement, may be regarded as confidential due to other provisions according to the Public
Access to Information and Secrecy Act.
Stockholm County Council will treat any submitted responses within the frame of this
market analysis, to the extent they contain commercially confidential business information,
as subject to confidentiality.
If the Applicant considers information provided during this market survey and dialogue to
fulfill the conditions for commercial confidentiality, the Applicant shall submit a request for
commercial confidentiality. The request shall detail which information should be covered,
and what damage the Applicant would suffer if the information would become public.
SLL individually assesses each request for public information. Note that SLL’s decision to
treat information with confidentiality can be reassessed and challenged in court.
4.4 Costs
Participating parties in this market analysis shall bear their own costs related to such
participation.
4.5 Modifications to or cancelling of the market analysis
SLL has the right to modify any information or stated pre-requisites related to this market
analysis, such as which as well as dates for activities and details about their purpose and
content as well as cancelling part or whole of the market analysis at any time.
9 (36)
SLL will neither be responsible for continuing the overall process described in this
document nor perform it in the way described herein.
4.6 Contact people
4.6.1 Administrative issues regarding the survey
Name: Charlotta Bergman
Phone: +46 (0) 8 123 147 31
E-mail: [email protected]
4.6.2 Content issues regarding the survey
Name: Fredrik Lundkvist
Phone: +46 (0) 708 78 81 10
E-mail: [email protected]
10 (36)
5 The overall need and ambition
5.1 The core care process: The perioperative process and intensive care
The perioperative process and intensive care (ICU) is a care process in which patient security
is always present, directly during operations and indirectly through the risk of complications.
The perioperative process can be initiated though an elective process, i.e. when a patient is
scheduled for operation, or as an emergency process. Sometimes the patient is taken from the
ICU, or in some cases from a care unit, to operation or from operation to an ICU.
For a picture of the care process and the overall activities performed, see section 14.
The care performed in the perioperative process and in the ICU is characterized by often
complicated procedures, with the support of so called Medical Technology Devices such as
patient monitors, infusion pumps, dialysis machines, and ventilators. These devices are
connected to the patient to monitor vital parameters and administer different kinds of
pharmaceuticals. The information provided by the MTD´s are an important part of the work
during this care process, by which decision support is provided on different screens
integrated in the MTD´s. Parallel to this monitoring, care staff register all activities
performed..
In brief, the need for IT support in this process is related to:
Information about the patient´s history and clinically relevant background
information.
The automatic capture, storage, and visualization of information from the MTD.
Decision support provided to the care staff as data from the MTD are analyzed and
provide proactive information on the patient´s status and/or prognosticated status.
The registering of activities related to the patient during the process.
ICU: Ordination of drugs to be administered, the calculation of and preparation of
drugs, and the registration of administration of drugs.
The above functionality is provided by the market by means of so called Patient Data
Management Systems (PDMS), which integrates to MTD´s and display this information in a
single application interface in which also decision support is provided – visually by trend
curves and proactively by the triggering of alarms when set intervals are reached.
Besides from our perceived lack of user friendly and intuitive interfaces, the often lacking
cross-device usage, and the somewhat inflexible ability to adapt the usage of these systems
to new functionality there are some further core capabilities affecting the possibility to meet
our needs:
Reliability and standardization of MTD-integration needs to be improved.
The data output, I e usage of data for f I reporting and research, is problematic.
The cooperation between departments and hospitals and the single-view-of-patient
over all units is hindered by data interoperability issues.
The decision support is lacking capability as the analysis and correlation of data is
limited.
11 (36)
By implementing f I best practice interfaces and interactivity, accessible over multiple
devices, with possibility to adapt the interface to context, process and rule work engines, and
analysis tools in an open architecture which provides maximum interoperability, flexibility,
as well as functional scalability, SLL feel that an IT support platform for the present as well
as the future can be gained.
There are scalability issues which also need to be considered – and which we have set as
must haves – such as:
- The increasing usage of MTDs in emergency rooms and care units. SLL require the
ability to easily add new data input sources (such as a new MTD brand) and new
interaction points without technical or other lock-in.
- The increasing and likely accelerating integration with and data from different e-
Health devices, f I the monitoring of patient vital parameters at home, before an
operation, or the daily monitoring of f I bold pressure or weight at home after a
surgery to be able to foresee possible complications and avoid re-admittance or
even new surgery, requiring the same avoidance of lock-in as above.
- The to some extent already known needs for “light versions” of different kinds, f I an
application for spot checks at care units in which vital parameters or activities are
easily registered or the “on-the-move” access to a patient vital parameter data and
status.
5.2 Bridging the gaps in care also beyond the perioperative and ICU
process
We want to bridge the gaps in the care process, and empower the care staff with an
intuitive, anywhere-anytime, tool for performing their daily work.
“Bridging the gaps in care” means providing relevant patient data over the whole care
process. The core care process is from pre-op to post-op and into the ICU. But a core
ambition is to enable continuity in care beyond this perioperative care process and ICU to
emergency and care units. The next step, and one which we also must enable taking, is
beyond the boundaries of the hospital; into the home of the patient and possibly into the
process of the primary care.
This bridging of gap vision – which requires the collection of data from the whole process as
well as the consumption of such data throughout the whole process - which T5 (9) is one
aspect of – also require the empowerment of the user with a modern interface, adapted to an
environment characterized by often dynamic and stressful events, and which can be
consumed over many devices.
There are of course important functionality which need to be delivered in a solution – such
as advanced decision support and modern and easy journaling – but the bridging the gaps
and enable continuity in the care process – perioperative, ICU, and beyond – is a core need
which we believe will deliver a better patient security.
12 (36)
6 Strategic needs - Providing capabilities also for tomorrow
The starting point for this process has been the needs from the profession of the clinical
process of an IT support system for the perioperative process and intensive care. But besides
these needs, important non-functional needs have been added, being critical to the ability of
SLL to meet the requirements in the clinical process up ahead as well as extending the focus
of this procurement process beyond the care process at its present core. It should be noted
that at the core of this process is thus not only the needs of functionality as can be provided
today but SLL´s needs of maximum flexibility to extend and scale the possible solution. For
us, new ideas and innovative solutions is not primarily a matter of delivering the
functionality we are able to specify today but providing best-of-breed capabilities for logic
and presentation in a flexible and scalable architecture.
Some of the non-functional aspects and needs which have and will continue to guide our
approach to a new solution are described below.
Picture: Conceptual description of how several long-term needs such as f i Networked based
care (Nätverksbaserad vård), Patient Information Continuity (Patientens process), and
Business and Operational Agility (Flexibel verksamhetsutveckling) create the need for open
architecture and technical flexibility.
6.1 Networked based care and Patient Information Continuity
The population of Stockholm County is growing at a fast pace and along with the relative
increase of elderly the demographic changes put pressure on the health providers of the
region.
In the plan for meeting these challenges, Stockholm County has concluded that a networked
base care is a crucial component for success. Networked based care requires a close
13 (36)
cooperation between care givers in the region to collaborate with providing a timely and
qualitative care for the patients.
For this to be possible there must be no restrictions in or time consuming or costly barriers to
our possibility to store and consume patient data as created in this care process between
hospitals and care units/departments.
Optimizing our ability to have continuity in patient information throughout the care process
is crucial to us. This means being able to collect and consume data throughout the whole
process, I e that care staff must be able to access patient information independent of place.
Out strive for patient continuity is not only restricted to the perioperative process and ICU
but we also need to be able to scale this continuity to emergency and care units.
6.2 Patient involvement and the evolution of mHealth provides
opportunities
Patient involvement is of utmost importance for modern, efficient, and values healthcare.
SLL has assumed patient focus and involvement as core to our ambitions to improve.
For the perioperative process and ICU the patient perspective is present in many ways, but
the interaction before and after admittance is something which stress the need for flexibility
and scalability of a solution.
Before and after the admittance there is a need for communication in general but specifically
the possibilities to have the patient deliver – manually by f I a smart phone application or
automatically by f I the use of an own or by the hospital lent device - data before and after
the admittance promise to increase the security of the care process as well as a means to
catch early warning symptoms so that complications can be avoided.
A solution must enable the time and cost effective scaling to new data input sources as well
as possible interfaces, extending the whole solution domain beyond what it is defined as
today.
Also, communication between patient and hospital is a possibility to enhance patient
involvement and a qualitative care service.
6.3 Business and operational agility
The overall strategic drivers require interoperability and conformity of data as well as an
open, flexible architectural design in a solution. We believe that it is of highest strategic
value to find a partner (-s) and solution with which we can continuously develop the
organization´s capacity to respond to new and future contexts and optimize the support
required by the organization to deliver an increasingly safer care. We, as well as any
organization utilizing IT as an important tool for operational excellence or organizational
14 (36)
development, must have the agility to add new functionality with a flexible solution with
which f I new presentation and interactivity interfaces can be added to the solution.
As described in this document, flexibility in and openness of architecture is in the core our
approach and thus, challenge to the market.
15 (36)
7 Summary of core needs
Following our needs – operative as well as strategic - as described in this document our core
criteria for a solution shall:
- Apply open architecture and standards for optimal data interoperability between care
givers.
- Enable us to assume full control over the patient data, I e enable full access to data
without technical or financial lock-in.
- Implement optimal flexibility in logic and presentation layer of a solution in order to
be able to continuously adapt a solution to the needs of our care staff and enable us
to reach for the highest possible patient security.
7.1 Vision
The below vision statement has been a guiding principle in analyzing the market´s capacity
to provide a solution to support the daily work with our patients.
The vision also includes a very important time aspect: That we believe that it is of utmost
importance that we maximize our ability to continuously and incrementally adapt, optimize,
and develop the solution over time. F i new technologies for interactivity, new best practices
supplied by R&D, new organizational processes, growing trends in and ability to monitor the
patient at home, and the possibilities in leveraging a great solution – or parts thereof -
outside the primary care process in order to increase patient security and secure care
continuity are aspects that we value more than the actual detailed functionality of a standard
solution or first version of a new solution.
Our vision is providing the safest – the very best – care in the world; today and tomorrow.
This vision is the very background for and foundation to concluding that we must engage the
market in our demand-driven approach.
Providing the safest care in the world in a networked base care environment.
The overriding goal is to bridge gaps in the continuity of care (see section 5.2).
7.2 T5 - The collection and storage of MTD
SLL recognizes the complexity of MTD integration and data capture. However, considering
that the market for MTD is moving towards standardization of MTD data communication
(for example via IHE and ISO 11073), and out-of-the-box ability for direct network
communication, we have stated, and are working to secure, the following:
A central repository for management of MTD data. This repository captures and
stores MTD-data using well-defined industry standards such as IHE, and exposes
this data to IT-applications such as a “PDMS” using similar standards. A pre-
requisite for deploying out this type of system is that the MTD of involved hospitals
16 (36)
needs to be capable of network-based communication using IHE transactions. To
overcome this pre-requisite, an interim solution involving the procurement of an
adapter solution is also required. The adapter will convert non-standardized data
from non-IHE compliant MTD into standard IHE transactions.
This strategy requires competence from the market as well as SLL in systems
integration and infrastructure, which we are exploring parallel to this process. The
goal is to be able to provide a single interface from which IT-solutions access MTD
data. Therefore, the core competence of IT-solutions core competence shall be
limited to logic and presentation. The consequence for SLL of isolating MTD data
management into a single system would be taking control over our strategic patient
data – for future input scenarios and data output and usage in today known and
unknown applications and situations – and create the ability to build pure IT
solutions on top of the data.
As a consequence of the above ambition for a central storage of MT data we are
currently preparing a procurement process for such a solution and service.
According to current plans, a market dialogue will commence during February.
See section 9 for more information about this approach – T5.
Our belief and hope is that the market with the above “split” shall be able to focus on
presenting ideas and solutions for how to create processes, logic and rule-work, analysis, and
presentation and interaction which utilize the most flexible and dynamic capabilities
available.
7.3 CAPACITY - A solution enabling the safest care in the world
Following the architectural strategy of T5 (7.2 and 9), we believe that the possibilities to
implement and/or develop a “pure IT” solution for logic and presentation is great.
We will not detail a specification of “functionality” for CAPACITY because we believe that
such requirements will be characterized by the paradigm of systems present today as well
clouded by our lacking insight in possibilities of new ideas and concepts. We also believe
that the possibilities provided by the market and a flexible solution will enable a new set of
possibilities for us to provide the care staff with.
However, we can conclude that a anywhere-anytime approach to consuming information and
interacting with the solution, where the use of the solution over tablets, smart screens, and
possibly mobile phones would enable a great increase in efficiency and possibilities to
evolve.
We also believe that f I a modern approach to journaling, a best-practice visualization of
clinical information for intuitive consumption by a user also under stressful conditions, and
“intelligent” (predictive) analysis which provides clinically relevant decision support to the
care staff are important capabilities for CAPACITY.
17 (36)
See 8 for more thoughts on the capabilities of CAPACITY.
7.4 Scalability
We have described that it is very likely that a solution must be scaled horizontally, I e to f I
emergency rooms and/or care units, as these become more and more equipped with MTD´s
and, as a result of a great, intuitive IT solution, as the possibilities of such a solution for
increased patient security becomes clear. We have also stated that a great solution for our
needs would be one that enables adding new functionality in the most flexible manner.
Although some might argue that all the above is possible with the products and systems
present today or with the solution one might propose, the definition of “possible” is one
needing clarification. We mean that the solution meeting our needs is one requiring
minimum effort of change in the solution, which has been designed with continuous change
as a base requirement, and that besides such technical possibilities also no business model
lock-ins exist.
Open architecture and optimal technical flexibility is a primary concern of us. See 12 and 13
for further thoughts and information.
Picture: Overview of our overall approach.
18 (36)
The picture above aims at summarizing how we see the core process of AN/OP, Postop, and
ICU being a care process which in terms of continuity of care and thus patient safe care
involves the emergency rooms and care units.
In the pre-hospital phase the patient herself will soon be a provider of information and data
which we want to be able to store just as data produced inside the hospital will be stored.
The primary care units are likely to be another important provider of data for optimizing
continuity of care. Ambulance transports have been excluded in the picture but is another
possible source of input of data.
During the pre-hospital phase, the patient and primary care are once again producers of data
which we want to be able to utilize.
We believe that T5 will provide the possibilities to create a modern, agile infrastructure
consuming different producer data over time.
We envision CAPACITY as being the modern, intuitive interface possible to continuously
deliver even better support for our care staff in providing the best and most safe care in the
world, consumed by care staff in the core care process in multiple and full-scale ways as well
as possibly on-the-move versions, by emergency room and care unit staff possibly in other
and more scaled down ways, and later possibly by external actors such as the patient in
adapted and relevant interfaces.
Powering this solution should be an architecture enabling the flexibility and agility we know
we will need trying to meet the known and un-known needs and possibilities up ahead.
19 (36)
8 CAPACITY
Our vision is that care staff shall be equipped with a solution which enables information
about patient information and status over the whole care process in a secure, mobile, and
intuitive manner.
We recognize the need to limit the information flow and presentation in a way that enables
efficiency for the care staff, I e avoiding an overload of information. We also believe that
“pull-based” solutions – meaning systems in which a use must know what to look for and
where to find it – should be challenged and a context-based best practice be explored as an
alternative and/or supplement.
At the same time, standardization of certain interfaces such as vital parameter status
visualization is likely to be important as to facilitate the efficient cross-over of staff between
units, departments, and hospitals.
The core success factor in a qualitative care is and will remain the work performed by the
care staff on a daily basis. We want to find a solution which leverage modern concepts,
techniques, and architecture to reach both strategic values (see 6) as described in this
document – such as interoperability in data storage and flexibility in the application layer –
and relate to the different roles and situations within the hospitals as well as beyond its wall,
I e the patient and possibly primary care providers.
To summarize, a solution which optimize the possibility for the specific user (care staff
person) to perform his or her job in the most efficient manner in a certain situation – also
when under stress – with a patient-centric approach is likely to bring the best possibilities for
our staff to perform safe care.
We have named the initiative CAPACITY, which is an acronym according to below.
Context-aware, PAtient-Centric, Interactivity Tool for You
8.1 Capabilities of CAPACITY
Our approach is – as described – one of enabling an incremental delivery of the functionality
demanded by the operation to pursue efficiency and patient security. We believe that there
might be a gap between what we “think” is needed and what would surface as possible and
first then demanded as we provide a flexible platform to distribute a tool for the care staff.
There are however some areas which we will need to address; the details unknown to us and
of importance first during a possible procurement of innovation process or even first at
public procurement. Below, some overall capabilities and needs are described.
Visualizing the patient data, as supplied by T5
20 (36)
Modern and easy journaling, I e documentation of f I data and values as observed
(of such values are not captured automatically)
Support for an intuitive way to support the ordination to administration process for
ICU´s
Supplying an overview of patient information, history, and status as to “get to know”
the patient and get an overview of what is clinically relevant to know or address
Decision support, both the backend analysis and logic to trigger information to care
staff as well as the pushing and/or distribution of such events to care staff
8.1.1 Decision support
There is a great need for advanced decision support to the care staff. This could mean f I:
- Analyzing aggregated data from T5 (MT data) together with data from CAPACITY to
render trend information in patient status.
- Analyzing data from T5 (MT data) together with data from CAPACITY and possibly
other sources (such as laboratory results) to create events – notifications, warnings,
checklists etc – to the care staff.
The decision support capabilities we believe would make a difference are likely to based on
aggregated data from many sources.
There are most likely many aspects and possibilities with ”decision support” but in general
we believe that we need advanced decision support based on the correlation between
different data and creating clinically relevant events. We are interested in knowledge, ideas,
type of solutions, and possible products which could address this need and also be flexible
for us to be able to tweak and add data as well as the rule-works/algorithms etc which can
evolve to a decision support of great value.
21 (36)
Decision support is something we see as a possible separate module/capability but our
insight into the possibilities is not deep enough to conclude the manner in which this need is
best addressed.
8.1.2 Context-aware
One possibility which we want to explore is that of “context”. For us, a context-based
solution would in the best of worlds provide the user with the information he or she needs at
a certain time without he or she knowing she needs it. Context also relates to different
situations such as the physical space (f I operation room or at home) and device used (f I
stationary computer or tablet).
We believe that a true context based application would provide a possible revolutionary
approach to a care process often characterized by fast, dynamic, and stressful situations,
personnel sometimes working with many patients, and competence and experience being a
constant critical factor which however cannot be accepted as a basis for patient security.
Somehow connecting functionality, logic, and views/presentation with a context-based rule-
work could mean great benefits as a supplement to a more standardized, pull-based
application.
Overall, we know that there will be changes required and demanded regarding process, logic,
functionality, and interaction in the future. A solution which optimizes the flexibility to
change logic and presentation separately meanwhile providing a time and cost efficient
maintenance would be of great benefit to our continuous improvement of the IT support
provided to the profession.
8.1.3 Pharmaceuticals
Pharmaceuticals and the facts, recommendations, interactions etc related to them is crucial
for an efficient perioperative and ICU care process.
The capabilities provided today, and as we have thus far evaluated it in the market, for the
level of functionality related to pharmaceuticals do not meet the actual needs in the
organization. The effect has been the local and unit level production of algorithms used in
limited, local contexts. This is however a source of knowledge, definition, and even structure
capital possible to leverage and use in a new solution.
We are currently defining our vision and needs related to pharmaceuticals but it is possible
that a module which consumes data from sources of standard pharmaceutical data and then
enables the easy configuration of how to relate pharmaceuticals and create logic and
implement algorithms for what should be presented, suggested, and advised in CAPACITY
22 (36)
would provide the platform and framework for continuously implementing the support
needed over time.
Pharmaceuticals is closely related to decision support, see 8.1.1, but probably a separate
module/function which handle the logic for interaction between pharmaceuticals for use in
ordination, preparation, and administration and which a decision support
capability/module/function use as one data source.
8.1.4 Efficient ordination to administration process at ICU´s
Besides the generic needs of among others patient overview, aggregated information about
MT-data, and journaling, there is one important process which is important in the ICU: The
process of Ordination to Administration.
In ICU´s, doctors will define ordinations, I e pharmaceuticals to be given to a patient during
their stay in the ICU. This is usually done once a day, sometimes by detailing exact articles
and time and sometimes replaced by or supplemented with the setting of targets – f I
intervals – regarding health status and values which the operating care staff in the ICU shall
act to maintain.
Simplified, the process is:
1. Ordination – sometimes also targets defined – by a doctor.
2. The preparation, I e the collection, calculation1, and preparationof pharmaceuticals,
performed by nurses in the ICU.
3. The timely administration of the prepared pharmaceuticals, either according to
ordinate schedule or depending on the targets defined or decisions made by a nurse
depending on a change in status of a patient.
We envision an intuitive way to work with the above process, in which visual overview of
the schedule and events and rule work for reminders and other push notifications are defined.
Such abilities must be very flexible and dynamic.
8.1.5 External capabilities
Beyond the above internal capabilities, we also believe that the possibilities concerning
patient involvement and the care process beyond the hospital are great. CAPACITY should
enable:
An interface towards patients via web and/or mobile interface for the secure –
identified patient – input of text, data, and pictures by the patient. With T5 (see 9),
we believe that we will be able to receive and centrally store defined data from the
patient in T5, to be consumed by care staff in CAPACITY interfaces.
1 There are calculations needed for the amount of a pharmaceutical to give a specific patient
dependent on f I the fluid output and input related to weight. Such algorithms exists.
23 (36)
The possibility to utilize such an external application also in other hospital-external
contexts, such as primary care.
24 (36)
9 T5 – the theory behind a central MT data repository and its
effect on a solution
Conventional patient data management systems (PDMS) sometimes feature a monolithic
architecture that combines the following functional areas:
1. Data collection. This functional area covers direct communication with MTD units,
format conversion from vendor specific data format, and storage of data in a
universal format.
2. Data analysis and aggregation. This functional area covers in-depth analysis of
patient data. For example the calculation of NEWS-scores.
3. Data presentation. This functional area presents relevant data to clinicians via a
user-interface.
The main issue with this approach is that MTD data becomes “locked into” the specific
PDMS system which collected the data. A practical consequence of this issue is that
departments that have deployed different PDMS systems cannot easily or cost-efficiently
access each other’s data. For example, ICU-clinicians cannot use a high-end PDMS to access
patient data which was recorded by a low-end PDMS in the emergency room.
Instead, SLL has decided to isolate the first functional area (data collection) into a dedicated
system, designated T5. Data will flow through T5 according the following overall steps:
1. Data collection. Data will be collected from all MTD-units using the IHE Device
Enterprise Communication technical standard. An adapter solution needs to be
procured for MTD-units which are not IHE compatible.
2. Semantic conversion. Observation data needs to be converted into a useful and
uniform semantic model, perhaps using an IHE Device Observation Semantic
Bridge.
3. Data storage. Data will be permanently stored in a central repository. The storage
solution needs to support constant data availability, low query latency, and a high
degree of scalability in terms of storage volume.
4. Data accessibility.
This architecture will provide SLL with a master-repository for all data produced by MTD-
units throughout the patient care process. Additionally, integration costs will be lowered due
to the elimination of n:n-integrations between PDMS systems and MTD-units.
9.1 Embracing the movement towards standardization with IHE
We embrace the trend towards standardization with IHE. In a pure IHE MT-world, the
possibilities which we seek – moving away from technical lock-in and into a more flexible
and pure IT-based domain of solutions and applications consuming such data and providing
the best possible logic and presentation towards care staff – are great.
25 (36)
But waiting for a trend to become standard and waiting for suppliers to move into the place
we would like them to be is something we cannot afford with our critical functional and
strategic needs.
Therefore, we decided to procure what we need. This means that we will define a data layer
for MT-data which consumes, stores, and exposes (to applications; primarily CAPACITY)
IHE. Developing such software with a supplier, we will enable the separation of, simplified,
MT from IT – T5 from CAPACITY.
We believe that the technological abilities to design and effectively implement and maintain
T5 are very good. One important aspect is of course the capture of MT-data from many
MTD´s producing RS232 signals today. While we turnover our MTD inventory to
communicate wireless with IHE data output, we will need to define a MT adapter which
convert RS232 to IHE.
We know that the MT-market is moving towards IHE. We need to get there faster.
9.2 Requiring standardization
At New Karolinska, we have already started to specify and procure only those MTD´s which
communicate in a way aligned with our vision of T5, I e wireless and with IHE data output.
We will, once we have verified and specified the capabilities we need from MTD´s to meet
our vision, implement such a specification throughout the procurement processes of the SLL
hospitals. This way, we hope to move faster into an MT infrastructure most efficiently
aligned with T5.
9.3 Other data producers
Besides the internal MTD-units, we see other producers of MT-data to be stored in T5. We
will work to enable the secure input of data in T5 from patients, I e leveraging patient
involvement to capture important data before and after the hospital visit. With a secure
solution, easy to use for many patients, which provides an interface to digitally enter or
capture MT data to be stored in T5 as typed with type of producer and thus data reliability,
the continuity in the care process would improve.
Another data producer could be primary care (Vårdcentral).
9.4 Other benefits from T5
Besides providing a central data source to bridge gaps in the continuity of care, T5 would
provide an opportunity for a very valuable data quantity for research and development.
26 (36)
SLL believes that such a source of knowledge will be a unique asset for the continuous
improvement in care and research being one key driver for SLL, we will want to secure a
data mining capability on T5 without constraints in output.
27 (36)
10 Procurement process likely to follow this market analysis
After years of exploring our operational and strategic needs and evaluating the market, we
are fully committed to explore the possibilities of a new - possibly innovative – and,
regarding all aspects of a dynamic solution, modern approach.
We want to emphasize that we have made the principal decision to actively and forcefully
proceed with this process from en demand driven approach, I e that we feel that our needs
are of such importance for the evolution of our ability to provide the most secure care in the
world and enable to crucial ability to provide this care in a networked based environment
throughout the Stockholm region, and later possibly in an even bigger context.
As a consequence of this principal decision, we will encourage and value actors of different
competence in relation to the open architectural approach overall described in this document
and the size and formal experience from this field will be less valued than providing
innovative solutions which best meet our vision and strategy.
The below is the background, recent as well as current status, and planned and preliminary
steps in our process to find the best solution for our needs.
10.1 Background
- Between 2008 and 2011 SLL performed invested much time and effort in defining a
specification for a new solution for the perioperative process and intensive care. The
market was consulted during this process. The market was deemed unable to fulfill
many of our needs, both in usability, flexibility, and scalability. There was a no-go to
moving into procurement. The specification is still valid regarding many details in
functionality.
- In late 2013 and early 2014 SLL performed a pre-study, building on the above
specification work. The needs were once again analyzed and defined along with
overall wanted values and effects. The market was invited for dialogue and
demonstration but deemed unable to fulfill many of our needs, both in usability,
flexibility and scalability.
10.2 Preperation for Procurement of Innovation (current phase)
- In September 2014 we engaged in what we defined as a “Preparation for a
Procurement of Innovation for a new solution for the perioperative process and ICU”.
This phase is to deliver its result in the end of March.
- In December 2014 the project had, based on the highlighting of overall current and
future strategic needs within SLL, defined and recommended the approach defined
28 (36)
in this document. This approach was communicated and discussed at various levels
within SLL and decided upon, the consequence being bringing the project to a
program level, including several coordinated activities required to work towards the
realization of the set strategy.
- This Market analysis and survey is one activity in the above preparation
project/program. The purpose of this analysis is, as described elsewhere in this
document, to explain to the market what SLL overall needs are and engage with the
market to explore possible ideas and concepts to meet these needs.
Observe that we value information from the market about how you translate
our needs into open architecture. Deciding if to proceed with this process we
would like to see the market verify that the overall approach is doable and,
hopefully, that there are different approaches possible and several competent
actors interested in realizing a new breed of solutions for the health industry.
- The input in this analysis and dialogue will be added to the internal need analysis
work we have performed. With this information we will evaluate which challenges to
define for the market in the below Procurement of Innovation.
- If we can conclude that there is a gap between what the current market can
realistically deliver and our needs – operational as well as strategic – we will engage
in a Procurement of Innovation. This will most likely be performed as a Pre-
commercial Procurement (PCP). Decision about next step will be made in mid-April
and be based on the report from the Preparation project and other program
activities.
10.3 Possible Procurement of Innovation
10.3.1 Ideas on how to perform an eventual Pre-commercial Procurement
- If decided, a possible PCP would possibly include:
o We will post a Challenge to the market, including one or several challenges
we see must be solved by Research and Development efforts to arrive at
knowledge, specifications, and possibly structure capital (code,
documentation, wireframes etc) and/or prototypes for us to be able to enter
into a procurement process after the PCP.
o We will enable for any and all actors to compete to be a part of the PCP
process, I e not set requirements of company size or health care
experience.
o Interested actors will be asked to provide their ideas, concepts, and possibly
products (in which to base the concepts if such products are required). We
will evaluate these ideas and answers based on the criteria we have set,
which are likely to be focused around the core capabilities we see as
29 (36)
strategic and as described is this document, f I technical flexibility in general
as well as functional and business model scalability.
o We will pay the actors chosen market rates for their work, but all actors must
also – following the procurement stipulations – invest own time; I e
participating actors will be compensated for part of their work.
o We will accept and encourage joint efforts/proposals, I e two or more actors
entering the PCP as one consortium or similar arrangement.
10.4 Possible Public Procurement
Following a possible the PCP, it is SLL´s intent to enter into a procurement phase, focused
on finding one or several partners for the realization of a solution, which the PCP has
enabled, and enter into an Innovation Partnership with such actor (-s).
10.5 Possible Innovation Partnership
Our ambition and belief is that we together with an Innovation Partner shall enter into a
long-term partnership in which SLL´s operation, facilities, and personnel will be organized
for the agile and continuous development and implementation of a solution which shall
enable the safest care in the world. Such as Innovation Partner can be one or several actors, I
e a consortium, but include one legal counterpart.
10.6 Overview of possible procurement process
The below picture include an overview of the main stages in a possible procurement process
following this market survey.
T5 has been included in the below but will most likely, as stated elsewhere in this document,
be handled parallel to the CAPACITY process.
Picture: Overview of our intended – but dependent on market survey – process for establishing
CAPACITY (and T5) within SLL.
MARKET ANALYSIS & DIALOGUE
PRE-COMMERCIAL PROCUREMENT
(INNOVATIONSUPPHANDLING)
PUBLIC PROCUREMENT
(LOU)
INNOVATION PARTNERSHIP
MARKET ANALYSIS & DIALOGUE
PUBLIC PROCUREMENT
(LOU)
IMPLEMENTATION AND SERVICE DELIVERY
Input from the marketInput for a specification and requirements for a solution
meeting SLL needs
COMMUNICATING WITH THE MARKET
EXPLORING HOW TO BEST SOLVE OUR NEEDS
PROCURING A PARTNER AND A SOLUTION
(FRAMEWORK)
AN AGILE AND CONTINUOUS IMPLEMENTATION OF FUNCTIONALITY
IN CLOSE COOPERATION
Long-term agreement with a supplier and
partner
COMMUNICATING WITH THE MARKET
PROCURING A SOLUTION AND POSSIBLY SERVICE FOR T5
SETTING UP T5 AND CONNECTING HOSPITALS
CONTINUOUSLY
Input from the marketSupplier for T5,
including, MT adapter
CAPACITY
T5
30 (36)
Note: - The above is a very preliminary plan open for change overall as in detail.
- The chosen process is the result of a deliberate effort by SLL to actively explore new
concepts and solutions for a very important care process. We are intent on enabling
for those actors currently non-present or active in the health care sector to enter it.
- In an eventual PCP, suppliers will not be delivering results directly used in patient
care, I e any risk will be excluded from the work.
31 (36)
11 Information about the market survey
11.1 Purpose
The purpose of this market analysis and survey is:
To activate the market in providing feedback on our overall strategy, as described in
this document, as well as ideas, concepts, and products which the market believe
can provide the capabilities sought by us.
The “get to know” the market, I e identify possible suppliers for an eventual
innovation procurement process as well as public procurement process (and thus
innovations partnership).
11.2 Important dates
February 5th
Publishing of material (this document)
February 9th - March 13
th Submitting-of-material period
February 22nd
– March 20th One on one meetings*
*SLL will continuously review material supplied and, if SLL believe such being interesting
for the learning curve of SLL , might invite suppliers to one-on-one-meetings (see section
11.5) continuously.
The above dates and activities are subject to change, should SLL deem it necessary. Such
changes will be published on the same area as this markets analysis document.
11.3 Publishing
This material and supplementary information will be published on www.e-Avrop.com.
11.4 Supplying material
Observe that we do not require a lengthy document nor any detailed description of a
solution.
We are interested in identifying actors with possible interest in all or parts of a
possible solution for CAPACITY and that these actors state as a minimum an
explanation to why and in what overall way they believe they can contribute.
Answering, I e supplying material, is not synonymous with a commitment of any sort.
Material can be supplied by one or several parties together.
There should be one contact person clearly stated in the material, with which SLL
can schedule a one on one meeting or get in touch with for questions.
The material shall be provided in Word format.
11.4.1.1 What to include in an answer
We would like you to address the following areas in your answer, which shall be no more
than 20 pages.
32 (36)
1. Company presentation and, if relevant, a presentation of roles in a possible
consortium.
2. Your general view and feedback on the strategy as we have described in this
document, I e CAPACITY separated from T5.
3. Your ideas, concepts, and possible products/solutions related to the realizing
CAPACITY and how these ideas and concepts relate to our core need of open
architecture (see 13), I e technical flexibility.
4. Your area of interest in and thoughts on being a part of a possible procurement
process.
11.4.2 Q & A
We will answer questions at the best of our ability but as this is not a part of a formal
evaluation process we do not guarantee that all questions will be answered. Furthermore, we
are focusing on the overall architecture and capabilities of a solution – for which it is our
intent that this market analysis will provide – instead of specifications of functionality we
would like interested parties to refrain from asking detailed questions about detailed
functionality requirements.
Please submit questions on www.e-Avrop.com. For general questions, please use the
contact information in section 4.6.
11.5 One on one meetings
Following the submitting of material from suppliers, SLL will decide if to invite some
suppliers for a one on one meeting and dialogue. Such an invitation can also be done before
the last day of set for submitting material, I e we are likely to “open” answers and material
before the last day of admittance and will in case we find such one interesting possibly
engage in a dialogue and one on one meeting asap.
33 (36)
12 Appendix 1 – Conceptual model of enabling maximum
solution flexibility
The below picture is intended to explain the how we believe that a separation of the system
components of a current PDMS will provide the flexibility and scalability we need.
As described in this document, we are underway with defining how the integration and
database level, I e the capture, storage, and exposing of MT-data shall be done.
CAPACITY, then, will be the application layer, consisting of logic and presentation (and of
course an own database, however not responsible for MT integration and storage). We will
as previously described focus on and value maximum flexibility in such a solution, with the
purpose of supplying us with the possibility to implement new functionality and modules
beyond current needs.
Observe that CAPACITY of course will need it own database for possibly short-term
(during a patient session) storage of aggregated data from backend systems and T5 as
well as storing data produced in CAPACITY until such is sent to the main journal
system and/or long-term database for CAPACITY data.
34 (36)
13 Appendix 2 – Our thoughts on “open architecture”
In this document we are using the term “open architecture” to describe our need of technical
flexibility for CAPACITY.
The below definition, which we believe in a summarized way explains our purpose with an
open architecture, is taken from the US Defense Acquisition agency:
“An open architecture is defined as a technical architecture that adopts open standards
supporting a modular, loosely coupled, and highly cohesive system structure that includes
the publishing of key interfaces within the system and relevant design disclosure. The key
enabler for open architecture is the adoption of an open business model that requires doing
business in a transparent way that leverages the collaborative innovation of numerous
participants across the enterprise, permitting shared risk, maximized reuse of assets, and
reduced total ownership costs. The combination of open architecture and an open business
model permits the acquisition of OSA that yield modular, interoperable systems allowing
components to be added, modified, replaced, removed, and/or supported by different vendors
throughout the life cycle in order to afford opportunities for enhanced competition and
innovation.”
Below we have outlined one overall (not stating capabilities which might be needed)
example of open architecture which, if designed and built or enabled through the use of
products and solutions already existing which is designed and built with those architectural
capabilities, we believe possibly could deliver a more flexible technical architecture.
In the picture below Logic engine could f I be analysis or predictions triggering an event for
alarms, decision support or notifications.
Observe that part of an architecture as below could be performed by other systems, f i a
possible future 3R environment.
35 (36)
CAPACITY Core
Event engineUser/Role/
Group
Logic engine
Logic engineEvents / Triggers
Storage Integration
Pat
ien
t A
PI
Jou
rnal
AP
I
Ph
oto
/Dic
om
A
PI
T5 d
ata
AP
I
Syst
em r
elat
ed
AP
I
Big screenMobile device
Integration Engine
Web server
SLL EKAuthorization
Stationary computer
Pre
sen
-ta
tio
n
Picture: Example on an open architecture approach with separation of f I processing logic
and presentation logic. The picture is conceptual, I e not all-inclusive regarding capabilities.
Our ambition is enabling flexible functional scalability.
MARKET ANALYSIS
14 Appendix 3 – Overall description of the core care process
PRE-OP OP POSTOP ICU
Arrival
Identity control
Procedure check with
patient
Preperations
(infarter)
Manual values
(urin)
Ready for operation
Arrival
Connecting MT
devices
Procedure check
(checklists)
Anesthesia & start
Narcosis MT
Clothing etc
Identity control
First incission
Monitoring,
registration, and
journaling
Closing of patient
Waking patient
Unconnecting MT
devices
Transportation to
Postop, ICU, or CU
Handover to Postop Handover to ICU
Connecting MT
devices
Monitoring,
registration, and
journaling
Transportation to ICU
or CU
When stable
Arrival Postop Arrival ICU
Connecting MT
devices
Monitoring,
registration, and
journaling
Ordination &
Administration
Transportation to CU,
discharge, or new
operation