Document integration considerations
When planning integration and workflows, documents play a central role in this consideration. This page is written for the project implementation team to support discussions around when consent PDFs are sent from Concentric, how they are managed on the organisation’s side, and how they should be displayed to clinical users.
Consent events
Consent PDFs are generated within Concentric whenever a consent event occurs. The possible consent events are:
- patient signs their consent via the clinician application more than 24hrs before treatment
- patient signs their consent via the clinician application less than 24hrs before treatment
- patient signs their consent via the patient application
- consent is confirmed on the day of treatment within the clinician application
- consent is revoked within the clinician application
Events 1 and 3 place a consent episode into an ‘awaiting confirmation of consent’ state, so can be considered incomplete documents. i.e A further event (consent being confirmed on the day - event 4) is expected before the document is complete.
Event 4 can be completed on multiple occasions (for example in the case that consent is confirmed then the case is cancelled, leading to a further confirmation occurring at a subsequent date). Event 5 is a rare event.
Information shared via integration
In the vast majority of cases, metadata (data relating to the document) is passed with the consent PDF. This is often used to show key information at a glance with an EHR/EDMS.
Metadata can also be used to apply logic rules, for example, by sending consent PDFs relating to a specific specialty to an EHR used within that department.
The relevant metadata fields that can be shared alongside the document are: consent form type (e.g. consent form 1, consent form 2), episode consent status (e.g consent given, consent confirmed), version (this is the version of the consent PDF for this consent episode), timestamp (this is the time the event was recorded in Concentric), patient identifier (typically the hospital number), treatment name, specialty, responsible clinician, and consenting clinician.
Visibility and versioning
In most scenarios, we advocate that documents are sent to the organisation each time a consent event occurs. This ensures that within the organisation there is a full history of document states.
However, there are considerations regarding how these sent documents are managed and viewed by end users. The two considerations below should be considered together as a decision/capabilities regarding one may impact the right approach for the other.
All documents or just completed documents?
Most organisations decide to make a Concentric-generated consent PDF visible within the EHR/EDMS regardless of whether it is in a completed state (following events 2, 4, 5 above) or in an incomplete state (following events 1, 3 above). The status of the episode can be shown at a glance via the metadata (episode consent status above) and is shown prominently on the first page of the PDF:
Occasionally, organisations decide to only show PDFs to clinicians when an episode is in a completed state. The rationale for this is to reduce the risk of a consent form mistakenly being used during a WHO surgical safety checklist when there is further action that should be completed.
Versioning
The preferred approach regarding versioning is that all versions sent to the organisation (as per above) are stored within the organisation, with only the most recent being shown to the clinician in the EHR/EDMS user interface. This ensures that within the organisation there is a full history of document states but is dependent on the ability of the EHR/EDMS to manage versioning.
Two less optimal approaches are:
- One PDF version for the consent episode is stored, with previous versions overwritten upon receipt of a new version.
- All PDF versions are kept and presented separately to the clinician in a list, meaning that the clinician needs to select the newest PDF for the episode.