Save Patient-level Clinical Data Workflow

This transaction allows a point of service (PoS) system to save patient-level clinical data to the SHR. The transaction is verified and validated against the other registries before it is saved in the SHR. The following sequence diagram shows the steps involved.

Workflow Maturity

Mature

  • One or more OpenHIE implementations of this workflow exist in one or more countries

  • Workflow is defined and ARB approved

  • Workflow is supported by mature standards*

Standards

  • XDS.b with the on-demand document (ODD) option - provide and register document - ITI-41

  • CDA documents profiled by IHE PCC as the clinical data

  • CSD - Find matching services - ITI-73

  • Optionally, the MHD (FHIR-based) profile may be used instead of the XDS.b profile to enable PoC systems to save clinical content using a simpler and more modern approach. This option may be supported in two ways:

    • The SHR itself may support the required MHD transactions.

    • The IL can provide an adapter to convert incoming MHD transactions to XDS.b transactions for the SHR to process as normal.

Assumptions and Prerequisites

  • The PoS system has a curated list of Providers that interact with that system, with knowledge of at least the providers that are relevant to that PoS system.

  • The PoS system has a curated list of Facilities that this system serves, with knowledge of at least one member (itself).

  • The PoS system must ensure the patient they are submitting clinical information about already exists. It can do this by querying for the patient and if they don't exist they should register them (Create patient demographic record workflow).

  • The PoS system is a trusted application known by the HIE and it is registered with the interoperability layer to be able to send and receive data securely (Common message security workflow).

  • The conditions for the validation of facility, provider and services are configurable to enable them to be more or less strict.

  • All XDS submissions to the IL MUST contain author information. Either authorPerson or authorInstitution or both MUST be supplied. When supplying these, they MUST be supplied in full XCN/XON format and these MUST include an identifier component. This requirement is more restrictive than the XDS.b profile, however it is required in order to perform validation of the health worker and facility submitting this information.

  • The SHR MUST be able to store certain sections of a CDA document as discrete data in its internal data model for use when generating on-demand documents. The sections that are to be supported for discrete import are those defined in the XDS-MS specification, as well as (optionally) any other section that is deemed useful within the environment in which the SHR is deployed.

Actors

  • PoS - The point of service system that captures a patient clinical encounter, it is responsible for sending this encounter on to the HIE.

  • IL - Mediates the transactions between the PoS system and the infrastructure services to facilitate easier interoperability.

  • CR - The source of truth for patient demographic and identifier detail. It is able to be queried using an identifier to find the enterprise identifier for a particular person.

  • IL (Interlinked Registry) - The source of truth for facility information. It is able to be queried for details about a particular facility by ID. In implementations, the FR and/or the HWR can be used if the IL is not required for linking health workers and facilities.

  • SHR - Stored patients clinical information. It is able to receive and store a patient clinical documents.

Interaction Description

The following is a description of the interaction steps.

#

Interaction

Data

Transaction Options

1

Submit clinical encounter

CDA document conforming to a particular PCC profile

XDS.b provide and register document (ITI-41 from the ITI framework) - SOAP web service

and optionally

MHD provide document bundle (ITI-65) - RESTful FHIR interface

XDS: IHE IT Infrastructure

Vol. 1 - Section 10, Appendix E, J, K

Vol. 2a - Sections 3.18

Vol. 2b - Sections 3.41, 3.42, 3.43

Vol. 2x - Appendix A, B, K, L, M, N, V, W

Vol. 3 - Section 4.1, 4.2, 4.3MHD: MHD profile supplement

2

Resolve client identifier

HL7 QBP^Q23 message

IHE IT Infrastructure

PIX Query (ITI-9)

Vol. 1 - Section 5

Vol. 2 - Sections 3.9

3

Return person record

HL7 RSP^K23 message

4

Extract ECID and enrich message with ECID if patient exists, else error

5

Fetch provider details and perform validation

Function urn='urn:ihe:iti:csd:2014:stored-function:provider-search'

6

Return cached details and validation results

Return validation results

7

Fetch facility details and perform validation

Function urn='urn:ihe:iti:csd:2014:stored-function:facility-search'

8

Return cached details and validation results

9

Read validation result and enrich document with EPID and ELID

10

Save clinical encounter

CDA document conforming to a particular PCC profile

XDS.b provide and register document (ITI-41 from the ITI framework) - SOAP web service

and optionally

MHD provide document bundle (ITI-65) - RESTful FHIR interface

IHE IT Infrastructure

Vol. 1 - Section 10, Appendix E, J, K

Vol. 2a - Sections 3.18

Vol. 2b - Sections 3.41, 3.42, 3.43

Vol. 2x - Appendix A, B, K, L, M, N, V, W

Vol. 3 - Section 4.1, 4.2, 4.3 MHD: MHD profile supplement

11

Parse and store certain sections of clinical document discretely

12

Register a CCD on-demand document for this patient

Generated metadata

IHE IT Infrastructure

Vol. 1 - Section 10, Appendix E, J, K

Vol. 2a - Sections 3.18

Vol. 2b - Sections 3.41, 3.42, 3.43

Vol. 2x - Appendix A, B, K, L, M, N, V, W

Vol. 3 - Section 4.1, 4.2, 4.3

XDS-MS specification

13

Acknowledge encounter saved

ITI-41 SOAP response

and optionally

ITI-65 RESTful response

14

Acknowledge encounter saved

ITI-41 SOAP response

and optionally

ITI-65 RESTful response

Last updated