Lower Extremity Skin Wound Assessment Implementation Guide STU1 CI Build

Lower Extremity Skin Wound Assessment - IG - Local Development build (v0.1.0). See the Directory of published versions

Use Case - Receive and Retain

Introduction

Wound Assessment and Treatment Template (WATT) Scenario - Use Case - Originate and Retain.

Demonstrate how an EHR actor incorporates the FHIR Record Lifecycle Event (RLE) Implementation Guide (IG) processing of the Originate/Retain and Amend Record Content events when receiving Wound Assessement and Treatment Template (WATT) data.

The focus of this use case is the verification and validation of recording and storage of the FHIR Record Lifecycle Event data represented by the FHIR Resource Types of AuditEvent and US Core Provenance (R4).

 

Actors

The following actors, FHIR Interactions and RLE events are part of this Use Case:

  • Wound Assessment Registry (and Repository)
    • FHIR Interactions from other EHR actors:
      • create, read, update, search and transaction of WATT data
  • EHR - Example: Primary Care Physician (PCP)
    • FHIR Interactions to Registry:
      • create, read, update, search and transaction of WATT data
    • FHIR RLE Events:
      • Receive/Retain Record Entry
      • Evidence of Receive/Retain Record Entry

 

Summary Workflow

This use case defines the FHIR Record Lifecycle Event processes performed by an EHR actor when sending the Wound Assessment Template data for a given Patient encounter to the Wound Assessment Registry (WAR) actor. The workflow is outlined in the following figure.

Use Case Receive and Retain
UseCase_Receive.jpg

 

Expected Behavior

The following is the expected behavior of the Wound Assessment Registry (WAR) actor system when implementing the FHIR RLE Events when receiving Wound Assessment Template data from an EHR actor:

1. Receive/Retain Record Entry The creation of the the Wound Assessment Template data as empty FHIR resource instances of

2. Evidence of Receive/Retain Record Entry The creation of the corresponding FHIR RLE AuditEvent and US Core Provenance (R4) resources related to #1.

WATT Data Storage

The expectation for the Wound Assessment Registry (WAR) actor system is that all of the Wound Assessment and Treatment Template (WATT) data will be processeded as a single transaction. This will result in the Wound Assessment Registry (WAR) actor’s (FHIR) data repository storing a local copy of the WATT data FHIR resources:

  • #1 - fully populated created version 1 instances

RLE Data Storage

The expectation here is that the generated RLE data FHIR instances will be:

 

Data Examples

Example FHIR resource instances illustrating the expected contents of the WATT and RLE data (FHIR resource instances) the Wound Assessment Registry (WAR) actor system will store after each of the FHIR RLE Events:

1. Receive/Retain Record Entry

2. Evidence of Receive/Retain Record Entry

 

Validation Test Details

Validation of Wound Assessment and Treatment Template (WATT) data

See Use Case - Search: Query and retrieval of the Wound Assessment and Treatment Template (WATT) data

Validation for Evidence of FHIR Record Lifecycle Event data

The Wound Assessment Registry (WAR) actor system will provide standard FHIR GET search operation support for query and retrieval of the AuditEvent and US Core Provenance (R4) resource instances received and created from the RLE Evidence event #2.

AuditEvent

The search criteria will consist at a minimum of the AuditEvent patient parameter equal to the known Patient id and the date parameter set to a targeted datetime range. Additional optional search parameters could include the entity-type parameter equal to ‘Condition’ or ‘Observation’, and the type parameter equal to ‘C’ for Create or ‘U’ for Update.

Provenance

The search criteria will consist at a minimum of the Provenance patient parameter equal to the known Patient id and the recorded parameter set to a targeted datetime range. Additional optional search parameters could include the target parameter equal to the known ‘Condition’ or ‘Observation’ resource references.

Test Definition

Actors: Origin - External client system, or Test Platform; Destination - Wound Assessment Registry (WAR) actor (Note: Origin and Destination cannot be the same actor)

Test Data: See Data Examples above

Setup: If the destination system is pre-populated prior to the test execution with known test data, the setup step can be skipped. Otherwise, for automated testing, the testing platform can send the known test data to the destination system.

Action 1a (Test Step): Origin system executes a FHIR Search Interaction for the RLE AuditEvent or US Core Provenance (R4) resources matching a specific Patient id and date to the destination system

GET [base]/AuditEvent?patient=[Patient id]&date=[YYYY-MM-DD]

Accept: application/fhir+xml or application/fhir+json

GET [base]/Provenance?patient=[Patient id]&recorded=[YYYY-MM-DD]

Accept: application/fhir+xml or application/fhir+json

Action 1b (Test Step): Origin system executes a FHIR Search Interaction for the RLE AuditEvent or US Core Provenance (R4) resources matching a specific Patient id, date and WATT resource type to the destination system

GET [base]/AuditEvent?patient=[Patient id]&date=[YYYY-MM-DD]&entity-type=Condition

Accept: application/fhir+xml or application/fhir+json

GET [base]/Provenance?patient=[Patient id]&recorded=[YYYY-MM-DD]&target=Observation

Accept: application/fhir+xml or application/fhir+json

Request Success Criteria 1 (Asserts):

  • HTTP Accept header contains valid FHIR mime-type
  • GET URL - verify expected search parameters in path
  • HTTP response code is 200 (OK)
  • HTTP response body is a FHIR Bundle Resource Type
  • Validate the returned Bundle.entry.resource contents include the expected matching AuditEvent and/or Provenance instances
  • Validate returned Bundle against base FHIR specification Bundle profile (FHIR Validation Engine will perform individual validation of each Bundle.entry.resource using their declared profile conformance)

 

Summary of FHIR Artifacts

FHIR Resource Overview

Resources supported for this use case:

Resource Type Profile Name Link to R4 Profile
Patient US Core Patient Profile US Core Patient (R4)
Practitioner US Core Practitioner Profile US Core Practitioner (R4)
Encounter US Core Encounter Profile US Core Encounter (R4)
Condition WoundAssert Condition Profile WoundAssert Condition (R4)
Observation WoundRelatedObservationsPanel Observation Profile WoundRelatedObservationsPanel Observation (R4)
AuditEvent FHIR AuditEvent Profile FHIR AuditEvent (R4)
Provenance US Core Provenance Profile US Core Provenance (R4)