Tuesday, July 28, 2015

Patient Identity Matching without a National Identifier in IHE Profiles

In the US, because Congress won't even let anyone in the Federal government TALK about creating a national identifier (privacy concerns), we have to deal with multiple identifiers at every healthcare provider.  At least in Canada, the provinces can assign a provincial patient ID.  But, not here alas.

So, last week at the IHE Meeting, somebody asked what identifiers are supported in IHE Profiles, from this list.  I think this query may have been in support of this project.

First Name
Last Name
Middle Initial
Suffix
Date of Birth
Gender
Race
Home phone number     
Address
·         Street
·         State
·         Zip
Middle Name
Cell phone
Mothers Maiden Name
Prefix
Marital Status
Alias or Previous name     
USPS Address
Identifier:
·         Last 4 of SSN
·         Driver License
·         Passport
·         Alien #
Multi Birth
Birth Order
Birth Place
E-mail
Previous Address
Previous Cell Phone(s)
Insurance ID
Insurance Plan Name
Previous Insurance
Medicaid ID
Medicare ID
Biometric ID

So, I put together a spreadsheet mapping these identifiers to HL7 V2.5.1, PIX, PDQ, PAM, PIX/PDQ V3, XCPD, and PDQm.  It didn't take too long, just a couple of hours.

A quick summary: HL7 Version 2 and PAM supports all of these directly by name with the exception of the alien #, which is simply another identifier in Patient Identifier List (PID-3).  HL7 makes no distinction between current and previous at the field level, although other parameters can be used to distinguish a current address from a previous address, or a current insurance identifier from a previous one. The notion of previous is dependent upon the time the query is performed, rather than being an attribute of any of this data in any case.  The distinction between Alias and simply another name is slim enough that even though PAM doesn't support the alias field, you can use repetitions of the name field to get there.

