#FHIR Paradigms

Many of the FHIR tutorials show this diagram:

The goal of this diagram is to show that FHIR defines 3 different ways to exchange FHIR resources:

  • Using the RESTful interface – the most high profile way to exchange data
  • Packaging the resources in messages, and pushing them between systems (similar architecture as HL7 v2)
  • Packaging the resources in documents, with a managed presentation (similar architecture as CDA)

Also, what this diagram is intending to show is that in addition to the 3 ways defined by the FHIR specification itself, there’s other ways to exchange resources. Since the most common alternative method is to use some enterprise web services framework (say. some kind of SOAPy thing) – we called it ‘services’.

But that’s misleading; a ‘service’ is some orchestration of exchange of FHIR resources, and most implementation projects build their services using some combination of RESTful interfaces, messages, and documents, along with other methods of transfer. And that’s a combination that the FHIR community thinks is perfectly valid. So calling the 4th ‘other’ category “services” is… misleading… to say the least.

However there’s something beyond that missing from this diagram. In the last year or so, the FHIR community has gradually become more focused on what is emerging as a distinct 4th paradigm: using persistent data stores of some kind or other to exchange data between systems. Classically, this is associated with analytics – but it doesn’t actually need to be. The typical pattern is:

  • Create some kind of persistent store (can be an SQL database, a nosql db, a big data repository, an RDF triple store)
  • Applications generating data commit resources to the store
  • Applications using the data to the store find and retrieve data from the store at a later time

We haven’t really acknowledged this paradigm of exchange in the specification – but it’s what the RDF serialization is really about. And all the uses I’ve seen have one uniting characteristic: there’s a need to reconcile the data when it is committed, or later, to help with subsequent data analysis. There’s 2 kinds of reconciliation that matter:

  • detecting, preventing or repairing duplicate records
  • matching references (e.g. resolving URLs to their target identity in the database, and storing the native link)

One of the subjects I’d like to discuss in New Orleans next month is to gather the various disparate strands of work in the community around a ‘storage paradigm’ into a single coherent whole – if that’s possible. It’s something that we’ve been slow to take up, mainly because HL7 classically agrees to focus on the ‘interface’ and keep away from vendor design. But that’s happening in the community now has moved past this.

In particular, there’s really interesting and energetic work using new databases (or new features of old databases) to store FHIR resources directly in the database, and performing the analysis directly on the resources. Google presented some really interesting work around this at DevDays in Amsterdam a couple of weeks ago, and we’re working towards hosting a publicly usable example of this.

Clearly, we’ll need a new diagram to keep up with all these changes

Question: LOINC code for smoking start date

Question:

My team is currently working with FHIR DSTU2, and part of the project that we are working on requires  SMOKING information, particularly the date the patient started smoking.  Part of this work is also mapping this particular information to LOINC, and basically our issue is that we are unable to find anything that refers to a patient’s smoking start date in LOINC.  What would be your suggested work around for the above?

We did find quit date, which good – just not start date.

Answer:

Well, there’s no LOINC code to match 74010-0 (Date quit tobacco smoking). So the best option is to make up your own code, and propose that LOINC add a matching code, then change to use that once that’s done.

You can propose new LOINC codes here: https://loinc.org/submissions/

Sharing Information with a Patient Case Manager

Sharing Information with a Patient Case Manager

This post (which is co-authored with Josh Mandel, thanks) describes a general pattern for a clinician to initiate sharing of a clinical record between an EHR (or more generally, a clinical records system – can be more than just an EHR) and some other clinical information service. These might be one the following:

  • Patient assistance organizations like Medic Alert
  • Patient networks such as ‘PatientsLikeMe
  • Voluntary/professional Clinical case registries (e.g. Vermont Oxford network)
  • Social support services
  • Government and Private Preventative/Management Programs(?)

During the clinical workflow, the clinician with consent from the patient, agrees to ‘refer’ the patient’s case to some kind of case manager, and continue to share information about the patient with the case manager. At some stage, either the clinician or the patient may wish to stop further sharing.

