Question: FHIR release schedule


I’m using the Java version of FHIR release 0.81. A bug fix that I needed required a later version of the code. I downloaded the code (rev. 2833) from SVN and, following the directions on the FHIR build page, had no trouble recompiling all of FHIR. Since rebuilding and replacing FHIR in our application is time consuming, I have some questions concerning release management:

  1. Is there a published release plan and schedule for FHIR?
  2. Is there a mechanism for patching or updating FHIR code between releases?

Note: this question was originally asked on StackOverflow where it was (a little unfairly) ruled out of scope.


The FHIR project is a combination of a specification, and a set of source that supports it. The project life cycle is driven by the considerations that flow from this.

The trunk version of FHIR is the current development version of FHIR, what the team works on from day to day. As a matter of ongoing work, it is not stable, and there is no guarantee that it is coherent and/or correct. The trunk version of FHIR is published here:

Periodically, the core editorial team that works on the specification and the code will determine that there have been enough changes and there is enough stability to publish a development release. These are published here: We typically keep upcoming connectathons that intend to use a more recent version than the formal DSTU in mind when we do this. This effectively corresponds to a beta release. Change notes and release notes are prepared when this is done.

Finally, HL7 ballots FHIR through the formal standards processes. The ballot process is based on the trunk version, and is the principle driver of the project development work. Once the ballot is passed and finalised, then a branch will be created for that formal publication – so far, there has only been one, the first DSTU (draft standard for trial use), published Feb 3 2014. This is published here:

A little further information can be found in our version numbering/change tracking policy.

Future plans:

  • We have no formal plans around when new development releases are made – this will happen periodically
  • We plan to close the next ballot cycle around May/June next year (e.g. 2015), and publish the 2nd DSTU then
  • Then we will start working on the full normative release, perhaps end of 2016. note that there can be no formal timeline for this, because it depends on the ballot process

A note about DSTU: from a software perspective, the 1st DSTU was a full release of working software. From a standards perspective, this is a beta release. Once a full normative standard is released, different change control policies kick in.

