81
Margunn Aanestad Building work-oriented information infrastructures Cases of Electronic Patient Record Systems INF5210, October 28th 2015
Margunn Aanestad
Building work-oriented information infrastructures
Cases of Electronic Patient Record Systems
INF5210, October 28th 2015
Today
• More about design processes that start from
work processes and actual use:
– Specification driven, top-down, enforced
– Pilot, prototype, demonstrator
– «living lab»: cultivation connected to actual use.
• What happens to work/work organization
when an II is built?
– «Infrastructuring of work/work of infrastructuring»
• How to deal with work-related «installed
base» in change processes? 3
Work-oriented perspectives on IIs
• Susan Leigh Star and Karen Ruhleder
(1996): “Steps Toward an Ecology of
Infrastructure: Design and Access for Large
Information Spaces”. Information Systems
Research, vol. 7, no. 1, pp. 111-134.
• Ole Hanseth og Nina Lundberg (2001):
“Designing Work Oriented Infrastructures”.
Computer Supported Cooperative Work
(CSCW), vol. 10, nr. 3-4, s. 347-372.
4
Star og Ruhleder (1996): definition p. 113
– EMBEDDEDNESS
– TRANSPARENCY
– REACH/SCOPE
– LEARNED AS PART OF MEMBERSHIP
– LINKS WITH CONVENTIONS OF PRACTICE
– EMBODIMENT OF STANDARDS
– BUILT ON AN INSTALLED BASE
– BECOMES VISIBLE UPON BREAKDOWN
5
6
From Edwards, Jackson, Bowker & Knobel (2007): ”Understanding Infrastructure:
Dynamics, Tensions and Design. Report of a Workshop on “History & Theory of Infrastructure:
Lessons for New Scientific Cyberinfrastructures”
Articles/cases today:
• Margunn Aanestad and Tina Blegind Jensen (2011)
Building nation-wide information infrastructures in
healthcare through modular implementation
strategies, The Journal of Strategic Information
Systems, 20(2),161-176
• Margunn Aanestad, Bob Joliffe, Arunima Mukherjee,
Sundeep Sahay (2014): «Infrastructuring Work:
Building a state-wide hospital information
infrastructure in India”. Information Systems
Research, Special Issue on Information, Technology,
and the Changing Nature of Work, 25(4), 834-845
7
• What can we learn from comparing large-scale, strategic
national projects (which usually fail to deliver) with small-
scale initiatives that succeed?
• Paper with Tina Blegind Jensen (CBS):
– Case study of two Danish projects
• Our initial focus:
– The project’s ambitions (and the consequences of
these ambitions)
– The project’s approach – “how to get there from here”
Framework from first version of paper: Three
dimensions of complexity in information
infrastructures
Jensen, Tina Blegind and Aanestad, Margunn:
”NATIONAL INITIATIVES TO BUILD HEALTHCARE INFORMATION INFRASTRUCTURES”
MCIS 2010 Proceedings. Paper 43. http://aisel.aisnet.org/mcis2010/43
Possibly more ’dimensions’?
For example:
Degree of change (how radical)
Depth of penetration (how comprehensive)
Shared EPRs in Denmark:
• Electronic Patient Record
• Comparing the story of:
– The (failed) B-EPR initiative
• Danish: G-EPJ – Grundstruktur for EPJ (Basic Structure
for Electronic Patient Record Systems)
– The successful SEP initiative
• Danish: SUP – Standardiseret Udtræk av Patientdata
(Standardized Extraction of Patient Data)
• Today: the ”eRecord” in www.sundhed.dk
Background
• “Action Plan for EPR systems” in 1996:
– promote, stimulate, and coordinate the
development of EPRs in Danish hospitals
– 13 EPR implementations, the EPR Observatory
• The Board of Health created the B-EPR
project
– Important conceptual principles of B-EPR vision:
• structured data, process-orientation, problem-
orientation, cross-disciplinarity, trajectory-orientation
(“2nd generation”)
– Renewing national database:
• Develop a new Forløbsbasert Landspatientregister to
replace existing Kontaktbasert Landspatientregister
Denmark’s B-EPR initiative
The EPR should be structured to support the clinical process (i.e. the problem solving process:
Diagnostic consideration
Planning
Execution
Evaluation
Political backing
The National Strategy (2003 – 2007) says:
The B-EPR should be the foundation for the coordinated development and implementation of EPRs in Denmark (i.e. the national standard).
Purpose: “…to ensure a common structure for communication among [EPR] systems and between [EPR] systems and other information systems in the healthcare service”
A full-scale implementation across Denmark should be achieved within January 1st 2006
This was agreed upon in the ‘Economy Agreement between the Government and the Association of County Councils’ for 2003
Development of the B-EPR
Managed by Sundhedsstyrelsen/Board of Health
2000: version 0.1 was subjected to a hearing
Version 0.2 – the ABE project (Gentofte)
A larger revision - version 1.0
2002: UML specification for two modules (medication, imaging)
The GEPJ was included in the National Strategy (2003-2007)
Updates to version 1.0 was published in 2003 and 2004
Version 2.0 published in March 2004
The GEPKA projects (7 counties’ hospitals) as well as a hearing provide inputs
Version 2.2 accepted by EPR standardization group (August 2005)
GEPKA pilots
2003-2007: a number of pilot projects initiated to test and evaluate the B-EPR
model in practice (GEPKA projects)
Hospitals in seven counties participated
Evaluation reports showed that a common structure for EPR systems was
challenging
Not easily transferable to a clinical setting; would require substantial changes in
clinical practices
Information was too fragmented and not well-structured, leading to poor user
interfaces
Difficulties for two EPR systems built upon the B-EPR structure to exchange
data:
What data to be communicated?
What rules for security issues and consent?
Which technical standards to be used? Etc.
The end of B-EPR
• Critical report by P.S. Olsen 2004, dismissed by the Board of
Health
• The EHR Observatory status report for 2005:
– mentions technical and organizational challenges in realizing the B-EPR
model
• The EHR Observatory status report for 2006:
– recommend that the B-EPR is put on hold
• Winter 2006/Spring 2007: Deloitte conducts an independent
review of the EPR status, which documented that
– A full-scale implementation of any B-EPR based EPR was not imminent
– Development work was not ongoing, current version not yet tested
– Danish healthcare terminology (SUNDTERM) not finished until 2010.
– The municipalities were not interested in implementing G-EPJ
• Current strategic plan: the B-EPR was only mentioned in an
appendix where the conclusion from the Deloitte report on B-
EPR was repeated.
Large ambitions on many fronts
Functional span:
- Problem-oriented documentation and
cross-disciplinary
- The need for structured clinical
terminology
- Revised: medicine card and national
patient index
Geographical scope:
- Define a patient record for both primary
healthcare and hospital sector across the
whole country
- A lot of local EPR systems already
existed
- In steps implementation of medicine card
and national patient index
Temporal reach:
- Radical changes were expected within a
short time frame
- The ambition that all Danish hospitals
should have EPR systems before 2006 was
modified Ref. Jones: ”more modest targets”
A different story - SUP
• SUP - Standardiseret Udtræk af Pasientdata
– Extract data from different EPR systems, provide access
through web browser to a SUP database
• Developed in Jutland hospitals (Vejle and Viborg)
• Solved real problem:
– Transfer of newborn children & mother to pediatric and
gynecological/obstetric wards
– Patient transfer between surgical dept., medical/cardiology
dept and thoracic surgery dept.
• http://www.epj-
observatoriet.dk/konference2001/slides/parallel1datamodeller/PeterSyl
vest270901.pdf
A different story - SUP
• Pilot testing
– Somewhat limited functionality in pilots, but real-
life use
– Continued use (in pilot site) after pilot period
ended
• MedCom project from 2003
– Inter-county communication, address registries,
security administration, distribution of XML
standards, coordination of purchase processes
– «Infrastructuring process»
SUP growth
• 2004: available for hospitals in Vejle County
• 9th January 2007: available for all citizens in previous
Viborg county.
• 23rd January 2007: opened for all General
Practitioners within the previous counties of Viborg,
Aarhus, Vejle, Southern Jutland, and Funen.
• 10th December 2008: Copenhagen Region – for
doctors and citizens
• April 1st 2009 there existed an e-record for 4.3
million Danes
• Denmark has achieved (sort of) interoperability
between EPR systems through a non-strategic
project
Differences w/SEP (from B-EPR)
• No changes in data registration or work practices required
• Hospitals could keep existing EPR systems
• Small work task for EPR vendors
• Immediate, not future benefits
• Low number of stakeholders
• No need for comprehensive, new healthcare terminology
• No coupling to national registers (FLPR/KLPR)
– In other words:
– Building on installed base
– Gradual evolution, iterative, step by step (cultivation)
– Minimizing (avoiding) complexity
• Deloitte report stated that one of the
main difficulties had been in realizing
“large and ambitious goals in a few
giant leaps” (Deloitte 2007, p. 49).
• Large undertakings must be broken
down to smaller tasks (decomposed),
sequenced, etc.
– But how?
• B-EPR was composed by modules, pursued
iterative development, learning from pilots etc…
Modularity/hierarchy in complex
systems
• Herbert A. Simon:
– “The Architecture of
Complexity”
• Proceedings of the American
Philosophical Society, Vol.
106, No. 6. (Dec. 12, 1962),
pp. 467-482.
– The parable of the two
watchmakers
From Wikipedia:
American political scientist, economist, sociologist, and
psychologist, and professor—most notably at Carnegie Mellon
University—whose research ranged across the fields of
cognitive psychology, cognitive science, computer science,
public administration, economics, management,
philosophy of science, sociology, and political science.
With almost a thousand very highly cited publications,
he is one of the most influential social scientists of
the 20th century.
There once were two watchmakers, named Hora and Tempus, who made
very fine watches. The phones in their workshops rang frequently and new
customers were constantly calling them. However, Hora prospered while
Tempus became poorer and poorer. In the end, Tempus lost his shop. What
was the reason behind this?
The watches consisted of about 1000 parts each. The watches that Tempus
made were designed such that, when he had to put down a partly
assembled watch, it immediately fell into pieces and had to be reassembled
from the basic elements. Hora had designed his watches so that he could
put together sub-assemblies of about ten components each, and each sub-
assembly could be put down without falling apart. Ten of these sub-
assemblies could be put together to make a larger sub-assembly, and ten
of the larger sub-assemblies constituted the whole watch.
24
Modularity in software design
• Seminal paper: – Parnas, D.L. (1972) On the criteria to be used in
decomposing systems into modules,
Communications of the ACM 15 (12), 1053-1058.
• Criterion of information hiding – Alternative formulation: high cohesion within
modules and loose coupling between modules
• “It is almost always incorrect to begin the
decomposition of a system into modules
on the basis of a flowchart. We propose
instead that one begins with a list of
difficult design decisions or design
decisions which are likely to change. Each
module is then designed to hide such a
decision from the others” (Parnas 1972, p.
1058).
From Wikipedia:
David Lorge Parnas, a Canadian
early pioneer of software
engineering.
Developed the concept of
information hiding
in modular programming/software
design.
Modularity in IIs
• Challenge in inter-organizational Iis
– To mobilize, organize and coordinate the action of
a diverse set of actors
– Assymetric distribution of costs/investements and
benefits give rise to ”collective action” dilemmas
• Existing II studies:
– Bootstrapping (Hanseth and Aanestad, 2003;
Hanseth and Lyytinen, 2010)
• How to select a wise starting point and to sequence the
growth process (maximize no. of users, reach critical
mass, unleash self-reinforcing effects)
Modularity
• Modular implementation approach
– A precondition for ”realizable” IIs?
– Assist in stakeholder mobilization/organization
• Vs Hanseth and Lyytinen: modularity not
(just) in order to deal with the adaptability
challenge, also the bootstrap challenge…
Modular implementation approach
• Direct usefulness:
– The solution (at each stage of development)
solves a concrete/actual problem
– Thus costs/investements can be justified
• Generic solution
– Reusable by many
• Decoupled implementation
– Lesser demands on stakeholder coordination
29
30
Second article:
• Margunn Aanestad, Bob Joliffe, Arunima Mukherjee, Sundeep
Sahay: «Infrastructuring Work: Building a state-wide hospital
information infrastructure in India”.
31
32
33
34
35
36
Storyline
• HISP India worked with NSTATE on DHIS
implementation
• 2009: MoU (Memorandum of Understanding)
incl. «e-health architecture», tender process
• Development, deployment, in pilot hospital +
in 20 hospitals (contracted) + more…
• Spread to other Indian states, other countries
• Developed based on OpenMRS…
37
OpenMRS (Open Medical Record System)
• Established in 2004, non-profit (open source)
community, led by Regenstrief Institute and
Partners In Health (Boston)
• OpenMRS is “a software platform and a
reference application which enables design of a
customized medical records system with no
programming knowledge”
– Core: Concept dictionary
• But: EPR system for clinic - not a full-fledged
hospital information system 38
• INGO team: 4 developers, 7 public health people
• Team designed 10 core modules and new work
processes in a participative process
39
40
ROUTINE PATIENT FLOW AT DDU
REGISTRATION
OPD
BILLING
INVESTIGATIONS (Gen lab/
Radiology/ national prog labs/
blood bank)
PROCEDURES
DRUG DISPENSING REFERALS
IPD
EXTERNAL REFERAL
OTHER OPD’S & NATIONAL PROGS
OPD Follow up
PATIENT
REGISTRATION EMERGENCY (Stabilization)
OPD IPD PROCEDURES EXTERNAL REFERAL
PATIENT
LABOUR ROOM EXTERNAL REFERAL
OT
IPD
Discharge
INTERNAL REFERAL
MINOR PROCEDURES
41
Working with staff
• Participatory Design process
– Work flow study, sketches, mock-ups, discussions
with clinical and admin staff
– Next slides : examples from what was presented
in consultations with end users
• Example 1: documenting patient information
42
Admitted Patient
Last date any investigation(s)
was/were reported
<value2>dd/mm/yyyy
<value1>dd/mm/yyyy
Hemoglobin
<value2>dd/mm/yyyy
<value1>dd/mm/yyyy
Hemoglobin
Hematology :
<value1>dd/mm/yyyy
ESR
<value1>dd/mm/yyyy
ESR
Biochemistry :
<value2>dd/mm/yyyy
<value1>dd/mm/yyyy
Fasting blood sugar:
<value2>dd/mm/yyyy
<value1>dd/mm/yyyy
Fasting blood sugar:
View Date of visit Type of visit Treating doctor Diagnosis Procedures
(if any)
Linked visit
<dd/mm/yyy> <OPD
visited/IPD
Admitted>
<doctors name> <diagnosis> <New
complaint>
/<follow
up>
Summary of clinical interactions
Link current visit Remove link
If possible to show hierarchy of linked visit by first visit and follow up then subsequently by date
Linking of visits is a way in which all visits to the hospital could be linked based on the management of a particular
diagnosis. This could also be done form the opd entry screen (logic
being assessed).
• HospIS: accumulate information for revisit patients
– Better patient care + analysis of services
• OPD: high workload, sceptical to HospIS
– Selective documentation: chronic conditions only
51
52
53
BEFORE:
Radiology reports
written in free text
Staff’s concern:
Too much to type
into system
EXAMPLE 2: Standardization of radiology reports
• Hospital radiologist involved other colleagues in
state, who jointly defined:
– List of tests (36 test but flexible to add more)
– For each test: relevant parameters to report on
– For each parameter: result options
• Joint (state-wide) standardization process
– Community building and quality improvement
54
Re-organising work with HospIS
• Registration before:
– Not compulsory for all services
– Needed «OPD slip» to see an OPD doctor
– (Patients might reuse old OPD slips)
– No queue control, no overview of OPD load
• Registration after:
– Compulsory registration of old and new patients
– Placed in queues by HospIS system, queues displayed
to OPD staff and patients called acc. to queue no.
– Additional information collected 55
Re-organising work with HospIS
• Billing before:
– Done distributed (labs/exam. rooms)
– Referral to lab by OPD doctor: go to «room 31»,
then to lab to pay
• Billing after:
– Centralized to one site (freeing time for lab staff)
– Linked to labs (not bill for unavailable services)
– Eliminated the visit to «room 31»
56
57
58
«Judicious design»
• Laser printers -> dot matrix, pre-printed paper
• Printing the «OPD slip» to be annotated along the
process (tests, medicines) 59
60
61
Iterative, evolutionary, careful ‘cultivation’
• Reduce complexity
– 10 core modules (clinical care, hospital adm)
kept, while 10 ‘nice to have’ modules stripped off
(e.g. modules for diet, laundry or archiving digital
images)
• Context-aware design
– Hybrid design (digital/paper), e.g. OPD slip, dot
matrix printers, local support
• Stepwise introduction
– Start with ‘simple’ and visible modules
– Adjust when going to new settings 62
Scaling to other hospitals
• Now in 20 district hospitals across state
– Plus 2 medical colleges, + 15 PHCs
• Process: Site visit, situational analysis,
customization of system, initial support
• INGO’s emerging realization what a «hospital
information infrastructure» really is and
demands.
– More than a number of identical systems installed
in a various sites.
– Something distinctly «infrastructural» 63
• What is «infrastructural»? We can see
Infrastructure as:
– underlying (invisible, enabling, supporting work)
– having spatial extent (multiple sites, users, usage
needs, conditions)
– having temporal duration (sustainability, support)
• Work of infrastructuring:
– the work associated with the building of an II
• Infrastructuring of work:
– the effect of the II building on the ‘core’ work
– example: … 64
Patient registration: more data captured
• Patient demographics
– name, age, gender, address, phone number, next-of-kin
• Patient category
– health insurance type/number, Below Poverty Line
beneficiary, state govt. employee, central govt.
employee, physically challenged
• Referral information:
– referred from type of facility (primary health center,
health post, community health center)
– reason for referral (investigation, surgery, TB etc.)
• Instructions on which OPD room to visit. 65
..reflects multiple information needs…
• Hospital management
– patient demographics and financial categories
• Public health officials
– patient addresses and referral reasons
• State authorities
– standardize patient registration across the state
– overall picture of health system performance and
health situation
66
«Informating» health management
• It is now possible to
– examine referrals (where patients come from, for
what service, demographic profiles),
– disease profiles (diagnoses disaggregated by age
and gender),
– hospital management (billing, stocks, patient
loads, bed utilization, etc.) and
– epidemiology (disease incidence and prevalence,
patterns in the spread of diseases).
67
«Informating» health management
• Such data can be used to
– identify and strengthen weakly performing units
– construct disease and mortality profile
– strengthen administrative processes
– improve resource optimization
– conduct inter-hospital comparisons of
performance, resource utilization and disease
burdens.
– strenghten epidemiological research and analysis
at the state level 68
Shoshana Zuboff: «Automate/informate»
• Zuboff’s argument:
– Automation of production (e.g. CNC) produced
information. New skills required from workers to
deal with data instead of physical processes.
– Presence of information also opens new potentials
– «informating» the work and the organization
• (Our paper aim to examine this in an II context) 69
HospIS, automating and informating:
• Some examples of «real automation»
(understood as delegation of work to the
system):
– computerized inventory control, queue
management, report generation
• Most: Intended redesign and change of work
to achieve efficiency, transparency, quality
– Disciplining patients, standardize documentation,
simplify billing structures etc
70
Changes: not the same for all
• Work of lab technicians simplified
• Additional work for registration clerks and for
OPD doctors (more data to be entered)
• New work tasks (support)
• Work of IPD nurses: simplified (patient
management) and «complexified» (drug
dispensing)
71
New linkages drive changes
• Within organization:
– Better logistics with tighter couplings (info flow)
between departments
• Between hospitals
– Possibilities for new types of collaboration (ex.
pharmacies, blood banks)
• At state level
– Possibility for ‘informated’ decision making based
on more immediate and richer data
72
• Automation of work (delegating to the
‘machine’) accompanied by additional work
(to feed the ‘machine’)
• Informating not only a «by product» of
automating, but can also emerge from a
deliberate attempt to «informate» the
organization
• Linkages/connections central
73
74
Dependencies between process
strategy, architecture and governance
approach
75
Governance
(structures for regulating process,
e.g. for participation in
decisionmaking)
Process strategy
(temporal organization of activities, e.g.
sequencing, phasing, prioritization)
Architecture
(the structural characteristics of the II)
State-level architecture decisions
• Online installations communicating with one
central db (store all data centrally)
– or
• Distributed installations (local dbs) to
communicate with central db (send reports to
data warehouse)
• Debated in several rounds (workshop Jan
2012)
76
State-level architecture decisions
• Some factors:
– Connectivity and uptime of state WAN?
– Competency to support local installations?
– Uncertainty about regulative requirements (new
data protection legislation coming)
– Relatively little movement of patient, little need to
share patient data across facilities
• Decision: local servers for patient data,
aggregated data to be exported to state’s
data warehouse daily. 77
Localizing the data model
• Open MRS: ~ 2500 concepts (but oriented to ART)
• Millenium Village Project (considered global best
practice and mapped to ICD10 and SNOMED CT)
~45 000 concepts
• INGO decided to develop own concept dictionary
w/3500 concepts (from practice)
– Generic/common and specific
• Curatorship: developers -> PH/clinical staff
• Appropriate model for governance of metadata?
State? INGO (national/international) 78
Contracts, procurement etc.
• Need for a way to assign responsibility for
e.g. HW procurement, LAN design and
installation
• Budgeting routines
• Running support (long-term) – state vs.
District:
– Ex. Provision of stationery (preprinted paper)
• State, district, hospital, third party or INGO?
79
Support, capacity building
80
Institutionalizing support structures
• INGO -> Interested staff
– Data entry staff from local IT company
– E.g. clear paper jams, restart server, run backup
• Same model used in other hospitals
• 2014: new cadre of workers in state
– defined skill sets and career paths
– IT cells: support and training of clinical staff
• Professionalization also of INGO
– tools, processes 81
• The work of infrastructuring
• The infrastructuring of work
• Co-occuring in a recursive relation, IIs ‘never
complete’…
82
