Category Archives: Standards

The 3 Legs of the Health Informatics Standards Process

Lately, I’ve been describing the standards process that we’re engaged in – making a difference to people’s health through defining healthcare IT standards – as a process that has 3 legs. Kind of like this:

Finding out whether you’re really friends

Well, not really. It’s actually 3 legs of a journey. The 3 legs are:

  1. Developing the base standards
  2. Profiling the standard for particular communities 
  3. Driving Solutions into production in the market

#1 Developing the Base Standards

The first leg is developing the base standards the define the capabilities for describing and exchanging healthcare. These base standards enable all sorts of communities to form around exchanging healthcare data. 

But given the breadth of healthcare, and the variety of processes, jurisdictions and business rules – along with the fact that there’s no single authority of these things (in as much as there’s any authority at all), these are platform standards: they create platforms that are used in all sorts of different ways. They define how things can work.

Example Standards:

They’re also limited in that they can only make hard rules that everyone in the world agrees to – which is a lot less than an particular set of rules that a single solution needs. So they don’t define particular solutions, except in the rare case that everyone in the world agrees to the solution (we actually might have a couple of those things: consumer healthcare repository, and terminology service).

#2 Profiling the Standard for Particular Communities 

Once the international platform specification(s) exist, particular communities find common use cases for which they need to determine and record their business rules, and converge on a common approach for using the platform standards. These are called various things – profiles, templates, value sets, reference sets, implementation guides. But in all cases the basic steps are the same:

  • identify the need for a particular solution
  • form a smaller community around it 
  • support the community to converge and agree on a particular approach 
  • publish the approach and help the community test it’s validity 
  • iterate the process

The principle is simple: a smaller communities can get more agreement amongst themselves because they have more in common (and are sometimes empowered by hard rules/regulations/laws – when they are useful)

There’s lots of organizations working in this space. Some relevant in the FHIR eco-system:

Aside: Platform vs Usage

Note that the demarcation line between leg #1 (platform) and leg #2 (usage) is grey. I think of XDS as a platform standard, even though it’s technically profiling other standards. Thing is, that’s what FHIR does too, and it’s very definitely a platform standard. The question is far more about community and process than technology, and XDS has played out more like a platform standard (though it’s not that important which it is)

At first encounter with the standards process, many people challenge the value of the platform/usage split – why not just get it right in the first place? We’d love to – but the trade-off between community size and level of agreement is a hard external fact we can’t wish away. Given that, if you don’t create the platform/application split, the result will be a shattered standards system with myriads of incompatible standards, one for each variation of the use case and all incompatible. Which is (unfortunately) too much like what we have now. 😒 It’s really nice the first time you solve a problem, but the next time you solve a related problem…. then you start to feel the pain. After the Nth time… you really want a platform standard.

#3 Driving Solutions into production in the market

Once you’ve formed a community, got your agreements, published them, and tested that it’s possible… you’re still not done. You created capability, and expectation. But at that point, nothing is actually working (except for limited demonstrations at hotels and exhibitions, typically). 

Driving the solutions home – the last leg of the journey – that’s actually the hardest part of the journey. IT solution providers (vendors, usually though not exclusively) are often happy to collaborate in a community process, and demonstrate cool stuff to sell, but bringing stuff to market involves messy processes like certification, sales, deployment, contracts, and many people have to sign off on the process and someone has to fund the deployment/testing/maintenance. 

This is the primary source of the Gartner Trough of Despair, and we’re certainly hearing that this the case with FHIR:

  • The platform standard is doing well – 4th release, normative, lots of energy and adoption spreading like wild fire (sorry)
  • There’s plenty of projects around profiling / usage agreements from IHE and others. In particular, the Argonaut project has created a huge potential in USA with access to EHR data
  • But – case in point – actual argonaut end-points are not widely available, and getting access to them, even when in production, can be very difficult

HL7 has pretty much no leverage over the 3rd leg of the process. IHE has more, but not as much as everyone would like. Argonaut, in their smaller community, has more again – but still not enough. Classically, the agents that have influence/leverage over the 3rd leg are the regulators (hello CMSONC and the NPRM), but professional societies such as HIMSS and HISA also have influence, since their membership is much more provider based.

HL7 and the FHIR community are starting to pay much more attention to the whole 3 legs, and looking to work much more pro-actively with critical partners like IHE, HIMSS etc to see what we can do to make as much as possible real.

MyHR: CDA or PDF?

Quoting from the story Sue Dunlevy wrote about John Halamka after his visit to Australia for Wild Health this week (paywalled):

The My Health record is a noble idea but the standard they chose is from 1995, it uses PDFs, it’s not computable, it is just digitised paper,” he told News Corp Australia

Technically, the MyHR is a document repository where the repository uses a modified variant of XDS (for the ‘personally controlled’ bit) and the documents are all CDA documents. A small number of the CDA documents are simply wrappers around PDF documents (<5%) but the rest are full CDA documents with variable amounts of coded data embedded in them (some quite comprehensive indeed).

In spite of the fact that it’s a repository of CDA documents, most of the commentary in the media describes them as PDF documents, and John’s comments reflect that – based on what people told him while he was here. 

So if the repository is full of CDA documents, why all the commentary about PDF? Actually, the answer is pretty simple: 

  • Consumers (patients) cannot get the CDA documents; all they can get is a print out of the presented part of the CDA document – that is, in effect, PDF (and probably is literally PDF, if they print to PDF)

    Aside: I’m not sure why it would be such a problem for consumers to get their own data, but this is a long standing prohibition 

  • Clinicians can download the CDA documents directly to their systems, and the systems are able to extract the data from the CDA documents. But mostly, this doesn’t happen (for a variety of reasons), and all the clinician gets is a presented view of the CDA document, just like if it was PDF

  • The purpose of the system was to collate data, but the lack of solid data and clinical agreements have made that very hard to do, and the collation views that are offered are less useful than first intended – so they’re not very high profile. More generally, the system doesn’t support integrated data based work flows – it mostly behaves like a repository of PDF documents

  • Finally, the public (and journalists, and politicians) have an inherent understanding of PDF (all of us read them, and many of us produce them), and use imprecise language with regard to standards . “PDF-like” quickly transits to just simply “PDF”. This even happens in the general healthcare IT community

I’ve given up trying to dispute the language – programmers and analysts working directly with the system know better, but since the system mostly functions like a repository of PDF documents, I think there’s bigger things to focus on. 

But if you like precision in your language… the MyHR is a CDA based system, not a PDF based system.

Follow up to Senate Submission + Future Health Index

My last blog entry published my senate submission (which is formally found here) and testimony about the Australian My Health Record.

I’ve had a lot of feedback about my submission from across the healthcare eco-system. Almost all of the feedback has been positive – endorsing my basic argument, and expressing the hope that the senate and/or the department take note of my submission and broaden the scope of the My Health Record to allow for a federated architecture.

Not every one agrees, but no one has said so publicly or privately: the My Health Record remains divisive and political. We just aren’t having good quality discussions about how it should work in public. If the Senate inquiry has demonstrated anything to me, that’s the lesson: we aren’t having the right public discussion about what we have and what we should have.

On the subject of the Senate, many people thought that I was wasting my time here – the senators would not understand what I was talking about. But I thought the sharp and insightful questions from Senators Siewart, Keneally, Di Natale and Gichuhi indicated that they understood my point quite well (even if I didn’t always understand the questions correctly until too late). However given the variation in the testimony, and the wider political context… I have no idea what the inquiry report will contain.

Of course, the agency and the department may choose to proiritise a federated architecture as part of the re-platforming anyway, irrespective of the Senate report; that’s possible but it will take some time before any decision might be made. So we’ll have to wait and see.

This week, the 2018 Future Health Index was published. This has some relevance to the My Health Record. Consider this, from the press release:

