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 PIX Query - ITI-9 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'	IHE ITI CSD Supplement
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'	IHE ITI CSD Supplement
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

References:

• WHO DDCC Workflows
• Digitize Vaccine Event