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
To understand how this work has been shaped it is important to take a look at the page on scope, goal and process.
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.
In line with our overall goals we try to follow three overall strategies in the design of an OpenTele3 architecture:
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:
This amongst others means that we encourage:
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.
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:
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:
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:
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:
If we take a peek inside a single service we propose an OpenTele3 service architecture following this scheme:
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
There are still a number of things to consider:
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:
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:
… towards a componentisation that can conceptually be depicted through this illustration:
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:
And, in brief summary, the functionality supporting the production of this data we describe as follows:
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:
One further strategic focus area should be added as a cross-cutting concern:
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:
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:
Zooming in on the AHD to WAN device to repository part this implies an architecture that can be depicted as follows:
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:
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:
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:
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.
Expanding on stakeholder input there are at least four different basic roles related to questionnaires:
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.
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:
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.|
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:
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
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:
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 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.
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.
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
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.
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: