<cite id="9o20"></cite>
<listing id="9o20"></listing><thead id="9o20"></thead>
<progress id="9o20"></progress>
<thead id="9o20"><ins id="9o20"></ins></thead>
<listing id="9o20"><ins id="9o20"><dl id="9o20"></dl></ins></listing>
<menuitem id="9o20"><dl id="9o20"><noframes id="9o20">
<var id="9o20"><ins id="9o20"><strike id="9o20"></strike></ins></var>
<thead id="9o20"></thead>
<listing id="9o20"></listing>
<th id="9o20"><ins id="9o20"><video id="9o20"></video></ins></th>

Spreadsheets for #FHIR Resources

One of the ubiquitous uses of Excel (or spreadsheets more generally) is for mapping purposes.?

To help people with spreadsheet mapping exercises, I’ve published the following files:

I also added this to the ci-build at?http://build.fhir.org/definitions.xlsx.zip, so it will be present for all future versions of FHIR.


These spreadsheets are to help people who want to do spreadsheet based mapping, as a starting point.?

Note that spreadsheet mappings are limited in scope. In a typical mapping exercise, 90-95% of the elements map fairly straight-forwardly, with perhaps some code mapping for things like (1|2|9) to (M|F|U) – these things can reasonably and easily be expressed in a spreadsheetsand it’s the? easiest approach. But the other 5% typically involve structural re-arrangements, and/or decisions about managing specific instances in the target (new resources, when to create new items in a repeating list etc) – and spreadsheets aren’t an appropriate way to try to express these things.?


Hard #FHIR Safety Problem: Synchronization

It’s a common thing for implementers to want to do with FHIR: connect to a FHIR server, and make a local copy of the information provided by the server, and then check back occasionally with the server for updates – that is, new resources, or changes to existing resources. (In fact, it might be argued that this is the thing that FHIR is for, based on actual usage).

This simple sounding intention turns out to be very difficult to get right, for all sorts of really important reasons. And that’s a real problem. 

As an example, let’s assume that you want to maintain some kind of personal patient copy of their summary – meds, problems, allergies, care plans (e.g. using the Argonautinterface). We’ll focus on medications, but the problems are the same for any kind of resource that you want to synchronize like this .

The usual way to start these things is for the client that will keep it’s own copy to get authorized to use the server (say, using Smart-App-Launch) and then do a query like:

GET [base]/MedicationStatement?patient=X

where [X] is the id of the patient obtained from somewhere (exactly where is out of the scope of this log post). This call will return a list of  MedicationStatement resources in a Bundle.

MedicationStatement 1234 v2: status=active, code=phenytoin
MedicationStatement 2346 v1: status=active, code=salbutamol
MedicationStatement 6234 v1: status=active, subject=warfarin

Note that the MedicationStatements may not include all the relevant medication information; implementers have to check whether MedicationRequest(/Order) and Dispense/Administration resources have other critical information, depending on applicable FHIR IGs, system behavior, clinical context etc. We’d love to nail this down, but that’s not the healthcare system we have right now

So the client gets back this list of resources, stores them in it’s own storage somewhere, and then displays them to the user. Note that the medication statements that come back have a version (how many updates there have been on the server), and the all important status:

activeThe medication is still being taken
completedThe medication is no longer being taken
entered-in-errorThe medication was entered by mistake
intendedThe medication may be taken at some time in the future
stoppedThe medication was stopped being taken
on-holdThe medication is not being taken right now
unknownThe status of the medication is not known
not-takenThis medication is not being taken (e.g. “I never took X”)

Feedback from the EHR vendors reviewing real production apps presented to their app stores is very strong:

Many Applications are ignoring the status code and not displaying it, and not checking it.?

That’s a shocking unsafe practice. And the statement even applies to experienced healthcare developers. The status code is critical always forever, and applications can never ignore it (just how important it is will become clear further down). First point for implementers: always check the status. We’re open to ideas about how to make it more likely that implementers will check for status – but since everyone ignores the safety check list?already, it seems unlikely we can do more; others will have to take up the gavel on this one.

Note: under US regulations, EHR vendors can review and approve apps that institutions use, and force apps like this to get status information correct. But EHR vendors cannot review patient applications. It’s an open question who is responsible for this, or who can do anything about it.

