Saturday, September 29, 2012

MeaningfulUse Stage2 Wave 4 Test Methods Released

The next and final wave will be out October 17 according to what I've been hearing. Then there's supposed to be a three day technical workshop on the certification test methods on November 13-15 and the final test methods are scheduled for release in med December, with certification to begin on the first business day of the new year.

   -- Keith
2014 Draft Test Methods: Wave Four Released for Public Review and Comment
The Office of the National Coordinator for Health IT (ONC) is pleased to announce the release of the fourth set of 2014 Edition draft Test Methods (test procedures, tools, and applicable test data and files).

All Test Methods will undergo public review and comment before being finalized and approved by ONC for use in testing and certification. The final set of Test Methods is expected to be available for use in early 2013.

Comments and suggestions should be submitted to All submissions should include "2014 Test Methods" in the subject line. Please be as specific as possible in your comment submission.

For additional information, and to access the 2014 Edition draft Test Methods, please visit the 2014 Edition Draft Test Procedures webpage.
The Office ofthe National coordinator for Health Information Technology

Friday, September 28, 2012

Wave 3 of MeaningfulUse Stage2 Tests

I'm behind on evaluating Wave 3, and if they are following the same schedule, Wave 4 will show up tonight (although it may not, I heard something about there being a delay for the next wave).

I'm only going to be looking at two of the test procedures, because only two of them address the need to use interoperability standards per se, and I'm stretching on one of them.

Clinical Information Reconciliation

The first of the test procedures is Clinical Information Reconciliation.  I say this is a stretch because except for the IHE Reconciliation profile and the HL7 EHR Functional Model, there are few "standards" out there that address this.

This is a pretty decent set of tests.  Basically it verifies the EHR's capabilities to display in two separate lists the information to be reconciled, with attribution of the data source, and relevant dates.  There are three separate tests performed for each of the three data categories (problems, medications and allergies).

Display Test

  • The Vendor creates a patient record in their EHR and populates that patient’s record  with ONC supplied medication test data in the medication list
  • The Vendor creates at least one additional medication list for this patient using ONC-supplied medication test data in the(se) medication list(s)
  • The Tester displays the two or more medication lists simultaneously in a single view
  • The Tester verifies that each of the medication lists displays the source of the medication list and the last date each medication was documented, ordered, prescribed, refilled, or edited

The one thing that I think it is missing is ensuring that the two records used in the test are for the same patient.  You can imagine situations where all you have are patient demographics to go on here (e.g., patient transmits a recent record from provider A to another provider B using VDT, and provider B needs to reconcile his/her list with that provided by provider A).

This is something that the IHE Reconciliation profile mandates:
  1. It SHALL present the demographics used to identify the patient provided by each separate source of clinical information to the end user.

Creation Test

Although appearing to be somewhat mislabeled, the point of this test it to ensure that a single unified list can be created, with corrections.
  • The Tester merges the two or more medication lists from the Display test into a single reconciled medication list
  • The Tester consolidates identical medications from these medication lists into one representation of those medications on the single reconciled medication list
  • The Tester removes a medication from the single reconciled medication list
What IHE has to say is a bit more direct:
  1. It SHALL highlight inconsistencies found during the automated reconciliation process and provide the clinician with mechanisms to adjust or correct the input.
  2. It SHALL provide a mechanism for a clinician to add new information to the reconciled results.
Removal is simply one mechanism to adjust or correct.  IHE notes that you could also add new data to the results.

Review, Validate, Confirm, and Submit

This step is about saving the results.
  • The Tester displays the single reconciled medication list generated in the Merge test
  • The Tester reviews the reconciled medication list and validates that the data contained in the list are accurate and complete
  • The Tester confirms and submits the reconciled medication list to the patient’s record in the EHR
  • The Tester views the patient’s active medication list and verifies that it includes all of the reconciled medications and that these medications are accurate and complete
Again, IHE is a bit more direct about some things:
  1. It SHALL authenticate the clinician prior to storage of the reconciled data (this step may be combined with other authentication steps used to finalize the record).
  2. It SHALL store the resulting data for future use by other actors as described below.
Tests for the other information categories are fairly similar.

Ambulatory setting only – clinical summary

