Download Durham and Darlington Electronic Health Record

Durham & Darlington ERDIP
Demonstrator Project
Proposed Pilot Environment
(EHR Simulator)
20/06/01
Version: Final
Authors: SCHIN Team and Eclypsis
EHR Simulator
Contents
1
Executive Summary
2
Background to Simulator
3
4
2.1
Objectives
2.2
Definition
Approach
3.1
Architecture
3.2
Functional Capabilities
Issues, Risks and Identified Problems
Appendices
1
Data Mapping
2
Electronic Health Record Headings
3
Hardware Architecture
4
Software
Contents
Version 1 - 20th June 2001
Version Final - 20th June 2001
EHR Simulator
1
Executive Summary
In parallel with the development of the EHR organisational architectural models by
the SCHIN group involved in the Durham and Darlington EHR Project, which are
designed to illustrate the ethical and security framework for Electronic Health Record
operations, the EHR Simulator is being developed. The Simulator is to provide a
mechanism for the deployment of those concepts using sample data in a test system
which can be reviewed by stakeholder representatives.
The key components of the Simulator are the specification of 'content' (what is in the
EHR) and 'presentation' (who can access the content and how). Additionally, the
communications traffic and system tools to build and maintain the content and access
elements are to be explored.
EHR Content
There are two elements to EHR content. Firstly the structure of the record and
secondly the patient data itself.
Regarding structure, we have made significant progress. Appendix 2 lists the major
data categories and sub-headings by which we intend to structure the record. This is
largely derived form the 'Headings Project' work, which provides a de facto standard
in this area.
Obtaining data to populate the record has proven to be much more problematic.
Our original thoughts as to the content of the Electronic Health Record where based
on the assumption that we would be able to gain access to authentic patient data that
was held in both an acute facility and a sample of three GP practices using 3 different
practice systems. We would then anonymise it and use the data to populate the
Simulator. Originally we were considering using approximately 2000 records. We
have been forced to change our ideas for a number of reasons:1
We made approaches to the major GP suppliers to try and obtain their data
dictionaries and data maps, to find what data could be collected and in what format
this would be. They were not very willing to share this information with what they
thought of as a possible competitor, therefore the information received was very
patchy in depth and volume.
We then visited 2 practices in the locality. The first practice was using IPS and
PathLink (so all lab data was being entered into the system). All the radiology text
results were keyed in manually. We were able, by using multiple screen prints, to map
the data they collected against what could be stored in the proposed central repository
(the Clinical Data Repository (CDR) from the Eclipsys Sunrise Clinical Manager
(SCM) application). The second practice used EMIS to a very minimal level. They
appeared to input no clinical details and, essentially, the system was merely populated
with demographic data. They also have been unable (due to workload) to send us any
screen prints. Thus, to date, we have been unable to map EMIS data.
Executive Summary
3
Version Final - 20th June 2001
EHR Simulator
This highlighted the fact the data existing in different practices differed hugely –
varying from a very complete record to one that was virtually non-existent. An
illustration of data mapping work to date, is provided in Appendix 1.
2
As a result of this research we also found that currently, it is not the practice to
electronically download or transfer patient information e.g. in the circumstance of a
patient moving from one practice to another, even though the receiving practice is
using the same system. A hard copy of the electronic record is usually printed and
sent with the patients paper record. The receiving practice then makes the decision to
either key in all, part, or none of the data into their system. This again highlights the
differing quality and depth of data that is held within each Practice. On further
investigation we found that none of the GP suppliers offer a straightforward method
of performing an electronic transfer of data, which has major implications as to how
we move forward with populating and maintaining the EHR.
3
Minimal research has been carried out as to the structure and content of Social
Services records. There are 2 major suppliers - OMS and Sheridan. Neither system
has the facility to electronically export data and they do not use HL7 messaging. The
content of the data is very different to that seen in NHS systems, as they primarily
collect data that links clients into family groups.
4
It became apparent that we had a number of issues concerning data protection
and confidentiality. The whole concept of the Data Protection Act and the adoption of
BS7799, as they apply to the NHS, is still being developed and defined. A number of
details have to be considered:



What is ‘informed consent’ for the access to a person’s medical record and how
should it be sought? Work is currently being carried out by SCHIN to develop an
acceptable consent form to be used when we are seeking genuine medical records
to populate the simulator.
What level of anonymisation will we have to go to satisfy the Data Protection
Officer and local Caldicott Guardians?
Will it be acceptable for a commercial organisation (e.g. Eclipsys) to hold and
have access to both consented non-anonymised patient data and anonymised
patient data (consented or not)?
How will we be able to use Social Services records? Will we be able to have
access to registers such as “at risk” data concerning a minor, which is heavily
protected.
To try to address the above it has been decided that to allow the configuration of the
first Simulator in the time frame allowed, we need to go with artificial data that is
correct in content and format. Therefore, for the first iteration of the Simulator,
approximately 30 acute and GP style records will be built to populate the database,
that can be used to demonstrate the workflow and functionality that would be possible
should we be able to use genuine patient data.
EHR Presentation
Work on presentation aspects will be commencing in July.
Executive Summary
4
Version Final - 20th June 2001
EHR Simulator
2
Background to Simulator
2.1
Objectives
The Simulator will provide an experimental environment to explore the potential of
the EHR concept housed within an ethical framework.

To implement an EHR simulator environment, on the basis of artificial content but
with the potential for increasing realism of both content and operation.

To verify the ethical and security models and also the proposed operational
characteristics of the EHR service through experiments and evaluation exercises
involving representatives of all the stake holders.

To identify critical technical issues, constraints and opportunities which arise in
developing the simulator which have an impact on any aspect of the architecture
and to reflect these back into the architectural process.
The simulator will contain and present a sufficient quantity of realistic data to provide
a experimental environment to test the proposed architecture and concepts inherent
within the EHR. The data to be used will be based on artificially generated material.
This will provide the ‘corpus’ and will be responsible for all aspects of traffic
simulation and evaluation.
This experimental environment will be populated with some data, which has potential
to become more and more realistic as the overall EHR project matures, and will be
instrumented to provide the means of observing and demonstrating structure and
behaviour.
A framework for conducting tests and evaluations from both the technical and the
user perspectives will be defined and refined through experiments and evaluation
exercises.
2.2



