Mirror the documentation / CAD system requirements
To ensure data mapping is as easy as possible, make sure all required information fields to complete the documentation process are represented in the Corti flow.
Example: If a date of the incident is needed for the system Corti is integrating with, there needs to be a question within the protocol asking for the date of the incident.
In addition, if the classification of a specific incident or chief complaint is listed as x, y, and z in an existing documentation system, the classification needs to be the same in a view node within the Corti flow.
Tips and tricks: When initiating the protocol-building process, ask the customer’s IT team for an overview of required information fields and fixed inputs within their current systems.
Please note:
- The naming can be different within the Corti flow. However, it needs to map to a selection from an existing system.
- If there can only be one chief complaint / incident type / injury type then remember to unselect the “multiselect” option, when setting up the protocol selection.
Example: if the existing system only allows you to choose between 20 chief complaints, a selection of 30 chief complaints within the Corti flow will cause mapping issues.
In general, make sure the protocol matches the existing documentation requirements as much as possible. This makes data mapping much easier when information is to be transferred from Corti to an existing documentation system.
Use facts to skip or send information to Corti
If the protocol needs to branch out based on information hosted within an existing system, the “Facts Library”, within the protocol editor, can be used. This enables external information to be shown in a FVC within the Corti flow. It also enables logic gates to determine what view nodes are shown based of external information
Example: if the external system has patient's address listed. A “fact” can be set to display this information to the call-taker. It can also be used to determine what branch the call-taker should follow. If the caller lives in a big city the advice might be different from if a caller lives in the countryside.
There are two types of facts; Boolean facts and String facts. Boolean facts is a data type that has one of two possible values, false or true. Whereas, string facts are used to represent a series of characters (i.e. text).
Use the feature “critical pathway” to avoid issues with data mapping
Depending on what type of integration it is; REST/GET end-points or event-based client API’s, then the critical pathway feature may be very useful. The critical pathway enables users to only save information in the FVC from the last chosen protocol branch.
If the critical pathway is not enabled for your FVC, all information collected is saved in the FVC. This is also true if a user starts in one branch, regrets it, and starts navigating down another branch. This can as a result lead to issues with the data mapping when transferring information. This is especially true with the REST/GET end-point as information is synched manually via. the click of a button, instead of being live-updated with event-based client API’s.
Example: A call starts and the caller initially takes about shoulder pains. During the call, it becomes evident the caller is having a stroke. This makes the call-taker change the chief complaint 2-3 min. into the call. All documentation up until this point has been collected in the wrong branch, and stored within the FVC. With the critical pathway enabled, the old documentation is removed from the FVC, and new information is collected in the new branch.