Gazelle updates to support Actor and Transaction use in publication

[JohnMoehrke]

No description provided.

[costateixeira]

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]

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]

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]

(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]

(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]

(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]

(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]

Until all these comments are sorted out, the text for Appendix A has been updated to read: Appendix A: Actor Descriptions IHE Actor definitions are maintained in Gazelle Master Model and can be accessed under the menu <https://gazelle.ihe.net/GMM/tf/actor/listActors.seam> TF / Actor Browsing. This page lists the actors of all IHE Domains. Results can be further refined by IHE Domain, actor keyword or actor name. Learn more about Actor Browsing in Gazelle Master Model and additional information Gazelle Master Model provides for IHE Actors on the <https://wiki.ihe.net/index.php/Gazelle_Browsing> Gazelle Master Model Browsing IHE Wiki page. The same changes will be made to Appendix B. The other alternative for now, would be to point back to the PDF file that currently exists (but would be updated to reflect current GMM data, as what the PDF has now is old). From: lynnfel ***@***.***> Sent: Thursday, March 11, 2021 10:02 AM To: IHE/publications ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [IHE/publications] Gazelle updates to support Actor and Transaction use in publication (#78) (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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#78 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGDULOOMLHJM2O6UQURFEITTDDLPZANCNFSM4YZWYVKA> . <https://github.com/notifications/beacon/AGDULOKX244XKS3E2K7AELTTDDLPZA5CNFSM4YZWYVKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOF57OBKQ.gif>

[lynnfel]

(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]

If we think in the future that we cannot rely on the GMM database for actors and transactions, do we need to rethink using GMM as our “repository” for actors and transactions? From: lynnfel ***@***.***> Sent: Thursday, March 11, 2021 9:59 AM To: IHE/publications ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [IHE/publications] Gazelle updates to support Actor and Transaction use in publication (#78) (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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#78 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGDULOOMKS6RXWMI32MVCXLTDDLFBANCNFSM4YZWYVKA> . <https://github.com/notifications/beacon/AGDULOOUSTRQC43GZTH227TTDDLFBA5CNFSM4YZWYVKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOF57NOTA.gif>

[lynnfel]

(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]

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

[lynnfel]

(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]

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

[stl-steve-moore]

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.