Notes:

  • This is not the same as a formal clinical referral, though there’s some similarities – that’ll be a separate post.
  • There’s a spread of balance between clinical and patient interest here – some of them are ‘what the clinician wants, with consent of the patient’ while others are ‘helpful suggestions from the clinician that the patient might want to run with’. The balance of these may influence which parts of the interaction pattern are more applicable
  • There’s other kinds of case manager registries where the patient doesn’t get consulted. Typically, this is for mandatory public health reporting; this is a different problem for which this particular pattern is not applicable, though parts of it would no doubt be useful

Interaction pattern

Up till now, this kind of sharing has been very difficult to organize in practice, because it has needed vendor support one way or another, and vendors just don’t have time for the never-ending stream of requests for this. That translates into the fact that each individual project cannot afford the development. But FHIR, SMART on FHIR, and CDS Hooks change that.

This blog describes a general pattern for using the Argonaut profile and current EHR development to organize this sharing without needing any special arrangements. I’m publishing this because the overall pattern isn’t evident to many participants.

This pattern describes:

  1. How the case manager service can suggest to the clinician that they should initiate the referral
  2. How the case manager service can provide an application that initiates the sharing
  3. How the sharing can be maintained in an ongoing fashion

Pre-requisites

In order to support this pattern, the clinician must be using an EHR that supports the following:

  • Required: Registering and Running SMART on FHIR applications
  • Recommended: An internet facing provider portal (preferred) or patient portal
  • Optional: Registering and using CDS Hooks service for patient-view hooks

Setting up the pattern includes registering the case manager service with the EHR, and vice versa, and probably exchanging public keys. This step is not standardized by the FHIR/SMART on FHIR/CDS Hooks specifications, but it needs to be done.

Interaction

#1 Prompting the clinician to register the patient

The EHR notifies the case manager service that a patient is being viewed. The case manager service uses the local patient id, and patient information – if provided – to determine whether the patient is already registered, or could or should be registered, and, if it wants, can prompt the user to run the registration app.