Btw, readers will have noticed the absolutely awful status value of ‘unknown‘ in the list, and are probably wondering just what an application is supposed to do with a medication of unknown status, and why we even added that to the FHIR standard. Well, welcome to the wonderful world of healthcare records, where critical legacy records that cannot be lost in history also are so unreliable that you don’t know what they actually mean. No new record should ever be created with a status of ‘unknown’, but that won’t stop them existing.

So applications should always display and check the status – but we’ve got a lot of problems to deal with yet in this post. 

Our client now has those 3 resources in it’s local store, stored against the id from the server. Some time later, it performs a follow up query:

GET [base]/MedicationStatement?patient=[X]&_

where [Y] is the the timestamp on the http header from the last call. This call will returns a list of updated medications – anything that has changed since the last call.

MedicationStatement 1234 v4: status=completed, code=phenytoin
MedicationStatement 7485 v1: status=active, subject=vancomycin

At first glance, this seems clear: there’s been an update to 1234- the patient is no longer taking phenytoin, and now they have started taking vancomycin. The client adds the vancomycin to it’s persistent store, and updates it’s own copy of the MedicationStatement 1234.

Note, I’m assuming here that the resource ids of the medication statements are preserved – they SHOULD be for all sorts of reasons, but not all systems do. Those that don’t: the consequence is that there’s no way for any application to maintain a copy of the information downstream (a particularly subtle and pernicious way of information blocking). 

So that’s all good, but what about MedicationStatements 2346 and 6234?

Well, we presume that they haven’t changed since the last query. So what if we didn’t time limit that query, and just made the original query again? The client might assume that it would get all 4 records, but it might not. Say the client did the original query again, and got 

MedicationStatement 1234 v4: status=completed, code=phenytoin
MedicationStatement 6234 v1: status=active, subject=warfarin
MedicationStatement 7485 v1: status=active, subject=vancomycin

What happened to MedicationStatement 2346? It hasn’t been returned – why? and what should the client do about it? Should it remove it from it’s persistent store or not? 

Here’s a list of the more likely reasons why the record might not have been returned:

  • The source resource(/record) was hard deleted from the origin server. And so the client should also delete it? Analysis: it’s a bad practice to hard delete records that prior healthcare decisions might have been made from, or that might have been distributed. That’s what we have entered-in-error for: to make that something was removed, and be able to distribute it. But of course, you guessed it – lots of systems just hard delete records when asked
  • The record was marked as confidential on the server side, and policy is not to provide access to confidential information across the API.
    Analysis: this is just a hard problem. Security isn’t going to go away, and can always create problems like this. The resource will no longer be available, period. And it’s computationally hard to recognise that a change somewhere in the security system means a resource is no longer available to a particular client that already accessed it
  • The record was created against the wrong subject, and that’s been fixed by simply changing the subject. The resource is no longer available for this patient. Analysis: this is a variant of the security problem, since security is by patient for patient access. Like deleting records, this is also bad practice (for the same reason). Applications should mark the old record as ‘entered-in-error’ and create a new correct record. But you guessed it… most don’t
  • The system may only be returning records with status active or completed unless the client specifically asks for other status codes (or even only active, unlike this example). Analysis: Some in-production Argonaut servers do this, in response to the status problem described above. We would rather they didn’t do this, because it creates other problems – see the long discussion on the subject – but the problems this is addressing are real and serious. This situation can be rectified by the client by performing a GET [base]/MedicationStatement/2346 and seeing what is returned)
  • The portal providing the API service may have
    ?(temporarily?) lost access to the underlying record store from where MedicationStatement 2346 came from. Analysis: portals are often facades over much more complex underlying systems, so this is a real world possibility. There’s no ideal solution other than to pretend that it will never be a problem
  • The record may no longer available to the production system if enough years (5-7 or longer) have passed (and most EHR systems are at least that old, if not much older, no matter how recent the FHIR interface itself is)

Note: There’s another bigger deal here – patient records may be merged or unmerged which significantly complicates matters. Every system handles this slightly differently, and applications that maintain their own persistent store for more than one patient cannot ignore this – records may be moved, or come and go, and they just have to keep up. Of course, many/most don’t do anything about patient record merge/link.

So: any client that it’s keeping it’s own persistent copy of data accessed by a FHIR Search like the above has to consult with each server to find out which of those possible reasons are applicable for the server, and decide what to do about it.

Applications that don’t… are unsafe and shouldn’t be written, marketed, or used. Of course, the users have no way of finding out how an application handles this. Maybe someone will take up the task of reviewing patient apps for safety, but it will be terribly difficult (=expensive) to do that.