Our Future Health Index research shows that ‘universal’ electronic health records (EHRs) and AI will play an important role in advancing integration and promoting more effective use of data. These technologies are investigated in detail in the report, with five key learnings emerging that provide guidance on the steps to drive integrated care:
1. Get regulation right. Clearly defined polices and robust data privacy and security standards at the national level build confidence in all parts of the healthcare continuum and help healthcare institutions develop their own data codes of practice, as well as encouraging healthcare professionals and the general population to collect, share and analyze data with greater confidence.
2. Modernize education. Healthcare professionals won’t demand EHRs and AI tools at work if they don’t learn to rely on them during medical training. Increasing healthcare professionals’ adoption of these tools must start with their integration into medical school curriculums.
3. End top-down implementation. Healthcare professionals are unlikely to adopt new tools when they’re presented as a ‘fait accompli’ by technologists. Creating EHRs and AI solutions in collaboration with both healthcare professionals and the general population will have a significant impact on successful integration.
4. Prove and explain value. Both healthcare professionals and patients need to be able to easily understand how data collection and analytics tools make a difference. Constantly measuring and communicating outcomes will create a body of evidence that will help bridge the understanding gap.
5. Harmonize data standards. Companies, healthcare professionals and governments in each market must work together to reach a greater degree of consensus on data formats and protocols.

The bolding is mine – I’ve highlighted the points in the summary that pertain to testimony about the MyHR to the Senate – for example, we cannot at this time say that we have “robust privacy and security standards that build confidence” nor can we say that “health care professionals and patients easily understand how the MyHR will make a difference”.  And of course, “Companies, healthcare professionals and governments should work together on data formats and protocols” – we have an international process for that, but right now, nothing in Australia, to my despair. 

On the other hand: “End top-down implementation” is very easy to say, but really hard to actually do. Much of what we have in the MyHR was an outcome of clinician led design, or at least the intent to have that. As is every other EHR type software product I’ve worked on. But reality is way messier than any design process can deal with, and national health records must be some of the messiest products ever. Armchair critics and bloggers should keep that in mind…. as well as anyone who works on any federated architecture for a possible phase 2 of the MyHR (might be me)

p.s. I was interviewed for the Future Health Index report.

Submission to the Senate inquiry on My Health Record

This is the submission I made to the Australian Senate with regard to it’s inquiry into the My Health Record. 

Executive Summary
My remarks relate to the following parts of the terms of reference:
  a. the expected benefits of the My Health Record system;
  f. how My Health Record compares to alternative systems of digitising health records internationally;
Recommendation:
The Department of Health (DOH) and the Australian Digital Health Agency (ADHA) work with the community to define an alternative architecture for a federated system for healthcare data exchange. This would allow for the implementation of the National Digital Health Strategy, and stimulate innovation to improve health, and leverage international standards and programs.

Introduction

I am the Product Director and Community Lead for the FHIR standard , which is published through HL7, the leading international healthcare standards provider.
The FHIR standard is an open, freely available standard that is recognized as a key innovation in healthcare , and is increasingly considered the main future standard in the healthcare community. It is being adopted across the world by countries including Australia, UK, EU countries, New Zealand, Canada, Russia, China, Vietnam. USA is a leader in FHIR adoption.
I work with vendors, institutions, and national healthcare programs around the world. I work directly for the US and Australian governments (ADHA), and through the Argonaut consortium, I work with multi-national corporations including Cerner, Epic, AllScripts, Apple, Google and many other companies.
I have provided technical advice to the MyHR program development since the beginning of the project.

Current Situation – State of the Art 2007

The existing MyHR system is a significant achievement: Australia has a national health records system based on solid technical standards. An under-appreciated amount of political, policy and technical development was needed that depended on extensive bi-partisan, agency and state support.
The design of the system and the standards it is based on were state of the art in 2007 . Although a more distributed design was initially planned, it is now, unfortunately, a centralised national database of static summary documents. This was an inevitable consequence of the technical standards used at the time, but now constrains the use, extensibility and therefore the value of the system.

Transforming Expectations: 2018

In the ensuing decade, there have been significant transformations in the technological and social context for the MyHR.
Significant technologies have been introduced or become widely available: smartphones (e.g. iPhone), wearables, cloud computing, and (mobile) high speed broadband. Associated with these technologies, there have been major new developments in data exchange protocols – particularly the growth of web Application Programming Interfaces (APIs), and the OAuth standard that supports federated authentication processes. In the last decade, these technologies and standards have transformed whole industries.
In response to these trends, in 2011 I created the FHIR specification, to allow the use of Web APIs in healthcare. I wanted to enable this innovation in healthcare to better support federated data processing – that is, an open data platform with multiple interactions between different independent parties (like the web itself). It was apparent then that the technical standards on which the MyHR was based were leading to an overall design that would lack the functionality and flexibility which consumers and providers now expect.
At the same time as these changes, there has been significant public impact resulting from the use of data collected through social media, and the ongoing stream of data breaches. Society is increasingly concerned about the appropriate use of data, re-identification and identity theft.
These developments need to be considered in future designs of the MyHR and associated digital services. Users now expect a federated system: an open system that allows them to connect to their different service providers directly, and that allows the service providers to interact directly with their customers with the care provision services that suit their customers.

National Digital Health Strategy

The National Digital Health strategy was published last year , and its recommendations recognise these trends. It calls for a set of new digital innovations to transform healthcare, leveraging the developments described above.
However, the existing MyHR is not a suitable vehicle for implementing many of these recommendations – the standards and overall design are not fit for this purpose. This is my opinion as an expert in this area, and also of other experts (see endorsements below).
One key problem in this respect is related to consent. A single national database requires consent agreements framed in complicated language consumers are not used to, and getting different consent agreements for particular projects (e.g. “I agree to share this information with my hospital and my GP, but no one else”) is too complex for the system designers, let alone consumers (see example). This is a key blocker for exploring new innovations associated with the system.
ADHA is presently engaged in ‘re-platforming’ the MyHR. At this time, it is not clear exactly what this means. It may simply be replacing the existing technical infrastructure with the same services from another vendor, or it may involve some limited or even extensive redesign of the system. ADHA has committed to a public consultation about the re-platforming process . However, extensive public consultation will be needed to make any real change to the overall design. The deadlines associated with re-platforming – complete by mid-2020 when the existing operational contact ends – means that it is now too late for any fundamental change to the overall design.

International Approaches

Internationally, there are a range of approaches which support consumer engagement and health data aggregation. Some countries focus on building single closed national data stores while others build frameworks for empowering consumers via support for open systems. Some countries are combining these approaches.
In general, the national data stores are associated with countries such as China and Vietnam and developing countries with low privacy concerns. USA (Argonaut) and Netherlands (MedMij) are building federated arrangements which strongly focus on empowering individuals by providing access to their health data. Commonwealth countries have generally favoured single national databases, often with associated political controversy (e.g. The UK care.data project ).
Irrespective of the approach, Australia is clearly lagging behind other countries which are prototyping innovative digital approaches to solve healthcare problems.

The Political Problem

The transition to opt-out has created a wave of controversy and media commentary around the MyHR system. Most of the informed commentary has focused on the technical and political dangers of a single database and lack of support for federated/open data-based services. There has also been discussion about the ‘confused value proposition’ of the MyHR. This is because the overall design of the system does not support the expectations consumers or healthcare providers now have, particularly as expressed in the National Digital Health Strategy. Users now expect more than digitised paper records.
Successive governments have had a strong focus on building towards the success of the MyHR. The result of this is that all other health IT projects are forced into the strait jacket of the centralised document store with its limited consent model, or they are de-prioritised and/or unfunded by DOH or ADHA. The industry expects that this narrow focus will become more intense after DOH makes another round of investment in the system (re-platforming).
An ongoing focus on a centralised document store with inflexible consent arrangements will ensure that the political controversy continues . Suppressing other options will continue to raise suspicions that the government is seeking to gather and use people’s healthcare data and/or restrict innovation in healthcare.

Recommendation

