Wednesday, August 31, 2011
When I was growing up I used to be able to ride my bike to the doctor's office and dentist's office in my neighborhood. While I might still be able to do so, I've seen few if any physician offices in neighborhoods anymore. They are still close by, but no longer really part of the community. My children don't go to school with my doctor's kids. Sometimes I do wish that life were simpler.
Oh well, at least I still get my milk from glass bottles.
The name element is used to contain the name of a person, be they provider, patient, emergency contact et cetera. There are several difficulties with names when they are exchanged. The first of these has to do with cultural variations in how names are "displayed". Related are differences in how a name is parsed into different parts by various cultures. Finally, there is the fact that the name element itself uses mixed content in the CDA Release 2.0 XML.
One of the "requests" of the Metadata ANPRM is a "display name" representation. This is already supported in CDA. If you take the name parts in the order presented, you have them in the correct display order. In Asian cultures, the family name is often given first, followed by the given name. CDA doesn't specify the order in which the name parts are provided, but the PN data type does have a virtual property which delivers the name formatted appropriately. The method by which the formatted name is extracted is given in the HL7 Data types specification. Actually a much easier way to get at is uses the XPath or XSLT string function. If $name is a variable containing the name element, normalize-space(string($name)) is an XPath or XSLT expression that will return the formatted name according to the HL7 rules for the PN data type. If you encode the name as shown in the examples this works just fine.
With regard to cultural differences in parsing, in the western world we often think of first, middle and last name. But the common features are that names are either given (first and middle), or are family names (maiden and last). Crossing between these two is sometimes a challenge. Women often use their maiden name as a middle name after marriage. So for them, the first given name is the first name, the first family name would be the maiden name, and the last family name would be the last name. But men usually don't change their name, so the first given name is the first name, the second given name is the middle name, and the first family name is the last name. Of course there are plenty of other variations. In order to be interoperable with systems that still think in this western-centric way, I tell people to simply place the middle name as the second given name. It makes it much easier, even if it isn't exactly correct.
The mixed model provides another challenge, because white space is significant. I need to examine the CDA Consolidation guide for how to represent names, because I think we recommended it not be present. That defeats the simple XPath/XSLT extraction of the formatted name. There are still ways to get at it by inserting the implicit white space through a very simple transform, but it isn't quite as clean.
Another request of the Metadata ANPRM is to provide a display name for searching purposes. The Entity Name data type (from which Person Name is derived) has a use attribute that can identify the name used for search purposes. The way to represent that is to add use='SRCH' to the name element.
Tuesday, August 30, 2011
In My SKIM of the Metadata ANPRM, I made the mistake of assuming it applied to Metadata used for Health Information Exchange. After all, the title is: Metadata Standards to Support Nationwide Electronic Health Information Exchange. In my SCAN of that document, I found this on Page 13:
As a feasible first step, the HIT Policy Committee suggested that ONC focus on facilitating the development and adoption of a minimal set of standards for metadata that could be “wrapped around” or attached to a summary care record when a patient seeks to download their health information from, for example, a health care provider’s patient portal or when a patient directs his or her health care provider to transmit his or her health information to a personal health record (PHR). Generally speaking, the term “metadata” is often used to mean “data about data” or, in other words, “data that provides more information or detail about a piece of data.”In the ANPRM, the standard identified for the purpose of downloading PATIENT SUMMARY data is CDA Release 2.0, and I can wholeheartedly support it for that purpose. In fact, the S&I Framework CDA Consolidation Project and Transfers of Care project both use the same standard to convey summary information. So no "wrapping" is even necessary.
There's more needed, (e.g., requirements on what must be present, and vocabulary), but this is a good first step. I'd suggest they look at what is already being done today (using the HITSP C32 Version 2.5) to fill in those gaps (see C83 page 27 Personal Information and C80 page 26 Personal Information)
Now that I understand what David McCallie was trying to tell us, I get it. Thanks David.
Monday, August 29, 2011
If you needed flashlights, gasoline powered chainsaws ( or other tools ), gas cans, you were out of luck in my neighborhood, but the nearby big-box hardware store did have generators amd some gasoline powered tools.
I know this not because I was looking, but because I ran into others for my short run for work gloves and pruning shears.
One thing it made very clear is that you need to test your emergency plans BEFORE you actually have to use them. Simulations and brainstorming are good ways to play the what if game.
Back to clearing the yard (all are safe here and there was no major damage).
My local electric company just called to tell us that some areas could be without power through the weekend! Glad that's not us.
Friday, August 26, 2011
Here's my checklist:
- Water and liquids: Have enough fluids for several days.
- Food: Same deal. Don't count on what you have in the refrigerator.
- Flashlights and batteries. You could be without power for some time. Make sure you have lighting. I also have an oil lamp and lots of candles.
- Power: I bought a backup generator a while back to deal with a local outage (car hit a transformer station). It gets tested out again today. I'll make sure I have fuel for it as well, because if there is no power, the local service stations won't be able to pump it. That will get my refrigerator and freezer through short outages without spoilage. Buying one now could be difficult, I'm glad to have one beforehand.
- Charge everything: Phones, rechargable tools, et cetera, and make sure you have a way to get information (a battery powered radio) if your power goes out.
- Fuel: Make sure your car is filled up, and that you have spare fuel also for any gasoline powered equipment you may need.
- Chainsaw: After the storm, you may need to clear downed trees or branches. If you don't own one, trying to buy one after the storm could be difficult.
- Masking Tape and Plywood. This storm won't be so bad (Category one), but its wind can still damage windows. Taping them prevents shattering, but won't keep them from breaking. Plywood can prevent flying debris from causing damage.
11:27 Update: My tree guy is on his way.
Thursday, August 25, 2011
One study concluded that there were 1.7 errors per patient day in America's ICUs. Of these errors, 29 percent could have caused significant harm or death.
He points out that the average stay is about 3 days. That means just over 5 errors. The chance of leaving the ICU without suffering from such an error means that you need need to succeed on five rolls on a pair of dice without rolling a 2, 3, 4 or 5. You'll manage that less than 1 time in five (about 18% of the time).
Many of us have seen informed consent forms. They list the significant risks of a surgical or diagnostic procedure. But what they don't do is list the actual chances associated with that risk.
What if, on being asked to consent to a procedure you were told:
Even better yet, it could use one of those pictures like Energy Star uses.
Wouldn't that actually say something relevant to patients and incent institutions and providers to do better?
Wednesday, August 24, 2011
Originally, it was going to cover ITI, Patient Care Coordination, and Quality, Public Health and Research domains. But, last week there were a number of questions about Patient Identification, and I hope we focus on what IHE has to offer in this space. IHE IT Infrastructure profiles support the following.
First, there is Patient Identity Cross Referencing (PIX). This profile is designed to allow an EHR or other Health IT system to integrate with a Master Patient Index using HL7 Version 2.3.1 and 2.5.1 messaging. If you know the ID of the patient in one domain, this profile allows you to find the ID of the patient in another domain.
Next there is Patient Demographics Query (PDQ). This profile allows you to search for patient identities based on patient demographics. You can locate all of the matching identities, or just those from a specific identity domain. This also uses HL7 Version 2, but this time, just 2.5.1 to support the queries. PIX/PDQ are rarely found implemented separately, but they are written as separate profiles.
A few other countries require the use of HL7 Version 3 messaging to access this information, so IHE created a HL7 Version 3 edition that has the same capabilities, called PIX/PDQ Version 3 (PIXV3 and PDQV3).
Identifying patients from one HIE who might have records in another is a more significant challenge. The Cross Community Patient Discovery (XCPD) profile builds off of the PIX/PDQ V3 work. It needs to use web services to perform the exchange for various reasons.
Finally, there is Patient Administration Management (PAM) which uses HL7 Version 2 to address general patient administration (ADT) messaging, which is where a patient identity usually enters the system.
One reason for the focus on Patient Identity is the ONC Advance Notice of Proposed Rulemaking on Metadata for Health Information Exchange. You can find my thoughts on that rule here, and an initial post and a more detailed on with answers from John Moehrke as well.
I look forward to your questions.
Tuesday, August 23, 2011
I will probably bring the topic up for the HL7 Coordination with Other SDO's panel session in September to see if there is something that could be done to improve the situation.
Several people this week were frustrated over ONC's scheduling of the Summer Concert Series, especially as it overlaps with the Public Health Informatics Conference in Atlanta, where most of the people that Query Health is supposed to serve are. There are no sessions here on what Query Health is. And the Finale of the Query Health summer concert series is being held when an important member of the desired audience is out of town for most of the week.
OK, now that I have that off my chest, I did have an interesting discussion about Query Health over a fantastic Omikase style dinner at MF Sushibar.
There are a couple of challenges with "sending the query to the data" which Query Health will need to address. The first challenge is scalability. The second is coordination. The third is overlap with reporting.
With regard to scalability, I can imagine the number of queries getting quite large. I don't think that it will be feasible to process a large number of queries if they aren't designed to be very efficient. There are some techniques that can be used to enable the system to operate linearly in the size of the records being queried, rather than on the number of queries being performed. But that means that the queries need to be aggregable, so that multiple queries can be run at the same time, sort of the way that the Unix egrep tool can very efficiently search for a number of strings. But that does mean that the queries need to be pretty simple to support the aggregation of them.
The second piece that needs to be addressed is coordinating results in a timely way. I don't see query health being used effectively for a national outbreak of H1N1. But I do see it being used in other ways. Even so, unless the query is truly computed the same way, there could be some challenges in interpreting the results. I'll give an example. In one case, HEDIS measures for one region in a state were way off. It appeared that Women weren't getting routine laboratory tests done that should have been. The problem was traced back to the fact that when test A was ordered, test B and C were done reflexively (automatically). But the measures were computed based on what was ordered, not on what was reported on. That variance in interpretation caused the results for one region to be so badly off that it was readily identified. But I suspect more subtle implementation decisions could wind up introducing other variances that are not so easily detectable. It needs to be looked out for. The key here is to ensure that the queries are simple enough that there can be no real differences in the results introduced by differences in implementation. Aggregation is one of those spaces where it could be challenging to produce results that don't exhibit that problem.
Finally, there is the overlap with Public Health Reporting. Ideally, I'd like to the same specification used to describe computable representation of the data needed for a report as for a query. In the first case, that representation describes the data outputs of a system. In the second case, it describes the inputs to a computation. I can use the gozouta of one as the gozinta to the other. That will be extremely powerful for not just "public health query", but as a way to define interfaces in general.
That would enable interfaces for all kinds of <a href='http://wiki.siframework.org/Public+Health+Reporting+Initiative'>public health reports</a> to be generated automatically in software. That might put a lot of interface engineers out of a job, but I'm certain that in the current environment, there will still be plenty of call on their skills for other projects. Because as soon as you turn around, there'll be another initiative. I'm having trouble keeping up, and unlike many other standards geeks, that IS my day job.
The specification is very simple. You request a resource using a URL. The query parameters to use are specified in the HL7 Infobutton specification.
But the specifications as they stand in either IHE or HITSP are incomplete.
- How do you retrieve medical knowledge on a specific disease? A medication? What are the query parameters to set? What if you want a response suitable for a healthcare provider? A patient?
- What happens when there is nothing to show?
- How do you authenticate the provider using the request?
- What are the error cases?
- What is the format of the response?
- What additional metadata should be returned in the response?
- How can we make responses cachable? Should they be?
- How do we retrieve multiple results?
- Should the request be made using GET or POST?
These are all questions I had to address in the implementation I'm demonstrating at the Public Health Informatics conference this week in Atlanta. Some of the answers can be generalized to any use of InfoButton. Others are more specific to the kind of request being made.
There needs to be a general specification that addresses the common issues. These should be written as Change proposals to QRPH-29.
I have three or four other use cases for which I'd like to see a more detailed specification put together.
- Accessing Patient oriented education information on a laboratory result, condition or diagnosis, or medication. This is a capability already supported in MedLine Plus as I understand it. I'll be following up with a few people from NLM for more details on that. Note: Access to Patient-specific education information is one of the menu-set objectives in Meaningful Use.
- Accessing information about clinical trials relevant to a particular disease. Many patients with serious life-threatening or chronic illness would love to find out about clinical trials they might fit into. A suitable InfoButton query could be crafted to support access to an Atom or RSS Feed of clinical trials. That could go a long way towards encouraging enrollment in clinical trials.
- Taking the next step in creating actionable public health alerts. In my current implementation we are getting a HTML page back. But, the content would be easier to handle if it were actually an Atom or RSS Feed in response to the query. This addresses multiple issues:
- It supports multiple responses to the query.
- It allows just the key metadata to be returned as a response, with subsequent retrieval of the detailed data when needed.
- It allows each alert seen to be given a unique resource ID that DOESN'T change even when the alert changes. This is critical, as it allows providers to keep track of what they saw, when they saw it, without having to keep a separate copy. When the alert changes, the link in the feed changes, rather than the content of the page. This is an important issue for medical records professionals.
- When a feed is used, the URL found is to the appropriate alert. That makes the detailed alert result cache-able. This is another important issue that can help address network latency issues. A simpler response can be returned that points to the potentially cached resource.
The ProblemProviders and patients need a simple way to search for web resources that can answer specific questions. The HL7 InfoButton standard provides one such mechanism by which this can be done. However, there are a number of different ways that InfoButton can be used, and there are a number of options in how a system can respond. We need a consistent set of rules for using InfoButton to query for information that is either patient or provider-oriented. We need a consistent way to address and report on errors in the responses. We need a consistent way to return results so that EHRs and PHRs can make these queries, process the results, and display them in a normalized form.
Key Use CasesA provider using an EHR wants to locate patient oriented education materials on a given condition. How should the query be structured to obtain a selection of available materials? A patient wants to keep track of clinical trials for a specific condition. How should the query be structured to obtain a selection of appropriate clinical trials?
Standards and SystemsInfoButton, HTTP, XHTML, HTML, HTML 5, Atom, RSS EHR, PHR, HIE
DiscussionThis should be a joint work item between Patient Care Coordination, and Quality Research and Public Health. IHE would be a good venue to solve this problem because it involves developing a profile across several existing standards. It has the necessary expertise in PCC and QRPH to address content issues, and in IT Infrastrucure to address common infrastructure questions. There may also be cases where a query could actually return a URL to a form that could be used with the IHE Request Form for Data Capture profile. We should examine what the glide path is from QRPH-29 to ITI-34.
Monday, August 22, 2011
IHE IT Infrastructure Technical Framework volumes and supplements published
The IHE IT Infrastructure Technical Committee has published the following Technical Framework volumes as of August 19, 2011:
· Volume 1 (ITI TF-1): Integration Profiles
· Volume 2 (ITI TF-2): Transactions (volume 2 is divided into three separate sub-volumes)
o Volume 2a (ITI TF-2a): Transactions ITI-1 through ITI-28
o Volume 2b (ITI TF-2b): Transactions (cont.) ITI-29 through ITI-64
o Volume 2x (ITI TF-2x): Appendices A through W and Glossary
· Volume 3 (ITI TF-3): Section 4–Cross-Transaction Specifications and Section 5–IHE Content Specifications
The documents are available for download at .
The Committee has also published the following supplements to the IHE IT Infrastructure Technical Framework as of August 19, 2011:
· Cross-Community Fetch (XCF) - Published 2011-08-19
· Cross-Community Patient Discovery (XCPD) - Revised 2011-08-19
· Cross-Enterprise User Assertion - Attribute Extension (XUA++) - Revised 2011-08-19
· Document Encryption (DEN) - Published 2011-08-19
· Healthcare Provider Directory (HPD) - Revised 2011-08-19
· On-Demand Documents - Revised 2011-08-19
· Retrieve Form for Data Capture (RFD) - Revised 2011-08-19
· Support for Metadata - Limited Document Sources - Published 2011-08-19
· XAD-PID Change Management (XPID) - Published 2011-08-19
· XDS Metadata Update - Revised 2011-08-19
These profiles will be available for testing at subsequent IHE Connectathons. The documents are available for download at .
Comments on all documents can be submitted at
In this post, he talks about the Collaborative Health Record. This is a record of a patient's health that both the physician and the patient have access to.
He makes that point that a PHR is really only a small lens into the entire realm of health information available.
Outside the US, the term "Electronic Health Record" has a slightly different meaning. It is the longitudinal record of care for a patient which both can access. Many countries are creating systems to access this information. In Australia, they call it the "Personally Controlled Health Record". In HITSP, we defined PHR based on the definition of EHR. Instead of saying that it was an IT system designed for Physician use, the PHR was a system designed for Patient use.
The reality is that EHR and PHR are simply two sides of the same coin, and that we need to think about them together. Innovation that applies to one also applies to the other. For example, with respect to the Public Health Alerting scenario I'm demonstrating today at #2011PHI, the same interface could also be used from a PHR to show patients what public health alerts are related to their symptoms.
We need more of this kind of thinking in Healthcare. I applaud John and Dr. Siegel for their insight.
I cannot wait (although I must) until my healthcare provider installs their patient portal. That system is connected to the EHR and will be a great tool to assist me in collaboration with my doctor.
Now if we could just update our secondary (and primary) education systems to teach people how to work with their physicians. Then we could enable collaboration around health, instead of disease.
Friday, August 19, 2011
If you look at the ACO rules, the shift is also towards exchanging clinical data.
If you look at some of the work happening in Health Information Exchanges that payers are setting up, there also is a move towards clinical data exchange.
If you look at the recent work of the HIT Standards committee, you see the focus on quality measures has shifted to clinical vocabularies.
I welcome this shift, and see it as the start of a Healthcare Revolution.
This sort of revolution won't be without its challenges. We definitely need established mappings from ICD-9-CM and ICD-10-CM to SNOMED CT to support them. As HIMSS mentions in their post, it could take some time to implement.
Thursday, August 18, 2011
It will be the first Healthcare Conference that I wear my jacket too. It's been to other events, but this will be its first conference.
If you are looking for me, you can find me in my usual place: The Interoperability Showcase where I and many other IHE supporters will be demonstrating use of Healthcare standards for interoperability.
I'll be participating in the Public Health Alerting demonstration, just like I have in prior years. To learn more about what is happening there, you can also check out this session and this one.
I'm looking forward to it.
What we will be demonstrating is actually a very powerful mechanism to deliver public health clinical decision support as a service that can be used by any electronic health record system, health information exchange, or even a personal health record. The work is based on the HITSP T81 specification.
If this seems like old news, it's probably because you've read some of the press I talked about here. We are taking it to the next step. It may have taken time, but I'm hoping it will have been worth the wait.
There will be plenty of other things going on, including use of HL7 CDA to support disease monitoring and surveillance, electronic laboratory reporting, and implementation of several IHE profiles developed by the Quality, Research and Public Health domains. If you are going to the conference, stop by the showcase and say hi. I'll be pretty easy to spot.
IHE Cardiology Technical Framework Volumes, Technical Framework Supplement and White Papers published
- Volume 1 (CARD TF-1): Integration Profiles
- Volume 2 (CARD TF-2): Transactions
- Resting ECG Workflow (REWF)
- 3D/4D Echocardiography Workflow
- Cardiac Electrophysiology Key Data Elements
Wednesday, August 17, 2011
Tuesday, August 16, 2011
Interested parties are invited to submit proposals for new Profiles in IHE Radiology. Proposals will be considered for development in the 2011-2012 development cycle of the IHE Radiology Domain and are due by Friday, September 9, 2011.
Proposals should follow the attached Brief Proposal Template. Submit completed proposals to email@example.com.
(Note that the template is also available as a Wiki page at http://wiki.ihe.net/index.php?title=Brief_Proposal_Template. If you are comfortable editing in MediaWiki, you can create a Wiki page for your proposal following the instructions at http://wiki.ihe.net/index.php?title=Radiology_Profile_Proposals_2011-2012.)
The critical questions the proposal should address are:
- What is the problem and how does it affect clinical practice (use case)?
- How should things look in practice if it were fixed?
- What specific pieces of standards could be used to solve the problem?
An IHE Radiology Planning Committee meeting will be held on Wednesday, Sept. 14, 9:00-11:00 am CT to review proposals submitted. All interested parties are invited to take part in the discussion. Call-in information can be found at http://wiki.ihe.net/index.php?title=Rad_Plan_Agenda_2011-09-14#Dial-in.
Please address any questions about proposal submission process to firstname.lastname@example.org.
Secretary, IHE Radiology
Monday, August 15, 2011
Take those facts into account and then read this tweet.
@Skepticscalpel: How can a patient, who does not know what meds she is on or why, seriously participate in "Shared Decision Making"?
"The same way a doc who doesn't know the difference between a web browser and a mail client uses his computer" I responded.
"@Skepticscalpel: @motorcycle_guy But the doc isn't putting his care & possibly life in danger by not knowing" is the quick response.
The risks are irrelevant. The notion that one must be technically proficient to participate in decision making is a misconception stongly held by technologists of all kinds. While we'd certainly like for it to be true, it often isn't (remember the stats cited above).
As a software developer, it is often my job to make a complex set of issues readily understandable to a stakeholder who doesn't have the neccessary background to infer consequences of the decisions they must make. My responsibility is to make it clear, theirs is to make their needs known. Together, we decide on a best course forward. If we do a good job, everyone feels good. It is a shared responsibility. I cannot blame the customer for my failure to explain the repurcussions of their choices.
After all, if they understood it as well a I did, they wouldn't need me in the first place.
People are much more complicated than computers or software. I expect the professionals that serve and service them to be much more skilled at this than I am. But perhaps I ask too much.
I've worked with structured documents and natural language processing for a long time, probably twice as long as I've been in healthcare.What I find interesting in healthcare is the nature of the information being used. Just for fun, I'm going to look at it from a document oriented perspective, since that's what I've spent most of my life working with.
From a document perspective, a dictionary, phone book or thesaurus is almost ALL data. Every last dot and twiddle can be expressed as either discrete data, or relationships to other data. In the healthcare world, this is like a drug database, or a vocabulary like RxNORM, SNOMED® CT, LOINC®, ICD or CPT. In XML (or SGML), there's a lot of markup expressing relationships between content, as compared to text to display to the end user.
A clinical note, especially ED, Inpatient or progress notes, involve quite a bit of storytelling. Sections like "History of Present Illness" or "Hospital Course" tell a story about what led up to a visit, or what happened afterwards. The relationships are fuzzy and ill-defined, often hard to identify. There is data here, but it has a great deal of subtlety. It's hard to pin down, or to compute with (you will note that I said, hard, not impossible). There are little pockets of low hanging fruit. You can readily identify diseases or medications in the text, treatments or diagnostics. The medical profession uses language precisely (some would say "like a scalpel"), which makes it a lot easier to identify this data in the narrative. But just because it cannot be identified, doesn't mean it's not there. It's just represented in a way that you cannot easily fit into third normal form.
Interspersed throughout the narrative are larger chunks of discrete data, results from examinations and assessments that can be finely structured, collections of measurements, like vital signs. These notes are like entries in an almanac. There are broad swaths of narrative, interspersed with finely structured text dense with data: Flag, Population, GDP; Blood Pressure, Temp, O2 Saturation. This stuff is designed to be put into tables, both on the screen and underneath it.
The electronic health record is a collection of data. Some of it is stored in a format suitable for humans to read, and other parts of it stored in a way that makes it easier for software developers to compute with. It's all data, the question really is what are the tools you use to access it. The EHR is one such tool. From the physician perspective, it ought to be digital library of data, making it easy to access information about a given patient, disease, medication, treatment, diagnostic, clinical trial, outbreak, et cetera. Having accessed it, now display it, analyze it, and otherwise compute with it. That's a lot to ask for from one application. Mapping, charting, searching, keeping up with current events. Heck, that's a lot to ask for from one standard.
Not everything that is data is easily stored or computed. Not every stream of data need be stored in human readable form. Yep, XML might be the answer, but I think there are a heck of a lot more questions.
I used to work with almanacs, thesauruses, dictionaries and encyclopedias as structured text. Each one had rich markup that worked very well inside the book. In other words, the markup of a single publication worked well with data structures designed in that publication. But getting them to work together across publications, that was very different, and a difficult prospect. We still struggle with this in the "semantic web" today. It shouldn't be a big surprise that the XML representations across these different viewpoints of healthcare might work well from that one perspective, but not from others.
Saturday, August 13, 2011
The IHE Patient Care Device Technical Committee has published the following Technical Framework volumes as of August 12, 2011:
- Volume 1 (PCD TF-1): Integration Profiles
- Volume 2 (PCD TF-2): Transactions
- Infusion Pump Event Communication (IPEC)
- IHE Patient Care Device User Handbook – 2011 Edition
Thursday, August 11, 2011
Wednesday, August 10, 2011
Thanks to the Fox Group, LLC for preserving a directory of Healthcare Hashtags, and maintaining chat transcripts.
|motorcycle_guy||Five minutes until the #HITstd tweet chat starts. Join us at http://tweetchat.com/room/HITstd #HITstd|
|mjadala||Hello all, glad to join this chat! #HITstd|
|diegokaminker||Hi I consider me to be half-expert, half-querant and the other half too! #HITstd|
|motorcycle_guy||@mjadala Are you a querant, expert or fly-on-the-wall? #HITstd|
|mjadala||Madhur Jadala from IL; worked in HL7 2.3, 2.5; trying to learn about ccd, cda; Querant here #HITstd|
|motorcycle_guy||@GrahameGrieve Good Moooorning Australia, and welcome Grahame. Glad you could make it. What time is is there? #HITstd|
|TheGr8Chalupa||Erica Olenski, managing editor of @HealthStandards. Versed in #HL7, but always open to learn from the experts! #HITstd|
|theEHRGuy||Hi, my name is Michael Planchart and I have experience with HL7, DICOM, IHE and HITSP. #HITstd #HIT100 #HealthIT|
|mjadala||We do not use ccd a lot now, but are exploring its use when working with hospitals on elr electronic lab reporting. #HITstd|
|mjadala||Hello erica, graham & rest.. #HITstd|
|NateOsit||Nate here, friendly Health IT geek! Most likely fly on the wall, but may jump in w/ a question! #HITstd|
|diegokaminker||No questions yet? I have one question for Keith..re Meaningful use and #CDA/#C32 - is there any change for meaningful use Stage 2? #HITstd|
|diegokaminker||@GrahameGrieve it refreshes itself every # seconds if you are in tweetchat #HITstd|
|mjadala||#HITstd what is the current adoption rate of cda vs ccr etc?|
|motorcycle_guy||@diegokaminker With respect to #CDA and MU Stage 2, I expect HIT Standards Committee to discuss Consolided CDA guide for transfers #HITstd|
|HITExchange||Anyone using #CDA to draw out data for MU quality reports? #HITstd|
|diegokaminker||@motorcycle_guy @GrahameGrieve Oh I´ve got it now- We need to update SouthAmerica. At least 5 countries using CDA R2 #HITstd|
|motorcycle_guy||Welcome @rjhornii, sorry you cannot stay long. Maybe we can drag you in for DICOM discussion #HITstd|
|starkehealth||Hi there. Jomo Starke, Manager of HIE for SynerMed, versed in HL7 and HITSP. Multitasking, fly on the wall today. #HITstd|
|GrahameGrieve||@motorcycle_guy ta. I can edit, but how do we get people to register? #HITstd|
|motorcycle_guy||@mjadala Hard to tell. At least 400+ systems read BOTH. These systems have demonstrated CCD/CDA creation: http://bit.ly/pXYZaP #HITstd|
|motorcycle_guy||RT @HITExchange: Anyone using #CDA to draw out data for MU quality reports? #HITstd|
|motorcycle_guy||@HITExchange I get a LOT of questions on extracting CDA data 4 quality reporting. I would have to say that many are trying it. #HITstd|
|motorcycle_guy||@mjadala No hard data on creating CCRs publicly available. #HITstd|
|mjadala||“@motorcycle_guy: @mjadala No hard data on creating CCRs publicly available. #HITstd” thanks Keith|
|rjhorniii||How many quality use problems are format vs content related. E.g., using diagnostic codes chosen for billing purposes. #HITstd|
|motorcycle_guy||@rjhorniii Excellent question. A number of retooled measures use billing codes. Unfortunately it seems the only codes many have. #HITstd|
|motorcycle_guy||How many of you would prefer to drop #HL7 V2 for immunizations and lab reporting, and just go #CDA all the way? #HITstd|
|GrahameGrieve||@motorcycle_guy I would prefer to use CDA for these "reports" which are clinical documents - but they also need process (=v2) #HITstd|
|motorcycle_guy||@GrahameGrieve @motorcycle_guy #hitstd|
|mjadala||#HITstd currently scrambling to accept hl7 2.5 for elr to meet #MU|
|motorcycle_guy||@GrahameGrieve What process would be needed? #hitstd|
|diegokaminker||@motorcycle_guy maybe as an option...it will be great #HITstd|
|GrahameGrieve||@motorcycle_guy - for labs, ordering and reporting are tied, and ordering = v2. Immunization - also subject to ordering here in Oz #HITstd|
|kim_nolen||Me too! @NateOsit: Nate here, friendly Health IT geek! Most likely fly on the wall, but may jump in w/ a question! #HITstd|
|motorcycle_guy||RT @GrahameGrieve: I would prefer to use CDA for these "reports" which are clinical documents - but they also need process (=v2) #HITstd|
|motorcycle_guy||So, @NateOsit, what do you want to know about #CDA? #HITstd|
|NateOsit||@motorcycle_guy I guess my Q would be how well can CDA interface w/ systems using non-HL7 messaging? ie: Epic, Meditech, etc #hitstd|
|motorcycle_guy||@NateOsit Old news right in your back yard: South Shore (Meditech) exchange #CDA with Atrius (Epic) via XDS http://bit.ly/rfHoZW #HITstd|
|motorcycle_guy||@mjadala What is your biggest #CDA Challenge? #HITstd|
|diegokaminker||Has anyone tested trifolia to manage CDA templates? Any comments on the experience? #HITstd|
|motorcycle_guy||RT @diegokaminker: Has anyone tested trifolia to manage CDA templates? Any comments on the experience? #HITstd|
|motorcycle_guy||Just a few minutes to go. What topics would you like us to address in future chats? #HITstd|
|diegokaminker||Another one...Are we going to have (someday) a central repository for ALL CDA R2 templates...no matter who generated them...? #HITstd|
|Cascadia||RT @motorcycle_guy: Just a few minutes to go. What topics would you like us to address in future chats? ^patient identification #HITstd|
|motorcycle_guy||@diegokaminker #ONC @SIframework is supposed to be developing a repository for artifacts through tooling contract. #HITstd|
|diegokaminker||Will this repository be "global" or only for the US? #HITstd|
|motorcycle_guy||Thanks for joining the #HITstd chat. Join us again in two weeks for a discussion of IHE profiles from ITI, QRPH, and PCC #HITstd|
|diegokaminker||Thank you for the answers and the great idea! Hope a lot more people join for future sessions! I will invite all the HL7 ELC course #HITstd|
|diegokaminker||And you will get >400 participants :) #HITstd|