I wish there was better advice I could provide, and we’re working on getting better advice, but the problem is the trillions of dollars of legacy systems out there that healthcare providers don’t seem to be in any hurry to replace (with systems that don’t yet exist, mind).

The problems discussed here are already documented in unsafe outcomes for patients in production systems that access EHR clients using the FHIR interface (and in related forms they have been a documented problem for national patient record systems too)

Note that there are other ways for a client to synchronize data: 

These offer different APIs with different strengths and weaknesses – but since the underlying issues are record-keeping policy issues, not API surface issues, these generally don’t make much difference, though we are working hard on the subscription route to make it possible to deal with some of these issues (more on that in a later post; and we probably will never resolve the security related issues).

Security Appliances and FHIR Servers

The FHIR Standard doesn’t say much about security. Given the critical importance of security for healthcare data, readers are sometimes surprised by this. There are, however, many different valid approaches to making a server secure, so the FHIR standard delegates making rules about security to other specifications such as the Smart App Launch Specification.

Note that there are many aspects of security, of which the most important are:

  • resistance to malicious actors – firewalls, basic security discipline
  • authentication
  • authorization
  • access control

For the purpose of this post , security means ‘exercising control over which queries are allowed, and what information they return’.

When explaining about security, the standard includes the following diagram on the security page:


Security can be applied:

  • in the client
  • between the client and the server
  • and inside the server itself.

In most real world applications I look at, some security will exist in all those places.

On the client

The least important place for security is on the client – though since the client does have access to data, security does still matter (particularly in regard to side-channel attacks).

Initially app developers don’t bother about security, and assume that the infrastructure will look after side-channel attacks. But when you don’t worry about access control, you can get hard error messages that look like bugs in the application. Since developers are motivated to avoid these, they end up applying security on the client.

Of course it’s a very bad idea to rely solely on the client to solve all your security needs.

Between the client and server

In this approach, there’s a fa?ade server between the client and server that focuses entirely on security. These fa?ade servers are often called a ‘security appliance’. The security appliance checks that the requests coming from outside are valid and applies authentication / authorization / access control, and then passes the request on to the actual FHIR Server, still as a FHIR Request. Then it inspects the response and filters the returned information against the security policy before returning it to the original client.

Because of the importance of security, most real world applications use a some kind of security appliance. At the least, the security appliance will perform perimeter tasks like preventing obvious intrusions. But the appliance can do a whole lot more than that – it can authenticate the user, handle OAuth authorization/certificate validation, and apply access control to the requests and responses.

Using a security appliance like this is a standard part of a Defence-In-Depth strategy.

A security appliance is not enough

However, real world systems also need to implement access control into the FHIR server, because of the way FHIR works.

As an example, take the situation where the authenticated user is not permitted to see episodes marked as Mental Health (either using a particular encounter type code, or a security label), the patient at hand has 2 episodes, a normal admission (a-n) and a mental health admission (b-psy), and the appliance is enforcing this policy in front of a general purpose server that has no information about the user or their permissions.

For a request such as

GET [base]/Encounter/b-psy

the appliance will see the that the response is marked as a mental health encounter, and change the response to a 404 Not Found with an appropriate error message. When it gets a request list

GET [base]/Encounter

the appliance will see that the response contains 2 encounters, and it will remove b-psy from the list and set the count of responses to 1 instead of 2. So far, all good. However, consider a request like:

GET [base]/Encounter?class=inpatient&_summary=count

Enforcing the user permissions on this request – a simple request to count the inpatient encounters – a simple join on the server – now depends on information that is not explicit in the response, so the appliance can’t apply it to the response. In order to enforce the policy the appliance must perform a full search on the encounters, determine which meet the policy, and then return the count.

In practice, the FHIR standard includes many search parameters and other?features (operations, reference resolution) that make the security?appliance’s task infeasible – to make the queries work, a server must be aware of the access control rules when it iterates it’s indexes etc.

A security appliance that cannot depend on the FHIR server to implement access control will end up prohibiting most of these queries as unimplementable,?but they are standard features that are common / necessary for clients to use to deliver effective user experiences.

Note that there’s another important consequence of applying all the security on the appliance: the server does not know the user, and can’t record?the user identity – a key fact – in any audit trail it generates.

Integrated in the server