I don't think race belongs in this list.  It's not an "identifier", because in the US, race is whatever the patient says it is at the time that they say it (see OMB Policy Directive #15), and shouldn't be completed by someone else.

PDQ in all its flavors (V2, V3, and Mobile/FHIR) supports most of these (in bold).  Some (in italics) require the use of the Pediatric Demographics Option.  XCPD is a super set of PDQ V3, so it too supports the same set.

PIX (in all its flavors) performs patient matching.  IHE doesn't specify the algorithm, because master patient directory systems use a variety of different matching algorithms, and these are often tuned to the location where they are used.  Tuning parameters for name matching in Arizona could differ greatly from those in Wisconsin or New York for example.

Any missing pieces could be added as national extensions to existing IHE profiles.




Monday, July 27, 2015

Argue your limitations and they are yours

I'm having a [amusing | interesting | disheartening | great ] discussion over on Facebook with two Massachusetts doctors who are telling me how difficult it is to get information about the cost of treatment from payers.

Fortunately for me, unfortunately for them, MA state law effective January 1, 2014 states:
§228(a): Prior to an admission, procedure or service and upon request by a patient or prospective patient, a health care provider shall, within 2 working days, disclose the allowed amount or charge of the admission, procedure or service, including the amount for any facility fees required; provided, however, that if a health care provider is unable to quote a specific amount in advance due to the health care provider’s inability to predict the specific treatment or diagnostic code, the health care provider shall disclose the estimated maximum allowed amount or charge for a proposed admission, procedure or service, including the amount for any facility fees required.
(b) If a patient or prospective patient is covered by a health plan, a health care provider who participates as a network provider shall, upon request of a patient or prospective patient, provide, based on the information available to the provider at the time of the request, sufficient information regarding the proposed admission, procedure or service for the patient or prospective patient to use the applicable toll-free telephone number and website of the health plan established to disclose out-of-pocket costs, under section 23 of chapter 176O. A health care provider may assist a patient or prospective patient in using the health plan’s toll-free number and website.
Unfortunately for me, they probably still don't have a clue how to do this if the discussion I'm hearing is any clue.  This information is "difficult", hard to find, not complete, et cetera.

As my wife likes to tell me routinely, arguing for your limitations simply makes them stick, rather than producing any real change.

When I have a real health concern where this becomes an issue, I think I'll go tilt at that windmill for a while.

   Keith

Wednesday, July 22, 2015

IHE PCC FHIR-based Profiles for Trial Implementation

It's only Wednesday and already we have approved three IHE profiles to move forward into Trial Implementation, AND have the content updated for publication.  The CMAP and GAO profiles a number of comments from IHE and HL7 participants.  GAO received 50 comments.  CMAP received 30.

These profiles, like just about anything else I've done with FHIR were very easy to update.  We are usually scrambling to get this work done by the end of the meeting (tomorrow), and often have to complete our editing in the following weeks.  By this morning, we had already finished two of these, and after about 90 minutes of editing during lunch, I had finished GAO, which was the more complex of these two.

You can find the prepublication copy of these profiles on the IHE Web site.  They await a final editorial pass starting next week, and will be published very shortly.

I now have one work item left on my plate for THIS meeting, which is to finish up the BPMN white paper for public comment.  That's going to take some major editorial work, because it is as much an instructional guide to creating an IHE XDW profile in BPMN as it is anything else.  That stuff is always hard to get right.

     Keith

Tuesday, July 21, 2015

I'll be back!

In my outgoing message to HL7 members as an HL7 Board Member, I made a very short, simple statement.  "I'll be back" I said.

I had made an attempt to become the HL7 Chair, and that didn't work out.  The next opportunity for that role is some time away, and I don't want to spend that much time "out of the loop" of HL7 Board governance.  So I am again running for the HL7 Board.

HL7 International Members can vote for me here.

Unfortunately, at this time, Affiliate members cannot vote for me, and that is something I'd like to change, and have been working with the Internationalization task force to help the organization move in that direction.  That's been a multi-year effort that began initially when I first joined the HL7 Board, and is making SLOW progress.  But the same could be said for the progress we made on freeing up the HL7 standards and developing new business models until suddenly one day we were actually able to announce that policy change.

Big changes like this take time and effort.  I've been part of that effort, and would like to continue to be part of it going forward in HL7.  So, please vote for me in the HL7 Election, and if not me, then at least for someone who will do a good job.  There's a really good slate of candidates this year.

   Keith

Monday, July 13, 2015

Trifolia Template Comparison for CCDA 2.1

I finished my Trifolia template comparison tool last night and used it to compare C-CDA 1.1 to C-CDA 2.1.  You can find my detailed report here. A quick summary of results follows along with some general observations:

TypeIssuesComments
Major21Most were issues where 1.1 is more restrictive (has SHALL constraints) in content that MAY be present.  It's the "X, if present, SHALL" that causes a potential problem. These constraints most often appear in performer//addr and performer//telecom.  There are also a couple of possibly missed constraints, though CCDA 1.1 doesn't always follow the same patterns with Narrative text constraints.
Minor3These were mostly cases where a deprecated template which was removed in C-CDA 2.1 might need to be addressed in a SHOULD NOT constraint, just to make the point. If folks strongly disagree, I can back down.
Future9Minor inconsistencies in constraint splitting, or where something might be fixed or clarified without changing the meaning.  These can all wait for later as maintenance as far as I'm concerned.
Total33Overall, not bad for several dozen pages of constraints.

You can get the comparison stylesheet here.  Tonight I'm probably going to compare 2.0 to 2.1 just to see what shows up.  That has a different purpose.  I want to see what it takes to create a 2.1/2.0 aware C-CDA consumer.  I think that might be a useful document to add to the C-CDA 2.1 package.



Sunday, July 12, 2015

Agile Development

I've been improving my template comparison tool over various iterations, as I have been prone to do most of my life as a software developer.  It never really occured to me that I use agile without really thinking about it in projects like these.  Since I'm both the audience, and the developer, I try something out, and see where it goes.  I start with something that minimally works, or is at least good enough to start with.  Then I look at it, and see what I want to make better or improve upon.

The tool has evolved in various stages.  I started with basic comparisons over the narrative text of the constraints.  I made some changes to remove some non-essentials from the text comparison when I first built it, e.g., conformance identifiers.  Subsequently (after implementing a few other tweaks), I realized that I could further improve that comparison by simply removing parenthetical text.

In between those tweaks, I fixed my context "bug", where I hadn't counted on the fact that that same context could be constrained in different ways.  Originally, I just iterated through all the variations, but found that two different contexts that should have lined up (entryRelationships where typeCode='COMP'] didn't, simply because of ordering issues.  So I then sorted those contexts differently, using typeCode.  I later realized that wasn't good enough, because I was comparing an entry of type Act to another of type Procedure.  So, now I look at both @typeCode and @class.

But adding typeCode and class to the context makes the output ugly, and I really don't need to see this stuff, just organize by it.  So I'll have to change my output to eliminate text between [] in my rewritten contexts.

It's still not perfect.  One of my current challenges is that while I want to keep my comparison table columns aligned between templates, I also want to support indenting of nested constraints in some way.

outer context constraint 1Old stuffNew Stuff
outer context constraint 2Old stuffNew Stuff
inner context constraint 2aOld StuffNew Stuff
inner context constraint 2bOld StuffNew Stuff

The problem is that I don't know how many rows of inner constraints will be produced until I produce the output.  So I cannot compute how many rows I need to span value for the empty cells in the inner context.

There are at least three ways I can think of to resolve this.  The simplest of these is to apply a second pass transform over the output to clean up the context breaks.  I can simply output a tag in the recursing section of the table, and then count rows and compute how to clean it up.  See there?  I've done it again.

Well, it's about bedtime (I'm in Budapest for the next three days), so I better finish up and get some sleep.