With regard to patching the FHIR code between releases, the reference implementations are actively maintained. The major ones (Java, C#, and pascal) are maintained in (or for) both the trunk and the DSTU branch (tagged DSTU1). We do periodic releases to them as major bugs are identified and fixed.

The DSTU branch has a history.

Specifically, with regard to the Java Reference Implementation, as of 12-Sept 2014:

  • We will maintain Maven releases for both the DSTU and development releases. The dev/trunk is not published to Maven
  • The original DSTU release was numbered 0.80. After a large argument about version numbering, we changed that version number to 0.0.81, and both of these are published on Maven. 0.0.81 supercedes 0.81
  • The specification will change to reference the correct Maven package directly next time it is published
  • A new release for the DSTU version is required now., because of a significant issue in the json represented, but there is considerable due process to releases in the DSTU branch, and the process isn’t quite finished yet.
  • I will be updating the development version immediately after the Sept 2014 connectathon, including releasing a new dev version

20 Questions #6: Optionality vs Extensiblity

In the 6th question of the 20 Questions seriesGreg Meyer, asks:

Optionality vs Extensibility: What effect is the large selection of standards and technology in the health IT domain having on interoperability? Do we need to eliminate optionality and focus more on extensibility?

There’s a bit more context with the question:

In my view, optionality is the death sentence of interoperability. That statement deserves a bit a context starting with the definition of optionality. Simply stated, optionality is the ability to choose one or more entities with complete disregard to supporting alternate entities. Applying that to interoperability, it means you can choose a single option (or multiple) from an enumerated set of options to perform a task without the requirement of supporting the rest of the options in that set. The result is a multitude of systems supporting different option sets where there may be no intersection of compatible options. The end game: no universal interoperability.

The real problem here is lack of alignment of use cases. Why aren’t the use cases aligned? Maybe the options truly are irrelevant – for instance, there’s no point expecting a physiotherapist package to supporting prescribing medications, for instance. On the other hand, two applications that both are a core EHR, why don’t their use cases match? There’s a number of reasons for that, including that there’s no consensus in medicine as to what the core use cases are. Also application history/legacy, different marketing/product strategies, and the personal choices of the key clinical and technical people as the application was taking shape.

If 2 applications don’t share the same set of use cases, then there won’t be any interoperability between them, or it will be fitful – like pasting content between word and a browser and vice versa – it kind of sorta works. Most of the time, but you’ll often have to manually fix it for things that didn’t work how you wanted it to. In these cases, the choice of optionality vs extensibility is moving deck chairs around on the titanic, and there’s not much you can do. Following this thought experiment, it means that resolving optionality is the same as resolving the use cases, and the problem is that IT people can’t do it, and clinical people don’t yet see the need to do it.

Given that we can’t resolve the problem, which is the best way to do it? In HL7, we generally call this the minimal vs maximal approach. We have a set of use cases that create overlapping wire format requirements – should we express the super set of all of them, or the subset of only what they all share? Put like this, it’s obvious: the minimal set that all use cases share is not (generally) capable of supporting any of the individual use cases, and a specification that is minimal doesn’t work for any of them. So in practice, we produce standards that are half way in-between – not minimal or maximal – and in FHIR, we’re trying to be explicit about that.

Does that mean we don’t care about the minimal problem? No – the full HL7 methodologies for the various standards are capable of expressing the idea of minimum conformance – this is the minimum capability that you must have to be conformant. There’s a few problems with this though:

  • The capability for this is mostly lost in the overall complexity, and the tools to support it are poor
  • It’s not usually HL7’s business to force people to comply, so there’s often not a lot of point trying to capture this
  • It’s extremely difficult to capture this information

The consequence of this is that the minimal set is hardly ever expressed.

On that last point – it is extremely difficult to capture the information about the minimal set of shared requirements/use cases. It’s easy for an open community to capture use cases that aren’t handled – this can be expressed as “your standard doesn’t work for this use case” – a fault with the community product. But to capture the set of minimal agreement requires the members of the community to say something like “we don’t do this” – making it sound as if the fault is with the member. Very hard for a community to get it’s members to do, and vendors- and even providers – are extremely reluctant to do that (in fact, in practice, the decision to release that kind of information often has to be approved at the C-level). In FHIR, we’re setting up a special system to cater for gathering this kind of information through a trusted proxy so that there’s no possibility that observers will be able to trace information about the minimal set to any particular source, but it remains to be seen how well that will work.

Interoperability remains a tough problem.


#FHIR: Testing a new search mechanism

The FHIR search mechanism is based on the HTTP parameter mechanism – a series of named parameters with values. This works quite well for simple cases, but we’ve pushed it pretty far, and there’s a few cases for which we’ve had to invent some pretty tricky hacks to get things done (modifiers!). Here’s an example of a moderately simple search: find all the observations for patient with a name including “peter” that have a LOINC code 1234-5:

GET [base]/Observation?name=|1234-5&

The OData and SCIM specifications do search differently – a single http parameter “filter”, with it’s own search syntax. Following this pattern, the search would be:

GET [base]/Observation?filter=name eq|1234-5 and co "peter"

That alternative syntax has different strengths and weaknesses – it’s a little harder to get to to work (another syntax to deal with) but it’s also more capable, particularly at expressing nested related searches, which is the limitation of the existing approach. On the other hand, the existing approach is amenable to making up html forms fairly simply, and that’s not true of the filter based approach, so there’s always a price to pay for complexity.

But since implementers regularly ask why we don’t do search like OData/SCIM etc, I decided that for the connectathon this weekend, I’d add support for a _filter parameter (“_filter” not “filter” because of the way FHIR naming conventions work). Here’s how what I’ve implemented works:

  • A filter can be a logical one (x or x, or x and x, or not x)
  • A filter can contain other filters in a set of parentheses : “()”
  • A filter can be a test – path operation value, where operation is taken from the table below, and value is either a “true”, “false”, a JSON string, or a token (any sequence of non-whitespace characters, excluding “)” and “]”. Values are never case sensitive
  • A ‘path’ is a name, with chained searches done by etc as per existing source. There can also be a filter: name[filter].name…
  • The name is one of the defined search parameters that are used with the other search mechanism, with some special exemptions defined below.

Here’s some example filters:

  • Patient: name co “pet” – all patients with the characters “pet” in a given or family name
  • Patient: given eq “peter” and birthdate ge 2014-10-10 – all patients with a given name of peter, born on or after 10-Oct 2014
  • Observation: name eq|1234-5 – all observations with the loinc code “1234-5″
  • Observation: co “pet” – all observations on a patient with the characters “pet” in a given or family name
  • Observation: related[type eq "has-component"].target pr true – all observations that have component observations (note: this uses one of the search parameters defined for this mechanism, see below)
  • Observation: related[type eq has-component].target re Observation/4 – all observations that have Observation/v as a component

Note that the only difference between a “string” value and a “token” value is that a string can contain spaces and ) and ]. There is otherwise no significant difference between them.

