Soliciting Feedback concerning the roadmap for FHIR R5

HL7 is working hard on publishing the next major version of FHIR, which is R5. R4 is the current approved version, and it was published in Oct 2019. Since then, we’ve been working on R5, an incremental release that addresses known issues and adds additional functionality to the standard. We’ve also been working on R4B, a patch on R4 that allows for implementing new functionality while being identical to R4 in the areas that are widely implemented. R4B is expected to be published soon, but we’re not sure what to do about R5. This post relates to our plan for R5.

The (recent) original plan for balloting R5 was that we would perform the normative ballot in the May ballot 2022 (which is actually open in March / April). This would lead to ballot reconciliation at the May WGM, and then further reconciliation processes etc would lead to a full R5 publication, with updates to both normative and trial use content at the end of 2022 (roughly). 

However the work required to actually prepare R5 has been bigger than estimated. This includes both applying previously agreed committee changes, and the underlying tooling work to fix identified issues in the publishing tools, and it’s clear that this work will not be completed in time for the forthcoming ballot March – May ballot. Note that the capacity of HL7 to manage the FHIR publication tooling workload is a known issue that HL7 is working to address.

Because the content will not be ready, FMG has decided that R5 will not be balloted in the May cycle. 

However, we’re close to being ready to ballot, and also, one of the problems of getting R5 ready for ballot is that the resources required for R5 compete with the resources required for IG and other ballot preparation. For this reason, FMG is planning to hold a special ballot cycle through June(ish) to ballot R5. 

During discussion about the challenges of balloting R5, FMG also discussed the benefits of publishing R5 at all. The FHIR community is quite disparate; some users and ecosystems are well into the implementation phase, based on R4, and see no benefit at all from R5, and will be ignoring it – they will reconsider when R6 is published. Other users are very keen for specific changes in R5, and consequently very keen to see it published as soon as possible. Yet more users are spread between those points. But one thing we noted is that few of the users that are keen on adopting R5 are focused on the normative parts of the specification, but it’s the normative parts of the specification that present the most procedural work and risk with the R5 ballot. 

FMG discussed several options around the R5 ballot, and we are seeking feedback from the standards and implementation communities as to which to choose. 

Option #1: Go ahead and publish R5 with normative content

This option means that we go ahead and publish R5 as close to the current schedule as possible – early in 2023 (the original schedule slid due to covid – both the direct and indirect impacts. The current schedule had us publishing R5 in late 2022). We will work to get R5 as solid as possible knowing that some implementations will migrate to R5 with plans to hold the normative portions of the implementation forward compatible from R4 forwards.

Option #2: Hold R5 off completely

For this option, we decide that we’re just going to publish R4B (which will be in March/April) and that will have to be enough for the implementers keen on something after R4, and we’ll wait longer for R5, letting the debates around the normative content pieces mature further before releasing an R5, expecting that the R5 release will be bigger and more authoritative. This option might imply that there’ll be an R4C after R4B, for instance, though the limitations on R4B mean further follow ups in that chain are marginally useful.

Option #3: Publish R5 as “trial-use”

In this option, we go ahead and publish R5 as soon as we can – hopefully towards the end of this year, but call all of the R5 changes ‘trial-use’, even the changes made to the content presently labelled normative. This allows us to test out changes to normative content but then make further changes before calling the changes ‘normative’ in R6. This reduces the procedural load associated with R5, and it appears reasonable to expect that we would get it published this year 

FMG is seeking feedback on this question prior to 4pm Eastern Wed 9th March. Feedback may be made by email to fmg-contact@hl7.org, fhir-director@hl7.org, or by joining discussion at R4A/B/R5 Discussion

Product Director Report for Atlanta (Sept 2019)

This week, the HL7 and FHIR communities met for the annual Plenary WGM at the Atlanta Marriott Marquis.

Connectathon / Meeting size

The connectathon had 413 participants which is significantly bigger than our previous biggest connectathon:

2019_09_connectathon

A few people asked me whether the connectathon is going to get bigger than the main HL7 meeting, but that won’t happen because many connectathon attendees stay on for the main meeting, and this was also the biggest HL7 meeting ever with almost 800 participants.

