Explore Tervali topics
No topics found. Try “processes”, “Caremap” or “training”.
Technology and processes
Define sources of truth, track failures between systems, and organize incidents with traceability, metrics, and an example without identifiable clinical data.
Interoperability depends on rules about who maintains each piece of information, how changes flow, and who resolves discrepancies. Integrations need processing confirmation, traceability, and contingency plans, in addition to a technical connection between applications.
A registration record corrected in the EHR may remain outdated in the laboratory system. A prescription change may reach the pharmacy without showing up at the next step. Education may be logged as sent without the person having understood it. These problems show why connecting systems requires following the process all the way to its operational outcome.
This guide covers sources of truth, integration contracts, incidents, and traceability without presenting identifiable clinical data. The scenarios are generic and the chart uses a worked example. Brazil's Ministry of Health defines the RNDS (National Health Data Network) as the national infrastructure for standardized sharing of health information. This initiative is a reference point for interoperability, but internal workflows still require local design and clearly assigned responsibilities. [1]
A source of truth is the system authorized to maintain a given set of information, with an owner and a correction rule. An organization may choose an enterprise master registry for identifiers, the pharmacy system for inventory movements, and a dedicated log for incidents. This allocation is a proposed operational architecture. It should be confirmed with the process owners, without assuming that any one application has authority over all data.
For each domain, document who creates, who consults, who can correct, and how the change reaches downstream consumers. When two systems disagree, the rule should indicate where to investigate and who decides. Do not resolve conflicts by always choosing the most recently received record: an older message may have been held up. Keep the version and the time the event occurred separate from the time it was received.
Describe the event that triggers the exchange, required fields, identifiers, units, terminologies, possible states, and the expected acknowledgment. Add version, destination, owner, and handling of mismatches. A technically well-formed message can still carry a code with a different meaning than expected. That is why acceptance must check content and effect on the process, in addition to the format received.
To avoid duplicates, one approach is to assign a stable key to each event and make repeated processing unable to generate a second, improper transaction. Also define how out-of-order messages are handled and set a limited number of retries. Persistent failures should go to a review queue with an assigned owner. These decisions are design recommendations; they depend on system capabilities and do not describe a universal vendor feature.
Batch of 1,000 unique events at cutoff. Exclusive categories: 950 completed on the first attempt, 30 after a retry, and 20 pending. Total confirmed: 980 events, or 98%.
| Category | unique events |
|---|---|
| Completed on first attempt | 950 |
| Completed after retry | 30 |
| Pending at cutoff | 20 |
Process map for discussing responsibilities and handoff points with your teams. Adapt it to your institution’s context.
Domain owner confirms the event's identifier, version, and meaning.
Integration layer checks the contract and logs correlation, without exposing clinical content on dashboards.
Consuming system checks for repeats, ordering, and business rules; returns a confirmation or failure reason.
Support and the operational owner review pending items; clinical assessment triggers the safety workflow when appropriate.
Departments confirm the final state; gaps go back for review and corrective actions are verified.
In the medication workflow, distinguish between a recorded prescription, an amended version, dispensing, and documented administration. One state does not prove the next. The integration should make it possible to detect when a revision has not propagated and route the discrepancy to the authorized team. Clinical decisions remain with the responsible professionals; the integration mechanism should not reinterpret or complete a prescription to work around a technical failure.
Before go-live, rehearse a change followed by a cancellation, a system outage, and a resend of the same event. Use synthetic records in a test environment. Define how the team works during downtime and how records will be reconciled afterward. Restoring the connection is not enough: you need to verify that the correct sequence was recovered and whether there are pending items that could affect care.
The HL7 FHIR R4 specification describes Provenance as a way to record the context in which a resource was created or revised and the agents involved. This resource helps investigate where a piece of information came from. [3] AuditEvent, in turn, is primarily intended to record events for security auditing, including system usage activity. [4] These are distinct conceptual references, not automatic requirements for every internal integration.
For an operational trail, consider storing the event identifier, sending system, version, timestamp, result, and correlation identifier. Preserve failures and corrections under access control, and avoid deleting history to make the dashboard look clean. Metadata can also identify people or allow indirect linkage. Therefore, restricting clinical content does not eliminate the need for protection, a retention policy, and an analysis of what actually needs to be recorded.
An integration failure may be purely a technical issue or part of a patient safety incident. Classification requires a process review, with participation from the responsible departments and the Patient Safety Committee (Núcleo de Segurança do Paciente) when appropriate. The initial form can capture minimal context and allow details to be added later, reducing effort without compromising the investigation. Link the technical ticket to the safety report through a controlled reference, avoiding unnecessary copies.
Anvisa, Brazil's health regulatory agency, maintains reporting guidance, tutorials, and update notices for the Health Care module of Notivisa, its adverse event reporting system. [5] The internal workflow should support assessment and any applicable reporting while preserving institutional responsibilities. Do not assume that opening a ticket or integrating a tool already submits the report to the agency. Close the loop with a corrective action, an owner, verification, and feedback to the team that reported the problem.
For instructions given to patients and families, separate drafting, review, sending, delivery, and confirmation of understanding. Each state answers a different question. A channel can confirm delivery without showing that the instructions were current or that the recipient was authorized. Define which version is valid and who may revise it. Maintain institutional channels and an alternative when there are barriers to access or comprehension.
Brazil's data protection law (LGPD) classifies health-related information as sensitive personal data and sets out principles such as purpose limitation, necessity, and security. [2] In the proposed design, use only data relevant to the purpose, with role-based access and an institutional assessment of the applicable legal basis. Replacing names with codes does not guarantee anonymization. For broad dashboards, prefer aggregates with a reidentification risk assessment; for testing and demos, use synthetic data.
In the example in the chart, a batch has one thousand events: 950 processed successfully on the first attempt, 30 processed after a retry, and 20 pending at cutoff. The categories are mutually exclusive. All events may have been received, but only 980 had confirmed processing. The completion rate is 98%, with 2% still pending. These values are not a recommended target.
Beyond the percentage, track the age of the oldest pending item and the propagation time. Completed events alone do not reveal how delayed the stuck ones are. Start with a well-scoped workflow, with an identified operational owner and technical support. Acceptance should include failure, recovery, reconciliation, and a demonstration of the final state at the destination. Only then expand the scope, keeping stop criteria in place when there is risk to the process.
Check off the items already in place. Use the rest as a working agenda.
100 × unique events with confirmed business processing by cutoff / eligible unique events issued in the batch.
Define eligibility, cutoff time, and confirmation. A transport-level response does not prove the process was completed.
95th percentile of the time between issuance and confirmed processing, for completed events in the defined cohort; unit: seconds or minutes.
Report the percentile method, clock synchronization, and pending events. A cohort of completed events only can hide persistent failures.
100 × eligible unique events without final confirmation at cutoff / eligible unique events in the batch.
Show absolute count, age, and criticality. Define separate rules for cancellations and final rejections.
100 × actions due in the period with verified effectiveness / actions due in the period, according to criteria defined by the process owner.
Closing a ticket does not demonstrate effectiveness. This metric does not replace safety analysis or reporting obligations.
No. A standard organizes representation and exchange, but you still need to define meaning, versions, identifiers, responsibilities, and confirmation of processing in the local workflow.
No. The ticket and the safety report serve different purposes. The institution must assess the event and follow the applicable reporting guidance and responsibilities. [5]
This guide recommends synthetic data. Processing real data requires an institutional assessment of purpose, legal basis, necessity, and safeguards, especially for health data. [2]
Primary sources used to produce this content. Implementation recommendations should be adapted and validated by each institution.
Role of the RNDS as national infrastructure for interoperability and standardized sharing; does not demonstrate local integrations or the availability of specific features.
Official text consulted: article 5, II, health data as sensitive; article 6, principles of purpose limitation, necessity, and security. Does not constitute individual legal advice.
Context of resource creation and revision and the agents involved; distinction from AuditEvent, in version R4.
Purpose of security auditing and recording of usage events. R4 version reference, without asserting that it is mandatory or supported in local systems.
Guidance, tutorials, and update notices for the Health Care module of Notivisa. The article does not assume a reporting API or define regulatory deadlines.
Educational content on management and technology. It does not replace professional judgment, current regulations or clinical protocols.
KEEP EXPLORING
