Monthly Archives: June 2014

Question: v2 Referrals

Question:

A typical scenario of tele-consultation is as follows. A patient comes to his nearest hospital. He is assigned to an initially assigned physician (IAP). All the relevant medical information are collected. IAP wants to consult with a specialist physician from a different hospital. So he sends the patient records to the referred hospital.

I assume hospitals are equipped with these EMR systems and they communicate via HL7 V2 messages. How patient medical records can be sent to the referred EMR? Which event to be triggered? What should be the message type? I could not find any HL7v2 message type that could hold all kind of patient records. How to handle such a situation with HL7v2? CDA has that capability. Many revisions are done for HL7v2. Is that already addressed?

Answer

The message type you are looking for is a referral – the IAP is referring the patient to the specialist. Note that some clinicians use the word “referral” strictly in the sense of a full transfer of care, not just a consultation, while others use the term more loosely. The HL7 referral message is suitable for both uses.

The message you are looking for is an REF/RRI message (event I12, chapter 11). It includes the following kinds of information:

  • Referral details
  • Contact and Provider information
  • Observations, and Diagnostic reports
  • Procedures, Problem lists, Allergy Lists
  • Encounter details

Alternatively, there’s the MDM messages in chapter 9 that deal with transfer of medical records – though they leave open the question of what format to use. In your use case, the natural choice would be CDA as the format, but if you want to avoid that, well, you come back to the REF message.

Error in R2 Datatypes

Today, Rick Geimer and Austin Kreisler discovered a rather egregious error in the Data Types R2 specifications. The ISO data types say:

This specification defines the following extensions to the URN scheme:

hl7ii – a reference to an II value defined in this specification. The full syntax of the URN is urn:hl7ii:{root}[:{extension}] where {root} and {extension} (if present) are the values from the II that is being referenced. Full details of this protocol are defined in the HL7 Abstract Data Types Specification

Reference: Section 7.6.2.7 of the ISO Data types

However, if you look through the Abstract Data Types R2 for information about this, you won’t find anything about hl7ii. But there is this, in section 4.13.1.1:

The scheme hl7-att is used to make references to HL7 Attachments. HL7 attachments may be located in the instance itself as an attachment on the Message class, or in some wrapping entity such as a MIME package, or stored elsewhere.

The following rules are required to make the hl7-att scheme work:

  1. Attachments SHALL be globally uniquely identified. Attachment id is mandatory, and an ID SHALL never be re-used. Once assigned, an attachment id SHALL be accosiated with exactly one byte-stream as defined for ED.data.
  2. When receiving an attachment, a receiver SHOULD store that attachment for later reference. A sender is not required to resend the same attachment if the attachment has already been sent.
  3. Attachment references SHALL be resolved against all stored attachments using the globally unique attachment identifier in the address.

(p.s. references are behind HL7 registration wall, but are free)

These are meant to be the same thing, but they are named differently: urn:hl7ii:… vs hl7-att:…

I guess this will have to be handled as a technical correction to one of the two specifications. I prefer urn:hl7ii:.

Comments welcome.

#FHIR + Open ID Connect

I’ve upgraded my FHIR server to support OpenID Connect tokens as part of it’s OAuth based login. This is part of implementing IHE’s IUA profile, though I’m not yet sure whether I’m going to finish that off – I’m still discussing the way that works with the IHE authors.

What this means is that as part of the server login process, my server provides a signed openID Connect token with user identification included in it. There’s now a standard Open ID Connect discovery document available here. Josh Mandel and I would like to make it standard for any FHIR server that uses OAuth, that the URL

[fhir-base]/.well-known/openid-configuration

either returns an OIDC discovery document describing the OAuth part of the server, or redirects to the appropriate location (OIDC puts it on the root of the server, so that would be best place for it).

I added this to help understand how hard it is to support the tokens, since they’re part of the Smart-On-FHIR framework. And the answer’s kind of split – the JSON/identification bits are relatively straight-forward (so far). But the crypto bits – they’re screamingly hard. Because my server is written using Delphi, my choice of crypto libraries is somewhat limited – especially since my code is open source – and in the end I had to go with openSSL. It’s astounding how hard this crypto stuff is. At least half the problem is because of openSSL (see, “openSSL is written by monkeys” – my experience matched that). But it’s not all openSSL – basic crypto is harder than it should be – a myriad of closely related counter-intuitive terms, barely differentiated but incompatible file formats, conflicting or wrong advice, etc. And then it either works, or it doesn’t, and mostly all you get is “didn’t work” as an error (e.g. the signature didn’t verify). But I got nearly there in the end (I still have to work though the hard bits of this) (and thanks to Josh for support).