I think that this is natural; as digital transformation starts to bite into the healthcare eco-system, there’s naturally and appropriately more interest in HL7 and other digital health standards organizations, given the key role digital health standards will play in the future.

The FHIR program is a broad and swiftly moving river now – there’s such a lot going on that there’s simply no way to summarize everything. Across the community, we reviewed hundreds of change proposals, discussed design paradigms, development methodology, governance approaches, and performed technical clinical testing/validation. But there’s some notable outcomes to report on.

FHIR Publishing Plan

Previous, I wrote that R5 would be expected to be published in Q3 2020. I also said that:

We will be surveying our members and partners later this year to determine whether our normal cycle is appropriate, or whether the community would prefer for us to wait longer to publish so that there can be more convergence on a single version

We will still survey our members and partners later this year, but the emerging consensus in our community who were at the meeting this week is that we’d be better to focus on quality and testing and that there’s no great need to publish in Q3 2020. At this meeting we agreed that we won’t start the publishing preparation cycle until after the next meeting (which is in Sydney in early February 2020). That means that the earliest we can publish is now Jan 2021, though we have not yet committed to that date.

The  overall R5 roadmap hasn’t changed much other than the changes to dates.

We are planning to publish a Technical Correction in a couple of weeks times which addresses a number of issues in the published R3 and R4 specifications. I’ll post about this once we release the changes.

Patient Merge

One strong theme that attracted a lot of attention this meeting was dealing with Patient Merge. This has emerged as a significant safety issue in real world implementations of FHIR, so we are seeking to provide guidance, and possibly normative standards, around how Patient merge works, and manifests on the FHIR RESTful API. IHE is also looking at publishing Patient merge related specifications, and we’ll be working with them.

The challenge here is that Patient Merge/Unmerge (or link/unlink) is a difficult challenge with all sorts of incompatible solutions deeply embedded into healthcare institutions. So it’s not going to be easy to solve, but it’s certainly very important. I’ll blog about the technical issues associated with Patient Merge in the future.

Patient Advocacy

HL7 supported ePatient Dave to attend this meeting. You can read Dave’s writings about why he’s involved with HL7 in his blog. At the request of the board, HL7 is planning to create a formal Patient Advocacy / Empowerment group to represent patient interests.

I think that this is important because while it might be true that we are all patients, we haven’t all experienced healthcare in the turns people into focused advocates. A focused group that is organised around representing patient interests is just as a good idea as separating out your governance, management and methodology.

Based on discussion this week, probable interests for a patient advocacy group might include:

  • Reviewing work products of other work groups to identify places where a patient perspective might enhance the value or success of the work
  • Engage with other work groups to provide support in the way of patient scenarios, evaluating language for accessibility, providing perspective on patient considerations, etc.
  • Developing informative guidance for patients, caregivers, practitioners and developers related to patient/caregiver facing applications, data access and use
  • Developing or assisting in the development of specifications for patient managed data (e.g. patient diaries)

If you’re interested in this activity, join us on our chat.

Clinical Genomics Changes                

Turning to a specific technical issue, the Clinical Genomics (CG) workgroup has asked to correct several canonical URLs in the terminology list:

That is, remove the trailing slashes. The trailing slashes appear to be have been introduced into the R4 spec as an editorial error.

We have approved making this change as part of the technical correction due out in a couple of weeks if we can be sure that this change will not impact on implementers by 27th Sept. If you are an implementer that uses one of these code systems, please contact Patrick Werner ASAP.

FHIR Accelerators

One really active area of development in the HL7 community is the FHIR Accelerator Program. The HL7 FHIR Accelerator Program is designed to assist implementers across the health care spectrum to work with HL7 to create of FHIR Implementation Guides or other informative documents

The current Accelerators are:

Additional Accelerators will be announced imminently.

In the future, I’ll include notes from the Accelerator projects as part of the meeting reports.

See you all in Sydney, Australia in February 2020.

FHIR R5 Roadmap

General

Now that we have published FHIR R4, our attention at our January 2019 meeting (in San Antonio) was focused on producing a roadmap for FHIR R5.