Definition – What are the aims of the Simulator ?
To specify the EHR concept in technical terms
To generate an implementation reference model of the system and its interfaces
required for working with other organisations
To facilitate the possible design and technical specification requirements of an
EHR model.
Background
5
Version 1 - 20th June 2001
EHR Simulator
3
Approach
3.1
Architecture
The proposed Simulator architecture is illustrated below in figures 1 and 2, showing
the proposed data feeds and user access:
Demographics
TextBase
GP
Data Collection
Interface
Engine
PAS
Acute
Identity
Resolution
Resolved
Demographics
Identified
Histories
Medical History
Accumulation
of Data
Database
Interface
Engine
Labs
GP
Database
Population
Identifier
DB
External
Reference
Index
Repository
Social
Figure 1 – Data feeds to the EHR
User Access
Web Server
Database
DB Queries
Views
Security
Resolution
Log
Repository
Auditing
Figure 2 – Stakeholder acces to the EHR
Approach
6
User Terminal
HTML
Web Browser
Security Client
Version 1 - 20th June 2001
EHR Simulator
3.2
Functional Capabilities
What will be delivered and how it will work?
Rationalising demographic information fed from acute, community, Mental
Health and Social Services EPRs.
Overcoming the patient identification problem will be one of the first issues that the
Simulator will have to address. Existing patients will have multiple identifiers on
multiple systems. The simulator will demonstrate a method of rationalising multiple
identifiers fed from two sources by using an externalised master person index.
Simulation of batch feeds to an external index from two representative systems, North
Durham acute EPR and sample GP system data, will be used to populate the
demographic component of the Simulator .
Data for the GP systems will be provided as flat files supplied by SCHIN in an
agreed format and containing sufficient content information to support the EHR
concepts described Section 2. The nature of the GP flat file will be derived from the
existing ‘TextBase’ project, using artificial data. It is anticipated that up to 30
‘artificial’ GP patient records containing both demographic and non-demographic
data will be used.
Using such data will ensure avoidance of data protection and confidentiality issues
relating to the use of ‘real’ patient data. The EPR data will be supplied as a batch file.
Similarly, we will use artificial data representing that available from the North
Durham EPR, mirroring the GP data supplied from SCHIN.
The GP file and EPR file will rationalised using the Eclipsys’ Enterprise Person Index
(EPI) tool.
The inbound demographic data will be cross-referenced against an EPI database
containing all possible identifiers for the same patient. An external reference dataset
containing validated ‘quality’ identifiers (NSTS, Exeter) can be cross-referenced by
the EPI. The EPI will resolve the inbound data to produce ‘clean’ and consistent
resolved demographic data to be stored in the EHR data repository (figure 1).
Clinical Data
Data from other sources (Acute Labs, GP, Community, Mental Health) will be needed
to fully complete the content model. The originating systems (Acute Lab, GP,
Community) will be represented by a realistic sample of data presented in the form of
batch files. Individual data records may contain different identifiers to those held
within the repository. The Simulator will demonstrate the process involved in
resolving identifiers contained within non-demographic data. The batch files will be
processed by the EPI resolving application to ensure that the appropriate patient
identifier is matched with the non-demographic data required to be fed into the EHR
Approach
7
Version 1 - 20th June 2001
EHR Simulator
repository. The result of the EPI processing will be a batch-file representing the
‘cleansed’ data.
Simulation of transfer of these documents from originating systems to EHR.
‘Clean’ data resolved by the EPI application will contain data in a variety of message
formats. An EHR will need to be able to adequately handle such data and transform
data into suitable formats as required to be stored within the EHR. The actual data
content will be supplied by SCHIN and will be sufficient to address the underlying
EHR concepts. This will be based upon information from existing systems so as to
provide maximum value and correspondence to a “real world” view and thus
applicability.
Definition of data content types will be supplied using the work already done on
Headings. Appendix 2 refers to the Headings to be used within the Simulator data
sets. The superset of content data will contain in overall the following headings;
Demographics, Alerts, Visit Summary, Results, Diagnostic Imaging, Documents
(Physician, Nursing, Social Services, Rehab Services, Nutritional Services, health
Visitor, Patient Education), and Vaccination Record.
The Simulator will demonstrate the transformation of data from different message
formats into a format suitable for transfer into the EHR database. For the simulation,
data will be transformed into an international standard message format (HL7 2.3)
using an integration engine (Eclipsys’ eConnect). Transformation to alternate message
formats (XML, EDI) can also be achieved but for this particular Simulator HL7 will
be used as it is a widely used and widely supported Health Message format and can
adequately demonstrate the processes involved in transferring data and documents
from originating systems into the EHR.
The integration engine will take the files output generated by EPI resolution and
transform the inbound message format into HL7 2.3 message format in the
presentation of a batch file. The Simulator will then demonstrate the ‘feeding’ of
transformed data into the data repository. This will achieved using an interface
message feeding application (the InterfacesLite component of the Sunrise Clinical
Manager toolset). The batch file with the ‘resolved identifiers’ and transformed data
can be viewed via InterfacesLite (for illustration purposes) and then sent straight
through into the EHR repository.
Data Repository
The repository will contain summarised clinical data. The repository will receive
feeds from the identified data originating sources. The database will be refreshed
after each simulation for consistent repeatable demonstration of the underling
processes involved in the transfer of data from ‘originator’ to ‘storage’ repository.
This will provide an experimental platform that can used repeatedly to demonstrate
the concepts related to cleansing, transforming and transferring data from source to
repository.
The actual data repository will be provided from Eclipsys’ SCM. Using an existing
flexible schema, designed to support clinical data structures, with inbuilt features for
Approach
8
Version 1 - 20th June 2001
EHR Simulator
maintaining and refreshing the database, will provide a simpler administrative
workload for the purposes of demonstrating the simulator than building a sample
repository using generic database tools.
Configuration of the repository will be done based on content information supplied by
SCHIN working group. Inherent in the configuration will be details on the security
models to from the EHR Demonstrator, based on the done by other collaborators in
the Durham and Darlington and Tees projects.
Security models
The security concepts to be tested by the EHR will be incorporated within the
configuration of the database and reflected in the database schema content.
The Simulator will also demonstrate some of the technical issues related to ‘security’
in a wider context.

Database security – The Database will be located on dedicated database server
with secure login. User information is encrypted within the database. Access to
sensitive patient data will be via the ‘integration toolkit’. User and password
details to the database are encased within business logic code, which is compiled
as binary executables.

