Category Archives: Standards

Question: CCDA and milliseconds in timestamp

Question:

We are exchanging CCDs over an  HIE. While consuming a CCD from a particular partner, we are having issues parsing the dates provided in the CCD. Most often, we cannot process the effectiveTime in various sections of the CCD.

We have been told that our partner is using a C-CDA conformant CCD. The CCD parser on our side cannot handle any of the effectiveTime values which contain milliseconds, such as:
<effectiveTime value=”20170217194506.075″/>

Our vendor informed us that:

“The schema you referenced (for a CCD) is the general data type specification for CDA. There are additional implementation documents that further constrain the data that should be reported. For example, the sections shown below are from the HL7 Implementation Guide for Consolidated CDA Release 1.1. As you can see, a US Realm date/time field (which includes the ClinicalDocument/effectiveTime element) allows for precision to the second.
The guides for other CCD implementations – C32, C-CDA R2.0, etc. – include identical constraints for /ClinicalDocument/effectiveTime. These constraints are the basis for our assertion that milliseconds are not acceptable in ClinicalDocument/effectiveTime/@value.”

The schemas provided for C-CDA and CDA do allow for a milliseconds value, according to their RegEx pattern. The CCDA schematrons have notes that specify:

The content of time SHALL be a conformant US Realm Date and Time (DTM.US.FIELDED) (2.16.840.1.113883.10.20.22.5.3).

Even though the schematron may not have the checks to flag a millisecond value, they do make that statement, which does not allow for milliseconds.

Please provide guidance on whether milliseconds are acceptable in C-CDAs and/or CCDs.  If milliseconds are not allowed, then why don’t the schemas/schematrons trigger errors when millisecond values are found?

Answer:

Firstly, some background: The CDA schema is a general schema that applies to all use of the CDA specification anywhere. So the schema allows milliseconds. CCDA is a specification that builds on CDA to make further restrictions. Most of these can’t be stated in schema (because schema does not allow for different content models for elements with the same name). So these extra constraints are made as schematron, so they can also be tested for CCDA documents.

The CCDA specification says, concerning date times, that they SHALL conform to DTM.US.FIELDED, and about dates like that, it says:

1. SHALL be precise to the day (CONF:81-10078).

2. SHOULD be precise to the minute (CONF:81-10079).

3. MAY be precise to the second (CONF:81-10080).

4. If more precise than day, SHOULD include time-zone offset (CONF:81-10081).

It sure sounds like you can’t use milliseconds. But, unfortunately, that’s a wrong interpretation. The DTM.US.FIELDED template on TS is an ‘open template’ which means that anything not explicitly prohibited is allowed.

Since milliseconds are not explicitly prohibited, they are allowed.

(Yes, you can then ask, why say “MAY be precise to the second”? this is careless language for a specification, and creates exactly this kind of trouble)

Note: this answer comes from Calvin Beebe (coming HL7 chair) on the HL7 Structured Documents Email List, and I’m just archiving the answer here so it can be found from search engines.

#FHIR, CDS-Hooks, and Clinical Decision Support

This is a guest post written by Kevin Shekleton from Cerner, and first posted to the HL7 CDS email list. Reproduced here for wider availability by agreement with Kevin


TL;DR: CDS Hooks will be working with the HL7 Clinical Reasoning team to make sure our approaches are complementary, and to ensure that CDS Hooks is on a path to standardization. The CDS Hooks implementation community should expect no changes to our open, community-based development process (but should expect to see increased interest and engagement from the community).

