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

General Guidance

This section outlines important definitions and interpretations and requirements common to all Lower Extremity Skin Wound Assessment actors used in this guide.

The conformance verbs used are defined in FHIR Conformance Rules.


Contents


FHIR Version Support

See Managing Multiple FHIR Versions - Mime Type Parameter section for details regarding requirements for client and server actors’ support of the fhirVersion=4.0 parameter.


Use Case Guidance

The Use Case definitions represent descrete portions of functionality within a given EHR actor system and/or Wound Assessment Registry (WAR) actor system complete workflow in capturing Wound Assessment and Treatment Template (WATT) data. This specificity provides the implementer with a more focused representation of the needed functionality within their given system.

Please refer to each Use Case definition page for specific guidance:

  1. Use Case - Originate and Retain (null), then Amend (populate with clinical content): FHIR Record Lifecycle Event (RLE) Originate and Retain, and Amend in relation to the initial creation of the Wound Assessment and Treatment Template (WATT) data as empty templates and then fully populated instances in an EHR actor system
    • This represents the first trial definition of incorporating the RLE Originate and Retain event and RLE Amend event into the the WATT data creation. This is the simplest way for the local system to demonstrate that the “populate with clinical content” step began from an “all null clinical content” state. This also establishes that the null-state template may pre-exist on the local system for any interval (seconds to years) prior to its “Amend” to add an instance of assessment.
    • For future work, we may identify the complexity of demonstrating that the null-state version could be empty also of patient demographics, thus the null state could be used as the initial state for all subsequent patient-specific captures as Amend events to the all-null original.
  2. Use Case - Receive and Retain: FHIR Record Lifecycle Event (RLE) Receive and Retain in relation to the sending of Wound Assessment and Treatment Template (WATT) data from an EHR actor system to a Wound Assessement Registry (WAR) actor system

  3. Use Case - Search: Query and retrieval of the Wound Assessment and Treatment Template (WATT) data from either an EHR actor system or Wound Assessement Registry (WAR) actor system


Record LifeCycle Events - Metadata Captured in FHIR Resources

The following table has been updated with corrected mappings to the FHIR R4 specification AuditEvent and Provenance resource types.

The following table shows the FHIR Resources and applicable Attributes captured - event, provenance and evidentiary metadata - at each occurrence of a Record Lifecycle Event. W5 metadata includes who, what, when, where, why attributes as shown below. W5 metadata elements are required.

Record Lifecycle Event Metadata FHIR R4 Resource Resource Element(s)
WHO
Organization Provenance signature : Signature 0..*
Provenance.agent : 1..* type: CodeableConcept 0..1 ⇐ ProvenanceParticipantType+ ⇒
role: CodeableConcept 0..* ⇐ SecurityRoleType+ ⇒
who: Reference (Organization) 1..1
onBehalfOf: Reference (Organization) 0..1
AuditEvent.agent : 1..* type: CodeableConcept 0..1 ⇐ ParticipationRoleType ⇒
role: CodeableConcept 0..* ⇐ SecurityRoleCode ⇒
who: Resource(Organization) 0..1
altId: string 0..1
Patient Provenance signature : Signature 0..*
Provenance.agent : 1..* type: CodeableConcept 0..1 ⇐ ProvenanceParticipantType+ ⇒
role: CodeableConcept 0..* ⇐ SecurityRoleType+ ⇒
who: Reference (Patient) 1..1
onBehalfOf: Reference (Patient) 0..1
AuditEvent.agent : 1..* type: CodeableConcept 0..1 ⇐ ParticipationRoleType ⇒
role: CodeableConcept 0..* ⇐ SecurityRoleCode ⇒
who: Resource(Patient) 0..1
altId: string 0..1

Action - Performer

Record - Author/User