This is the big one... creating Consolidated CDA Conforming Documents.  They are using MDHT to do this testing, and given recent results reported at the HL7 Working Group Meeting, this is going to be much better than Schematron (you may recall that Dave Carlson is a Harley Award winner for his work on MDHT).

There's a lot of functional details in this test that finally address one of my favorite issues, relevant and pertinent.  You have to be able to demonstrate the provider's ability to select the relevant data in this test.

I'll have to spend more time with the testing tool to see how it works.  One of the nice features of this tool is that eventually, it will support the specified transports, to test that as well.

It looks like the put my buddy from NIST, Bill Majurski, in charge of this tool, and he's used the testing framework that NIST has been supplying IHE with to deploy this test.   I'm sure he'll be thrilled with all the e-mail this tool is going to be generating for him, especially since they put his e-mail address in the test procedure.  Good luck Bill!

  -- Keith

IHE NA Connectathon 2013: Registration Closes October 5

IHE NA Connectathon 2013: System Registration Closes October 5, 2012
Time is Running Out! Register Today for the Industry’s Largest Interoperability Testing Event!
IHE Profiles are the cornerstone of achieving health IT interoperability as required by Meaningful Use Stage 2. Prepare your team to successfully test at the NA Connectathon 2013 by completing system registration before October 5th! The NA Connectathon 2013 will be held in Chicago, IL, January 28 - February 2, 2013 at the Hyatt Regency Chicago. For the first time ever, the Consolidated CDA® standard developed by Health Story Project, in collaboration with HL7 and IHE, will be available for testing! Discover more about IHE and Consolidated CDA® system registration online.
Shift your Product Development Cycle into High Gear!
Want to know more about testing at the IHE NA Connectathon 2013 and how it will benefit your organization? IHE USA’s educational sessions will provide an overview of IHE's role in the healthcare industry, Technical Frameworks, and impact on Meaningful Use. Access all the sessions online through HIMSS eLearning Academy. Sign up for a free account today!

For more information visit IHE USA’s website or contact

Thursday, September 27, 2012

Chilling PHR Patents

