Tuesday, April 19, 2011
Wednesday, April 13, 2011
When you want to work with a patient's medical record, you request a copy from a repository (maybe more than one) and it is delivered from the repository to you without leaving a trace anywhere in between. No copies, no caching, nothing. When you're done, all that PHI disappears completely from you local system, leaving only those copies stored in secure repositories within the health care system.
A health care professional (provider) is authorized to view a particular piece of PHI for a period of time. When a device or person becomes "de-authorized" to view a record, for example when a provider "logs out," then that PHI should be gone, leaving nothing of itself anywhere in the system. If a patient changes providers, then the consent rules change accordingly. Most commonly, consent is given for a finite period of time and will expire unless explicitly renewed. (This medical record will self-destruct on July 13, 2011.) PHI always exists in the secure repository and the patient, that is to say the person whose medical record it is (the "owner" of that medical record), is permanently authorized to handle the PHI and give or take away consent.
An ideal medical record, therefore, knows who is and isn’t authorized to see it at any given time, and is kind enough to politely decline to be transmitted or remove itself from an unauthorized system.
Thursday, April 7, 2011
At Axolotl, we dynamically generate template based CDA documents from various data sources.
One commonly transmitted document is the CCD, or Continuity of Care Document. This is a summary document, its intended purpose to have enough information, well organized, to preserve the continuity of patient care between different care providers.
The way I approach template-based CDA is to first look at the document as a container for health data, and construct the empty container first.
You can see it has, first, the necessary meta-data. Source, destination, attribution, author, the time period this document covers, any confidentiality instructions, and other information about this document.
Then it has the patient demographics and a list of all healthcare providers involved in the care described, and all doctors who provided care during the covered period.
The largest part is the clinical information itself. This document is a container, and the clinical section is meant to contain a list of clinical sections.
A section can be thought of as a smaller CDA entity in and of itself, and just as the document is composed of smaller pieces. It has template identifiers, a title, a human readable narrative text in an html-like format, and a number of entries. Each entry represents a single clinical event.
You can subclass the section into the different categories of clinical information, thereby putting a complete summary into a list of clinical sections.
The entries, themselves, have a wide variety of forms, so we subclass them into different types of entries for the various sections, support entries for the support section, insurance plan entries for the payers section, allergy entries for the alerts section, and so on.
If you need to build a CCD, or any template-based CDA document, that’s an approach to think about.