Provenance signature : Signature 0..*
Provenance.agent : 1..* type: CodeableConcept 0..1 ⇐ ProvenanceParticipantType+ ⇒
role: CodeableConcept 0..* ⇐ SecurityRoleType+ ⇒
who: Reference (Practitioner|PractitionerRole|RelatedPerson|Patient|Device|Organization) 1..1
onBehalfOf: Reference (Practitioner|PractitionerRole|RelatedPerson|Patient|Device|Organization) 0..1
AuditEvent.agent : 1..* type: CodeableConcept 0..1 ⇐ ParticipationRoleType ⇒
role: CodeableConcept 0..* ⇐ SecurityRoleCode ⇒
who: Resource(PractitionerRole|Practitioner|Organization|Device|Patient|RelatedPerson) 0..1
altId: string 0..1
Record - System/Device Provenance signature : Signature 0..*
Provenance.agent : 1..* type: CodeableConcept 0..1 ⇐ ProvenanceParticipantType+ ⇒
role: CodeableConcept 0..* ⇐ SecurityRoleType+ ⇒
who: Reference (Device) 1..1
onBehalfOf: Reference (Device) 0..1
AuditEvent.agent : 1..* type: CodeableConcept 0..1 ⇐ ParticipationRoleType ⇒
role: CodeableConcept 0..* ⇐ SecurityRoleCode ⇒
who: Resource(Device) 0..1
altId: string 0..1
WHAT
Action - Taken Provenance activity: CodeableConcept 0..1 ⇐ ProvenanceActivityType ⇒
AuditEvent type: Coding 1..1 ⇐ AuditEventID+ ⇒
subtype: Coding 0..* ⇐ AuditEventSub-Type+ ⇒
action: code 0..1 ⇐ AuditEventAction ⇒
Record - Lifecyle Event AuditEvent.entity: 0..* what: Reference(Any) 0..1
type: Coding 0..1 ⇐ AuditEventEventType ⇒
role: Coding 0..1 ⇐ AuditEventEventRole ⇒
lifecycle: Coding 0..1 ⇐ ObjectLifecycleEvents ⇒
WHEN
Action - Date/Time Provenance occurredPeriod : Period 0..1
AuditEvent period : Period 0..1
Record - Date/Time Provenance recorded : instant 1..1
AuditEvent recorded : instant 1..1
WHERE
Action - Physical Location Provenance location : Reference(Location) 0..1
AuditEvent.source : 1..1 site: string 0..1
observer: Reference (Organization) 1..1
type: Coding 0..* ⇐ AuditEventSourceType ⇒
Record - Network Address Provenance location : Reference(Location) 0..1
AuditEvent.agent.network address : string 0..1
type : code 0..1 ⇐ AuditEventAgentNetworkType ⇒
WHY
Action - Reason, Rationale, Purpose Provenance reason : CodeableConcept 0..*
AuditEvent.agent : 1..* purposeOfUse : CodeableConcept 0..* ⇐ v3.PurposeOfUse ⇒
Record - Reason, Rationale, Purpose Provenance reason : CodeableConcept 0..*
policy : uri 0..*
AuditEvent purposeOfEvent : CodeableConcept 0..* ⇐ v3.PurposeOfUse ⇒
Additional Evidentiary Metadata, as applicable
Digital Signature(s) Provenance
one per signature
signature : Signature 0..*
Record Entry ID Provenance target : Reference(Any) 1..*
AuditEvent.entity : 0..* what : Reference(Any) 0..1
Record Entry Content ID(s):
data, docs, artifacts
Provenance target : Reference(Any) 1..*
Provenance.entity : 0..*
one per Record Entry
role : code 0..1 ⇐ ProvenanceEntityRole ⇒
what : Reference(Any) 1..1
agent : [see Provenance.agent]
AuditEvent.entity : 0..*
one per Content item
what : Reference(Any) 0..1
type : Coding 0..1 ⇐ AuditEventEventType ⇒
role : Coding 0..1 ⇐ AuditEventEventRole ⇒
Corresponding/linked Record Entry(ies) Provenance.entity : 0..*
one per linked Record Entry
role : code 1..1 ⇐ ProvenanceEntityRole ⇒
what : Reference(Any) 1..1
agent : [see Provenance.agent]
AuditEvent.entity : 0..*
one per linked Record Entry
what : Reference(Any) 0..1
type : Coding 0..1 ⇐ AuditEventEventType ⇒
role : Coding 0..1 ⇐ AuditEventEventRole ⇒
Amendment/Translation Sequence Provenance.entity : 0..*
one for each Record Entry in sequence
role : code 1..1 ⇐ ProvenanceEntityRole ⇒
what : Reference(Any) 1..1
agent : [see Provenance.agent]
AuditEvent.entity : 0..* lifecycle: Coding 0..1 ⇐ ObjectLifecycleEvents ⇒
Pointer to Pre Event Entry, if chained Provenance.entity : 0..*
one per previous instance
role : code 1..1 ⇐ ProvenanceEntityRole ⇒
what : Reference(Any) 1..1
agent : [see Provenance.agent]
AuditEvent.entity : 0..*
one per previous instance
what : Reference(Any) 0..1
type : Coding 0..1 ⇐ AuditEventEventType ⇒
role : Coding 0..1 ⇐ AuditEventEventRole ⇒
Source of Copied Content
(e.g. copy/paste template)
Provenance.entity : 0..*
one per source
role : code 1..1 ⇐ ProvenanceEntityRole ⇒
what : Reference(Any) 1..1
agent : [see Provenance.agent]
AuditEvent.source : 1..1
one per source
site: string 0..1
observer: Reference(PractitionerRole|Practitioner|Organization|Device|Patient|RelatedPerson) 1..1
type: Coding 0..* ⇐ AuditEventSourceType ⇒
AuditEvent.entity : 0..*
one per source
what : Reference(Any) 0..1
type : Coding 0..1 ⇐ AuditEventEventType ⇒
role : Coding 0..1 ⇐ AuditEventEventRole ⇒
Event is known Disclosure AuditEvent.entity : 0..* lifecycle: Coding 0..1 ⇐ ObjectLifecycleEvents ⇒
where lifecycle = "disclose"
Record Entry Permissions AuditEvent.agent : 1..*
one per agent
[for role-based permissions]
role: CodeableConcept 0..* ⇐ SecurityRoleCode ⇒
[for user-based permissions]
who: Resource(PractitionerRole|Practitioner|Organization|Device|Patient|RelatedPerson) 0..1
altId: string 0..1
AuditEvent.entity : 0..*
One per agent label
securityLabel : Coding 0..* ⇐ SecurityLabels ⇒
Event Transaction Entries Provenance.entity : 0..*
one per Record Entry
role : code 1..1 ⇐ ProvenanceEntityRole ⇒
what : Reference(Any) 1..1
agent : [see Provenance.agent]
AuditEvent.entity : 0..*
one per Record Entry
what : Reference(Any) 0..1
type : Coding 0..1 ⇐ AuditEventEventType ⇒
role : Coding 0..1 ⇐ AuditEventEventRole ⇒
Identifier/Version of Translation Tools Provenance.entity : 0..*
one per translation event
role : code 1..1 ⇐ ProvenanceEntityRole ⇒
what : Reference(Any) 1..1
agent : [see Provenance.agent]
AuditEvent.agent : 1..*
one per translation event
type: CodeableConcept 0..1 ⇐ ParticipationRoleType ⇒
role: CodeableConcept 0..* ⇐ SecurityRoleCode ⇒
who: Resource(Device) 0..1
altId: string 0..1


