Currently under discussion in the FHIR community is what to do with contained resources, and how they could be searched (or not). I argue that they should be able to be searched, and that FHIR should specify how they can be returned in a standard way, but also that NOT every FHIR conforming system need be able to search for contained resources. At present, to retrieve any type of contained resource in FHIR, you must perform a query that will return its container, and you cannot directly query the resource type of that resource. You can chain a query into the resource type, but you have to know then, the association between the container and the contained resource.
But not every system will know that, and it may not very well have ever been considered by the system designer. In analytics, the analytic engines often pick up some pretty strange associations in the data that they process. They completely ignore any notion of what you or I would consider to be elegant information system design. Even so, having found an association through analytics, now you want to be able to do something based on it. You might use the presence of a particular fact to drive some sort of decision support, perhaps a dashboard, or something else. So, you need to be able to get to instances of that fact without necessarily knowing the association.
"Wait!" You argue, "of course the analytics system knows the associations too." And so it does. For this design. But the association discovered could be an important trigger that works with other systems that work with similar, but not identical data. You find these sorts of associations published all the time in the medical literature: Presence of X leads to Y. So even the analysis may be from somewhere else. And you don't care about the container. You care about finding all the instances of resource X so that you can prevent Y, or treat Y, or even simply reward the behavior associated with X and its related resources. You might want to count all the Xs, or inspect them further to see if this case qualifies for some sort of intervention, or do something else with them. What you need to do is not particularly important, just that you need to do something with these things. So, if you cannot find a particular X, then you have data locked away that isn't all that useful.
Let's look at the mechanics of how this might be implemented:
Using an analogy, lets say you have a system representing people, drivers, cars, registrations, drivers, licenses, and a registration authority and a licensing authority. Each could be represented as a separate resource and might have a separate identity. And a road trip resource might have a destination, and be associated with driver, a car and the people who are its passengers.
But what do you do about the hitchhiker that you might need to keep track of for the road trip, but don't much care about later? In FHIR, you could create the hitchhiker as a contained passenger resource associated with the road trip. After all, outside of the context of the road trip, he doesn't much matter, but he should be listed as part of the resources associated with the road trip.
Now, as resources go, any person resource can be searched, and you can locate any person who has been on a road trip from Chicago to Milwaukee. Or can you? Actually you cannot. Because if John picks up a hitchhiker (Keith) for a road trip from Chicago to Milwaukee, and decides he doesn't care to track Keith as a person, he could just contain Keith as a person resource in the road trip resource using the passenger attribute of the road trip resource.
So far, so good. But now look at what happens when John goes to do some queries about how his car is being used. The way that FHIR works today, we would be able find all the drivers, all the road trips associated with the car registered in his name, but what he cannot find is all the passengers who have been in his car. That's fine, you say, we didn't care about that passenger enough to make it a full blow resource anyway. And there is some benefit here, because you don't have to return that contained passenger as a resource.
BUT: What happens when you query for road trips? The query specification says that you are permitted to support chaining of queries across associations. So John could arguably query for a road trip where Keith was listed as a passenger. But he could not query for passengers named Keith who have been on road trips with him and get that one where Keith was listed as a contained resource. So even though the contained resource couldn't be returned, it still needs to be indexed so that the chained search works right.
Implicitly, you can view a containment as a particular kind of association (an aggregation). The container had the contained resource embedded within it. And the contained resource has this implicit association with one and only one container. So what if we said that "_container" acted as if it was an attribute on the Any resource that resolved to the resource that held a contained resource. If we did that, we could resolve a lot of challenges with search on contained resources.
If you wanted to search for resources that were only contained, you could do that by ensuring that _container was valued. If you wanted to search for resources that were not contained, you could do that by ensuring _container was not valued. If you wanted to search for resources that were contained by a resource of a particular type, you'd use _container:ResourceType, just as you would for other associations.
The mechanics of how this would work are pretty clear, and for those use cases for when you want to access "contained" resources, now you have a way to specify that they be present in the search results. For a contained resource, you could ask to _include resources that appear along the _container association. If I lost you, let me put it this way. When John goes to search for people who have been on road trips in his car, he can say GET [base]/Person?_container:RoadTrip&_include=Person._container and he would get a bunch of Person resources, and where they were contained, he would get their containers (which would happen to include those Person resources)*.
Now, an analytics system that simply wants to keep track of what Keith is doing really doesn't care whether the activity is RoadTrip, or Sleeping. It just wants to find Keith and see what he is up to. It doesn't care about all the associations, it just needs to report to Keith's wife what he is doing. Now it can do so without any prior knowledge about how John is keeping track of what he does with Keith.
-- Keith
* Looking at this a bit more deeply, I can see that GET [base]/Person?_container:RoadTrip is pretty useless without the _include=Person._container. I'm not sure where to go with that. We could determine that use of _container required _include, we could make that automatic, or we could come up with something else. For now, I'm not really worried about it, since it doesn't much matter for the immediate discussion.
Wednesday, October 29, 2014
Saturday, October 25, 2014
IHE Radiology Profile Selections
This comes to me via my colleague Chris Lindop (who is also IHE Radiology planning co-chair):
The IHE Radiology
Planning Committee has selected 3 profiles to develop for trial testing in 2016.
The proposal development work items selected are:
The first two of these I mentioned earlier today with regard to PCC planning. As you can see, this will be a coordinated effort between committees if all goes through.
Friday, October 24, 2014
2015-2016 IHE PCC Planning
IHE Patient Care Coordination, Quality, Research, and Public Health, and IT Infrastructure met the last two days to discuss profiles and work for the 2015/2016 development cycle. You can find the minutes of PCC's meeting here, as well as the final evaluation spreadsheet we will be passing on to the technical committee for their review.
I'll make a few comments on this year's work items:
Radiology and Patient Care Devices have some work they'd like PCC's help with. From the PCD perspective, one of these simply a matter of documenting existing PCD and Continua efforts in a profile so that it can be tested in Connectathon for Home Health Monitoring. Another would make it easier for medical devices to communicate with some EHR systems, supporting the exchange of PCD-01 messages to a "Semantic Bridge" (fancy way of saying: Interface Engine) to translate it from one form (HL7 V2.6) to another form (e.g., C-CDA or maybe even FHIR) that might be more digestible for some EHR systems.
On the Radiology side, they'd like to see Remote Reading Workflow, and support for CDS during the imaging ordering process. For the former, we are thinking about XDW-based workflow profile, perhaps combining with another submission (Basic Testing Workflow), and updating the referral workflow profile. For the latter, I'm thinking this is something like what QRPH has already done with RFD and CRD. Except in this case, instead of getting back a form, you also have the option of simply getting back a token that says that the imaging procedure is authorized based on the data provided. This would take the place of getting back a form that asks for information needed to verify that the procedure is warranted, and eventually, that "authorization" token might be returned.
Finally there is the DAF proposal. This one is challenging. The basic ask is that we prepare an implementation guide for S&I Framework, but this really isn't an IHE International profile proposal. So we are looking at putting together something like a template for developing such a guide in IHE PCC, and then having IHE USA fill it in. So there'd be some joint work, but not an IHE Profile per se. The template work might need to be addressed by the DCC (Domain Coordination Committee), with some help from PCC.
These are of course, just my opinions; this is still my sabbatical year from chairing anything.
Keith
P.S. There's also some IHE/HL7 work that I'm going to be proposing once that joint workgroup gets officially established, but we still have some work to do there. That's another blog post.
I'll make a few comments on this year's work items:
Radiology and Patient Care Devices have some work they'd like PCC's help with. From the PCD perspective, one of these simply a matter of documenting existing PCD and Continua efforts in a profile so that it can be tested in Connectathon for Home Health Monitoring. Another would make it easier for medical devices to communicate with some EHR systems, supporting the exchange of PCD-01 messages to a "Semantic Bridge" (fancy way of saying: Interface Engine) to translate it from one form (HL7 V2.6) to another form (e.g., C-CDA or maybe even FHIR) that might be more digestible for some EHR systems.
On the Radiology side, they'd like to see Remote Reading Workflow, and support for CDS during the imaging ordering process. For the former, we are thinking about XDW-based workflow profile, perhaps combining with another submission (Basic Testing Workflow), and updating the referral workflow profile. For the latter, I'm thinking this is something like what QRPH has already done with RFD and CRD. Except in this case, instead of getting back a form, you also have the option of simply getting back a token that says that the imaging procedure is authorized based on the data provided. This would take the place of getting back a form that asks for information needed to verify that the procedure is warranted, and eventually, that "authorization" token might be returned.
Finally there is the DAF proposal. This one is challenging. The basic ask is that we prepare an implementation guide for S&I Framework, but this really isn't an IHE International profile proposal. So we are looking at putting together something like a template for developing such a guide in IHE PCC, and then having IHE USA fill it in. So there'd be some joint work, but not an IHE Profile per se. The template work might need to be addressed by the DCC (Domain Coordination Committee), with some help from PCC.
These are of course, just my opinions; this is still my sabbatical year from chairing anything.
Keith
P.S. There's also some IHE/HL7 work that I'm going to be proposing once that joint workgroup gets officially established, but we still have some work to do there. That's another blog post.
Tuesday, October 21, 2014
JASON and the EHRnauts
I thought I was done with JASON and the EHRnauts for a little bit, when this query popped into my inbox via Will Ross over at Redwood MedNet. He points to this bit of wisdom:
From the report:
Here are some of the limitations of documents:
Now, as to the limits, all of these can be overcome, the question is who does it. The fundamental organization of data in an EHR around information documented during an encounter isn't likely to change whether you look at a large grained document-centric approach, or a finer-grained data item-centric approach.
You'll only ever be able to find information that has been gathered, or the fact that it hasn't been gathered. The document based approach means that you need to look at several documents to determine that for a time period, a finer grained approach means that the system you ask for that information must look at all data items in that time period.
You will always have to have some idea about what you want to ask for. In the document-centric approach, that can be based on document metadata such as who, where, what or when. Those questions are often asked at the first level of the physician's workflow in their search for more information. Finer-grained approaches will allow more detailed questions to be addressed that come later in the evaluation of the patient: Did they have this test? If so what were the results? Was ____ ruled out? When was the last time ___?
When dealing with multiple facts over time, you will have to deal with redundancy, ambiguity and disagreement. It is quite possible in an EHR today to have one physician assert something, and another deny that same thing, and both may be correct, or they may conflict. This is true regardless of whether the data items are accessed through coarse- or fine-grained mechanisms. Documents increase the degree to which this occurs because of the wholeness principle, you get all of the relevant data about the encounter, not just a few small pieces of data. But you should be able to readily resolve those issues, because you will always have them to deal with as soon as you have multiple data sources. Documents just make that problem visible sooner, because each document can be (and often is) treated as a single data source, whereas it only shows up in fine-grained access mechanisms once you have more than one data source.
The key issue is that some folks want to get right down into the computer automation of tricky bits, which means that they often don't want what they consider to be the excess baggage of documents. Agreed, we need a better way, and the industry is working on it.
I also love it when I hear "lock in", because frankly, when something better comes along, people will use it, regardless of what the government says or does (consider how mobile has driven healthcare). In most cases, the best thing it can do is get itself out of the way ;-)
To say (as the JASON Task Force does) that "There is currently no industry- or government-led plan or effort focused on ubiquitous adoption of standardized Public APIs." is technically correct. But let me ask you, where was the plan to adopt HTTP and HTML and CSS for the World Wide Web? XML and Schema? MIME and SMTP and POP for eMail? If anywhere, it was in the minds of the creators of those standards and the implementers. There was no government program driving adoption.
Right now, HL7, CDISC, DICOM, IEEE, OpenEHR, and IHE have all rallied around FHIR as the way forward for a variety of different use cases (see for example IHE's Mobile Access to Health Documents effort). Major vendors, national programs, industry consortia, and other organizations have publicly announced support for FHIR in products, programs and services currently being developed. This kind of thing is nearly unprecedented in health care. To come upon if after the fact and try to impose some US federally crafted plan to make it happen is just a bit ambitious don't you think? After all, it worked so well the last time with Direct.
My advice is to tread carefully, as ONC has already been doing. Offer support and assistance, encourage communication among different groups, maybe even fund some development. However, I think HHS needs to avoid the arrogance of thinking that it could plan this much better than is already occurring naturally in the industry.
I leave you with these thoughts: The Web took about five years to be widely used, and another five to really mature. FHIR has been with us for a bit more than two years. Rather than asking whether we can we afford to wait, consider if it will be worth it to rush. It won't be too much longer.
-- Keith
P.S. I was very impressed with the JTF report. It was a very thoughtful response to the original work.
From the report:
To the extent that query capabilities are included in MU Stage 3, we are at an awkward moment in standards development: Older standards such as XDS/XCA are mature but inherently limited, whereas newer API-based standards are not yet ready for large-scale adoption. We believe it would be detrimental to lock the industry in to older standards, and thus, we recommend that ONC mobilize an accelerated standards development process to ready an initial specification of FHIR for certification to support MU Stage 3.I love it when people raise the point about limits, without delving into what those limits are. It always sounds so authoritative. Yes, documents are limited.
Here are some of the limitations of documents:
- You can only operate on what appears within documents.
- You have to have some idea about which documents you want.
- When dealing with multiple documents, you have to deal with redundancy and ambiguity.
- Documents are coarser grained than some problems want to deal with.
- A document can be operated on by a human using very little technology (Human Readability), or by a computer.
- Documents link each fact reported to an encounter or visit, a healthcare provider and and institution (Context).
- A document provides the complete record of the encounter or visit, not just individual parts that can be interpreted out of context (Wholeness).
- The content of a document can be retrieved at any point in time in the future in a way that is repeatable (Persistent).
- A document links data to the organization that gathered, uses and manages it (Stewardship).
- A document can be signed by a healthcare provider (Potential for Authentication).
Now, as to the limits, all of these can be overcome, the question is who does it. The fundamental organization of data in an EHR around information documented during an encounter isn't likely to change whether you look at a large grained document-centric approach, or a finer-grained data item-centric approach.
You'll only ever be able to find information that has been gathered, or the fact that it hasn't been gathered. The document based approach means that you need to look at several documents to determine that for a time period, a finer grained approach means that the system you ask for that information must look at all data items in that time period.
You will always have to have some idea about what you want to ask for. In the document-centric approach, that can be based on document metadata such as who, where, what or when. Those questions are often asked at the first level of the physician's workflow in their search for more information. Finer-grained approaches will allow more detailed questions to be addressed that come later in the evaluation of the patient: Did they have this test? If so what were the results? Was ____ ruled out? When was the last time ___?
When dealing with multiple facts over time, you will have to deal with redundancy, ambiguity and disagreement. It is quite possible in an EHR today to have one physician assert something, and another deny that same thing, and both may be correct, or they may conflict. This is true regardless of whether the data items are accessed through coarse- or fine-grained mechanisms. Documents increase the degree to which this occurs because of the wholeness principle, you get all of the relevant data about the encounter, not just a few small pieces of data. But you should be able to readily resolve those issues, because you will always have them to deal with as soon as you have multiple data sources. Documents just make that problem visible sooner, because each document can be (and often is) treated as a single data source, whereas it only shows up in fine-grained access mechanisms once you have more than one data source.
The key issue is that some folks want to get right down into the computer automation of tricky bits, which means that they often don't want what they consider to be the excess baggage of documents. Agreed, we need a better way, and the industry is working on it.
I also love it when I hear "lock in", because frankly, when something better comes along, people will use it, regardless of what the government says or does (consider how mobile has driven healthcare). In most cases, the best thing it can do is get itself out of the way ;-)
To say (as the JASON Task Force does) that "There is currently no industry- or government-led plan or effort focused on ubiquitous adoption of standardized Public APIs." is technically correct. But let me ask you, where was the plan to adopt HTTP and HTML and CSS for the World Wide Web? XML and Schema? MIME and SMTP and POP for eMail? If anywhere, it was in the minds of the creators of those standards and the implementers. There was no government program driving adoption.
Right now, HL7, CDISC, DICOM, IEEE, OpenEHR, and IHE have all rallied around FHIR as the way forward for a variety of different use cases (see for example IHE's Mobile Access to Health Documents effort). Major vendors, national programs, industry consortia, and other organizations have publicly announced support for FHIR in products, programs and services currently being developed. This kind of thing is nearly unprecedented in health care. To come upon if after the fact and try to impose some US federally crafted plan to make it happen is just a bit ambitious don't you think? After all, it worked so well the last time with Direct.
My advice is to tread carefully, as ONC has already been doing. Offer support and assistance, encourage communication among different groups, maybe even fund some development. However, I think HHS needs to avoid the arrogance of thinking that it could plan this much better than is already occurring naturally in the industry.
I leave you with these thoughts: The Web took about five years to be widely used, and another five to really mature. FHIR has been with us for a bit more than two years. Rather than asking whether we can we afford to wait, consider if it will be worth it to rush. It won't be too much longer.
-- Keith
P.S. I was very impressed with the JTF report. It was a very thoughtful response to the original work.
Friday, October 17, 2014
Take as Written
One of the requirements for the HITSP C32 as specified by AHIP was that a medication entry provide the free text sig. That specification met the requirement by indicating that it could be found in the <text> element of the <substanceAdministration> element. This has resulted in implementation confusion because some feel that it meant that ONLY the sig should appear in substanceAdministration/text, and others felt that it could be part of it, but that it could also include the medication and other details (such as preconditions or other cautions or instructions like take with food).
The latter interpretation is what the HL7 RIM specifies should appear in the medication template's substanceAdministration/text element. Some systems want access to just the sig, and cannot determine where it begins or ends in the medication template. So Structured Documents is now working on a new template that can be used within the Medication template to show JUST the sig. Rick Geimer and I have been tasked with coming up with a proposal.
Here's essentially the proposal that we discussed on the SDWG call yesterday. We add a new template called "Medication Free Text Sig" (or some similar name) which provides the free text sig component of the medication. This template becomes a recommended component of the substanceAdministration template now, and perhaps becomes required in future editions of C-CDA. It looks something like this:
<section>
<text>
<paragraph ID='med-1'>
<content ID='medname-1'>Amlodipine-Benzapril 2.5-10mg</content>
<content ID='sig-1'>one capsule daily</content>
</paragraph>
</text>
...
<entry>
<substanceAdministration classCode='SBADM' moodCode='INT'>
<text><reference value='#med-1'/></text>
...
<consumable typeCode="CSM">
<manufacturedProduct classCode="MANU">
...
<manufacturedMaterial>
<code code="898352"
displayName="Amlodipine 2.5 MG/Benazepril hydrochloride 10 MG Oral Capsule"
codeSystem="2.16.840.1.113883.6.88" codeSystemName="RxNorm">
<originalText><reference value="#medname-1"/></originalText>
</code>
<name>Amlodipine 2.5 MG / Benazepril hydrochloride 10 MG Oral Capsule</name>
</manufacturedMaterial>
</manufacturedProduct>
</consumable>
...
<entryRelationship typeCode='COMP'>
<substanceAdministration classCode='SBADM' moodCode='INT'>
<code code='422096002' displayName='Take'
codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED-CT'/>
<text><reference value='#sig-1'/></text>
</substanceAdministration>
</entryRelationship>
</substanceAdmnistration>
</entry>
</section>
This component simply provides access to the free text content of the sig portion of the medication entry. Like the travel history section, certified EHR systems could start using a template like this today. Consider this my prescription for how to solve the problem.
-- Keith
The latter interpretation is what the HL7 RIM specifies should appear in the medication template's substanceAdministration/text element. Some systems want access to just the sig, and cannot determine where it begins or ends in the medication template. So Structured Documents is now working on a new template that can be used within the Medication template to show JUST the sig. Rick Geimer and I have been tasked with coming up with a proposal.
Here's essentially the proposal that we discussed on the SDWG call yesterday. We add a new template called "Medication Free Text Sig" (or some similar name) which provides the free text sig component of the medication. This template becomes a recommended component of the substanceAdministration template now, and perhaps becomes required in future editions of C-CDA. It looks something like this:
<section>
<text>
<paragraph ID='med-1'>
<content ID='medname-1'>Amlodipine-Benzapril 2.5-10mg</content>
<content ID='sig-1'>one capsule daily</content>
</paragraph>
</text>
...
<entry>
<substanceAdministration classCode='SBADM' moodCode='INT'>
<text><reference value='#med-1'/></text>
...
<consumable typeCode="CSM">
<manufacturedProduct classCode="MANU">
...
<manufacturedMaterial>
<code code="898352"
displayName="Amlodipine 2.5 MG/Benazepril hydrochloride 10 MG Oral Capsule"
codeSystem="2.16.840.1.113883.6.88" codeSystemName="RxNorm">
<originalText><reference value="#medname-1"/></originalText>
</code>
<name>Amlodipine 2.5 MG / Benazepril hydrochloride 10 MG Oral Capsule</name>
</manufacturedMaterial>
</manufacturedProduct>
</consumable>
...
<entryRelationship typeCode='COMP'>
<substanceAdministration classCode='SBADM' moodCode='INT'>
<code code='422096002' displayName='Take'
codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED-CT'/>
<text><reference value='#sig-1'/></text>
</substanceAdministration>
</entryRelationship>
</substanceAdmnistration>
</entry>
</section>
This component simply provides access to the free text content of the sig portion of the medication entry. Like the travel history section, certified EHR systems could start using a template like this today. Consider this my prescription for how to solve the problem.
-- Keith
Thursday, October 16, 2014
On a Process for Rapid Template Development
Recently a question crossed the Structured Documents Workgroup List about how to record information about a patient's recent travel. You can probably guess what recent media events motivated that question.
IHE had long ago developed a template for foreign travel, as part of XPHR. Since this section wasn't required in the HITSP C32, it was not further developed in C-CDA. However, that doesn't stop anyone from using it, even under Meaningful Use. The Foreign Travel template is simply a section containing a narrative description of travel. Narrative capture of travel history is what most EHR systems today support. This usually appears somewhere in the social history section of the patient chart, and is accessible to any provider caring for the patient in most EHR systems.
For cases of communicable disease, if you want the EHR to be able to apply clinical decision support to recent foreign travel, you would need coded entries, or natural language processing over the narrative. To code the travel information, you will need to do more in this section. The basic activity being documented is travel, and so you could readily capture that in an act, with location participants for each place visited.
<act classCode='ACT' moodCode='EVN'>
<code code='420008001' displayName='Travel'
codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED-CT'/>
<effectiveTime><!-- This might be optional, see participant/time below -->
<low value='Starting Date for Travel History'/>
<high value='Ending Date for Travel History'/>
</effectiveTime>
<participant typeCode='LOC'>
...
</participant>
</act>
The participant would represent the various locations visited during the time period described in the travel act. We need not go into the entity level since participant.role can capture what we need.
<participant typeCode='LOC'>
<time>
<low value='Starting Date for this Location'/>
<high value='Ending Date for this Location'/>
</time>
<participantRole classCode='TERR'>
<!-- This might be optional, and could identify locations using a value
set such as Geographic Location History -->
<code code='Code identifying location'
codeSystem='Code System for Locations (e.g., ISO-3166)'/>
<addr>
<city>...</city>
<county>...</county>
<state>...</state>
<country>...</country>
</addr>
</participantRole>
</participant>
We would probably want to constrain participantRole so that only one addr element was present (and was mandatory), and had at least one element of city, county, state or country. I would also recommend that country always be present, and that if city or county is present, that state also be present. For disambiguation purposes, you might need to know which of the twelve New London's in the US your patient was recently in.
Some have suggested that location could be rolled up into a code, as I have shown above in participantRole/code. While I agree that would make certain kinds of decision support easier, it is something that could be done within the clinical decision support module, rather than being specified within the EHR. The Geographic Location Value set referenced above shows why this might be a problem, as it contains codes describing locations at different levels.
So, now back to the main point. We quickly went through this model on the Structured Documents workgroup list service in less than three days. It would take us several months to role this out as a new template. We need a model of development and consensus building somewhat like what OpenEHR does for archetypes, allowing for quicker development and deployment of these sorts of artifacts. I also think that this is the way some of these templates should be developed in the future. We should develop a model that can be approved through a general call for consensus, and then periodically, we can roll up several of these templates into a release which gets a more thorough review through the HL7 ballot process.
This would allow HL7 to be responsive to rapidly developing health issues, without having to make it something that we have to panic about. Note that foreign travel is relevant only for some cases. There are plenty of other ways to be exposed to disease, including everyday activities like going to school or work, or shopping. For that you might want to be looking at other information in the patient health record, such as their home address, and workplace and school contacts. IHE also included entries for those contacts in XPHR.
-- Keith
IHE had long ago developed a template for foreign travel, as part of XPHR. Since this section wasn't required in the HITSP C32, it was not further developed in C-CDA. However, that doesn't stop anyone from using it, even under Meaningful Use. The Foreign Travel template is simply a section containing a narrative description of travel. Narrative capture of travel history is what most EHR systems today support. This usually appears somewhere in the social history section of the patient chart, and is accessible to any provider caring for the patient in most EHR systems.
For cases of communicable disease, if you want the EHR to be able to apply clinical decision support to recent foreign travel, you would need coded entries, or natural language processing over the narrative. To code the travel information, you will need to do more in this section. The basic activity being documented is travel, and so you could readily capture that in an act, with location participants for each place visited.
<act classCode='ACT' moodCode='EVN'>
<code code='420008001' displayName='Travel'
codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED-CT'/>
<effectiveTime><!-- This might be optional, see participant/time below -->
<low value='Starting Date for Travel History'/>
<high value='Ending Date for Travel History'/>
</effectiveTime>
<participant typeCode='LOC'>
...
</participant>
</act>
The participant would represent the various locations visited during the time period described in the travel act. We need not go into the entity level since participant.role can capture what we need.
<participant typeCode='LOC'>
<time>
<low value='Starting Date for this Location'/>
<high value='Ending Date for this Location'/>
</time>
<participantRole classCode='TERR'>
<!-- This might be optional, and could identify locations using a value
set such as Geographic Location History -->
<code code='Code identifying location'
codeSystem='Code System for Locations (e.g., ISO-3166)'/>
<addr>
<city>...</city>
<county>...</county>
<state>...</state>
<country>...</country>
</addr>
</participantRole>
</participant>
We would probably want to constrain participantRole so that only one addr element was present (and was mandatory), and had at least one element of city, county, state or country. I would also recommend that country always be present, and that if city or county is present, that state also be present. For disambiguation purposes, you might need to know which of the twelve New London's in the US your patient was recently in.
Some have suggested that location could be rolled up into a code, as I have shown above in participantRole/code. While I agree that would make certain kinds of decision support easier, it is something that could be done within the clinical decision support module, rather than being specified within the EHR. The Geographic Location Value set referenced above shows why this might be a problem, as it contains codes describing locations at different levels.
So, now back to the main point. We quickly went through this model on the Structured Documents workgroup list service in less than three days. It would take us several months to role this out as a new template. We need a model of development and consensus building somewhat like what OpenEHR does for archetypes, allowing for quicker development and deployment of these sorts of artifacts. I also think that this is the way some of these templates should be developed in the future. We should develop a model that can be approved through a general call for consensus, and then periodically, we can roll up several of these templates into a release which gets a more thorough review through the HL7 ballot process.
This would allow HL7 to be responsive to rapidly developing health issues, without having to make it something that we have to panic about. Note that foreign travel is relevant only for some cases. There are plenty of other ways to be exposed to disease, including everyday activities like going to school or work, or shopping. For that you might want to be looking at other information in the patient health record, such as their home address, and workplace and school contacts. IHE also included entries for those contacts in XPHR.
-- Keith
Wednesday, October 15, 2014
A Short and Sensual Sojourn
One day last week I took a ride on my motorcycle to pick up my daughter from school. Having recently moved into this rural neighborhood, I took to the back roads to explore. To ride is to be connected to the environment around you. The roads were narrow, winding and tree covered. Gleefully I followed them over to her school, absorbing all I could see, smell and feel. Combining the visuals of fiery fall foliage with the aroma of recent rain and fallen leaves, and the soft touch of cool fall air brushing by me, I almost reached a sensual nirvana. All too soon I arrived at my destination. After collecting my daughter, we reversed my original course back to our new home. She also marveled at our new surroundings. The more I explore this new place, the happier I am to have moved here. Why I made such a lifestyle shift was readily answered in a single and all too short ride, I realized, as I pulled into my space at the end of the driveway.
About this text: This was originally part of a homework assignment for my Scientific Writing class, which I then updated a bit. I enjoyed it and am still digging out of boxes, so there is no excess brain to write with for something else today. I promise there will be something with meat on it soon.
Thursday, October 9, 2014
Worth Waiting For
About 12 years ago I was to have given a sermon at my church. In planning for it, I asked our rector how long a sermon should be. He answered with this bit of wisdom: "It takes as long as it takes." Of course, he didn't realize I was asking about what I needed to do next week, and was thinking I was commenting on the length of his sermon that week. But the phrase stuck with me, and the next week, when he realized WHY I was asking, we had a good laugh over his non-answer.
It is now October 2014. This time last year HL7 was hurriedly trying to put the final pieces together for C-CDA Release 2.0, so that we could get it out in time for regulation. It's still not published yet, although it soon will be, and the reality is that we apparently didn't need it in such a hurry. Recent discussions on HL7 FHIR and the CDA and C-CDA on FHIR projects indicate that the dates for these don't all line up for the DSTU FHIR Ballot schedule. There's some discussion about whether or not we should delay it.
I for one am all for taking as long as it takes to do things right. I'm a bit tired of rushing stuff out to ballot to meet deadlines that were made by people who don't necessarily understand real world healthcare provider upgrade and deployment schedules. We have plenty of work to do, and the industry has gotten itself pretty convinced about the right way to go. Now we just have to convince folks that it will be worth waiting for.
Thus ends my sermon for this day...
Keith
It is now October 2014. This time last year HL7 was hurriedly trying to put the final pieces together for C-CDA Release 2.0, so that we could get it out in time for regulation. It's still not published yet, although it soon will be, and the reality is that we apparently didn't need it in such a hurry. Recent discussions on HL7 FHIR and the CDA and C-CDA on FHIR projects indicate that the dates for these don't all line up for the DSTU FHIR Ballot schedule. There's some discussion about whether or not we should delay it.
I for one am all for taking as long as it takes to do things right. I'm a bit tired of rushing stuff out to ballot to meet deadlines that were made by people who don't necessarily understand real world healthcare provider upgrade and deployment schedules. We have plenty of work to do, and the industry has gotten itself pretty convinced about the right way to go. Now we just have to convince folks that it will be worth waiting for.
Thus ends my sermon for this day...
Keith
Wednesday, October 8, 2014
Assumed Ignorant
My internet was down for about an hour yesterday. It could be readily traced back to a specific piece of hardware, and fortunately for me, I happened to have a replacement on hand that wasn't the same make and model that was causing massive internet outages all over the world. Even when I upgrade, I hardly ever throw anything away. I have at least three routers and a Hub sitting in my office, unused since they've been replaced with faster equipment. So, once I knew what the problem was, I dug out my old Netgear Wireless router, reset it to factory defaults, and plugged it in to get us limping back along until Belkin could fix whatever it messed up.
The tech at Charter couldn't explain to me what was wrong, only that it was a problem with the Belkin router. Belkin couldn't explain what was wrong, only that some software change had caused the problem. My bet is that the server at Belkin that the routers used to ping to determine that they really had Internet access were either down, decommissioned, or renamed.
In trying to work through the problem with my Internet tech support guy, I ran into a problem that patients (especially chronic ones) have with their doctors. I know more than your average Internet user about networking. By the time I've called the cable guy, I've gone through all the standard Tier 1 fixes, sniffed the network if necessary, and have a pretty good idea the problem is NOT at my end. I tried to explain that to this guy, but he didn't have ANY training about how to talk to a tech savvy customer. He only knows his scripts. I've had doctor's like that too, who try to dumb stuff down for me because "It's too complicated." I'd like to show them some of the code I've had to maintain in my life.
In any case, I wish there was something we could do about the attitude that customers or patients should be assumed ignorant until proven otherwise. I think that there are some basic skills, such as being able to reset your internet box, fill up your tank, change and flush your oil and coolant, throw a breaker, or understand our health, and the healthcare system (such as it is) that should be part of everyone's basic education. And I think the same thing goes for Physicians and technology!
When did assumed ignorant become the default, and why do we let people get away with it?
The tech at Charter couldn't explain to me what was wrong, only that it was a problem with the Belkin router. Belkin couldn't explain what was wrong, only that some software change had caused the problem. My bet is that the server at Belkin that the routers used to ping to determine that they really had Internet access were either down, decommissioned, or renamed.
In trying to work through the problem with my Internet tech support guy, I ran into a problem that patients (especially chronic ones) have with their doctors. I know more than your average Internet user about networking. By the time I've called the cable guy, I've gone through all the standard Tier 1 fixes, sniffed the network if necessary, and have a pretty good idea the problem is NOT at my end. I tried to explain that to this guy, but he didn't have ANY training about how to talk to a tech savvy customer. He only knows his scripts. I've had doctor's like that too, who try to dumb stuff down for me because "It's too complicated." I'd like to show them some of the code I've had to maintain in my life.
In any case, I wish there was something we could do about the attitude that customers or patients should be assumed ignorant until proven otherwise. I think that there are some basic skills, such as being able to reset your internet box, fill up your tank, change and flush your oil and coolant, throw a breaker, or understand our health, and the healthcare system (such as it is) that should be part of everyone's basic education. And I think the same thing goes for Physicians and technology!
When did assumed ignorant become the default, and why do we let people get away with it?
Monday, October 6, 2014
Life Flow
For the past few weeks I have been rearranging my life so that I could move. As we move into the new house, my family is redesigning our spaces and technology solutions to better fit our life. The kitchen is not just about making and eating meals, it is about breakfast, lunch and dinner. So now part of my kitchen is devoted to making the appliances accessible that we ALL use in the morning, from coffee maker to toaster oven to microwave in one part. While another part of the kitchen is devoted to more intense meal preparation for dinner done by one or two persons at a time.
My office which used to hold half our books now has over 90% of them. The internet router, telephone base station, and main printer, which used to be spread throughout the house are all right next to me so that the "hey Honey, why won't the printer print?" (Or wifi connect, or phone dial) question need not be shouted across half the house. I can watch the smoker outside from my desk. The exercise and entertainment centers can now be used together, synergistically.
There is so much stuff, we are still in the just get it out of boxes, get it to work stage in many places. We'll rough out the life flow as we do that, and then fine tune it as we find the problems (afte a coffee spill it was noted that we probably want the marble topped sideboard under the coffee pot rather than the oak topped one). This is real, rational and agile all at the same time. I wonder if there isn't a lesson to be learned from this for healthcare. Except that I don't know if most Physicians could live through the kind of chaos that roughing out and testing workflows would require.