Category: Meeting Report

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

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.

 

FHIR Product Director’s Report from 2017 Sept (San Diego) Meeting

Last week, the HL7 and FHIR communities met for the annual Plenary WGM. This time, the meeting was held at the Hyatt Regency La Jolla, which was a great facility for the HL7 meeting. Thanks to Mary Ann Boyle, who’s taking over from Lillian in organizing the WGMs – they are a big event to organize.

HL7 Formal Strategy

The HL7 Board announced its core strategic goals during the Plenary session:

  • Enhance the public image and achieve recognition by stakeholders as the leading SDO for worldwide health data interoperability standards
  • Secure long-term sustainable revenue to realize the vision and improve customer experiences (internal and external)
  • Establish FHIR as the primary standard for global health data interoperability
  • Enhance and maintain quality of and accessibility to HL7 standards in current use

With regard to the FHIR specific goal, the board provided these strategic objectives:

  1. Increase understanding of FHIR usage and value of usage worldwide (Immediate)
  2. Achieve symbiotic link of brand and financial benefit between HL7 and FHIR.(Immediate)
  3. Demonstrate the value of FHIR in enabling interoperability (Midterm)
  4. Ensure resources are most effectively focused to enhance FHIR (Midterm)

As you can see, FHIR is front and center… I guess we’re all going to be busy in the coming year making this strategy a reality. At a later time I’ll blog about how we can realize these goals.

FHIR Foundation

The FHIR Foundation is now ready to take members. You can sign up here. The annual fee for individual members at this time is US$250. For that, you get:

  • The knowledge that you’re helping maintain the viability of the FHIR ecosystem
  • Access to the Product Director’s monthly report summarizing the FHIR community progress
  • Access to member’s forum (discuss future of the FHIR Foundation)
  • Access to the member’s market place where job/contract opportunities are
    publicized (and these are starting to flow)

We’ll be adding new additional benefits in the future, as discussed with members. We’re hoping that individual memberships will cover the basic year to year costs of keeping the FHIR Foundation viable (legal/accounting fees etc).

The FHIR Foundation isn’t yet ready to open for organizational members, but it’s our intent that we will be soon. We believe that any company or institution selling services related to FHIR (consulting, middleware, implementation tools etc) will want to be part of the FHIR Foundation, and we’re working on services related to  that now. Note that this is not the same as providing healthcare services using FHIR interfaces, though of course we’ll be building membership benefits for those kind of organizations too.

One again, the FHIR Foundation thanks Google for providing the cloud infrastructure on which the fhir.org services are hosted.

Connectathon

The meeting started with the biggest connectathon we’ve had to date – we had over 218 attendees. It’s become clear that we need to rework the way connectathons are managed – we need more organization and more preparation, as they continue to grow. With that in mind, we’ve asked whether anyone is interested in taking on a formal role as the event organizer (If you’re interested, contact me directly).

There were 22 proposed connectathon tracks for this connectathon. At least 2 of them didn’t get enough participants to get off the ground when it came to it, but most did. Each track provided a very brief summary presentation of outcomes, some of you can find in the links below.

As always, the connectathon is very important to us as a way to validate how the specification works. We will continue to add new streams as our community interests broaden. I plan to blog about some of the streams individually, and some streams have already blogged.

Reports and Blogs:

Clinicians on FHIR

The meeting closes with the Clinicians on FHIR event, where we engage Clinicians by working with ClinFHIR to record real clinical cases with the purpose of identifying gaps or deficiencies in the FHIR specification. This was our 10th event. The organizers of the CoF are developing processes to more clearly document clinical scenarios, testing, and feedback to the FHIR development process, and as part of that, we held a new breakout session for Beginners to help get them up to speed on the process.

The Clinicians on FHIR is another important way for us to validate how the specification works.

SMART App Launch Ballot

The Smart App Launch Specification was balloted in the lead up to this meeting. We received plenty of ballot comments, which is great. We’re confident that we’ll be able to publish the first STU for this specification later this year. Most of the comments related to clarification and clarity in the specification, though we’ll be noting some open issues to work on for future versions of the specification.

Community Consultation

Part of the FHIR Maturity Process is that once an artifact is at level 4/5, breaking changes require formal community consultation. In the next week, I’ll be issuing requests for comment on (at least) the following breaking changes:

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

Notifications on these will be provided in the following places:

Normative Plans

Overall, our plans are unchanged from last time, though we’ve clarified the
time lines. High points:

  • Draft for comment, Dec/Jan: lining up for ballot
  • Mixed normative/STU, Apr/May: Main normative ballot
  • 2nd Normative + STU, Aug/Sept: 2nd chance ballot
  • Publication Mid-Dec

Those are pretty firm deadlines – we’ll slip normative content back to STU rather than hold up the timeline, since various jurisdictions and consortium initiatives are synchronizing their timelines to this (though HL7 can never provide any firm promises in this regard – we have to follow our processes)

A few additional resources are being considered candidates for normative. Last call for comments about which resources should be candidates will be in November (watch this space). After the draft for comment goes out, resources can be dropped from the normative list, but not added.

