Stream: ihe
Topic: IHE Profile Structure
Jose Costa Teixeira (Feb 27 2020 at 13:00):
We should have our Actors and Transactions as FHIR resources. Not sure where decisions last landed, but I think:
Transactions - PlanDefinition
Actors - Device? CapStatement?
John Moehrke (Feb 27 2020 at 13:56):
I have been creating a CapabilityStatement for every Actor. This seems clear. One might have other CapabilityStatement for various options or other reasons, but there should be at-least ONE
John Moehrke (Feb 27 2020 at 13:58):
I expect at-least ONE StructureDefinition for the "Message Encoding" sub-section in each IHE Transaction. Given that an IHE Transaction can be made up of 1..* messages. An important point is that the IHE Transaction structure is made up of three subsections, for which messge encoding is just one of them. The oters are "Trigger Event" and "Expected Action". These other two sub-sections don't have an obvious conformance resource.
John Moehrke (Feb 27 2020 at 14:00):
The Transaction layout is being worked by some using Gherkin-- Given/When/Then which is much like Trigger-Event/Message-Encoding/Expected-Action. There is experimentation in IHE on two projects
John Moehrke (Feb 27 2020 at 14:00):
I think there is also interest in using other FHIR resources, such as Test Scenario
John Moehrke (Feb 27 2020 at 14:01):
I don't think that Plan Definition is proper, but I just haven't thought much about it
Jose Costa Teixeira (Feb 27 2020 at 15:08):
I think PlanDefinition is proper :). Name is misleading, I think. But that is the place to say "Alice says ... to Bob"
Jose Costa Teixeira (Feb 27 2020 at 15:09):
CapabilityStatement contains the specs - does it contain the Actor definition? I started with that as well, not sure where we landed
Jose Costa Teixeira (Feb 27 2020 at 15:11):
The requirements you mention for Transactions seem covered
Jose Costa Teixeira (Feb 27 2020 at 15:12):
I am prototyping adding more resource types to the BE IG, so it's good to start this discussion in parallel
Jose Costa Teixeira (Feb 27 2020 at 15:14):
My focus for now is Transaction and Examples/ Use cases (pending a change in the template)
Jose Costa Teixeira (Feb 27 2020 at 15:15):
I think we should restart some calls
Keith Boone (Feb 27 2020 at 21:33):
I disagree with using PlanDefinition for this. It's really meant to be used in a clinical context, where the plan is some sort of care/treatment plan that can be customized based on decision points. The fact that it could be used for this purpose is inconsequential. It's not really appropriate for this purpose.
Jose Costa Teixeira (Feb 27 2020 at 21:43):
I can provide the history of the discussions in a future call
Jose Costa Teixeira (Feb 27 2020 at 21:44):
I just did a search for "plandefinition workflow conformance" and I got some of the discussions around this
Jose Costa Teixeira (Feb 27 2020 at 21:46):
At the time I raised the same point - PlanDefinition seems about clinical decision. But I accepted it and have worked on that assumption
Jose Costa Teixeira (Feb 27 2020 at 21:48):
What we are missing is actors, glossary terms.
Jose Costa Teixeira (Feb 27 2020 at 21:53):
CapStatements are needed. I had a question mark because I wanted to see if we agree whether they are the actual actor definition (in the IHE sense).
Jose Costa Teixeira (Feb 27 2020 at 21:54):
If an actor has 2 capabilitystatements, then the capabilitystatement cannot be the definition of the actor, right? An actor cannot have 2 definitions
Jose Costa Teixeira (Feb 27 2020 at 21:55):
Perhaps we need a 3rd CapStatement to actually define the actor
Keith Boone (Feb 28 2020 at 20:08):
I use capability statements to define actors. A transaction imposes constraints on what needs to appear within a transaction on both sides of the transaction. As John has noted, these could actually be described as constraints on the actor supplied CapabilityStatement Resource.
Jose Costa Teixeira (Mar 04 2020 at 10:20):
I think we just have to clarify what we do for the options.
Jose Costa Teixeira (Mar 04 2020 at 10:23):
And probably my need for actor definitions is different. What I want is a governed repository of actor definitions (independent of options).
I also want a repository of transactions (we're working on that in Belgium)
And a repository of glossary terms (will be good to see where those sit)
John Moehrke (Mar 04 2020 at 14:52):
These things will come with effort. It is not hard to solve them for ONE editor, the hard part is making it something that the organization can sustain.
John Moehrke (Mar 04 2020 at 14:54):
To that end, there are some projects that we will each taken on that solve the same kind of problem differently. This is "Trial Implementation". So I encourage a few potential solutions, when there is potential. Hence why I am encouraging Cucumber experimentation too.
Jose Costa Teixeira (Mar 04 2020 at 15:30):
Not sure we're looking at the same here.
I'd want to have a governed set of actors, that we can maintain across all editors and domains. If an actor has 1 transaction adn one option, how many CapStatements do we have? I am guessing 2 or 3.
Jose Costa Teixeira (Mar 04 2020 at 15:30):
And a governed set of transactions (as part of our architecture) - not the detailed specifications, just the repository.
Jose Costa Teixeira (Mar 04 2020 at 15:34):
Perhaps I should have started with that vision: I would want our artefacts to be governed (having them as resources will help in the publication process).
- Actors
-
Transaction definitions
** Content profiles (StructureDefs)
** Workflow profiles (PlanDefinitions) -
Glossary Terms (CodeSystems?)
- Test scenarios
- Terminologies (CodeSystems/ValueSets)
Eventually more stuff, like Actual implementations...
John Moehrke (Mar 04 2020 at 16:14):
Jose Costa Teixeira said:
Not sure we're looking at the same here.
I'd want to have a governed set of actors, that we can maintain across all editors and domains. If an actor has 1 transaction adn one option, how many CapStatements do we have? I am guessing 2 or 3.
IHE does have that now.. The mechanics are just not well understood and well used... So, yes there is room for improvement and I very much agree. However in the context of a specific PROFILE the CapabilitySttement is the right way to give profile specific context. These are not two different things
Jose Costa Teixeira (Mar 04 2020 at 16:44):
I think most of what I indicated is manual and copy-paste.
And in my vision, the different profiles will build up those assets - if a profile adds a term, or an actor, etc., I want the rest to be automated - publication, maintenance...
John Moehrke (Mar 04 2020 at 16:51):
YES!!!! you do know that Mary is in the process of automating this... and getting it html published... but yes the IG build should enhance this even more
Jose Costa Teixeira (Mar 04 2020 at 17:05):
yep. hence my points. we need a bit of a revolution there, and that should be based on governed assets like FHIR resources.
I expect an Author to need to provide all the input (in a structured format) so that Mary just has to press a button.
Keith Boone (Mar 04 2020 at 20:48):
My thoughts on this: A CapabilityStatement is a statement of what a application or system supports. A claim by an application or system to support an Actor reflects what should be seen in a CapabilityStatement, as does a separate claim to support a particular option for an actor. Thus, each is a set of requirements associated with an Actor, or an Option, and can be reported in a separate set of constraints on the CapabilityStatement resources exposed by that application or system. They can be expressed as profiles on an Instance (CapabilityStatement.kind="instance"), and represented as independent capabilities (in a CapabilityStatement where kind="capability"). The former can be used for validation, the latter for expression of the capabiltiies, and the former (profiles) can be crafted from the latter.
Keith Boone (Mar 04 2020 at 20:50):
I've got some stuff I'm playing around with that can automate generation of an IG that might be worthy of discussion on an IHE FHIR workgroup call.
Jose Costa Teixeira (Mar 04 2020 at 22:02):
Keith Boone said:
I've got some stuff I'm playing around with that can automate generation of an IG that might be worthy of discussion on an IHE FHIR workgroup call.
Definitely worth discussing.
I think we need to pool these efforts. Personally I have looked at
- editing pages in Word
- generating our diagrams from the resources (which is why I want to clarify the actors /transactions thing)
- forcing some content layout (we don't want people to define their own menu structure)
John Moehrke (Mar 05 2020 at 13:53):
Agree, and I ask of the IHE-FHIR workgroup members, for which you two are a part, to gather your list of tasks so that we can create a work plan. So please take this topic to the IHE-FHIR workgroup
Jose Costa Teixeira (Jan 25 2021 at 06:06):
Reusing this old thread. I was postponing it, but now I think I should look at someone else's XSLT for automating the page generation :)..
@Keith Boone can you point me to your IG that had all those transformations?
Jose Costa Teixeira (Jan 25 2021 at 06:06):
I even think I made a nice diagram for your model (as I understood it), but I can't find it. So I need to see that wizardry again
Jose Costa Teixeira (Feb 25 2021 at 17:50):
While that is in the works, another question:
Gherkin - I think that conceptually, Gherkin corresponds to (a computable expression of) Acceptance Criteria
which means that our model, to contain gherkin, would comprehend the notion of Acceptance Criteria.
Jose Costa Teixeira (Feb 25 2021 at 17:50):
Right?
Jose Costa Teixeira (Feb 25 2021 at 17:50):
Thoughts?
Carl Leitner (Feb 25 2021 at 17:50):
that sounds right, but I have no practical/hands-on experience with Gherkin
John Moehrke (Feb 25 2021 at 18:29):
yes. but I am not clear what the alternative is that you are trying to scope out.
John Moehrke (Feb 25 2021 at 18:30):
the current use of Gherkin is simply as a means of expressing the expected tests that should be designed for the IHE-Connectathon. It is not a replacement for SHALL language or structureDefinitions. I expect the Gherkin will leverage the structureDefinitions at points of conformance checking.
Jose Costa Teixeira (Feb 25 2021 at 18:59):
No alternative, I just want to see what it is so that it fits in a structured model (and therefore in a more industrialized process).
If they are acceptance criteria, they are related to requirements/user stories. The link to Connectathon is not a direct link, I think.
Example:
"Given a patient exists on the system, when I try to create a new patient with the same ID, this should fail"
or
"Given a patient exists on the system, when I submit an updated patient record, then the server should result ..."
- these are Acceptance criteria, which belong to a User Story; this User Story is in the origin of Conformance Artifacts including the StructureDefs. In a Connectathon you may apply a test plan which includes the tests for a given set of criteria
Todd Cooper (Feb 25 2021 at 19:30):
In the Gemini MDI project, we ended up utilizing Cucumber/Gherkin as a handy way of getting more precision in the story / use case / scenario specifications associated with an IHE Profile; however, we found that once you get much beyond that (e.g., linking them to test platforms, as Gherkin was designed to do), you quickly end up with more complexity than needed or wanted (esp. on the part of the SMEs describing the scenario logic.
So we will be using ReqIF (OMG spec supported by quite a few requirements management tools) to represent both Gherkin-based requirements as well as all other requirements, including from standards referenced in the IHE Profile.
Stay tuned ... but we think it will get us to where we need to go, namely a CA report of sufficient rigor that it can be directly included in regulatory submissions.
Jose Costa Teixeira (Feb 25 2021 at 20:05):
I was not going as far as interoperable requirements. I'd be glad to have clearly identified requirements :)
Todd Cooper (Feb 25 2021 at 20:09):
LOL ... In our final review (last week?) of the strategy we'll take, we added "Requirements Interoperability" to that particular slide ... wish us luck!
John Moehrke (Feb 25 2021 at 20:15):
QRPH tried to use Gherkin as their requirements language. Two problems, (1) although it should be easer given the BDD ideal, but turns for the kind of requirements IHE focuses on it is not always that much more clear. We already have the concepts of Given/When/Then built into Volume 2 in our Trigger/MessageEncoding/ExpectedActions.... and (2) the governance of IHE says that we use the normative words "SHALL/SHOULD/MAY", so a specification without those words will be seen by many as a NULL specification.
John Moehrke (Feb 25 2021 at 20:16):
hence why we are just looking at filling the gap between Interop spec and testing; and for that space Gherkin is a good tool.
John Moehrke (Feb 25 2021 at 20:17):
I am not a fan of trying to change the tires while the buss is rolling down the highway; say nothing about changing the oil too.
Jose Costa Teixeira (Feb 26 2021 at 08:00):
Todd Cooper said:
LOL ... In our final review (last week?) of the strategy we'll take, we added "Requirements Interoperability" to that particular slide ... wish us luck!
Ok, then I correct my statement - i WAS not going as far as interoperable requirements. When you have something, I'll be happy to see if we can take those files and put them in the publication somehow (creating a section for requirements?..)
Jose Costa Teixeira (Feb 26 2021 at 08:02):
John Moehrke said:
hence why we are just looking at filling the gap between Interop spec and testing; and for that space Gherkin is a good tool.
At this moment, I'm trying to see what that gap is. Not how big it is, or which tool covers it, but what that gap is named. I think it is Acceptance Criteria
Jose Costa Teixeira (Feb 26 2021 at 08:04):
John Moehrke said:
QRPH tried to use Gherkin as their requirements language. Two problems, (1) although it should be easer given the BDD ideal, but turns for the kind of requirements IHE focuses on it is not always that much more clear. We already have the concepts of Given/When/Then built into Volume 2 in our Trigger/MessageEncoding/ExpectedActions.... and (2) the governance of IHE says that we use the normative words "SHALL/SHOULD/MAY", so a specification without those words will be seen by many as a NULL specification.
Well, that sounds like we're trying to fit a language without seeing where it should go. A user story is different from Acceptance Criteria, and an Acceptance Criteria is not a technical specification.
Jose Costa Teixeira (Feb 26 2021 at 08:06):
John Moehrke said:
hence why we are just looking at filling the gap between Interop spec and testing; and for that space Gherkin is a good tool.
From what I know today, Gherkin is a good tool IF we are talking about (Acceptance Criteria/?). That is what I am trying to find out.
Jose Costa Teixeira (Feb 26 2021 at 08:09):
John Moehrke said:
I am not a fan of trying to change the tires while the buss is rolling down the highway; say nothing about changing the oil too.
Yes, so we have a shiny new bus in the workshop, we can mess with that at will. And if your bus is rolling down the highway, and I understand we cannot slow down the bus, if you need to change the oil, what I'm trying to avoid is that you put gas in the oil compartment.
John Moehrke (Feb 26 2021 at 13:02):
the use of Gherkin in IHE today is experimental, and may not be found to be useful. There is the use that I describe in the IPS, CCG, and MHD profiles. It is very minimal, it is an appendix. It is just as likely to be found unnecessary as it is to be found a distraction.
Jose Costa Teixeira (Feb 26 2021 at 15:09):
I'm glad I asked then :)
John Moehrke (Feb 26 2021 at 15:51):
I hope I had not misdirected you to thinking it was more common when I asked if there was a way to have the IG publisher display .feature files. I asked only to see if there was something already done that can be directed to pull in TEXT files and display them inline, possibly as code blocks, etc.
John Moehrke (Feb 26 2021 at 15:52):
@Keith Boone has some gherkin rendering in his SANER project.
Jose Costa Teixeira (Feb 26 2021 at 19:06):
Yes, we can display text files (or markdown, or diagrams). For that we need to build the template (not difficult) and for building the template we need to see what that template is about - i.e. we want to put text in what "type" of page? in the structuredef intro? in any random markdown? Or as part of a "requirements" section? Or as part of the "test" section? In either case, we need to know which text to put where.
I'm glad the call today helped clarify that.
John Moehrke (Feb 26 2021 at 19:19):
you are a few steps beyond what I need today. I just need a way that a markdown page in an IG can include text from a named file. That named file happens to be a .feature file. But for my needs it could be anything. The alternative I have is to copy-paste it into the markdown, and thus have two instances of the text.. i am trying to avoid two copies of the same text.
Jose Costa Teixeira (Feb 26 2021 at 19:31):
you could try to {% include yourfile.feature %}inside your markdown
Jose Costa Teixeira (Feb 26 2021 at 19:31):
yourfile.feature would need to be in the ig's input\images folder
John Moehrke (Feb 26 2021 at 19:45):
I probably did something wrong, but that didn't work. I think I followed instructions... this filename is right, and it exists in the images-source
Jekyll has failed. Complete output from running Jekyll: ←[31m Liquid Exception: Could not locate the included file 'create-simple-weight.feature' in any of ["C:/Users/john.moehrke/Git/MHV-PGHD/temp/pages/_includes"]. Ensure it exists in one of those directories and, if it is a symlink, does not point outside y (02:55.0922)
John Moehrke (Feb 26 2021 at 20:44):
didn't help to make the file a .txt file.
Jose Costa Teixeira (Feb 26 2021 at 21:33):
it's a shot in the dar.. do you have a repo (i'm lazy to setup something from scratch)?)
Last updated: Apr 12 2022 at 19:14 UTC
