Save Patient-level Clinical Data Workflow
Last updated
Last updated
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.
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
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
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
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
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
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
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.