FHIR R5 will build on R4 by:

  • Moving more content to formal Normative status
  • Further improving the support for publishing implementation guides
  • Adding additional content in newly developing domains
  • Improving support for applications using multiple FHIR releases seamlessly, and also multi-language support and federated servers
  • Adding new facilities for migrating data to and from v2 messages and CDA documents

In addition, the community will continue to develop the adjunct specifications to FHIR – SMART App Launch, CDS Hooks, FHIRCast, CQL,  Bulk Data specification, and others – that build out a complete API-based eco-system for the exchange of healthcare data.

HL7 will also continue to collaborate with our many partners across industry, government, and academic communities to support the overall development of data exchange and health process improvement.

Implementation Guidance

We expect some specific implementation guidance to arise out of our collaborations and both ongoing and new projects that will lead to better processes in healthcare:

  • Use of Smart App Launch, FHIRCast and combinations of the FHIR and DicomWeb stacks to lead to better imaging related workflows
  • Build in on initial Public Health collaborations to further improve bio-surveillance and morbidly/mortality reporting
  • Improved integration around prior authorization and financial processes
  • Finalize detailed genomic reporting specifications ,and develop processes to integrate translational science into operational healthcare
  • Provide access to the complete medical record for a patient

Timeline

Our normal cycle is about 20 months, so R5 would be expected to be published in Q3 2020.

We will be surveying our members and partners later this year to determine whether our normal cycle is appropriate, or whether the community would prefer for us to wait longer to publish so that there can be more convergence on a single version.

In addition, we may consider publishing patch releases that introduces changes only to the draft resources, since these are earlier in their maturity process, and changing more quickly.

Committee plans

FHIR is maintained by a set of committees, each responsible for a portion of the specification. Here are further details for the roadmap by committee:

  • Biomedical Research and Regulation aims to have the ResearchStudy and ResearchSubject advanced to maturity level 5 and will continue to work on the regulated product-related resources
  • Community Based Collaborative Care aims to bring Consent resource to Normative status for patient-privacy and will work on resolving the Research, Advance Directives and Treatment use cases
  • Clinical Decision Support and Clinical Quality Information aim to support the representation and sharing of clinical knowledge that enables a continuous quality improvement cycle and pilots of the same (e.g. business as usual)
  • Clinical Genomics will continue to work on refining MolecularSequence, rationalise the existing genomic content to the Genomics Reporting IG, and work with patient care on the family history pedigree representation/profile
  • FHIR Infrastructure’s focus will include reviewing the trial use parts of CapabilityStatement, improved facilities for managing Composition content (including use of GraphDefinition), Subscriptions, and Digital Signatures
  • Financial Management goals are to bring the eClaims resources to Normative status, and continue to be develop the other resource
  • Imaging Integration anticipates defining new resource “SpecificImageReference”, and profiling DiagnosticReports, Observations, and Procedures for imaging use cases, potentially producing formal profiles
  • Orders and Observations aims to bring DiagnosticReport and Device to Normative status, and to work on resource scope/boundaries for a number of resources
  • Patient Administration aims to bring several resources to normative status – including Encounter, improve the linkage between the administrative and financial domains, along with defining the patient merge/link functionality and completing the VhDir Implementation Guide.
  • Patient Care: Patient Care is targeting several resources to go normative, and working to increase the maturity of other resources, with a focus on care planning
  • Public Health will continue to evolve Immunization resources as experience is gathered by implementers and also support parties interested in writing FHIR IGs in the public health domain
  • Pharmacy continues work on the MedicationKnowledge resource and will work with the community to mature the existing medication resources. The Medication, MedicationRequest and MedicationStatement resources may be normative candidates in the R5 ballot.
  • Structured Documents: Consider DocumentReference for normative, and decide what to do with DocumentManifest
  • Security WG will focus on gaining confidence in AuditEvent Resource, Provenance Resource, and Signature datatype. New work will focus on Implementation Guides on Basic Provenance use, new operations to support GDPR (e.g. $erase), and Document Digital JSON Signature
  • Vocabulary: In addition to maintaining existing terminology content and processes, vocabulary will focus on finalising ConceptMap, business rules for Code System Supplements and terminology identifiers, and start working on support for Code system maintenance and development

Normative Resources

