FHIR Chat · Must-Support and element values · conformance

Stream: conformance

Topic: Must-Support and element values

---

Grahame Grieve (Sep 01 2020 at 13:29):

We presently have must-support as a boolean that applies to the element. We've spent considerable time over the years arguing about it, but now a new issue has arisen in a couple of different contexts, which is that IG authors are starting to want control beyond just whether the element is supported or not: they want to pick out some parts of the value domain and indicate that they these parts are 'must-support'

The 2 most obvious places are:

• which target types are must-support in a set (currently an acute issue for US-Core)
• which codes in a value set are must-support

Grahame Grieve (Sep 01 2020 at 13:30):

There's a theoretical need for some other cases, like date and integer ranges, but those are more difficult

Grahame Grieve (Sep 01 2020 at 13:32):

I believe that the must-support in the binding should be done as part of the binding discussion (which is presently sleeping but I'm going to wake it up). So I want to talk about target types - the editors of US core have asked for support to indicate which target types in a profile are must-support.

Grahame Grieve (Sep 01 2020 at 13:32):

For me, this raises 2 questions:

• how would you indicate this in a profile?
• what's the right way to render this in a view?

Grahame Grieve (Sep 01 2020 at 13:33):

I think that the answer to the first is an extension of type boolean that can be set to true or false and can be used on ElementDefinition.type.targetProfile and `ElementDefinition.type.profile.

Grahame Grieve (Sep 01 2020 at 13:34):

and the second would be that if that extension exists, then either the red square or a greyed out (for negative) will be shown next to the type / target profile

Grahame Grieve (Sep 01 2020 at 13:36):

we could consider, as a variation, using a url instead of a boolean, so that you can say more specifically what you mean about must-support. @Michael Lawley suggested this about a year ago for must-support, but (a) that's normative and (b) we have no consensus on the type of things to say as part of must-support. And watching the argument around US-Core has made me convinced that we won't be able to nail that down

Grahame Grieve (Sep 01 2020 at 13:36):

hence, I propose a boolean.

Jose Costa Teixeira (Sep 01 2020 at 14:59):

what about a code?

Lloyd McKenzie (Sep 01 2020 at 15:38):

We have an extension that allows defining mustSupport for value sets. My leaning would be the same approach for target types. Default would be "must support at least one type" or "must support at least one code"

Grahame Grieve (Sep 01 2020 at 20:01):

what extension is this?

Lloyd McKenzie (Sep 01 2020 at 21:05):

http://build.fhir.org/extension-elementdefinition-minvalueset.html

Hans Buitendijk (Sep 02 2020 at 19:24):

While Must Support and rest optional is most typical, there are various places in IGs where Do Not Support would be in play as well. Particularly if the IG indicates that other references in the underlying standard remain valid (as US Core does). E.g., for Vital Signs, Device, Location, or Group are permitted per the language, but for this profile never should be used. Where relevant, that should be able to be expressed as well.

Grahame Grieve (Sep 02 2020 at 20:05):

Do you mean to imply that there's a difference between 'not allowed' and 'do not support'?

Brian Postlethwaite (Sep 02 2020 at 22:54):

what about a best practice invariant?

Lloyd McKenzie (Sep 03 2020 at 18:15):

Here's the documentation I promised to write coming out of the call today:

Areas for additional clarity around mustSupport expectations are:

1. Polymorphic types - any element that declares multiple types or profiles - generally with a name of foo[x] (e.g. Observation.value is mustSupport and allows integer, string, SampledData, etc. - does a system have to support all of them to comply?)

• methodology: at the moment, there's no mechanism to explicitly identify which types in the list of allowed types must be supported
• methodology documentation: none. However, the spirit of the spec is that mustSupport assertions must be explicit and must be able to be declared at a granular level
• action: define the needed extension to allow being explicit about which target profiles must be supported) and provide documentation making clear that in the absence of other assertions, the expectation for multiple types is that the system must support at least one of the types - and highlight both the extension and textual conformance statements as a means to assert additional requirements.

2. Target choices - any element of type Reference or canonical (e.g. Procedure.author is mustSupport and allows Patient, Practitioner, RelatedPerson - does a system have to support all of them to comply?)

• methodology: at the moment, there's no mechanism to explicitly identify which resources/profiles in the list of allowed target profiles must be supported
• methodology documentation: none. However, the spirit of the spec is that mustSupport assertions must be explicit and must be able to be declared at a granular level.
• action: define the needed extension to allow being explicit about which target profiles must be supported) and provide documentation making clear that in the absence of other assertions, the expectation for multiple target profiles is that the system must support at least one of the target profiles - and highlight both the extension and textual conformance statements as a means to assert additional requirements.

3. The data type component level (e.g. if Procedure.code is mustSupport, is it sufficient to support just Procedure.code.text, or even Procdure.code.extension(data-absent-reason), or is there a need to support coding (and coding.code, coding.system, coding.version, etc)

• methodology: a profile can: drill down and express explicit mustSupport on components in context; an implementation guide can declare a global profile for a Data Type where the profile sets mustSupport expectations everywhere; or descriptive text conformance language can be specified
• methodology documentation: the profiling rules make clear that if mustSupport isn't specifically declared in a profile, it can be declared in a derived profile. As well, if an element is mustSupport, a derived profile can't remove that assertion. Therefore, the only logical inference is that mustSupport must be interpreted as 'false' unless explicitly declared otherwise
• action: make clear in the documentation that, in the absence of other explicit declarations, if an element is "must support", the system must be support at least one of the allowed components - and highlight both the extension and textual conformance statements as a means to assert additional requirements.

4. Terminology (e.g. Patient.gender is mustSupport and is constrained to male, female, other and unknown - is it conformant if you only support 'unknown'?)

• methodology: there's a 'min-binding' extension that allows explicitly declaring the subset of the overall 'allowed' codes that must be supported by an implementer. The implication is that, in the absence of defining that extension, so long as at least one code satisfying the binding is supported, the system is conformant
• methodology documentation: nothing other than the existence of the binding
• action: make clear in the documentation that, in the absence of other explicit declarations otherwise, so long as a system supports at least one code from the specified binding, it is conformant - and highlight both the extension and textual conformance statements as a means to assert additional requirements.

Grahame Grieve (Sep 03 2020 at 20:28):

did this come with created tasks?

Lloyd McKenzie (Sep 03 2020 at 22:51):

Nope. Want some discussion first to agree that my summary reflects consensus and that the actions are indeed what we want to do

Grahame Grieve (Sep 04 2020 at 02:09):

I think its all reasonable

Lloyd McKenzie (Sep 04 2020 at 02:37):

@Hans Buitendijk @Jean Duteau @Brett Marquard @Eric Haas

Hans Buitendijk (Sep 04 2020 at 12:23):

The following would be a further progression of the proposed language we had in FHIR and could serve as the starting point for the Connectathon breakout disscussion discussed.

In accordance with FHIR Core, Section 2.1.0.5 MustSupport, “Labeling an element MustSupport means that implementations that produce or consume resources SHALL provide "support" for the element in some meaningful way.” It furthermore states “When a profile does this, it SHALL also make clear exactly what kind of "support" is required, as this could involve expectations around what a system must store, display, allow data capture of, include in decision logic, pass on to other data consumers, etc.” The interpretation of this is that any choices (reference, target), data type components, or value set content identified in the binding are not suddenly all required because the attribute that includes either of these is marked as MustSupport. Without further flagging of each element in those choices, components, and/or value sets, at least one of them needs to be supported. Thus, there is no inherent requirement for the source system to support all elements where the FHIR profile only flagged the attribute as MustSupport, unless the profile explicitly indicates that to be the case in general or each specific attribute element.

The US Core project team had no intent to require every element within an attribute to be required by way of the attribute being flagged MustSupport. Rather it only marked such instances sparingly. For example, CarePlan.category indicates explicitly that .coding.system and .coding.code are required (OTHER EXAMPLES?). In US Core Section 2.1.1.4 Must Support the general definition of FHIR Core, Section 2.1.0.5 MustSupport is further applied to US Core, but does not introduce further restrictions/requirements, but it does reference HL7 v2 “Required but may be Empty - RE”. ONC indicates for HL7 v2 messages in their certification testing that it will use data sets to exercise fields/components marked as such, although it may not exercise all as part of testing. However, ONC has been very clear in its communication that the fact it may not have been tested, the software is still expected to support those fields/components. We understand that same principle applies here. However, US Core did not specify for any data type choices (reference or target), for many data type components, and various value sets any further MustSupport flags on the data type elements. Thus they should be considered in accordance with the FHIR Core definition and approach to MustSupport.

For abundance of clarity, we propose that the following statement be included in the US Core Section 2.1.1.4 Must Support as an errata to avoid any doubt.

• Must Support SHALL apply to the attribute level only. Unless attribute components are fully decomposed with specific cardinality and Must Support statement on each (sub-)component, or the Description & Constraints specifically indicates that certain components are Must Support (or not allowed as may be needed at times), attribute components are considered as optional as the underlying standard allows where the source system needs to support at least one of the choices, values, or elements.

Hans Buitendijk (Sep 04 2020 at 12:32):

@Grahame Grieve: not allowed and do not support are equivalent. Not easy to find in the FHIR documentation what the various flags are that can be tagged to an element where MustSupport jumps out, but the rest is "hidden". One would expect that to be documented as part of 2.1.0 Conformance http://www.hl7.org/fhir/conformance-rules.html#2.1.0 , but nowhere to be found. Only MustSupport is described in that section, while not allowed and other values should be described there as well, if they exist.

Grahame Grieve (Sep 04 2020 at 12:37):

I don't understand this. Cardinality is documented before must-support and is certainly clear

Brett Marquard (Sep 04 2020 at 12:43):

Thanks @Lloyd McKenzie, this is a good start and I think a conversation on FHIR-I or another place to continue is appropriate.

Brett Marquard (Sep 04 2020 at 12:49):

@Hans Buitendijk I appreciate the proposed new bullet -- I am concerned this language will allow a system to only support string at Observation.value and I am certain that was not our intent in DAF--> Argonaut--> US Core. We have rewritten these bullets numerous times, and the happy middle path isn't clear to me yet. During the US Core track next week I am hoping we can spend some time on this topic.

Brett Marquard (Sep 04 2020 at 12:50):

...the future state of flagging these individually will be lovely.

Lloyd McKenzie (Sep 04 2020 at 13:27):

I'm not sure that you can update US Core to explicitly list which choice options or targetChoice options are considered 'mustSupport' and which are optional without going back to ballot, because that would be a substantive change and would be a hard stretch to consider a technical correction. However, if you can get some degree of consensus from the community, you might be able to have an "HL7 statement" or something from the relevant work-group with sign-on from some of the members identifying what you've agreed is 'reasonable'. I'd be surprised if the regulatory process allowed them to enforce that. My presumption is that for US-Core release 3.1.x, you're going to be stuck with "at least one" - which means that a system that only spits out Observation.valueString for everything would comply. Getting tighter than that will require a new release - and the regulation being updated to point to the new release. That sucks, but I'm not sure there's a formal process that can get us there via another path. Fully open to ideas though.

Lloyd McKenzie (Sep 04 2020 at 13:29):

"Not allowed" isn't something we should be introducing. That's handled by cardinality - just set max=0. It has nothing to do with mustSupport. mustSupport isn't about what must (or must not) appear in a given instance, it's about what a systems capabilities are. It's intended to force the existence of specific capabilities originally to what appears in all instances.

Hans Buitendijk (Sep 04 2020 at 13:42):

@Grahame Grieve : That covers elements, but how do you express in a choice list that the subject of a vital signs cannot be a Device, while Device is an allowed subject of Observation that the vital signs is profiled on? As we are trying to balance between minimum required and "the rest" being optional, there are some situations where we need to be explicit that with "the rest" there are some that just are not allowed, as obvious as they may seem. Cardinality would not do that. Same for target choice. In vocabulary one does it by excluding certain values from the value set, unless it still needs to be extensible (not a likely combination when that happens).

Lloyd McKenzie (Sep 04 2020 at 13:52):

You would constrain the choice list to exclude it. If you have something that allows 'Any' and you want to allow "everything except X and Y" and don't want to enumerate everything else, you could use an invariant.

Hans Buitendijk (Sep 04 2020 at 13:52):

@Brett Marquard : Regarding "...the future state of flagging these individually will be lovely.", welcome to the world of certification testing, conformance claims, and computable constraints. You should see a couple of HL7 v2 IGs.......:) Which btw highlights the reference between MustSupport and RE. REs in v2 had a certain meaning as those messages were meant for workflow support where it was critical that certain data be supported by the underlying system. Using those same messages for viewing was "nice". For the FHIR APIs in USCDI scope it is all about viewing so providing access to what you have is sufficient. Once it goes on to workflow management we may find that we also need to distinguish between what Must Support means in the context of either.

That makes it more challenging for US Core that it cannot get too tight either. DME Ordering would be the place to do that, while US Core needs to remain more at the general access level to avoid over constraining various use cases below it. That then means that "at least one" may be unavoidable for US Core, although I clearly am with you that it is not desirable to just put everything in string where the source has it available in integer, etc. However, trying to use computable flags to drive improved use of structured data where you can seems not a likely capability as you would have to know what the underlying system actually has, and/or what is actually reasonable/practical for the data at hand. I consider that beyond the reach of structured profiling, rather in the realm of overall continued and repeated encouragement. Even if we agree the appropriateness that both string and integer are reasonable, still no guarantee that data that could been put in an integer is actual put there.

Hans Buitendijk (Sep 04 2020 at 13:55):

@Lloyd McKenzie : Current wording in US Core indicates that other choices from FHIR Core are still permissible and if you do so to preferably use US Core Profiles where available. So invariant it is rather than a simple check box next to each one (Must Support, Optional, Not Allowed) that is easy to read and easy to compute?

Lloyd McKenzie (Sep 04 2020 at 13:56):

An invariant would be easy to read and compute. We definitely don't want to add 'not allowed' when it's redundant with mechanisms we already have.

Hans Buitendijk (Sep 04 2020 at 13:58):

@Lloyd McKenzie : easy to read is all in the eye of the beholder where invariants tend to favor some over others in that regard.

Lloyd McKenzie (Sep 04 2020 at 13:58):

I think the Observation.value issue for US Core wouldn't be handled by the proposed new extension to allow indicating certain types as 'mustSupport' - because there will be some systems covered by US Core where they simply won't have Observations (or a need for Observations) that would ever produce some of the types that you would generally expect would need to be supported. I expect where you'll need to end up is to describe the characteristics of what data types must be supported. You could identify that Observations with LOINC codes with LOINC-declared data types of certain values must be expressed by certain FHIR data types. That would allow you to prohibit sending "25 mmol/ml" as a string while still not forcing the use of 'Quantity' as a mustSupport data type for a psychiatric app that only ever needs valueCodeableConcept and valueString.

Lloyd McKenzie (Sep 04 2020 at 14:00):

The 'human readable' part of an invariant is as easy to read as you choose to make it - and has a clear flag on the element whose cardinality is impacted. The computable portion of the invariant has a learning curve - but it's a learning curve all FHIR implementers need to mount regardless because there are invariants on almost all resources alaready.

Brett Marquard (Sep 04 2020 at 14:34):

overall continued and repeated encouragement.

One thing I learned in C-CDA certification is if lab result string is allowed, some vendors will only ever send it that way -- even if stored discretely.

Brett Marquard (Sep 04 2020 at 14:36):

+1 to comment about us being careful to not get too tight, this will create problems on reuse of US Core.

Eric Haas (Sep 04 2020 at 15:50):

Brett Marquard said:

+1 to comment about us being careful to not get too tight, this will create problems on reuse of US Core.

This is our overall challenge along with continued support of the real world (including relative ease of use ) which is why we in US Core value implementation feedback above all modelling concerns

Eric Haas (Sep 04 2020 at 15:50):

(deleted)

Hans Buitendijk (Sep 04 2020 at 16:35):

@Eric Haas Consider our JIRAs and topic implementer feedback and a reality check on how to model or it will yield unintended consequences.

Brett Marquard (Sep 04 2020 at 16:38):

one comment - US Core is not just a USCDI certification guide

Hans Buitendijk (Sep 04 2020 at 20:01):

@Brett Marquard : Agreed and adds to potential unintended consequences challenges, which would yield the need for less restrictive, without creating a "for certification purposes....." IG below US Core (or above depending what direction you want to draw the diagram).
If you have some updates to the proposed draft to start the breakout conversation they may strike a better balance, please do. Also, based on @Lloyd McKenzie 's comment that invariants would be the only tool available today to preclude certain choices (to be used very sparingly), may need to bring that in around vital signs. But depending on where we land, may not be immediately needed.

Grahame Grieve (Sep 04 2020 at 20:23):

@Hans Buitendijk I don't understand your position here. If an item is not listed as an option, then it's Not Allowed. That's pretty clear to me, but you appear to think otherwise.

Hans Buitendijk (Sep 04 2020 at 20:59):

@Grahame Grieve : Section 2.1.1.5 Referencing US Core Profiles (http://hl7.org/fhir/us/core/STU3.1.1/general-guidance.html#referencing-us-core-profiles) contains the following line " Other resources allowed in the base FHIR specification may be referenced even though the current publication framework does not display them. For example, RelatedPerson is an allowed target reference in DocumentReference.author." That gives the impression options not in the list, but in the Core specification are acceptable. If you then take the US Core to Vital Signs path and go to Observation.subject, then that seemingly implies other subjects are valid. In the absence of further Must Support guidance in either US Core or Vital Signs that it is not allowed, you can go there. Vital signs of a Group, Location, or Device is probably not reasonably to have to deal with (as much as it is not likely it would be done, but creativity has no bounds nor should it where desired).

Grahame Grieve (Sep 04 2020 at 22:13):

That's a rather interesting passage I had not noticed before.

Grahame Grieve (Sep 04 2020 at 22:14):

so up until the last sentence, it was making sense to me:

Grahame Grieve (Sep 04 2020 at 22:14):

Many of the profiles in this guide reference other FHIR resources that are also US Core Profiles. This is defined in the formal profile definitions. For example, US Core CareTeam Profile references US Core Patient. For any other references to base FHIR resources1 or not formally defined in a US Core Profiles, the referenced resource SHOULD be a US Core Profile if a US Core Profile exists for the resource type. For example, although Condition.asserter is not constrained by this guide, the reference to Patient or Practitioner SHOULD be a valid US Core Patient or US Core Practitioner.

Hans Buitendijk (Sep 04 2020 at 22:14):

@Grahame Grieve : It certainly opens unexpected doors.

Grahame Grieve (Sep 04 2020 at 22:15):

that's totally sensible. we didn't say anything about Condition.asserter... but you SHOULD still refer to something that conforms to US core..

Grahame Grieve (Sep 04 2020 at 22:16):

That makes sense to me - it would be good, but there might be corner cases that make us not want this to be a SHALL - sure

Grahame Grieve (Sep 04 2020 at 22:17):

Other resources allowed in the base FHIR specification may be referenced even though the current publication framework does not display them.

well... ok. I mean, if that's a restatement of the meaning of what we just talked about, it's not wrong. Odd language... but not, like, wrong per se

Grahame Grieve (Sep 04 2020 at 22:17):

but then it finishes with this:

Grahame Grieve (Sep 04 2020 at 22:17):

For example, RelatedPerson is an allowed target reference in DocumentReference.author.

umm, no. That's very clear. RelatedPerson is not an allowed target reference in in DocumentReference.author because the profile very definitely says it's not.

Grahame Grieve (Sep 04 2020 at 22:18):

That sentence is invalid. Period.

Hans Buitendijk (Sep 04 2020 at 22:21):

But that "Other resoruces...." sentence does create ambiguity that options beyond what is actually listed in the IG's profile could be used. Brought home with the example in the last sentence that exactly does that as you indicate. Having clarity that anything not listed is not allowed OR that it is allowed unless expressly not allowed (like Vital Signs against Group, Location, or Device). would help.

Grahame Grieve (Sep 04 2020 at 22:23):

I agree that the example given in the last sentence makes it clear that the intent of the second last sentence is invalid (e.g. it's ambiguous, but the example resolves the ambiguity and leaves it wrong).

Hans Buitendijk (Sep 04 2020 at 22:25):

That also led us in the detailed JIRAs to shorten the list to "absolute minimum" as this text seemingly allowed for others to still be used so the MustSupport, if interpreted to be applicable to the full choice list, would not extend to the full list. So definitely some wordsmithing and/or flagging in order to remove these ambiguities to avoid unintended requirements to support everything in a reference or target list in a profile.

Grahame Grieve (Sep 04 2020 at 22:26):

in a profile, for a set of target types, anything not listed is not allowed:

If any profiles are specified, then the content must conform to at least one of them

Grahame Grieve (Sep 04 2020 at 22:27):

well, perhaps the authors were trying to have their cake and eat it too as a way of working around not being able to differentiate between allowed and must-support. But that's not possible here

Brett Marquard (Sep 07 2020 at 18:33):

It seems like we are stuck -- list all FHIR references and ONC requires system test all. List only the ones we explicitly expect systems to support, and we have inadvertently disallowed other options. I am certain we were thinking a middle road... Should a resource reference we don't include 'must support' be disallowed? (i.e. DocumentReference.relatedPerson example)

Brett Marquard (Sep 07 2020 at 18:37):

@Hans Buitendijk I am concerned about 'adding' another bullet without thinking through many many scenarios -- it seems each time we added a bullet we have an unintended consequence at a later date. I am thinking we agree to set of heuristics for review - for example:

• We will review all choice elements (i.e. Observation.value[x])

• We will reconsider all references where more than one choice is present.
  -- will consider read of Client
  -- will consider write of server

• We will reconsider Vitals

Brett Marquard (Sep 07 2020 at 18:38):

I am concerned though that some systems don't support Patient at DocumentReference.author and if we remove that option -- we are explicitly disallowing patient.

Brett Marquard (Sep 07 2020 at 18:38):

(per conversation above)

Lloyd McKenzie (Sep 07 2020 at 18:49):

Not listing something absolutely must mean disallowed. The list of type has always been about "what's permitted" and has never had anything to do with "what must be supported". And that's not something we can change - otherwise, in the core spec, all resources would be allowed for all references and all data types would be allowed for all choices. If we want to talk about support expectations within type choices and reference choices, the only options are to use textual language in the spec or a new extension that makes mustSupport expectations explicit for each type or reference option.

I suspect you're going to be better off with the 'text' option in quite a few cases - certainly something like Observation.value. You don't want to make someone non-conformant for not supporting valueInteger or valueCodeableConcept if they don't ever deal with observations where the observations would use those types - but you do want to make them non-conformant if they so support observations where those types ought to be used and instead they spit everythign out as string. To get that behavior, you'll need to make the mustSupport for various value[x] types contingent on the characteristics of Observation.code, rather than an absolute.

Brett Marquard (Sep 07 2020 at 18:58):

I didn't mean beyond what was in the FHIR core resource...

Brett Marquard (Sep 07 2020 at 19:00):

We don't list all the Resource elements in a profile, and they are all allowed.

Brett Marquard (Sep 07 2020 at 19:04):

Should the publication 'full view' on resource references not included show them with a strike threw?

Lloyd McKenzie (Sep 07 2020 at 19:05):

The snapshot does list all resource elements. The differential says what's changed. With types, if you list them, then you're constraining the allowed list. One thing you could do is slice by type and declare distinct conformance expectations on different slices.

Lloyd McKenzie (Sep 07 2020 at 19:06):

Showing everything prohibited with strikethrough would get pretty visually annoying. Imagine an Observation where you want to tighten from 10 types down to 1 - or worse, imagine constraining a Reference<Any> to a Reference<Observation>

Brett Marquard (Sep 07 2020 at 19:08):

strike through on the 3 extra references?

Brett Marquard (Sep 07 2020 at 19:09):

I didn't realize we were disallowing until recently when testing with the validator.

Lloyd McKenzie (Sep 07 2020 at 19:09):

The rendering approach is the same whether you're excluding 3 or excluding 150. I guess we could change the behavior so it varied based on volume, but that would create its own sort of confusion...

Brett Marquard (Sep 07 2020 at 19:10):

I hope we don't have any FHIR resources that reference another 150...oh wait, the any...

Brett Marquard (Sep 07 2020 at 19:12):

I think for our current predicament we are going to have to default back to text guidance. Agreeing on exactly what is 'must support' I hope is our primary focus.

Lloyd McKenzie (Sep 07 2020 at 19:14):

Agree. The tricky part is that providing that guidance is going to be hard to put through as merely being a technical correction - which means you're probably going to have to go back to ballot. Not sure what the ramifications of that are on the regulatory front :(

Hans Buitendijk (Sep 08 2020 at 14:36):

Perhaps a mix of flags and text can help with ANY for now, but having flags on each choice to indicate Must Support, Optional, Not Allowed (whether by absence or otherwise) is most expressive and could help that, e.g., a string does not become the only one supported and reduces risk that data that could be more structured still ends up less structured. The latter would still benefit from text or other means. For example, in the v2 Lab guides (having in part been used by certification such as LRI and ELR), for LOINC encoded observations there is text to indicate that LOINC properties would be indicative of the right data type to use. You should be able for Lab tests to use at least the strength of the guidance listed there and stay in sync with LRI and ELR lab reporting. Or thottle back a little if FHIR is not quite ready for that.

Lloyd McKenzie (Sep 08 2020 at 14:53):

Defining 'mustSupport' sets an expectation of what the system must be able to do - irrespective of what type of data it typically handles. So you should have a degree of homogeneity of the systems using the profiles. If you're confident that all systems conforming with US Core will need to produce/consume lab results that use Quantity, then making Quantity mustSupport is fine.

Hans Buitendijk (Sep 08 2020 at 14:59):

That may then yield more text in the base profile, or further profiling where it is clear that if you support Labs, then...., if Rad, then ..... Not pretty, but certainly clear.

Lloyd McKenzie (Sep 08 2020 at 15:18):

Clear is good - and making sure that the rules defined actually cover the behavior you want for the relevant systems but don't negatively impact the non-relevant systems.

Lloyd McKenzie (Sep 10 2020 at 16:30):

Commenting on the slide deck here seeing as I can't comment in the deck:

• MedicationRequest authored by Patient/Organization is not illegal. Remember that MedicationRequest isn't only 'placer-order' - it can also be a proposal, a plan and various other things - and some of those things might be authored by patients, care-givers or organizations. It may be that EHRs don't currently track that information and/or that it's deemed out of scope for the profile, in which case the scope of the profile should make clear that it's only dealing with full-blown original prescriptions (and not filler orders, instance orders, etc.)

Eric Haas (Sep 18 2020 at 23:30):

After belatedly reading this stream. From a profile authoring perspective we wrote the differentials to"white-list" what we as US Core cared about. In essence everything not explicitedly excluded was permitted but undefined. That is how profiling works for elements. ( what you don't constrain is allowed ) But that paradigm shifts for references and choice types where the MS choices unexpectedly "black-lists" everything you don't include. This inconsistency in the differential interpretation is inconsistent and mind-bending on an element to element basis and IMO contributed greatly to these issues.

Grahame Grieve (Sep 19 2020 at 03:41):

it should not have been unexpected

---

Last updated: Apr 12 2022 at 19:14 UTC