Monthly Archives: September 2017

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.

#FHIR and Bulk Data Access Proposal

ONC have asked the FHIR community to add 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.

The background to this requirement is that while FHIR allows for access to data from multiple patients at a time, the Argonaut implementations are generally constrained to a single patient access, and requires human mediated login on a regular basis. This is mainly because the use case on which the Argonaut community focused was patient portal access. If this work is going to be extended to provide support for API based access to a large number of patients in support of provider based exchange, the following questions (among others) need to be answered:

  • how does a business client (a backend service, not a human) get access to the service? How are authorizations handled?
  • How do the client and server agree about which patients are being accessed, and which data is available?
  • What format is the data made available in?
  • How is the request made on a RESTful API?
  • How would the client and server most efficiently ensure the client gets the data it asks for, without sending all data every time?

The last few questions are important because the data could be pretty large – potentially >100000000 resources, and we’ve been focused on highly granular exchanges so far. Our existing solutions don’t scale well.

In response to some of these problems, the SMART team had drafted an initial strawman proposal, which a group of us (FHIR editors, ONC staff, EHR & other vendors) met to discuss further late one night at the San Diego WGM last week. Discussion was – as expected – vigorous. Between us, we hammered out the following refined proposal:


Summary

This proposal describes a way of granting an application access to data on a set of patients. The application can request a copy of all pertinent (clinical) access to the patients in a single download. Note: We expect that this data will be pretty large.

Authorizing Access

Access to the data is granted by using the SMART backend services spec.

