Create diagram with Layered view

[dkapitan]

I would be happy to have a go at creating a diagram of the diagram of the layers to be used here.

Just wanted to check whether it is helpful to do so using the Archimate standard as follows:

• Annotation Layer:

  • Technology Artifact: physical format of the data. The passive structure, including composition in terms of Bundles could be visualized like this
  • Technology/Application Functions/Nodes/Services: we can explicitly visualize how artifacts can be transformed into different formats/representation without loss of information in a diagram like [this]9https://archimatetool.gitbook.io/quick_guide/archimate-technology-layer/behavioral-concepts). The different implementation stack can be visualized as different nodes

• View Layer:

  • Application Data object: the definition of the view itself
  • Application component: View Runners as the different implementations

• Analytics Layer:

  • Examples of workflows, e.g. running an SQL query, feed into BI tool, train a ML model

Please let me know what you think and I should be able get out a first version in a matter of days.

[bkaney]

Awesome, here was my very early start at this, happy to share the Miro if you want:

[bkaney]

FWIW, we will likely change "Annotation Layer" to "Data Layer" see: https://chat.fhir.org/#narrow/stream/179219-analytics-on-FHIR/topic/Implementation.20Guide.20UX

[dkapitan]

@bkaney Here is my first go at it. Let me know (and be brutally honest) whether this is helpful. I was trying to scratch my own itch, since I needed to specify in more detail how the SQL-on-FHIR stack would play out in the project I am working on.

I was trying to have a bit more details to illustrate the different options that there are (also see https://github.com/FHIR/sql-on-fhir-v2/discussions/75). The diagram now shows the most likely scenario's but there are a couple more. For example, with a duckdb runner you can work on a file-based data layer and even on some RDBMS data layer (PostgreSQL integration). But I think the most important thing is to have a visual overview of the description of the layers, otherwise the visual gets too busy. At a later stage, we could add similar layered views for each specific use-case / runner implementation.

I have made this using Archi, the source code is here.

[bkaney]

This is great! I think your nice details here could be interpreted as part of the spec (and not as examples). I wonder if we could try out a version that is a bit more simplified and abstract; perhaps a summary of each layer: 1) what does the layer do, and 2) what are the use-cases of the layer

What do you think?

[dkapitan]

Happy you like it, and have actually grown to like Archimate for this type of work. Indeed what you can do is create different views on the specifcation:

• A very abstract one, like your Miro, explaining the high-level spec
• Details per layer (as specification)
• Details per use case

I saw you took up the helm for the UX part of the IG, happy to help and contribute. Am quite tied up for the coming days, will pick it up after that.

[dkapitan]

@bkaney Just wanted to check: shall a work on a separate branch and create a new PR with the diagrams + explanations? I saw the discussion on the overall structure of the pages, so please let me know what structure to follow.