DOH and ADHA should prepare a blue print for an alternative framework that defines policies, standards and supporting services that establish a federated highly-interoperable health data exchange, and that leverages similar work and standards as used in other countries.
Specifically, this technical and policy framework should enable healthcare providers to break open the closed national database, and offer their own digital health services directly to consumers. The framework should re-use existing infrastructure (e.g. National Healthcare Identifiers Service and National Clinical Terminology Service) and add new services, such as web-ready authentication services. The framework should leverage the existing MyHR (patient-controlled document store) as one service offered to consumers within the overall eco-system.
This framework must provide for:

  • Implementation of the recommendations of the National Digital Health Strategy
  • Provide grounds for investing in projects without requiring use of the single national document store when it is inappropriate for the project
  • Provide confidence to jurisdictions, industry and healthcare providers with regard to implementation of projects that use an open design, implementing local requirements and offering services directly to consumers
  • Adoption of appropriate consent agreements and information for particular specific user and project needs instead of ‘one size fits all’
  • Supporting an active community that includes industry which takes stewardship of the technical standards and builds on the framework organically.

It is not enough that this framework exists – there must be a robust policy to use it where appropriate. At this time, there is no coherent overall strategy for a framework like this.

In the absence of such a concerted strategy, Australia will drift towards an unsatisfactory digital health system that lags even further behind the rest of the world, holding back innovation and improvements to the Australian Healthcare system.
These recommendations are intended to create both a technical path and political will to enable the National Digital Health Strategy to be delivered, and for many other improvements to the healthcare system to be possible.

Note: Some of this recommended work is already in progress, or is proposed in current ADHA workplan (“Co-design a National Technology Strategy that puts Australia at the cutting edge of national digital innovation”, from the agency workplan, page A13). The general intent of the recommendation is consistent with the message presented by ADHA since the publication of the National Health Digital Strategy. The problem is not the work that has happened, but the work that has not: this must have priority and budget

Endorsements

A number of my respected professional peers endorsed my submission. Some are shown here below – for full details, see the full senate submission. I think both those who endorsed my submission, and many others, for making significant contributions.

Mark Braunstein, MD, Professor of the Practice, Georgia Institute of Technology (presently on sabbatical in Australia)

The controversy surrounding the adoption of opt-out for MyHR is, in my view, symptomatic of a deeper issue which is the perceived value seen by Australians in having a MyHR. Patient access to their own digital health record (e.g. not just viewing the data but actually possessing it in a form that is suitable for use in healthcare apps or in other technical envelops) is now US government policy and it has led to a revolution in patient access to their data for whatever use individual patients find of value to them.
I too recognize that at the time MyHR was created the technology platform chosen was ‘state of the art’ but health informatics is now a rapidly progressing field (in no small part due to Grahame) and it is finally embracing the technologies of the web to make data access and use far more facile. Most major US EHR vendors now have FHIR app galleries and some of those apps are patient-directed. This trend will accelerate rapidly as a result of Apple’s decision to implement FHIR as a means of allowing patients to aggregate their health record from multiple sources on their iPhone.
Australia was brave enough to take a major first step in 2007. I hope it will find the will to make a mid-course correction that will significantly increase the value and I believe the acceptance of MyHR.

Jeff Parker, FCHSM, GAICD, Managing Director JP Consulting (Aust) Pty Ltd and a digital health strategy and management specialist

Grahame and I have spoken extensively about the idea of this submission and I have provided input and feedback in its development.
I’m adding my name to endorse the submission, as I support the overall argument it makes for change, and the recommendations in my view are sound and outline what is needed.

Emma Hossack B.A (Hons) LLB, LLM
CEO Extensia, President Medical Software Industry Association

Australia’s health software industry is strong. It can transform our healthcare system and lead the way internationally. We have observed the failure of one size fits all national health records in Australia and internationally.
We have a chance now to take advantage of the review, reset the architecture and realise the outcomes and efficiencies our industry enables. The ideas in this submission are a sensible way forward for Australia.

Reuben Daniels Managing Director and Principal Consultant, Saludax
Former Lead Architect, National E-Health Transition Authority (NEHTA)

Australia has all the ingredients to be the world leader in digital health:
• The realisation that digital is the way forward.
• Strong health informatics organisations: a society (HISA), a college (ACHI), and recognised world leaders;
• An active health informatics standards developer community;
• State and territory government health departments are actively investing in national initiatives and local digital health solutions (e.g. solutions for electronic health records, pathology, imaging, and medication management);
• The federal government is actively investing in digital health through the department of health and national agencies (e.g. the ADHA, AIHW, CSIRO, Healthdirect Australia, and the Digital Health CRC);
• Australia has a robust digital health research community;
• A strong software development industry for innovative products and services both locally and internationally;
• Growing education and certification opportunities to build our digital health workforce;
• Australia’s national infrastructure services for digital health (e.g. the National Clinical Terminology Service (NCTS) and the Healthcare Identifiers (HI) Service) are the envy of many nations;It is unfortunate that these are not yet fully harnessed to deliver a national platform for the meaningful exchange of healthcare data that is broadly supported by healthcare recipients, carers, providers, and administrators. Specifically, I agree with Grahame’s view that the current architecture of the My Health Record will not address delivery of the national digital health strategy.
The recommendation put forward in this submission is not only sensible and with strong foundation, it is essential if Australia is to maximise the value of digital health as a key enabler of better health outcomes for all Australians.

#FHIR and the Gartner Hype Cycle

On a forum for FHIR Foundation members, I raised the subject of where FHIR is on the Gartner Hype Cycle (see Gartner write up, or Wikipedia). FHIR Foundation member Wes Rishel (@wrishel), who’s a FHIR user, and also was a Gartner Analyst before he retired, graciously made this contribution that I could post here.

From 2000-2014 I was the person positioning health IT standards on Gartner’s Hype Cycle. In the last few years I created and positioned a spot for FHIR. Given my enthusiasm for FHIR it was always a struggle to maintain my professionalism. The professional side was assisted by peer review and a methodology that had evolved tracking tens of thousands of technologies for many years.
If I were still evaluating FHIR for the Gartner hype cycle I would be looking for the following factors to move it to the slope of enlightenment.

  • One or more well-defined, application-specific market segments.
  • Full adoption by a small portion of the market.
  • Predictability in assessing project risk and timing, based on experience with the technology.
  • Reasonable labor pool of experienced developers.
  • Conformance testing.
  • The development of at least an informal body of knowledge of what it takes to really interop with certain important FHIR servers or certain important EHR clients.
  • Having been through the “trough of disillusionment”

One or more well-defined market segments.

There are many markets and a wide variety of uses of FHIR, but the usage pattern that seems to have the widest adoption is “sidecar applications for EHRs”. Many of the SMART applications would fall into that category. Are there other segments that can be defined by usage patterns of participants in the marketplace? For example, are analytics products switching to FHIR rather than ad hoc interfaces? I acknowledge I’m out of the loop but I’m not aware of much that could be defined as having a common pool of vendors and purchasers (or in FHIR terms a common pool of server-apps and client-apps).

Full adoption by a small portion of the market.

As shown in the Wikipedia article that Grant cited, the first solid sign that a technology has turned the corner is ful” adoption by 5% of the market. “Full adoption” does not mean replacing an older technology. FHIR could be at the top of the slope while V2 messages still flow. I think I would have found this crieterion to be met if I could see that some group of healthcare organizations that care for at least 5% of the patients in industrialized countries were using FHIR for multiple independently developed apps in one of the market segments in mission-critical apps.
I am skeptical about this. As an indirect measure of widespread adoption for the sidecar market, I would be looking at how far the major EHR vendors had progressed at rolling out FHIR support. It seems to me that the biggest two vendors have active programs promoting FHIR adoption including standard business relationships with third-party vendors. That’s reasonable progress. The last I heard, though, the data available through the FHIR interfaces was read-only and limited to registration data. Third-parties were being encouraged to use non-FHIR proprietary interfaces for update and access to more data types.

Predictability in assessing project risk and timing, based on experience with the technology.

FHIR is easy to start to use and to get working in the lab or a Connectathon. If I were looking at project risk it would be towards the end of a project where testing can’t begin or is delayed because of one of the partner’s schedules or where unexpected semantic issues arise. These unfortunate events can happen in any project and, in theory, are less likely in RESTful interfaces. However, as products climb the slope of enlightenment they get less frequent. Are we there yet?

