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….

Should you use #FHIR resources as your storage format?

In discussions with implementers, one question that has come up quite a lot recently is whether you should store FHIR resources natively in your database or not.

In principle, FHIR resources (like all HL7 specifications) are designed for exchange between systems, rather than as a database storage format. That doesn’t mean that we won’t consider utility or design requests intended to meet storage use cases, just that we will always prioritise design priorities around robust exchange.  One practical consequence of this is that FHIR resources are highly denormalised, so that granular exchanges are fairly stand alone.

To illustrate this, consider using an RxNorm code as a medication code. In a prescription resource (MedicationRequest), that will look like this:

<MedicationRequest xmlns="">
     <system value=""/>
     <value value=""/>

If we were prioritizing storage efficiency, we would normalise this so that the code was just some primary key reference:

<MedicationRequest xmlns="">
  <code key="123431232"/>

..well, we probably would do that. Whether to normalise or not is an engineering design question that has multiple different considerations, and very often product designers change their decision about this for engineering reasons with no associated change in functionality or requirements.

When designing exchange formats, on the other hand, you almost always end up choosing robustness and stability over efficiency. Using a key reference like the second example would require all the participants in an exchange to synchronize the key… often not possible, and rarely stable. Not always, but most of the time, and we choose reference points after considerable discussion about reliability. Performance considerations come a distant second.

Engineering Considerations

So you might immediately assume that it would always be a mistake to store resources natively, but that’s not always the case.

Many implementers assume that a general purpose REST based implementation stack will always be less efficient, reliable and manageable than a purpose built application stack… but there’s some pretty awesome stacks for handling generic resources out there, with deep support for application development – code generation, UI binding, management reporting… so it’s no longer a given that you can do a better engineering job than just storing the resources directly.

I’ve seen implementers storing resources natively in:

  • classic SQL servers with JSON support
  • NoSQL servers like Mongodb / Couch etc (or Hadoop)
  • Google’s Big Query
  • Some RDF based store using the RDF in the turtle format

So if you can consider something like this for your storage, you can consider storing resources natively. If you can’t… then you won’t be asking the question.

But just because you can doesn’t mean you should.


The most important determinate of whether you should store resources natively is about your requirements.

If your information requirements are nailed down: well understood, clearly expressed, and not subject to uncontrolled change – then you can easily design a data storage schema that is completely fit for purpose and magically efficient compared to storing FHIR resources. Classic Enterprise Information Systems tend to behave like this.

If, on the other hand, your information requirements are not at all nailed down, and you have to deal with whatever comes, and you only find out what’s coming on an ongoing basis – then FHIR resources are actually a very sound way to store your data – the extensibility approach makes FHIR a particularly robust choice. In fact, FHIR might already be your best choice outright. Clinical Data Repositories tend to behave like this.

The really interesting thing, though, is that every information system I’ve ever worked with is somewhere between these 2 extremes. And so the choice of whether to store FHIR resources natively or not is not straight forward.

In fact, I’m starting to see a lot of system taking a hybrid approach – storing FHIR resources natively, and storing a well controlled subset of information in some expressly designed scheme. The balance between these is driven by the stability of information requirements for different parts of the system.

Managing Joins

Going back to the question about normalisation and references – most systems that store resources natively find the way references work in FHIR to be a pain point; references can be absolute or relative URLs, they can be version specific or not, they may or many not follow FHIR’s well defined RESTful interface pattern, and they may or may not resolve in the local system (and the kind of systems where you’re storing resources directly are the kind of systems where you can’t always enforce referential integrity). All this flexibility is required in various exchange scenarios, but it’s a real tax if you’re filling a coherent data store with resources.

For that reason, I recommend that if you’re storing resources natively, you consider extending the storage format of your choice with a resolved link in addition to the existing reference/identifier in the Reference data type. The RDF format does this explicitly for references and codings (fhir:reference and fhir:concept) and Google’s protobuf implementation does something similar. (note that if you’re storing JSON, then you’ll have to remove the extension for exchange, unless you use a native FHIR extension – which isn’t the most efficient way to do it)

Australian Digital Health Strategy Question

On the subject of replatforming the MyHR, the Australian Digital Health Strategy has this to say:

Every healthcare provider will have the ability to communicate with other professionals and their patients via secure digital channels by 2022. Patients will also be able to communicate with their healthcare providers using these digital channels. This will end dependence on paper-based correspondence and the fax machine or post.

I’m doing some consulting to the Agency around Secure messaging, and I’m thinking about this. I haven’t heard any discussion about this anywhere – what would it look like?

  • Would patients have to communicate through a MyHR portal? Or could they choose to use their normal Email? Or should there stringent security requirements?
  • Would doctors ask patient’s for the email id? or would the register it via their MyHR?
  • Would patients get a Doctor’s email from their website? Or would they look it up in the national healthcare directory?
  • What kinds of workflows would you build on top of that? Care plans? Scheduling?

Obviously this is all just idle speculation. Surely there’ll be formal consultation and design and so forth later. But maybe we can toss around some ideas now…


Re-platforming the MyHR

A couple of months ago I made a post proposing that the MyHR could be reworked to use the Argonaut interface. This change could open up the MyHR infrastructure so that providers and vendors could collaborate to build innovative local solutions without being bound to national political concerns about what is possible or not.

That caused quite a bit of discussion and media interest (e.g. in Pulse IT). This week I met with Tim Kelsey (CEO, Australian Digital Health Agency) as part of the follow up, and he pointed out an as-yet under-appreciated aspect of the Agency’s work plan for next year.

Quoting from the Budget Measure:

This measure allows the Australian Digital Health Agency to implement plans that will increase efficiency and sustainability and reduce the ongoing operational costs of the system in the longer term through the transition of Department of Human Services’ support functions to the Agency, the re-tender of the national infrastructure operator and delivery of a new, more flexible platform.

I’ve heard lots of discussion about efficiency and sustainability, but it seems that the commentariat haven’t picked up on the significance of ‘a new, more flexible platform’.

The Agency will be conducting community consultation around this subject in the first half of next year. In advance of that, the community of interest in digital health in Australia – which is a pretty wide set of people and institutions – should start thinking about these questions:

  • How should the Agency conduct the consultation to ensure that it gets good, honest open input from the community, without political noise overwhelming the process?
  • What kinds of improvements could be made to the MyHR to make it a more flexible platform that are both politically and financially realistic? (and that align with the digital health strategy, since that’s that the official national strategy)
  • How should the technical specifications that underpin a more flexible system be managed (e.g. what’s the standards process for digital health in Australia)?

Tim will be commenting in public about this subject too – I’ll link to his comment from here once he makes it (maybe later in January)

Note: I have a contract with the Agency, to provide advice around strategic direction with regard to the Secure Messaging project, which overlaps a little with regard to this subject. But in this case, I’m not speaking on behalf of the agency in any official sense.

#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.


(Chinese Translation)

Question: LOINC code for smoking start date


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

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


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

You can propose new LOINC codes here:

Sharing Information with a Patient Case Manager

Sharing Information with a Patient Case Manager

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

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

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


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

Interaction pattern

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

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

This pattern describes:

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


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

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

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


#1 Prompting the clinician to register the patient

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

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


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

#2 Registering a patient with the case manager service

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

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


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

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

#3 Ongoing sharing of the clinical record

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

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

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

Provider Portal:

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

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

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

Patient Portal:

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

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

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


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

#FHIR and R (Stats / graphing language)

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

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

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

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

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

Restructuring the data

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

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

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

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

Where to now?

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

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

Question: HL7 v2 referrals in Australia


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

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

And within that

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

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


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

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

The link to the simplified profile is

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