Here’s the formal grammar for the syntax:

filter       = paramExp / logExp / ("not") "(" filter ")"
logExp       = filter ("and" / "or" filter)+
paramExp     = paramPath SP compareOp SP compValue
compareOp    = (see table below)
compValue    = string / numberOrDate / token
string       = json string
token        = any sequence of non-whitespace characters (by Unicode rules) except "]" and ")"
paramPath    = paramName (("[" filter "]") "." paramPath)
paramName    = ALPHA (nameChar)*
nameChar     = "_" / "-" / DIGIT / ALPHA
numberOrDate = DIGIT (DateChar)*
dateChar     = DIGIT / "T" / "-" / "." / "+"

Some additional notes about this:

  • Logical expressions are evaluated left to right, with no precedence between “and” and “or”. If there is ambiguity, use parentheses to be explicit
  • the compareOp is always evaluated against the set of values produced by evaluating the param path
  • the parameter names are those defined by the specification for search parameters, except for those defined below
  • the date format is a standard XML (i.e. XSD) dateTime (including timezone).

This table summarises the comparison operations available:

Operation Definition
eq an item in the set has an equal value
ne An  item in the set has an unequal value
co An item in the set contains this value
sw An item in the set starts with this value
ew An item in the set ends with this value
gt / lt / ge / le A value in the set is (greater than, less than, greater or equal, less or equal)  the given value
pr The set is empty or not (value is false or true)
po True if a (implied) date period in the set overlaps with the implied period in the value
ss True if the value subsumes a concept in the set
sb True if the value is subsumed by a concept in the set
in True if one of the concepts in the set is in the nominated value set by URI, either a relative, literal or logical vs
re True if one of the references in set points to the given URL

The interpretation of the operation depends on the type of the search parameter it is being evaulated against. This table contains those details:

Operation String Number Date Token Reference Quantity
Eq Character sequence is the same (case insensitive) Number is the same incl same precision Date is the same including same precision and timezone if provided Token is the same, including namespace if specified (case insensitive) n/a Unit and value are the same
Ne (same)————————————————————————————————————————————
Co Character sequence matches somewhere (case insensitive) An item in the set’s implicit imprecision includes the stated value An item in the set’s implicit period includes the stated value n/a n/a n/a?
Sw Character sequence matches from first digit (left most, when L->R) (case insensitive) n/a n/a n/a n/a n/a
ew Character sequence matches up to last digit (right most, when L->R) (case insensitive) n/a n/a n/a n/a n/a
gt / lt / ge / le Based on Integer comparison of Unicode code points of starting character (trimmed) (case insensitive) Based on numerical comparison Based on date period comparison per n/a n/a Based on numerical comparison if units are the same (or are canonicalised)
po n/a n/a Based on date period comparison per n/a n/a
ss n/a n/a n/a Based on logical subsumption; potentially catering for mapping between tx n/a n/a
sb n/a n/a n/a Based on logical subsumption; potentially catering for mapping between tx n/a n/a
in n/a n/a n/a Based on logical subsumption; potentially catering for mapping between tx n/a n/a
re n/a n/a n/a n/a Relative or absolute url n/a


  • For token, the format is the same as the existing search parameter. For convenience, the codes “loinc”, “snomed”, “rxnorm” and “ucum” are predefined and can be used in place of the full namespace

Additional Parameters

I needed to define some additional parameters in order to get this to work well. This table summarises the search parameters I added:

Resource Type Parameter Name Children
Observation related target = related-target

Type = related-type

Group characteristic value = value

code = characteristic

DocumentReference relatesTo code = relation

target = relatesTo

DiagnosticOrder event status = event-status
date = event-date
DiagnosticOrder item status = item-status

code = item-code

site = bodysite

event = item-event

DiagnosticOrder item-event status = item-past-status
date = item-date
actor = actor


  • Any time these names are used in a parameter, they must have a filter and a chained name under them
  • The first column is the resource type against which this name can be used
  • The second column is the name that is used
  • The third column defines the names that can be used in the chained parameter, and in the filter, and shows which existing search parameters they equate to
  • For example, you could search on Observation for related[type eq has-component].target re url. “type” here refers to the search parameter “related-type”, and “target” to the search parameter “related-target”. Note that the names are not always aligned like this – FHIR itself may be revised to make it so (a gForge task already exists to do so)


This is implemented on my server at, though the implementation has got some things that aren’t done yet (none of the really cool operations in “ss”, “sb” or “in”, for instance). Hopefully I’ll be able to fill some of these out by this weekend.

