Page tree
Skip to end of metadata
Go to start of metadata

Attendees

AttendingNameOrganization

Robert Snelick

Brett Marquard

Lloyd McKenzie

Hans Buitendijk

Jeffrey Danford

Yunwei Wang

AbdulMalik Shakir

Alex Kontur

Alexander Henket

Catherine Hoang

Chris Amorosa

Ciprian Gerstenberger

Craig Newman

David Hay



Didi Davis

Doug Pratt

Durwin Day

Frank Oemig

Jay Lyle

Jeff Helman

Jonathan Percival

Josh Mandel

Keith Carlson

Mark Kramer

Matt Rahn

Michael Donnelly

Richard Ettema



Yunwei Wang

Sean Muir

Thomas Tveit Rosenlund

Brett Marquard

Caroline Macumber

Emma Jones

Jeffrey Danford

Ward Weistra

Yunwei Wang

Rachel Richesson

William Ted Klein

Patricia Taylor

Lenel JamesBCBSA


FHIR Profiling and Conformance Testing

Rob began the discussion and is going through and showing an example. 

Showing Sender/Consumer Perspective. How the usages worked in HL7 v2. 

Discussion about data absent reason and how it relates to the concept of "nulling" a field. There is an interest in specifying exactly when an element is supposed to be present. Lloyd says, that cannot be done, absolutely not. "You cannot have a single element that combines the cardinality and conditionality. " 

We want to add clarity not capability. 

Need to understand better what is being proposed. Grouped asked for the presentation from Rob to be restarted and explain what is being proposed.

Just providing a mechanism for expressing the requirements, but not requiring that people use these. Looking for something better than narrative text, something that is unmutable across profiles.

We received guidance in January to see this proposal as an enhancement of mustSupport. 

Talking about profiling down. We need more generic profiles and ones that can be constrained down. 

Does conformance understand that mustSupport is orthogonal to cardinality. "Must support" means that there needs to be a widget on the screen. 

Rob is going through the proposal, specifically what values we need in the conformance usage indicator. 

Concerned about being restrictive might not be good. FHIR is helpful because it so open. Problem in US Core is that it became too restrictive. 

The conformance constructs must be applied differently depending on the level of profiling. The top profiles have to be more open and the lowers ones less so. This just provides the mechanisms to specifying this, not how restrictive you should be at each level. That has to be determined at each level. Providing a mechanism, but you will apply to use cases as appropriate. 

From one participant: Looks like some of the concepts are covered by concepts that are already in FHIR. Might be more clear, but could also be in conflict or redundant. Perhaps create a document on conformance patterns. The extension is not necessary. 

Another: Fundamental problem: FHIR is not relying on narrative. The only place is with mustSupport and that aspect is not supported by this proposal at all. 

Is this redundant? Lloyd says he can compute the proposed values directly from the current FHIR resources. So this extension is not needed. 

US-Core profile defines how to send null for a value. There is no notion in FHIR of "mandatory" and it is a dangerous concept in FHIR. The "null" concept might exist in the code set. Needs to be defined in FHIR terms as to what this exactly means. 

People are asking that "mustSupport" be less wishy-washy. 

Proposal that: Do we all agree that these situations need to be documented and addressed in some way in FHIR? 

The diagram above should be moved up for people to see more and be core to the extension. 

Next Steps:

  • Lloyd has three takaways to FHIR-I, doesn't see value in an extension
  • Side-by-side comparison

Relevant Discussion on Whova

Hans Buitendijk
Can we have one overview first before jumping too dep?

Josh Mandel
is this deck available?

David Hay
https://confluence.hl7.org/display/CONF/Conformance%2C+Guidance+and+Best+Practices+for+FHIR+Implementation+Guides+Project

Michael Donnelly
Thanks David.

William Ted Klein
is any screen being shared? I hear the audio but do not see any screen being shared

Michael Donnelly
Yes, a screen is being shared.
It's the slide deck that David Hay linked above.
The current slide is the one with the header "FHIR Method"

