Input From Stakeholders

This page is part of the OpenTele3 architectural design efforts.

When we initiated these efforts 4S invited all interested parties to participate and contribute to the formation of a OpenTele 3.0 software architecture. Public as well as private parties have been included in this process and so far it has taken the form of a series of meetings where 4S representatives have conducted meetings with individual stakeholders. This page represents a condensed and loosely categorised summary of output from this meetings.

So far we have conducted meetings with representatives from:

• InTeleCare4U [I4U]
• Silverbullet [SB]
• NNIT [NNIT]
• IBM [IBM]
• NextStep Citizen [NSC]
• Region Hovedstaden [RH]
• Region Midtjylland [RM]
• Region Nordjylland [RN]
• National Sundheds-IT [NSI]
• MedCom [MedCom]

The sequence of the topics is not intended to suggest a prioritisation. In square brackets we have tried to capture which stakeholders explicitly made a point about which issues. This does not mean that other stakeholders may not also have touched on an issue or have the wish prioritise it.

• OpenTele should produce documents for XDS [RH]
• OpenTele WAN interface should conform with Continua Design Guidelines [RH]
  • OpenTele client/server communication (WAN-IF) should conform with standards and guidelines specified by Continua Design Guidelines.
• Use HL7 FHIR outside Danish reference architectures [RH, NSC, MedCom, RM]
  • Where Danish reference architectures and/or Continua doesn't say anything experiment with using FHIR where possible
• Integration with Danish National Service Platform [RN]
  • Further integrate with services like Behandlingsrelation and Samtykke where and when appropriate.

• Observations - searching and subscribing [RH]
  • Need to continuously save incoming data in easily/fast searchable format
  • Should have a standard for subscribing to incoming measurements
• Observation assessment - as a separate service/component [MedCom, RM, RN]
  • Should isolate (safety) critical components
  • Healthcare professionals should not need to look at normal data - i.e. data within set thresholds
  • Support for patients seeing own measurements [RH]

• Asset management - managing measurement kits/devices [RH, RN]
  • Separate module/functionality
  • Current OpenTele module is in a bad shape
  • Interface with/for existing asset management systems
  • Healthcare professionals need to see types of devices associated with a patient
• Bring Your Own Device (BYOD) [RH, RM]
  • 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.
• Integration to support systems [RN]
  • Support healthcare professionals ability to see status of technical support tickets for individual patients

• Frontends / web portals as independent/separate components [RH]
  • Support for multiple types of clinicians and/or patients web portals
  • Portal/frontend functionality should be decoupled from OpenTele servers
• Visual integration [CGI]
  • Standardised way of visually integrating telemedical views in EHR and other existing healthcare systems. Potentially based on HL7 CCOW

• Questionnaire Editor as a separate component [RH, RM, RN, MedCom]
  • 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 [RH, RN, MedCom]
  • Based on Danish profile of QFDD
• Generic questionnaire presentation component [RH]
  • For instance an HTML5/JS based component for presenting HL7 QFDD based questionnaires
• A QRD builder [MedCom]

• Video [RH, RM, NNIT]
  • Basic requirements / wishes
    • Open standard for video communication (WebRTC)
    • No requirements regarding special software on client
    • Establishing citizen/clinician connection: A dynamic and secure context. A consultation?
    • open source
  • Technological considerations:
    • Existing, closed source, solution based on Vidyo.
    • WebRTC is a strong candidate for an open video technology
    • MedCom videoconferencing (VDX) (http://www.medcom.dk/dwn7117)
• Patient/clinician messaging as separate functionality/modules [RH]
  • Patient ↔ clinician messaging: A general, non-OpenTele specific, solution
  • What are the standards and how about security?
  • Example security consideration: young people with diabetes communicate with named clinicians about things like sex and alcohol. At other times they communicate about more generic/general non-sensitive issues.
• Notes - as a separate module/component [RM]
  • Small notes sharing information between patient and clinician or sharing information between clinicians
  • Varying visibility
  • Can be attached to patient / patient information
• Information about “egenmestring” [RM]
  • Sharing information about how to cope with diagnosis/disease and similar

• Calendar for creating and sharing of appointments [RM]
• Treatment plans [CGI]
  • Template treatment plans, that instantiated into concreate plans for individual patient.
  • Contains meausurements, questionnaires and other patient targeted artifacts
• Integration with care plans [SB]

• User administration [RN, SB]
  • Administration across sectors (regional and local)
  • Healthcare professionals and citizens
  • Integration with ADFS (Active Directory Federated Services) part of solution, but have to integrate with regional and local services.
• Integration with patient administration systems (PAS) [SB]
• Patients self service [RH]
  • Patient establishes personal data profile
  • In relation to BYOD: entry point for activating/deactivating device
  • Based on NemID, but possibly easier authentication after first logon.
• Relatives [RN]
  • A national component/service for information about relatives
• Improve integration with patient master data [RN]
  • Update when people e.g. move or die