This part of the pattern is optional: the clinician can always choose to run the registration app (step #2) without being prompted – this just makes the process easier.

Details:

  • EHR calls CDS Hooks Service. Information provided includes something like:
    • hook :  “patient-view”
    • hookInstance : random UUID,
    • patient: {local patient id}
    • context: none
    • prefetch: patient resource, list of patient’s medications, allergies etc (all optional, and case manager service specific)
  • CDS Hooks Service returns a card that says
    •  patient is or is not (or might be) registered with case manager service (based on recognising local id, or matching patient details (if provided)
    •  patient is not registered with case manager service
    •  if prefetch was passed, and patient is not registered with case manager service, and patient meets criteria, a link to a SMART App to register the patient with the case manager service
    • card includes a link the case manager smart app (see #2)

#2 Registering a patient with the case manager service

The user runs the SMART on FHIR application for the case manager, which gathers information from the EHR (as authorized by the user/institution) and then prompts the user for any additional information needed by the case manager service, and then submits all the information to the case manager service.

Note that each case manager service provides their own application that does what they want, though there is likely to be a (or several) general open source frameworks that do most of what is entailed here.

Details:

  1. User runs the registration app. Either as prompted by CDS Hooks Service above, or by a manual app launch
  2. SMART app loads patient details
  3. SMART app loads medications, problems, allergies, subset of lab results as appropriate for case service
  4. SMART app connects to case manager service, and prompt user for additional information as required (typically, this would include patient consent information and reason for referral at least)
  5. user fills out additional information and submits  (As an optional best practice, the information can be submitted as is submitted to register as a FHIR Bundle, including ServiceRequest, practitioner resource, provenance resource, and gathered data, as appropriate)
  6. Case Management Service stores all required information within its own database.

Note that FHIR provides the Questionnaire/QuestionnaireResponse resources. In this case, the app would retrieve a blank Questionnaire from the case manager service, prompt the user to fill out any information that cannot be automatically determined, and then save a QuestionnaireResponse as part of its registration Bundle (see the SDC implementation guide for details on this)

#3 Ongoing sharing of the clinical record

This part of the pattern is optional – there might not be any utility in ongoing sharing, or it might not be appropriate to ask (either clinician or patient), or it might not be consented to. Note that there’s a marked difference between consenting to share ‘this set of information’ and ‘what ever arises in the future’.

How ongoing sharing works depends on whether the provider API end-point (used by the application in #2) is publicly available or not, and whether the ongoing sharing should be patient or provider managed. If it’s not public, the patient API end-point can be used. If the sharing should be managed by the patient, the patient API should be used. If there’s no patient or provider API publicly available, then there’s no way to orchestrate on-going sharing; records can only be shared as a one-time process in step #2 when the clinician chooses to (usually during a referral). (note: whether the provider portal is publicly accessible, or the URL of the patient portal need to be shared with the application at configuration time).

Ongoing sharing uses the SMART on FHIR protocol as profiled in Sync for Science (S4S) until access is revoked. Access to the S4S interface requires a bearer token  – this pattern relates to acquiring the token.

Provider Portal:

If the provider portal is publicly available, then the application (during step #2) shares its bearer token with the case manager service. How this works:

  • The application asks for an access token with offline scope
  • It shares the token with the case manager service
  • The case manager service uses the token to update the patient’s record periodically

Note that it might be useful for the case manager service to have a different token from the case manager application that runs locally and interactively. The application could use the draft IETF token exchange spec for that, though this is not part of the eco-system now.

Patient Portal:

If there is no provider portal, or if ongoing sharing should be managed by the patient, the patient portal can be used instead. The way this works generally is:

  • The case manager service emails the patient a link (email gathered during registration)
  • patient follows the link and logs in or registers etc
  • patient gets redirected to OAuth login on patient’s portal
  • Patient chooses to authorise the case manager service to access patient data. Scopes could include a broad permission like “patient/*.read”, or granular permissions like “patient/AllergyIntolerance.read”, “patient/MedicationStatement.read”, “patient/MedicationOrder.read”, “patient/Medication.read”, “patient/Condition.read”, “patient/Observation.read”, etc.
  • Case manager service uses the bearer token as described above

If there is no Internet-accessible FHIR API endpoint for the EHR’s data, then there’s another solution: to run a service within the hospital’s internal network that hosts SMART on FHIR apps that can have access to the provider portal. That’s, well, possible, but there’s a series of challenges around administration.

Note:

This pattern is for managing this task using the FHIR/SMART on FHIR/CDS Hooks framework alone. There are other patterns – using the Consent resource – that come into play if the EHRs implement a patient managed consent framework (directly or using UMA), or if the EHR vendor is able/willing to do integration work.

#FHIR and R (Stats / graphing language)

I’ve spent the last 2 days at the 2017 Australian R Unconference working on an R client for FHIR.

For my FHIR readers, R is a language and environment for statistical computing and graphics. (Having spent the last couple of days explaining what FHIR is to R people).  My goal for the 2 days was to implement a FHIR client in R so that anyone wishing to perform statistical analysis of information available in R could quickly and easily do so. I was invited to the R Unconference by Prof Rob Hyndman (a family friend) as it would be the best environment to work on that.

My work was a made a lot easier when Sander Laverman from Furore released an R package to do just what I intended to do earlier this week. We started by learning the package, and testing it. Here’s a graph generated by R using data from test.fhir.org:

Once we had the R Package (and the server) all working, I added a few additional methods to it (the other read methods). For sample code and additional graphs, see my rOpenSci write up.

I think it’s important to make the FHIR data easily available to R because it opens up a connection between two different communities – that’s good for both. Many of the participants are the Unconference were involved in health, and aware of how hard it is to make data available for analysis

Restructuring the data

FHIR data is nested, heirarchical, and focused on operational use. I’ve written about the difference between operational and analytical use before. Once we had the data being imported from a FHIR server into a set of R data frames, Rob and I looked at the data and agreed that that most important area to focus on was tools to help reshape the data down to a usable form. The thing about this is that it’s not a single problem – the ‘usable form‘ will depend entirely on what the question that is being asked of the data is.

So I spent most of the time at the Unconference extending my graphQL implementation to allow reshaping of the data (in addition to it’s existing function in assembling and filtering the data). I defined 4 new directives:

I’ve documented the details of this over on the rOpenSci write up, along with examples of how they work. They don’t solve all data restructuring problems by a very long shot, but they do represent a very efficient and reusable way to shift the restructuring work to the server.

There was some interest at the unconference in taking my graphQL code and building it into an R package to allow graphQL query of graphs of data frames in R, to assemble, filter, and restructure them – it’s an idea that’s useful anytime you want to do analysis of a graph of data. But we were all too busy for that – perhaps another time.

Where to now?

I think we should add R support to the AMIA FHIR datathon series, and maybe it’s time to encourage the research track at the main FHIR connectathons to try using R – I think it’s a very powerful tool to add to our FHIR toolkits.

Thanks to Adam Gruer from Melbourne’s Royal Children’s Hospital for helping – those graphs are his. Thanks also the organisers – particularly Nick Tierney (gitmeister estraordinaire). I picked up some ideas from the Unconference that will improve the FHIR connectathons.

Question: HL7 v2 referrals in Australia

Question:

It seems there are lots of different ways to format a letter type message in Australian Health IT

  1. Pretend its a path report and use ORU with the appropriate LOINC code. This seems the most common
  2. Do it “properly”: use REF
  3. Use PIT, still around I understand
  4. MyEHR CDA type

And within that

  1. 1/ use the FT plain-text format
  2. 2/ embed as an RTF document
  3. 3/ embed as PDF

So that’s 12 permutations at least and I’m sure I’m missing some. Which options have the best chance of getting parsed/rendered correctly by the current crop of GP software (MDW, Best Practice, Zedmed, etc)

Answer:

Well, I think that right now there is no great answer to this question. I consulted Peter Young from Telstra Health, who is leading a vendor consortium that is working with Australian Digital Health Agency (ADHA) on this particular issue. Peter says:

There is work underway in collaboration between HL7 Australia, ADHA and a number of industry players to create a standard mechanism of sharing messages between clinical applications and capable of being transmitted via SMD based on an HL7 Ref I12. It leverages the recently published pathology messaging profile and is part of a broader program led by ADHA  to improve interoperability between applications. Initially there is a baseline specification that provides essential structured data with a clinical document that can be in  either of RTF, pdf, html or text. The idea is that receiving applications will support any document format; if not natively, at least use a viewer. The work plan also includes extensions to add more structured data.  Most of the major clinical and messaging vendors are involved in the work program.

The link to the simplified profile is https://confluence.hl7australia.com/display/OO/Appendix+8+Simplified+REF+profile

I think that the best bet right now is the REF I12 message, with PDF for the letter. But this is an area of active work.

Argonaut in Australia, and the MyHR

Project Argonaut is coming to Australia. That is, at least one major US EHR vendor is planning to make their SMART-on-FHIR EHR extension interface available in Australia during 2018 (discussion about this at Cerner Health Conference where I was last week). HL7 Australia will work with them (and any other vendor) to describe what the Argonaut interface looks like in Australia (short answer: not much different: some different patient extensions, a few terminology changes (not RxNorm), maybe a couple of extensions on prescriptions for Reg24 & CTG). Also, HL7 Australia will be planning to engage with Australian customers of the US EHR vendors to help build a community that can leverage the capabilities of the SMART on FHIR interface.

This is a big deal for Australian EHR vendors that compete with the US vendors – they better start offering the same capabilities based on the same standards, or one of their key market advantages will be consigned to the dust of history. They’ll also find themselves competing with established SMART on FHIR Application vendors too. So I look forward to good engagement with Australian companies as we flesh this out (I know at least one will be deeply involved).

This also offers us an opportunity to consider what to do with the MyHR. The government has spent a great deal of money on this, and results have been disappointing. (Yes, the government publishes regular usage stats which show continuous increase, but these are not the important usage metrics, and they’re not the kind of stats that were hoped for back when we were designing the system). And it’s hardly popular amongst the typical candidate users (see, for example, AMA comments, or for more color, Jeremy Knibb’s comments or even David More’s blog).

But I’m not surprised at this. Back when it was the pcEHR, the intentions were solid, and though the original timeline was impossibly tight, it came together in an amazingly quick time (kudos to the implementers). But as it came together, I knew it was doomed. This is inevitable given it’s architecture:

Salient points about this architecture:

  • The providers push CDA documents to the central document repository
  • Patients can view documents about them
  • Patient’s can write their own documents, but providers won’t see them
  • Patient’s can exert their control only by ‘hiding’ documents – e.g. they can only break the flow of information (reminder, the internet age treats censorship as damage and routes around it)
  • Clinicians can find and read documents
  • Each document is it’s own little snap shot. There’s no continuity between them, no way to reconcile information between them
  • There are no notifications associated with the system

You can’t build any process on that system. You can’t even build any reliable analysis on it (stakeholders worried about the government using it for secondary data analysis shouldn’t, in general, worry about this, it’s too hard to get good data out of most of the CDA documents). These limitations are baked into the design. That’s why I went and developed FHIR – so that when the full reality of the system become evident, we’d have a better option than a document repository.

Well, 10 years later, and we’re still trying to load ever more use into the same broken design, and the government sponsors are still wondering why it’s not ‘working’. (at least we stopped calling it the ‘personally controlled’ EHR, since it’s the government controlled EHR). And as long as it exists and is the focus of all government efforts to make digital health happen, it will continue to hold up innovation in this country – a fact which is terribly evident as I travel and see what’s happening elsewhere.

But it doesn’t have to be like this.

The MyHR is built on a bunch of useful infrastructure. There is good ideas in here, and it can do good things. It’s just that everything is locked up into a single broken solution. But we can break it open, and reuse the infrastructure. And the easiest way I can see to do this is to flip the push over. That is, instead of the source information providers pushing CDA documents to a single repository, we should get them to put up an Argonaut interface that provides a read/write API to the patient’s data. Then, you change the MyHR so that it takes that information and generates CDA documents to go into the MyHR – so no change needed to the core MyHR.

What this does is open up the system to all sorts of innovation, the most important of which is that the patient can authorise their care providers to exchange information directly, and build working clinically functional systems (e.g. GP/local hospital, or coordinated care planning), all without the government bureaucrats having to decide in advance that they can’t be liable for anything like that. That is, an actually personally controlled health record system not a government controlled one. And there’s still a MyHR for all the purposes it does exist for

This alternative looks like this:

The salient features of this architecture:

  • All healthcare providers make healthcare information services available using the common Argonaut based interface (including write services)
  • Patients can control the flow at the source – or authorise flows globally through myGov (needs new work on myGov)
  • Systems can read and write data between them without central control
  • The MyHR can pull data (as authorised) from the sources and populate the MyHR as it does now
  • Vendors and providers can leverage the same infrastructure to provide additional services (notifications, say)

The patient can exert control (either directly at the provider level, or through mygov as an OAuth provider) and control the flow of information at the source – they can opt-in or -out of the myHR as appropriate, but they can also share their information with other providers of healthcare services directly. Say, their phone’s very personal health store. Or research projects (e,g, AllofUs). Or, most importantly and usefully, their actual healthcare providers, who can, as authorised by the patient, set up bi-directional flows of information on top of which they can build better coordinated care processes.

These features lead to some important and different outcomes:

  • Healthcare providers and/or system vendors can innovate to build distributed care models that provide a good balance between risk and reward for different populations (instead of the one-size suits bureaucrats that we have now)
  • Patient’s can control the system by enabling the care flows that they want
  • Clinicians can engage in better care processes and improve their process and outcomes (though the US process shows clearly that things get worse before they get better, and you have to plan for that)

This isn’t a small change – but it’s the smallest change I know of that we can make that preserves the MyHR and associated investment, and gives us a healthcare system that can innovate and build better care models. But I don’t know how we’ll think about getting there, given that we’re still focused on “make everyone use the MyHR”.

Note: Adapted from my presentation yesterday at the HL7 Australia Meeting

 

Cultural Factors affecting Interoperability

One of the under-appreciated factors that affects how successful you’ll be at ‘interoperability’ (for all the various things that it might mean) is your underlying culture of working with other people – your and their underlying expectations about whether and when you’ll compromise with other people in order to pursue a shared goal.

Culture varies from organization to organization, and from person to person. And even more, it varies from country to country. As I work with different countries, it’s clear that in some countries, it’s harder to get people to to sacrifice their short term personal interests for shared long term communal interests. There’s plenty of research about this – mostly phrased in terms of micro-economics. And it very often comes to down trust (or lack thereof). Trust is a critical success factor for success at compromise and collaboration. And it’s pretty widely observed that the level of trust that people have in institutions of various kinds is reducing at the moment (e.g. 1 2 3).

Plenty has been written about subject, and I’m not going to add to it. Instead, I’m going to make a couple of related observations that I think are under-appreciated when it comes to interoperability:

The first is that smaller countries with a bigger dominant country that can easily overpower them next door (my go-to examples: Estonia, Denmark, New Zealand) have populations that are much more motivated to collaborate and compromise with each other than countries that are economically (and/or politically) without peer in their geographic area.

And so you might think that these countries are better at interoperability than others…? well, sort of:

Countries that have a cultural disadvantage with regard to interoperability are the countries that produce the great interoperability technologies and methodologies (they have to!), but countries that have a cultural advantage for interoperability are much better at taking those technologies and methodologies and driving them home so the task is complete.

If my theory is right, then when you look at what countries are doing, you should look for different lessons from them, depending upon their cultural situation with regard to interoperability.

p.s. If my theory is right, one really has to wonder how bad are the cultural headwinds against interoperability here in Australia..

p.p.s. I found very little about this on the web. References in comments would be great.

 

 

Gender Participation in the #FHIR Community

This is post #3 in my series about why to participate in the FHIR standards process.

A few weeks ago, I attended the AIIA awards night at the kind invitation of the eHealth team from CSIRO. One of the speakers was the Victorian Minister for Small Business, the Hon Philip Dalidakis. The presentation was the day after the sad passing away of another Victorian minister, Fiona Richardson, and in her memory, he made an inspired plea for us all to actively consider whether there’s anything that we can or should do to improve the gender imbalance that’s typical in IT.

HL7 – and the FHIR community – does have the gender imbalance that’s characteristic of IT communities – though it’s also a health community, and so the gender divide is not as stark as it is in some communities. But it’s not anywhere close to 50:50, and his words made me wonder whether we/I are in a position to do anything more about that. After the presentation, I spoke to Minister Dalidakis about what levers we might have in an open standards community to encourage more balanced participation – they’re different to those you can/should use in a commercial setting.  He graciously gave me several pieces of advice, and since then I’ve been discussing this with the FHIR team, and particularly with our female leaders in the community.

FHIR and HL7 are great communities to be involved with, and that’s particularly true if you’re a woman – that’s what our female leaders tell me.

They say this is because:

  • We have a strong governance model that is good at managing contention (we have a fair bit of it to manage!)
  • Everyone is treated equally, and mostly treated well (the issues mentioned here are gender neutral)
  • Our discussions are thoughtful and respectful
  • The healthcare vertical is inherently non-confrontational, non-violent

And FHIR is a great place to contribute. Paula Braun says:

Many of the important indicators about our health…e.g., blood pressure, abnormal lab results, etc…are invisible to us. Without access to this data, we and the professionals we entrust to take care of us, are operating in the dark. The older, outdated ways of accessing and exchanging health information have an “I know better than you” feel to them. It was the equivalent of somebody saying, “Hey there girl, don’t worry your pretty little head about how this all works. It’s much too complicated for you.” FHIR is different. FHIR is a community where motivated people self-select to un-break healthcare…at least the IT part of healthcare. I don’t consider myself a “techie” but I choose to participate in the FHIR community because of the possibilities that FHIR enables, the professionalism that is maintained, and, most importantly, because its fun to be part of a movement that is transforming the dominant assumptions and expectations about healthcare

Michelle Miller (who is rightfully one of the Health Data Management’s 2016 Most Powerful Women in Health Care IT) says:

I participate in the FHIR community because:

  • Even with my bright pink “First-Time Attendee” ribbon, I quickly learned that my input was valued.
  • HL7 FHIR has a focus on those who adopt and implement the standard specification, such that implementer involvement and input is very much respected and encouraged.
  • After getting energized by the fantastic collaboration that occurred during the HL7 work group meetings, I started attending weekly work group conference calls to continue the discussion
  • I feel strongly that all changes, big and small, help make the FHIR specification that much better for the next implementer or developer to adopt.  Adoption is what makes a specification a standard because without adoption, we haven’t really achieved interoperability
  • I have been so impressed with the knowledge, collaboration and overall friendliness of the HL7 FHIR community. The discussion is always thoughtful and respectful, such that I have high confidence in FHIR’s ability to maximize interoperability.

In sum, it is energizing for me to collaborate with such knowledgeable experts on a subject (healthcare) that is so meaningful and impactful (bigger than just me, my job, or even my country).  Despite the diversity in our perspectives (country, vendor, government, technical vs clinical etc.), the FHIR community is genuinely interested in reaching the best conclusion because adoption is what makes a specification a standard and achieves interoperability

Michelle has a full write up about her involvement on the Cerner Blog.

So the FHIR community is a great place for women who want to make a difference to contribute. If you’re thinking about it – we’d love to have you involved; please get in contact with me, or one of:

(though there’s many other valued contributers as well).

Still, there’s plenty we can do to improve:

  • One particularly pertinent issue around gender participation is about time requirements. HL7 is both good and bad here – most participation is remote, and really flexible in terms of hours and location – that’s a big deal. But there’s also face to face meetings that require travel – that can be a real problem, and HL7 has struggled to find a practical solution around remote participation (it’s an inherently hard problem).
  • There’s general agreement that we could do a lot better with regard to welcoming, induction, and initial training procedures – these are actually issues for both genders – so that’s something that we’re going to work on
  • We need to communicate better that the FHIR community is not just engineers and hackers (who lean male) – it’s about health, and clinicians and nurses (and business managers) are just as much implementers with valuable contributions to make. Of course, the FHIR community is comprised of both genders across all these roles
  • Good consultative leadership is hard to find, and we need/want more of that
  • We have good leaders – we need to recognize the ones we have.
  • We could keep an eye on statistics around assignment of administrative duties (“housework”) at HL7 – but we don’t

Note that all these are really about maximizing our human capital. So, we have plenty of potential, but we aren’t really capitalizing on it. Increasingly, we are investing in human capital as our community grows, so watch this space.

Btw, this image from the Madrid meeting shows that we can do better on balance (though, in fact, we are on the whole more balanced than this particular photo):

Contributers recognized for contributions way beyond expectations to getting FHIR R3 published – featuring both Melva and Michelle

p.s. A note about the FHIR and HL7 communities: these are tightly related communities with a good % overlap, but they are also different in nature, processes, and composition, so we had to consider them both.