Reasonable labor pool of experienced developers.

This is one major source of technology risk. I would be looking at FHIR books, courses in school curricula including not only Universities but high-volume purveyors of video tutorials. I may be wrong but it seems like a limiting factor in FHIR education is that it takes a time of the most productive developers.

Conformance testing and certification.

A sign of a maturing interface technology is when the vendors that use the technology recognize that they need to make an investment in funding a common testing lab and slog through the hard technical and political issues of what it even means. FHIR has been developed from the start with import provisions for making and testing conformance and there are more than one places to operate such tests. There is a lot of potential. But it doesn’t rise to the level of a service mark that would give the consumer of Health IT products the assurance that if they buy two certified interoperable products, the product will interoperate. AFAIK we’ve never aspired to that level of conformance testing or certification in healthcare. It took Bluetooth and USB technologies years to appproach that level. Having having independent, industry-wide certification is a definite mark of a maturing technology.
One can argue that this is not an important criterion for being on the slope. HL7 v2 and CDA clearly made it to the slope without this. I agree, but I would argue that the demonstrated success of conformance testing would be a substantial argument for moving FHIR more rapidly to the slope.

The development of at least an informal body of knowledge of what it takes to really interop with certain important FHIR servers or certain important EHR clients.

This is a definite sign of the maturity of the technology. It means that management and system integrators can assess project risk on a much more nuanced basis. 

Having been through the “trough of disillusionment”.

If FHIR has gone through the trough it’s one of the shallowest troughs on record. Where are the click-bait postings on problems? Where are the failures of early startup vendors and the requirement for advanced rounds of capital?

The closest I’ve heard is some grumbling among sidecar-app vendors that they thought using FHIR would make it easy to sell. They describe problems getting big company CIOs to take their calls. One of the signs or a technology on the slops is a community of vendors that understand not only the technology but the practical issues of selling and delivery.

So, as much as I would like to be at Gartner positioning FHIR on the slope I would almost surely still place it pre-trough. 

Thanks for the contribution, Wes. A few clarifications from me:

  • Wes asks “Are there other segments that can be defined by usage patterns of participants in the marketplace? For example, are analytics products switching to FHIR rather than ad hoc interfaces?” – my answer is, yes, that’s happening, but it’s not yet at the point where you could call it ‘a market’
  • In general, there is lots of FHIR adoption, in lots of different ways, but they don’t constitute a identifiable market in the sense that Wes is talking about here. 
  • I’ve always been aiming for a shallow trough: if the fundamentals are in place, it won’t be so deep. But we still have fundamentals to get in place
  • I think, at least, that we are no longer in the rocket-mode growth phase of the very earliest part of the hype cycle.

Active Questionnaires in #FHIR

FHIR defines a Questionnaire resource that specifies a set of questions for a user, along with a QuestionnaireResponse resource to capture their response. Forms/Questionnaires like this are ubiquitious in healthcare, so this has had a lot of attention.

A questionnaire contains a list of questions, with a nested structure, and for each question, a way to specify another question that the visibility of the question depends on. But there’s several common ways people use questionnaires that this doesn’t deal with, that we could call ‘Active Questionnaire’ support:

  •         Prepopulating a questionnaire from known data
  •         Calculating a score for a questionnaire
  •         Extracting data from a questionnaire after entry and populating other resources
  •         Adaptive questionnaire where the next question depends on the answer to previous questions

A few of us have been working on proposals for how these problems could be solved in an interoperable way. I’m publishing these ideas here for discussion – then they’ll go to the HL7 committees for further consideration.

Note that our solutions to these problems are based on the availability of resources, and the RESTful API. This enables interoperability between the record server and the form filler, but it is not necessary that they are separate, or even that they use FHIR to communicate between them – the form filler can process the FHIR based questionnaire content for whatever form is desired.

Prepopulating a questionnaire

This is a common idea; that a series of questions will be asked about a patient, for a clinical user to answer. At least some of the questions will already have known answers from data stored in the system. E.g. Patient demographics, blood type, existing medications etc. Once the answers are populated, they are presented to the user who can change them if necessary.

We understand pre-populating a questionnaire in 3 phases:

  •         Specifying what the ‘context’ of a questionnaire is: the information that the form-filler needs when the user answers a questionnaire
  •         Defining Variables
  •         Filling the answers

Specifying the context

Extension: http://hl7.org/fhir/StructureDefinition/form-filler-parameter

This parameter defines a parameter that the form filler needs to pre-populate the questionnaire:

“Extension”: [{
    "url" : "http://hl7.org/fhir/StructureDefinition/form-filler-parameter",
    "extension: [{
      "url" : "name",
      "valueString" : "patient"
     },{
      "url" : "type",
      "valueCode" : "Patient"
     }]
  }]

This extension says that the form filler takes a parameter which is a FHIR Patient resource. The application that hosts the form filler (which may be a separate app or a module in the application) is provided this as external input. The parameter is named “patient” through out the questionnaire.

E.g. the form filler would be provided with a map of named resource that identify the application context of the questionnaire.

It’s up the form filler and/or the application to decide what to do if the parameter is not available; obviously pre-population won’t be possible, but it may not be right to even answer the questionnaire.

Defining Variables

“Extension”: [{ 
  "url" : "http://hl7.org/fhir/StructureDefinition/variable",
  "valueExpression" : {
    "name" : "sleepObs",
    "language" : "application/x-fhir-query",
    "expression" : "Observation?code=http://loinc.org|65972-2&date=gt{{today()-7 days}}&patient={{patient.id}}&_sort=-date&_count=1"
  }
}]

This extension defines a ‘variable’. A variable has a name, and a value which is a list of resources or FHIR types. Variables are defined on the questionnaire itself, or on any item, and available in the scope of the element where it is defined, and any contained items (unless overridden by a variable with same name on a contained item, which overrides if in the scope of that nested item).

Each variable is defined by a expression, which the form-filler evaluates when needed. Form-fillers should support FHIRPath and CQL for these expressions, but most important is the application/x-fhir-query type, which specifies a templated FHIR query. This is a query string that has no [base] (that’s known to the form filler, not the questionnaire). The query string allowed expressions using liquid format e.g. {{expression}}, where each expression is itself a FHIRPath expression.

The form filler evaluates the expression, and then executes the FHIR query against the record store it is operating in the context of. The set of resources in the response becomes the value of the variable.

In the case of the example above, that means one resource, the most recent observation for the patient if there is one in the last 7 days. Or ‘null’ if there isn’t one.

Filling the answers

When processing an item, the form-filler has a set of variables in context. The “populate-value” extension defines how a value is derived from the variables:

“Extension”: [{
  "url" : "http://hl7.org/fhir/StructureDefinition/populate-value",
  "valueExpression" : {
    "language" : "text/fhirPath",
    "expression " : "sleepObs.value"
  }
}]

The extension has a value which an expression, which is a FHIRPath expression, that extracts a value from one of the variables. The form-filler evaluates the expression, and if there is a value returned, and it is a valid answer for the item (e.g based on item type and allowed answers), then it goes in the answer.

The combination of

  •         Specifying what information is provided from the context
  •         Building up a set if variables by querying the record store
  •         Populating the answers by selecting information from the variables

meets most of the requirements for pre-populating the answers. Requirements beyond what can be done here fall back to adaptive questionnaires (see below).

Note that the data extraction section below defines additional ways by which questionnaires can be pre-populated.

Calculating a score for a questionnaire

A very common use case for questionnaires is to use them to calculate some kind of clinical score – such questionnaires are very common across healthcare. Mostly, it’s a fairly simple form – answer a series of linear questions, and get a single score, but there’s much more complex examples

Calculating a score is understood as a 3 step process:

  • Specifying a numeric value for some/all answers
  • Generating the score
  • Putting the score in an answer

Note that the third part is not necessary – the score might be generated and displayed to the user without being made part of the formal answers (on the basis that it can be recalculated as required).

