General Lab DiagnosticReport (Patient) Profile

FHIR Requirements for general lab DiagnosticReport information displayed to a citizen/patient.

Constraints on the DiagnosticReport resource to reflect source data mappings for the ACCESS Health project. Focus of this profile is on display of general Diagnostic Report result information to citizen/patient viewers.

This profile was generated from HL7 DiagnosticReport StructureDefinition

Sources-To-Date

• Nova Scotia HL7v2 LIS Specification & Test Messages

• Prince Edward Island HL7v2 LIS Specification

• Ontario Laboratory Information System (OLIS) HL7v2 LIS Specification

Constraints

As part of the scope of the discovery phase of this project, mappings, profiles, and implementation guides were expected to be agnostic with regard to implementation decisions or architectural paradigm.

• It could not be assumed that future implementations will exchange information via a RESTful API.
• Design for how resources could be identified and verified/matched across organizations and jurisdictions fell outside of scope for this phase. Mappings had to be made under the most basic assumption that resources could be referenced on a local server.

Availability of Atlantic LIS specifications and test messages were also a limitation on mapping and profiling efforts. Currently, the general lab profiles were completed using documentation from Nova Scotia, Prince Edward Island, and Ontario Lab Information Systems (LIS). Additional evaluation and iteration of these profiles, as additional jurisdictional specifications are made available, is paramount to ensure the final profile reflects the current state of Atlantic systems.

Alignment and compatibility with other prominent profiles in similar functional areas were sought (e.g. OLIS, US Core/CA Core), in part to validate the ACCESS Atlantic work, and in part to ensure that decisions taken in developing the ACCESS profiles were, at a minimum, not mutually exclusive with widely used profiles.

ACCESS General Lab DiagnosticReport (Patient) Profile

ACCESS DiagnosticReport General Lab (Patient) Profile

DiagnosticReport

DiagnosticReport.identifier

DiagnosticReport.status

DiagnosticReport.category

DiagnosticReport.category.lab

{
  "coding": [
    {
      "system": "http://terminology.hl7.org/CodeSystem/v2-0074",
      "code": "LAB"
    }
  ]
}

DiagnosticReport.code

DiagnosticReport.subject

DiagnosticReport.effectiveDateTime

DiagnosticReport.issued

DiagnosticReport.performer

DiagnosticReport.performer.practitioner

DiagnosticReport.performer.organization

DiagnosticReport.specimen

DiagnosticReport.result

DiagnosticReport.conclusion

DiagnosticReport.conclusionCode

Example Message: DiagnosticReport (Patient) Example

Key differences from DiagnosticReport Base Resource:

• Removed the following elements from the profile due to lack of available semantically equivalent ORU fields across examined sites:

  • basedOn, encounter, resultsInterpreter, imagingStudy, media, presentedForm

• Flagged the following elements as "Must Support":

  • status, category, code, subject, effectiveDateTime, issued, performer, result

• Changed the cardinality of the following elements:

  • category, subject

These profiles sought to target alignment with the US Core DiagnosticReport Profile and OLIS DiagnosticReport Profile in order to avoid proliferation of competing standards.

Key differences from US Core DiagnosticReport R4 Profile:

Much like Observation, the ACCESS DiagnosticReport profile has intentional alignment with the US Core DiagnosticReport profile. Differences between the two profiles are largely due to the citizen access focus of the ACCESS profile as well as from natural constraints and variances from the anticipated data sources (HL7 v2 ORU RO1 messages).

Differences between the two profiles are as follows:

Must Support Differences

• Media and presentedForm elements are flagged as Must Support elements in the US Core profile, but are not considered Must Support in the ACCESS profile.
  • Media: This decision was due to the difficulty associated with correctly identifying and parsing the correct media from an HL7 v2 ORU RO1 attachment when there is no clear method of differentiating between what the base-64 encoded images are intended to represent when they are included in the OBX-5 field of a message.
  • presentedForm: While providing the full ORU message in the presentedForm element helps clinicians ensure clinical fidelity, this profile is solely focused on providing simple meaningful lab information to patients in a user-friendly manner that can be displayed by third-party applications. Very few patients are expected to know how to read the ORU messages presented and the variances between LIS formatting of messages will likely cause further confusion.