Bulk Data

The US ONC has asked to work on adding new capabilities to the FHIR specification to increase support for API-based access and push of data for large number of patients in support of provider-based exchange, analytics and other value-based services. This is a high priority work item for them this year. See write up of plans for further information regarding our proposal – this should lead to a connectathon track at HL7’s January meeting in New Orleans, at which all are welcome.

Tooling EcoSystem

The FHIR tooling ecosystem is starting to fill out quite nicely. In particular, the FHIR registry is now entering pilot mode. Please feel free to use, and (for now) provide feedback through chat.fhir.org.

We’ve been working on documenting the tools we have and need – see the HL7 wiki for further information. This is still draft work, and we’re looking for further feedback and community participation.

Certification

The FHIR Proficiency Certification process was trialed at the San Diego meeting. So far, preliminary results show that we’re broadly on the right track. We still plan to have the certification fully available for the January meeting in New Orleans. Congratulations to

Yunwei Wang, IMO

who was the first person to pass the certification. Intending candidates should note that the test aims to ensure that you are familiar with the scope and shape of the full FHIR specification. Knowing the RESTful API and the resources is not enough for proficiency certification (people who know this stuff well from the connectathons/other implementations will still need to read up on the rest of the specification – terminology, intent, licensing, maintenance procedures, etc).

New Areas for the specification

The HL7 technical committees are taking up new areas of functionality and
adding them to the FHIR Specification as draft/STU for the forthcoming
release 4:

  • Public Health Case Reporting and Reportability Responses (PHER)
  • Occupational Data for Health (PHER)
  • Laboratory Test Catalog (OO)
  • BiologicallyDerivedProduct ( blood transfusion, and hematopoietic cell transplant material.) (OO)
  • Medical Device Nomenclature/Vocabulary Service (Dev)
  • Insurance Plans (FM)

If you’re interested in any of these, please get in contact with the relevant committees.

Forthcoming Events

 

#FHIR Report from Madrid Working Group Meeting

Last week the HL7 Community met for one of our regular working group meetings. This time, we met in Madrid at the Marriott, which was actually a pretty good venue for an HL7 meeting (these are challenging because we want lots of small and medium sized rooms). In particular, the food was excellent. This was also a notable meeting because it’s the last meeting for Lillian Bigham who has organised HL7 meetings for the last 12 years – we’re going to miss her a lot.

As usual, the event kicked off with a connectathon on the Sat/Sun. This meeting set a first for us: this connectathon had fewer participants than the last one – obviously due to the non-US location a lot of regulars didn’t attend.

connectathon

The connectathon as still very productive, with many happy outcomes for the implementers, and further change requests for the FHIR specification itself. Importantly, the set of functionality that the connectathons test continue to broaden.

Product Planning

For the many different committees that manage the various parts of the FHIR specification, this meeting – coming immediately after publishing Release 3 – was an opportunity to make plans for our next release – what features do want in it?

Here is a list of the major features we plan for Release 4:

  • Normative – see below
  • RDF: prototype a solid ontology binding to evaluate how much benefit this might bring
  • Data Analytics: support for a bulk data analysis bridge format (Apache Avro/Parquet?)
  • API: establish better control over retrieving graphs of resources, and value added query support (tabular format?)
  • Patterns: change the W5 framework to a pattern (logical model), tie the patterns to ontology, and use of patterns to drive more consistency (and how to do this without decreasing quality)
  • Services: more business level services. Some candidates: conformance, appointments, personal health data
  • Deployment: get a clear standards path for smart on fhir / cds-hooks (and alignment with UMA/Heart)
  • FM: work on alignment between FM resources and the rest of FHIR

Note that this list anticipates that our normal maintenance tasks will continue to happen, and there’ll still be ongoing changes across the board in response to implementer experience and internal quality processes. (Also, most of these product priorities are already in progress)

Normative FHIR

One of our key plans is that we are going to ballot some of the specification as normative for Release 4. “Normative” means that the content is now locked in and only forwards compatible changes will be made in the future. This means that applications written for an older version will interoperate with the current version (if, that is, certain rules are followed).

This is the current list of artifacts we plan to take normative in R4:

  • Framework / XML / JSON / RESTful API + Search
  • CodeSystem, ValueSet, and possibly ConceptMap. (But not all operations on those resources)
  • Bundle / OperationOutcome / Parameters / StructureDefinition / SearchParameter / + maybe CapabilityStatement/OperationDefinition
  • Patient, Observation

Note that this list won’t be finalized until January, so there’s plenty of time for discussion about this list. You may see some implementation activities driven by this list, as we encourage the community to look at some aspects of these resources in more detail.

Implementation guides and registries

We’ve nearly got all our tooling in place for implementation guides. The final major piece that is missing is registry.fhir.org. We worked hard on getting http://registry.fhir.org ready this meeting, and I’m hopeful that it will be up and running before the September meeting. We also worked on plans for integrating our existing tooling with the registry, and other additional quality processes.