As briefly mentioned a few days ago on an earlier thread, there is some news to share from the HL7 WGM a couple weeks ago. I didn’t share this immediately at that time because frankly, I wasn’t sure as to the details yet. Rather than posting a vague post I was waiting until we had a few more discussions before communicating this out. 🙂
During the WGM, I attended a joint meeting between the CDS, CQI, and FHIR-I working groups. During this meeting, one of the topics of discussion was a new project scope statement (PSS) to semantically align Clinical Reasoning to CDS Hooks. There was an acknowledgement by the HL7 working group of the support and interest CDS Hooks has within the EHR and CDS vendor communities, so ensuring Clinical Reasoning aligns (where/when possible) to CDS Hooks is beneficial to those planning to support both projects.
The CDS working group has been working on a model for clinical decision support within FHIR called Clinical Reasoning (formerly known as CDS on FHIR). I’ve fielded many questions from folks all asking the same thing: “What is the difference between Clinical Reasoning and CDS Hooks?”
At the end of the joint meeting, several of us stuck around afterwards to discuss the two projects in further detail. Specifically, we began to directly address that aforementioned question: “What is the difference between Clinical Reasoning and CDS Hooks?”. We all agreed that none of us have ever had a very clear response to that question, mainly because each of us have been focused on our respective projects and have not sat down recently to compare/contrast the specifics of our approaches and goals.
Bryn Rhodes (primary architect of Clinical Reasoning), Isaac Vetter (Epic), and I proceeded to work for the next 6 hours or so on educating each other on architecture specifics, projects goals, and design constraints of each project. In doing so, we came away with the following high level takeaways:
  • CDS Hooks is designed solely around the execution of external clinical decision support.
  • Clinical Reasoning was designed primarily around the definition, sharing, and execution of local clinical decision support. However, the project also defines capabilities for external decision support that are based on older specifications, resulting in the overlap with CDS Hooks.
Based upon our initial work that afternoon/night, we all agreed on several things:
  • Continuing our conversations was in the best interest of both projects.
  • Both projects should be complementary
  • The sweet spot of Clinical Reasoning is in the space of local CDS
  • The sweet spot of CDS Hooks is in the space of external CDS
To reflect this, we modified the aforementioned project scope statement to commit to continuing these discussions in 2017 with the goal of more directly aligning the projects. Specifically, we agreed to explore moving CDS Hooks as an independent entity within the HL7 CDS community to solve the problem of external CDS, leaving the current Clinical Reasoning project to focus on the problem of local CDS.
What does this mean to all of you who are implementing CDS Hooks?
Not much, actually. We’re not changing our focus or design. The simplicity and focus of CDS Hooks has been one of its best strengths which is evident in the broad support, interest, and ease of development within the community. We will not compromise that.
What does this mean for how the project is managed?
Again, not much. CDS Hooks will remain a consensus driven open source project using modern development practices and tooling and following its own independent release process. I think this has worked well for other projects like SMART. I am working on a more formal project governance (more on this later) that should allow us to continue operating as-is while simultaneously satisfying HL7’s requirements.
Additionally, all of the conversations and work we’re just now starting will be done in full view of the community. Any proposed changes to CDS Hooks will continue to be logged as Github Issues and discussed with those interested, we’ll still run Connectathon tracks to get implementer feedback, and we’ll continue to use this mailing list and Zulip for discussions.
How does this benefit CDS Hooks, Clinical Reasoning, and the community?
First, the entire CDS community will have a clear understanding of Clinical Reasoning and CDS Hooks as well as when it’s appropriate to use each approach.
Second, both projects are going to be strengthened by our continued joint work to align on shared needs, identify gaps, and work in complementary directions rather than potentially pulling in opposing directions.
Finally, having CDS Hooks published under HL7 will benefit organizations that are constrained to recommending or implementing HL7 standards.
I’m excited for the work we’re all going to do within the CDS standards communities and specifically, CDS Hooks. The community support around CDS Hooks has been outstanding and I’m looking forward to working towards a 1.0 releases of a CDS Hooks spec this year as well as our first production implementations.

Opportunities Vacant in the #FHIR project

The FHIR team is continuing to grow, and has plenty of opportunities for more people to contribute.  Here are some of those opportunities:

Core FHIR spec

