Stream: ihe
Topic: IHE package names
Grahame Grieve (Aug 23 2018 at 00:41):
@John Moehrke I have updated the FHIR IG registry with new package names for IHE npm packages. Obviously I cannot dictate what package names IHE uses, but I do strongly recommend that IHE follows my anticipated naming convention when it produces IGs. In particular, using ihe.fhir.* leaves ihe able to produce other kind of npm packages should it want to be in the future (e.g. ihe.legacy.xds or something).
Grahame Grieve (Aug 23 2018 at 00:41):
you can see the changes here: https://github.com/FHIR/ig-registry/pull/7/commits/9694e50ed6b9d8d718020a6286c0c2cdb688bc2a
John Moehrke (Aug 23 2018 at 12:08):
so period is allowed here? Is that going to be taken away later? @Grahame Grieve
John Moehrke (Aug 23 2018 at 12:10):
Is there any reason the NPM name is not the .id value in the ImplementationGuide? So in that case today it is "IHE.MHD", but after R4 when I must change period to underbar will be "IHE_MHD".
John Moehrke (Aug 23 2018 at 12:12):
for IHE there is no need to put ".fhir." in between "IHE" and the profile name. As the Profile name must be unique across IHE, and IHE profiles are rarely dedicated to only one underlying standard. The Profile use-case comes first, then the standards to be profiled are picked based on a best-fit assessment.
Grahame Grieve (Aug 23 2018 at 20:39):
so I didn't understand any of these 3 points:
- period is used for namespacing. it's not going to get taken away
- what's this about changing? why?
- because the IHE profile can cover more than one standard, that's precisely why I suggest namespacing which .fhir., in case IHe founds other use for packages. that's why we use hl7.fhir.
John Moehrke (Aug 23 2018 at 21:36):
So, lets not worry about the period.. you say it is good, I am happy
John Moehrke (Aug 23 2018 at 21:37):
the model IHE uses that the profile name is prime. The technology chosen is later.
Grahame Grieve (Aug 23 2018 at 21:37):
so you would say ihe.mhd.fhir .... that would be ok
John Moehrke (Aug 23 2018 at 21:37):
Indeed there are profiles that orchistrate many technologies. So to have the technology first, would make this kind of hard.
John Moehrke (Aug 23 2018 at 21:37):
does .fhir need to be in there at all?
John Moehrke (Aug 23 2018 at 21:38):
what is wrong with ihe.mhd?
John Moehrke (Aug 23 2018 at 21:38):
(of course IHE needs to shout so will use uppercase)
Grahame Grieve (Aug 23 2018 at 21:39):
no, it doesn't need to be there at all. But not having if there would make it a challenge later if ihe decided that it wanted to use npm packages as a way to distribute something other than fhir packages
John Moehrke (Aug 23 2018 at 21:39):
why?
John Moehrke (Aug 23 2018 at 21:40):
ihe.xds as published using an Implementation Guide
John Moehrke (Aug 23 2018 at 21:40):
why would that need to be ihe.xds.ebRIM?
John Moehrke (Aug 23 2018 at 21:41):
we have already chosen that ihe.pdq was different than ihe.pdqv3 so logically ihe.pdqm
Grahame Grieve (Aug 23 2018 at 21:42):
why would IHE want to release other kind of packages? or why would it be a problem?
John Moehrke (Aug 23 2018 at 21:42):
there are times that we regret using 'm' for FHIR.. but it is not required. Some FHR profiles will never use 'm' they would be totally use-case driven
Grahame Grieve (Aug 23 2018 at 21:43):
that seems incompatible with 'the model IHE uses that the profile name is prime. The technology chosen is later"
John Moehrke (Aug 23 2018 at 21:43):
why is it a problem
John Moehrke (Aug 23 2018 at 21:43):
it seems that way only because the full set is not clear. In the case of PDQm, the use-case expicitly asked for FHIR.. hence it was the same use-cases with FHR.
John Moehrke (Aug 23 2018 at 21:44):
but when the new profile is NOT a exact same set of use-cases as some other... then 'm' isn't used.
John Moehrke (Aug 23 2018 at 21:45):
for example some of the content profiles coming out of PCC are one use-case with two alternatives (CDA vs FHIR-document).
John Moehrke (Aug 23 2018 at 21:46):
so that package can't be labeled with .fhir
John Moehrke (Aug 23 2018 at 21:46):
There are Radiology profiles that are DICOM and FHIR
John Moehrke (Aug 23 2018 at 21:47):
yes.. we might regret... but the guiding principle is that the use-case (need) comes first, choice of standard is part of the standards evaluation.
Grahame Grieve (Aug 23 2018 at 21:47):
I feel as though we're talking to some different perspective. when you say
some of the content profiles coming out of PCC are one use-case with two alternatives (CDA vs FHIR-document)
then i draw the exact opposite conlusion as this:
so that package can't be labeled with .fhir
Grahame Grieve (Aug 23 2018 at 21:48):
that's exactly when it woudl be most appropriate to be explicit about fhir
John Moehrke (Aug 23 2018 at 21:48):
but the IG is both FHIR and CDA
Grahame Grieve (Aug 23 2018 at 21:49):
the package is just fhir
John Moehrke (Aug 23 2018 at 21:49):
maybe I am not understanding the difference between package and IG
John Moehrke (Aug 23 2018 at 21:49):
what?
Grahame Grieve (Aug 23 2018 at 21:50):
The package is a set of FHIR artifacts that conforms to a Fhir spec, for fhir purposes.
Grahame Grieve (Aug 23 2018 at 21:50):
if IHE ever wanted to use an npm package for some other aspect of said specification, it would have be a different package
John Moehrke (Aug 23 2018 at 21:50):
so then package can't be the prime organizational structure of the IG registry..
Grahame Grieve (Aug 23 2018 at 21:51):
package can't be the prime organizational structure of the IG registry.
Don't understand since it will be
John Moehrke (Aug 23 2018 at 21:51):
IG registry is a registry of IG... right?
Grahame Grieve (Aug 23 2018 at 21:52):
yes, and the package is the technical representation of the contents of the IG for tools and registries
John Moehrke (Aug 23 2018 at 21:52):
and you are saying an IG might be composed of zero-or-more FHIR packages, and/or zero-or-more other kind of packages
John Moehrke (Aug 23 2018 at 21:53):
I don't understand this package thing. yet it is somehow driving the bus
Grahame Grieve (Aug 23 2018 at 21:55):
the package represents the implementation guide 1:1. My understanding is that an IHE profile might have a FHIR Implementation guide, but also an instantiation in another standard as well (per "some of the content profiles coming out of PCC are one use-case with two alternatives (CDA vs FHIR-document)")
John Moehrke (Aug 23 2018 at 21:56):
that is true sometimes... such as PDQ vs PDQv3 vs PDQm... but it is not required...
Grahame Grieve (Aug 23 2018 at 21:56):
which is the not required?
Grahame Grieve (Aug 23 2018 at 21:57):
what I hear is: for IHE, if the technical standard varies, this is explicit in the profile name
John Moehrke (Aug 23 2018 at 21:57):
it is not required to have independent profiles per technolgoy
John Moehrke (Aug 23 2018 at 21:57):
such as th PCC Emergency profile that has two options: CDA vs FHIR-document
John Moehrke (Aug 23 2018 at 21:58):
other IHE profiles are profiling many standards: A profile that uses FHIR, HL7, and DICOM
John Moehrke (Aug 23 2018 at 21:58):
profiles are use-case driven, not technology driven
Grahame Grieve (Aug 23 2018 at 21:59):
your communications are a marvel in non-clarity. I asked:
if the technical standard varies, this is explicit in the profile name
true? false?
John Moehrke (Aug 23 2018 at 22:00):
you are focused on one possibility, that is not the only possibility. so the answer is YES
John Moehrke (Aug 23 2018 at 22:00):
one case --- PDQ
John Moehrke (Aug 23 2018 at 22:00):
the other case -- https://wiki.ihe.net/index.php/Birth_and_Fetal_Death_Reporting_Enhanced_Profile
John Moehrke (Aug 23 2018 at 22:01):
or even ATNA --- which has SYSLOG, TLS, S/MIME, WS-Security, and FHIR AuditEvent
Grahame Grieve (Aug 23 2018 at 22:02):
so looking at BFDR-E, I do not see that the name differs based on the underlying technical specification. both the v2/cda profile and the FHIR IG have the same name
John Moehrke (Aug 23 2018 at 22:02):
exactly
John Moehrke (Aug 23 2018 at 22:02):
that is my point.. one IHE Profile (aka Implementation Guide).
John Moehrke (Aug 23 2018 at 22:03):
two alternative encodings of the same content: CDA and FHIR-Document
John Moehrke (Aug 23 2018 at 22:03):
(unfortunately for clarity sake that profile is not done yet, so you can't see it fully)
Grahame Grieve (Aug 23 2018 at 22:04):
man this is hard work. so what I am saying is, if the FHIR package name for this is ihe.bfdre, and this is the package for the FHIR IG, then if it turns out that it would be useful to have a CDA package for bfdr-e that contained technical artifacts for tools - which I think would be a very good idea - then it can't also have the name ihe.bfdre
John Moehrke (Aug 23 2018 at 22:04):
okay, so I am learning that IG != package
John Moehrke (Aug 23 2018 at 22:05):
but what is a CDA package?
John Moehrke (Aug 23 2018 at 22:05):
what is a DICOM package?
John Moehrke (Aug 23 2018 at 22:05):
what is a SYSLOG package?
John Moehrke (Aug 23 2018 at 22:05):
because IHE needs all of these and more
John Moehrke (Aug 23 2018 at 22:05):
what is an eb Registry package?
Grahame Grieve (Aug 23 2018 at 22:05):
in fhir terms IG = package. I don't know what's not clear about that. an IHE profile != a FHIR IG. I think we've established that
John Moehrke (Aug 23 2018 at 22:05):
besides the IHE Profile (IG) orchistrates many interactions between thse technologies, there are not nice neat lines
Grahame Grieve (Aug 23 2018 at 22:06):
at this point, there is no definition of a CDA package. but there should be
Grahame Grieve (Aug 23 2018 at 22:07):
I give up. You're not at all understanding anything I say, and we're going around in circles. call then what you will, but don't say I didn't warn you.
John Moehrke (Aug 23 2018 at 22:07):
okay, so I understand your naming intent.. but it is artificial to the reader of the IG.
John Moehrke (Aug 23 2018 at 22:08):
sorry.. but this package thing has not been explained anywhere in this level of clarity.. I can't be everywhere you are
John Moehrke (Aug 23 2018 at 22:11):
so if I have an IHE profile similar to the complexity of Radiology Scheduled Workflow that is orchestrating many standards, imaging including FHIR, in very intricate ways... I would still group all the FHIR stuff in one package? If that is the case, then I understand the package to be a publication grouping mechanism that does not affect the IG ability to orchestrate in intricate ways that which is within that package. Right?
John Moehrke (Aug 23 2018 at 22:13):
in that case then I understand "ihe.mhd.fhir" the inclusion of the .fhir to identify that subset packaging of all the FHIR things used in that IG.
Grahame Grieve (Aug 23 2018 at 22:16):
yes and yes. and if we get to having packages for cda.. as we should, then .cda would indicate the parts of the spec that are useful to cda validation tools
John Moehrke (Aug 23 2018 at 22:33):
okay. now I understand. yes the .fhir should be after the profile name... not sure right now the relationship to IHE Profile Options... but leave that for a later time
Grahame Grieve (Aug 23 2018 at 22:37):
ok. well, I won't update the package names in the registry right now until we're sure
Elliot Silver (Aug 23 2018 at 23:24):
Let me see if I can bridge this. An IHE profile is a lower-case implementation guide. It provides guidance on the use of one or more standards for a particular use case.
I think Grahame is seeing that that translates into an Implementation Guide for the FHIR portions of the profile; which is distributed as a package. If there were other standards involved in that profile, the guidance would be distributed in other packages. Thus the package name should include FHIR since it describes only the FHIR portions.
John thinks that the whole profile would be documented in an Implementation Guide, of which only a part might be FHIR. The whole profile is distributed as a single package. Thus the package name should stop at the profile name, since we don't distribute per-standard guidance.
Further, John is looking to the future and seeing the IG process as a way for IHE to get off our current PDF-based distribution, and thus needs to be able to handle multiple standards. Grahame sees the IG process as FHIR only.
The fact that most of the IHE's existing FHIR profiling is FHIR-only, with a few FHIR-alternative, won't necessarily hold in the future. Today I was having a discussion about a potential profile passing data back and forth between FHIR and DICOM. You'll need the whole profile to be able to use it.
Am I close to characterizing this correctly? Does this help?
Grahame Grieve (Aug 23 2018 at 23:49):
you're thinking about publishing everything through the FHIR publishing mechanism?
Elliot Silver (Aug 24 2018 at 04:54):
That is one possibility we've been discussing. There is a desire to move off our current pdf-based publication. The structure of an IG is not to far off of our structure, and it appears to be the preferred way to publish FHIR profiling. I expect, IHE is going to want to move to a single approach for all profiling publication. Publishing FHIR profiles one way, but v2, v3, ebXML, and DICOM profiling another way (or worse, other ways) is going to be a pain. If FHIR publication can't support IGs involving those other standards, we'll have to look to other publishing mechanisms that do. And if we find something that works for all those other standards, I doubt we'll use something different just for FHIR.
Elliot Silver (Aug 24 2018 at 04:58):
I want to be clear, I don't intend that as a threat or ultimatum, or anything like that.
Elliot Silver (Aug 24 2018 at 05:00):
It isn't clear what FHIR-like publishing of those other standards looks like, but at worst, it could be all text with a few schemas or example files linked.
Grahame Grieve (Aug 24 2018 at 05:09):
So we already use the FHIR publishing mechanism for several HTML only guides purely for convenience. So you absolutely can publish anything you like that way. The interesting question will be if you start wanting additional processing support.... we can validate CDA documents and HL7 v2 messages to some degree... but what else? that will be the question
Elliot Silver (Aug 24 2018 at 05:13):
OK, knowing pure HTML is supported is good, and there is some support for more is also good. I don't know enough about the FHIR publishing mechanism or what the IHE "dream" publication system's needs are to talk about gaps.
Elliot Silver (Aug 24 2018 at 05:19):
John and Jose are the ones thinking about this more. They are working on requirements for what we want from a publication system.
Elliot Silver (Aug 24 2018 at 05:20):
I jumped in because I thought you and John were talking past each other and working from different sets of assumptions.
John Moehrke (Aug 24 2018 at 12:03):
It was long... but I eventually learned what Grahame was teaching... The conclusion is that yes we want a ".fhir" but at the end of the NPM name in the IG we have published in the IG registry.
Last updated: Apr 12 2022 at 19:14 UTC
