MedicalDirector Helix: use Abe separately or verify the integration
Who this is for
This guide is for an authorised practice or hospital arranging non-patient reference access alongside MedicalDirector Helix. The integration route remains unavailable: this guide records a route to pursue, not an accepted Abe installation or vendor partnership. Fees are unconfirmed and require a current written contract for the chosen purpose.
The recorded route is a SMART launch using vendor registration and scoped clinician identity. The linked development guide is a ci-build/local-development guide; it is not evidence that a production Helix tenant accepts an Abe application.
Start here
- Record the exact product, version, practice or hospital, intended reference purpose and authorised contact. Do not put patient details or credentials in the request.
- While integration is gated, sign in to Abe separately. Use Professional development or Evidence search within your own current access. This companion does not connect the vendor or exchange patient data.
- Obtain written production support for the exact Helix tenant and version. Confirm the issuer, registered client, discovery information, supported launch and identity scope, return location and tenant context with the vendor.
- Agree source permission for the exact audience and representation. Permission to open a source link does not establish permission to copy its full body into a panel or redistribute it.
- Arrange the acceptance witness below and name the support owner. Payment, application registration and human consent are separate from vendor acceptance.
What success looks like
The standalone companion reaches the correct Abe account and permitted reference result. The proposed integration route is SMART launch, and it can be called accepted only after the exact environment and contract have a witnessed result.
Witness a real launch in the actual approved production tenant using a non-patient test. Confirm the clinician and practice, then switch user and tenant, test expiry and revoke. A development launch alone cannot pass this acceptance.
The acceptance record must show the actual product/version, practice, identity, scope, source use, expiry and revoke outcome. Patient reads and writes remain disabled under this reference scope, even if a vendor API offers them. Sponsoring a person does not expose their private alert criteria or make a practice credential that person's identity.
If it does not work
If production support or issuer/identity mapping is missing, use Abe separately. Do not substitute a patient account, a development issuer or a broader patient data permission.
Stop if a reference opens under the wrong person or site, or a source has no current permission. Send support the product/version, intended non-patient task and safe error only. Do not send keys, patient information or screenshots containing either. Use Troubleshooting for failures in the existing companion; it cannot replace missing vendor acceptance.
Stop or change your choices
Before accepting an integration, witness what happens when you switch user, account or site. Disconnect the affected Abe host permission through its supported process and revoke the vendor credential, pairing or launch permission through the separately confirmed vendor process. Verify old access is denied; if that process is not known or cannot be witnessed, the integration route stays unavailable.
Revocation prevents new authorised uses; an already delivered reference or in-flight operation cannot be recalled by disconnecting. Keep independently valid direct Abe access, personal preferences and funding separate. Manage and cancel explains those separate choices. Reconnecting later requires current authority and renewed acceptance where the contract or environment changed.
Recorded source: MedicalDirector Helix vendor documentation. Obtain current written confirmation before activation; the recorded documentation is not a fee quote or proof that Abe has been accepted.