of 23
8/8/2019 Use Case - CalRHIO ED Linking
1/23
CalRHIO ED Link Table of Contents
Use Case Specification
CalRHIO EDLinking Project Use Case
Use Case Specification
Version 2.1
8/8/2019 Use Case - CalRHIO ED Linking
2/23
Page ii
Prepared by Timothy KwanPrepared for CalRHIO ED LINKING PROJECTVersion Released 01/06/2006Document Status Draft
8/8/2019 Use Case - CalRHIO ED Linking
3/23
CalRHIO ED Link Table of Contents
Use Case Specification
Page i
Table of Contents
1. Use Case Revision History table 12. Description of CalRHIO Emergency Department Link Use Case 23. Scope of CalRHIO Emergency Department Link Use Case 34. Stakeholders for Use Case 45. Pre-Conditions 6
5.1 A patient requires emergency care and presents at an Emergency Department 65.2 Identifiable patient requires emergency care 65.3 Patient has had previous treatment at a participating data provider 65.4 Data Sources meet CalRHIO standards (standards TBD) 65.5 Data Users meet CalRHIO standards (standards TBD) 65.6 Data Sources filter clinical data 6
6. Obstacles to Implementing Use Case 76.1 Authentication 76.2 Federated Search Limitation 76.3 Patient may not provide accurate information 76.4 Reconciling information sources 7
7. Post-Conditions 87.1 Patient treated 87.2 System logs user out 87.3 Updates to patient information 87.4 Search / Use transaction record 87.5 Use of Clinical Data 87.6 ED User Configuration 87.7 System effectiveness feedback loop 8
8. Details of Use Case Scenarios and Perspectives 98.1 Patient Perspective 128.2 ED Staff Perspective 138.3 System Administrator Perspective 178.4 Data Intermediary Perspective 18
8/8/2019 Use Case - CalRHIO ED Linking
4/23
8/8/2019 Use Case - CalRHIO ED Linking
5/23
CalRHIO ED Link Use Case Revision History table
Use Case Specification
Page 1
1. Use Case Revision History table
Version
Number
Description of Change Name of Author Date Published
1.0 Initial draft Tim Kwan 11/22/2005
1.3 Incorporated feedback from CalRHIO ED
subgroup meeting on 12/6/2005. Expanded
alternative flows, added sequence diagram,clarified principles and data providers /users.
Tim Kwan 12/9/2005
2.0 Incorporated feedback from CalRHIO EDsubgroup meeting on 12/13/2005. Added
ONC advisory elements to ED via entity-driven perspectives.
Tim Kwan 12/15/2005
2.1 Added data intermediary perspective Tim Kwan 01/06/2006
8/8/2019 Use Case - CalRHIO ED Linking
6/23
Page 2
2. Description of CalRHIO Emergency Department Link Use Case
Problem we want to solve:
o Improve patient safety and clinical care effectiveness by delivering clinical data about the patient
at the point of care in the Emergency Department.
Basic issues for success:o Connect
o ID Patients
o Exchange Information
The ED Project Team continues to have an important role to play in managing the ED Linking Project with the
Technology and Clinical Working Group providing oversight as needed.
Key principles that the project will abide by include:
o The latest information available about the patient will be a priority whether from health plan/payeror hospital source (medication, laboratory, radiology, clinical notes, EKG).
o Feedback from ED physicians is essential.
o No centralized databases will be used to host clinical information; information will come from
existing sources of data.
o Use of existing clinical information sources includes electronic systems and human resources in
any existing combination or business model
o CalRHIO leadership will be leveraged to bring organizations together.
o Secure transactions that ensure compliance to all privacy standards will be established. Project
should establish project collaboration and technical communication among California providers.
o Project should reflect Technology and Clinical Working Groups decisions regarding priorities,
technology, privacy and security, other.
8/8/2019 Use Case - CalRHIO ED Linking
7/23
CalRHIO ED Link Scope of CalRHIO Emergency Department Linking Use Case
Use Case Specification
Page 3
3. Scope of CalRHIO Emergency Department Linking Use Case
This use case will present the ED work flow, perspectives, alternative flows, pre and post conditions. The ED
Linking Project Team will iteratively refine this document and maintain it so that it can be translated into technicalrequirements.
This document will focus on a high-level use case for the project. It will not attempt to address the following:
Redefining workflow that might be necessary for an individual hospital.
Specific staff members who would do tasks as this is the prerogative of the individual hospital.
Technical limitations or design of the system that will support the actions described.
System will not allow for data input to a patients clinical information. All clinical data will be pulled from
existing data sources.
The following components will be specifically addressed by the use case:
Usage of the system from the point of patient entry into an Emergency Department
Data exchange architecture must work across regions (statewide) as well as across a community. Project should demonstrate minimal development time and resources to populate data sources.
8/8/2019 Use Case - CalRHIO ED Linking
8/23
Page 4
4. Stakeholders for Use Case
Relationship diagram:
The participating data sources (data providers) and key stakeholders are:
Clinical data sources: Integrated delivery systems, physician providers, other provider
organizations, disease & immunization registries, labs, pharmacies, free-standing radiologic Dx
centers (MRI, CT), free-standing surgi-centers, nursing homes, free-standing home healthproviders, etc. All of these sources will maintain clinical records of some sort, and may be data
contributors in this scenario either as primary contributors, or as referral providers based onpre-existing records.
Payors: Health Maintenance Organizations, Medi-Cal payors will have eligibility and claims datathat can be contributed.
Government agencies: DMV may have demographic data that can be used to validate identities.
Pharmacy: Pharmacy benefit managers or Hubs will have medication lists and other data tocontribute.
The participating users will be members of CalRHIO and are a part of:
Emergency Departments
Bio-surveillance Organizations
ED LinkingSystem
DataUsers
Patient
DataProviders
8/8/2019 Use Case - CalRHIO ED Linking
9/23
CalRHIO ED Link Stakeholders for Use Case
Use Case Specification
Page 5
For the purposes of the initial prioritization, this use case will be focused on EmergencyDepartments; however, the project recognizes that the system could be expanded to include a
number of additional user roles and will work towards a flexible technology platform that willenable participating organizations to customize the system to their particular workflow.
Walk in clinics
Urgent Care centers
Primary or Specialty Care Providers
Bio-surveillance organizations
Perspectives presented in this use case are:
Patient this includes both the individual patient or patient representative.
ED staff - includes all levels of users such as clinicians, triage nurses, registrars. The respectiverole and how the system is used by role is to be determined by each participating data user.
Data intermediary includes any external systems or organizations that may receive information
requests via CalRHIO ED Link
System Administrator includes all levels of administrative usage. The same individual may be astaff member or administrator of the system depending on how delegation is established by each
participating organization.
8/8/2019 Use Case - CalRHIO ED Linking
10/23
Page 6
5. Pre-Conditions
5.1 A patient requires emergency care and presents at an Emergency Department
The use case starts at the point in which a patient presents at the Emergency Department. This
patient actor event serves as the trigger to the main use case.
5.2 Identifiable patient requires emergency care
A patient requiring emergency care who can present the minimum level of demographic data isnecessary. The key assumption here is that the patient is identifiable in some manner so as toretrieve some clinical record.
5.3 Patient has had previous treatment at a participating data provider
The patient must have some record at a participating data provider for the system to find anyinformation.
5.4 Data Sources meet CalRHIO standards (standards TBD)
To become designated as a validated source of clinical information connected to EDLinking, each
source must meet standards of data content (standards tbd - e.g., meds, allergies, EKG, labs, priordiagnoses, discharge summaries), security standards (tbd), interface standards (tbd), coding
standards (tbd), quality standards (tbd), other standards (tbd).
5.5 Data Users meet CalRHIO standards (standards TBD)
To become designated as a validated user (requestor) of clinical information connected to theCalRHIO ED Linking project, the institution and user must be registered with CalRHIO in a such a
way that allows access attribution for the purposes of logging access to records.
5.6 Data Sources filter clinical data
Patient confidential data is to be filtered at the data source. The ED linking system will enable a
service wide patient opt-out; however, the assumption is that each participating data source willtake on front-line filtering based on that organizations data sharing rules.
8/8/2019 Use Case - CalRHIO ED Linking
11/23
CalRHIO ED Link Obstacles to Implementing Use Case
Use Case Specification
Page 7
6. Obstacles to Implementing Use Case
6.1 Authentication
In order for a participating data provider to accept and honor a request for data there must first be
authentication that the data requestor (data user) is a participant in the CalRHIO HIN, and theremust be an explicit assertion that the data being requested is necessary for the treatment of the
identified patient at the requestors organization.
6.2 Federated Search Limitation
HIPAA rules require the maintenance of patient privacy unless there is an explicit request for that
persons data for the purposes of TPA, or unless the patient has granted explicit approval for theirrecords use. For this reason, it may not be possible for Covered Entities to allow other entities,regardless of their Covered status, even with BA agreements in place, to search a list of potential
patient matches (perform an MPI search).
6.3 Patient may not provide accurate information
It is recognized that the patient may choose to or accidentally provide demographic information that
is incorrect and results in mismatches. This event may lead to incorrect results or lack of results.
6.4 Reconciling information sourcesVarious information sources may present conflicting clinical data. As part of the workflow or system,
there needs to be consideration to this issue and how it can be reconciled. The ED project team willrequests the clinical working group to review this issue.
6.5 Data security concerns for public health data needs
The rules and regulations surrounding data security are not fully established with regards to what
can be used for public health surveillance which currently limits the type and quantity of data thatmay be available to bio-surveillance data users.
8/8/2019 Use Case - CalRHIO ED Linking
12/23
Page 8
7. Post-Conditions
7.1 Patient treated
After data from the system are made available, the patient is treated accordingly.
7.2 System logs user out
After data is retrieved and used for treatment, the system ends the session and logs the
transaction. The definition of session in this case is defined by each organizations workflow.
7.3 Updates to patient information
Any updates to patients clinical information will be handled at the source system and not throughthe ED Linking utility.
7.4 Search / Use transaction record
After a search, a record of the transaction from the requestor to the data provider will be enabled
for organizations that request or require some acknowledgement of data use at a transactionlevel.
For discussion: The fact that the patient was treated (and some specifics of the treatment) isimportant information to be included in our EHR. As a plan, this will be minimally required
information for the requesting provider to give us anyway in order to be paid for (or credited for)the ED visit (already covered under the TPA provision). I believe that excluding the possibility of
the return trip is short sighted and not a limitation that is needed (again, this can be a use casealternate flow or follow-on extension after the POC is operational).
7.5 Use of Clinical Data
There is no determination for purposes of this use case of how clinical data will be used orincorporated into the data receivers systems such is left to the determination of the individualinstitutional participant. It is an assumption of this use case, however, that the clinical data will be
presented in such a way as to be directly loadable into the data receivers systems if such isdesired by that institution.
7.6 ED User ConfigurationThe ED user will be able to customize their user experience such as trusting particular data viadefault search criteria. User configuration and system administration use cases will detailed in
the technical requirements and in other use cases.
7.7 System effectiveness feedback loop
After a clinical data search and retrieval, the system should have some method to track theeffectiveness of the data search and system use. This would help answer the basic value
proposition question of the system. Included in this would be information on how frequently thesystem was able to locate data on patient searches and whether the actual clinical data returned
was useful in the treatment of the patient.
8/8/2019 Use Case - CalRHIO ED Linking
13/23
CalRHIO ED Link Details of Use Case Scenarios and Perspectives
Use Case Specification
Page 9
8. Details of Use Case Scenarios and Perspectives
Perspectives Diagram:
ED Link Use Case
Perspective 1:Patient
Perspective 2:ED Staff
Perspective 3:System
Administrator
Event 1: Providedemographic data
Event 2a:Authorize Access
Event 1a: Requestdemographics
Event 2b: Opt-out
Event 3: Requestfor clinical search
history
Event 2: Log intosystem
Event 3: Meetsystem use cr iteria
Event 4: Search forpatient
Event 1b:Configure system
Event 5: Search forclinical information
Event 6:Review clinicalsearch results
Event 7:Review clinical
results
Event 2b: Changepassword
Event 1: Log intosystem
Event 2:Administer users
accounts
Event 3:Administerinstitutions
Event 4: ReviewLogs
Perspective 4:Data Intermediary
Event 1: ReceiveRequest
Event 2: Verifydemographics and
patient identity
Event 4: ClinicalData Query
Event 3: Verifyrequest for clinical
information
Event 5: Present &discuss clinical
results
8/8/2019 Use Case - CalRHIO ED Linking
14/23
Page 10
Sequence Diagram:
Use Case for ED Linkage
ED StaffED Linkage
System
Presents at ED
Patient Inquiry Search Clinical Data
Patient
Search MasterPatient Index
Maintain Audit Trail
Hospital &Payer Systems
Locate ClinicalResults
Present Clinical Results
SystemAdmin
Review Audit Trail
Treat Patient
8/8/2019 Use Case - CalRHIO ED Linking
15/23
CalRHIO ED Link Details of Use Case Scenarios and Perspectives
Use Case Specification
Page 11
Use Case Diagram
System
ED staff Login
Authorizes Access
Patient
*
*
Search master patient index
*
*
Search for patient
Providesdemographics
*
*
*
*
*
*
Verify patient
Search forclinical data
Review clinicalresults
Treat patient
*
*
*
*
*
*
*
*
Maintain audit trail
Locate clinical results
Present clinical results
System Admin
Create / modify userroles and groups
*
*
Review audit trail
*
*
*
*
Data Intermediary
*
*
*
*
*
*
8/8/2019 Use Case - CalRHIO ED Linking
16/23
Page 12
8.1 Patient Perspective
The patient perspective captures the events and actions that the patient may take during this use case.
Code Description Comment
1.1.1.0 Event 1: Provide demographics and/orhealth identifier
Used to identify the patient in the ED Linksystem
1.1.1.1 Action: Patient, patient representativeor another trigger provides some formof demographics that may be used toidentify the patient.
If there are no demographicsavailable for the patient, then thesystem will not be available for use.
Key fields that are currently consideredare:
Last Name,
First Name,
Birthdate,
SSN,
Insurance identifier,
Personal Health Record identifier,
Address,
Drivers License,
Other voluntary identifier
1.1.a.2.0 Event 2: Patient agrees / consents to useof the system.
ED staff will check with patient for consentto use the system.
1.1.a.2.1 Action: Patient or patientrepresentative consents to ED staffsearch for clinical data
This event is not applicable should thepatient be unconscious
1.1.b.2.0 Event 3: Patient disagrees to or opts out
of data search.
Patient may opt out for this one occasion or
may opt-out for of entire ED link systemstate-wide.
1.1.b.2.a.1Action: Patient or patientrepresentative opts out of data searchfor this occasion.
One-time opt outs will not result in anypermanent system flags.
1.1.b.2.b.1 Action: Patient opts out of datasearch permanently.
System will flag patient demographicas having opted out during patientsearch for future searches
Permanent opt-out will flag patient asnot wanting to participate in any clinicalsearches state-wide.
1.1.4.0 Event 4: Patient requests clinical data
search history.
Patient may request for who has accessed
their clinical data1.1.4.1 Action: Patient submits formal
request for clinical search historyThe implementation of the actualclinical search history request needs tobe determined as well as the type ofreturn format.
8/8/2019 Use Case - CalRHIO ED Linking
17/23
CalRHIO ED Link Details of Use Case Scenarios and Perspectives
Use Case Specification
Page 13
8.2 ED Staff Perspective
(Note: ED Staff designated for each task will depend on the specific Hospitals workflow. Lesson learned by MA-
Share was that hospitals approach task assignments differently and need to find their own solutions forincorporating ED Linking into their workflow.)
Code Description Comment
1.a.2.1.0 Event 1: Request demographics Used to identify the patient in the ED Link
system
Scenario A covers all Staff interactions withthe goal of searching or viewing clinical
results.
1.a.2.1.1 Action: ED Staff (as designated by theHospital) 1) requests patientdemographics as available.
The actual information may be captured
at any point in the provider workflow. Forexample, a walk in patient may providethat information to the patient registration
desk or a patient being flown in viahelicopter may provide the information to
the staff on location.
Key fields that are currently consideredare:
Last Name,
First Name,
Birthdate,
SSN,Insurance identifier,
Personal Health Record identifier,
Address,
Drivers License,
Gender
1.a.2.2.0 Event 2: ED Staff secure logs into
system
1.a.2.2.a.1
Action: ED staff member enters
username and password to accessED Link system
1.a.2.2.b.1 Action: ED staff logs into an alternatesystem that simultaneously logs intoED Link
This alternate action captures theability for organizations to utilize singlesign-on applications.
1.a.2.2.c.1 Action: ED staff requests username /password reset
Staff member forgets theirauthentication and attempts to retrieveit
1.a.2.2.d.1 Action: ED staff requests account New staff member requests for anaccount to access ED Link system
1.a.2.3.0 Event 3: ED Staff is authorized toperform patient search
1.a.2.3.a.1 Action: ED staff member hasreceived patient consent andproceeds to patient search
1.a.2.3.b.1 Action: Patient is unavailable to giveconsent so multiple staff membersauthorize use of system
Patient is unavailable to provideconsent for search so more than 1 staffmember searches. The system willneed to be flexible enough to allow for
8/8/2019 Use Case - CalRHIO ED Linking
18/23
Page 14
Code Description Comment
alternate consent options that matchthose of each data users workflow.
1.a.2.3.2 ED Staff informs patient of use of EDLinking system
Informing patient of system use once apatient regains consciousness or isavailable to be informed.
1.a.2.4.0 Event 4: ED Staff searches for patient
1.a.2.4.a.1 Action: Staff member inputs patientdemographic information to system
1.a.2.4.b.1 Action: Staff member uses anothersystem that is linked into ED Link toperform automatic patient search
Allows for systems with both user andclinical single sign-on to automate apatient search from one system toanother. Would allow for a personalhealth record system, registrationsystem or insurance ID verification totransfer demographics into ED link forpatient search.
1.a.2.4.2 Action: Staff member initiates systemquery
1.a.2.4.3 Action: Staff member reviews returnresults
The system presents a set of returninformation by default regarding thepatient. The exact set of fields thatwill be stored and reviewed by theMPI have not been fully defined.Here is a suggested list:
Last update
Key patient demographics
Search history on patient
MPI should also rank the level of thematch between information providedto that of the system match.
ED staff member compares userprovider demographics with thosereturned by the system
1.a.2.4.a.4 Action: Staff member sorts data byfield
When the return is large, it may benecessary to sort the demographic
return based on certain fields1.a.2.4.b.4 Staff member drills down on patient
demographics
Available details should be:
Search history by ED link system
Full patient demographics
Staff member selects to view patientdemographic details captured at eachsystem
8/8/2019 Use Case - CalRHIO ED Linking
19/23
CalRHIO ED Link Details of Use Case Scenarios and Perspectives
Use Case Specification
Page 15
Code Description Comment
Picture
Biometrics
1.a.2.4.a.5 Action: Staff member selectsidentified patient for subsequentaction
1.a.2.4.b.5 Action: Staff member does not findany patient match
System flags lack of patient match
1.a.2.4.c.5 Action: Staff member selects morethan 1 correctly patient match
Flag to merge patient but searchshould continue with both selectedpatients
1.a.2.4.d.5 Action: Staff member flags incorrectlymatched patients listed as a singlepatient
Need for patient split
1.a.2.4.e.5 Action: Staff member flags incorrectinformation
Staff member notes that there isincorrect information and flags this.
1.a.2.4.6 Action: Staff member verifies patientselection
Selection of patient for clinical searchimplies a staff member has verified thecorrect information.
1.a.2.4.7 Action: Staff member adds identifiedpatient to patient list
This would allow the staff member toselect multiple patients for querying tooptimize workflow.
1.a.2.5.0 Event 5: ED Staff searches for clinical
information
Executable on single patient or patient list
1.a.2.5.a.1 Action: Staff member selects criteriafor search
Current criteria for search include:
Date range
Information Type
Data Source
1.a.2.5.b.1 Action: Staff member uses defaultcriteria for search
Default criteria would be modifiable bythe user in configuration
1.a.2.5.2 Action: Staff member executessearch
1.a.2.6.0 Event 6: ED Staff reviews clinical searchresults
Clinical search results and clinical resultsshould have persistence throughout the
patients stay at the ER.
1.a.2.6.1 Action: Staff member sorts clinicalinformation returned
System should provide informationbased on some sort of default criteria result date, data type, data source,result description
1.a.2.5.a.2 Action: Staff member validates andselects actual clinical result for review
8/8/2019 Use Case - CalRHIO ED Linking
20/23
Page 16
Code Description Comment
1.a.2.6.b.2 Action: Staff member forwardsclinical metadata to another staffmember
Allows the staff member to forward thereturn result metadata to another staffmember for review.
1.a.2.6.c.2 Action: Staff views clinical searchresults forwarded to them from
another user
Staff member views which results areavailable for retrieval from another staff
member.1.a.2.6.d.2 Action: Staff flags clinical result as
inappropriate or invalid.Upon review of the result, a staffmember may see data that should becompletely confidential such as specifictypes of lab results or note that thedata is erroneous.
1.a.2.6.e.2 Action: Staff reviews clinical resultsthat were retrieved as part of anautomated search from a patient list.
1.a.2.6.f.2 Action: Staff reviews data from a dataintermediary
See perspective 4 (data intermediary)
1.a.2.6.3 Action: User provides feedback onsearch results
Useful or not useful?
1.a.2.7.0 Event 7: ED Staff reviews clinical results
1.a.2.7.a.1 Action: Staff member queries forclinical results selected during search
This action is intended for the staffmember to be able to physically viewthe complete result returned by thesystem
1.a.2.7.b.1 Action: Staff member forwardsclinical result to another staff member
Difference here is a single result vs theentire clinical search metadata.
1.a.2.7.c.1 Action: Staff member views clinicalresults forwarded to them Staff member selects results to viewthat is forwarded to them.
1.a.2.7.d.1 Action: Staff assembles a longitudinalrecord for a set of clinical information
Staff member should be able tocompile relevant information over timefor a patient during system use and notneed to reselect and review informationeach time.
1.a.2.7.a.2 Action: Staff member prints clinicalresults
User can select which results they wantto print for review.
1.a.2.7.b.2 Action: Staff member saves clinicalresults for viewing later
User finds result that they want toreview later and saves it.
1.a.2.7.c.2 Action: Staff member is directedresults to contact another location forclinical information e.g. call centeror physician office
While clinical results may not be fullyretrievable, alternate sources of clinicalinformation may be available via phoneor other mediums.
1.a.2.7.3 Action: Staff member providesfeedback on clinical result
Useful or not useful?
Scenario B: User configures/administers their system experience
8/8/2019 Use Case - CalRHIO ED Linking
21/23
CalRHIO ED Link Details of Use Case Scenarios and Perspectives
Use Case Specification
Page 17
Code Description Comment
1.b.2.1.0 Event 1: User selects to configure their
preferences
1.b.2.1.a.1 Action 1: User configures theirpreferences
Items that can be configured are:
Default patient search criteria
Default patient result sorting
Patient list search frequency
Default Result metadata searchcriteria
Default result sorting
Patient filtering
Result filtering
Patient lists
1.b.2.1.b.1 Action 2: User changes password What type of authentication protocolsshould the system enforce?
8.3 System Administrator Perspective
Code Description Comment
1.3.1.0 Event 1: Log in
1.3.1.1 Action: User logs into system There will be several types ofadministrators. It may be necessary toseparate each type of administrator asit own type of perspective:
Registrar
System-wide
Data provider
Data user
1.3.2.0 Event 2: Administer users and user
groups
1.3.2.1 Review user requests for systemaccounts
1.3.2.a.2 Authorize requests for account toindividual user
1.3.2.b.2 Revoke account access for individualuser
1.3.3.0 Event 3: Administer institutions
8/8/2019 Use Case - CalRHIO ED Linking
22/23
Page 18
Code Description Comment
1.3.3.1 Review institution request for systemaccess
1.3.3.a.2 Authorize system access for institution
1.3.3.b.2 Revoke system access for institution
1.3.4.0 Event 4: Review logs There will be multiple types of logs and willneed to be defined during requirements
1.3.4.1 Review user access logs
These logs should contain audit trailinformation of what user executedwhat action at what time.
1.3.4.2 Review system logs
These logs should track the ED linksystems uptime, availability,interfaces and operational statuses
1.3.4.3 Review interface logs
These logs should track theavailability of interfaces to each of thedata provider systems
1.3.4.4 Review system value logs
These logs should capture thefeedback metrics designed intosystem such as usefulness of data,patient search return %, patientselection %s.
1.3.4.5 Review alert logs
These logs contain information wherethe system had detected an error andhas notified the appropriateadministrator. Alerts should include:
1) Interface down
2) Inappropriate access
3) Flags from users
8.4 Data Intermediary Perspective
Code Description Comment
1.4.1.0 Event 1: Receive Request
1.4.1.1 Action: Data intermediary receives aninformation request from an ED Link user
Requests can be in the form of a phonecall, fax, email or some other interfacedesignated by the data intermediary
8/8/2019 Use Case - CalRHIO ED Linking
23/23
CalRHIO ED Link Details of Use Case Scenarios and Perspectives
Use Case Specification
Code Description Comment
1.4.2.0 Event 2: Verify demographics and patient
identity
1.4.2.1 Action: Data intermediary collectsdemographic data
1.4.2.2 Action: Intermediary searches for
patient and presence of clinical data
1.4.3.0 Event 3: Verify request for clinical
information
1.4.3.1 Action: Data intermediaryauthenticates request
1.4.3.2 Action: Intermediary documentsrequest for information according toorganizations policies and procedures
1.4.4.0 Event 4: Intermediary performs clinicaldata query
1.4.4.1 Action: Intermediary searches forrequested clinical data query
This is parallel to 1.a.2.5.0 except theintermediary is performing the clinicalsearch
1.4.5.0 Event 5: Present / discuss clinical results
1.4.5.1 Action: Intermediary presents anddiscusses clinical results withrequesting clinician or organizationstaff member
System will need to determine how todocument / track the informationrequest and how the information via anintermediary can be noted in the EDLink system