Business Context Index > Business Model
Consent override is a process by which an requester expresses the intention for unblocking any blocked clinical records. It is also referred as “reinstate consent” operation.
At present consent override mechanism varies for each Ontario provincial EHR asset. The current override approach has different types of interfaces, security requirements and interaction patterns for each repository making it difficult for consuming applications to implement.
The PCOI interface aims to propose a consent override approach for the provider gateway that will be consistent across all the lines of business. Provider gateway aims to expose EHR as a unified FHIR service endpoint as opposed to individual repositories, simplifying implementation for consuming applications.
Flow
Provider logged in the POS application using their ONEID oAuth credentials. POS Provider queries FHIR LOB API to get the patient EHR records.
A patient shows up at the provider POS and has a consent directive against its LOB records. POS Provider queries the FHIR LOB GET API to get the OS/LOB results and the provider receives a message that there is a consent directive against the patient’s LOB record.
POS provider presses the consent override button in the POS. Under the cover, the POS calls the FHIR CMS POST API to set the patient and provider context.
The POS then launches the PCOI viewlet.
The PCOI viewlet authenticates against ONEID oAuth and calls the FHIR CMS GET API to retrieve the provider and patient context in order to populate the Consent Override form. The provider fills up the form, and checks the LOB domain check box to override. If overriding DHDR, the provider additionally prints and signs the form.
The Provider presses the Override button from the PCOI viewlet. The PCOI viewlet calls the FHIR LOB Consent Override API to unlock the LOB record.
The POS calls the FHIR LOB GET API to get the unlocked LOB results.
The diagram below illustrates the Business Context for the PCOI solution:
PCOI Viewlet: Arch Input Required
POS: A Point of Service (PoS) System is an electronic product, service or system that uses electronic means to collect, use, modify, disclose, retain or dispose of PHI, and that is selected, developed or used by a HIC. Examples include but are not limited to: an electronic medical record (EMR), a hospital information system (HIS), and clinical viewer.
ONE Access Gateway: The gateway will expose the following API endpoints out of the backend Object Sharing Service:
ONE ID: The external systems (e.g., EMR, MTO) are required to integrate with ONE ID OIDC service so that appropriate OAuth or Access tokens can be provided to the OAG along with requests. This way, it can ensure that objects (e.g., DMR submissions) are securely shared with the intended recipient(s).
Ontario Context Management System (CMS): An external document sender may choose integrating with the CMS so that appropriate patient and provider data can be filled in the document before it gets sent to the recipient(s).
Provincial Consent Management Solution: The provincial Consent Management solution provides the technology and support to business processes for the collection, storage and management of consent directives. It allows Ontario Health to centralize the management of consent directives and to standardize consent management functionality and processes across Ontario Health clinical domains. The Consent Management solution ensures access to an individual's PHI occurs in accordance with consent directives provided by the individual.
LOB: Arch Input Required
Powered by SIMPLIFIER.NET