Site Tools


opentele3:ot3_to_be_architecture

To-be Architecture

This page is part of the OpenTele3 architectural design efforts.

Here we outline the proposal for an OpenTele3 architecture. The proposal comes in the form of

  • A number of general and specific principles for component design and interaction
  • Key components and their interaction

To understand how this work has been shaped it is important to take a look at the page on scope, goal and process.

Principles:

In this section we present proposals for guiding principles for the OpenTele3 architecture. First we present some overall or General principles that are neutral with regard to standards and technologies. Then, in the subsection Specific principles, we delve into specific guidelines, technologies and standards to apply when designing components, interfaces and their interaction.

General principles

In line with our overall goals we try to follow three overall strategies in the design of an OpenTele3 architecture:

  1. Work towards a microservice architectural style
  2. Use international standards for communication and content formats
  3. Aim for cross-platform support and low platform dependence

In "OpenTele Modularisation - A proposal for discussion" we outlined some benefits and characteristics of microservice style architectures. Here, we supplement this by Newmans 1) two main points characterising microservices:

  • Small, and doing one thing well: Microservices are independent services and its boundaries are aligned with boundaries of the business domain.
  • Autonomous: A microservice is a separate entity and can be deployed in isolation without requiring data consumers to change. Avoids tight coupling and each service can change independently of the other.

This amongst others means that we encourage:

  • Loose coupling and high cohesion - applying the single responsibility principle to services.
  • Separate frontends from backend data services.
  • Decentralized data management: A data store is only to be owned by one service. Other services may only get access to its data through the owner's service API.
  • Small number of ways for components to interact - well described and standardised.
  • Componentisation via services - when modularising aim towards components as self-contained services interacting at runtime.

The above is not meant as a comprehensive list of architectural principles we find sound to follow, but rather as a few tenets that serve as guides and inspiration when proposing a redesign of the architecture.

Specific principles

Component/service interfaces: When designing a component/service interface we put forward a prioritized check list for where to look for standards and guides on how to design the interaction and interface:

  1. Does the national eHealth reference architectures say anything? (for Denmark look here)
  2. Does the Continua Design Guidelines say anything?
  3. Does HL7 FHIR say anything?
  4. If your service handles any kind of resource, support a RESTful interface based on hData

The first three items of this list is more less a direct reflection of stakeholder input on standards and interfaces and the last item leans heavily on the fact that the hData specifications have been approved by HL7 and the Object Management Group (OMG), and have been adopted by Continua Health Alliance for mobile health devices2).

Data services and frontends: As mentioned under General principles we encourage decentralized data management. That is, a data store should only be owned by one service. Other services may only get access to its data through the owner's service API. We introduce the concept of a 4S data service with the following typical characteristics:

  • Exposes RESTful interface that support read, locate and update of resources (RLUS = Read, Locate, Update Service)
  • Has a RESTful interface based on hData and/or FHIR
  • Supports capability exchange through hData root file structure, exposing capabilities / resource structure.
  • Storage solution is encapsulated and free of choice
  • Supports basic monitoring: Standardised logging and collection of service metrics.
  • Assumes the role of a resource server actor in relation to the IHE Internet User Authorization profile (IUA).

Notice: RLUS is just a basic capability of a 4S data service. In general we discourage anemic data models and services and thus discourage pure CRUD/RLU services. So, we also encourage you to think about what business functionality the data service should support and expose.

The 4S data service concept works in support of the stakeholder wish to separate frontends from backend data services:
3)

In this way any number of specialised UIs can be connected to a backend data service and thus flexibly support multiple types of clinicians and/or patients web frontends.

Regarding capability exchange (see more below) we suggest following the latest Continua recommendations:

  • When using REST support capability exchange
  • When using SOAP capability exchange is optional


If we take a peek inside a single service we propose an OpenTele3 service architecture following this scheme:

4)


Things to consider:
  * Is your system responsible for maintaining and indexing the information? See push vs pull,  http://www.hl7.org/fhir/2015May/pushpull.html.
  * Relationship between FHIR and hData: http://www.projecthdata.org/faq.html