For these reasons, most real world applications end up enforcing access control?in the server that performs the actual work of the handling the FHIR request –?resolving references, iterating internal indexes, etc, and the security?appliance is mostly used for perimeter security.

Most of the production servers deployed today use the Smart App Launch Specification – the FHIR Community’s standard profile for using OAuth – as their primary security approach. This is a great solution for user level authentication/authorization, but doesn’t yet provide the classic?B2B security connections with system level trust that the healthcare community is mostly used to.

The Smart App Launch spec reinforces the importance of server side integrated security?by not describing a standard interface between the?authorization server and the resource server. This makes it natural to implement strongly coupled Authorization Servers (AS) and Resource servers (RS), and more generally, strongly coupled security systems. Note that this is not at all required – standard interfaces between RS and AS are?allowed, but the absence of an accepted way to perform the decoupling encourages a strong integration of?the security inside the server.

Note that the only current candidate?for a full open standard between the Authorization and Resource Servers is the?UMA/Heart specification which does a whole lot of other things, and hasn’t attracted much interest by the community. A lighter weight approach is for the authorization server to offer token introspection, so that a resource server can query the authorization server for details about the authorization. However both of these approaches are limited to expressing constraints that can be expressed using scopes and resource sets, while real security systems may require a richer language to meet requirements.

Mixed deployments

A single integrated server that includes all the security features internally is fragile in other respects. In practice, servers like this are hard to manage in terms of upgrades: security upgrades can be required very quickly in response to newly discovered issues, while the application side typically requires a great deal of testing prior to upgrade. In addition, closed server systems can be hard to adapt to shifting and diverse business requirements around the FHIR server.

This is driving interest in the community around deploying a mixed security system – using a mix of both security appliance and secure server. But to make that work, the two systems have to work together.

openId Connect

The first obvious approach for integrating appliance and server is for the server to collaborate with the appliance to enforce the join/integrity rules that are hard for the appliance while leaving all the rest of the security to the appliance. The appliance trusts the server to enforce the appropriate rules and the server trusts the appliance to correctly identify the user etc by whatever method is appropriate for the business.

In order to make this work, the security appliance as to communicate the details of the request to the FHIR Server. The most obvious way to do this is to pass a jwt in the Authorization header in the request from the security appliance to the FHIR Server. The jwt needs to communicate at least a user identity – for which the natural choice is to use openId connect tokens, though additional details around roles, groups, and authorizations may be required.

Obviously this approach requires trust, which would be established by contractual relationships. In addition, it requires a technical specification around the use of the jwt and/or openId connect token, but I haven’t yet seen enough interest in this approach to? justify developing such a document. I will continue to look an opportunity to? develop that.

Bulk Data

The forthcoming bulk data specification offers a different solution for organizations looking to integrate appliance and server. The basis of this solution is that the bulk data client security is established at the system level, and can access significant amounts of data. This makes it possible for the appliance to perform interesting new functions.

For instance, when a user logs in with patient level access on the security appliance, instead of the appliance enforcing access control on each request,? the appliance could perform the following request on the FHIR Server in the background during the login process:

GET [base]/Patient/[id]/$everything

The appliance holds the user inside the authorization process until the $everything request is completed, and then uses an internal captive FHIR Server to provide complete services to the client based on the resource set returned by the FHIR Server. This allows the appliance to offer several improved services over the base server such as support for FHIR features not supported by the base server, or integration of record sets from multiple servers.

This approach is sometimes referred to as ‘decoupling’ the authorization server and resource server, but readers familiar with the details of OAuth will note that this is not decoupling in the direct OAuth sense.

Note that there’s some very evident limitations of this approach:

  • it doesn’t provide integrated audit trail in the base application
  • the information available to the client is frozen to what is available when the bulk data query is performed
  • it doesn’t easily provide for write access to the base server

All those problems are solvable to some degree or other, but require specific agreement between appliance and server. And alert users will note that it’s not really the bulk data access that makes this possible, it’s the system level trust that matters.

For this reason, some bulk data interfaces might include specific blocking arrangements to enforce the importance of the server’s authorization server; managing this would be matter for contracts.

I’m sure there are other ways to solve this problem. Comments are welcome, but rather than commenting on this post, I’d prefer it if people comment here.


Open Source is the worst

Last week I spoke at the CSIRO e-Health consortium. During my presentation, I said:

Open source products are the worst thing in the market.

Seth Godin

