4.13 Case Study #19: Portuguese National Broker

Transcription

1 4.13 Case Study #19: Portuguese National Broker Author of case study within the estandards project: o Rita Cunha o Hugo Soares Project name: PNB Portuguese National Broker Project type: large-scale deployment for sustained routine use Project status (in 10/2015): deployed for sustained routine use Countries / Regions: Portugal (all regions) Project partners: Portuguese Ministry of Health, Shared Services (SPMS) Scale of deployment: Cross-region Project Overview There are several centralized ehealth systems in the Portuguese national infrastructure that need to communicate data with local facilities hospitals and primary care units. In order to achieve data synchronization between these both sides we have been implemented large-scale interfaces that are responsible for managing the interoperability process. The scope of these integration engines encompasses such diverse workflows as the patient summary or the electronic prescription. However, with the continuous spread of centralized applications or information repositories through other workflows (e. g. vaccines), there has been a significant increase of this type of interoperability needs that makes its error-free maintenance a very hard task. Currently, despite the thousands of messages that are processed daily, we still deal with constraints caused by design problems of the Portuguese National Broker s (PNB) initial solution. That is the reason why we have been working on a new version of PNB. This PNB 2.0 aims to be a robust generic architecture to support nationwide interfaces in Portugal. The main goal we want to reach with this approach is to provide technical reliability to cross-region exchange of critical information using international standards, regardless of the workflow involved. To achieve that, we will pay particular attention to relevant issues such as high availability, scalability of the solution, monitoring or alarms. The main purposes of the PNB can be summed up in four aspects: to centralize the transfer of health data between NHS institutions or internationals; to improve the capacity of maintaining and upgrading the recent transfer workflow; to facilitate the adoption and implementation from third parties to PNB s ecosystem; to contribute to the promotion of interoperability in health care data Approach Care Process The PNB intends to define transversal rules, based on recognized standards that will be adopted by all the teams in the institution. By implementing these standards, we will address the concerns related to technical implementation rules to a common scope; not only to the National Health System, but also to an international level. The core-project PNB team is working on is the Vacinas (e-vaccines) project. The main purpose of this project is to have a centralized management of The National Immunization Program to the Na- D4.1: Solutions for a Coexistence of ehealth Standards Page 221

2 tional Health System users. The Vacinas project intends to replace the current immunization registration, made in SINUS (application used on Primary Care Units for the immunization record) by the nurses, in Primary Care Units. The main goal of this project is to centralize the management of the Immunization National Programme to the National Health System users. Due to its complexity, it needs to have several products working together with it. Vacinas Workflow To Be PDS Vacinas PNB Vacinas Aplicação local Inoculation Registration Inoculation Registration Inoculation Registration/Edit Inoculation Registration/Edit Delete Inoculation Delete Inoculation Next Inoculation Next Inoculation Registration/Remove non-vacination Registration/Remove non-vacination Remove/Delete patient s inscription for vacination Remove/Delete patient s inscription for vacination Information The PNB has the following functionality: Figure 73: e-vaccines Workflow Message reception: The information providers should send HL7 FHIR messages to the Broker. The information will be received by a Mirth channel available for this purpose, which implements the REST API used by the HL7 FHIR standard for the Bundle resource type Message. The Bundle Resource type is an infrastructure type of resource, which generally provides useful information, and/or are referenced directly from base FHIR framework. The client will receive an immediate response, indicating the validation status of the message and act accordingly. If the client doesn t receive the answer message, he must act according to the Reliable Message specification the FHIR messaging framework [FHIR]. The figure below shows an example of such a HL7 FHIR call, with information encoded in JSON. D4.1: Solutions for a Coexistence of ehealth Standards Page 222

3 D4.1: Solutions for a Coexistence of ehealth Standards Page 223

4 Figure 74: HL7 FHIR Example Message: e-vaccines Validation of FHIR Messages: The message received in the PNB will be validated according to the HL7 FHIR standard also in line with the specific rules of the implemented workflow, e. g. vaccines. Forwarding of FHIR messages: If the message is successfully validated, it will be sent to a specific place, defined by the message, in the field destinations. The receptor should ex- D4.1: Solutions for a Coexistence of ehealth Standards Page 224

