Referrals Re-opened via FHIR API Will Now Appear in the 'Pending Booking' Folder

Referrals in a terminal state (i.e. Cancelled, Completed, Declined) can be re-opened by changing their status back to 'active' state (i.e. Accepted) via the HL7 FHIR eReferral API.

Currently, this causes the referral to move to the 'Pending Booking' in the referral sender's Ocean Site. However, within the referral receiver's Ocean Site, the referral remains in the terminal state folder (i.e., Cancelled, Completed, Declined).
As of the Ocean Server Upgrade scheduled for release on the evening of July 25th, 2024, this behaviour will be changed such that the referral will also move into the 'Pending Booking' folder within the referral receiver's Ocean Site.
Please share this update with FHIR-integrated Receiver site users so that they are aware of the new location of re-opened referrals.


Issue Impacting FHIR integrations - March 27, 2024 [RESOLVED]

As communicated previously, a new feature was released on March 21, 2024 to include both the referral submitter and authorizer information in the FHIR payload.  A bug has been identified with this feature that prevents the FHIR payload from being constructed when the submitter does not have a professional ID value in their user account. 

A fix is scheduled for release in the evening of March 27th.It is recommended that referral receivers with a FHIR integration monitor the Ocean Portal's eReferral & eConsult View for any new or updated referrals that were received after March 21st in case they have not been received within the point-of-service system

March 27, 2024, 4:45 PM EST:  Upon release of the fix, Ocean will resend all of the delayed referral events that have queued up since March 21st.   It may take several hours until the full set of delayed payloads are resent.  

March 28, 2024, 12:30 PM EST: The fix released last night has enabled Ocean to successfully resend all of the eReferral events that were impacted since March 21st.   There should be no loss of data for the receiving point-of-service systems.   Please notify us at support@oceanmd.com if you have any additional questions or concerns.

 


Upcoming Enhancements: Patient Email Notifications and Communicating the Request Submitter and Authorizer

 

OceanMD will be introducing two integration-related enhancements in the March 21st Ocean release:

1. Patient email notifications

Currently, FHIR-integrated sites must include the patient's email address in the Patient resource of the message-event payload to signal to Ocean that a patient email notification should be sent.   We have received input from several integrators that they would prefer to use the email address that was submitted by the requestor (because they have received consent from the patient for it to be used for Ocean communications) and that Ocean follow its internal model for patient notifications.  

The March 21st release will include a configuration option to support this and it will be the default for all net-new sites that add an integration.  For backwards compatibility, all existing integrated sites will continue to follow the current model (of sending the email address in the FHIR payload) until the new configuration option has been modified. 

 

2. Inclusion of both request submitter and authorizer information in the FHIR payload

Ocean currently only sends the referrer information of the most senior clinician involved in the request in the FHIR payload.  However, many Ocean referral and consults involve another actor that submits the request on behalf of the clinician.  In this case, there is a request authorizer and a request submitter.  Examples can include a medical secretary, physician assistant and resident that is submitting the referral under the supervision of a staff physician and an independently-practicing nurse practitioner sending a MRI order with the authorization of an physician.  The FHIR iGuide business rules section states " the referral authorizer is captured by ServiceRequest.requester, and may also be mapped onto MessageHeader.author when submitting the referral. The referral submitter is captured by MessageHeader.sender."   Below are examples of how the submitter and authorizer information will be populated in the payload:

 

MessageHeader.sender

ServiceRequest.requester

MessageHeader.author

Physician Assistant PA sending referral under physician Dr. D PA Dr. D Dr. D
Resident R sending referral under physician Dr. D R Dr. D Dr. D
Nurse Practitioner NP sending referral (ordering an MRI) under authorizing physician Dr. Digley NP Dr. D Dr. D
Medical Secretary MOA sending referral as a delegate under Dr. D MOA Dr. D Dr. D

 

Upon the March 21st release, where relevant, the request submitter's information will be added to Ocean FHIR payload for both v0.10.0 and v0.11.1.   This will follow the business rules above, as well as introduce a third Practitioner and PractitionerRole resource into the bundle (for the submitter, the authorizer and the receiver).

Integrators are encouraged to review their implementations to ensure that they are populating their POS fields accordingly.    There will also be an opportunity to perform regression tests in Ocean's staging.cognisantmd.com environment between March 19 - 20th.   

 

Please contact Ocean Support team with any questions or concerns. 

 

 


Minor Update to Ocean's v0.11.1 DocumentReference Resource

A minor update to the Ocean HL7 FHIR V0.11.1 payloads is scheduled for March 21st, 2024: 

 

In the DocumentReference resource, Ocean currently specifies the referral identifier with the prefix "referral-" and the attachment identifier with the prefix "attachment-".   These prefixes will be removed so that the identifier will simply be a UUID in order to align with the V0.11.1 DocumentReference profile.  Examples of the current and future formats are provided below:

Current Format: { "reference": "urn:uuid:referral-1c5d5318-f8c7-4714-8d2c-95081fdaa2c9" }

Future Format: { "reference": "urn:uuid:0fa5b45e-5d6d-445f-85e9-ffe76f41b8b6" }

 

Integrators using the v0.11.1 APIs are encouraged to review their implementations to confirm compatibility with this change.   They will be able to test compatibility with this change in the Ocean staging environment (staging.cognisantmd.com) between between March 19, 12:00 AM EST - March 21st 12:00 PM EST.

 

NOTE: This change is not relevant to implementations using the v0.10.0 APIs and no action is required.

 

Please contact Ocean Support team with any questions.   

 


Referrer's Billing ID in the HL7 FHIR Payload

Several integrations have requested that the eReferral Sender's billing identifier be included in the HL7 FHIR payload to facilitate their ability to receive referrals from new sending providers. Ocean will be adding this into the v0.10.0 and v0.11.1 FHIR payloads in an upcoming release. It will be sent in the 'Practitioner.identifier' property in the format of:

"identifier":
{
  "system": "https://fhir.infoway-inforoute.ca/NamingSystem/ca-on-ohip-billing-id",
  "value": "12345678"
}

The billing ID is entered by the user into their user account or into the referral form at the time of sending. The availability and accuracy of the billing ID is the responsibility of the Ocean sender; Ocean does not have a means to validate it.

This is a non-breaking change, so it should not impact any existing implementations. If you have any questions or concerns, please use our request form to contact us.


New Versions of Ocean's HL7 FHIR eReferral APIs and SMART Launch

FHIR v0.11.1

Ocean offers HL7 FHIR eReferral APIs based on the Ontario HL7 FHIR eReferral Implementation Guide v0.10.0. These have been used to integrate over 20 different vendor systems in order to enable referral receivers to manage referrals within their point-of-services systems.

Ontario has released v0.11.1 of the implementation guide, which includes support for integration with Ontario Health's digital health assets, such as OTN eConsult. Ocean will be building v0.11.1 APIs to enable Ontario Ocean users to send and manage eConsults within Ocean without having to log into the OTN eConsult platform.

OceanMD recognizes the investment its integrating partners have made to date and will continue to offer and maintain the v0.10.0 APIs. These APIs will be available to integrators that have already begun development.

As of October 2023, new integrators that have not already initiated development to the v0.10.0 APIs will be strongly encouraged to develop to the v0.11.1 APIs to leverage the improvements in modeling and validation that have been incorporated into it.

SMART $everything

Clinicians appreciate the ability to single-sign-on into Ocean's Healthmap with the patient in context. When they select a referral target, the patient's demographics are pre-populated for them, saving time and avoiding typographical errors.

Many point-of-service systems have already leveraged the SMART framework to launch Ocean as a SMART app to accomplish this.

Two improvements to Ocean's existing SMART app launch have been identified:

  1. Because Ocean encrypts PHI, it is necessary to have the Shared Encryption Key (SEK) passed in the SMART sequence to avoid requiring the user to enter the SEK in order to decrypt the PHI. In the current implementation, the SEK is passed as a parameter in the JWT token (in step 9 of the sequence described in the Ocean SMART App Launch Overview). While this is compliant with the OAuth protocol, it is an extension from other SMART apps. It also means that each site's SEK has to be programmed individually into the SMART launch sequence.
  2. It would be beneficial to referral senders if the SMART launcher could provide additional clinical data and attachments (as FHIR resources) during the contextual launch sequence beyond Patient.read.

Ocean will be updating its SMART launch sequence in September 2023 to incorporate these two improvements.

  1. Implementers will be able to specify that Ocean should retrieve the SEK from the site's Cloud Connect module as part of the SMART allow-list setup. This will eliminate the need to extend existing SMART designs with the SEK.
  2. Implementers will also be able to specify that Ocean should request access to the FHIR $everything endpoint. The FHIR server can determine the breadth (which FHIR resources) and depth (how far back in time) should be provided to Ocean.

Because these are both breaking changes, Ocean will support both SMART launch sequences so that there is no impact to live integrations. Vendors intending to use the newer version of the SMART launch should explicitly state this when sharing their SMART allowlist parameters so that the correct sequence will be setup by the Ocean Support team.

Questions regarding these announcements can be submitted to the OceanMD Support team.


Change to Ocean's API Authentication Framework Planned for December 15th Release

A non-breaking change to the authentication framework that Ocean uses when sending outbound API messages (both Ocean's Open API and FHIR-based API) is scheduled to be released on the night of December 15, 2022.   We have confirmed that the new framework is functioning properly in our staging environment with several integrated partners.   

If any unexpected behaviours are observed with API integrated sites in either the production (ocean.cognisantmd.com) or test (test.cognisantmd.com) environments after the December 15th release, please contact support@cognisantmd.com with the environment name, Ocean site number, referral IDs, any error messages received, and a description of the unexpected behaviour.