Didi Davis
Thank you to everyone for joining today. I feel this information Rob is presenting will need to be considered to enable conformance and interoperability testing leveraging multiple layers of profiles and/or implementation guides.

Hans Buitendijk
Would echo, and that having consistency of capabilities across standards as the same data is moving around any of them.

Caroline Macumber
I wasn't seeing the slides either, if you referesh they'll show up

Hans Buitendijk
is critical.

Lloyd McKenzie
We won't have consistency of capabilities across standards because the base technology is fundamentally different. v2 doesn't allow extensions at the field/data type level. v2 can't dump its existing concepts to introduce the notion of "mustSupport" as being orthogonal to cardinality. In FHIR, mustSupport *is* orthogonal.

Hans Buitendijk
That is a falacy in terms in the context on defining the strength of required or optional support.
RE/R/O/C is orthogonal to cardinality. If you look up v2 IGs you will see them expressed separately.
Clearly, something 1..1 or 1..* is an R or Must Support, but 0..1 or 0..* can be any.

Lloyd McKenzie
1..1 does NOT have to be mustSupport

Hans Buitendijk
Clarify how a 1..1 or 1..* does not force that attribute to always be present if MustSupport is not indicated.

Lloyd McKenzie
mustSupport deals with specific system functionality of the system *independent* of what appears on the wire. It covers things like "must store", "must display to user", "must allow user to specify", "must consider in decision support logic". It has *nothing* to do with what must appear in the instance.
1..x elements with mustSupport=true can be satisfied by fixed values on the sender side and thrown away on the receiver side.
blah. Meant mustSupport=false

Hans Buitendijk
Must Support is totally reliant on language to clarify that rather than computable. When you look at Lab EHRS guide to accompany v2 LRI you can see where one get more computable with asserting those behaviors. Currently, Must Support cannot be interpreted easily across IGs. More precision in expression is essential if we want to go being human interpretation of nuanced language.

Lloyd McKenzie
Sure - and there may be value in codifying mustSupport, though I'm far from confident we can cover all of the space needed. However, this proposal doesn't give us that.
This proposal is confusing mustSupport, cardinality and conditionality
And they're not related.
Coding mustSupport would mean codes that say "mustDisplay" vs. "mustStore" vs. "mustAllowUserCapture"

Hans Buitendijk
Not convinced, but once we get there, happy to understand also how an alternative than would be different and more precise. I'm not getting the sense they are being mixed conceptually.

Lloyd McKenzie
v2 didn't try to distinguish those expectations at all.

Thomas Tveit Rosenlund
Can you test the meaningful data? computable?

Lloyd McKenzie
mustSupport can't be tested by looking at an instance - ever
An instance won't tell you what's displayed to the user, stored in the database, etc.

Frank Oemig
Different guides introduces different requirements by using mustSupport. Why not formalizing that, like reuiqirements for sender, requirements for reciver, functionality to be done, expectations about using extensions in general or specific like data-absent/null-value

Lloyd McKenzie
With FHIR, we strictly separate what can be tested in an instance vs. what can only be tested by evaluating internal system behavior.
We can do requirements for sender vs. receiver now - that's distinct profiles and distinct capability statements

Thomas Tveit Rosenlund
Different apps will have different requirements on what must support means because the use case poses different requirement on what must-support has to signify.

Lloyd McKenzie
We *don't* have a handy flag right now that says "must have a value". That might be a worthwhile discussion, though there is considerable risk there.
Our challenge with mustSupport is that when it's declared, it makes deriving profiles where the use-case environment is different is harder. But this proposal doesn't fix that.

Frank Oemig
This ends up with an explosion of profiles. And they miss relations.