We’re looking for:

  • people from committees to work within committees to improve the definitions for resource, data type and profile elements and codes
  • implementers to work with the editors to develop further realistic high-quality examples that fill out resource usage
  • anyone who wants to work on proof-reading,
  • more committee members to learn how to edit specifications to give us more depth in the committees

Web Presence

We’re looking for:

  • a fhir.org web developer. If you know drupal, and you’re a member of the fhir+hl7 community, you can help with the various fhir.org services
  • more people to respond to questions on community.fhir.org

Reference Implementations

HAPI and the C# reference implementations would love to get more active contributors.

There are several roles:

  • first responder – answer questions about using them in various social media
  • tester – maintaining and extending the automated tests, and manually testing what can’t be automatically tested
  • documentation – contributing how-to and core documentation, and explaining how the RIs compare to the spec
  • committer – code contributors are also welcome

 

You can contribute to these as much as you like – a few hours here and there, up to full time.

If you’re interested in contributing in any of these roles, let me know (at grahame@hl7.org), and I’ll connect you up with the right team member.  We will be happy to provide support and direct you to necessary training material and documentation and/or set up mentor/mentee relationships to help you through the process.  If you’d like some justification to share with your manager/employer, we may be able to help there too.

If you have other ideas about how you’d like to assist, those would be welcome as well.

#FHIR – Adding Identifier to Reference

One of the more controversial sessions at the Baltimore meeting was where we discussed task 10659:  Reference should support logical references

This is a difficult subject because it relates to handling and exchanging information where a formal URL based view of the world is incomplete. In effect, that means, from a purist point of view, the world is already broken. This makes effective resolution difficult; at best, the resolution is also going to be broken – but is it broken in the least unuseful way? – that’s a bad place to try and get consensus from.

Further, in the FHIR framework, the Reference data type is clearly FMM level 5 – it’s been hammered everywhere from the beginning and is production in all sorts of places. And we’ve said that we won’t make breaking changes to FMM level 5 artefacts without consultation with the users. What’s not clear, though, is whether any of the changes that were proposed in the extensive discussion leading up to the quarter devoted to the task (see, for example, here and here) were actually breaking changes.

The outcome of the meeting was that we would add an Identifier to the Reference data type. Given the background, there was fairly strong consensus for the change, but it wasn’t complete. As a consequence, we said that we would define the change, let everyone look at it for a month, and see if any argument comes up that we had not considered.

So I’ve made the changes: see the Reference data type in the current build. Implementers are encouraged to evaluate the impact of this addition in their implementations, and share their findings on the FHIR email list.

Note: since this is not strictly a breaking change, this is not strictly consulting the implementers before making a breaking change 😉

#FHIR DevDays event is coming up

I’m finally on the way home from the HL7 Baltimore meeting. That means that the next main event for the FHIR community is the DevDays meeting in Amsterdam, organised by Furore. This just gets better every year.

The 2016 edition of the International HL7 FHIR Developer Days (16-18 November in Amsterdam) includes a tracks on many subjects, and – as is the practice of the FHIR community – features collaborations with other communities. In particular, this year, we’ll be sharing tracks with the openEHR and The Continua Alliance communities. The speaker line-up is a hall of fame of FHIR and I’m proud to be part of it. Participants of DevDays are free to follow any of the tutorials and hands-on sessions.

If you are interested in “my” track or in FHIR in general, don’t forget to sign up before September 30th, which is the Early Bird deadline and saves you 300 Euro.

I really enjoy the DevDays style, and it’s one of the best meetings I go to. It’s also the best way to engage with the FHIR community and work if you’re in Europe. I’ll see you all there!

 

#FHIR: Comments in JSON

We use XML comments extensively in FHIR for the examples in the specification:

  <Patient xmlns="http://hl7.org/fhir">
    <!-- this example patient shows how to use ... -->
  </Patient>