Normative resources are maintained for stability so that implementers do not have to rework existing software as new FHIR versions are published. Before bringing a resource to normative status, we require considerable real word experience to demonstrate that the design is robust and ready to be made stable.

We will work to bring the following resources to normative status for FHIR R5. Note that this is not a commitment; whether a resource will achieve normative status depends on how implementation experience unfolds.

  • AllergyIntolerance
  • AuditEvent
  • CareTeam
  • Claim
  • ClaimResponse
  • ConceptMap
  • Condition
  • Consent
  • CoverageEligibiltyRequest
  • CoverageEligibilityResponse
  • Device
  • DiagnosticReport
  • DocumentReference?
  • Encounter
  • ExplanationOfBenefit
  • ImagingStudy
  • ImplementationGuide
  • Location
  • Medication
  • MedicationRequest
  • MedicationStatement
  • Organization
  • PaymentNotice
  • PaymentReconciliation
  • Practitioner
  • PractitionerRole
  • Procedure
  • Provenance
  • Questionnaire
  • QuestionnaireResponse
  • SearchParameter
  • Subscription
  • VisionPrescription

FHIR R4 is published

HL7 is pleased to announce that FHIR R4 is now published.

R4 is the culmination of 18 months of extensive work to finalize the base parts of the specification, and incorporate changes and enhancement requests received from implementation partners across the world.

The most significant change in FHIR Release 4 is that the base platform of the standard has passed a normative ballot, and will be submitted to ANSI as a normative standard. This means that future changes should be backward compatible, so that applications that implement the normative parts of R4 no longer risk being non-conformant to the standard. The following portions of the standard are now normative:

  • The RESTful API, the XML and JSON formats, and the basic datatypes
  • The Terminology layer (CodeSystem and ValueSet)
  • The Conformance Framework (StructureDefinition and CapabilityStatement)
  • The key resources Patient and Observation

Thousands of other R4 updates and changes have been made in response to implementation experience and quality review processes.

FHIR Release 4 marks a significant milestone with the introduction of a normative base. This new maturity will help support our very active and growing community

Credits

Publishing a new Version of FHIR is a massive piece of work involving  a big community. It’s impossible to track – let alone acknowledge – everyone who’s contributed to publishing FHIR R4. We’ve given it a go in the credits page.

Question: Publication Date for FHIR R4

Question:

Do you know if there is a firm date set for R4 being released? Or a timeframe? I have not been able to find any dates when searching online.

The short version is that we inted to publish Release 4 at about the end of this year. We still don’t have a precise date yet – it’s subject to going ballot and feedback, and we have processes that we have to follow and how long they take depends on the feedback we get.

You can see the full details of the schedule on the FHIR Wiki

Report from 2018 September Working Group Meeting

This is the product director’s report from the 2018 September Working Group Meeting, held in Baltimore.

Ballot Status

Our focus this meeting was ballot reconciliation for the R4 milestone. We balloted R4 in 5 parts:

  • Infrastructure – RESTful API, formats, data types, etc
  • Terminology and Conformance – Profile/Extension definition framework, and Code system/Value Set
  • Patient
  • Observation
  • Everything else (‘core’)

The first 4 ballots were normative, which is an ANSI term for a full standard. That means that we’ll be more tightly constrained in the types of changes we can make – generally “no breaking changes”.

Negative comments for the Infrastructure and Patient ballots were able to be resolved without making substantive changes. However, for both Terminology and Conformance, and Observation, ballot reconciliation and editorial review led to 2 substantive changes each. As a consequence, we’ll be re-balloting a total of 4 substantive changes in an out-of-cycle ballot from Nov 6th to Dec 6th. These ballots are only on the 4 specific changes, and ballot responses may only be provided by the members who participated in the prior 2  ballots for FHIR R4 (so there’s no additional sign-up allowed during the “notification of ballot period”).   If you signed up for the Sept. ballot but did not vote, by default you won’t be able to vote in this third ballot.  However, if you’d like to be reinstated in the pool for this out-of-cycle ballot you should submit an appeal HL7 HQ.

