Child pages
  • Save patient-level clinical data workflow
Skip to end of metadata
Go to start of metadata

Notice

The official version of the OHIE workflows can be found in the OpenHIE Architecture Specification.

Overview

Description: 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.

Sponsor:  Ryan Crichton (with the IL and SHR communities)

Status: In Progress

Referenced Standards and APIs:

  • 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 profile can be supported 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 my support the required MHD transactions.
    • (recommended) 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 (Query patient demographic records by demographics workflow - V1.0) and if they don't exist they should register them (Create patient demographic record workflow - V1.0).
  • 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 OpenHIM MUST contain author information. Either authorPerson or authorInstitution or both MUST be supplied. When supplying these, they MUST be supplied is full XCN/XON format and these MUST include an identifier component. This requirement is more restrictive that 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 it internal data model for use when generating on-demand documents. The section that are to be supported for discrete import those defined in the XDS-MS specification as well as (optionally) any other section that are 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.
  • FR - The source of truth for facility information. It is able to be queried for details about a particular facility by ID.
  • SHR - Stored patients clinical information. It is able to receive and store a patient clinical documents.

Validations

The IL should validate the clinical document before it can be saved to the SHR. There are some key validations that are always required and the transaction should fail if these are not met. These are base validation that must always take place:

  • The client (patient) is known and has an enterprise client id (ecid).
  • The facility is valid and operational and can be uniquely identified with an enterprise location id (elid).
  • The provider is valid and currently practising and can be uniquely identified with an enterprise provider id (epid).

There are also additional optional validations that may be beneficial for more advanced HIEs where the information is available. Implementation can also come up with other validation that make sense to their environment. These validations should not fail the transaction but rather be logged as warnings for a HIE admin to check up on:

  • The provider currently works at the facility
  • The provider currently provides the service requested at the facility
  • The service is allowed at the facility



Technical details


Ensure that the provider is valid and currently practicing, enrich message with EPID

RefInteractionEndpointDataTransaction Specification
1

Submit clinical encounter

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

CDA document conforming to a particular PCC profile

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.3

MHD: MHD profile supplement

2Resolve client identifierPIX Query (ITI-9)

HL7 QBP^Q23 message

IHE IT Infrastructure
  • Vol. 1 - Section 5
  • Vol. 2 - Sections 3.9
3Return person record

HL7 RSP^K23 message

"
4

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

none

5

Fetch provider details and perform validation

CSD Care Services Request - Find matching services

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"
7Fetch facility details and perform validationCSD Care Services Request - Find matching servicesfunction urn='urn:ihe:iti:csd:2014:stored-function:facility-search'IHE ITI CSD Supplement
8Return cached details and validation results

"
9

Read validation result and enrich document with EPID and ELID

none

10Save clinical encounter

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


CDA document conforming to a particular PCC profile 

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 

11Parse and store certain sections of clinical document discretelyInternal operation

12Register a CCD on-demand document for this patientXDS.b register document set (ITI-42 from the ITI framework) - SOAP web serviceGenerated 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

13Acknowledge encounter saved

ITI-41 SOAP response

and optionally

ITI-65 RESTful response

"
14Acknowledge encounter saved

ITI-41 SOAP response

and optionally

ITI-65 RESTful response


"

Pseudo code for validation logic

// This refers to metadata that comes from the XDS.b evelope
get SubmissionSet.patientId
create PIX query using id and assigningAuthority
do PIX query
if success and assigning authority isn't already ECID
	get ECID from PIX query response
	change SubmissionSet.patientId to ECID
if not success
	reject submission set
for each SubmissionSet.author element
	create CSD query using local IDs from author.authorInstitution and/or author.authorPerson
	do CSD query
	if success
		replace author.authorInstitution/author.authorPerson details with EPID or ELID details
	if not success
		reject submission set
for each CDA document in submission set
	get DocumentEntry.patientId
	create PIX query using id and assigningAuthority
	do PIX query
	if success and assigning authority isn't already ECID
		get ECID from PIX query response
		change DocumentEntry.patientId to ECID
		add ECID to CDA header recordTarget
	if not success
		reject submission set
	for each DocumentEntry.author element
		create CSD query using IDs local from author.authorInstitution and/or author.authorPerson
		do CSD query
		if success
			replace author.authorInstitution/author.authorPerson details with EPID or ELID details
			Add EPID to CDA header author elements
			Add ELID to CDA organisations that apppear
		if not success
			reject submission set
 
  • No labels