use case - calrhio ed linking

8/8/2019 Use Case - CalRHIO ED Linking

1/23

CalRHIO ED Link Table of Contents

Use Case Specification

CalRHIO EDLinking Project Use Case


Version 2.1


2/23

Page ii

Prepared by Timothy KwanPrepared for CalRHIO ED LINKING PROJECTVersion Released 01/06/2006Document Status Draft


3/23

CalRHIO ED Link Table of Contents


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


4/23


5/23

CalRHIO ED Link Use Case Revision History table


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


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.


7/23

CalRHIO ED Link Scope of CalRHIO Emergency Department Linking Use Case


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/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


9/23

CalRHIO ED Link Stakeholders for Use Case


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.


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.


11/23

CalRHIO ED Link Obstacles to Implementing Use Case


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.


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.


13/23

CalRHIO ED Link Details of Use Case Scenarios and Perspectives


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


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


15/23



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

*

*

*

*

*

*


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.


17/23



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.)


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


18/23

Page 14


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


19/23



Page 15


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


20/23

Page 16


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


21/23



Page 17


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


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


22/23

Page 18


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


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


23/23




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

use case - calrhio ed linking

Documents