Friday, July 10, 2015

Comparing Template Versions in CCDA

One of the things that I'm doing right now is working on examples for C-CDA 2.1.  To evaluate these examples, I'm running them through both the 1.1 and 2.1 schematons produced by Trifolia, as well as a couple of other validators.  Sometimes the validators don't agree, as I've discussed previously.

To better address the compatibility issues and to verify that what I have is correct, I wanted to be able to compare requirements side by side.  So, I build an XSLT stylesheet to compare the output from Trifolia for two different template versions.  Here's how it works:

It processes an XML file containing the old XML Template in the format produced by Trifolia.  It accepts one parameter, the name of the new IG XML file (in that same format) to compare it to.  For each template in the input file, it attempts to find a matching template in the new IG, perhaps with a new version.  If there is no new version, it doesn't do anything.  If there is, it produces a table comparing the two templates.

The table displays the template metadata (IG Name, Title, Identifier, Version, Publication Status, Template Type, Open/Closed Status, Context, Previous Version, and Description).  If differences are found, the metadata name cell is highlighted in gray.

Then it traverses all the constraints within either template, sorted by context, and simply compares the narrative of each constraint, ignoring minor differences due to CONF: statement numbering in its comparison.  If a difference is found, it highlights the context cell with a background color of red, yellow or green depending on whether the original constraint was SHALL, SHOULD or MAY.

What appears below is a sample of the output.  There's still a bug or two in this, in that when two constraints apply to the same context (entryRelationship), the code doesn't correctly deal with that.  I have some work to do there yet.  When I get around to fixing that, I'll post the stylesheet.  You can see a sample of the output below.

This has proved to be very useful in comparing the CCDA 1.1 and 2.1 templates.  I wish I'd had the time to do this when we started on the compatibility work a few months back, as it would have made my life a lot easier.  However, I hadn't at that time figured out how to get a good comparison.  That's probably because I wasn't thinking about how a minimally viable comparison might work.  Now that I have that, I can actually get an even better comparison with a bit more work.

   Keith

US Realm Header