Frontend, client-side software: The current “common denominator” of platform independence is the combination of HTML5 and JavaScript (JS). All current platforms – from smartphones over tablets and desktop computers to modern TVs – have web-browser capabilities, and the HTML/JS content may even be “wrapped” in native-looking applications tailored for the individual platforms. Some recent platforms (Firefox OS, Chromium OS) even require that all apps must be HTML/JS-based.

There are still a number of things to consider:

  • Separating functionality into different loosely coupled JS modules. Study this example for more inspiration.
  • Keep background processing and timing-critical software (such as reminder alarms or communication with external devices) in separate modules, so that they may be launched as background services on the client platform. Such modules may have to run as a native application on some platforms. To maximize portability, we suggest considering C or C++ along with a non-blocking programming style for native modules. See the 4SDC architecture document for more advice on this subject.
  • When considering the use of external libraries, choose as few and as mature libraries as possible. Beware of the "dependency hell", i.e. be careful about dependencies on specific library versions, as this may lead to conflicting dependencies when this module is combined with other modules. In this JIRA issue a JS module for handling dependencies is being planned.
  • Consider adopting a Single-page-application-style for the client application, in the sense that the application will be more independent of the server (less “chatty”). Of course, individual modules in the client application may communicate a lot internally, but communication with the server should be limited as much as possible, because this will:
    1. scale better, as the server will be able to serve more clients.
    2. lead to a better user experience, as the user interface will function more smoothly.
  • If, for some reason, the application must be “chatty”, consider the user experience of users on a lousy Internet connection (low bandwith, long latency, or dropouts). If possible, consider asynchronous communication with the server to avoid blocking the user interface due to a bad connection.

For more examples and background information:

Integration with legacy and non-standard components: A telemedical system is part of a larger complex of health IT systems and ideally integration is seamless and each new integration can happen at low cost and low risk. Ideally you could come close to such a situation if all systems where fully agreed on standard interfaces and exchange formats. In reality, a large bulk of legacy will be fashioned with non-standard interfaces and interchange formats. In order to isolate the complexity of each non-standard integration and in order to still enable our own software components to communicate in standardised ways we recommend separate integration with legacy into transformational services. These will on the one side expose a facade compliant with standards and on the other encapsulate the specific integration through legacy interface:

5)

Key components and their interaction

Revisiting the data handled by and use cases supported by the existing OpenTele implementation we basically wish to determine which parts should stay as core components in the future and which parts can be sensibly be externalised and componetised. That is, with the input from stakeholders as a key resource we suggest moving from a situation where OpenTele handles: 6) … towards a componentisation that can conceptually be depicted through this illustration:

7)

The inner circle is the part of the original OpenTele data that we suggest as the basis for core types of data and functionality in relation to a concentrated focus on monitoring and collecting health data from citizens. The orange topics surrounding the inner circle depict functionality that on the one hand is key, or at least relevant, to the telemedical system, but on the other hand has been identified (with stakeholders) as functionality that has a more generic or general purpose nature - either through existing systems / components / services or through an proposed externalisation of internal functionality with the purpose of future reuse and sharing. That is, as core data:

  • Measurements
  • Measurement thresholds
  • Questionnaire responses
  • Monitoring plans
  • Acknowledgements
  • Audit log

And, in brief summary, the functionality supporting the production of this data we describe as follows:

  • Measurements:
    • A patient can take measurements and send the responses to the central telemedical server (the WAN device in Continua terms).
    • A patient can view own measurements taken
    • A healthcare professional can view patient's measurements taken
  • Measurement thresholds: A healthcare professional can set individual thresholds for measurements and measurements can be categorised according to thresholds (see Observation assessment service below)
  • Questionnaire responses:
    • A patient can answer questionnaires and send the responses to the central telemedical server (the WAN device in Continua terms).
    • A healthcare professional can view responses from patients
  • Monitoring plans:
    • A healthcare professional can setup a monitoring plan for the patient. The monitoring plan is basically a plan scheduling when and which questionnaires and what measurements the patient should respond to.
    • The monitoring plan can be communicated to the patients device(s) (the AHD).
  • Acknowledgements: A healthcare professional can acknowledge the receipt of responses from patients.
  • Audit log: In order to be able to track unwanted intrusions and inappropriate use any business event is logged to an audit log.