This was an interesting press release that crossed my desk a couple of days ago.  Quoting from the release [emphasis mine]:
According to Ted Ward of the law firm Liner Grode Stein Yankelevitz Sunshine Regenstreif & Taylor LLP (, which represents the Company as patent litigation counsel, "The MMR health IT Patent Portfolio means that anyone who provides a consumer with a Web-based portal, including hospitals, physicians and pharmacies, where the consumer can access personal health information may be infringing on MMR's IP." Ward added that Liner is in the process of contacting hundreds of hospitals and physician group practices to discuss opportunities to license the Company's IP in advance of 2014 Meaningful Use requirements to provide patients online access to their health information within four days of the information being available to the doctor and within 36 hours of being discharged from the hospital.
Chilling, especially the part in bold.

Relevant patents referenced in the release are:
  • Method and System for Providing Online Records (which will soon be issued), and which links to this application.
  • 8,117,646  Method and System for Providing Online Records
  • 8,117,045  Method and System for Providing Online Records
  • 8,121,855  Method and System for Providing Online Records
There's nothing fundamentally surprising to one versed in the art of the Internet in these patents as far as I can tell.  It's not clear to me (because I am not a lawyer), how fundamentally this could impact things like Direct.  The patents seem relevant when e-mail is involved.  I'll be looking at them to see how they impact ABBI.  So far, what I'm dealing with can use any back end that can provide health information in a certain way.

The earliest filing date seems to be in Q3 of 2005.

There seems to be quite a bit of prior art that I'm aware of, but I've not fully groked the patents in question either.

I know I was thinking about PHRs prior to Q3 2005, and using the Internet to exchange information.  We created XDS in 2004, and prototyped it in 2003.  The original XDS (XDS.a to newbies) included e-Mail as a transport mechanism for health data for patients back in 2004 (ftp to PDF). You'd want to look at the off-line mode of operation, in which IHE specifically talks about using SMTP (e-mail) to communicate health data between systems.  In that specification, we discuss the creation of a patient health record account, and the submission of documents to that account using the Provider and Register transaction.  In off-line mode, that includes transmission via e-mail.

We considered patients to be part of this network back then, and also in early PCC days (see 6/1/2005 Minutes).   Using e-mail for notifications was one of the early additions to the IHE family of XDS related profiles.  I started in the NAV project in late 2004, and we published the first draft of Notification of Document Availability in 2005.

I know AHIMA had developed a practice brief on Personal Health Records back in 2005, I'd love to see that version of the brief.  What you can find today was updated not too long ago.  You can also see what the site looked like back in late 2003.

So, what do you think about this press release?  And the claims of these patents?  I'd be interested in hearing from you.

-- Keith

I'd be interested in hearing what others think about these patents.  

Ask me a Question Archive 2011

  1. Ask me a Question is something I started here.  Periodically, I will archive old questions to keep the page smaller.  This is the Archive from 2011.

    Hi, My question relates to the Connect Opensource project. After spending a ton of time downloading all the parts and installing and configuring and doing several dances of prayer to help getting it working, I was kind of successful. After spending an unusual amount of time, I was wondering if you know of any resources that could provide a way to connect my existing systems to "connect" without using the portal software that is provided. I'd like to NOT have to deal with that implementation.
  2. Hi Keith,

    What top 3 Emerging Technologies in #HealthIT do you envision for the next 5 years?

    What would you consider a BIG occurrance in #HealthIT?


    Michael (@theEHRGuy)


    1. HIE, mHealth and tablets
    2. A Big occurrence in Healthcare IT?
      1. Any major change in the payment model that we don't currently deal with today.
      2. HTML5 in CDA R3 for every kind of reporting (ELR, Immunizations, Summaries).
  3. Hi Keith,

    I work on a patient portal application. Across many different vendors, we are seeing inconsistency with the coded medications section. Primarily, around the code system used. The NIST CDA validators, as well as the HITSP specs indicate that medications should be coded with the RxNorm code system. However, I'm seeing vendors that are coding using Multum, NDC, etc. Some that are indicating RxNorm, but each entry has a nullFlavor for the code. Could you provide some clarity here. For an application, which expects to receive CCDs generated from multiple vendors, can we safely rely on the specification of RxNorm or should we expect to deal with nonconforming vendors? Who holds the vendors accountable for making sure they conform?

    Thanks for your thoughts.


    1. See this post for a partial answer. RxNORM is preferred by C32/C83, but others are allowed as translations. Codes, however, are not REQUIRED. You cannot expect RxNORM at present. As to holding vendors accountable, the ONC-ATCB should to start with. But if you are having problems, you should complain first to the vendor, then their ATCB's and finally to ONC if not satisfied.
  4. Michal: A Big occurrence in Healthcare IT?
    1. Any major change in the payment model that we don't currently deal with today.
    2. HTML5 in CDA R3 for every kind of reporting (ELR, Immunizations, Summaries).
  5. Hi Keith,
    I want to store CDA documents in a RDBMS, What do you suggest should be best way to do that.

    1. Create tables using Hierarchical Description?
    2. Create specific tables such as problem, allergy, procedure etc?



    1. t depends on what you are trying to do. I assume that your reason for storing in an RDMBS is to get at the clinical content, and thus, I would recommend #2 for you. But at the very least, you also want to index documents, and for that, using a pruned down HD for the CDA Header would work pretty well.

      I wouldn't recommend using the HD or R-MIM directly unless you have a system that is optimized for V3 in storage.
  6. Hi Keith,

    Thank you for answer. The objective is to store the incoming CDA documents into RDBMS, then update the tables from NLP output eg. add coded clinical contents,
    then generate CDA Documents with coded clinical info.

    the incoming document can be any type of CDA- Hitsp, Healthstory, IHE and even CCR.

    Do you think in this situation we should create
    domain specific tables or R-mim or HD are batter choice.



    1. Given you are generating NLP based output, I'm assuming that you are working with a fixed set of NLP targets, e.g. Diseases, medications, allergies, et cetera. If so, I'd recommend domain specific tables.
  7. how can I represent not know result in results section ?


    1. Hi,
      Result Status Code is used to send the Result Status.
      Consult the CONF# 7303 against 2.16.840.1.113883.5.14 for suaitable value you want to send as per your requirements.


  8. Hi Keith,
    I'd like to make a small correction on the CDA book.
    In table 10.3, page 102, the Code of Before lunch seems to be 'ACD' since its description is 'ante cibus diurnus'.


    1. Thanks for pointing that out. I've created an Errata Page for the book.
  9. I have a subjective question for you about the openness of standards. (If you've covered this before I apologize) Do you think it's appropriate to require a membership and fees to get access to standards? Do you think this encourages innovation or stifles it?
  10. I did cover this before here. I like the direction HL7 is headed "Read for free, use for a fee". I agree that access encourages use (and innovation).
  11. What is the relationship between CDA-R2, CCD, C83, C80 and C154. How does conformance in each of the standard associate and what is the relationship.

  12. This is a follow up to my earlier post on Twitter:
    I am a payor writing an extract for claims analysis, is there a defined format for this? Where can I find specs? @motorcycle_guy #HealthIT

    I am currently writing an extract for a business partner of ours to allow them to do analysis based on the vision claims data of the employers members. The business partner is hired by the employer to produce reports for them.

    I am looking to see if there are defined standards for this type of extract. I currently produce a formatted text file they import.
  13. There is nothing that I'm specifically aware of that covers what you are looking for. There are several standards that could be used to report on this data, one of which might be CDA, but I imagine that your data requirements are more dealing with the Administrative / Financial side, rather than the clinical side, so I would be hesitant in recommending that format. What kind of data elements are you dealing with?
  14. The current report includes these elements but is likely to need more soon: CLAIM_NO, Employer ID number, Unique member ID, date_serv_from (date of service), Date claim paid, PROCEDURE_CODE, AMT_BILLED, AMT_PAID, Unique Provider identifier, Diagnosis Codes applied to service, member_name, Gender, DATE_BIRTH, MEMBER_SSN

    These are all at the service level. This is vision claims data (but really should not make a difference.
  15. I assumed that this would be similar to what an HIE would use.
  16. Please walk me to the the definition of hl7 code 21568.

    Simply cannot find out what it means.
  17. I strongly suspect that you are dealing with quality measure spreadsheets from NQF, and are dealing with this issue. I need more context to answer your question though, because I cannot find that code either.
  18. This code and several others are mandated for "Meaningful Use" in certified EHR products. The measures are called CQM (clinical quality measures) with NQF overlap. Try NQF 0041 as it relates code 21568. This is a SYSTEM reason for medication not done.
  19. OK, so I was about the source of the problem. The code you are looking for probably appears in either ActCode or ActReason code systems from HL7, and the 21568 is a typo of some sort, because I cannot find it in the HTML files. That value is the internalId instead of the code. You'll have to look at the May or normative vocabulary materials, because the internalId was REMOVED from the ballots to prevent this sort of mishap in the future. At this point, your guess is as good as mine, but at least now you might know where to look.
  20. The HL7 internal id 21568 corresponds to the abstract code "_ReferralReasonCode" in the ActReason code system (OID 2.16.840.1.113883.5.8). So whatever specification is referencing the code is doubly broken:
    - First because HL7 internal ids are exactly that - internal. They should never appear over the wire at any time.
    - Second because the code that corresponds to that internal id is an abstract code. Abstract codes are intended to group other codes for semantic analysis and value set definition and are not permitted to go over the wire.
  21. Hey Keith,

    Do you do collaborations on articles. I have resources for health care comparisons that would be great to share with your readers. The comparisons give detailed descriptions of health care providers or policies, and all information is from the government so it is not biased by companies. Please email me if you would like to talk to me about this information I can share with you. All resources are free and great for people to use when looking for insurance policies and companies. Thanks
  22. Keith - since you are not following me, I can't answer you on Twitter. I decided to follow you based on the post on NwHIN and Direct. I think we are elaborating Direct to the point that it will not serve for simple connections. Also, the addressing recommendation is a good one. I hope it gets some attention.

    Ruby Raley
  23. Hi Keith,

    I opened a thread on Grahame's website,
    I'd like to have your opinion on CDA for recording change of dosage. Thanks!! (The topic is around the bottom of the responses)

    James Chan
  24. Keith,

    Some have suggested that CDA compliant structures could serve as entries in an EHR. Others agree if CDA/R3 is used. Would you care to weigh in on this?
  25. Hi Keith,
    I'm very new to healthcare and interoperability standards, yet I started working for a software development company and since I'm the only one speaking English, I have to "digest" the standards and in few months - advise our people on which standards to implement while developing medical image sharing system. Is any guidebook, tools or something like "HIS interoperability for dummies" available? Or some guidelines that say "if you are developing EHR / image sharing system, these are the things you should implement while over those items are optional, and here's when you should consider them in development process"?

    By the way, I already have read a lot about HL7 (CDA, CCR, v2,v3), IHE profiles, HSSP, SNOMED, etc but still have no idea how and when to include those standards in development in a logical, sequential way ...

    great thanks for saving my life (and time) with your advises
  26. Hi
    I am from Saudi Arabia, working in ministry of health at ehealth program we need to contact with you.
  27. Keith,
    Do you know of standard classification system for classifying health IT standards? I have looked at the ISO International Classification for Standards but it stays pretty generic with respect to health IT standards, most would classify as "35.240.80: IT Applications in health care technology" and/or "01.040.01 Health care techology vocabularies". I would like to get to something more browsable such as "Information Exchange Standards-> Pharmacy Information Exchange Standard -> NCPDP"
    Pardon the overly simplified example but I think you probably get the idea.
    Many thanks for your consideration.
  28. Kevin: I do sometimes have guests write posts, but the kind of information you are talking about really isn't about healthcare standards, but healthcare in general, so I don't think it would be appropriate here.

    Geoffry: Interestingly enough, some EHR's use CDA as a native storage format for clinical documents. Most EHR models map pretty well to structured data elements represented in HL7 V3 XML. See Models for Query Health to see what I mean.

    Kristina: There's more healthcare standards than even I can keep track of, and no, I don't know of any good place where you can get that kind of advise other than by asking different people for their opinions. It might make for an interesting blog post or seven. As far as imaging goes, I'd look for someone with more DICOM expertise than I have to advise you.

    Hashem: I dropped you an e-mail...

    Jennifer: I don't know of a good classification system for health IT standards.
  29. Keith, I am currently working to add the additional content that is needed for Stage 2 in my CCD document (to make it available via a PHR which is expected) and am having a hard time finding details in the HITSP specification regarding how you should represent a plan of care - which at least based on the preliminary publications - seems to be content they would like to see there. Are you aware of information available on this topic outside of the very high level information in the C32 and C83 specifications?
  30. Anonymous: I don't know of anything more detailed than that other than what might be in the CDA Consolidation guide, and that is at the same level as the C32/C83 specifications. It's a bit hard to answer your question because Stage 2 requirements haven't been formally defined yet by ONC, we only have HITSC requirements.
  31. Can you explain the difference and similarity between CDA, CCR, CCD, GreenCDA, CCDA, C32, C48, C999, and any other flavor that I might see written about?

    Please direct your response to someone who worked on MU certification last year, but otherwise has not participated in any standard or government initiative.
  32. Is Blue Button the same thing as InfoButton?
  33. I would like to know what is the expectation in the scenario given below-
    A healthcare professional attests for MU and gets his money..later the EHR vendor finds a bug in their software's MU calculation so they fix it on all systems. Now, if the Dr. re-runs the report again, the report will show different counts. Can they go back to CMS and re-attest with that updated report? If there is no such process set by CMS, what is the expectation from Vendor and doctors in such cases?
  34. Anonymous: I too have not seen anything from CMS on how to address that issue. I would strongly recommend that you contact your vendor account representative to see what they suggest.
  35. Hi Keith
    Could you let me know if IHE XDW can be used as the workflow for IHE XDS-MS and are there any examples or references you could point me to.
  36. Alan, IHE PCC is working on a profile this year for referrals, and it will include use of both XDW and XDS-MS in it. The XDW profile includes as an informative appendix a method to use XDW for referrals.
  37. What is the roadmap for NHIN Connect?

    Why is there no ongoing updated information on the specifics of what will be rolled out in 3.3?

    When will all of this be ready for prime time?

    When will State HIE(s) and federal agencies begin real exchange on an ongoing basis?