FeatureOriginalNew
IGConsolidationConsolidation V3
titleUS Realm HeaderUS Realm Header (V3)
identifier2.16.840.1.113883.10.20.22.1.12.16.840.1.113883.10.20.22.1.1
version2015-08-01:
publishStatusPublishedDraft
templateTypedocumentdocument
isOpentruetrue
contextTypeClinicalDocumentClinicalDocument
PreviousVersionUS Realm Header (V2) (urn:hl7ii:2.16.840.1.113883.10.20.22.1.1:2014-06-09)
DescriptionThis section describes constraints that apply to the header for all documents within the scope of this implementation guide. Header constraints specific to each document type are described in the appropriate document-specific section below.This template defines constraints that represent common administrative and demographic concepts for US Realm CDA documents. Further specification, such as ClinicalDocument/code, are provided in document templates that conform to this template.
ClinicalDocument/realmCodeSHALL contain exactly one [1..1] realmCode="US" (CONF:16791).SHALL contain exactly one [1..1] realmCode="US" (CONF:16791).
ClinicalDocument/typeIdSHALL contain exactly one [1..1] typeId (CONF:5361).SHALL contain exactly one [1..1] typeId (CONF:5361).
ClinicalDocument/typeId/​@rootThis typeId SHALL contain exactly one [1..1] @root="2.16.840.1.113883.1.3" (CONF:5250).This typeId SHALL contain exactly one [1..1] @root="2.16.840.1.113883.1.3" (CONF:5250).
ClinicalDocument/typeId/​@extensionThis typeId SHALL contain exactly one [1..1] @extension="POCD_HD000040" (CONF:5251).This typeId SHALL contain exactly one [1..1] @extension="POCD_HD000040" (CONF:5251).
ClinicalDocument/templateIdSHALL contain exactly one [1..1] templateId (CONF:5252) such that itSHALL contain exactly one [1..1] templateId (CONF:5252) such that it
ClinicalDocument/templateId/​@rootSHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.1.1" (CONF:10036).SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.1.1" (CONF:10036).
ClinicalDocument/templateId/​@extensionSHALL contain exactly one [1..1] @extension="2015-08-01" (CONF:32503).
ClinicalDocument/idSHALL contain exactly one [1..1] id (CONF:5363).SHALL contain exactly one [1..1] id (CONF:5363).
ClinicalDocument/codeSHALL contain exactly one [1..1] code (CONF:5253).SHALL contain exactly one [1..1] code (CONF:5253).
ClinicalDocument/titleSHALL contain exactly one [1..1] title (CONF:5254).SHALL contain exactly one [1..1] title (CONF:5254).
ClinicalDocument/effectiveTimeSHALL contain exactly one [1..1] effectiveTime (CONF:5256).SHALL contain exactly one [1..1] US Realm Date and Time (DTM.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.4) (CONF:5256).
ClinicalDocument/confidentialityCodeSHALL contain exactly one [1..1] confidentialityCode, which SHOULD be selected from ValueSet HL7 BasicConfidentialityKind urn:oid:2.16.840.1.113883.1.11.16926 STATIC 2010-04-21 (CONF:5259).SHALL contain exactly one [1..1] confidentialityCode, which SHOULD be selected from ValueSet HL7 BasicConfidentialityKind urn:oid:2.16.840.1.113883.1.11.16926 STATIC (CONF:5259).


Thursday, July 9, 2015

Criticality vs. Severity in Allergies in HL7 CCDA

The HL7 Structured Documents workgroup had on its agenda to discuss updates to C-CDA 1.1 and 2.1 to address Allergy Criticality and Severity.  I first mentioned this problem at the end of last month.

Today, we discussed this in committee and with John Quinn, the HL7 CTO (who must approve errata), and agreed to address this issue as errata in the CCDA 2.1 DSTU Update project.  Once again, HL7 has shown that they can be responsive in addressing a critical issue.  I'm pleased to see this, and can only hope that we don't wind up being so responsive that we need to institute  Bureau of Sabotage.

Effectively what we will be doing in CCDA 2.1 DSTU Update project is create a new template to support criticality, and deprecating use of Severity template on the allergy itself.

   -- Keith


For those who aren't familiar with the issue, I will reproduce the important content below:

The stated project need for SDWG project 1014 is “Proposed US federal regulation has identified C-CDA 2.0 as being the preferred way forward, but introduces a need for compatibility that was not anticipated for in the original project scope.  An update is needed to ensure that new templates are backwards compatible.

Existing Consolidated CDA (C-CDA) needs to be enhanced by adding templates to represent priority data elements, and modified/new section level and document level templates needed for transitions of care and care plans, areas essential to patient care and the meaningful use of EHRs; we need to incorporate errata; and we want to address areas that implementers have found to be ambiguous.”    Patient Care is a co-sponsor of this project originally approved in 2013.  The TSC approved the updated project scope statement on June 9, 2015. 