In the section below we outline how we propose communication and service infrastructure reflecting this.

Furthermore, in sections below this we group the “orange” topics in strategic focus areas for componetisation:

  • Frontends and portals
  • Questionnaires
  • Communication: Messaging, video conferencing, notes, patient fora, e-learning
  • Calendars and planning
  • Administration, self service and master data
  • Logistics, asset management and tech support

One further strategic focus area should be added as a cross-cutting concern:

  • International standards for communication and content formats

Core telemedical functionality:

In line with the Danish reference architecture we identify, as the heart of a telemedical solution like OpenTele, the ability to monitor and collect health data from patients. In the conceptual image above this is visualised as dealing with the data within the dotted oval. In terms of the reference architecture and Continua Design Guidelines the main component interaction can be mapped out like this:

8)
Where, quoting the Danish reference architecture:

  • Monitoring device: equipment that generates various types of data about the citizen's health.
  • Application hosting device (AHD): An electronic unit that collects data from a monitoring device situated locally with the citizen, and which sends the data on to a WAN device.
  • WAN device: ICT system in which collected data is stored and prepared for consumption in an IHE repository.
  • Repository (IHE): The document repository is responsible for both the persistent storage of documents as well as for their registration with the appropriate document registry.

In terms of the current OpenTele the AHD corresponds to OpenTele tablet clients and the WAN device corresponds to OpenTele servers. Notice that the WAN device is a logical unit or role. That is the internal structure of the WAN device can consist of any number of servers and services - whatever is most suitable for the organisation of data collection, communication with frontends etc.

Following stakeholder input on standards and interface and questionnaires we suggest to follow the most recent version of the Continua Design Guidelines closely regarding the interfaces between the main components. In overview this means applying standards as follows:
9)

Zooming in on the AHD to WAN device to repository part this implies an architecture that can be depicted as follows:
10)
That is:

  • Measurement observations are uploaded in content format PCD-01. Notice that the WAN device can support delivery over SOAP as well as via a hData RESTful interface. We propose supporting both, but with RESTful communication as the preferred way of interaction.
  • Answers to questionnaires are uploaded via hData REST in the form of HL7 Questionnaire Response Documents (QRD).
  • To support patients viewing past questionnaire answers the AHD can via hData REST retrieve a list of completed questionnaires in the form of an atom feed. On the basis of this the answers themselves can be retrieved in QRD format via hData rest.
  • Patients can view and be reminded of questionnaires that they are supposed to fill out through the AHD being to retrieve an atom feed list of questionnaires to be completed. This feed contains a due date along with a reference to a HL7 Questionnaire Form Definition Document (QFDD). On the basis of this individual QFDDs can be downloaded to the AHD. Both atom feed and QFDD over hData REST interface. Notice that the list of questionnaires to be completed can be seen as constituting implicit monitoring plan information.
  • Socalled capability exchange (not depicted) happens via hData root files. The purpose of the capability exchange is to support AHD and WAN device services in exchanging information about the services supported and corresponding resource structure.

Notice that the Continua Design Guidelines do not explicitly specify a way for patients to retrieve and download already taken measurement observations. The obvious symmetrical case to QRD download would be to support retrieval of raw PCD-01 reports. However, as we outline below we suggest exploring how the WAN device can support a RESTful interface in general and in particular in relation to observations and questionnaire answers. In this context it leads to the suggestion to look towards HL7 FHIR observation resources potentially coupled with FHIR bundles.

On the inside of the WAN device we have sketched a number of data services. We propose to model these on our principles for data services. More specifically we suggest to follow stakeholder input on standards and interface and on observations and measurements:

  • Use HL7 FHIR outside Danish reference architectures: Where Danish reference architectures and/or Continua doesn't say anything experiment with using FHIR where possible.
  • Observations - searching and subscribing
    • Need to continuously save incoming data in easily/fast searchable format
    • Should have a standard for subscribing to incoming measurements