User authentication – EHR simulator will demonstrate some of the issues involved
in securing patient data. The simulator will provide access via controlled
identification of users using a ‘sign-on’ methodology. Each of the simulated
Stakeholder groups will be able to logon on via a web browser. The sign-on
application to be used in the simulator will be Eclipsys’ eCompose. This ‘singlesign-on’ application supports biometric and non-biometric (card based)
identification approaches and authentication is achieved via logon with user name
and password. For the purposes of the Simulator, authentication via logon will be
used initially. A separate secure database is used to store ‘user’ logon credentials.
The data held is encrypted and all intercommunication transfer of logon data is
encrypted. Logon audit details is fully tracked and user/stakeholder access to
front-end application is managed by the sign-on application .
For the purposes of the simulator eCompose will be used to verify and audit logon of
the stakeholders and, allow access to pre-defined sub-sections of the front-end
application presented as specific ‘views’ of the EHR repository data.
Presentation - Views into the EHR
The EHR simulator environment will present consistent and appropriate interfaces to
the different sorts of stakeholder involved in working with personal medical records.
The Simulator will demonstrate a variety of pre-agreed views of the EHR data which
can be used to demonstrate possible presentation configurations. Issues such as
Stakeholder access availability and breadth of data access can be tested. The views
will also provide a reference point to test the acceptability of visual presentation
format, content and functionality.
Approach
9
Version 1 - 20th June 2001
EHR Simulator
The simulator will allow Stakeholders to access the EHR via a web browser hosted on
a client machine (Figure 2). The user will have to negotiate secure login prior to
accessing the browser-hosted views. The views will be standard HTML templates
referencing data pulled from the EHR repository. To tie the HTML templates and data
together in a secure and efficient way a middleware application will be used
(eCompose). The application will process requests from users sent from the browser
and pull relevant EHR data out of the repository which will then be sent back to the
browser for presentation to the user. The middleware is designed to create integrated
web applications with full support for encryption (RAS 3DES Diffie Hullman keys)
and support for Digital Certificates. Reference to third-party encryption tool kits is
fully supported for developing a PKI infrastructure.
For the purposes of the Simulator the Stakeholders will be presented with a set
number of pre-agreed views (GP, A&E, and Social Services). Depending on the
agreed access and defined rights of the stakeholder group different subsets of the EHR
data will be presented. The user will be able to navigate through the different views of
data.
Approach
10
EHR Simulator
4
Version 1 - 20th June 2001
Issues, Risks and Identified Problems
In the research leading to this plan for the EHR Demonstrator architecture, a number
of problems have been highlighted. These include:

GP information systems suppliers are unable or unwilling to export information
from their systems in electronic form. As a result, the batch input data will not be
in one of the proprietary formats used in GP surgeries, but in the TextBase format.
Efforts will be made to ensure a reflection of the variety of the GP system formats
within the sample data. It may be possible within a future EHR project requiring
real data to circumvent these data extraction problems by converting data
designed for printouts into a useable format, but a more practical long term
solution is needed using more open GP software or mandated interchange
standards.

Even if data could be extracted from the GP systems for incorporation into an
EHR system, many practices record incomplete data electronically e.g. only
demographics. For an EHR to become useful, a large-scale change in attitudes to
the use of systems in GP surgeries will be required.

Similarly, transfer of data from one practise to another requires generating and reentering a hard copy of the patients’ details. This can lead to incomplete digital
patient records.

The nature of the “informed consent” required for centralised data storage is
currently unclear or impractical. Although the project circumvents these problems
using artificial but realistic data, the next stage of EHR development must find a
way to resolve these issues.

The IT systems of Social Services are even less advanced than those of GPs. As
yet no information has been gathered on the data that Community Health, Social
Services or Mental Health will contribute on the project.