Record LifeCycle Events - Conformance Criteria

Processing of the FHIR Record Lifecycle Events (RLE) is defined as the capture of Conformance Criteria from the ISO/TS 21089 Record lifecycle events and action instances sections. The initial minimum required candidate Conformance Criteria are highlighted and shall be captured if the recording system supports this data. Additional criteria may be processed by a system but will not be required at this time.

Please see the Guidance - RLE Mapping page for specific guidance on mapping these criteria to FHIR RLE resource types AuditEvent and US Core Provenance (R4).

15.1.1 Initial action instance

Identity/Accountability Context

  • (cc1) SHALL Who - Action Subject - Individual Subject of Care ID
  • (cc2) SHALL Who - Accountable Health/care Party(ies), if applicable:
  • (cc3) SHALL - Organization ID/Descriptor
  • (cc4) SHALL - Business Unit ID/Descriptor
  • (cc5) SHALL - Individual Healthcare Professional, Caregiver ID
  • (cc6) SHOULD - Role - relative to organization, business unit
  • (cc7) SHOULD - Role - relative to Action Subject
  • (cc8) SHOULD - Role - relative to action instance: e.g. perform, assist, observe
  • (cc9) SHOULD - Scope of accountability
  • (cc10) SHALL What - Action taken, performed, rendered: Action Instance ID
  • (cc11) SHALL What - Action status: e.g. pending, in progress, complete, cancelled
  • (cc12) SHALL When - Action date/time, duration
  • (cc13) SHALL Where - Action physical location: e.g. point of service/care
  • (cc14) SHOULD Why - rationale or purpose for action taken, if applicable

Data Integrity ContextDIC

  • (dic1) If applicable - Purpose of data/record record capture
  • (dic2) If applicable - Purpose of data/record use: fitness, suitability, relevance
  • (dic3) If applicable - Evidence of data/record provenance
  • (dic4) If applicable - Measures and rules to ensure accuracy, continuity, consistency, completeness: of the health record and record entry

