In an earlier post, I asked for community for comment on changing some elements from uri to Reference:

For the conformance resources, change all elements of type uri where they will always point to a Conformance resource to type Reference(XX).  This will include changes to StructureDefinition (GF#12902)

We received some feedback, and have just revisited the issue. The feedback made it clear that there are 2 different issues on the table here:

• When you refer to content outside the resource, must the content refer to an actual FHIR resource? or is it allowed to refer to something else (like a PDF)?
• When you follow the reference, should you actually look it up like a URL? or should you treat it as a canonical reference and look it up by URL on a terminology service or a registry?

After considerable discussion, we agreed to make a set of changes that are much more pervasive to the specification, but actually make less change to implementations. Specifically, we propose:

• Define two new types of URI called “canonical” and “url”.
• canonical is an URI (IRI, URL, absolute or relative that refers to a FHIR resource by it’s canonical URL (e.g. that has a .url element). This type allows allows version (using canonical versions)
• url is always a literal reference (used in a few places including Attachments)
• References don’t contain canonical URLs anymore (currently this allowed)
• Canonical works like reference in that: you can specify aggregation, targetProfile, and _include (which means that you’d see canonical(PlanDefinition|ActivityDefinition))
• uri would still be used where the target of a reference might not be a URL. The Lookup pathway is unspecified (either canonical or literal)

The following elements would have their types changed:

• StructureDefinition.baseDefinition = canonical
• ElementDefinition.type.code = uri
• ElementDefinition.type.profile = canonical
• ElementDefinition.type.targetProfile = canonical
• ElementDefinition.constraint.source = canonical
• ElementDefinition.binding.valueSet[x] = canonical, uri
• CodeSystem.valueSet = canonical
• CodeSystem.supplements = canonical
• ValueSet.include.valueSet = canonical
• ImplementationGuide.package.resource.source[x] = [think about it]
• ImplementationGuide.package.resource.exampleFor = canonical
• ImplementationGuide.global.profile = canonical
• CapabilityStatement.instantiates = canonical
• CapabilityStatement.implementationGuide = canonical
• CapabilityStatement.rest.searchParam.definition = canonical
• CapabilityStatement.rest.compartment = canonical
• CapabilityStatement.rest.resource.profile = canonical
• CapabilityStatement.rest.resource.supportedProfile = canonical
• CapabilitStatement.rest.operation.definition = canonical
• CapabilityStatement.messaging.supportedMessage.definition = canonical
• CapabilityStatement.document.profile = canonical
• SearchParameter.derivedFrom = canonical
• SearchParameter.component.definition = canonical
• OperationDefinition.targetProfile = canonical
• OperationDefinition.binding.valueSet[x] = uri | canonical
• OperationDefinition.base = canonical
• OperationDefinition.inputProfile = canonical
• OperationDefinition.outputProfile = canonical
• OperationDefinition.param.binding.valueSet = uri | canonical
• QuestionnaireResponse.questionnaire = canonical
• Questionnaire.derivedFrom = canonical
• Questionnaire.options = canonical
• MessageDefinition.base = canonical
• MessageDefinition.parent = canonical
• MessageDefinition.replaces = canonical
• MessageDefinition.focus.profile = canonical
• MessageDefinition.allowedResponse.message = canonical
• GraphDefinition.profile = canonical
• GraphDefinition.link.target.profile = canonical
• Meta.profile = canonical
• ExampleScenario.workflow = canonical
• ConceptMap.source[x] = uri | canonical
• ConceptMap.target[x] = uri | canonical
• ConceptMap.unmapped.url = canonical
• TerminologyCapabilities.expansion.definition = canonical
• TerminologyCapabilities.expansion.profile = canonical.

(note that this list only includes changes to infrastructure resources – other resources will also be affected)

Given that this is the second consultation on this issue, and that time is running tight, we’ll only open this consultation for a week – comments must be in by CoB Monday 26th February

The January HL7 WGM was held last week in New Orleans. I found this a very laid back and cool meeting – perhaps it was a New Orleans thing? I’m sure that the HL7 Parade helped – but we did get plenty done – connectathon, ballot reconciliation, clinicians on FHIR, planning for normative, and more.

Girls on FHIR

We had really cool swag this meeting:

That’s a riff on a Hunger games t-shirt, and also a way for us to celebrate our many female contributors, though we didn’t want to leave the guys out – they could get the same t-shirt with “HL7 on FHIR” on it.

Ballot Outcome / Normative FHIR

The first ballot in the release 4 cycle for FHIR closed just before the HL7 meeting. We had excellent participation for a draft-for-comment ballot: 40 affirm, 81 negative and 51 abstain (for those not familiar with HL7 balloting, those are pretty good numbers, and we would expect most of the negatives to be withdrawn, though that’s not actually required for draft-for-comment ballot).

There were plenty of line items (319) – including a number that focused on Normative process issues, and some that caused significant debate.

The main take-away from the meeting is that we expect the normative ballot to go ahead as planned, though we are taking the opportunity to do some formal consultation around a few contentious issues – see below.

Clinical Notes

There was plenty of discussion at the meeting about how to best represent ‘Clinical Notes’ in FHIR. One of the problems with this is just what is a clinical note? there’s such a wide array of meanings for ‘clinical note’ from a few sentences written into a record, to a carefully constructed narrative letter to a fellow clinician, through to a fully structured
data rich transfer of care.

It’s clear how some of these things are represented in resources, but not all of them, and there’s no single coherent picture – though it’s not clear whether there should be. We had a lot of circular discussion, and we didn’t come to any strong conclusions, but we did agree that we will construct a connectathon track around this question to further investigate the optimal solution.

Mother/Child

We’re seeking comments about how to understand record keeping around the relationships between mother and child. The health, treatment, and records of mother and child are deeply linked, but there is real variation between jurisdictions and institutions about how privacy is maintained, and how the links are represented. There’s some previous work in HL7 on this, and in other organizations – we’ll be revisiting
this subject, and seeking comment, and making a proposal for how these links should be represented in FHIR Resources.

Community Consultation

There are 4 items for which we are seeking community consultation on the basis that they represent breaking changes to FMM4-5 level artifacts. Comment is sought from anyone who has implementations that are impacted by the following changes.

Note about this: if we’ve gone to the trouble of making breaking changes and then seeking feedback about them, you should assume that they are potentially pretty significant, and investigate. Don’t regret not paying attention later.

Note also that we could just ballot these as part of the normative ballot, and call that the formal consultation, but we’d rather get comments on them immediately in case they change our mind about what to take to ballot.

Please submit formal feedback to fhir-director@hl7.org by CoB Friday 23rd Feb. (or join discussion at https://chat.fhir.org)

1. Removal of default values

A series of gForge tasks and ballot items related to the practical implications of missing values, and in particular default values. After long discussion at the New Orleans meeting (3 whole quarters!) we propose to make the following changes prior to ballot:

• Remove ElementDefinition.defaultValue[x]
• Clarify that ElementDefinition.meaningWhenMissing should only be documented when it says something of substance
• advise committees not to create models where meaningWhenMissing is important (where possible)
• Committees will review elements that currently have default values with a view to making them mandatory

This actually has fairly far reaching impacts. To help reviewers, here’s the current list of elements
that have a default value assigned:

• SampledData.factor: 1
• ElementDefinition.slicing.ordered: false
• ElementDefinition.type.versioning: either
• ElementDefinition.mustSupport: false
• ElementDefinition.isModifier: false
• ElementDefinition.isSummary: false
• Timing.repeat.frequency: 1
• BodyStructure.active: true
• CarePlan.activity.detail.prohibited: false
• ConceptMap.group.element.target.equivalence: equivalent
• Condition.verificationStatus: unknown
• Consent.provision.action: all actions
• Consent.provision.data: all data
• ExpansionProfile.includeDefinition: false
• ExpansionProfile.activeOnly: false
• Group.active: true
• Group.member.inactive: false
• HealthcareService.active: true
• ImplementationGuide.package.resource.example: false
• Linkage.active: true
• List.entry.deleted: false
• Measure.subject: Patient
• Media.frames: 1
• MessageDefinition.focus.min: 0
• MessageDefinition.responseRequired: false
• Organization.active: true
• OrganizationRole.active: true
• Patient.active: true
• Practitioner.active: true
• PractitionerRole.active: true
• ProductPlan.status: active
• Questionnaire.item.required: false
• Questionnaire.item.repeats: false
• Questionnaire.item.option.initialSelected: false
• RelatedPerson.active: true
• Schedule.active: true
• ServiceRequest.doNotPerform: false
• Task.priority: If missing, this task should be performed with normal priority
• TestScript.origin.profile: FHIR-Client
• TestScript.destination.profile: FHIR-Server
• TestScript.metadata.capability.required: false
• TestScript.metadata.capability.validated: false
• TestScript.fixture.autocreate: false
• TestScript.fixture.autodelete: false
• TestScript.setup.action.operation.encodeRequestUrl: true
• TestScript.setup.action.assert.warningOnly: false
• ValueSet.expansion.contains.abstract: false
• ValueSet.expansion.contains.inactive: false

 

… quite a lot, as you can see. This is a significant change. GForge task 15121

2. Addition of Reference.type

The FHIR-Infrastructure committee has decided to bring back an element that we removed very early in the FHIR process: Reference.type, it will be a code, bound to ResourceType, with a cardinality of 0..1. If present, it has to be consistent with the actual reference. Adding Type like this may have unexpected consequences, so while this isn’t strictly a breaking change, we want to seek opinions on this. GForge 13543

3. Removing Patient.animal

We have received a few items of feedback regarding the inclusion of the animal part of the Patient resource which the Patient Administration workgroup would like some additional feedback from the FHIR community prior to making a final decision for the normative definition of Patient.

There is no argument that the animal component is not part of the 80% (as per normal FHIR guidelines) and has been an intentional exception to the rule, the desire being to make a definitive statement that veterinary usage is a part of the scope of FHIR.

Most systems will either be all human, or all animal (veterinary), and not both. However systems like lab and pharmacy do handle both human and animal content.

So what’s the issue then?

1. The Patient resource is going normative, and this part of the resource has not been adequately tested/verified with real systems (which is a part of the FMM progression scales)
2. The current backbone element is marked as a modifier element, which isn’t a modifier like anywhere else in FHIR. Other properties that are modifiers impact how to interpret the resource itself. For Patient, it impacts how you might interpret other resources.
3. Patient Administration is missing feedback from the many sides of veterinary – domestic and agricultural. The content we currently have appears to satisfy the domestic side of things (pets etc) but not clear how this would work with herds or exotic species.

Resources: GForge Tasks: 14880 Move Patient.animal to a standard extension and 14393 Patient.animal needs a meaning when absent &  Discussion

4. URLs vs References

We previously sought comment about gForge task #12902. Feedback from implementers has caused us to revisit this proposal again – look out for a post about this on my personal blog.