Guidance

Conformance Language

This specification uses the conformance verbs SHALL, SHOULD, and MAY as defined in RFC 2119.

  • SHALL: Indicates requirements that must be met to be conformant with the specification.
  • SHOULD: Indicates requirements that are strongly recommended (and which could result in interoperability issues if not adhered to), but which do not, for this version of the specification, affect the determination of specification conformance.
  • MAY: Describes optional requirements that implementers are free to consider but where there is no recommendation for or against adoption.

An eOrder-Lab-related message (e.g. ServiceRequest bundle etc.) SHALL be well-formed and conform with this specification including conformance to business rules and data curation.

Participants in eOrder-Lab process SHALL use a PoS that has passed Alberta Health conformance, and the requesting provider SHALL be registered with Alberta Health to participate in this service.

Tested or Conditionally Tested Elements

This specification identifies the elements that will be tested during conformance validation to ensure vendors are able to support them. These elements are noted with "TESTED" or "CONDITIONALLY TESTED" element. To note, these tested elements may or may not have the MS (Must Support) indicator.

Unused if submitted

Elements that are submitted will NOT be tested and/or will NOT be used in the laboratory workflow process unless: a) it is explicitly identified as tested or conditionally tested element; or b) it is explicitly identified as mandatory (i.e. with minimum cardinality of 1 and/or noted as shall always be populated or valued in the Usage Notes section); or c) it is explicitly identified as MUST NOT be submitted in the Restrictions section.

Identifier Policy

The AB:eOrder-Lab uses URIs whenever Object Identifiers are required. URIs (Uniform Resource Identifiers) are globally unique identifiers for individual objects, as well as for value sets, code systems, profiles, namespaces, and more. URIs are the preferred object identifiers for FHIR objects, and are usually represented as URLs. For more information, or to obtain the proper URLs for use in this project, contact Alberta Health at hisca@gov.ab.ca.

The base namespace for global identifier such as the system identifier for Alberta Personal Health Number will be referred to as "[id-system-global-base]" throughout the specification.

The base namespace for a local identifier such as a ServiceRequest.identifier Assigning Authority will be referred to as "[id-system-local-base]" throughout the specification.

The base namespace for local code systems and value sets will be referred to as "[code-system-local-base]" and “[value-set-base]” throughout the specification.

Due to the evolving FHIR standard and its developing framework and governance, implementers should recognize that these identifiers may change if identifier registration becomes governed nationally or internationally. Implementers are recommended to implement URIs using configurable variables.

Identifier Variables

Variable Value
[id-system-global-base] "https://fhir.infoway-inforoute.ca/NamingSystem"
[id-system-local-base] "https://fhir.alberta.ca/NamingSystem"
[base-structure] "https://www.alberta.ca/fhir/StructureDefinition"
[code-system-local-base] "https://www.alberta.ca/fhir/CodeSystem"
[value-set-local-base] "https://www.alberta.ca/fhir/ValueSet"

Data Formatting

Letter Case

Information in eOrder-Lab message is stored as mixed case and information is preserved in the format provided by the source (e.g. ALL UPPER CASE, Mixed Case, lower case). eOrder-Lab message consumers MAY apply data formatting rules where there is a local requirement to standardize information to a consistent format.

Extended Character Set

Information within eOrder-Lab message SHALL be in UTF-8 to support extended characters beyond standard ASCII/ANSI character set including French characters.

Date/Time

In this specification, date/time SHALL be in UTC format. Date SHALL be "YYYY-MM-DD" or partial date formats “YYYY-MM” or “YYYY” . If this format is not provided, or an invalid date is provided in the defined format, the message will be rejected. Below are the formats supported:

  • 2015-01-07T13:28:17-05:00
  • 2015-01-07T18:28:17Z
  • 2015-01
  • 2015

Telecom

In this specification, the telecom SHALL be "+[country code]-[area code]-[exchange]-[subscriber number] ext."[extension]". Note that if country code is not used, the "+" prefix is skipped. Example: "+1-555-555-5555 ext. 123456"

URI/UUID

In this specificaiton, Uniform Resource Identifiers (URIs) leveraged are case sensitive. URIs MAY be absolute or relative, and MAY have an optional fragment identifier.

Universally Unique IDs (UUIDs) SHALL be in lower case format (e.g. “urn:uuid:53fefa32-fcbb-4ff8-8a92-55ee120877b7”). It is recommended that UUID version 4 be used. When URI/UUID is used in indentifier.value the identifier.system SHALL be "urn:ietf:rfc:3986".

Referencing FHIR Resources

The following approach is used in AB:eOrder-Lab for referencing resources in the Bundle:

  1. Referenced resource is included in the message as a Bundle.entry. When this approach is used, the following SHALL be expected:
    • The Bundle.entry.fullURL SHALL use urn:uuid
    • The UUID used in fullURL SHALL be used in Reference.reference to reference the corresponding FHIR resource in the Bundle
    • The UUID used in fullURL SHOULD also be assigned as the Resource.id

OR

  1. Use of Reference.identifier for identifier previously known to both systems. When this approach is used, the following SHALL be expected:
    • both .system and .value elements SHALL always be populated

Unless otherwise specified, the first approach is generally used in this specification.

Constructing Messages

Transmission of information between two systems using FHIR messaging involves the exchange of a message payload that consists of several parts:

  • A Message Bundle: A Bundle resource (.type = "message") is used to package together a collection of FHIR resource instances that will be sent from one system to another. The Bundle SHALL have an entry for each of the FHIR resources required to convey information about the business event, starting with the MessageHeader which SHALL always be first.

  • A Message Header: A MessageHeader resource with .eventCoding identifying the trigger event and other message related metadata including an .id, .source.endpoint, .destination.endpoint is used to convey the purpose of the message and to support message routing.

  • The Focus of the Message: MessageHeader.focus SHALL point to one or more ServiceRequest.

  • Other referenced entities and supporting information: When there is an update to other resources in the notify-update-service-request events, the MessageHeader.focus SHALL reference other resources to convey information about the Patient who is the subject of the referral request (ServiceRequest.subject), the PractitionerRole of the requester (ServiceRequest.requester, MessageHeader.author), supporting information (ServiceRequest.supportingInfo), etc.

  • Identifiers & Timestamps: Bundles and MessageHeaders SHALL have appropriate identifiers & timestamps as defined in the FHIR messaging requirements. Each Bundle.entry element SHALL have a unique .fullUrl and resource so systems that receive messages can resolve references within the Bundle.

The event (MessageHeader.event) and focus of the message (MessageHeader.focus) determines the content and structure of the Bundle of information (FHIR Resources) exchanged between participants.

Reducing Message Size

References between resources within a Bundle are managed using using the Reference element, specified below.

The structure supports references in either of two formats:

  • a reference to a FHIR resource including within a Bundle.entry, or
  • a shared business identifier for a resource known to both systems

AB:eOrder-Lab Messaging requires that:

  • when sending Send new service request [ eOrder-Labm-1 ] transaction, all resources referenced within the message SHALL be included in the message as Bundle entries and referenced from other resources using an absolute URL
  • when sending messages for other transactions:
    • any resource(s) referenced in MessageHeader.focus SHALL be included in the message as Bundle entries and referenced from other resources using an absolute URL
    • any resource referenced within the message that does not include a previously shared business identifier SHALL be included in the message as a Bundle entry and referenced from other resources using an absolute URL
    • other resources with a previously shared business identifier MAY be referenced using the reference.identifier element with both the .system and .value elements populated