The Patient Care Work Group (PCWG) has been working on the Allergy and Intolerance topic to update and harmonize standards since 2010.  The products related to this work include an Allergy and Intolerance Domain Analysis Model, Allergy and Intolerance Clinical Models (DSTU) and an Allergy and Intolerance FHIR resource.  In order to ensure harmonization across HL7 standards, the Patient Care WG conducted an extensive review of C-CDA R1.1 and R2.0.  During this review, the PCWG presented on-going issues to the SDWG at two face-to-face sessions (most recently at the Paris WG meeting) in order to reinforce the findings and recommendations of this year-long analysis of known C-CDA issues.  The results of this analysis were posted as DSTU comments for C-CDA R1.0 (Comment 643) and C-CDA R2.0 (Comment 644).   At the request of the SDWG, multiple comments were submitted against each C-CDA version in tabular format.  This summary document can also be found on the Patient Care wiki: C-CDA Harmonization Table.

The Issue

Patient Care has kept the SDWG apprised of work in the area of Allergies and Intolerances since this work began in 2010.  Multiple presentations on this topic were given at each Work Group meeting (see minutes from each joint PCWG/SDWG Thursday Q2).  As the PC WG harmonization process continued, it was apparent that the C-CDA did not recognize some of the concepts within the PCWG DAM or clinical models, or the FHIR allergy and intolerance resource.  Working with a primary representative and additional representatives from the SDWG, the PCWG has diligently outlined and proposed solutions to ensure harmonization all of the HL7 products that address allergies and intolerances.  This has included extensive terminology work in coding systems including HL7, SNOMED CT and LOINC. 

Extensive comments and recommendations were posted to the DSTU website for both C-CDA R1.1 and R2.0, with the expectation that these comments would be duly considered during the current review of errata and backwards compatibility issues.  Comments from the PCWG are substantive and seek to ensure that the use of C-CDA provides clinically correct data exchange between providers. 

On Thursday, June 25, the Patient Care WG presented a synthesis of these comments to the SDWG.  The most significant issue at hand relates to the use of the Severity Template in two contexts related to the Allergy and Intolerance Observation and the Reaction Observation. 

The current relationship of the Severity Template is shown in this diagram taken from C-CDA R1.1.  This relationship is retained in R2.0:  The relationship between the allergy observation and severity is erroneous, is creating confusion through ambiguity and does not reflect the current relationships in other HL7 allergy and intolerance standards.


The PCWG Allergy and Intolerance DAM and Clinical Models as well as the FHIR resource have a different relationship. 


A reaction is correctly described by severity, e.g. a patient had a mild reaction to a drug, or a severe reaction to a food.  However, the allergic condition is not described in terms of severity, rather the term criticality.  The concept of criticality is in the RIM as the code “CRIT”[1] in ActCode/ObservationType, and is associated with the allergic or intolerant condition. 

The definition of criticality as per the PCWG is as follows:  A clinical judgment as to the worst case result of a future exposure (including substance administration). When the worst case result is assessed to have a life-threatening or organ system threatening potential, it is considered to be of high criticality.

It is important to note that there is not a 1:1 relationship between the severity of a reaction and the criticality of the condition.  For example a patient might have a severe reaction to a medication (nausea) however that condition has a low criticality – e.g. the medication can still be prescribed if medically indicated.  Conversely, a child may have a mild reaction on the first exposure to a peanut, however a repeat exposure to peanuts may be life threatening and therefore of high criticality.

After the presentation by the PCWG on June 25 to the SDWG, the group discussed the issues at hand for some 30 minutes.  Despite an acknowledgement of the issues, no resolution was proposed nor voted on by the SDWG. 

Patient Safety and Clinical Practice

The PCWG has many other DSTU comments – however, we are writing to ensure that the criticality concept is included without delay in the C-CDA templates. 

Currently the use of severity in the context of a reaction and also in the context of a condition has the following potential consequences in systems exchanging information on allergies and intolerances:

1.      Patient safety issue:  When a system reports an allergic or intolerant reaction with mild severity but which is associated with a condition of high criticality (e.g. the risk of a life threatening reaction), based on severity alone a receiving system could allow an order to be processed for a drug or medication that should not be prescribed.  The current construct in the C-CDA does not capture or convey the correct information to mitigate this risk.
2.      The current construct does not allow for the most effective treatment:  A patient may report a severe reaction to a medication, such as “severe nausea” – however, nausea in most cases is of low criticality. A similar example is the common reaction to epinephrine (adrenaline) where most patients would describe their nausea, vomiting and sweating as severe – but if adrenaline is clinically indicated, it will be prescribed.   The current C-CDA construct is unable to correctly convey this information.
3.      Alert fatigue:  Clinicians often complain of alert fatigue, including for alerts for the severity of an allergic condition, since it is a spurious concept.  Given the documented drug-allergy alert override rate of around 90%[2], the use of criticality will clearly convey issues that require a careful consideration of the clinical options. 

In addition to the DSTU comments prepared by the PCWG, the C-CDA R2 ballot comments included a comment on the use of severity in two contexts.  The reconciliation spreadsheet for the 2013 ballot (Comment 290) noted under the disposition that SDWG would consult with the Allergy and Intolerance DAM.  However the final disposition reads as follows:   "In CCD.xml, add commenting [sic] which relates to the description in the severity template: ""When the Severity Observation is associated directly with an allergy it characterizes the allergy. When the Severity Observation is associated with a Reaction Observation it characterizes a Reaction."  This statement is incorrect, and it is unfortunate that the use of criticality (a concept currently existing in the RIM) was not considered. 

The C-CDA R2.1 Project

SDWG is considering candidate errata for C-CDA 2.1, a project designed to ensure backwards compatibility from R2.0 to R1.1 based on considerations related to the Meaningful Use 3 NPRM.  The project wiki is here: http://wiki.hl7.org/index.php?title=Consolidated_CDA_R2.1_DSTU_Update and the need for the project opinion is here: http://motorcycleguy.blogspot.com/2015/05/tell-onc-to-use-ccda-21-for-stage3-2015.html

What are errata?

The SDWG has discussed what errata are: (the post is the opinion of the author) http://motorcycleguy.blogspot.com/2013/03/defining-errata.html

The Chicago Manual of Style defines errata as follows: "Errata, lists of errors and their corrections, may take the form of loose, inserted sheets or bound-in pages. An errata sheet is definitely not a usual part of a book. It should never be supplied to correct simple typographical errors (which may be rectified in a later printing) or to insert additions to, or revisions of, the printed text (which should wait for the next edition of the book). It is a device to be used only in extreme cases where errors severe enough to cause misunderstanding are detected too late to correct in the normal way but before the finished (book) is distributed. Then the errors may be listed with their locations and their corrections on a sheet that is tipped in, either before or after the book is bound, or laid in loose, usually inside the front cover of the book.
Reference:  Chicago Manual of Style:  (referenced June 28, 2015) http://www.chicagomanualofstyle.org/home.html

Is the issue of criticality an erratum?  The PCWG feels that the omission of the criticality concept is of sufficient gravity to qualify as an erratum that must be considered in the current C-CDA 2.1 process.  The risk of not dealing with the criticality issue at this time is that the Meaningful Use 3 standard will point to a version of the C-CDA that is clinically incorrect and has the potential to cause patient harm. 

The PCWG understands the alacrity with which the errata process must occur to meet federal timelines.  The current timeline for C-CDA DSTU errata review is due to begin on July 1 and end on July 10th, 2015.  While the HL7 Governance and Operations Manual describes the process for submission of DSTU errata to the HL7 CTO, the PCWG appeals to the HL7 SDWG to duly consider this request prior to finalizing C-CDA 2.1 comments through the DSTU errata process.  Normally such an activity would be balloted allowing for broad member comment. 

Outcome Requested

The C-CDA is cited as the means to support health information exchange within the NPRM[3] for MU 3.    HL7 needs to ensure that the information exchanged is correct, based on current standards such as the RIM, and responsibly mitigates the risk of ambiguous and clinically incorrect information. The Patient Care WG respectfully requests that the concept of criticality be added to the C-CDA standard as an erratum because of the risk of patient harm. 