We thus suggest exploring how the WAN device can support a lightweight or fine grained RESTful interface in general and with a particular focus on how and where HL7 FHIR resources can meaningfully come into play. In the context of the core telemedical functionality of monitoring and collecting health data from patients this implies exploring:

On the basis of this we outline a bit more detail on the WAN device and interface as follows:
11) That is in a step-be-step process:

  • Implementing support for standards based communication over SOAP, hData and FHIR from AHDs towards the WAN interface.
  • Internally implementing FHIR based (micro-)services
  • Implementing translator or transformation services in order to support all the interfaces in parallel - isolating differences and keeping internal service communication simple and standardised as well.
  • Publish/subscribe based services reacting on new data - for example:
    • An XDS Document Set Builder service that takes incoming PHMR and QRD, building a document set with metadata and submitting it to XDS repository.
    • An Observation assessment service that in line with stakeholder input in a separate service deals with assessment and categorisation of measurements according to thresholds. Could potentially be generalised to also dealing with the assessment and categorisation of any kind of data stemming from patients - particularly questionnaire responses.

Questionnaires

12)

While the ability to ask the patient to answer a questionnaire and the ability of patient to answer it is seen as part of core functionality, we see the act of defining the questionnaires themselves as a candidate for component extraction from core services. The following items from the stakeholder input on questionnaires relate directly to this:

  • Questionnaire Editor as a separate component
    • General storage and editor that can be used for questionnaires in a non-OpenTele context
    • OpenTele should just be consumer of questionnaires
  • Support for HL7 questionnaire standards - QFDD and QRD
    • Based on Danish profile of QFDD
  • Generic questionnaire presentation component
    • For instance an HTML5/JS based component for presenting HL7 QFDD based questionnaires

As described in the general introduction to the OpenTele3 activities implementing a QFDD based questionnaire editor as a separate component is part of the OpenTele3 activities. There are lots of details on this to be found OpenTele3 Questionnaire editor|on the Questionnaire Editor wiki pages]]. In this section we therefore focus on outlining considerations in relation to how editor, storage and questionnaire utilisers are thought to interact.
13)
Expanding on stakeholder input there are at least four different basic roles related to questionnaires:

  • Creating and editing questionnaire definitions
  • Storing questionnaire definitions
  • Presenting and answering questionnaire (definitions), producing questionnaire answers
  • Storing questionnaire answers

Following this and in line with our general principles (loose coupling, decentralised data management etc.) we propose questionnaire definition editor and questionnaire definition storage service separate from each other. Questionnaire storage is proposed to have a RESTful interface based on hData via which QFDD documents can be stored and retrieved. We also put forward that it should be considered simultaneously supporting an interface based on the FHIR Questionnaire ressource.

Regarding presentation of questionnaires it is an obvious to use XSLT for the presention in browsers or browser like contexts - be it directly on Application Hosting Devices or via users web browsers. Regarding the provision of the questionnaire definition itself we do not typically imagene that an AHD communicates directly with QFDD data storage, but rather does this through communication with a WAN device, as illustrate in the section on core telemedical functionality. Similarly, storage of questionnaire answers will typically, in a telemedical setting, be handled through a WAN device, that in turn will deliver QRD documents to XDS infrastructures.

Communication: Messaging, video conferencing and notes

14)
Messaging (email, sms or similar) and video conferencing functionality is often a part of telemedical solution, but for a number of reasons, it shouldn't:

  • Communication and notes are part of the clinical reasoning and coordination between health authorities, and by law requirement, all written communication must be documented in the various EHR systems etc.
  • Communication about a patient is seldom related to a telemedical treatment alone, but will also be relevant in any other kinds of contacts between the patient and the clinicians.
  • Whenever messages, notes etc are implemented within telemedical systems, clinicians are faced with impractical double documentation work, where telemedical notes must be copied to the EHRs/clinical documentation and vice verse.