I’ve done this so that we can get a feel for how this approach works. It may become a candidate to add to the specification, either in addition to the existing search, or instead of it. I’m dubious about the second option though – what I’ve discovered about this search is that it isn’t degenerate, like the existing search – either you implement all the search, or you return an http error code. The existing search, you just add parameters in case they apply. That’s pretty useful, actually.



20 Questions for Health IT

“20 Questions for Health IT” is a project being run by Chad Johnson from

Beginning Tuesday, Sept. 2., we will begin publishing one health IT topic per day from 20 different individuals with a deep understanding of the topic. The author of each question was generous enough to stick her or his neck out and pose a short answer to the question in the hopes it will encourage further discussion in the comments section and also on Twitter using the #20HIT tag.

I’m honoured to be one of the 20 individuals. I’ve seen some of the topics that are coming, and it looks like it’s going to be pretty interesting. Hopefully Chad will post a summary for non-twitterers.

Observation of Titers in HL7 Content

Several important diagnostic measures take the form of a Titer. Quoting from Wikipedia:

A titer (or titre) is a way of expressing concentration. Titer testing employs serial dilution to obtain approximate quantitative information from an analytical procedure that inherently only evaluates as positive or negative. The titer corresponds to the highest dilution factor that still yields a positive reading. For example, positive readings in the first 8 serial twofold dilutions translate into a titer of 1:256 (i.e., 2−8). Titers are sometimes expressed by the denominator only, for example 1:256 is written 256.

A specific example is a viral titer, which is the lowest concentration of virus that still infects cells. To determine the titer, several dilutions are prepared, such as 10−1, 10−2, 10−3, … 10−8.

So the higher the titer, the higher the concentration. 1:2 means a lower concentration than 1:128 (note that this means the clinical intent is the opposite of the literal numeric intent – as the titre gets lower, the concentration gets higher).

Titers are pretty common in clinical diagnostics – I found about 2600 codes for titer type tests in LOINC v2.48 (e.g. Leptospira sp Ab.IgG).

Representing Titers in HL7 Content

In diagnostic reports, titers are usually presented in the text narrative (or the printed form) using the form 1:64, since this makes clear the somewhat arbitrary nature of the numbers in the value. However it’s not unusual for labs to report just the denominator (e.g. “64”) and the person interpreting the reports is required to understand that this is a titer test (this is usually stated in the name).

When it comes to reporting a Titer in structured computable content, there’s several general options:

  • represent it as a string, and leave it up to the recipient to parse that if they really want
  • represent it as an integer, the denominator
  • use a structured form for representing the content

Each of the main HL7 versions (v2, CDA, and FHIR) offer options for each of these approaches:

String Integer Structured
V2 OBX||ST|{test}||1:64 OBX||NM|{test}||64 OBX||SN|{test}||^1^:^64
CDA <value xsi:type=”ST”> 1:64 </value> <value xsi:type=”INT”> 1:64 </value> <value xsi:type=”RTO_INT_INT”> <numerator value=”1”/> <denominator value=”64”> </value>
FHIR “valueString “ : “1:64” “valueInteger” : ”64” “valueRatio”: { “numerator” : { “value” : “1” }, “denominator” : { “value” : “64” } }

(using the JSON form for FHIR here)

One of the joys of titres is that there’s no consistency between the labs – some use one form, some another. A few even switch between representations for the same test (e.g. one LOINC code, different forms, for the same lab).

This is one area where there would definitely be some benefit – to saying that all labs should use the same form. That’s easy to say, but it would be really hard to get the labs to agree, and I don’t know what the path to pushing for conformance would be (in the US, it might be CLIA; in Australia, it would be PITUS; for other countries, I don’t know).

One of the problems here is that v2 (in particular) is ambiguous about whether OBX-5 is for presentation or not. It depends on the use case. And labs are much more conservative about changing human presentation than changing computable form – because of good safety considerations. (Here in Australia, the OBX05 should not be used for presentation, if both sender and receiver are fully conformant to AS 4700.2, but I don’t think anyone would have any confidence in that). In FHIR and CDA, the primary presentation is the narrative form, but the structured data would become the source of presentation for any derived presentation; this is not the primary attested presentation, which generally allays the lab’s safety concerns around changing the content.

If that’s not enough, there’s a further issue…

Incomplete Titers

