Category Archives: Standards

#FHIR Paradigms

Many of the FHIR tutorials show this diagram:

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

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

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

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

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

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

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

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

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

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

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

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.

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.

 

 

Lloyd McKenzie on Woody Beeler

Guest post: My close friend Lloyd wanted to share his thoughts on hearing the news about Woody.

My recollections of Woody are similar to Grahame’s.

I started my HL7 international journey in 2000.  In my case, it was in an attempt to understand how I could design my v2 profiles so they would be well aligned with v3.  I quickly learned the foolishness of that notion, but became enamored of the v3 effort.

HL7 was an extremely welcoming organization and Woody played a big part in that welcome.  I was a wet-behind the ears techy from Canada and he was an eminent physician, former organization chair and respected elder of the organization.  Yet he always treated me as an equal.  Over the years, we collaborated on tooling, data models, methodology, processes and the challenges of getting things done in an organization with many diverse viewpoints.  In addition to his sense of humour and willingness to get his hands dirty, I remember Woody for his passion.  He really cared about making interoperability work.  He was willing to listen to anyone who was trying to “solve the problem”, but he had little patience for those who he didn’t sense had similar motivations.

His openness to new ideas is perhaps best exemplified by his reaction to the advent of FHIR.  Woody was one of the founding fathers of v3 and certainly one of its most passionate advocates.  Over his time with HL7, he invested years of his life advocating, developing tools, providing support, educating, guiding the development of methodology and doing whatever else needed to be done.  Given his incredible investment in the v3 standard, it would not be surprising for him to be reluctant to embrace the new up-and-comer that was threatening to upset the applecart.  But he responded to the new development in typical Woody fashion.  He asked probing questions, he evaluated the intended outcomes and considered whether  the proposed path was a feasible and efficient way to satisfy those outcomes.  Once he had satisfied himself with the answers, he embraced the new platform.  Woody took an active role in forming the FHIR governance structures served as one of the first co-chairs of the FHIR govenance board.  To Woody, it was the outcome that mattered, not his ego.

Woody embraced life.  He loved traveling with his wife Selby (and his kids or grandkids when he could).  He loved new challenges.  He loved his work, but he wasn’t afraid to play either.  He was an active participant in after-hours WGM poker games.

It was with reluctance that Woody stepped back from his HL7 activities after his diagnosis with cancer, but as he expressed it at the time, he had discovered that he only had time for two of three important things – fighting his illness, spending time with his family and doing the work he loved with HL7.  He chose the right two priorities.

While version 3 might not have had the success we thought it would when we were developing it, the community that evolved under HL7 v3 and the knowledge we gleaned in that effort has formed the essential foundation and platform that enabled the building of FHIR.  I am grateful to have had Woody in my life – as a mentor, a co-worker and a friend.  I am grateful too for everything he helped build.  Woody’s priority was to focus on really making a difference.  In that he has set the bar very high for the rest of us.

Thank you for everything you’ve done Woody.  We miss you.

Woody Beeler has passed away

Today, Woody Beeler passed away after battling cancer for a few years. Woody was a friend, an inspiration, and my mentor in health care standards, and I’m going to miss him.

I first met Woody in 2001 at my first HL7 meeting. It was Woody who drew me into the HL7 community, and who educated me about the impact that standards could have. Many people at HL7 have told me the same thing – it was Woody that inspired them to become part of the community.

When I remember Woody, I think of his humour, his passion for developing the best standards possible, and his commitment to building the community out of which standards arise. And I remember the way Woody was prepared to roll up his sleeves and get his hands dirty to get the job done. To the point of learning significant new technical skills long after retirement age had come and gone. Truly, a Jedi master at healthcare standards.

For many years, Woody was the v3 project lead for HL7. Woody wasn’t blind to the issues with v3, but it was the best option available to the community at the time – so he gave everything he had to bring v3 to completion.  And it was Woody who mentored me through the early stages of establishing the FHIR community.

