Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Tuesday, June 16, 2009

Observation of the Week

What's wrong with this list:

Vehicle Type:
  • 4-Cylinder
  • Commercial Truck
  • Motorcycle
  • Hybrid

One of the problems is that the value set for this data element covers five different axes for classifying the vehicle: Number of engine cylinders, use and body style of the vehicle (in one term), skills needed to drive it, and type of engine.

These are accentuated by the fact that the data element itself isn't well described. If it had said "vehicle cylinder count", "vehicle use", "body style", driver's license type, or engine type, it would be much more clear how this particular data element was to be used.

I have had four separate discussions with different groups on data elements that use the word "type", "kind", "category", "classification" or "code" in the name, where the only other piece of information given was what was being classified. Most things can be classified more than one way, and we usually know in a class diagram what class the attribute applies to. Most of the time I spent with these different groups was in understanding what the definition of the data element meant. By the way, on at least one occasion, drilling into the definition yielded something like: "the XYZ type describes the kind of XYZ that is being used". That's not very helpful ;-(

My design observation for this week is that if you are naming a data element to classify a thing, think not about what it applies to (vehicle), or that it classfies it (type), but rather, how you are classifying it. The implementers of the system you are designing may never notice, but then you'll probably never have to field questions about what "XYZ type" means either. It may save you some time, and it should certainly save them some.


Monday, June 15, 2009

Freely Available Standards

One of the discussions that I routinely have in HITSP meetings lately is about the cost of the standards to implementers. The assumption seems to be that standards HITSP selects should be available for free to the implementers, and this has been raised as an issue for a number of standards that HITSP has selected. When HITSP reviews the standards it selects (in what we call a Tier 2 evaluation), one of the factors is indeed cost for use of the standard. HITSP does recognize that standards aren't always free, but that reasonable costs shouldn't be a barrier to selection. I reproduce the guidance given for tier 2 evaluation below:

"6.7 Favorable intellectual property and licensing terms

The standard produced by the organization should be readily available to
entities for implementation and usage. The standard should be available to most
stakeholders at no or reasonable cost. Code sets or terminologies should have
licensing arrangements, which do not pose a barrier to usage. This
availability should include a willingness to share necessary standards with the
HITSP and its Technical Committees for use in evaluation and, based on further
agreement, in HITSP Interoperability Specifications. When necessary,
evaluation of favorable IP and licensing terms may be applied to individual
standards if the standards organization maintains different terms for different
standards (see 3.0)"



I can see the point being made by those arguing for free access to the standards. This is especially important those in the open source community who do not have a revenue stream to support purchase of standards. However, I also understand why standards development organizations need to charge for their standards. Developing standards is not without cost, and somehow that cost needs to be recovered, or their simply won't be any new standards to use.

One of the proposals that has been suggested is that the Federal government purchase the rights for implementors to use standards that it mandates for use within electronic transactions through various regulations (e.g, ARRA, eRX and HIPAA). The government has already done this for SNOMED CT. This would make the standards freely accessible to implementors and users of the standards, and would also do something to reduce the costs of implementation of Healthcare IT.

Perhaps ONC should consider using some of the funds that it hasn't allocated yet to ensure that the necessary standards are available. Another important aspect of this would be that it would also allow the American public free access to the technology that is being used to support the provision of healthcare. This brings up several questions, including how each license would be negotiated, how value would be fairly apportioned to the copyright holders, and how access to the standards would be provided.

I think these are all interesting topics, and I frankly don't have an answer to any of them, but I do have another related idea that might be part of the framework for resolving these issues. A lot of what we wind up doing within HITSP which naturally flows outwards to the various SDOs is similar to what Canada InfoWay does with their Standards Collaborative. It might be interesting to review the Canadian model, and to think about what a public-private collaborative organization serving a similar purpose here in the US might do to make the standards more available.

It's just a thought...

Tuesday, June 2, 2009

IHE Public Comment Period Opens

IHE - Changing the Way Healthcare Connects

IHE Community,

The following Technical Framework supplements and white papers have been published for public comment.

IT Infrastructure (ITI)
The IHE ITI Technical Committee has published the following supplements and white papers for public comment:

  • Document Metadata Subscription (DSUB)
  • Multi-Patient Queries (MPQ)
  • Retrieve Form for Data Capture (RFD)
  • Cross-Community Patient Discovery (XCPD)
  • White Paper: Access Control
  • White Paper: A Service-Oriented Architecture (SOA) View of IHE Profiles
Patient Care Coordination (PCC)
The IHE PCC Technical Committee has published the following supplements and white paper for public comment:

  • Antepartum Record (APR)
  • CDA Content Modules
  • EMS Transfer of Care (ETC)
  • Labor and Delivery Record (LDR)
  • Patient Plan of Care (PPOC)
  • Request for Clinical Guidance (RCG) and Immunization Care Plan (ICP)
  • White Paper: Waveform Tracings

Patient Care Devices (PCD)
The IHE PCC Technical Committee has published the following supplement for public comment:
  • Implantable Cardiac Device Observation IDCO
The documents are available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm. Comments may be submitted to the online forums at http://forums.rsna.org/. To be considered for incorporation in the trial implementation versions of these supplements, comments must be submitted by July 1, 2009.