Hans Buitendijk
Perhaps having a look at this (http://www.hl7.org/implement/standards/la.cfm?file=/documentcenter/public/standards/dstu/EHR_IG_LRI_FUNCREQS_R1_DSTU_2016MAY.zip) particularly the spreadsheet in that download.

Lloyd McKenzie
"They miss relations"?

Frank Oemig
The sender profile is not related to the receiver profile

Hans Buitendijk
Having profiles where that is needed is fine. It is not for all profiles.

Lloyd McKenzie
What relationship is needed?
Forcing a relationship can actually prevent re-use

Frank Oemig
how they belong to each other and where there is some overlap

Hans Buitendijk
Yes, we need consider sender/client/receiver/server perspectives and responsibilities. Unavoidable. We've tried with English, but we need to get to computable statements and use those wisely, sparingly, purposefully.

Frank Oemig
:-)

Hans Buitendijk
Not forcing relationships for certain use cases can yield to mis-matches. It's a tool kit we need so we can be very expressive and apply it where needed.

Lloyd McKenzie
We have computable sender & receiver expectations

Hans Buitendijk
So then we would not have to define the meaning of Must Support in every IG in English anymore?

Lloyd McKenzie
That's not about the relationship, it's about ensuring sender and receiving profiles are appropriately aligned
This proposal wouldn't stop needing to define mustSupport in English
Because these codes don't differentiate "must store", "must display", "must consider in decision support", etc.
And *that's* what the English covers
The codes here are really just providing a single code that tries to collapse certain aspects of cardinality, condition and mustSupport flags into one column.
Unfortunately, they don't cover all of the combinations, and you'd *still* need to expose cardinality because it doesn't convey anything other than "=0" vs "=1"

Michael Donnelly
This: "That's not about the relationship, it's about ensuring sender and receiving profiles are appropriately aligned"

Hans Buitendijk
Let's then don't argue the need, rather what are all the variants that needed to be expressed for the sender or receiver, client or server, in the context of a use case for which a profile (or related profiles) is created. I'm hearing fundamental disagreement on need rather than what are the perspectives need to be expressed.

Lenel James
I don't hear consensus. Table this for a WG call?

Hans Buitendijk
This is a workgroup call, right?

Joel Francis
this is a WG call :)

Hans Buitendijk
I'd like to see a side-by-side comparison of the proposal and how that may or may not be expressed in FHIR already, and where the two do not align.

Michael Donnelly
Good idea, Hans.

Brett Marquard
+1

Lenel James
+1

Caroline Macumber
+1

Joel Francis
1
+1

Doug Pratt
+1

Avinash Shanbhag
That would be nice:)

Lloyd McKenzie
I've got a table that shows how these codes map to FHIR concepts

Jeff Helman
Well stated, Didi.

Lloyd McKenzie
Except Mandatory - which is new and ill-defined - but I think there's a hole in FHIR there.

Jay Lyle
Didi, you see questions in the Whova chat?

Thomas Tveit Rosenlund
Another question, are these missing capabilities of the FHIR conformance model big pain points for implementers?

Didi Davis
@Jay Lyle, I see your question in the chat.

Jay Lyle
never mind, whova woke up
thx

Hans Buitendijk
@Thomas: Yes.
Current guidance, a mix of English, indicators, and invariants, can lead to different expectations on what the client and/or server, sender and/or receiver are expected to support.
Today 11:10 AM

Didi Davis
Yes, @Thomas, these are pain points that exist as we start planning for conformance testing with the wild west of ways different profiles and IGs are being structured.

Lloyd McKenzie
It's not clear @Thomas. I'm not sure that having a computable flag for "must display", "must store", etc. are something that would make a huge difference
And the reality is that there's nuance around 'display' that gets hard to express computably

Hans Buitendijk
@Lloyd: from our v2 experience that does make a huge difference.

Thomas Tveit Rosenlund
I don't see it, can you give an example of when this is important when implementing an API?

Lloyd McKenzie
For example if you have 'must display' for an identifier.system, what does that mean - show the URL or show a human-readable mapping of the URL?
v2 doesn't touch it at all formally

Yunwei Wang
Other than M, can't all the rest be computable from existing ElementDefinition?

Hans Buitendijk
@lloyd: check out that link I provided early and happy to talk after that.

Lloyd McKenzie
I saw that link. But that's not part of the v2 methodology. And it's not being proposed here either.
I'm happy for us to move the discussion to introducing something like that.

