Platform and data access

HeartAI provides a variety of platform environments that are suitable for differing remits and use cases. HeartAI administrators and developers often interact with internal HeartAI platform environments and backing services such as data servers, message servers, and logging, monitoring, and observability systems. HeartAI end-users typically interact with application and service endpoints. Access to HeartAI services, products, and technologies may be requested through various channels, often with the support of automated processes to access and interact with these environments. Some services require more specific access processes, such as access to endpoints within South Australian Government digital environments. In addition, access to health system information is typically governed by policies requiring users to be appropriately credentialed.

This policy provides formalised guidelines to access HeartAI platform environments and information systems and should be used as a reference to understand responsibilities and obligations when interacting with these environments

Policy

  1. Overview
    1.1. HeartAI provides a variety of platform environments that are suitable for differing remits and use cases.
    1.2. Access to HeartAI services, products, and technologies may be requested through various channels, often with the support of automated processes to access and interact with these environments.
    1.3. Some services require more specific access processes, such as access to endpoints within South Australian Government digital environments. In addition, access to health system information is typically governed by policies requiring end-users to be appropriately credentialed.
  2. Platform environments
    2.1. HeartAI generally provides the following platform environments:
    2.1.1. Cloud infrastructural environments such as virtual machines.
    2.1.2. Cloud management environments such as Azure Portal.
    2.1.3. Operational orchestration environments such as Red Hat OpenShift.
    2.1.4. Identity and access management environments such as Keycloak.
    2.1.5. Logging, monitoring, and observability environments such as Prometheus, Grafana, Kiali, and Kibana.
    2.1.6. Security operations environments such as Red Hat Advanced Cluster Security.
    2.1.7. Deployment management environments such as Argo CD.
    2.1.8. Data server environments such as Azure Database for PostgreSQL.
    2.1.9. Data server management environments such as pgAdmin4.
    2.1.10 Service endpoints such as Scala and Python web services.
    2.1.11 Application endpoints such as Shiny server.
    2.1.12 Source code management environments such as Git and GitHub.
  3. Access to platform environments
    3.1. Access to platform environments is typically documented on the HeartAI website and HeartAI administrators and developers should continually maintain this documentation. Users should contact HeartAI administrators and developers if they require any information. Often, approaches to access platform environments are automated if the user has a baseline identity that is accepted within a corresponding HeartAI deployment. Currently, HeartAI primarily supports internal HeartAI identities in addition to SA Health Health Active Directory (HAD) identities.
    3.2. If the user does not have a baseline identity, the user may request access by coordinating with HeartAI administrators. If this also requires access to a South Australian Government digital environment the user may additionally be required to coordinate with corresponding South Australian Government organisations for the application of appropriate credentialing processes.
    3.3 Access to these environments is governed by HeartAI policies and any applicable state and federal laws, policies, regulations, and compliance standards. The user must understand and follow these obligations when accessing HeartAI platform environments.
  4. In relation to the ongoing review of this policy:
    4.1. This policy should be reviewed at least every 6 months. This review should assess the appropriateness of the existing policy, and should propose any modifications or extensions to the policy where needed.
    4.2. Modifications or extensions to this policy should be reviewed and approved by corresponding governing authorities.
    4.3. This policy welcomes suggestions and feedback.
  5. In relation to the governance and compliance of this policy:
    5.1. This policy must be understood and agreed to by HeartAI administrators and developers before the approval of access to HeartAI platform components.
    5.2. Where this policy does not provide a specification to, or conflicts with, a mandated SA Health or SA Government policy, the existing SA Health or SA Government policy will take precedence. HeartAI administrators will resolve policy deficits by approved modification or extension to HeartAI policy.
    5.3. HeartAI administrators are responsible for ensuring that this policy is compliant with SA Health and SA Government policies.