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.
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.
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.
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 email@example.com 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?
- 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)
- 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.
- 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.