Note: We discussed this at length, but we didn’t see a need for Group/* or Launch/* kind of scopes – System/*.read will do fine. (or User/*.*, for interactive processes, though interactive processes are out of scope for this work). This means that a user cannot restrict Authorization down to just a group, but in this context, users will trust their agents.

Accessing Data

The application can do either of the following queries:

 GET [base]/Patient/$everything?start=[date-time]&_type=[type,type]
 GET [base]/Group/[id]/$everything?start=[date-time]&_type=[type,type]

Notes:

  • The first query returns all data on all patients that the client’s account has access to, since the starting date time provided.
  • The second query provides access to all data on all patients in the nominated group. The point of this is that applications can request data on a subset of all their patients without needing a new access account provisioned (exactly how the Group resource is created/identified/defined/managed is out of scope for now – the question of whether we need to do sort this out has been referred to ONC for consideration).
  • The start date/time means only records since the nominated time. In the absence of the parameter, it means all data ever
  • The _type parameter is used to specify which resource types are part of the focal query – e.g. what kind of resources are returned in the main set. The _type parameter has no impact on which related resources are included) (e.g. practitioner details for clinical resources). In the absence of this parameter, all types are included.
  • The data that is available for return includes at least the CCDS (we referred the question of exactly what the data should cover back to the ONC)
  • The FHIR specification will be modified to allow Patient/$everything to cross patients, and to add $everything to Group
  • Group will be added as a compartment type in the base Specification

Asynchronous Query

Generally, this is expected to result in quite a lot of data. The client is expected to request this asynchronously, per rfc 7240. To do this, the client uses the Prefer header:

Prefer: respond-async

When the server sees this return header, instead of generating the response, and then returning it, the server returns a 202 Accepted header, and a Content-Location at which the client can use to access the response.

The client then queries this content location using GET content-location (no prefixing). The response can be one of 3 outcomes:

  • a 202 Accepted that indicates that processing is still happening. This may have an “X-Progress header” that provides some indication of progress to the user (displayed as is to the user – no format restrictions but should be <100 characters in length). The client repeats this request periodically until it gets either a 200 or a 5xx
  • a 5xx Error that indicates that preparing the response has failed. The body is an OperationOutcome describing the error
  • a 200 OK with the response for the original request. This response has one or more Link: headers (see rfc 5988) that list the files that are available for download as a result of servicing the request. The response can also carry a X-Available-Until header to indicate when the response will no longer be available

Notes:

  • This asynchronous protocol will be added as a general feature to the FHIR spec for all calls. it will be up to server discretion when to support it.
  • The client can cancel a task or advise the server it’s ok to delete the outcome using DELETE [content-location]
  • Other than the 5xx response, these responses have no body, except when the accept content type is ‘text/html’, in which case the responses should have an HTML representation of the content in the header (e.g. a redirect, an error, or a list of files to download) (it’s up to server discretion to decide whether to support text/html – typically, the reference/test servers do, and the production servers don’t)
  • Link Headers can have one or more links in them, per rfc 5988
  • Todo: decide whether to add ‘supports asynchronous’ flag to the CapabilityStatement resource

Format of returned data

If the client uses the Accept type if application/fhir+json or application/fhir+xml, the response will be a bundle in the specified format. Alternatively, the client can use the type application/fhir+ndjson. In this case:

  • The response is a set of files in ndjson format (see http://ndjson.org/).
  • Each file contains only resources of a single type.
  • There can be more than one file for each resource type.
  • Bundles are broken up at Bundle.entry.resource – e.g. a bundle is split on Entries so the the bundle json file will contain the bundle without the entry resource, and the resources are found (by id) in the type specific resource files (todo: how does that work for history?)

The nd-json files are split up by resource type to facilitate processing by generic software that reads nd-json into storage services such as Hadoop.

Notes:

  • the content type application/fhir+ndjson will be documented in the base spec
  • We may need to do some registration work to make +ndjson legal
  • We spent some time discussing formats such as Apache Avro and Parquet – these have considerable performance benefits over nd-json but are much harder to produce and consume. Clients and servers are welcome to do content type negotiation to support Parquet/ORC/etc, but for now, only nd-json is required. We’ll monitor implementation experience to see how it goes

Follow up Requests

Having made the initial request, applications should store and retain the data, and then only retrieve subsequent changes. this is done by providing a _start time on the request.

Notes:

  • Todo: Is _start the right parameter (probably need _lastUpdated, or a new one)?
  • Todo: where does the marker time (to go into the start/date of the next follow up request) go?
  • clients should be prepared to receive resources that change on the boundary more than once (still todo)

Subscriptions

The ONC request included “push of data”. It became clear, when discussing this, that server side push is hard for servers. Given that this applications can perform these queries regularly/as needed, we didn’t believe that push (e.g. based on subscriptions) was needed, and we have not described how to orchestrate a push based on these semantics at this time


Prototyping

It’s time to test out this proposal and see how it actually works. With that in mind, we’ll work to prototype this API on the reference servers, and then we’ll hold a connectathon on this API at the New Orleans HL7 meeting in January. Given this is an ONC request, we’ll be working with ONC to find participants in the connectathon, but we’ll be asking the Argonaut vendors to have a prototype available for this connectathon.

Also, I’ll be creating FHIR change proposals for community review for all the changes anticipated in this write up. I guess we’ll also be talking about an updated Argonaut implementation guide at some stage.

 

Question: #FHIR Documents and Composition

Question

What is the relationship between FHIR Documents and  composition resources? Meaning, what is the best way to capture/store in FHIR, documents that are not necessarily related to clinical info (file, images, file reference links to external content systems etc)

If I have several documents that need to be associated to a patient and organizations and was looking for your thoughts on best practices you have seen

Answer

Documents like this – files, images, reference links to content systems – these are best handled using DocumentReference.  Composition is used for documents that have tightly controlled content. a mix of narrative and data.

Question: Extending systems to deal with non-#FHIR type content

Question

What has your experience been with developers, developing on a FHIR model that requires FHIR resources — but also has a need for non-standard FHIR data (something like supply chain data or Blockchain external hashed data). Is the recommendation to shoe horn this into extensions  or have data models that live side-by-side with FHIR?

Answer

There’s no single answer to this question, because it depends on the other kind of data. Generally, there’s 3 approaches I’ve seen:

  1. Use extensions in existing resources (particularly Basic). This approach is only good while the extensions are pretty narrow and limited, and closely related to the existing FHIR functionality
  2. Use some other content model, and figure out how the functionality links. This approach is good where there is another content model. For example, in my server, I use SCIM for managing the user accounts. I use the SCIM content to link a user account to a FHIR resource like “Patient” so that I know which patient the user represents (if any) and I refer to the SCIM user identity in AuditEvent resources (as a URL)
  3. Make up your own content but follow the FHIR patterns – effectively, custom FHIR resources. Use extensions to reference them. This approach is good where you have quite a bit of content/functionality, but there’s no external standard to follow

Which is best depends on what you’re doing.

A note about the custom resources idea: this is legal – you can do whatever you want with the names the FHIR doesn’t define. e.g. [base]/User. And if you choose to put something there, that happens to look a bit like a FHIR resource.. that’s still whatever you want. But things like ‘can I describe it from the CapabilityStatement’ and ‘can I search into the space’ are not technically legal, and there’s always a risk that HL7 will use the name in the next version of FHIR, making your solution locked in to being non-conformant. We’ve investigated making some policy around these questions to make custom resources manageable, but we’ve never managed to get the energy to push agreements over the line.

The Vendor Engagement Matrix

This is post 2 in my series on why to participate in the standards process: a reason why Vendors should engage with standards

Professional Societies

One strong feature of the healthcare eco-system is professional societies. Everywhere you look, there’s another one. See here, and here, and on wikipedia. Or for Australia, here. (And none of the ones I’m involved with – HISA, ACHI, AACB – are even listed). For professionals in healthcare, the reasons to be involved in these are obvious (see, e.g. “Top 10 reasons“). In fact, in most places I’ve worked – whether clinical labs, research labs, government agencies, or vendors, membership of and engagement with professional societies is expected (or even required) if you have a leadership role.

And most employers enthusiastically support their employee’s involvement and leadership in professional societies (witness the employer affiliations for board members of ACHI, AIIA, AMIA). It’s obvious why employees participate in professional societies, but why do employers support this, even to their apparent cost (funding time, travel, sharing implicit IP, etc)? For example:

Some employers claim that there is no time for such efforts, or that it could prove too expensive. Many worry that all they would be doing is enhancing employees’ skills for a future employer. They ask themselves what would happen if they encourage professional development and some of their employees leave.

Those are all valid concerns. But:

A better question would be to ask what would happen if they ignore professional development and their employees stay

I’m quoting from the Society for Human Resource management there. Do read the whole thing. I’m just cherry picking a choice quote:

One critical reason given for seeking employment elsewhere was that although the employees valued mentoring, training and coaching very highly, their employers were falling far below expectations in those areas.

Finally, I’ll note that it’s when an organization must trust the choices that it’s employees make on their behalf that professional societies are most compelling – in fact, that’s when they become necessary: employees are inspired and pressured to apply professional excellence in ways that an employer cannot easily reproduce. And that’s why they’re a big deal in healthcare (and IT).

Most vendors I know encourage their staff – and particularly their leaders – to be involved in professional societies. It’s a tangible demonstration of their commitment to excellence. And the vendors that don’t encourage their staff to get involved?… they’re signalling to the market where they sit on professional engagement: it doesn’t matter. And, more importantly, they’re signalling to their staff about that as well, and I’ve seen that companies that don’t do this suffer from a steady erosion in their culture.

Choosing a Vendor

When it comes to choose your enterprise information system (EIS) providers, the quality and culture of the EIS vendor really matters. It all comes down to what you are buying. If you’re buying a widget, where the delivery of quality goods is feasible to measure, and the goods are a commodity, then it makes absolute sense to choose the lowest price you can get in the market. But once you start buying things where the quality is not easily measured, or you have a high transaction cost to change supplier, you have to think differently about your choice. And EIS’s really are the epitomy of these problems (e.g. changing EIS frequently costs more than the cost of the system, and the vendor pretty much does nothing but make decisions on your behalf, ones you can’t really review).

Because of this, thoroughly understanding the culture of the vendor of the EIS – who you are effectively marrying for the duration that you’ll depend on them to assist you manage your organization – is critical. As technical lead at Kestral, I always believed that our potential customers, when choosing a vendor, focused their scoring too highly on the current features of the widget they were buying (the EIS), and not on the relationship they were entering into – because the system they were buying was not static, and a key feature of their future success was how well their EIS vendor could support them to grow their business by delivering on their future interoperability requirements. (And, if I’m not mistaken, lack of delivery on interoperability features a little in the news at the moment….)

But the problem is, how do you choose a vendor that consistently delivers based on a culture of professional excellence? well, one way is to count what % of the vendors key employees have leadership roles in professional societies. And asking the vendor to report that should be a standard feature of all EIS RFPs, and it should be scored enough to weight it against the long list of feature the EIS is being scored on.

But, you say… that’s easy for a vendor – it’s not really very costly in the overall picture to support an employee’s involvement in a professional society, and there’s no need for that to make a meaningful difference to their culture. And that’s actually partly right. Which is why the real question is not about the professional societies of their employers, but the vendor’s membership of professional societies for the vendor itself. That’s where the rubber really hits the road.

And professional societies for healthcare EIS systems are standards organizations (or their derivative, informal open source collaborations).

Involvement in Standards Organization

This means that a vendors involvement in standards is a key indicator of it’s aspiration to enduring professional competence. And it’s deep involvement over time that matters, along with consistent delivery of the standards being worked on. It’s not a magic bullet, but it’s tangible evidence that the vendor has a deep commitment to it’s own professional standards to deliver a quality product in regards to more than just the feature list that appear on sales materials.

And this is something that institutions should ask about in their RFPs: what tangible evidence can you as a vendor show that you have an organizational commitment to quality? Now obviously there’s more answers to this than just involvement in the standards process, but involvement in the standards organization not only is one good and measurable marker, it’s a particularly relevant marker given an organizations inevitable future dependency on the vendor to deal with ongoing interoperability requirements.

All this suggests that we could define a Standards Engagement Matrix which can be used to score how involved a vendor is in the standards process. It might look something like this:

SDO Membership Gold Membership Organization leaders Technical Leaders Contributions Delivery
One row for each relevant SDO 5 points for being a paid member 20 points for paying high level fees 3 points for each board member, or chair of an organizational committee 4 points for each technical committee chair

5 points for each editor of standard

5 points for major contributions of tools, drafted documents.

10 points for donating patents to the SDO

10 points for each standard implemented during the trial phase in the last 4 years

3 points for proving conformance to the standard by a recognized testing authority in the last 4 years

Then divide the point totals to the log of the company revenue, and you have a the “Standards Engagement Matrix score”

I need to be clear here: this is just a straw man to make people think about how you would score something like this. I’m sure it needs more adjustment around vendor size/income. And you’d absolutely need some kind of adaptive score for the meaningfulness of the SDO itself. And note, of course, that as vendors grow, their organization and business interests broaden, and different parts of the organization could behave differently, so again, there’s no magic bullet here.

But if we had a working consensus on something like this, then providers buying a healthcare EIS could ask, as part of their RFP, ‘what’s your standards engagement matrix score?’, and know that the score is a very good indication of their organizational commitment to excellence. Which is actually more relevant than even vendor financial viability to the long term happiness of the purchaser, in my opinion.

 

p.s. The exact same logic applies to whether providers and institutions are willing to share patient data – it’s a key indicator to their own staff of their commitment to professional excellence, not just short term profit-making. And we should be educating patients about that.

Why participate in the #FHIR Community? (Individuals & Standards)

This blog is the first of series I’m going to run in the lead up to the HL7 San Diego meeting looking at the question of why to participate in the FHIR community. For this first blog, I’m going to look at the question of why to get involved in standards at all at the individual level. (subsequent entries in the series: The vendor engagement matrix, Gender Balance and Participation, …)

A couple of days ago, I was speaking to a well-known high-profile member of the Australian Health Informatics Community – someone who’s given considerable time to the development of the profession, both academically, and to the community. I asked him why he wasn’t involved in standards development. “Not standards!”, he said, with a definite frown.

Indeed, why be involved in standard development?

In some ways, it’s easier to say why it’s better not to be involved: standards work is slow, and involves arcane and myopic focus on small details in the presence of considerable contention about what should be done. Often must deal with toxic people in difficult circumstances – it’s kind of baked into the process. And progress is slow – actually, it’s often opaque whether you’re making any progress at all. What success you do have is often not appreciated outside the standards community (not appreciated, that is, by the people with money who fund your participation one way or another).

But…

There’s an old saying that anything worth doing is costly… and I think that applies to standards. While the work can indeed be arcane and myopic at times, of all the ways to impact the community, standards development is one of the ways that offers the most leverage. Standards can alter behavior, create entirely new arrangements, and transform industries. In the case of health, good protocols for data exchange – and the data standards that underlie them – can make a substantial difference to health outcomes.

I’d love to have more patient/consumer representatives involved in HL7 (though there’s many other venues where you can contribute to data and protocol standards). But when I talk to potential candidates, most can’t imagine being involved in something with such a long term outlook, where you have to do so much work before you get any outcomes… but that’s how you get really deep and meaningful outcomes. I think that’s sad.

So if you’re interested in contributing to the community, in advocating for change in healthcare: think about playing the long game, the one with the big payoffs, and contribute through the development of standards.