Calculating the score

 “Extension”: [{
     "url" : "http://hl7.org/fhir/StructureDefinition/questionnaire-calculated-value",
     "valueExpression" : {
       “description” : “Score (0-4: healthy; 5-8: Moderate; 9-12: Serious)”,
       "language" : "text/fhirpath",
       "name" : "score",
       "expression" : "answers().sum(value.ordinal())"
     }
  }]

The questionnaire-calculated-value extension defines a variable (just like the /variable extension above) but it is special for two reasons:

  •         The value is re-generated each time the set of answers change (whereas other variables are only calculated when prepopulating
  •         The form filler may show the outcomes of calculated scores in a special part of the UI that is not part of the questionnaire

Most calculated scores depend on assigning calculated-value values to coded answers using the http://hl7.org/fhir/StructureDefinition/valueset-ordinalValue extension. This extension can appear in one of the following places:

  •         On an answerOption
  •         On a value set referred to from answerValueSet (contained or external)
  •         On the underlying code system (contained or external)

Resolving the ordinal value is a chore that can make the expressions unnecessarily complex. We define 3 FHIRPath short cuts to simplify the expressions:

  • answers() – a flattened collection of all the answers in a response
  • ordinal() – given the focus of an answer (QuestionnaireResponse.item.answer.valueCoding), look up the ordinal value where ever it is defined
  • sum(expression) – a shortcut for aggregate($this + expression, 0)

These are defined FHIR Path extensions for form-fillers to implement.

For most scores, there is only one score on the questionnaire. However more complex questionnaires may have multiple scores for different sections, or even multiple interlacing scores. The questionnaire-calculated-value extension may be found at the root of the questionnaire, or on any item (just like other variable definitions)

Extracting Data from a questionnaire

This is the converse of the Pre-population case – given a set of answers to a questionnaire, extract data out of the answers into a set of resources – maybe medication statements, etc, but most of all, observations.

Note that it is at the discretion of the system when to extract data from a questionnaire. The most obvious time to do so is when the user indicates the questionnaire is ‘complete’ but there may be intermediate steps (e.g. if the user suspends answering the questionnaire).

Extracting data well can be a hard problem. There is one common special case that justifies a specific simple approach: when the data is extracted into an observation. For other cases, we define a context based approach.

Observation / Questionnaires

A very common situation is that questionnaire items are actually observations, and the answer provided by the user will become stored observation in the system – and also should be used to pre-populate the answer if an appropriate observation exists.

Questionnaires already have a code to tie them to an observation:

"code": [{
  "system": "http://loinc.org",
  "code": "65972-2",
  "display": "Appetite or sleep change notes" 
  }],

We define an extension to define the link between the item and an observation this:

“Extension”: [{
  "url" : "http://hl7.org/fhir/StructureDefinition/questionnaire-observation-link",
  "valueDuration" : {
    "value" : "14",
    "system" : "http://unitsofmeasure.org",
    "code" : "d"
  }
}]

This instructs the form-filler to look for any observations that have occurred within the last 14 days (or, more generally, any duration, based on how quickly the particular observation goes stale). If such an observation is found, then the most recent is used. When the data is extracted from the questionnaire, a new observation is created if:

  •         there is no existing observation
  •         the user changed the answer
  •         the system decides to create a new observation from user approval of the existing value anyway

If an element has both a link to an observation, and a pre-population details, the pre-population is treated as a fallback approach for if no existing observation is found.

Context based Data Extraction

“Extension”: [{
  "url" : "http://hl7.org/fhir/StructureDefinition/context",
  "valueExpression" : {
    "language" : "application/x-fhir-query",
    "name" : "meds2",
    "expression" : "MedicationStatement?date=ge{{today()-30 days}}&patient={{patient.id}}&status=active,completed,stopped,unknown"
  }
}]

This not only defines a variable (per the variable discussion above) but establishes that the variable is the context for the item, which means that for each value in the variable, the item will repeat. This implies that a context should generally only be established on a repeating item that is a group, though specific applications might not follow this pattern.

There can only be one context for an item.

Once a context is established, items are tied directly to the context by using Observation.item.definition:

“definition” : “MedicationStatement#MedicationStatement.medicationCodeableConcept”,

The form-filler extracts the indicated element and populates the answer value accordingly. Note that there’s considerable subtlety here – the are potential data type conversion and cardinality issues to handle, and the answer value may only be a part of the data type (e.g. in this case, a coding from a CodeableConcept). Failures may be handled

The element definition can leverage a custom profile to be more specific:

“definition” : “http://acme.com/profiles/MedStmtBase#MedicationStatement.medicationCodeableConcept.coding:rxnorm”,

The form-filler retains the link from populating the resource, so that existing resources can be updated. Newly created item groups create new resources when they are associated with a repeating context, and the questionnaire defines hidden form fields with calculated or fixed values to fill out the rest of the content of new resources.

Note: this approach only handles moderately complex questionnaires. To go beyond this, applications would have to use StructureMap or write custom transforms in some implementation language.

Implementation Notes

Note that the reference libraries can easily do all these things – FHIRPath, queries, etc, but many product implementations do have the underlying language support for this. It may be useful to define a lower level conformance/questionnaire/reasoning API to make it easy for these facilities to be added to existing products.

Adaptive Questionnaire

This is a growing area of interest, where behind the questionnaire, there’s an expert system (or maybe a full AI system) guiding the user through a set of questions – enabling or disabling, or even creating a custom questionnaire as the user works through the questions.

The basic idea here is that the form-filler begins with a questionnaire, and a link to an advisor system. Each time the user answers a question, the advisor is consulted and returns one of the following responses:

  • No more questions
  • Existing answer (by id) is invalid
  • Next question is [id]
  • A new question to ask (after [id], or at the end)

In some cases, this means that there’s a custom questionnaire; this is built as the user answers the questions, and then should be stored alongside the answers to provide context (or inside the QuestionnaireResponse, as a contained resource).

For this, one option is to use cds-hooks. The hook definition is:

Questionnaire-advise

Metadata Value
specificationVersion 1.0
hookVersion 0.0

Workflow

Call this hook each time a user provides an answer in a questionnaire. The client (the form-filler) provides both the questionnaire that the user is answering, and the QuestionnaireResponse that captures the answers to this point, along with the id of the question answered, and an id that represents the instance of the form, which the cds hooks server may use to request access to the form filler parameters (as defined above).

Context

Field Optionality Prefetch Token Type Description
questions REQUIRED No Questionnaire The questionnaire that the user is answering (provide the whole questionnaire, since it may change during the answering process)
answers REQUIRED No QuestionnaireResponse The users’ answers to this point
answered OPTIONAL No string The dotted linkId of the last question answered (e.g. linkId based path to the answer given that groups can repeat. No value – the user hasn’t answered any questions yet (this session)
parameters OPTIONAL Yes string A list of name=value pairs in URL syntax that defines the parameters available to the form filler e.g. patient=Patient/123&context=Encounter/123. The questionnaire can be expected to refer to these parameters.

The cds hooks server can request that these be prefetched (how exactly?)

There’s plenty of questions about this approach; would it be better to just define a direct operation to do this? (Pro: it would be simpler, but con: cds hooks provides an infrastructure to get more information about the patient when the responder to this is not the same as the patient record holder). So discussion about this is ongoing

 

Example

Here’s a worked example to help understand these ideas:

{
  "resourceType": "Questionnaire",
  "id": "questionnaire-example-phq9",
  "url": "http://fhir.org/guides/argonaut-questionnaire/Questionnaire/questionnaire-example-phq9",
  "meta": {
    "profile": [
      "http://fhir.org/guides/argonaut-questionnaire/StructureDefinition/q"
    ]
  },
  "contained": [
    {
      "resourceType": "ValueSet",
      "id": "PHQ-9",
      "url": "http://fhir.org/guides/argonaut-questionnaire/ValueSet/PHQ-9",
      "version": "0.0.0",
      "name": "PHQ-9",
      "title": "PHQ / Patient Health Questionnaire (PHQ-9) Not at all/Several days/More than half the days/Nearly every day",
      "status": "active",
      "date": "2018-04-05T12:40:10-07:00",
      "description": "PHQ / Patient Health Questionnaire (PHQ-9) Not at all/Several days/More than half the days/Nearly every day   http://loinc.org/vs/LL358-3",
      "jurisdiction": [
        {
          "coding": [
            {
              "system": "urn:iso:std:iso:3166",
              "code": "US",
              "display": "United States of America"
            }
          ]
        }
      ],
      "copyright": "This content LOINC® is copyright © 1995 Regenstrief Institute, Inc. and the LOINC Committee, and available at no cost under the license at http://loinc.org/terms-of-use",
      "compose": {
        "include": [
          {
            "system": "http://loinc.org",
            "concept": [
              {
                "extension": [
                  {
                    "url": "http://hl7.org/fhir/StructureDefinition/valueset-ordinalValue",
                    "valueDecimal": 0
                  }
                ],
                "code": "LA6568-5",
                "display": "Not at all"
              },
              {
                "extension": [
                  {
                    "url": "http://hl7.org/fhir/StructureDefinition/valueset-ordinalValue",
                    "valueDecimal": 1
                  }
                ],
                "code": "LA6569-3",
                "display": "Several days"
              },
              {
                "extension": [
                  {
                    "url": "http://hl7.org/fhir/StructureDefinition/valueset-ordinalValue",
                    "valueDecimal": 2
                  }
                ],
                "code": "LA6570-1",
                "display": "More than half the days"
              },
              {
                "extension": [
                  {
                    "url": "http://hl7.org/fhir/StructureDefinition/valueset-ordinalValue",
                    "valueDecimal": 3
                  }
                ],
                "code": "LA6571-9",
                "display": "Nearly every day"
              }
            ]
          }
        ]
      }
    }
  ],
  "identifier": [
    {
      "system": "http://acme.org/q-identifiers",
      "value": "business-identifier"
    }
  ],
  "title": "Patient Health Questionnaire (PHQ-9)",
  "status": "draft",
  "code": [
    {
      "system": "http://loinc.org",
      "code": "44249-1",
      "display": "PHQ-9 quick depression assessment panel:-:Pt:^Patient:-:Report.PHQ-9"
    }
  ],
  "subjectType": [
    "Patient"
  ],
  "extension" : [{
     "url" : "http://hl7.org/fhir/StructureDefinition/questionnaire-calculated-value",
     "valueExpression" : {
       "language" : "text/fhirpath",
       "name" : "score",
       "expression" : "answers().sum(value.ordinal())"
     }
  }, {
    "url" : "http://hl7.org/fhir/StructureDefinition/form-filler-parameter",
    "extension: [{
      "url" : "name",
      "valueString" : "patient"
     },{
      "url" : "type",
      "valueCode" : "Patient"
     }]
  }]
  "item": [
    {
      "linkId": "panel",
      "code": [
        {
          "system": "http://loinc.org",
          "code": "44249-1",
          "display": "PHQ-9 quick depression assessment panel:-:Pt:^Patient:-:Report.PHQ-9"
        }
      ],
      "text": "Over the last 2 weeks, how often have you been bothered by any of the following problems?",
      "type": "display"
    },
    { // observation lookup
      "extension" : [{     
        "url" : "http://hl7.org/fhir/StructureDefinition/variable",
        "valueExpression" : {
           "language" : "application/x-fhir-query",
           "name" : "sleepObs",
           "expression" : "Observation?code=http://loinc.org|65972-2&date=gt{{today()-7 days}}&patient={{patient.id}}&_sort=-date&_count=1"
         }
      }, {
        "url" : "http://hl7.org/fhir/StructureDefinition/populate-value",
        "valueExpression" : {
          "language" : "text/fhirPath",
          "expression " : "sleepObs.value"
        }
      }, {
        // if there's an observation on this patient (and in other applicable context) with the 
        // same code as the item, in the specified duration before [now], 
        // use the most recent observation value for the item. If there's no observation, it would 
        // appropriate to create one for later re-use if the system is capable of this.
        //
        // note: if you have this extension, the other two extensions (variable & populate) are
        // treated as fall backs if there is no observation
        //
        //  if there's no answer when form is completed, systems can (but are not required to) create an observation with 
        // dataAbsentReason = asked-declined
        "url" : "http://hl7.org/fhir/StructureDefinition/questionnaire-observation-link",
        "valueDuration" : {
          "value" : "14",
          "system" : "http://unitsofmeasure.org",
          "code" : "days"
        }
      }],
      "linkId": "sleeping",
      "code": [
        {
          "system": "http://loinc.org",
          "code": "65972-2",
          "display": "Appetite or sleep change notes"
        }
      ],
      "text": "How well have you been sleeping",
      "type": "string"
    },
    { // medications look up
      "extension" : [{
        "url" : "http://hl7.org/fhir/StructureDefinition/variable",
        "valueExpression" : {
           "language" : "application/x-fhir-query",
           "name" : "meds",
           "expression" : "?type=MedicationAdministration,MedicationRequest,MedicationStatement
              &code:in=http://valuesets/anti-depressant&date=gt{{today()-7 days}}&patient={{patient.id}}"
         }
      }, {
        "url" : "http://hl7.org/fhir/StructureDefinition/variable",
        "valueExpression" : {
           "language" : "application/x-fhir-query",
           "name" : "medsObs",
           "expression" : "Observation?code=http://loinc.org|XXX-X&date=gt{{today()-7 days}}&patient={{patient.id}}&_sort=-date&_count=1"
         }
      }, {
        "url" : "http://hl7.org/fhir/StructureDefinition/populate-value",
        "valueExpression" : {
          "language" : "text/fhirPath",
          "expression " : "meds.count() > 0 or medsObs.value"
        }
      }],
      "linkId": "anti-depressant",
      "text": "Are you taking anti-depressant therapy?",
      "type": "boolean"
    }, {
      // tie this to a list of medication statement resources 
      "extension" : [{
        "url" : "http://hl7.org/fhir/StructureDefinition/context",
        "valueExpression" : {
          "language" : "application/x-fhir-query",
          "name" : "meds2",
          "expression" : "MedicationStatement?date=ge{{today()-30 days}}&patient={{patient.id}}&status=active,completed,stopped,unknown"
      }]
      "linkId": "medlist",
      "text": "List of current or recent meds (last 30 days)",
      "type": "group",
      "required": false,
      "repeats": true,
      "item" : [{
        "linkId": "med",
        // one of these two.... (second ties to a more limited context)
        "definition" : "MedicationStatement#MedicationStatement.medicationCodeableConcept", // if system doesn't know which coding, pick first or go bang
        "definition" : "http://chris.special.guy/profiles/MedStmtBase#MedicationStatement.medicationCodeableConcept.coding:rxnorm",
        "text": "Name of medication",
        "type": "open-choice",
        "required": true,
        "options" : "http://hl7.org/fhir/rxnorm-and-unii-and-everthing-else-too"
      }, {
        // tie this to MedicationStatement.status
        "extension" : {[
           "url" : "http://hl7.org/fhir/StructureDefinition/populate-value",
           "valueExpression" : {
             "language" : "text/fhirPath",
             "expression " : "status = 'active'" // cause we've specified the context
           }
        }, {
           "url" : "http://hl7.org/fhir/StructureDefinition/extract-value",
           "valueExpression" : {
             "language" : "text/fhirPath",
             "expression " : "iff($this, 'active', 'stopped')"
           }
        }]
        "linkId": "status",
        "definition" : "MedicationStatement#MedicationStatement.status", 
        "text": "Current?",
        "type": "boolean",
        "required": true
      }, {
        "linkId": "how-long",
        "text": "How many days ago did you stop taking this?",
        "type": "decimal",
        "required": false
      }, {
        // tie this to MedicationStatement.note.text
        "linkId": "comment",
        "definition" : "MedicationStatement#MedicationStatement.note.text", // this is implicitly defined not explicit
        "text": "Comments about medication (dose, frequency etc)",
        "type": "string",
        "required": false
      }]
    },
    {
      "linkId": "LittleInterest",
      "code": [
        {
          "system": "http://loinc.org",
          "code": "44250-9"
        }
      ],
      "text": "Little interest or pleasure in doing things",
      "type": "choice",
      "required": true,
      "options": {
        "reference": "#PHQ-9",
        "display": "Patient Health Questionnaire (PHQ-9) Not at all/Several days/More than half the days/Nearly every day"
      }
    },
    {
      "linkId": "FeelingDown",
      "code": [
        {
          "system": "http://loinc.org",
          "code": "44255-8"
        }
      ],
      "text": "Feeling down, depressed, or hopeless",
      "type": "choice",
      "required": true,
      "options": {
        "reference": "#PHQ-9",
        "display": "Patient Health Questionnaire (PHQ-9) Not at all/Several days/More than half the days/Nearly every day"
      }
    },
    {
      "linkId": "TroubleSleeping",
      "code": [
        {
          "system": "http://loinc.org",
          "code": "44259-0"
        }
      ],
      "text": "Trouble falling or staying asleep",
      "type": "choice",
      "required": true,
      "options": {
        "reference": "#PHQ-9",
        "display": "Patient Health Questionnaire (PHQ-9) Not at all/Several days/More than half the days/Nearly every day"
      }
    },
    {
      "linkId": "FeelingTired",
      "code": [
        {
          "system": "http://loinc.org",
          "code": "44254-1"
        }
      ],
      "text": "Feeling tired or having little energy",
      "type": "choice",
      "required": true,
      "options": {
        "reference": "#PHQ-9",
        "display": "Patient Health Questionnaire (PHQ-9) Not at all/Several days/More than half the days/Nearly every day"
      }
    },
    {
      "linkId": "BadAppetite",
      "code": [
        {
          "system": "http://loinc.org",
          "code": "44251-7"
        }
      ],
      "text": "Poor appetite or overeating",
      "type": "choice",
      "required": true,
      "options": {
        "reference": "#PHQ-9",
        "display": "Patient Health Questionnaire (PHQ-9) Not at all/Several days/More than half the days/Nearly every day"
      }
    },
    {
      "linkId": "FeelingBadAboutSelf",
      "code": [
        {
          "system": "http://loinc.org",
          "code": "44258-2"
        }
      ],
      "text": "Feeling bad about yourself - or that you are a failure or have let yourself or your family down",
      "type": "choice",
      "required": true,
      "options": {
        "reference": "#PHQ-9",
        "display": "Patient Health Questionnaire (PHQ-9) Not at all/Several days/More than half the days/Nearly every day"
      }
    },
    {
      "linkId": "TroubleConcentrating",
      "code": [
        {
          "system": "http://loinc.org",
          "code": "44252-5"
        }
      ],
      "text": "Trouble concentrating on things, such as reading the newspaper or watching television",
      "type": "choice",
      "required": true,
      "options": {
        "reference": "#PHQ-9",
        "display": "Patient Health Questionnaire (PHQ-9) Not at all/Several days/More than half the days/Nearly every day"
      }
    },
    {
      "linkId": "MovingSpeaking",
      "code": [
        {
          "system": "http://loinc.org",
          "code": "44253-3"
        }
      ],
      "text": "Moving or speaking so slowly that other people could have noticed. Or the opposite - being so fidgety or restless that you have been moving around a lot more than usual",
      "type": "choice",
      "required": true,
      "options": {
        "reference": "#PHQ-9",
        "display": "Patient Health Questionnaire (PHQ-9) Not at all/Several days/More than half the days/Nearly every day"
      }
    },
    {
      "linkId": "TotalScore",
      "code": [
        {
          "system": "http://loinc.org",
          "code": "44261-6"
        }
      ],
      "text": "Total score",
      "type": "integer",
      "required": true,
      "extension" : [{
        "url" : "http://hl7.org/fhir/StructureDefinition/populate-value",
        "valueExpression" : {
          "language" :"text/fhirPath",
          "expression " : "score"
        }
      },{ 
        "url" : "http://hl7.org/fhir/StructureDefinition/questionnaire-hidden", 
        "valueBoolean" : false
      }]
    },
    {
      "linkId": "Difficulty",
      "code": [
        {
          "system": "http://loinc.org",
          "code": "44256-6"
        }
      ],
      "text": "If you checked off any problems, how difficult have these problems made it for you to do your work, take care of things at home, or get along with other people",
      "type": "choice",
      "required": true,
      "options": {
        "reference": "#PHQ-9",
        "display": "Not difficult at all/Somewhat difficult/Very difficult/Extremely difficult-Perceived difficulty (PHQ-9)"
      }
    },
    {
      // including a questionnaire module 
      // any link ids in the questionnire are prefixed with this id. 
      "linkId": "prefix",
      "type": "group",
      "required": true,
      "extension" : [{
        "url" : "http://hl7.org/fhir/StructureDefinition/questionnaire-include",
        "valueUri" : "[canonical URL]"
      }]
    }
    
  ]
}

Understanding #FHIR Patterns

The FHIR R4 ballot is out (see announcement), and I’d like to draw attention to one part of FHIR that we’ve been working hard on during the preparation of R4: Patterns.

Specific vs General

The background to patterns relates to generality vs specificity of the content models. When designing content models for exchange, designers have a choice:

(Sometimes this is called “Concrete” and “Abstract” but that has other meanings, so I’m going to stick with Specific / General)

Specific Designs:

  • For each actual exchange you want, you design a content model (schema) that has exactly the data items that you want for that exchange
  • This is really convenient for that exchange, because you only deal with exactly what the problem calls for
  • But as you deal with more and more related problems, you start from scratch each time, and spend more and more of your time writing transforms between the content models

General Designs:

  • You sum up all the related problems you have, and all the ones you can imagine, and design a big content model that handles all of them in a single structure
  • You get to reuse a lot of your work across different related problems
  • But each specific problem you work on, you get the tax of transforming to the general content model, and how do you prescribe these transforms?

This concept easily be illustrated using poetry: imagine that you are writing a scheme to describe a poem. It’s easy to imagine specific schemas for haikus and limericks, for instance – the rules for these are very well known. But there’s many other poetry forms that a much more fluid, and the schema becomes ever more flexible as you try to account for them (do poems even have to have words?). (h/t to Andrew Goodchild for introducing me to this example many years ago).

Choosing between Specific and General is a trade-off; there’s no great solution because you’re going to get transforms somewhere, and everyone (rightly) hates transforms. Also, it’s not a binary choice – you can (and should!) design somewhere along the spectrum, and where you land on the line is driven by a number of practical considerations.

In FHIR, we made a specific decision to be as specific as we can get away with. We debate the selection of use cases that get a common content model extensively, and have a number of consultation, community and management processes that deal specifically with this question. That still leaves us in the middle of the line somewhere, and we need to provide implementers with a language to deal with implementing more using a more specific or more general approach than FHIR. That’s necessary because implementers have their own constraints, and existing approaches that are already set in stone.

For supporting more specific approaches, we have profiling.

For supporting more general approaches, we have patterns.

FHIR Patterns

What we call patterns in FHIR (a name chosen somewhat arbitrarily) are a FHIR logical model that describes a more general pattern, and which the resources are required to conform to somewhat.

FHIR logical models are content models where the content modelling infrastructure developed for FHIR are used to describe a content model that is not a FHIR resource or data type.

Btw, note that the term “Logical Model” is really about the content being described is not – it’s not a FHIR resource or data type. In practice, we are using these for all sorts of things – domain analysis models, concrete schemas from other standards (v2, CDA, etc), or abstract design patterns. These are all different things, and lumping them under the general term “logical model” doesn’t really describe what’s going on here – we’re reviewing our use of language here.

FHIR patterns are logical models that describe a general design that other resources are required to follow to some degree. The most general pattern is the Five ‘W’s Attribution pattern (Who, What, When, Where, Why). This pattern describes a set of common attributes that resources might have:

This pattern says, for instance, that in general, resources might have identifiers, a version element, a status code, etc, and these are the recommended form for representing this attribution information in resources.

Resources can then define which elements they have, and how they map to the pattern – that is, how the resource is consistent with the pattern. Here’s an example for the DocumentReference resource:

The FHIR tooling then takes this information, and generates a large summary table that shows how the pattern is implemented in all the resources. Here’s the row for Document Reference:

This shows which pattern elements have a mapping into the resource for the Attribution pattern.

There are 3 other patterns:

  • Event: A pattern to be followed by resources that represent the performance of some activity, possibly in accordance with a request or service definition.
  • Request: A pattern to be followed by resources that represent a specific proposal, plan and/or order for some sort of action or service
  • Definition: A pattern to be followed by resources that represent a specific proposal, plan and/or order for some sort of action or service

Consistency?

An important fact – evident above – is that not all resources have these elements. Some literally contain elements based exactly on these element definitions, even using the same definitions, while others have some variation – sometimes the general concept is split into different elements capturing different aspects of the general case, or a simplified representation is chosen since it’s possible to be more specific for the use case in question. Or sometimes, the committee decides that there’s an obvious fixed value for one of the attributes, and documents that in the resource design, or sometimes committees decide that the element is not relevant for exchange in this use case (and that is a valid thing to do – there’s always the provenance resource to fall back on, where all of these elements can be represented).

It’s also possible that committees have failed to consider the use cases that these elements represent. That’s one of the points of defining these patterns – we can check whether resources conform to them, and require committees to account for the differences, to make sure that the use cases have been considered. This is work in progress – the patterns are following along behind the resources, and so it would be very appropriate to ballot around pattern consistency.

Note: alert readers with experience with HL7 v3 or openEHR will note that our approach here is different than in either of these, where pattern conformance is ruthlessly enforced, and we know that not everyone is happy about this. But it’s been a key philosophy of ours from the start, that the domain requirements are more important than the pattern consistency requirements.

We do have tooling that checks that when resource elements are mapped to pattern elements, they are actually consistent with the pattern element definitions and value domains, but at this time these are mostly only identified as QA issues for the committees to check. Over time, we expect some of these issues to turn into hard errors that must be resolved prior to publication.

Status Codes

One pattern element that has received particular focus is the status code element. Most (though not all) resources have a status element that describes the status of the resource. The possible status codes span the state of the resource as a record about a real world entity, and the state of the real world entity itself. Each resource defines its own status code, with a definition using language specific to the use cases that the resource addresses.

Every status code is also mapped to a code in the canonical status code system. Here’s the mapping for DocumentReference.docStatus:

So every status in a FHIR resource can be converted to a canonical status codes – this means that the resources have a common set of status codes. (Terminologists may think of this as a reference terminology with a set of interface terminologies.)

All of this infrastructure – the patterns, the element mappings, the code systems, and the concept mappings – is all published as conformance resources so that tools of all kinds can pick up the information and reason with it, whether that’s for design validation, resource validation, code generation, implementation guide publishing, etc.

Implementer Use of Patterns

While the patterns are defined to assist with design consistency, the intent is that they will also be useful to implementers: implementers that work with a more general design approach than FHIR – e.g. parts of the CIMI community (though CIMI is also very interested in very specific content models too) – can map to a pattern instead of individual resources. Then tooling could determine which of the mappings are reflected directly in particular resources, and which are unresolved (may need extensions?)

Such a mapping approach is somewhat degenerate, as described above – but that’s actually the point. One of the lessons of the V3 experience is that there is implicit degeneracy in the general à specific model transformation, and one of the big problems of V3 was that the degeneracy turned into under the cover issues for implementers. We believe that making the degeneracy explicit in the mappings is actually a value proposition.

So this is our intent: that implementers working with a more general design approach use patterns to map to the FHIR specification as part of their implementation guides. This is very much work in progress: there’s presently no clearly described way for an implementer to define their own pattern, or define mappings for the different resources for the pattern, or to publish this in an implementation guide, or to generate code from such mappings in the various relevant languages. Watch this space!

Blockchain in Heathcare – are standards needed?

Last weekend, in the lead in to HIMSS in Las Vegas, several of the FHIR team met with a number of block chain specialists, most particularly including David Huseby from the Hyperledger project at the Linux Foundation. We discussed various use cases for use of blockchain, with the intent of understanding what – if anything – HL7 should do to support blockchain adoption through the standards process. During an open and wide-ranging discussion, several of us came to the following consensus about the use of blockchain in healthcare (and we thank David greatly for his assistance).

Legal Assurance on Audit Trail

The first use case we recognised where blockchain has an obvious and appropriate usage is to provide strong legal assurance that an audit trail has not be tampered with. There’s all sorts of functions that a healthcare provider carries out where they may eventually be asked to provide evidence concerning past actions, and where there is a need to demonstrate that the audit trail has not been tampered with – and that includes against tampering by the system administrators themselves (that’s a very real concern – highly authorised insiders are the most likely attackers on the audit trail). If the audit trail is kept in electronic form, the only IT resource I know of that is proof against this level of attack is a distributed block chain where the system administrators don’t have total control of all the nodes.

There’s any number of compelling use cases for this in healthcare:

  • Compliance with GPDR removal-of-data requests
  • Keeping records around infection control
  • Keeping records involving cases of sexual abuse or other criminal behavior
  • etc

Technically, this is a really unchallenging use of blockchain – the head that creates blocks is completely trusted, so there’s no need for any form of voting/contest creating new blocks (e.g. no energy penalty cost for mining). And the audit trail only needs to contain encrypted copies of the actual records (or, alternatively, hash values for the records, though this introduces uncertainty around keeping hash methods constant over a period potentially spanning decades – though simply encrypting the records just moves the instability of system/version rot around). All the institution needs is one or more partners that can support the blockchain – it can be either private or public.

In fact, given how compelling this use case, it’s surprising that there isn’t commercial escrow type services simply hosting blockchains as a business service (at least, we didn’t know of any such service). It’s something that should be pretty easy to turn into a commodity using something like hyperledger, and there are strong reasons for healthcare providers to pay attention to storing these kinds of records really well.

Of course, this use of block chain is hardly scratching the surface of what block chain can do.

Need for Legally Established Trust

There’s lots of proposals floating around for using blockchain to create new trust arrangements. But whenever we considered actual use cases, we kept finding that in healthcare, any sharing of information, or delegation of trust or responsibility from one party to another starts in a closed regulated system, loaded with legal liability etc. You can’t begin to share information until you’ve established the legal basis for trust by contract – legal agreements and business agreements. And once you’ve established all those agreements, you don’t actually need a block chain – you can just have a central managed database by some consortium or foundation that acts on behalf of it’s members. This is a classic well established pattern in healthcare (see under Commonwell and Carequality – there are many others).

So, in practice, the need for legally established trust in a closed system turns out to mean that many of the proposed uses for blockchain involve quite a lot of hype.

But not all of them. For a start, while you’re going through the negotiations to set up such a consortium agreement, the fact that all the information associated with the agreements will be provably shared amongst all the participants can make it much easier to set up agreements that involve potential commercial benefit to one advantaged player… and I’ve seen several otherwise very useful initiatives flounder on this point.

And given my first law of interoperability – it’s all about the people – that means that blockchain turns out to be potentially pretty useful for interoperability after all, as a tool for changing how people think.

In fact, even just mentioning blockchain right now gets people’s attention – that’s a clear use case for using it, even when there’s no technical merit to the use of block chain directly.

Clinical Credential Tracking

We did discuss one very specific use of a public blockchain where it appears to be very useful – clinical credential tracking in USA. So it was somewhat ironic to see this headlines in USA Today today:

 

Standards Support for Blockchain

The upshot of all this is that it’s not at all clear that there’s any need for HL7 to work on blockchain related standards. We’re mainly going to sit back and watch this space and observe to see whether any compelling use case for standardization emerges – because it hasn’t yet (a compelling use case for standardization needs much more than just a compelling business use case for use of blockchain). But we are going to investigate 2 things:

  • Is there anything useful we should do about creating standard ways to create function specific audit trails from FHIR resources/bundles or CDA documents?
  • Should HL7 work on data and format standards to support clinical credential tracking (including, is this a real problem – we didn’t have consensus on this). Also, there are already communities working on it, and so we’d need to reach out to them to see whether formal standards support is useful for them

Comments welcome….