Cardinality Constraint Differences

• Category, effective, and issued have different cardinalities between the two profiles which can be categorized in the following ways:
  • Elements with upper constraint added in US Core profile: category
  • Elements with lower constraint added in US Core profile: effective, issued

Data Type Constraint Differences

• ACCESS DiagnosticReport profile limited the effective data type to only include effectiveDateTime. While the base resource supports multiple data types: DateTime, Timing, Period, Instant, the lab sources are expected to be using HL7 v2 time stamp data type which more closely aligns with dateTime. US Core allows dateTime and Period data types.
• The ACCESS profile also binds to the CA Core profiles whenever possible (CA Core Patient, organization) and the ACCESS general lab observation profile.

Binding Differences

• Setting a fixed system or value for category was avoided due to the expectation that other profiling efforts will result in the use of two (or more) category systems and values. US Core fixes its system to “http://terminology.hl7.org/CodeSystem/v2-0074” and fixes its value to “LAB”. ACCESS provides an example binding from the same code system but allows for additional diagnostic service categories to be present in the value set since that additional detail may be present in OBR-24 of the source HL7 v2 messages.
• For diagnosticReportCode, US Core creates an extensible binding to its own value set: US Core Diagnostic Report Laboratory Codes which pull from the LOINC code system. Because the LIS in the analysis primarily use their own unique nomenclatures (with some jurisdictions like PEI and OLIS supporting LOINC codes or nomenclatures that map to LOINC codes) the ACCESS profile identified the LOINC codes as a preferred binding when available but did not require its use through a “required” or “extensible” conformance binding.
• The ACCESS DiagnosticReport profile supports the optional elements of conclusionCode and provides an example binding to SNOMED CT clinical findings.

Key differences from the OLIS DiagnosticReport STU3 Profile:

Much like Observation, the ACCESS profile and OLIS DiagnosticReport profiles are similar; Observation ACCESS profile requirements are an approximate subset of OLIS requirements. It's important to note that OLIS profiles are built on FHIR STU3, while ACCESS profiles are built on FHIR R4, so a one-to-one comparison is not possible. Furthermore, the ACCESS profiles are tailored to citizen access, whereas OLIS is intended to support clinician use. Differences between the two profiles are as follows:

Must Support Differences

• category and effectiveDateTime are flagged as Must Support for the ACCESS profile and US Core, but not OLIS
• id, contained, identifier, specimen, and codedDiagnosis are flagged as Must Support for OLIS but not the ACCESS profile.

Cardinality Constraint Differences

• identifier, category, performer, and specimen have different cardinalities between the two profiles which can be categorized in the following ways:
  • Elements with upper constraint added in OLIS profile: category, performer, and specimen
  • Elements with lower constraint added in OLIS profile:
  • Elements with both upper and lower constraints added in OLIS profile: identifier
  • Elements with a lower constraint added in the ACCESS profile: category

Data Type Constraint Differences

• The OLIS profile constrains subject to the OLIS Patient Profile, while the ACCESS profile references the CA Core Patient Profile in anticipation of its release
• The ACCESS profile similarly limits performer data types to Practitioner and Organization references, however, each references its respective profiles (CA Core & OLIS)
• In addition to referencing its own Observation profile, OLIS also references a secondary OLIS Observation profile focused on Microbiology. The ACCESS profile in comparison only focuses on general lab results & diagnostic reports.

Binding Differences

• The ACCESS profile binds to the R4 Diagnostic Report Status value set whereas the OLIS profile binds to the STU3 Diagnostic Report Status value set. Similar to the observation profile, the value sets are different, but the coded values within both value sets are the same so no terminology considerations are anticipated.