5 pose an API, if there is the need to reprocess/re-send a vaccine intake. Central monitoring and Logging: All HL7 FHIR interactions will be registered in a central log and this log enables the user or the administrator to verify the message status (processed with error or success), and to generate statistics based on message contents Applications The immunization recommendation refers to the point in time of a patient s last immunization and a recommendation forecasting a patient s immunization eligibility according to a published schedule, with optional supporting justification. The business rules defined by the National Immunization Plan (PNV), such as the age, gender, health condition, which are provided by the National Health System (SNS), for instance sending the notice to immunization, are managed on a local level. The immunization describes the event of a patient being administered a vaccination, or a record of a vaccination as reported by a patient, a clinician or another party and may include vaccine reaction information and which vaccination protocol was followed. In this use case, the standardized HL7 FHIR interface helps in connecting two workflows, central and local: The information about the control of the administration or non-administration, adverse reactions and justification for non-vaccination is registered centrally, but the clinical file is stored locally. The standard interface allows the required information to travel from local to central IT Infrastructure Figure 75 below describes the outgoing and incoming connections, as well as the modules that internally comprise the PNB solution. The input flows are initiated by the Data Producers or Data Clients which insert or query data. PNB is responsible for exposing a HL7 FHIR Messaging API through a network layer that can assure reliable and safe access. Internally, the Broker has a HTTP server component that implements the clinical information exchange standard HL7 FHIR (DSTU2) and assures that the received data are compliant with this standard. Following the internal processes, all the requests are sent to its target connector that can be a contact point with an external FHIR server (through HTTP) or an external database (via JDBC). The forwarding rules are defined accordingly, taking advantage of the workflow engine that composes the Broker and the metadata that is managed via Backoffice. The workflow engine is composed of configurable routing rules implemented by the Asynchronous Mirth Channels. This metadata is mainly related to National Health System local catalogues (Distributed Data Repository Systems). All internal modules of the Broker report their status to the Monitoring & Analytics module, enabling troubleshooting and real-time control of the workflows implemented in the PNB. D4.1: Solutions for a Coexistence of ehealth Standards Page 225

6 HL7 FHIR messages HL7 FHIR messages or JDBC Figure 75: Portuguese National Broker Architecture Concurrent Use of Standards and Specifications (De-facto Standards) We chose to use HL7 FHIR because this standard allows us to abstract from certain details that the PNB doesn t define, it abstracts from the codeable concepts. A codeable concept represents a value that is usually supplied by providing a reference to one or more terminologies or ontologies, but may also be defined by the provision of free text. This is a common pattern in healthcare data. [CodC] Each coding is a representation of the concept as described above. The concept may be coded multi- D4.1: Solutions for a Coexistence of ehealth Standards Page 226

7 ple times in different code systems, where multiple forms are possible. The different codings may have slightly different granularity due to differences in the definitions of the underlying codes. There is no meaning associated with the ordering of codes with a codeable concept. The codeable concepts are recognized both by the receiver and the subscriber of those data. The de-facto standards used were the Catálogo de Vacinas da DGS and the Reacções Adversas Governance The entire development of the Vacines project is managed by the interoperability team of SPMS, by the PNB team. All of the operational process (including developing the suitable connectors) is under responsibility of the products teams that provide the roll-out of the Vacines and manage their interfaces Lessons learned The work group involved during the complete project is, for certain, an added value in this kind of major projects. The fact that there was a representative of each team, in permanent communication, was without a doubt a valuable aspect. The HL7 FHIR knowledge had to be distributed among all the teams, so the investigation effort to keep up with all the updates concerning the standard semantics as well as the implementation of new product requirements affecting the interfaces was extremely important. The tools used to implement the required distributed information rules were extremely useful since they provided the needed flexibility to implement this project. The utilization of the Mirth connect services allowed some kind of flexibility during the all process of implementation. The usage of Java and.net FHIR Reference Implementations helped kick-starting the project. The requirement of having a previous functional analysis in the interoperability component (which was performed in a later phase of the project) had some negative impact. The consequences were that it has interfered in the time needed for the development in the interoperability and made it more difficult to implement the workflows needed. The main lesson learned here is that before the implementation, a requirements analysis must be done Successes The use of the HL7 FHIR standard was a huge success: it contributes to simplify the technical implementation and to address functional and semantic questions to the standard itself instead of having to deal with these issues internally by building those guidelines ourselves. That has accelerated the entire process. The fact that HL7 FHIR is very well documented and structured also helped Pitfalls and Remedies We consider the poorly selected time in which the functional analysis occurred a pitfall in the project. The Vacinas project started with a wider scope and didn t include the local interoperability component. As the project was progressing, we were able to identify some gaps in the first functional analysis, in what concerns the patient notices to the immunization as well as in the Business intelligence part. The workaround we found in order to fulfil these requirements was to implement a mechanism of information propagation that would be now in the Vacinas to the local repositories where the absence of that information would be noticed. D4.1: Solutions for a Coexistence of ehealth Standards Page 227

8 References and Further Information [CodC] [FHIR] HL7 FHIR definition of CodeableConcept. Online: (accessed ). HL7FHIR Draft Standard for Trial Use (DSTU2): FHIR messaging framework. Online: (accessed ) D4.1: Solutions for a Coexistence of ehealth Standards Page 228