Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gazelle updates to support Actor and Transaction use in publication #78

Open
JohnMoehrke opened this issue Mar 8, 2021 · 15 comments
Open
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@JohnMoehrke
Copy link
Contributor

No description provided.

@costateixeira
Copy link
Contributor

Is this a one-off extraction of actors and transactions from Gazelle? Or do we want to make Gazelle a Master Data provider for Actors and Transactions (why?)

@JohnMoehrke
Copy link
Contributor Author

This is advancements that might be needed to the Gazelle tool to support the use in the html publications. The html publications already use the Gazelle Actor and Transaction registry.
See https://ihe.github.io/publications/GeneralIntro/ch-A.html
and https://ihe.github.io/publications/GeneralIntro/ch-B.html

There was some things observed about the Gazelle UI and the administrative behaviors of Gazelle that Lynn wanted to identify as improvement opportunities. Lynn will fill in the details.

@lynnfel
Copy link
Contributor

lynnfel commented Mar 11, 2021

In the comments that follow, I will identify items for consideration.

(1). In the intro to General Introduction Chapter A and B, we say, "IHE Actor definitions are maintained in Gazelle and can be accessed via the Actor Browsing page." The same thing is written for the transaction appendix.

==> We (IHE) in our documentation should never say "Gazelle". The term is too imprecise. In this case, we should say "Gazelle Master Model."

==> Instead of saying "...can be accessed via the Actor Browsing page", consider saying "...can be accessed under menu TF / Actor Browsing..."

As a side note, that same "TF" menu is available on any instance of Gazelle Test Management (note the term). These are used to manage connectathons, eg https://gazelle.iheusa.org/gazelle-na/home.seam OR https://gazelle.ihe.net/EU-CAT/home.seam. I'm not suggesting we include that detail in the explanation, but I want this TF publication audience to know this.

@lynnfel
Copy link
Contributor

lynnfel commented Mar 11, 2021

(2) On the home page of Gazelle Master Model (where we are telling people to go for Actor & Transaction definitions, https://gazelle.ihe.net/GMM/home.seam, the login option at the upper right of the page implies that a user has to log in. In fact, the contents of the TF menu (where we want people to go) are accessible without logging in (by design).

Because there will be more traffic here, people will be creating an account (because the UI suggests you can/should do that). In fact, only admin users are given access to GMM (eg TPMs and Mary). This is also by design. We will be refusing people accounts, and that will be confusing. Even if you write in the General Intro that people do not have to log in to access details, people will try to do it anyway.

@lynnfel
Copy link
Contributor

lynnfel commented Mar 11, 2021

(3) Here is suggestion from Steve Moore:

We would be better served to have a job that runs every night to pull what is needed out of GMM and make web pages that are controlled by the committees.

At some point in the future, Kereval may decide to change the UI or name of the tool, and documentation that relies on their UI will break. There is also the risk of relying on the GMMdatabase, but that is more stable.

@lynnfel
Copy link
Contributor

lynnfel commented Mar 11, 2021

(4) In the GMM database, each transaction has a "Status" field. This is a required field in the GUI, but the GMM DB design does not follow the TF model. We do not have Final Text or Trial Implementation Transactions, we have Final Text and TI Profiles.

@lynnfel
Copy link
Contributor

lynnfel commented Mar 11, 2021

(5) In GMM, the Transaction detail includes a section to link to "Standards". This is not a required field, so some transaction have them, and some do not. There is a separate menu "Standards" in GMM that contain entries that can be linked to transactions.

The problem is that this feature was introduced in GMM, but it was not maintained over time. Look, for example, at DICOM based transactions eg RAD-5. They point to DICOM 2011. (however the 'standard' doesn't link directly to DICOM.

It is a mess that is now more visible. Any inaccuracy casts doubt on other contents.

@MaryLJ
Copy link
Contributor

MaryLJ commented Mar 11, 2021 via email

@lynnfel
Copy link
Contributor

lynnfel commented Mar 11, 2021

(6) Each Transaction entry in GMM has a field for "TF Reference". This is not a required field. Historically, TPMs could put a TF reference in there (eg ITI TF-2a: 3.7), but it is a free-text field today. If ITI really really things that our URLs to transaction text will never change, we could paste them into ITI transactions.

We should consider the user experience (where the contents of this field might contain a URL, or a traditional TF reference, or nothing).

@MaryLJ
Copy link
Contributor

MaryLJ commented Mar 11, 2021 via email

@lynnfel
Copy link
Contributor

lynnfel commented Mar 11, 2021

(7) Related to (6), each Transaction entry in GMM has a field for "TF Section". For some Transaction, I suspect that Named Destination links were put there. Are they still there for some? I don't know.

The same problem identified above (maintainability) exists here.

Why have both "TF Reference" and "Section".

Again, these are issues with GMM, but now we are telling our audience to look there

@lynnfel
Copy link
Contributor

lynnfel commented Mar 11, 2021

Mary... I am gathering issues here. I am not asking you to make any changes today.

@lynnfel
Copy link
Contributor

lynnfel commented Mar 11, 2021

(8) In GMM under the TF menu, our General Appendices are pointing people to Actors and Transactions.

There is a lot of other good stuff under the TF menu (Profiles, Options, more). Our TF General Appendices don't tell people to look there, but they could. There's nothing to "hide" there (well, maybe links to out-of-date standards), but, again, its a visibility thing we should consider.

You might point to my laundry list and ask, "why didn't you raise these issues before". Fair enough. I think using a common, database-driven, source for modeling the TF is a good idea.

GMM "models" the entire TF, including profiles/actors/transactions/options . Mandatory groupings are also modeled in GMM (but they're not visible under the TF menu w/o logging in).

@lynnfel
Copy link
Contributor

lynnfel commented Mar 11, 2021

(9) Good news: Actor definitions in GMM do not have the same issues as identified above for Transactions.

@stl-steve-moore
Copy link

High level comment is that we could use the data modeled in Gazelle Master Model (GMM) as the source of truth (already your intent) and ignore the visualization provided by GMM. That means that this group would define what to display, when to display it and how to display it and would not rely on a separate application.

It also means you don't have people trying to make accounts in GMM and asking "Why doesn't my xxxx password work here?"

Lower level comment:

  1. Today, one could set up a database that is similar to the one used for Connectathon testing. That database (PostgreSQL) would run on some server that you specify and would get updates from GMM as someone enters new data. When I enter a change in a profile, that data is replicated to several databases with little or no lag (seconds, not days). If you had that database on your server, you would have a read only copy of the GMM database. You could write whatever script you wanted to pull data on whatever schedule you wanted (nightly, ....) to publish your view.
  2. GMM might have an API that you could request the data directly without a user account. If so, that is another option. It might be a SOAP API; I would prefer a REST AP
  3. Maybe you copy the database as in item Plan for common parts #1 and write a RESTful API as part of this work.

@JohnMoehrke JohnMoehrke added the documentation Improvements or additions to documentation label Mar 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

5 participants