Recently I came across a set of lab data that included the titer “<1:64″. Note that because the intent of the titre is reversed, it’s not perfectly clear what this means. Does this mean that titre was <64? or that the dilution was greater than 64. Well, fortunately, it’s the first. Quoting from the source:

There are several tests (titers for Rickettsia rickettsii, Bartonella, certain strains of Chlamydia in previously infected individuals, and other tests) for which a result that is less than 1:64 is considered Negative.  For these tests the testing begins at the 1:64 level and go up, 1:128, 1:256, etc.   If the 1:64 is negative then the titer is reported as less than this.

The test comes with this sample interpretation note:

Rickettsia rickettsii (Rocky Mtn. Spotted Fever) Ab, IgG:

  • Less than 1:64: Negative – No significant level of Rickettsia rickettsii IgG Antibody detected.
  • 1:64 – 1:128: Low Positive – Presence of Rickettsia rickettsii IgG Antibody detected
  • 1:256 or greater: Positive – Presence of Rickettsia rickettsii IgG Antibody, suggestive of recent or current infection.

So, how would you represent this one in the various HL7 specifications?

String Integer Structured
V2 OBX||ST|{test}||<1:64 {can’t be done} OBX||SN|{test}||<^1^:^64
CDA <value xsi:type=”ST”> &lt;1:64 </value>  {can’t be done} <value xsi:type=”IVL_RTO_INT_INT”> <high> <numerator value=”1”/> <denominator value=”64”> </high> </value>
FHIR “valueString “ : “<1:64” {can’t be done} “valueRatio”: { “numerator” : { “comparator” : “<”, “value” : “1” }, “denominator” : { “value” : “64” } }

This table shows how the stuctured/ratio form is better than the simple numeric – but there’s a problem: the CDA example, though legal in general v3, is illegal in CDA because CDA documents are required to be valid against the CDA schema, and IVL_RTO_INT_INT was not generated into the CDA schema. I guess that means that the CDA form will have to be the string form?



Caption Contest

I don’t get humorous stuff on this blog often enough. However, my attention has just been drawn to this picture of one the followers of this blog posing with a projection of the RIM:

Caption Contest

I’ll buy a beer at the next (HL7 meeting, HIMSS, or whereever) for the person who nominates the funniest caption for this picture.

p.s. be funny. I’ll moderate these comments if I have to

Question: Using Medication resources in FHIR


What’s the implementation extent for representing medication prescriptions with:

  1.  escalating dosage (eg,take 2 at each meal first week, then 1 at each meal)
  2. multi-drug medications (eg HYDROCODONE 5MG/ACETAMINOPHEN 500MG)


1. Variable Dosage

There is a variety of approaches to this in existing systems – sometimes text focused. But in the prescription resource, this is handled by repeating the dose instructions:

    <low value="2014-08-14"/>
    <high value="2014-08-21"/>
    <value value="2"/>
    <units value="tablet"/>
    <low value="2014-08-22"/>
    <value value="1"/>
    <units value="tablet"/>

2. Multi-Drug Medications

The MedicationPrescription resource refers to a Medication resource for the details of what is prescribed, and this offers 2 different ways to deal with this situation. The common way this works is that there is a single code for the medication, taken out of something like RxNorm.:

<Medication xmlns=""> 
   <system value=""/>
   <code value="856903"/>

Since the code itself is explicit about the multiple ingredients, then there is no need to say anything further. However in the case of extemporaneous medications, there is no extant code, so you would so something like:

<Medication xmlns="">
 <name value="My Custom Elixir"/>
 <kind value="product"/>
       <reference value="Medication/hydrocone"/>
        <value value="5"/>
        <system value=""/>
        <code value="mg"/>
        <value value="10"/>
        <system value=""/>
        <code value="mL"/>
       <reference value="Medication/acetaminophen"/>
        <value value="500"/>
        <system value=""/>
        <code value="mg"/>
        <value value="10"/>
        <system value=""/>
        <code value="mL"/>

Although, of course, this particular custom elixir doesn’t seem like a very likely real world case.

Update – related question:

“tid” is not the same thing as “q8h”.  Can they be differentiated in FHIR?

  <frequency value="3"/>
  <duration value="1"/>
  <units value="d"/>


  <frequency value="1"/>
  <duration value="8"/>
  <units value="h"/>

Question: sending PDFs via HL7 v2

This question is a follow up to one asked on Stack Overflow


On stack overflow you asked me to look at MDM message type. My question is that I know some systems can’t handle MDM message types so if this is the case how could sending of a url for a pdf be handle in that case?