Generally, comments are only useful in examples for the specification and implementation guides.

Unlike XML, JSON doesn’t have a comments syntax. Standing advice is to put the comment in some property, so that’s what we did:

  {
    "resourceType" : "Patient",
    "fhir_comments" : "this example patient shows how to use ..."
  }

But there’s problems with that approach – you’re parser has to parse them, and many people have trouble with the idea that you can truly ignore them. Then, if you’re using JSON schema, you have to allow for them. Also, if you’re round-tripping with XML, you lose the exact position of the comment. Finally, must human readers miss the comment anyway, since it’s in a property – and the human readers are the only point of having comments. (So many people use custom variations to include comments, but that’s not an option we have. The JSON community is discussing that, but it seems unlikely it will change, or if it changes, be widely adopted).

The cumulative effect of all this is that, as a consequence of a ballot comment (disclosure: from me) the HL7 ITS committee proposes to remove support for comments from the FHIR JSON format. Specifically, we propose to remove this paragraph:

There is no inherent support in JSON for a comment syntax. As a convention, content that would be comments in an XML representation is represented in a property with the name fhir_comments, which is an array of strings, which can appear on any JSON object. This is heavily used in example instances, e.g. in this specification, but not usually used in production systems (and production systems may choose to reject resources with comments in them)

We don’t know of anyone using this in practice, and for practical reasons, I removed comments from the actual JSON examples in the current version earlier this year, and we’ve had no comments about that. Never-the-less, the JSON format is labelled FMM 5 (see the specification definition), so we need to consult with the implementation community about this.

So we are calling for comment from implementers about this change. If you wish to comment on this change, please send an email to the FHIR email list before Octover 11th 2016. If you comment against this change, make sure you identify the production implementation that would be affected by the change, and how it would be affected.

Notes on #FHIR trademark usage

The FHIR trademark system is operational. There are 2 kinds of license to apply for:

You can use the name “FHIR” without applying for a trademark license in 2 circumstances.

Fair Use

You don’t need trademark permission to make use of the name “FHIR” to refer to the specification HL7 publishes, or the community that builds it. You can use “FHIR” as you like as long as you are referring to one of those things. That’s covered clearly under the “fair use” provisions of trademark law in most jurisdictions. HL7 asks that you mention that FHIR is a registered trademark, and provide attribution to HL7, but you don’t need to do those things under fair use law.

In practice, you can mostly differentiate between fair use and other kinds of use by inserting “HL7’s” into the sentence. For example, if you hold an event called “Learn about FHIR”, modifying the sentence doesn’t really change the meaning: “learn about HL7’s FHIR”. So that’s fair use. On the other hand, if adding “HL7’s” changes the meaning, it’s probably not fair use. For example, I maintain a server called the “FHIRServer” (and I don’t do that on behalf of HL7 as FHIR product director). Changing that to “HL7’s FHIRServer” is not correct – the FHIR Server is not ‘HL7’s server’. So that’s not fair use, and I need trademark permission (which I applied for).

We’re always happy to help members of the community determine what’s fair use – you can always ask me or Wayne Kubick (HL7 CTO) for assistance. (and we’ll be publishing an FAQ in the future on this)

Btw, using #FHIR on twitter is also definitely fair use.

HL7 Use

If you’re organising an event, or providing a resource, and the activity is organised by HL7 or an affiliate, and the activity is linked to a registered project in the HL7 database, or in an affiliate formal list, then you don’t need trademark permission – HL7 own the trademark for it’s own use.

Why?

HL7 has no choice but to enforce trademark protection, but we’re doing our best to make the trademark protection un-intrusive as possible. You don’t need any permission to talk about FHIR – even to be critical. But you need permission to use FHIR to describe something of your own. We’ll grant permission if you have a credible plan for alignment with the specification/community, and if you’re describing what you’re doing clearly, so that there’s no confusion about where the ultimate source of authority over the FHIR lies.