See the official FHIR Product Director Blog.
See the official FHIR Product Director Blog.
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:
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.113818.104.22.168.5.
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?
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.
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
See my post over on the official FHIR Product Director blog.
The FHIR team is continuing to grow, and has plenty of opportunities for more people to contribute. Here are some of those opportunities:
We’re looking for:
We’re looking for:
HAPI and the C# reference implementations would love to get more active contributors.
There are several roles:
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 firstname.lastname@example.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.
Unless you’ve been living under a rock, you’ve probably heard the terms ‘alt-right’ and ‘fake news’ by now. According to Wikipedia: “the alt-right (short for “alternative right”) is a loose group of people with far right ideologies who reject mainstream conservatism in the United States.” and “Fake news websites (also referred to online as hoax news) deliberately publish hoaxes, propaganda, and disinformation to drive web traffic inflamed by social media. Note: I’m well aware that Fake news websites aren’t confined to just the alt-right, but there’s a strong link between alt-right and fake news. It’s become clear, as time as progressed, that this is just another security risk in the eco-system that is the internet. Viruses, phishing, and now fake news. Something for Google and Facebook to work on – here’s some thoughts about that.
Waiting in the wings is something else I call ‘Alt-Health’ – the spread of bad healthcare advice running like wildfire through social media. One particular aspect of if – the anti-vaxxer campaign – that’s getting air time in the mainstream press, but it’s much broader problem than just that. Bad medical advice on the internet is nothing new – e.g. Google have a team devoted to working on the quality of web pages returned for medical related searches. But the spread of bad advice on social media is outside that. And it’s not always wrong advice, actually. Sometimes, it’s extremely good advice for one patient, but wrong for another patient. But it’s handed on as gospel – ‘this worked for me, so ignore your doctor and do what’s proven to work’… if only life were so simple. Looking forward, I expect that this is going to turn into an epidemic, as people turn away from complexity and cost, seeking simple solutions. What they’ll get is outright wrong or wrong in context, and it’s going to kill people. On the other hand, we know that while a lot of the advice is bad, it can also be very good as well. In some circumstances, better than the clinical advice a patient gets, particularly for rare diseases.
People are going to need trusted healthcare advisers to sort of good advice from bad advice. Unfortunately, there’s a challenge here: some advice will be 100% stupid and wrong (you can cure cancer by eating the right vitamins) while other advice will be 100% right and true (you should stay on the treatment advised by your clinical team, or talk to them if it’s not working out), but a lot of advice is going to fit into the category ‘or maybe true, depending on circumstances’.
That’s where FHIR enters the picture: the FHIR standard has the coverage of this space:
Though there are many other standards at play here, FHIR is the one that links all this space together, and naturally fits into the web/internet eco-system.
So I believe that one of our key activities in the FHIR community over the next few years will be ensuring that the standards are in place to address the challenge that alt-health brings – that is, to enable clinical decision support to rank the reliability of random advice on the internet.
See my post “New FHIR Milestone Publications” over on the FHIR Product Director Blog
See my post about collaboration between HL7 and IHTSDO on the FHIR Product Director Blog
I needed an implementation of the Verhoeff check digit algorithm in Delphi, and couldn’t find one. So reproduced here for ease of use by anyone else who needs it:
const verhoeff_d : array[0..9,0..9] of integer = ( (0, 1, 2, 3, 4, 5, 6, 7, 8, 9), (1, 2, 3, 4, 0, 6, 7, 8, 9, 5), (2, 3, 4, 0, 1, 7, 8, 9, 5, 6), (3, 4, 0, 1, 2, 8, 9, 5, 6, 7), (4, 0, 1, 2, 3, 9, 5, 6, 7, 8), (5, 9, 8, 7, 6, 0, 4, 3, 2, 1), (6, 5, 9, 8, 7, 1, 0, 4, 3, 2), (7, 6, 5, 9, 8, 2, 1, 0, 4, 3), (8, 7, 6, 5, 9, 3, 2, 1, 0, 4), (9, 8, 7, 6, 5, 4, 3, 2, 1, 0) ); // The permutation table verhoeff_p : array[0..7,0..9] of integer = ( (0, 1, 2, 3, 4, 5, 6, 7, 8, 9), (1, 5, 7, 6, 2, 8, 3, 0, 9, 4), (5, 8, 0, 3, 7, 9, 6, 1, 4, 2), (8, 9, 1, 6, 0, 4, 3, 5, 2, 7), (9, 4, 5, 3, 1, 2, 6, 8, 7, 0), (4, 2, 8, 6, 5, 7, 3, 9, 0, 1), (2, 7, 9, 3, 8, 0, 6, 4, 1, 5), (7, 0, 4, 6, 9, 1, 3, 2, 5, 8) ); //The inverse table verhoeff_inv : array [0..9] of char = ('0', '4', '3', '2', '1', '5', '6', '7', '8', '9'); //For a given number generates a Verhoeff digit function genCheckDigit(s : String): char; var i, c, len : integer; begin c := 0; s := s + '0'; len := length(s); for i := len downto 1 do c := verhoeff_d[c][verhoeff_p[((len-i) mod 8)][ord(s[i]) - ord('0')]]; result := verhoeff_inv[c]; end; ////Validates that an entered number is Verhoeff compliant. ////The check digit must be the last one. procedure validateCheckDigit(s : String); var i, c, len : integer; begin c := 0; len := length(s); for i := len downto 1 do c := verhoeff_d[c][verhoeff_p[((len-i) mod 8)][ord(s[i]) - ord('0')]]; if c <> 0 then raise Exception.Create('Check digit error: "'+s+'" is not valid by Verhoeff algorithm'); end;
On the last day of the baltimore meeting, a small group of us met to talk about the future of testing in the FHIR specification. In particular, the participants included both Aegis and Mitre, who develop Touchstone and Crucible respectively. Out small group made 3 decisions:
Taking these backwards:
The TestReport will contain a summary of the outcomes a test run – which tests were run, whether they passed, and references to a further information (logs, etc). It’s for helping to maintain current registries of implementations and outcomes. I’ll blog about this further once there’s a draft to look at.
I’ll comment on #2 in time, when we have a draft for people to consider.
For #1, a testing framework, we have several motivations for this:
We’d like to normalise testing – to make clear expectations about how production systems could be tested, and to start encouraging production systems to actually provide such support. Two key corollaries of this – administrators can download the official tests (e.g. IHE, or others) and run them against their system with robots playing the part of the the other system. And also, the testing framework starts to acquire a clinical safety role – adminstrators can add new tests to their own automated tests for the application (e.g. prior to upgrade or configuration change) and assure themselves that known system requirements with regard to system safety are assured. Note that this is something you can only do in the context of a fully configured and linked system of systems – which is why support for testing in production systems is so important in this regard.
Anywhere, he’s a set of ideas to get people thinking about how this all might work:
Anyone with any engineering experience will immediately recognise that implementing this set of requirements is a major design undertaking. It’s not going to happen quickly in existing EHRs, unless s conceptually similar system already exists – but I’ve never seen one.
But if we regularise the interface, and the test servers implement it (not too hard in my server) – then we might encourage movement in this direction gradually, and that would make it cheaper to deliver truly reliable systems….