Retrieval of Real World Data for Clinical Research, published by HL7 International - Biomedical Research & Regulation Work Group. This is not an authorized publication; it is the continuous build for version 1.0.0). This version is based on the current content of https://github.com/HL7/vulcan-rwd/ and changes regularly. See the Directory of published versions

Technical Considerations

Representing Absent and Not Known Data

When a source system supports the extended IPS request, the returned FHIR document will have sections that are required to be returned. When those sections do not contain any data, there is some ambiguity as to whether there is no data because the patient does not have any instances of the data that is contained in that section, i.e. allergies or medications, or there is no data because the patient has not been explicitly asked. Thus there is a need to indicate an explicit assertion of whether data is known to be absent or not is made. The following sections are indicated as required and therefore must follow this rule:

• Medication Summary
• Problem List
• Diagnostic Results
• Allergies and Intolerances

The following sections are recommended and can either explicitly assert unknown or no known information as above or the section may just be omitted:

• Immunizations
• Medical Devices
• Vital Signs

NOTE: If a recommended or optional section is omitted, receivers SHALL not assume that no information is known but rather that it is unknown whether the patient has any information for that section.

Must Support Element Rules

For the purposes of this implementation guide, a data element marked as MustSupport SHALL be interepreted as follows:

• Implementers creating content, either as a response to cohort building or to finding data:
  • SHALL be capable of including any data element marked as MustSupport
• Implements receiveing content, either as a response to cohort building or to finding data:
  • SHALL be capable of processing instances containing MustSupport elements without generating an error or causing the application to fail
    • SHOULD be capable of displaying MustSupport elements for human use or processing them for other purposes
    • SHALL be able to process instances containing MustSupport elements that are asserting missing information

Missing Data

Optional MustSupport Data Elements

If an implementer creating content does not have data to be included for optional data elements that are marked as MustSupport, they are allowed to omit the data.

Required MustSupport Data Elements

If an implementer creating content does not have data to be included for required data elements that are marked as MustSupport, they must include the element but are allowed to indicate that data is missing. This can be done in one of two ways:

1. For non-coded data elements, use the Data Absent Reason extension.
2. For coded data elements with example, preferred, or extensible bindings:
   • use the text element if the source system has no coded data
   • use an appropriate exception code from the value set, if available
   • use a code from the Data Absent Reason code system
3. For coded data elements with required bindings, use the appropriate exception code from the value set

Cross-Version Analysis

This is an R4 IG. None of the features it uses are changed in R4B, so it can be used as is with R4B systems. Packages for both R4 (hl7.fhir.uv.vulcan-rwd.r4) and R4B (hl7.fhir.uv.vulcan-rwd.r4b) are available.

Intellectual Property Statements

This publication includes IP covered under the following statements.

• Copyright HL7. Licensed under creative commons public domain
  Show Usage
  • PH_VaccinesAdministeredCVX_CDC_NIP: ExampleNonBNT162b2Codes
• This material contains content from LOINC. LOINC is copyright © 1995-2020, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and is available at no cost under the license. LOINC® is a registered United States trademark of Regenstrief Institute, Inc.
  Show Usage
  • LOINC: ExampleCOVID19TestCodes, ExampleHbA1cTestCodes and Observation/RWDLabResult
• This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact http://www.snomed.org/snomed-ct/get-snomed-ct or info@snomed.org.
  Show Usage
  • SNOMED Clinical Terms® (SNOMED CT®): Condition/RWDProblem, ExampleDialysisProcedureCodes, ExampleRespiratoryConditionCodes and Procedure/RWDProcedure
• Using RxNorm codes of type SAB=RXNORM as this specification describes does not require a UMLS license. Access to the full set of RxNorm definitions, and/or additional use of other RxNorm structures and information requires a UMLS license. The use of RxNorm in this specification is pursuant to HL7's status as a licensee of the NLM UMLS. HL7's license does not convey the right to use RxNorm to any users of this specification; implementers must acquire a license to use RxNorm in their own right.
  Show Usage
  • RxNorm: ExampleClopidogrelCodes, ExamplePrasugrelCodes... Show 7 more, ExampleTicagrelorCodes, MedicationAdministration/RWDMedicationAdministration, MedicationDispense/RWDMedicationDispense, MedicationRequest/RWDMedicationRequest, MedicationStatement/RWDMedicationStatementFromAdministration, MedicationStatement/RWDMedicationStatementFromDispense and MedicationStatement/RWDMedicationStatementFromRequest

Global Profiles

There are no Global profiles defined

IG Dependencies

This IG Contains the following dependencies on other IGs.

Package hl7.fhir.uv.smart-app-launch#2.0.0

Package hl7.fhir.uv.ipa#1.0.0 This IG describes how an application acting on behalf of a patient can access information about the patient from an clinical records system using a FHIR based API. The clinical records system may be supporting a clinical care provider (e.g. a hospital, or a general practitioner), or a health data exchange, including a national health record system. (built Sun, Mar 26, 2023 20:50+0000+00:00)