Therefore, in our conceptual drawing we have not depicted it as part of the core telemedical functionality. This is not to say that it can not be an important, or even sometimes essential, part of a telemedical solution like OpenTele. It is depicted this way due to the fact that these functionalities are also part of a great many other health IT applications, and integration with these is considered necessary for the functionality to be valuable.

Messaging services: As recorded in the input from stakeholders patient/clinician messaging is therefore a one of the candidates functionalities to be implemented through interfacing with external components.|

Considerations:

  • The nature of the content communicated can have very varying degrees of sensibility and therefore imply varying levels security concerns.
  • Depending on type of information communicated options span from regular sms and email, over encrypted regular email to encrypted/digitally signed special purpose solutions. The latter typically in the form of a web portals implementing secure messaging.
  • It is important to consider how to support users in communicating via users own devices. Supporting BYOD is an important stakeholder concern.
  • It is unclear how/if current solutions like e-Boks or MedCom correspondance can be smoothly integrated in existing solutions.

Video conferencing: There is significant stakeholder interest in developing general, open standards, open source video conferencing functionality that can be fluently integrated in telemedical solutions like OpenTele. So, again in reference to the stakeholder input, a solution should:

  • Be based on open standards - ideally both with respect to integration APIs and streaming technology and protocols.
  • Be available as open source (doesn't exclude closed source solutions based on same standard interfaces).
  • Put no or little requirements on clients with respect to pre-installed special software.
  • Function in desktop/web environments as well as mobile environments.
  • Enable a flexible session concept with support for multi-party as well as point-to-point sessions.
  • Enable (or not stand in its way of) secure data transmission.

During our stakeholder meetings WebRTC was brought up as a strong candidate for an open technology that a solution could be based on.

WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs.www.webrtc.org

In connection with WebRTC W3C and IETF are working on JavaScript APIs, standard HTML5 tags and underlying communication protocols for setup and management of a reliable communication channel between web browsers. So certainly WebRTC is well on its way to fullfilling the open standards part of the requirements. Furthermore, the basic WebRTC technology in itself is open source and there are several open source projects, like OpenRTC and easyRTC building on top of the technology. But before jumping to conclusions some things need further investigation:

  • WebRTC is currently only directly supported in Chrome and Firefox browsers. There are extensions for making it work in other browsers but the status of these is unclear. It is also unclear when/if the other browsers (IE, Opera, Safari etc.) will support WebRTC directly.
  • On mobile platforms WebRTC is directly supported on Android and iOS. What happens with other platforms, Windows Phone most prominently, needs to be clarified.
  • WebRTC is basically a peer-to-peer concept. Support for multi party communication (one-to-many, many-to-many) needs investigation. See for instance: webrtcH4cKS: ~ WebRTC beyond one-to-one communication.

Notes: Another form of communication raised by stakeholders is the basic ability to attach a note to any information resource. This could for instance be in the form of a clinician attaching a note to particular measurement results - stating special circumstances orally conveyed by the patient. Or it could be clinician to clinician notes on things to be particularly aware of - for instance that the patient gets easily agitated. This type of functionality could call for a separate data service with notes referencing uniquely identified resources.

Other communication functionalities: Field studies and interviews in particular concerning the telemedical services offered to women with complex pregnancies in the Central Denmark Region have produced the following candidates for further functionalities. Again, integration with existing systems and BYOD possibilities becomes essential for the functionalities to be valuable:

  • Patient Forum / integration with social networks
  • e-learning platform holding information, video clips, links to other resources, guidelines, manuals etc on both technical and clinical issues relevant for the patient.

Calendars and planning

15)
The ability to create and share appointments and generally view planned and recorded events in the form of a calendar. As with notes and messaging (see above) these functions have less value, if they are implemented isolated inside a standalone telemedical system. Towards the patient the BYOD line of thought and exchange/integration between the system and the patient's existing systems/apps becomes central. Towards the clinicians integration with EHR, care plans, administrative systems etc. must be dealt with.