We’ll be very strict about scope for this third ballot.  You’re free to submit feedback about the specification for consideration for R5, but we won’t be accepting any feedback for R4 as part of the ballot process other than comments specifically related to the 4 changes up for review.

Recirculation ballot: if there are any negatives that are not withdrawn from our normative ballots for the FHIR content, then HL7 will conduct a special vote amongst the members that balloted on the document to check that they will agree with the committee’s disposition of all non-withdrawn negative comments.  It provides all ballotters a chance to adjust their final vote – changing it to affirmative or negative.  The recirculation process adds 2 weeks to the publication cycle, pushing it into the Christmas period.  We’ll be talking with negative ballotters about whether they’re comfortable withdrawing their negatives votes so we can avoid this extra step if at all possible.

The final decision on pass or fail is based on the final count of votes for the final vote for each ballot grouping (Sept. for Infrastructure and Patient and Nov. for Terminology/Conformance and Observation) as adjusted by recirculation if that occurs.  If we get 75% affirmative votes, the content will pass.  If not and we pass by 60%, we have the option of publishing as STU instead.  If that doesn’t happen, then we’re faced with a brand-new ballot cycle.  We therefore encourage all of those who are part of the ballot pool to participate in the November cycle and, if necessary, the recirculation process, to ensure that the outcome reflects the will of the community.

Despite this complexity, we are still hopeful we will gain the support of the community so we can publish the final version of R4 in late December this year.

Fire Alarm

There was a fire alarm during one of the committee meeting slots. (yes- a real fire alarm, but as you can imagine, there was a great deal of joking about FHIR alarms). Here’s a photo of the FHIR-I committee demonstrating committee best practice by continuing the meeting in the park outside the hotel:park-work

Quote from Michel from Firely: “Fire will not keep us from completing FHIR!”

.. and that serves as a great example of the spirit of the whole meeting. (btw, it was a false alarm)

Roadmap planning

It’s a few years since HL7 published a road map for the FHIR specification and community. We’ll be working on this in the lead up to the San Antonio meeting in January, and I’ll be publishing a formal roadmap soon after.

We’re getting strong feedback from the market about FHIR: the potential is great, but there are plenty of deployment and adoption issues. Of course, that’s not a surprise, given what we know of the healthcare system. Part of the roadmap will definitely be focused on identifying technical barriers to adoption and working with the market participants to resolve those (through new standards, connectathons, and supporting regulatory and market initiatives).

Connectathon

The connectathon at the start of the meeting was our biggest ever – 286 listed participants:

connectathon progress

h/t Sandra Vance for the graph and for administering the connectathon again.

I’ve given up trying to even track the sheer variety of activities that are taking place at the connectathon – it’s a remarkable gathering of thought leaders and doers. But here’s some of the subjects that were worked on at the connectathon:

  • CDS Hooks (the biggest track, as usual)
  • Bulk Data / Data Analytics support
  • Accessing Clinical Notes from EHRs
  • Subscriptions / Application Synchronization
  • Questionnaires
  • International Patient Summary
  • Practical security of data exchange
  • Document handling
  • Evidence Based Medicine
  • Public Health case reporting
  • Clinical Research
  • … and many more

Implementation Guides

FHIR is a platform standard – a set of APIs and content models for supporting healthcare across the world. A few implementations (clinical data repositories, personal heath repositories) can use FHIR just as it is. But as soon as you start dealing with applications that depend on each other, or with clinical workflows, then you need additional agreements on top of what everyone agrees to internationally.

We call the documents that publish these agreements ‘Implementation Guides’ and they include a combination of:

  • Human readable documentation (web site) and computer readable documentation (in an NPM package)
  • Profiles and extension definitions
  • Value sets, Code Systems, mappings between code systems
  • API definitions & Choreography
  • Examples & Test Scripts (and conformance requirements)
  • Security and deployment agreements.

We’re still maturing our overall tool chain and publishing support for these documents – while we’re scaling up our ability to produce, review, and publish them. We’ve felt some growing pains around this process and we’re continuing to refine our tools and processes.

We’re going to see a lot more of these in the coming year. The September 2018 ballot included 14 implementation guides along with the core FHIR specification – and reconciliation is proceeding.