While the addition of a criticality template to C-CDA would be the most complete solution to this issue, there are several other paths forward:
1. At a minimum: Change the incorrectly referenced severity template to SHOULD NOT at the Allergy Intolerance Observation level.
2. If possible: Add a MAY conformance to the Allergy Intolerance Observation that permits use of the Criticality Observation.

The PCWG stands ready to assist with this endeavor. 

Respectfully submitted by the Patient Care WG Allergy and Intolerance Project Team,




[1] The current RIM definition of criticality is: CRIT (criticality) An observation representing a clinical judgment as to the worst case result of a future occurrence or the evolution of a current occurrence. It would be based on the severity of past occurrences, the details of what produced the past occurrences and the life-threatening or organ system threatening potential of the observation type.  The PCWG has a harmonization request pending to update this definition. 
[2] Bryant, AD, Fletcher, GS, Payne, TH.  Drug Interaction override rates in the Meaningful Use era – no evidence of progress.  App Clin Infor 2014:5(3);802-813 http://www.ncbi.nlm.nih.gov/pubmed/25298818


Tuesday, July 7, 2015

How Good it your CCDA Validator

I'm presently evaluating the HL7 C-CDA DSTU 2.1 update.  I'm doing it by way of updating the DSTU 2.0 sample files to conform to DSTU 2.1.  Along the way I've been testing my samples against both the 2.1 specification, and the 1.1 specification which it is to be backwards compatible with.

I have various validation tools for 1.1.  There's the Schematron produced by Trifolia, the TTT testing tool used for Meaningful Use, and the SITE Tool, as well as Josh Mandel's SMART CCDA Scorecard, and if I dug around hard enough, I could probably also find an Art Decor based validator.

Each one of these provides overlapping results.  Some are more up to date that others with HL7 Errata.  I'm still finding bugs with each of these so far.

One of the challenges that we have as an industry is that there is no single authority on what is a valid CCDA.  It should be HL7, but since ONC oversees the Certification program, and NIST develops the tools for that program, we have three different validators with slightly different ideas about what is a valid CCDA 1.1 document.

The validators are of varying quality with respect to how they work.  The Schematron-based tools are my favorite, simply because those tools are the most transparent about what they are testing.  None of the validation tools does a great job of taking me back to the source of truth used, although I can readily go from Conformance identifier back to the related specification.

I guess I'm spoiled by some of the W3C validators I've used, which link me directly to the conformance requirements in the standard.  Until we get an HTML version of CCDA, we won't be seeing that.  But hopefully that can be something that is produced sooner rather than later.

   Keith

Monday, July 6, 2015

The Economics of Healthcare Conferences

I've read a number of recent blog posts recently complaining about the lack of access patients have to various healthcare conferences.  The economics don't work, either for the patients, or for the organizers.  For most people who go to conferences, their employer gets a lot of value out of them going, and so is willing to cough up thousands of dollars worth of travel expenses and conference fees. But patients don't have that sort of support, and are often giving more then they are getting in terms of value.

That value, while immeasurable, is also unmeasureable, and so conference organizers have a hard time comping patients, or even making for an affordable entrance price.  The challenge for those patients who want to be engaged is that while they want to be part of the conversation, the value proposition for their entry hasn't been made adequately.  There has to be adequate value given for value received.

In part, I think that is because the business of healthcare has largely ignored the patient.  What are more important are the employers, the payers, the big providers, and yes, the vendors, who all make money off the Healthcare market.  And for conferences, it's all about how to make more money, isn't it.  And we know patients aren't the ones footing the bill, right?

We need a different economic model overall for healthcare in this country, but until we have one, I think we are going to be stuck with this story.  At least until someone comes along and figures out how to make a buck off having patients at their conference.

   Keith

P.S.  Unless a smart patient can figure out how to make the economics work for both parties.

Wednesday, July 1, 2015

CCDA 2.1 DSTU Update Available for Comment

I was quite please to see this cross my desk this afternoon.  It is the announcement of the request for comments on the C-CDA 2.1 DSTU Update.  As you may recall, this project was initiated at the May working group meeting.  We are now at the first of July, some six weeks after we initiated this project, and have knocked down our third duck (there are about three more to go).  We've done our best to make sure that there is plenty of time to get this into the Meaningful Use Stage 3 regulation, and now it is time for HL7 members to do their part.  Please have a look at the new material and provide your comments before July 13th.

   Keith