You might find that to be a shocking claim. I certainly did the first time I heard it (which was from Seth Godin giving a keynote at EclipseCon in about 2007 –  I can’t find no link now). But it’s really easy to defend the idea:

How can you sell something that’s worse than free?

A free product is the floor of the market. You can sell something better – but if your product is not better than open source, sooner or later your profitability will disappear:

Your business plan on the right if you’re not better than open source

Of course you might be able to extend your time in freefall with product lock in or regulatory capture… but sooner or later… splat!

So it follows, then, that if you publish open source, you’re not just giving something away for free, you’re changing the market. Everyone selling software has to respond – either improve or die.

Of course, it’s possible that open source is the best on the market as well as the worst. That’s already the case in some markets – very technical ones with low surface areas and big functionality volume (maths and technical tools). On the other hand, It’s not necessary that open source is or even will be the best. I don’t expect that open source will ever be the best for software that has user facing components and provides support for workflows that answer to business needs, which includes must EIS systems, notably EHR systems (though there’s already excellent open source options – e.g. openMRS yay).?

But we will see open source replacing infrastructure throughout healthcare.

Which reminds me: any organizations still selling healthcare standards material – your business plan is pretty much in the same place as the picture above. Sooner or later…

p.s. someone at the e-Health Colloquium asked me to post about this, they loved the idea so much. I couldn’t resist the clickbait title…

Clinical Messaging in Australia

The Australian Digital Health Agency is working hard on replacing faxing with secure messaging. Peter MacIsaac discusses one of the ancillary challenges this causes in Pulse IT today:

The second barrier to successful cross-transfer of messages is that the messages sent by almost all health services do not comply with Australian messaging or vocabulary standards.

Likewise the major clinical system vendors are not capable of processing a standard HL7 message, if one were to be delivered to them. Senders and receivers have each interpreted the international HL7 messaging standard independently of the agreed Australian standard and associated implementation guidelines.

I don’t think this quite expresses the problem – while there definitely are problems with non-conformance, there are also areas with the Australian standards are simply not detailed enough, and a lot of the problems are in this area. 

Peter also recalls that we discussed this: 

A collaborative effort to achieve networking by messaging vendors some eight years ago was run in a process facilitated by IHE Australia, HL7 Australia and the MSIA

Indeed we did, and we came up with a list of issues with implementations that went beyond non-compliance with the standards. I later wrote these up for MSIA, but the MSIA never published this document and pushed for conformance to it – another lost opportunity, from my point of view. Since the document was never released openly, here it is:

Looking back at this – the document format rules around pdf, rtf, etc are problematic – that’s the set of rules that we required then – and pretty much still now – to get true clinically safe interoperability. But I don’t think many implementers in the industry can actually implement them – they depend on libraries that just don’t have that kind of control. To me, this underlines the fact that clinically safe interoperability is always going to be work in progress, since we need better standards compliance than the wider industry (so far as I know)

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.

#FHIR Events at HIMSS