Note that publishing implementation guides is not a goal in itself; an implementation guide only has value if there’s a community that cherishes it, abides by it, and maintains it over time. One priority as we mature our processes is to ensure that this community perspective is maintained.

Personal Note

We’re just about finished publishing FHIR R4, our first with some normative content. All the signs are that it’s going to be a landmark milestone. Indeed, the opening of the HL7 WGM coincided with a pivotal blog from ONC that FHIR adoption is at an inflection point in the USA.  It’s been a remarkable ride, and I look back on it with amazement. The real strength of FHIR is not the technical spec (though I’m proud of that), it’s the community: thousands of people contribute to the FHIR community development process, many going far beyond the call of duty.

Together, we’re going to change the world.

 

Community Consultation: URLs vs References

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

Report – January 2018 meeting + Community Consultation

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:

IMG_1837

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:

 

… 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.

FHIR R4 Ballot & Community Consultation

The first of the R4 ballots is about to open. This is an important release cycle for the FHIR Communtity: it’s the first normative ballot cycle, and some of the FHIR content will be balloted as normative. Notes of interest:

  • This particular ballot is the first of three ballots to lead to the normative parts of R4
  • Once the parts finally become normative, there can be no breaking changes in those parts (well, it’s kind-of possible, but it takes multiple cycles and years)
  • Any substantive change during ballot reconciliation requires reballot – therefore committees balloting normative content will be highly motivated to refuse proposals for change
  • After this draft for ballot, there is no way to change what is selected to be balloted as normative or not for the rest of this cycle, nor to make substantiative changes to it

So we are looking for good review on this draft for comment ballot on the following things:

  • What content has been selected for normative
  • How the normative status is presented (clearly, hopefully)
  • The technical content of the normative material
  • Any suggestions for content that needs further implementation experience in the next few months

If you want to join in, and you haven’t already signed up, well, the ballot sign-up closes today. If you missed out, you can still comment through gForge.

Here’s some of the significant changes that have come with the introduction of normative content:

  • Every page has a clearly marked status now
  • There’s colors and markers for status (see here, here,  here, and here for examples)
  • The ballot introduction explains the division of the FHIR specification into different packages, and the concept of ‘mixed status resources’