Hello,

The Consolidated CDA R2.1 DSTU update is available for member review.


SDWG will follow the review process outlined here: http://wiki.hl7.org/index.php?title=C-CDA_R2.1_Comment_Submission

Comment submission deadline: 7/13/2105 11:59 PM ET
Updates open for comment are identified by yellow highlighting.
·         Volume 1 - If the heading is highlighted, the entire section is open for comment.
·         Volume 2 - The specific conformance statements updated are highlighted. Templates that are only updated to reference a contained template that have been versioned (extension="2015-08-01") are not open for comment. Figures with updated conformance statements are open for review.

There are 3 methods to find edits:
2.     High-level change-log in Volume 1 (page 43)
3.     Excel comparison files (CDA R1.1 vs 2.0 Reviews) included in the review zip

All 3 methods should bring a reviewer to the same changes. Comment submission deadline: 7/13/2105 11:59 PM ET

Note, several R1.1/R2.0 errata are fixed in this release  -- all marked with 8/1/2015 (C-CDA R2.0/2.1) on our DSTU comments page (R1.1 / R2.0). SDWG is developing an R1.1/R2.0 errata summary which will be available prior to final publication of R2.1.

Best,
Brett

Brett Marquard
Principal
River Rock Associates

A Protocol for Interactive Services in FHIR

In developing Health IT software, it's fairly common to develop solutions that have to interact with interactive web sites.  When all that is needed is for those web sites to interact with a user, this is fairly easy to work out.  However, when the interaction also needs to communicate to the "back end" to convey the outcome of what the user did, it is a bit more complicated.

There are several use cases for this kind of interaction that I've seen in the past, and one that most recently came up in the context of the Guideline Appropriate Ordering profile from IHE.

The first of the use cases is patient selection:
In this use case, a patient is registering or being admitted for care to an institution.  In this case, the patient name, date of birth, and gender are provided at the time of registration.  One or more pre-existing patient records are located by the system.
The user has a few choices:

  1. Select and confirm the appropriate record (if only one record is found, the selection step is skipped and that record is simply selected, if no records are found this option isn't available).
  2. The user can search again using different information.
  3. The user can create a new patient record.
  4. The user can cancel the registration process.

The second of these is document searching and viewing.  In this case, document search criteria are used to identify candidate documents.  Pretty much the same options are available to the user, with a different end result:

  1. They can select a particular document to view (If one document is found, it may be automatically selected; if no documents are available, this option isn't available).
  2. The user can search again using different criteria.
  3. The user can cancel (this use case doesn't have the create option).
The third of these use cases is clinical decision support on the appropriateness of the order.  In this case, the following options might be presented:
  1. The order might simply be approved, in which case the user may simply be asked to confirm the order details.
  2. The user might be asked for more information about the patient for whom the order is being made (e.g., for a MRI where the indication is headache, the CDS system might ask if this is the worst headache the patient has ever experienced).
  3. The order might not be approved, in which case the user may be requested to use a different service, or to override the CDS result.
  4. The user can cancel.
The previous may not seem to be obvious use cases, so I'll toss out another one that is pretty much accepted across the IT spectrum: User Authentication.  In this case, a user authenticates with an external system and the external system conveys a token back to the "back end" requesting the authentication.

For the IHE GAO Profile (the third use case above), we borrowed some design features from specifications that support authentication.  
  1. The client makes a request to an interactive service through a known (preconfigured or returned in some previous interaction).  It also passes in a URL to which the interactive session will be redirected when the server has finished interacting with the user.
  2. The interactive session continues as a normal web interaction.  
  3. When the server has finished interacting with the user, it passes back a redirection request using that URL, and some URL parameters to tell the page that it was redirected to what the status of the request was (canceled, completed, error, et cetera), and where to get the full details of the result.
It occurs to me that this could become a general pattern for interactive services that might be specified somewhere in an Implementation Guide.  What do you think?  Would this be a good pattern to specify for FHIR?  Or more generally?  What other features should be considered in this interactive framework?