R3 Publication Recognition

A little while before the Madrid meeting, we published FHIR Release 3. Because we did so much QA work, this turned into a massive project, and a few people helped out beyond the call of duty – being available at all times of the day or night. Since these people gave beyond the call of duty, HL7 recognized their efforts:

fhir-hero-contributers

From left: Bryn Rhodes, Eric Haas, David Hay, Rob Hausam, Grahame Grieve (me), Lloyd McKenzie, Brian Postlethwaite, Richard Ettema, Melva Peters, and Michelle (Moseman) Miller

Revised terminology process

During the meeting, we agreed to redesign all the HL7 terminology maintenance to a FHIR based tooling solution. This is part of a wider redesign of the terminology maintenance processes. There’ll be more information about this forth coming.

Quality processes

Most of the planning we did at Madrid for Release 4 involved investing in quality and quality processes. As FHIR as a whole is maturing, so is our understanding of what quality processes we need, and where in the process we need them. Additionally, we are starting to see new content in FHIR that hasn’t been so thoroughly analysed in previous standards (HL7 v2, v3, CDA, etc), such as AdverseEvent, and ClinicalImpression. These resources may need additional informatics related quality processes – this is something we are working on

FHIR foundation

Our plans for membership of the FHIR foundation are also maturing. We hope that membership will be open in the next few weeks – that will enable the foundation to actually start performing some of the functions it needs to do that require funds.

Note that FHIR Foundation board minutes are published on the FHIR Foundation web site.

DevDays USA

The HL7 board agreed that HL7 will hold a FHIR DevDays meeting in USA next year (probably June). HL7 will work with Furore, who organise the very successful FHIR DevDays help in Amsterdam in November of each year.

Changes

A few significant changes were agreed for R4 while in Madrid:

 

 

 

FHIR report from Baltimore meeting

Last week, HL7 held it’s annual plenary meeting in Baltimore at the Hyatt Regency. As usual, the Hyatt Regency’s odd-ball design generated a few comments, but we were not treated to a repeat of the comic-con the weekend before (provided a colorful backdrop to the last Baltimore meeting). I’m pretty sure I heard that this was HL7’s largest meeting ever. What I can say for sure is – accommodation is increasingly hard to get for HL7 meetings; make sure you get in early for the next one.

For the FHIR project, our main attention was the ballot. Across the core standard, and multiple implementation guides, we received >800 detailed comments as part of the ballot. This represents a slight increase over the last ballot, but there was a clear change in the focus of the comments – there was a significant drop in the number of comments relating to the infrastructure, and much more focus on the domain content, and it’s applicability to real world problems. This is a clear marker of the growing maturity of the standard. We continue to expect that we’ll publish FHIR release 3 at the end of this year.

Most of the meeting was devoted to ballot reconciliation, with a focus on the difficult to resolve items. But we got plenty of other things done as well:

  • The FHIR connectathon was out biggest ever, with more streams, more success, more of everything. Note, that the next meeting, in San Antonio, it’s doubtful we can accomodate that many people, so it’s probably going to be a case of getting in early…
  • The clinicians on FHIR event was also a success – well, what I saw of it. But since we’ve had people asking us about the event, and whether they can run their own, we filmed a documentary about the event – thanks to Kai Heitmann for doing that. We’re not planning to post this publicly; instead, if you’re interested in hosting a clinicians on FHIR event, let me know, and I’ll share it with you when it’s done
  • We (members of the FHIR team) met with several new communities that haven’t previously been part of the FHIR community, and planned how they could get engaged, and share their energy and outputs with us. As always this is a collaborative
    process, and I’ll be making more announcements about this going forward
  • We made some specific decisions to change widely implemented parts of the specifications; consultation with the wider community around these changes is ongoing (see “JSON Comments” and “Logical References“). This is reflective of our process towards normative; some of the next version of FHIR (release 4) will be normative. I’ll be making more announcements about how that’s going to work in the future (when we figure it out).
  • Probably the most significant single decision we made was to take the specification known by the obtuse code word “DAF-core” – that’s the spec based on the Project Argonaut collaboration – and rename it to the US realm Implementation guide, of which it comprise be one section, how to represent the Common Clinical Data Set. Over time, the US realm implementation guide will grow to encompass more than just that. (btw, one decision related to this is that we are working to bring the technical specification from SMART that Argonaut used to HL7 as an appendix to the FHIR specification, named something like the “Application Launch Framework”)
  • Finally, the FHIR foundation continues to take shape as a key part
    of the eco-system to support the implementation process of standards
    (as opposed to the actual development of the standards themselves).
    In particular, it looks like we’ll soon be able to set fhir.registry.org
    live, which is a key piece of the FHIR picture that many people are awaiting.

Overall, the FHIR development team (well, teams – there are many interlaced teams with responsibilities for different parts of the specification, the process, and the community) are happy with a gradual progress. While there is still much to be done across all the specification, the plenary meeting marked our 5th year anniversary, and we are proud of what we’ve achieved in that time.