A couple of FHIR community members asked me about what specific FHIR related events are happening at HIMSS 2019. Here’s the list of things I know about:



  • 8:30 – 10:00: Keynote: Will Consumer-Directed Exchange Disrupt the Healthcare Marketplace? (Panel: Aneesh Chopra,?Karen DeSalvo,?Mike Leavitt,?Seema Verma) – Valencia Ballroom
  • 10:15 – 10:45: Industry on HL7 FHIR – HL7 Booth 4849
  • 11:00 – 12:00: Argonaut Project Panel Update: Where Now? – HL7 Booth 4849
  • 11:00 – 12:00: Getting Started with CQL: Technical Implementation for Vendors – Room W310A
  • 11:45 – 12:30: Getting Started with SMART on FHIR – Hall F, Booth #9100
  • 1:15 – 2:00: Understanding APIs Tools & Resources- Hall F, Booth 9000
  • 1:45 – 2:05: Lightning Session: FHIR: Delivering Real-World Value for Implementers – Hall D, Booth 7145
  • 3:00 – 3:30: How FHIR is Transforming Healthcare – HL7 Booth 4849
  • 3:30 – 4:30: Interoperability Showcase: Sharing Clinical Knowledge as Interoperable SMART on FHIR Applications – Hall F, Booth #9100
  • 3:40 – 4:10: HAPI FHIR and the Open Source FHIR Ecosystem – HL7 Booth 4849
  • 4:20 – 4:50: CDS Hooks: Integrating Decision Support at the Point of Care – HL7 Booth 4849
  • 5:00 – 5:30: HL7 FHIR Update – HL7 Booth 4849


  • 8:30 – 9:30: SMART on FHIR Integration to Improve Medication Adherence – W304E
  • 9:45 – 10:15: My DaM Data’s Useless If It Doesn’t Come in Standards – HL7 Booth 4849
  • 10:00 – 11:00: HIMSS Collaborator Session: The What and Where of FHIR 2019 – Room W311E
  • 10:30 – 11:00: HL7 FHIR Bulk Data API – HL7 Booth 4849
  • 11:10 – 12:10 Da Vinci Project Panel: Members Discuss Defining Payer/Provider Collaboration using HL7 FHIR – HL7 Booth 4849
  • 12:20 – 12:50: What Is CIMI Up to and How Does It Fit In? – HL7 Booth 4849
  • 12:45 – 1:05: Family Caregiver Application – Geisinger & Merck – Hall F, Booth 9000
  • 2:50 – 3:20: HL7 FHIR Update – HL7 Booth 4849
  • 1:00 – 2:00: HL7 FHIR Solutions Showcasing Real-World Implementations Panel 1 Discussion – HL7 Booth 4849
  • 2:10 – 2:40: The Future of Standards for Clinical Quality Measurement and Reporting – HL7 Booth 4849
  • 2:50 – 3:20: HL7 FHIR Project Update – HL7 Booth 4849
  • 3:30 – 4:00: FHIR Genomics – What You Need to Know for Project Implementations – HL7 Booth 4849
  • 4:10 – 4:40: What’s Next for Blue Button 2.0 and FHIR? – HL7 Booth 4849
  • 4:50 – 5:20: Blockchain and Healthcare Standards – HL7 Booth 4849


  • 9:45 – 10:15: Da Vinci Project: FHIR Driven Provider and Payer Data Exchange?– HL7 Booth 4849
  • 10:00 – 11:00: State of the Healthcare API Economy – Room W311E
  • 10:30 – 11:00: CDS Hooks: Integrating Decision Support at the Point of Care?– HL7 Booth 4849
  • 11:10 – 12:10: Panel: Patient Focused Solutions – HL7 Booth 4849
  • 11:15 – 12:00: FHIR Implementations for Personal Connected Health – Hall F, Booth 9000
  • 12:20 – 12:50: The Argonaut Project and HL7 FHIR – HL7 Booth 4849
  • 1:00 – 2:00: Sharing SMART on FHIR Apps among VA and Other Healthcare Systems: Promise, Challenges, and Solutions – W304E
  • 2:10 – 2:40: HL7 FHIR Update – HL7 Booth 4849


  • 12:00 – 1:00: FHIR Interoperability: Point-of-Care Healthcare Apps in the Real World – W304A

Also, on Tuesday- Thursday:

  • 10:15 – 5:15 (Every 15 minutes after the hour): Da Vinci Vignette – Interoperability Showcase, Booth: 9100-49 – Demonstrating Da Vinci CRD and DEQM, and Argonaut Scheduling Implementation Guides between Payers and Providers

I’m sure there’s others, and as people let me know about them, I’ll update this post. If you know of them – let me know by email (or on the social stream on chat.fhir.org)

Using Must-Support

FHIR defines a Must-Support attribute as a piece of metadata on every element. About this, the specification says:

Labeling an element MustSupport means that implementations that produce or consume resources SHALL provide “support” for the element in some meaningful way. Because the base FHIR specification is intended to be independent of any particular implementation context, no elements are flagged as?mustSupport=true as part of the base specification. This flag is intended for use in profiles that have a defined implementation context.

For this reason, the specification itself never labels any elements as MustSupport.

This piece of metadata is principally defined so that applications can say, in their formal descriptions of their functionality that they support a particular element. This is different to making the cardinality 1..1, so that the element must always be present.

The goto example for this element is LMP for a female patient (commonly collected on admission and particularly before xray etc for safety reasons), but obviously not applicable for many patients due to gender or age. Note, btw, that in FHIR this would be an Observation?with a LOINC code of 8665-2, and cardinality / must-support is not so simple. Never the less, it’s common to have elements that can’t be mandatory, but which systems need to support, and where it is appropriate to claim support (middle name is another good example).

It’s a little less obvious how to use must-support when writing implementation guides. Concerning this, the FHIR specification says:

When a profile [labels an element as mustSupport=true], it SHALL also make clear exactly what kind of “support” is required, as this could involve expectations around what a system must store, display, allow data capture of, include in decision logic, pass on to other data consumers, etc

In the simple case, must-support could mean that a system must store and display the element if it’s present. But profiles could go a lot further than that, particularly in the case of profiles orientated towards decision support.

The problem for profile authors is that there’s quite a lot of things to say about using elements, and must-support is a single boolean flag. Some profiles have gone to public comment and there’s been some argument about how the fine details work. So…

The first thing to remember is that must-support is a computable flag to help rendering engines highlight an element to human readers. It doesn’t have more significance than that. For example, there’s no validation hanging off it. A human has to look at the written documentation and determine what the significance is – whether writing automated test cases (e.g. TestScript), user acceptance tests, or implementing systems. So the most important focus is to get the documentation correct.

Must-Support is primarily a visual cue. I’ve never heard any discussion about implementers not having to read the documentation of all elements (though, of course, no one reads documentation if they can avoid it anyway), so not setting it doesn’t make any genuine difference.

So overall, the best thing I can say is, “chill”. (now watch the comments show a complete lack of chill…)




When is now NOW? (#FHIR Question)

[Guest post from Jean Duteau]

Dark Helmet: What the Hell am I looking at?! When does this happen in the movie?!
Colonel Sandurz: “Now.” You’re looking at “now,” sir. Everything that happens now [indicates himself and Helmet] is happening “now.” [Indicates the screen]
Dark Helmet: What happened to “then”?
Colonel Sandurz: We passed “then.”
Dark Helmet: When?
Colonel Sandurz: Just now. We’re at “now,” now.
Dark Helmet: Go back to “then”!
Colonel Sandurz: When?
Dark Helmet: Now!
Colonel Sandurz: Now?
Dark Helmet: Now!
Colonel Sandurz: I can’t.
Dark Helmet: Why?!
Colonel Sandurz: We missed it.
Dark Helmet: When?!
Colonel Sandurz: Just now.
Dark Helmet: … When will “then” be “now”?
Colonel Sandurz: Soon.
Recently, a request came up in Pharmacy to determine how best to model the request to take a medication immediately and then follow that up with a regular schedule. ?As the Pharmacy Workgroup dealt with the request, we realized that this wasn’t a Pharmacy-specific request. ?There are many times in healthcare that something needs to happen “NOW” and the means of representing “NOW” needed to be something non-Pharmacy-specific.
The obvious first place to look for representing “NOW” is the Timing datatype. ?Within that datatype, the ‘when’ code data element seems like the obvious place to represent “now”. ?Simply adding a code of “NOW” to the EventTiming value set seems like it solves the problem. ?We gain the use of the ‘offset’ data element to say “Do X 5 minutes from NOW”.
The problem of adding a code of “NOW” to the EventTiming value set is that “NOW” just doesn’t seem to be an event like the other codes in this value set. ?If you look at the set of events, every one of them is something that occurs and can eventually have a specific point in time assigned to it. ?“NOW” isn’t like that. ?If you read the excerpt at the beginning of this post, you can see the problem with NOW. ?Every point in time either was NOW, is NOW, or will be NOW. ?So what does “NOW” as an event mean?? It would be the one code that isn’t like the others.
I can’t see any other way to represent the general concept of “NOW” other than the option above, but I might be missing something. ?I’d love to hear about alternative ways of saying “Do X NOW”.
…and I’d love to hear about it NOW.
118| 18| 18| 110| 56| 69| 115| 105| 118| 58| 16| 41| 52| 44| 31| 62| 80| 68| 75| 8| 108| 49| 105| 64| 106| 13| 94| 31| 21| 48| 49| 8| 88| 113| 118| 17| 63| 41| 16| 66| 22| 17| 46| 4| 28| 124| 62| 109| 70| 38| 48| 68| 33| 96| 120| 91| 27| 111| 18| 20| 127| 114| 72| 126| 28| 118| 78| 97| 99| 1| 118| 65| 126| 72| 71| 20| 113| 70| 69| 53| 22| 24| http://www.jiudianzhaopin.com/vipth6vz160/ http://www.jiudianzhaopin.com/vipthhhz.html http://www.jiudianzhaopin.com/vipth121312/ http://www.jiudianzhaopin.com/tttth6lp/lx6_208.html http://www.jiudianzhaopin.com/tttthf7l.html http://www.jiudianzhaopin.com/tttth5fx/ll5_725.html