Use Case 1 - Receiving Clinical Data

System A: System containing the existing patient record e.g., a health system data warehouse

System B: External system containing additional clinical data e.g., an EHR somewhere in an external health system

Goals:

• Have the correct trigger fire in system B (push model) or system A (pull model)
• Successfully establish a connection between system A and system B
• Successfully transfer new external clinical data from system B to an existing patient record in system A
• Record this new clinical data in an existing patient record in system A in a way that preserves the intended meaning of the information being transferred
• Close the transaction

Primary actors:

• System B – connects with system A and transmits data to it (push model)
• System A – connects with system B and asks it to send a data update (pull model)

Secondary actors:

• Practitioners who use system B and enter or update clinical information about their patients
• Practitioners who use system A and view (or request, in the pull model) up to date clinical information about their patients

Preconditions/triggers

Existence of business and clinical data governance rules, including those for data exchange, and those rules programmed into both systems

Existence of an identity and access management (IAM) solution, which reconciles users across both systems to ensure that practitioners using system A have rights to access clinical data in system B

Push model:

• System B obtains new data
• System B senses one or more preconditions under which it will connect to system A and transmit new clinical data e.g., the patient record in system B is updated
• System A requests data from system B

Pull model:

• System A is programmed to periodically query system B for new data, or practitioner using system A manually requests data from system B

List or describe the basic flow of the use case from beginning to end, without error states.

Push model:

• System B obtains new data
• System B is triggered e.g., a patient record is updated
• System B requests to open a connection with system A
• System A accepts the connection request and a connection is opened
• System B packages the updated clinical information in a format that system A can understand
• System B sends the updated clinical data to system A
• System A validates the updated clinical data
• System A accepts the data transfer
• System A translates the data into its own format and updates the relevant patient record
• System A closes the connection
• Practitioner using system A views the patient record containing the updated clinical data

Looking for a printer-friendly copy of this basic workflow?  Download the workflow diagram here!

List or describe alternate flows, including those that involve error conditions.

Pull model:

• System B obtains new data
• System A is programmed to request an update from system B, or practitioner using system A manually requests an update
• System A requests to open a connection with system B, with the request containing a query
• System B accepts the connection request and a connection is opened
• System B packages the updated clinical information in a format that system A can understand
• System B sends the updated clinical data to system A
• System A accepts the data transfer
• System A translates the data into its own format and updates the relevant patient record
• System A closes the connection

These failure modes might occur:

• Trigger on system B doesn’t occur
• System A rejects system B’s request for a connection
• System B sends the data but system A can’t translate it into its own format
• New clinical data from system B fails validation by system A
• System A updates its patient record with the new data but the data definitions don’t match and the data are successfully updated but the meaning has been altered
• The connection hangs and doesn’t successfully close

Looking for a printer-friendly copy of this alternate workflow?  Download the workflow diagram here!

Are there post conditions that will be true about the system after the use case has been accomplished?

• System A and system B will have the new clinical data in sync with each other

Set of resources that must be made available and/or configured to execute the use case. Data, services, systems, etc.

•  System A
•  System B
•  Appropriate triggers programmed into system A
•  Connectivity between systems A and B
•  Appropriate data standards so that A can understand updates from B