Although the data should be secure against unauthorised users (i.e. validated users
with no rights to access particular data) due to encryption and view restrictions, no
method for identification beyond passwords has been discussed (i.e. how to
determine if the user is who they claim to be).
Problems
Version 1 - 20th June 2001
EHR Simulator
Appendix 1 – Data Mapping
Exeter
Surname
Previous surname
Forename
Other forenames
Extra Name
Title
Sex
EMIS
In Practice
Family Name
Surname
Previous Last Previous Surname
Name
Forename
Forname 1
Calling Name
Forname 2
Title
Sex
SCM
Surname
??? Changes??
Forename
Other forenames
? Other forenames
Title Not there
Sex Gender
Marital Status Marital status
Race
Religion
Patient number
Address 1
identifier
Address
Address 2
Address 3
address 4
Address
Address
Address
Post code
Post code
Telephone Number
Age
Date of birth
New NHS number
Organisation identifier
Deduction reason
/Reason for
movement??
Email address
Location Type
Age
Date of Birth
NHS number
Institute Code
Match code ????
type of match???
Date of transaction
Related Date
Source of transaction
?Encounter Type
Type of transaction ?Registration Type
?Activity Type
Registration Status
Current GP code
GP id
GP Surname
House name Can build multiple
address
Number & Road
Locality
Town
County
Post code Zip code
Address type Address type
Contact Phone Type
numbers(multiple)
Age
Date of Birth Birth date
NHS number Client ID
Facility Code?
Date fields
?Registration ?relevant
Status
Record type
Appendices
Provider ID
Reg GP Care Provider
Version 1 - 20th June 2001
EHR Simulator
GP initials
GP Address line 1
GP Address line 2
GP Address line 3
GP Address line 4
GP Post code
GP responsible HA
GP start date
GP end date
End reason
GP Partnership name
GP Partner local code
Date added
?contact type GP
Health Authority
Registration Date
?comment field
Effective Date
Expiration Date
Transport
Arrangements
Referal Urgency
Language
Requirements
Referral Reason
Funding
Arrangement
Comment field
Comment field
Primary Language
Health issues?
Problems
All Problems Health issues
Currently Relevant Health issues
Consultations
Examination, ?Flow sheet
including
results,entered
by,date
Course Number
Medication Code
Appendices
13
Diagnosis, Health issues
including clinical
note, entered
by,date
Recalls
Date Pre admit visit
Reason
Operator
Medical History
Date Flow sheet ? Put
Problems-Medical in one
Clinical note N.B
Looks like a
longitudanal
consult record
Operater initial
Therapy
Issue number
Drug name One Generic item in
catalogue and a form with
all these data elements
Version 1 - 20th June 2001
EHR Simulator
Dosage
Instructions
Quantity
Prescribing ID
Dosage
Amount supplied
Prescribing Initial
Date Issued
Authorising Person
Prescription Type
Mixture Contents
Lifestyle
Text comment re
smoking
Text comment re
alcohol
Examination
Findings
Date
Operator Initials
Text clinical notes
Weight
BMI
Height
Diastolic With
recall note
Systolic With recall
note
Test Results
Biochemistry
(routine)
?comment field
Flow sheet
Flow sheet
Weight
Flow sheet
Height
Flow sheet
Flow sheet
? Unload University Hosp
catalogue plus
dictionaries
Biochemistry
(Other)
Haematology
Microbiology
Serology &
Immunology
Biochemistry
(hormone)
Diagnostic tests
Other Pathology
tests
HP Interventions
Date Documents
Operater initial
Text heath
education notes
Elderly
Housing text Flowsheet
comment
Relation e.g.
Spouse
Carer's details
Appendices
14
Version 1 - 20th June 2001
EHR Simulator
Risk Factors
Annual Test
include diabetes
Hearing exam
State of mind
Geriatric Health
Exam
Drug Therapy
Bladder
Bowels
Clinician Name
Further Care
Referral
Disease Registers
Note of which
register
Date Placed on it
Operater initial
Immunisations
Date given
Date Booster due
Immunisation
name
Operater initial
Diabetes
Date
DM Screen, text
DM monitoring
status test
DM monitoring
admin text
Diabetic Concerns
text
CV or
Hypertension
Cardiac Disease
Monitoring
Clinician Name
Diagnostic
Imaging
Text report
Epilepsy
Epilepsy Register
Y/N
Managed by text
Last Fit date
Fit details text
DVLC informed
Y/N
Asthma
Appendices
15
Flowsheet
Flowsheet
Flowsheet
University item catalogue
Flowsheet
Version 1 - 20th June 2001
EHR Simulator
History text
Management text
Consultation,
height,PF current
Smoking
Treatment
Broncodilators,Inha
led steroids,
cromoglycates
Allergy
Date of recording
Clinician Name
Read Term for
allergy
Drug?
Allergen?
Read term for
reaction
Reaction type
Severity
certainty
Maternity
Pregnancy Detail Flowsheet
Blood Group
LMP
EDD
Antenatal
Consultation
Date
Clinician Name
Read Term
Seen By
Weeks Gestation
Notes text entry
Weight
Blood Pressure
Haemaglobin
Investigations
Blood Group
Haemoglobin
Iron studies
Rubella
Pregnancy
Outcomes
Delivery Details
Gestation at birth
Stages of Labour
Outcome
Placenta
Appendices
16
Version 1 - 20th June 2001
EHR Simulator
Pap due date
Previous GP code
GP National code
GP Surname (Prev)
GP initials (prev)
GP Address line 1prev
GP Address line 2 prev
GP Address line 3 prev
GP Address line 4 prev
GP Post code prev
GP responsible HA prev
GP start date prev
GP end date prev
End reason prev
GP Partnership name
prev
GP Partner local code
prev
Date added prev
Appendices
Episiotomy
Perineal Tear
Sutures
Infant details
Apgar score
Post natal
Consultation
Postnatal Visit
Postnatal Exam
Postnatal
Symptoms
Weight
Blood Pressure
Maternal breast
exam
Maternal pelvic
exam
Contraception
CS claim due date
Cervical cytology
17
Comment?
Version 1 - 20th June 2001
EHR Simulator
Appendix 2 – EHR Headings
Demographics