Clinical ContextCLC

  • (clc1) If applicable - Action - clinical purpose, rationale
  • (clc2) If applicable - Action - clinical facts, findings, observations
  • (clc3) If applicable - Action - clinical context, conditions
  • (clc4) If applicable - Measures and rules to ensure continuity, completeness: of the health/care Action
  • (clc5) If applicable - Measures and indicators for compliance (e.g. with standards of practice/care), quality, performance, outcomes

Administrative/Operational ContextAOC

  • (aoc1) If applicable - Allocations, deployments
  • (aoc2) If applicable - Assigned responsibility
  • (aoc3) If applicable - Resource utilization: staff, time, facilities, devices, supplies
  • (aoc4) If applicable - Costs
  • (aoc5) If applicable - Productivity, work load

15.1.2 Record lifecycle event - Originate/retain record entry instance(s)

Identity/Accountability Context

  • (cc1) SHALL Who - Record Entry Subject - Individual Subject of Care ID
  • (cc2) SHALL Who - Accountable Health/care Party(ies), if applicable:
  • (cc3) SHOULD - Digital Signature
  • (cc4) SHALL - Organization ID/Descriptor
  • (cc5) SHALL - Business Unit ID/Descriptor
  • (cc6) SHALL - Individual Healthcare Professional, Caregiver ID
  • (cc7) SHOULD - Role - relative to organization, business unit
  • (cc8) SHOULD - Role - relative to Record Entry Instance: e.g. author, scribe/proxy, verifier
  • (cc9) SHOULD - Role - relative to individual author of content
  • (cc10) SHOULD - Scope of accountability
  • (cc11) SHALL Who - Accountable Health/care Agent(s), if applicable:
  • (cc12) SHOULD - Digital Signature
  • (cc13) SHALL - Device, application or software ID
  • (cc14) SHOULD - Role - relative to Record Entry Instance: originator, source
  • (cc15) SHOULD - Scope of accountability
  • (cc16) SHALL What - Action Instance ID
  • (cc17) SHALL What - Record Entry Instance ID
  • (cc18) SHALL What - Record Entry Lifecycle Event: originate
  • (cc19) SHALL What - Record Entry instance status: e.g. new, updated, verified
  • (cc20) SHALL What - Record Entry completion status: e.g. documented, dictated (pre-transcription), in progress, incomplete, pre-authenticated, authenticated, legally authenticated (ref: HL7)
  • (cc21) SHALL When - Record Entry origination date/time
  • (cc22) SHALL Where - Record Entry physical location, point of origination
  • (cc23) SHALL Where - network address
  • (cc24) SHOULD Why - rationale or purpose for Record Entry origination

Data Integrity Context

Clinical Context

Administrative/Operational Context

15.2.1 Subsequent action instance

Identity/Accountability Context

  • (cc1) SHALL Who - Action Subject - Individual Subject of Care ID
  • (cc2) SHALL Who - Accountable Health/care Party(ies), if applicable:
  • (cc3) SHALL - Organization ID/Descriptor
  • (cc4) SHALL - Business Unit ID/Descriptor
  • (cc5) SHALL - Individual Healthcare Professional, Caregiver ID
  • (cc6) SHOULD - Role - relative to organization, business unit
  • (cc7) SHOULD - Role - relative to Action Subject
  • (cc8) SHOULD - Role - relative to action instance: e.g. perform, assist, observe
  • (cc9) SHOULD - Scope of accountability
  • (cc10) SHALL What - Action taken, performed, rendered: Action Instance ID
  • (cc11) SHALL What - Action status: e.g. pending, in progress, complete, cancelled
  • (cc12) SHALL When - Action date/time, duration
  • (cc13) SHALL Where - Action physical location: e.g. point of service/care
  • (cc14) SHOULD Why - rationale or purpose for action taken, if applicable

Data Integrity Context

Clinical Context

Administrative/Operational Context

15.2.2 Record lifecycle event - Amend (update) record entry instance(s)

Identity/Accountability Context

  • (cc1) SHALL Who - Record Entry Subject - Individual Subject of Care ID
  • (cc2) SHALL Who - Accountable Health/care Party(ies), if applicable:
  • (cc3) SHOULD - Digital Signature
  • (cc4) SHALL - Organization ID/Descriptor
  • (cc5) SHALL - Business Unit ID/Descriptor
  • (cc6) SHALL - Individual Healthcare Professional, Caregiver ID
  • (cc7) SHOULD - Role - relative to organization, business unit
  • (cc8) SHOULD - Role - relative to Record Entry Instance: e.g. author, scribe/proxy
  • (cc9) SHOULD - Role - relative to individual author of content
  • (cc10) SHOULD - Scope of accountability
  • (cc11) SHALL What - Action Instance ID
  • (cc12) SHALL What - Record Entry Instance ID
  • (cc13) SHALL What - Record Entry Lifecycle Event: update
  • (cc14) SHALL What - Record Entry instance status: e.g. updated
  • (cc15) SHALL What - Record Entry completion status
  • (cc16) SHALL When - Record Entry update date/time
  • (cc17) SHALL Where - Record Entry physical location, point of update
  • (cc18) SHALL Where - network address
  • (cc19) SHOULD Why - rationale or purpose for Record Entry update