Anyway, the upshot of all this is the first (as far as I know) open source Delphi implementation of JSON Web Tokens and their associated stack of things (JWK, JWS). This might be useful for other delphi programmers, so:

  • JWT.pas – the core implementation of JSON Web Tokens
  • JSON.pas – the json library it uses
  • libeay32.pas – extensions to the standard Indy OpenSSL headers (the next version of delphi will include these in the standard header file; these are extensions to the XE5 version)

And there’s some tests too. Also, there’s a bunch of other library stuff in Github there that those units depend on.

Question: CDA as a canonical data model

Question:

I am a university Master student. My thesis involves an implementation of an ESB(Mule) with the CDA R2 schema as a canonical data model (CDM). All of this is done from scratch and I encountered a difficult learning curve but managed to make two target systems interoperable. The systems don’t use the CDA internally so the use of the CDA is just done in the integration solution (ESB).

In my solution I construct a CDA that has a structured body with  sections, lists and elements. The sections dont have codes. Would that make it a level one CDA?

I found the CDA to be very difficult and complex. What are the main problems with the CDA in your opinion? Would it be better to use FHIR instead of CDA?

Answer:

Presumably by “lists” and “elements” you mean lists in the narrative section, and entries with clinical statements? That would make it a level 3 document. At the very least, multiple sections is level 2. (Though there’s some argument about whether you can be level anything without well described templates, and well described templates are not that useful in your case).

You would have found CDA to be very difficult and complex; it’s a clinical document, intended to be used for where “documents” are exchanged between clinicians. For example, referrals, discharge summaries, etc. As such, it was intended to be a “document” with supporting data. That’s not really a suitable thing to use as a “Canonical Data Model” – and so I don’t doubt that you struggled with too much complexity.

CDA does have some issues – see, for instance, my conclusions from the Australian National Program, but the biggest problem is that for all it’s issues, it’s still the accepted way to exchange clinical information, even when this means uses well outside it’s original intention.

Is FHIR better? Yes, I think it will be. It’s natively positioned to be used as a CDM for exchange between clinical systems. It’s based on a much simpler technical base, that ruthlessly targets implementation simplicity. But FHIR is still very much in beta (DSTU = Draft Standard undergoing Trial Use) and so CDA remains the default choice for now.

Joint OpenEHR / FHIR review of Allergy-related Resources

I’m really pleased to announce a new initiative as part of the ongoing development: we’re going to do a joint review of the FHIR resources for Allergy/Intolerance (AllergyIntolerance and AdverseReaction), and the openEHR archetype for the equivalent content (openEHR-EHR-EVALUATION.adverse_reaction.v1). The review is going to be done on the openEHR CKM, on a newly prepared archetype that shows the essential content models of the existing archetypes and resources (they’re quite different)

The review will open in the next week or so (final details still being nailed down) and will be open to everyone – the openEHR community, the HL7 community, and anyone else interested in representing allergies in clinical systems, or exchanging records of them between systems.

Note that OpenEHR and FHIR have different a purpose with regard to why resources and archetypes are defined and differing philosophy about how things are done, so we’re not expecting to get exactly the same content models at the end of this process, but we are intending to get consistent content models between the FHIR and openEHR communities. Note for the HL7 community: any changes proposed to the FHIR resource are then subject to the HL7 ballot process, and we are hoping that we can work with the openEHR community when we resolve the ballot content, so that we can continue to have aligned models.

This is a trial run – if it works well, we hope to both formalize the process, and to follow on with clinical review of other FHIR resources, and to create a drive towards wider collaboration and convergence between the communities.

For my many readers who aren’t familiar with openEHR CKM – don’t sweat on it. It’s pretty straightforward – we chose to use it for that reason, and I’ll post more details about how to join the review process in a few days time.

p.s. I’d like to thank the HL7 Patient Care WG co-chairs and the openEHR clinical modeling leads for kicking off this joint review process, and to many people within HL7 for their support.

FHIR Skype Chat Logs

A lot of the working business of the FHIR project team is done over Skype. In the interests of transparency, we’re now publishing logs of the skype chats.

Note: the Skype chats are mostly insider’s working business – we’ll often take a lot of context for granted. I’m sure that will confuse some people who jump into the middle of the chats because google sent them there…

 

p.a. Thanks to Josh Mandel for setting up the logging/publishing process.