Hans Buitendijk
It is how IGs have started to deal with it and further aligned with Conformance.

Lloyd McKenzie
But adding codes of R/RE doesn't buy us anything.

Hans Buitendijk
That is where a compare and intend is critical as the underlying concepts need to be expressed.
Don't get stuck on the literal "R" or "RE", rather on what is conveyed by it and how to do something like that in FHIR.

Thomas Tveit Rosenlund
The "meaningful data" parts of the definition might not be computable @Yunwei

Frank Oemig
R/RE is easy, but "no extension" is not

Hans Buitendijk
RE for a sender means that they MUST be able to value that element, but each instance may not have a value. So the sender's system better be able to enable that.

Lloyd McKenzie
"No extension" is a constraint
And "no extension" is generally a dangerous thing to say in FHIR
It's saying "no safety valve"

Hans Buitendijk
"Meaningful" is not computable, but different ways of being meaningful can be codified in context.

Lloyd McKenzie
So we deliberately didn't make it an easy thing to say

Ioana Singureanu
https://www.hl7.org/fhir/us/core/general-guidance.html#missing-data

Hans Buitendijk
@Lloyd, clearly it has not been easy to explain "meaningful", while applying an 80/20 approach, much more can be expressed more clearly and only leaving a fraction for English to resolve where unfortunately less words don't help.

Mark Kramer
Let’s come together and create consensus documentation and direction for all combinations of existing element requirements

Michael Donnelly
+1 Mark

Didi Davis
+1 Mark

Patricia Taylor
+ Mark

Lloyd McKenzie
What I'm taking away are two requirements:
1. flag to say "no extensions"
2. codeable way of saying "what kind of support is needed for this mustSupport element"
I'm not convinced that either are good ideas, but they can certainly be explored
I don't see the proposal on the screen addressing either of these though

Jeffrey Danford
There should be a concern that implementing "no extensions" is going to severely limit the ability to use legacy data

Doug Pratt
Is there a way to say "conditionally required"? E.g., if the patient has a middle name, it must be sent. But not if they don't have a middle name.

Lloyd McKenzie
"No extensions" is a very dangerous thing to say
That would be min=0, mustSupport=true
There's no "condition" there

Avinash Shanbhag
It would be nice to have the rules that are not tied to "use case"

Frank Oemig
but that is what we for example need when exchanging specific required data

Doug Pratt
Right. Isn't that what we're missing for IG writers?

Avinash Shanbhag
otherwise, its hard to test the capability since the expectation is that the information is used in many use cases

Lloyd McKenzie
Rules have to be tied to use-case. The behavior of a decision support system is different from that of a repository.

Jeffrey Danford
We're running the danger of creating a specification that's both exhaustive and unusable.

Lloyd McKenzie
@Doug Pratt - "what we're missing for IG writers" - clarify?

Thomas Tveit Rosenlund
Absolutely agree @Jeffrey

Doug Pratt
How would an IG writer express my middle name use case in a computational form?

Hans Buitendijk
@Avinash: Agreed, particularly also as a FHIR resource can be used in many different ways. So very detailed profiles should be able to get to that, while higher level ones should remain more open/relaxed.

Thomas Tveit Rosenlund
Thats the next session @Doug?

Doug Pratt
HL7 should not get into how must support is implemented: display vs. persist vs. ...
We've never gotten into telling applications how they must be coded
Our domain is information exchange

Alex Kontur
Would be nice to just add some more words to the definition of the must support flag in the base spec. It isn't very illustrative of what is intended

Thomas Tveit Rosenlund
I think must-support can give good guidance on what the application is supposed to do with the data in the element. And this is crucial to achieve actual interoperability

Robert Snelick
https://confluence.hl7.org/display/CONF/FHIR+US+Conformance%3A+Specification+Outline

Jeffrey Danford
@Doug +1

Lloyd McKenzie
https://confluence.hl7.org/display/CONF/V2+conformance+to+FHIR+mapping

  • No labels