Mobile Cross-Enterprise Document Data Element Extraction (mXDE)
1.3.1-current - ci-build International flag

Mobile Cross-Enterprise Document Data Element Extraction (mXDE), published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 1.3.1-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.mXDE/ and changes regularly. See the Directory of published versions

Artifacts Summary

Contents:

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

Behavior: Capability Statements

The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.

mXDE Clinical Data Consumer Actor

CapabilityStatement for mXDE Clinical Data Consumer Actor

Uses available Provenance to retrieve source documents.
mXDE Data Element Extractor Actor

CapabilityStatement for mXDE Data Element Extractor Actor

Uses the provided links from data elements to source documents to obtain broader clinical context in which the data elements were recorded.

Structures: Resource Profiles

These define constraints on FHIR resources for systems conforming to this implementation guide.

mXDE Provenance

Provenance profile for use in mXDE when the data-elements (Resources pointed to by target) come from an XDS or MHD document. There will be one Provenance record for each document that has been decomposed by mXDE.

  • policy will be urn:ihe:iti:mxde:2023:document-provenance-policy to indicate mXDE produced provenance
  • target will point at ALL of the data found within the document
    • some target resources will be only found in the document
    • some target resources may have been found in other documents
  • activity will be Derivation to indicate the target resources were derived from documents
  • recorded will indicate when the document was decomposed into these target resources
  • agent will identify the software/service that implements the decomposition of the documents
    • this agent would be type assembler as it has assembled the FHIR Resources
    • this agent should describe the version of the software so as to understand data translation rules used
    • this agent may be a Resource or may be Contained depending on environment policy
  • other agent elements may be included
  • entity will point at the DocumentReference for the document from which the target data came

Example: Example Instances

These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.

Dummy Authoring Practitioner example

Dummy Practitioner example for completeness sake. No actual use of this resource other than an example target
Example Device example

Example Device example for completeness sake. No actual use of this resource other than an example target
Example DocumentReference example

Example DocumentReference example for completeness sake. No actual use of this resource other than an example target
Example Encounter

holding typical values
Example Patient

The patient from which all the example relate
Example of a blood pressure R4 observation, minimal

holding typical values
Example of a bodyWeight R4 observation

Sample for demonstration purposes of a common weight Observation

  • marked as compliant with IHE.ToDo.bodyWeight profile
  • marked as test data
  • status of final
  • category vital-signs
  • code of loinc body weight
  • subject of the example patient
  • effective time of December 25th, 2004
  • weight 185 pounds
  • note: a bit heavy
Example of a search set bundle

Search on Weight Observations with reverse include requesting Provenance. This is returning two weight Observations and one Provenance.
Example of an valid FHIR bodyWeight R4 observation, but not compliant with the profile

Sample for demonstration purposes of a common weight Observation.

  • Given that this is not compliant, it is thus not declaring that it is compliant, it is just an Observation
  • marked as test data
  • status of final
  • category of vital-signs
  • code of loinc 29463-7 and 3141-9
  • also code of snomed 27113001
  • subject of the example patient
  • linked to an encounter
  • effectiveDateTime = March 28, 2016
  • weight 280 lbs
  • note: a bit heavy, about 280 lbs
Provenance of extracted resources

Sample of a Provenance of a set of target FHIR Resource elements derived from a DocumentReference