It’s my goal that in the FHIR project we’ll keep Woody’s commitment to community and healthcare outcomes – and doing whatever is needed – alive.

Vale Woody

(pic h/t Rene Spronk, who maintains a history of HL7 v3 – see http://ringholm.com/docs/04500_en_History_of_the_HL7_RIM.htm)

FHIR Product Priorities for Release 4

Now that we’ve published Release 3 of FHIR, it’s time for us to consider our main priorities for the next FHIR release. This is my draft list of product priorities that we’ll be discussing – and trying to execute – at the Madrid meeting next week:

  • Normative: push to normative for
    • Foundation / API / XML / JSON / Bundle / OperationOutcome
    • Terminology Service (ValueSet / CodeSystem / ExpansionProfile)
    • StructureDefinition / CapabilityStatement
    • Patient / RelatedPerson / Practitioner / Organization / ?Endpoint
  • Position a core set of clinical resources (‘health base’?) for normative in R5 (or Observation | AllergyIntolerance | MedicationStatement normative for R4?)
  • JSON: ? use manifest for extensions, parameters resource (see blog post) (note that discussion on this didn’t go very well – probably will be dropped)
  • RDF: more ontology bindings + resolve status of JSON-LD
  • Data Analytics: support for a bulk data analysis bridge format (Apache Parquet?)
  • API: better control over retrieving graphs, and value added query support (tabular format?)
  • Patterns: change the W5 framework to a pattern (logical model), tie the patterns to ontology, and use of patterns to drive more consistency (and how to do this without decreasing quality)
  • Services: more services. Candidates: conformance, registry, personal health summary?, etc?
  • Deployment: get a clear standards path for smart on fhir / cds-hooks (and alignment with UMA/Heart)
  • FM: work on alignment between FM resources and the rest of FHIR

Note that this list is written anticipating that the normal standards development process occur, and the content as a whole is maintained. I’d expect that this would amount to 1000s of tasks. So this list is not a list of ‘what will change in R4’, but an indication of where particular focus will be applied by the FHIR leadership (so don’t be concerned if a particular issue of yours is not on this list, as long as it’s in gForge)

Proposal for #FHIR JSON format change: @manifest

There’s a long running discussion in the FHIR community about the way the JSON format handles extensions, and operation invocations (“Parameters”) resource.  Various implementers keep proposing format changes to the JSON format around extensions, but the last time we made an attempt to change this, it was roundly quashed at ballot.

The underlying problem is that there’s 2 different (though overlapping) communities that use the JSON format for FHIR:

  • the interoperability community, who value consistency and robustness
  • the app writing community who value conciseness much more

From the perspective of the second community, the current JSON format doesn’t work well for representing either extensions, or the parameters of an operation. With this in mind, and drawing on the practices of the JSON-LD community, I’d like to advance a proposal for a manifest approach to extensions and parameters in the FHIR JSON format.

The way this would work is that we start with the existing format, and add a “@manifest” property, which contains information about how extensions and parameters have been represented in the json format. Applications reading the JSON format can either read the properties directly, based on their implicit knowledge of the manifest, or read the manifest and process accordingly.

As an example, consider this example Patient resource:

{
  "resourceType": "Patient",
  "id": "ex1",
  "extension": [
    {
      "url": "http://example.org/StructureDefinition/trials",
      "valueCode": "renal"
    }
  ],
  "active": true
}

This uses an extension following as specified in FHIR Release 3. The same resource rendered using a manifest might look like this:

{
  "resourceType": "Patient",
  "id": "ex1",
  "@manifest" : {
    "trials" : {
      "extension" : "http://example.org/StructureDefinition/trials",
      "type" : "code",
      "list" : false
    }
  },
  "trials": "renal",
  "active": true
}

Note: It’s important to note that processing the JSON directly and ignoring the manifest is a convenient but fragile approach; changes in naming or type would be transparent to an application that processed via the manifest, but would likely break an application that processed using the ‘trials’ name directly. That doesn’t mean that applications should not do this; just that it should only be used where the client and server are fairly closely linked and managed.

Aside: I think of this as ‘interoperability’ vs ‘operability’. At heart, FHIR is a specification for an API between disparate systems with different designs and life cycles (and customers – see ‘drive-by interoperability‘). But lots of people are using it as a client/server format for singly maintained applications (often because there’s no strong technical boundary between the internal and external use) – and it’s in that tightly managed context that the manifest approach brings the most benefit with a manageable risk.

It’s also possible to take the manifest and move it out of band:

{
  "resourceType": "Patient",
  "id": "ex1",
  "@manifest" : "http://healthintersections.com.au/patient.manifest.json",
  "trials": "renal",
  "active": true
}

And then, at http://healthintersections.com.au/patient.manifest.json:

{
  "@manifest" : {
    "trials" : {
      "extension" : "http://example.org/StructureDefinition/trials",
      "type" : "code",
      "list" : false
    }
  }
}

Of course, if the manifest is not available at the nominated address, applications that use the manifest will not be able to process the instance correctly – if at all. So that’s an obvious risk that needs to be managed.

Readers familiar with JSON-LD will have seen the obvious similarities with JSON-LD’s @context. We’re not actually using ‘@context‘, though, because while what we are doing is structurally similar, we’re using it for a different purpose.

You could use the same technique with regard to parameters on an operation. Take, for example, this input to the $expand operation:

{
  "ResourceType" : "Parameters",
  "parameter" : [
    {
    "name" : "coding",
    "valueCodeableConcept" : {
      "coding" : {
        "system" : "http://loinc.org",
          "code" : "1963-8",
      "display" : "test"
      }
    }
  },
  {
    "name" : "valueSet",
    "resource": {
      "resourceType" : "ValueSet",
    [etc]
    }
  }
  ]
}

With an in-line manifest, this might look like this:

{
  "ResourceType" : "Parameters",
  "@manifest" : {
    "code" : {
      "parameter" : " http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code#coding",
      "type" : "Coding",
      "list" : false
    }
    "vs" : {
      "parameter" : " http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code#valueSet",
      "type" : "Resource",
      "list" : false
    }
  }
  "code" : {
    "coding" : {
      "system" : "http://loinc.org",
        "code" : "1963-8",
    "display" : "test"
    }
  },
  "vs" : {
      "resourceType" : "ValueSet",
    [etc]
    }
  }
}