Data Integrity Context

Clinical Context

Administrative/Operational Context

15.9 Record lifecycle event - Receive/retain record entry instance(s)

Identity/Accountability Context

  • (cc1) SHALL Who - Record Entry Subject - Individual Subject of Care ID
  • (cc2) SHALL Who - Source/Sender - Reporter, Discloser, Transmitter - Accountable Health/care Party(ies), if applicable:
  • (cc3) SHALL - Organization ID/Descriptor
  • (cc4) SHALL - Business Unit ID/Descriptor
  • (cc5) SHALL - Individual Healthcare Professional, Caregiver ID
  • (cc6) SHALL Who - Intended Recipient- Accountable Health/care Party(ies), if applicable:
  • (cc7) SHALL - Organization ID/Descriptor
  • (cc8) SHALL - Business Unit ID/Descriptor
  • (cc9) SHALL - Individual Healthcare Professional, Caregiver ID
  • (cc10) SHOULD - Role - relative to organization, business unit
  • (cc11) SHOULD - Role - relative to Record Entry Instance: e.g. recipient
  • (cc12) SHOULD - Scope of accountability
  • (cc13) SHALL Who - Accountable Health/care Agent(s), if applicable:
  • (cc14) SHOULD - Digital Signature
  • (cc15) SHALL - Device, application or software ID
  • (cc16) SHOULD - Role - relative to Record Entry Instance: e.g. receiver
  • (cc17) SHOULD - Scope of accountability
  • (cc18) SHALL What - Action Instance ID
  • (cc19) SHALL What - Record Entry Instance ID(s)
  • (cc20) SHALL What - Record Entry Lifecycle Event: receipt
  • (cc21) SHALL What - Record Entry instance status: e.g. received
  • (cc22) SHALL What - Record Entry completion status: e.g. completed
  • (cc23) SHALL When - Record Entry: e.g. date/time of receipt
  • (cc24) SHALL Where - Record Entry physical location: e.g. point of receipt
  • (cc25) SHALL Where - network address
  • (cc26) SHOULD Why - rationale or purpose for Record Entry receipt

Data Integrity Context

Clinical Context

Administrative/Operational Context

15.25 Record lifecycle event - Verify

Identity/Accountability Context

  • (cc1) SHALL Who - Record Entry Subject - Individual Subject of Care ID
  • (cc2) SHALL Who - Accountable Health/care Party(ies), if applicable:
  • (cc3) SHOULD - Digital Signature
  • (cc4) SHALL - Organization ID/Descriptor
  • (cc5) SHALL - Business Unit ID/Descriptor
  • (cc6) SHALL - Individual Healthcare Professional, Caregiver ID
  • (cc7) SHOULD - Role - relative to organization, business unit
  • (cc8) SHOULD - Role - relative to Record Entry Instance: e.g. verifier
  • (cc9) SHOULD - Scope of accountability
  • (cc10) SHALL Who - Accountable Health/care Agent(s), if applicable:
  • (cc11) SHOULD - Digital Signature
  • (cc12) SHALL - Device, application or software ID
  • (cc13) SHOULD - Role - relative to Record Entry Instance: e.g. verifier
  • (cc14) SHOULD - Scope of accountability
  • (cc15) SHALL What - Action Instance ID
  • (cc16) SHALL What - Record Entry Instance ID
  • (cc17) SHALL What - Record Entry Lifecycle Event: verify
  • (cc18) SHALL What - Record Entry instance status: e.g. verified
  • (cc19) SHALL What - Record Entry completion status: e.g. completed
  • (cc20) SHALL When - Record Entry verification date/time
  • (cc21) SHALL Where - Record Entry physical location, point of verification
  • (cc22) SHALL Where - network address
  • (cc23) SHOULD Why - rationale or purpose for Record Entry verification

Data Integrity Context

Clinical Context

Administrative/Operational Context