Along with the publication of the First R4 ballot, it’s time to do another round of consultation about proposed breaking changes to FMM4/5 content – almost all of which is slated to go normative in R4. Here’s a list of the change proposals:

  1. Include the PractitionerRole as an alternative target type for the Patient.generalPractitioner reference (GF#14224)
  2. Change the URL of the brithplace extension from ‘http://hl7.org/fhir/StructureDefinition/birthPlace’ to http://hl7.org/fhir/StructureDefinition/patient-birthPlace. (GF#12974)
  3. Change ElementDefinition.type.targetProfile from 0..1 to 0..* (GF#12465)
  4. 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)
  5. Add ElementDefinition.isModifierReason (0..1 string)  and possible replace .isModifier (GF#13065)
  6. Rename OperationDefinition.parameter.profile to OperationDefinition.parameter.targetProfile (to be consistent with ElementDefinition) (GF#13561)

If you’re an implementer who is affected by one of more of these changes, and you want to express an opinion, then send an email about the change to fhir-director@hl7.org, describing your implementation, how the change impacts on you, and your opinion on it. Notes that some of these are pretty arcane things only of interests to a few toolsmith type people, so if you don’t know what they, that’s not a problem. Also, strictly, #2 is not a FMM=4+ change, but the PA work group wanted to seek opinions anyway. Given where we are in the ballot cycle, and holidays etc, this comment period is open until Friday Jan 26 (noon Eastern) – close in time for the HL7 Workgroup meeting.

Btw, outcomes from the last round of consultations:

  • Renaming ValueSet.compose: Community input was negative, and the committee didn’t make the change (we’re going to rename $compose instead)
  • Use of Observation.related and types: Community input was muted but leaned positive, and the change is included in this ballot publication
  • Adopting GitHub Flavored Markdown: community input was positive, and this change will be adopted (but hasn’t been applied to the specification and tools yet)

 

 

 

Proposed Breaking changes for FHIR R4

According to the FHIR maturity model that is part of the FHIR development process, we must consult the community if we are going to make breaking changes to artefacts that are labelled level 4 or 5 maturity (though there’s some lack of clarity as to what exactly is a breaking change, and what the right process should be).

At the recent meeting in San Diego, a number of breaking changes to maturity 4/5 resources were proposed, and we are seeking feedback on these:

  • Rename ValueSet.compose to ValueSet.definition (Vocab)
  • Question on the use of related types with Observation (OO)
  • Proposal to adopt GitHub Flavored Markdown (FHIR-I)

In addition, while we are consulting, we are seeking feedback on an additional change:

  • Proposal to remove ImagingManifest (II)

Each of the changes is described below, along with the proposed justification. If you have already implemented systems that will be impacted by these changes, and you’d like to have your say, please send an email to grahame@hl7.org by Friday 20th October that details your implementation, the impact the change will have, and your opinion about the change.

Note: if you don’t have an actual implementation, and you still have an opinion, we’d still like to hear it – you can let us know through one of our normal channels (see fhir.org).

Renaming ValueSet.compose

ValueSet.compose is a verb — “compose the value set this way”, but that’s not language that connects with the wider community as well as ValueSet.definition would – “this is the definition of the value set content” (which is the “Content Logical Definition”) in the Vocab work group’s wider value set work). Also, ValueSet.definition matches ValueSet.expansion grammatically. Finally, ValueSet.compose overlaps in name with the $compose operation.

For these reasons, the work group would like to rename .compose to .definition. There’s no other semantic changes – it’s just a straight rename, to reduce confusion.

Note that ValueSet is planned for normative in R4 – there won’t be any other chance to make this change.

Use of Observation.related and types

Are you using Observation.related? how? The Orders and Observations Work Group.is considering removing .related and replacing it with:

  • member : Observation 0..*   type: Reference(Observation)
  • derived: Observation 0..*  type: Reference(Observation)

The other things related does would be relegated to extensions, or to the Provenance resource. The task proposing this (GForge #10118) was discussed at the Sept WGM by the Orders and Observations Work Group and is the direct result of internal FHIR methodology review and discussion which resulted in a proposal to substantially change the .related structure. This would simplify the structure of Observation, but the OO work group has been hesitant to make a significant change without meaningful implementer input.

Because our past attempts to get implementer feedback by reaching out to the FHIR community did not result in any response, the work group has deferred this tracker several times. As the Observation resource approaches normative status, there is increasing concern regarding making substantive changes. Implementer feedback is sought regarding whether that perceived benefits of this proposal is outweighed by the costs it imposes on implementation.

Adopting GitHub Flavored Markdown

Currently, the markdown data type specifies that the content is Gruber’s original markdown syntax, with an STU note soliciting feedback about adopting CommonMark instead. Feedback on this has generally been in favor of adopting commonmark, except that it doesn’t support tables, and it allows raw HTMlL. The community has indicated a strong preference for GitHub Flavored Markdown (GFM), and we propose to adopt this as a replacement. Note that the table extension in GFM are likely to find their way into commonmark, which would mean that we’d be using CommonMark with a profile that says ‘no HTML’

In practice, this will mean updating some existing code – e.g. a different markdown processing engine, and different generation, though the markdown syntaxes are somewhat compatible, and markdown degrades gracefully anyway.

Note, again, that the markdown data type is slated to be normative next time, so there’ll be no more opportunity to make this change. (though we could settle for pure CommonMark if the GFM extensions are brought into CommonMark – that would be a non-substantiative change). For further discussion, see chat.fhir.org

Proposal to remove ImagingManifest

The II committee (joint between DICOM and HL7) would like to remove the ImagingManifest resource. It’s a little hard for most implementers to differentiate between ImagingStudy and ImagingManifest, and the DICOM use cases for which ImagingManifest was defined (XDS-I) have been replaced by MHD-I which uses WIA (Web Image Access), leaving the use case for ImagingManifest somewhat obscure.

Hence the proposal is to remove ImageManifest and ensure that ImagingStudy can meet the identified needs.

Note that this is not a change that affects a maturity >=4 resource, so community consultation is not needed. However the committee asked for wider feedback. For further discussion, see chat.fhir.org