What is the best way(appropriate message/event type) to put a url for a pdf in an hl7 message(ie what are the message types and segment, etc.. that are appropriate)?

Also does the HL7 standard allow for the unsolicited pushing of pdf messages whether it be a url to a message or an actual pdf document encoded in hl7? For example if an ADT message came in and was successfully loaded into my system and I wanted to create an hl7 message to send out with the link or embeded pdf that i created. What hl7 message would i use to send?


Most systems would have no concept of why they’d accept an unsolicited PDF – where would it go? what’s it’s workflow? If they do know the answer to that question, and they can accept it, then they should implement the MDM messages (T12, T14, T15 maybe), since that’s the correct message type for that functionality.

If the destination system doesn’t handle MDM messages, then it most likely doesn’t handle unsolicited PDF messages, but you’d have to ask (or consult the documentation if it exists). It’s going to be a per system thing – but it is anyway, since systems vary so much.

You can send an ORU message with an OBX segment with an RP data type in OBX-5 which is a reference to a PDF(or even an ED data type with the entire PDF in it). But whether systems can accept ORU messages like this, and whether they can correctly represent an RP/ED like this… again, that’s a question for each individual system.

#FHIR CDA Position Statement & Roadmap: Joint Statement with Lantana

Lantana Consulting Group invited me to take part in the Spring CDA Academy after the HL7 Working meeting in Phoenix in May, which I enjoyed greatly. While I was there, we spent some time discussing the relationship between CDA and FHIR, both where things are today, and where we think they should be.

This is a pretty important subject, and from the beginning of our work on FHIR, one of the most common questions that we have been asked about FHIR is “what about CDA?”. Sometime, we get asked a more specific question:  “What does Lantana think about FHIR?”.

Since the CDA Academy, we’ve been working on a joint statement that summarizes the outcome of our discussions, a shared expression of where we believe that we are, and should be. Today, Lantana Consulting Group have posted our position statement on FHIR and CDA (see their blog post):

This position statement addresses the relationship between HL7’s Clinical Document Architecture (CDA) product line and the Fast Health Interoperability Resource (FHIR) product line. It was prepared jointly by Lantana Consulting Group—a recognized leader in the CDA community—and Grahame Grieve, Health Intersections, the FHIR project lead. This statement is not official policy. It is our hope that it will stimulate discussion and possibly guide policy makers, architects, and implementers as well as standards developers.

An underlying key concept for this position statement is that difference between a “package of data and narrative” and interactive access to the narrative and data in a patient or institution’s record, and that both have their place for exchange. Quoting from the document: 

CDA addresses interoperability for clinical documents, mixing narrative and structured data. FHIR provides granular access to data, a contemporary, streamlined approach to interoperability, and is easy to implement. FHIR can be the future of CDA, but it is not there yet.

FHIR offers considerable promise, but it’s certainly true that we have a long way to go yet. The joint statement issues a call to action:

FHIR DSTU 1 is not a replacement for CDA or C-CDA. Building out the specification so that it can represent existing documents as FHIR resources, and ensuring that FHIR resources can be integrated into CDA documents should be the focus of the next iteration of the DSTU

This is explicitly part of the scope of the next DSTU version of FHIR: to address the areas that CCDA covers, and several Lantana employees have already been working with us on this; I look forward to increased focus on this work.

Question: NEHTA CDA & GP referrals


Is there any example of NEHTA compliant CDA document that I can look at from a perspective of a GP referral form ( )? Is there a tool that can be used to navigate and generate the CDA from a HL7 v2 message?


There’s been a lot of discussion over the last decade or so about creating a CDA document for these kind of referral forms. I saw a pretty near complete set of functional requirements at one point. But for various reasons, the project to build this has got any funding, either as a NEHTA project, or a standards Australia project (it’s actually been on the IT-14-6-6 project list for a number of years, mostly with my name on it).

So right now, there’s no NEHTA compliant document. As a matter of fact, I don’t know of anything quite that like that from any of the national programs, though no doubt one of my readers will – please comment if you do. There is a project investigating this in the US National Program (S&I framework( but they’re not using CDA.

On the other part of the question, no, unfortunately not. NEHTA provides both C# and java libraries that implement the NEHTA described CDA documents, but it’s an exercise left to the implementer to convert from a v2 message to a CDA document. That’s primarily because there’s so much variability between v2 messages that there’s no safe way to write a single converter

I tried to do that with just AS 4700.2 messages, which are much more constrained than the general case, and it wasn’t really successful; the PITUS project is working on the fundamental alignment needed to get ti right in the future.