Name, full & aliases
Gender including change
Religion
Primary Language & others? Contact for translation? (e.g. relative – contact details?)
Date of Birth
NHS Number
Telephone Number &/or contact method?
Marital Status/social circumstances
Name and address of contact person/next of kin
Employment?
Height/Weight??
Social Worker
Alerts











Allergies
Known problems/Health Issues
Medication History
Family History
Date of next PAP Smear
Date of next Mammogram
Over the counter drug usage
Alcohol Usage
Smoking History
Patient instructions, preferences
Organ donation
Visit Summary













Reason for visit/ Problem & referral source (self, family, SW, CN, etc)
Consultation Note
Vital signs/Observations
Physical Examination
Investigations – carried out, ordered – matching results? Where ordered from?
Referral
Medication Prescribed/Active medications?
Preliminary Diagnosis
Date of visit/inpatient Stay
Type of visit e.g. GP, OPD, Inpatient etc
Service
Summary of Care/medication/surgery etc
Final Diagnosis
Appendices
18
Version 1 - 20th June 2001
EHR Simulator
Results
Laboratory






Haematology
Biochemistry
Microbiology
Serology
Anatomic Pathology
Other?
Diagnostic Imaging





X-Ray and Fluoroscopy
CT & MRI
Nuclear Medicine
Ultrasound
Other Procedures
Documents
Physician





Assessments
Notes
Consultations
Discharge Summary
Operative Notes
Nursing


Assessments
Notes
Social Services



Assessments
Notes
Discharge Plan
Rehab Services



Physical Therapy
Occupational Therapy
Speech Therapy
Nutritional Services

Dietary Assessment
Appendices
19
Version 1 - 20th June 2001
EHR Simulator

Dietary Advice
Health Visitor


Developmental Screening
Assessment
Patient Education


Post Operative Instructions
Home Care Instructions
Vaccination Record





Name of Vaccine
Name of person who administered it.
Date /Dose given
Adverse reactions/severity
Date Booster due
Appendices
20
Version 1 - 20th June 2001
EHR Simulator
Appendix 3 – Hardware Architecture
Servers sufficient to support the proposed configuration and permit a simulator
capable of maintaining a sufficient quantity of data and transactions to provide a
realistic assessment of future needs. Provisional estimate based upon twin IBM
NetFinity 3000 servers with dual processors.
Ethernet
Client
SCM & Associated
Software
EPI
eLink
eSign
Associated Software
Webserver
Fire wall ?
The fire wall is required if the system is to be perminatly
connected the the internet. Should the client be directly
connected the fire wall is optional.
Appendices
21
Version 1 - 20th June 2001
EHR Simulator
Appendix 4. Software
The following Eclipsys application software products will be deployed:
-
Sunrise Enterprise Patient Index
-
Sunrise eWebIT suite, comprising:
eConnect (eLink Integration engine)
eCompose (eView Web integration toolset)
eConfirm (eSign composite application security toolset)
-
Sunrise Clinical Manager Data Repository
Appendices
22