In this context we propose to explore the HL7 FHIR resources addressing Scheduling / Ordering and Workflow Management dealing with appointments, appointment responses, schedules, encounters etc..

In relation to our core telemedical functionality there is one particular area that needs further exploration, namely what in current OpenTele context is termed monitoring plans. As mentioned here Continua specify that patients can view and be reminded of questionnaires to fill out through the AHD retrieving an atom feed list of questionnaires to be completed and as such this list of questionnaires to be completed may be seen as constituting implicit monitoring plan information. However, there is no corresponding mechanism specified by Continua in relation to “measurements to be completed”. In current OpenTele planned measurements are part of questionnaires, and could thus be integral in the questionnaires to be completed feed. However, this is does not necessarily constitute a standardised solution to the issue in general. Also. looking towards FHIR it is unclear how to realise planned, recurring events like measurements to be taken. In conclusion: This needs further investigation and trial implementation.

Administration, self service and master data

16)

It has been obvious from discussions with stakeholders that there is a need for integrating OpenTele - and telemedical solutions in general - with already existing patient administrative systems as well as with clinical user administration systems. Regarding the latter, integration with existing ADFS (Active Directory Federated Services) is very likely part of the solution. In this context a security component that enables clinicians to authenticate against a SAML identity provider has been implemented for the existing OpenTele17). Here OpenTele gets all user information from the identity provider during authentication and thus utilises the existing central administration of clinical users (besides that, the use of SAML enables web based single-on). However, stakeholders have also pointed out that it's essential that systems like OpenTele work across sectors - regional and local - and it therefore needs to be further explored how user administration can be made to work in such a setting and not least how solutions can be standardised and shared.

With regards to patient administration hospitals already employ such systems and in municipalities there will also typically be components in use for the administration of citizen information. Again, a solution that only works in hospital settings will not suffice and thus a more general, standardised interface solution has to be found. In line with our specific principles we propose to look towards HL7 FHIR, specifically the attribution part of the administration resources. This part addresses patients as well as patient relatives. In interfacing with the already existing systems we propose the implementation of transformational services that wrap interfacing with legacy and expose a FHIR interface towards the telemedical solution - see integration with legacy and non-standard components under specific principles.

18)

Logistics, asset management and tech support

19)

In the vast majority of telemedical systems there is a need for managing the physical hardware in use. That is monitoring, tracking and keeping an overview of the status and whereabouts of individual measurement devices, tablets etc. and if they for instance are part of a pre-configured kit or package. This is often referred to as asset management. The existing OpenTele includes functionality along these lines, but from our stakeholder interviews we gather that this module is in little or no use. Furthermore, there seems to be consensus amongst stakeholders that

  • Asset management should be taken care of through separate components and services.
  • The currently built-in OpenTele functionality for managing monitoring kits should be discontinued.
  • OpenTele should interface with existing asset management systems

It should be noted that the latest version of FHIR includes resources for the devices and their characteristics, operational status and capabilities. It needs to be further explored how this can be put to use in integrating with existing asset management systems with particular focus towards adapting to the work flows between clinical staff, operational IT staff and potentially third party telemedical logistics providers.

Related to the topic of asset management is technical support for patients using different configurations of hardware of software for remote monitoring and communication with clinicians. In this context a stakeholder specifically raised the need to support healthcare professionals ability to see status of technical support tickets for individual patients. Potentially this could be enveloped via FHIR Communication resource, but this needs to be further explored.

Bring Your Own Device

Supporting scenarios where patients can bring their own devices into telemedical use is a recurring and important topic amongst almost all OpenTele stakeholders. Stakeholder input has revealed two basic scenarios that need further investigation:

  • Citizens using own devices as part of prescribed telemedical treatment. First step could be basic questionnaires shown on citizens own devices.
  • Citizens doing measurements on own accord. Supporting the ability to share such data with clinicians. Could entail bridging from e.g. Endomondo to CDA. Possibly entails separate services for assessing the quality of the data.
opentele3/ot3_to_be_architecture.txt · Last modified: 2018/12/12 13:27 (external edit)