Or, we could refer to a manifest defined in the specification itself:

{
  "ResourceType" : "Parameters",
  "@manifest" : "http://hl7.org/fhir/r4/validation.manifest.json",
  "code" : {
    "coding" : {
      "system" : "http://loinc.org",
        "code" : "1963-8",
    "display" : "test"
    }
  },
  "vs" : {
      "resourceType" : "ValueSet",
    [etc]
    }
  }
}

Several Questions I’ve had from the few people who’ve looked at this idea already:

  • Why not do this in XML too? Well, we could. But I don’t think it has value, because people using FHIR in tightly bound client/server type environments (where the @manifest approach is nost beneficical) are almost exclusively using JSON. So the cost/benefit is not there for XML. Also, in XML, schema validation matters more.
  • What about JSON schema then? It’s possible to generate a JSON schema for this, if the generation tooling knows what the manifest is going to say. No such tooling exists right now, but it could be written. Or else someone could easily write a convert to convert from the @manifest form to the existing normal form.
  • What about the reference implementations? They’d be enhanced to support this transparently on read, and there would be some kind of configuration to allow the user to control the manifest, and then it would write according to the manifest.
  • Would this be instead of the existing approach? I propose that it’s an additional approach: the existing extension and parameter format is still valid, and can still be used, but implementations can use the @manifest if they want – and can mix and match. e.g. some extensions represented using @manifest, and others (not known in the manifest) represented the existing way

For follow up / discussion, see fhir.chat.org, though comments here are also welcome.