Enabling Patients to Delegate Healthcare Information Access Authority

In the USA there is interest in defining goals to improve Patient ability to delegate personal representatives, specifically regarding accessing through the internet to the patient's healthcare information.:

The Health IT Policy Committee’s Privacy and Security Tiger Team is considering potential privacy and security policy issues that could arise when a family member, friend or legal designee is given access to patient information through the Certified EHR Technology “view/download/transmit” (V/D/T) capabilities. More from the HealthIT.Gov Blog

Here is my perspective given the current state of Privacy and Security standards and policy:

Set a Privacy Authorization Horizon Goal

I think that HHS/ONC needs to set a clear horizon that includes a reasonable yet powerful concept of what controls a patient should have regarding delegation and accessibility. However this horizon should be seen as something achievable in 12-15 years. This should be a detailed horizon that privacy advocates can agree with. This should meet the needs of special interests. This should be internationally friendly. This should  embody what Privacy really means. Defining Privacy

Define Stepping Stones to that Horizon

Backing back from that there should be a set of reasonable stepping stones that get us to that horizon. Each step should include a spec benefit over the previous step. Privacy Consent State of Mind. Each step should be expected to be 'state-of-the-art' for at least three years. Too small of a step and there is going to be resistance, too large a step and there will similarly be resistance. Many facilities will find it easy to hit these stepping stones, and might choose to take two steps; but the majority as a whole (median) would find each step reasonable and useful. The reason to have a detailed horizon is to make sure that we all agree to the destination and that by whatever pathway taken end up in the same place. Without a detailed horizon we will have very unclear results, some might say we will get no results without a clear horizon.

I think the biggest problem HHS/ONC has is the various state laws/regulations, and the various levels of special health topics. This makes it very hard to have an initiative driven at the federal level. Which might mean that at best they can set guidelines for technology, and not practice. It is not likely they can, through this horizon, get harmonization of regulations over the 10-15 years; but it might be a side benefit of having a well-defined horizon that is privacy advocate approved and internationally acceptable.

Simple is a good place to start

I expect the first step to be very blunt authorizations that use paper to authorize electronic access to all data, a proxy. Clearly would need to recognize state and federal rules that force the issue. These forced exceptions are handled at a high-level policy and thus don't need special call out in patient-by-patient authorization rules. This first step addresses cases where delegation of rights is rather complete: Like medical guardian, deceased, parent of minor. This first step would not support cases where the delegator has some medical conditions or medical history that they want to keep from the delegate. This needs to be made clear is a horizon desire, but not a first step goal. This first step is not unlike the blunt 'consent' for patient treatment, so it is similar except the 'authorization' is to a non-provider for assistance with care decisions. This 'authorization' would be similar to the blunt authorization the patient gives to others for business reasons, like insurance payment from automobile accident.

Break-Glass must be written into Consent Authorization Policies

Often I hear about 'break-glass'. This MUST be build into the policy. This is not an afterthought. The policy must be very clear what access is allowed and what is not. Inside this detail is the specifics about what kinds of glass is allowed to be broken, and what kind of cleanup will be done when the glass is broken. Simple and Effective HIE Consent

Quilting the details from different perspectives

I think the second step is to allow the patient to segment data by some vector. I am not sure what is the most reasonable vector but by this second step this capability should become more clear:

• date-of-service. That is to identify a date range that is either authorized or not authorized. This doesn't differentiate between kinds of data, but would typically be able to segment specifically sensitive episodes of care.
• broad categories of data. Discharge Summary, History & Physical, Consultation Reports, ER Reports, Lab Reports, EKG, AIDS/HIV Test/treatment, Alcohol/Drug abuse, Mental Health, Development Disabilities, Team Conference Reports, Therapy Evaluations, X-Ray Reports, X-Ray Films.

Likely another functionality is to put limitations on the purposes for which the data could be used: Further medical care, Application for insurance, Disability determination, legal investigation, vocational rehab, payment of claims, or for the patient own consumption.

Electronic Authorizations will take many years

Third step is when electronic authorizations happen. In my view this cannot happen for at least 10 years from now. There are efforts like NSTIC that are helping create a framework for trusted identities in cyberspace, but going from having a trusted identity to legally binding authorization is a big step. This is an important point to be made.There is much to be done before this is fully available: not just standards but policy and social change.

One functionality that I often hear as needed is where the patient can identify those individuals that shall NOT have access to the data. Writing rules in the 'negative' seems easy, enforcing negative rules is very hard. Especially if the negative rule is preventing someone that is very motivated and very capable.

Paper is not always a bad thing

This doesn't mean that the paper authorizations from before are not electronically enacted, they should be. These previous stepping stones should take the paper authorization form, after proper manual processing for legal purposes are converted into electronic 'tokens', such as IHE - Privacy and Security Profiles - Basic Patient Privacy Consents (IHE-BPPC), that are acted upon automatically using an access control rules engine, such as XACML. All the logic that controls the release should be automated, just the step of getting authorization should start purely paper based. The act by the patient of authorizing access doesn't happen very often, so it won't gain that much from automation. Yet failing to capture the authorization properly can do damage, it can offer attackers the ability to set their own rules.

 

Some Providers will be ahead of the curve

I will note that I went to my healthcare provider patient portal today and found that they have an online a mechanism where I could see the records of those that have been delegated to me. I feel BlueButton advancement. To authorize this delegation of rights does require paperwork, that I can download and print from this portal. My children are old enough that we don't have automatic access anymore. My youngest is in a age range that Wisconsin has some specific restrictions around. My oldest is beyond 18. We have not done any paperwork to gain access. This tells me that delegation in a broad sense is likely to be authorized by old-style-paper, but enabled electronically. My electronic access now includes the ability to download my medical summary (blue-button) in CCD format as part of an XDM bundle. This XDM bundle can be non-encrypted or encrypted. Rather nice experience. I think my experience is more advanced than those of my peers in other states.

Resources:

Patient Privacy controls (aka Consent, Authorization, Data Segmentation)

• Defining Privacy
• Safety vs Privacy
• Privacy Consent State of Mind
• Defining Privacy
• Universal Health ID -- Enable Privacy
• Texas HIE Consent Management System Design
• Simple and Effective HIE Consent
• IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
• Data Segmentation - now I know where the term comes from

Access Control (Consent enforcement)

• Healthcare access control scope constraints on OAuth tokens
• Advanced Access Controls to support sensitive health topics
• Policy Enforcing XDS Registry 
• Healthcare Metadata
• Texas HIE Consent Management System Design
• IHE - Privacy and Security Profiles - Access Control
• Data Classification - a key vector enabling rich Security and Privacy controls
• Healthcare Access Controls standards landscape
• Handling the obligation to prohibit Re-disclosure
• Access Controls: Policies --> Attributes --> Implementation 
• IHE - Privacy and Security Profiles - Document Encryption

Audit Control

• IHE-ATNA and HL7-FHIR.SecurityEvent -- recording a Disclosure
• Simplifying Security Audit Standards

I feel BlueButton advancement

Many of the people I work with in standards world are frustrated at their lack of access to their own health information. My experience here in Wisconsin has been very different. Even before any of this Meaningful Use push, I had access to a patient portal where I could see a summary of my medical record and some of the lab results. I don't go to to doctor that much, so I can't really point out missing information. I have always had some electronic access.

Last year I pulled my medical summary and got a PDF as well as the old style blue-button text file. Both carried the same information. The PDF was simply a more 'pretty' version of the text file. Nothing fancy, but fully available electronically.

Today I went to my patient portal and it was a very different user interface. The new patient portal gives me a nice view of my future appointments, and past visits. It allows me to send a secure message to my doctor. I can view each test result. I can view and pay outstanding bills. For some prescriptions I can request renewal.  I also can delegate access to others, such as my wife; and if delegated I can access others information. The UI is easy enough for me to understand, seems should be easy enough for anyone that is internet savvy.

This time when I asked for my health information I was able to get my health summary in CCD format. The Blue Button Plus. The above diagram shows how they explain this new CCD format. Note that the button to download is not really a 'blue' color, but rather an orange/rust color. This also comes with a PDF version that most people can view, this PDF is a more colorful and seems more readable.

The nice part for me is that the download is also a XDM formatted zip file that contains the CCD in full XML format. As I look at this content it is even nicely formatted. There is nothing else in this XDM but the CCD. I am not sure I have anything else not included in the summary (Lab results) that could be on the XDM.

The same is not as true about the hospital visits, which for me is just emergency room visits. Even my most recent visit for a post automobile accident checkout was not readily accessible. It was accessible, but I first needed to fill out specific paper work to release it. This paperwork was not difficult, and it gave me reasonable choices. Depending on 'why' and 'to where' the release was to happen it was either free or would cost something. I chose to release it with the reason of 'continued healthcare' and released to my general physician. So it was free. This information seems to have shown up at my GP, but it is not fully available to me. I am guessing that because it is not authored by my GP, it is not published to me by my GP.

I expect that the data released from the Hospital to my GP is done through the Wisconsin HIE (WISHIN). This is an XCA based health exchange across all of Wisconsin. I am on their technical standards advisory committee. This has been far more successful than the mandatory (by HHS/ONC) deployment of Direct. I can't figure out how I might use Direct to send my information to someone of my choosing. This Wisconsin wide exchange is now getting connected to the Nationwide Health Exchange (HealtheWay).

Constrained Vocabulary and Schema are good and needed - But Robustness must rule the longitudinal HIE

Strict schema and vocabulary are persistent hot topics in Interoperability. For example what is the constrained vocabulary that should be used for CCDA documents in the USA? This is an effort of Profiling, or even Profiling-of-a-Profile. Further constraining vocabulary and schema as far as possible, while still providing some value. This effort to constrain vocabulary and schema are helpful in the early days of building an HIE because it helps simplify (KISS). The more simple the interaction, the more likely  it will succeed. However the more simple the interaction the less information can be communicated.

In building an Health Information Exchange (Verb), one needs to start simple, and this is a message built into the IHE message on building an HIE. In this there is a white paper (handbook) that walks an HIE organization through how to do these constraining work found in the IHE Affinity Domain planning kit. This is still a fantastic resource for building your governance, code-sets, and policies; like seen from Connecticut.

I think however that the more critical part of this HIE building project is not in picking a vocabulary and a schema. But rather in defining what is the proper behavior related to metadata and related to content. Specifically what happens when content or metadata doesn’t utilize that vocabulary (e.g. historic information, or from a foreign land). What is the sending responsibility to ‘fixup’ codes? What is the receiving responsibility to be ‘robust’ to deviations? Is there a role for a translation-service? What is the medical-legal meaning of content that has been changed simply to meet some coding restriction?

Using a restricted code system should be guidance, not mandate. Conformance should be measured on ‘creation’ events, not necessarily ‘transmission’. Everyone must be liberal in how they process incoming content. This is fundamental to the success of the Internet and is known as “Postel’s Law” or the “Robustness Principle”. http://en.wikipedia.org/wiki/Robustness_principle

Use-cases like insurance or public-health reporting can get away with this code restriction, as there is little ‘danger’ of a loss of accuracy from a coding translation. This is why it is logical and reasonable for the original intention of HIPAA to define specific and constrained code-sets. This is why it is reasonable for public-health to define a coarse grain vocabulary.

The actual codes maintained in the medical record, the ones that would be used for current and future treatment have not changed and are the code that the doctor or medical-device picked as the best code at the time the code was picked. When making treatment decisions, accuracy is very important. Deviations from original accuracy are not unheard of, but when they happen they are clearly identified as a derivative or a transform or a translation.

XDS has had from the beginning the concept of a restricted c ode-set for metadata, the concept of the “XDS Affinity Domain”. But we always expected the document content to be the original content, unless it was a properly approved “Transform” (a concept also supported by XDS). The dynamic document concept is clearly an exception that could be called out specifically. The codes in the metadata are intended to be ‘meta’, and thus a bit of accuracy loss for the benefit of easier communication (interoperability) is reasonable. This is emphasized very specifically for some metadata, like classCode (the high-level classification of the kind of content), but is also true of more fine grain items like typeCode. Meaning that even typeCode is just a code representing the whole and thus not a complete representation of the whole content. They are both ‘meta’.

Even XDS recognized that this constrained “XDS Affinity Domain” vocabulary will evolve over-time. Meaning as much as you think that you can control the vocabulary today, the future will want to have different constraints. These different constraints can only add concepts. It is possible to deprecate “new use” of old concepts. But the old concepts can’t be forbidden.

It is the concept of ‘forbidden’ that worries me most. Anytime a constrained vocabulary is selected, this ‘implies’ that codes outside that vocabulary are ‘forbidden’. This is an ‘implied’ POLICY. Please don’t make it an implied policy. Please make it an explicit policy, and I suggest that the policy follow the Principle of Internet Robustness; aka Postel’s Law. Be specific in what you send, liberal in how you receive.

When put into the context of a longitudinal record, rather than the context of an instant in time message, the ‘send’ point-in-time is the point at which the content is created, not the point when it is transmitted. Meaning when content is created it should be created using the best vocabulary and schema at that time, and it should be intended to be as conforming as possible. However we must recognize that a document created today, might be needed 10 years from now when the schema or vocabulary have changed. The new rules should not be applied, and any system receiving the content should try as hard as it can to understand the 10 year old content. Sometimes this means that it can’t be fully processed and that the user (clinician) needs to be warned of this.

This is the receive side robustness.

Eating an Elephant -- How to approach IHE documentation on Health Information Exchange (HIE)

FHIR Full Steam Ahead

Update from the HL7 Workgroup Meeting (WGM). Although I am not at the meeting due to a traumatic automobile accident, the FMG did have a meeting that they extended to those of us members that couldn't make the meeting. The main agenda for the meeting was to agree on if we will be targeting a second formal ballot, or go direct to DSTU. The GE pushback has caused much open and transparent discussion among the FHIR community. The FMG took this FHIR community consensus as advisement. There was a very visible survey done at the FHIR Connectathon, as reported to me by Scott Bolte (GE).

After all this deliberation the FMG voted unanimously to go direct to DSTU, providing nothing traumatic comes up this week at the WGM. I will note that the GE position was an urging for a second ballot, while being very clear GE accepts either outcome as long as it is open and transparent.

A few actions did happened as an affect of the open and transparent discussion as a result of the GE pushback. First there will be some letters published openly that explains the way that FHIR is going to utilize the DSTU. These letters will stress that during the DSTU phase there will be no effort to maintain backward compatibility, yet all changes must be justified and persuasive.

Also there will be a formal bug-tracking system that is attached to the SVN that is used to maintain the source for the FHIR specification. Everyone is encouraged to report bugs, membership is not a factor. All bugs will be formally tracked, discussed, and disposed of. The changes to the specification will be linked to the bug.

There will be regular releases of the 'current' specification, with change-tracking generated from the bug-tracking system. Of these releases there will be some milestones that will be saved for longer times, such as the versions used for connectathons.

I am very happy with this result. Did I want a second ballot, yes. But what I really wanted was a open and transparent discussion of the process, with very visible understanding of the current stability and maturity of the specification with go-forward mechanisms and milestones.

Excited about FHIR, but want it done right

I am a huge supporter of HL7 FHIR. I am involved in the development, the use by IHE, and promoting it inside of GE Healthcare. I am about as involved in the FHIR standard as I can be, given my day-job. I truly want and expect FHIR to succeed. It is far better in many ways than the existing HL7 v2 or v3. It will break Healthcare out of the dark ages, and into the modern world of Interoperability.

The best way to get to this vision is to make sure that it receives as much review as is possible, without going overboard. Too much review is a bad thing too, as many standards have died due to over analysis. However FHIR has received ONE formal ballot, while benefiting from many people experimenting with it at the various FHIR connectathons (hackathons). I encouraged everyone back in August to review and comment Time to kindle the FHIR - It needs ballot comments to grow. I provided 42 comments, mostly focused on DocumentReference (aka XDS),  during this one formal ballot. I worked with Grahame to resolve these. I am happy that they were given the best review by Grahame as they could.

I however want another chance to review the whole FHIR ballot, and even more so I want everyone that is now more excited than ever to have a chance to review and comment on the whole FHIR ballot. There were hundreds of comments that changed almost every part of FHIR. Most of these changes were done by a very small core team that I have total faith in. I am not concerned that the HL7 ballot process was not executed. I am interested in making sure I and all the newly excited people get a second chance. A second chance to make sure the content is consistently following the FHIR core principles and is reasonable quality.

The DSTU phase is a dynamic phase. There WILL be more changes during the DSTU phase. So I know that a second ballot is not necessary to get convergence, this could happen during DSTU. However the more changes we make during DSTU the less visibility these changes have and the more they will break.

I, on behalf of GE, sent the following message to the FHIR Management Group (FMG), FHIR Governance Board (FGB), and the FHIR mailing list.

---------------------------------------------------------------------------------------------------------------------------------------------

GE Healthcare would like to express our complete support for FHIR. GE has provided comments and have seen these comments resolved to our satisfaction. However we would like to encourage the FMG and FGB to support another formal ballot before entering the DSTU phase. This reasoning is not that reconciliation of any specific votes is not satisfactory, but rather that the overall change by the total votes requires a renewed top-to-bottom examination. The most concerning is where a voter (A) was satisfied with a portion of the original ballot, where that section is changed by voter (B) to something that voter (A) would not agree with. It is simply too hard to watch the total ballot reconciliation and track all changes piecemeal.

The future for FHIR is very bright, and now is the time to make sure that it meets all the principles and uniformly applies them. GE realizes that this extra step is not minimally necessary according to the HL7 GOM. We accept the decision of the FMG and FGB, and will continue to support FHIR regardless of if another formal Ballot is executed or if FHIR enters DSTU directly.

--------------------------------------------------------------------------------------------------------------------------------------------

Please give us a second chance to review and comment on the FHIR content before it enters DSTU.

Recirculation Ballot of the HL7 Healthcare Privacy and Security Classification System (HCS)

The HCS is being forced through recirculation ballot because two people are objecting in broad terms to any mechanism that would allow for ‘segmentation’ of data. The committee has tried to address their concerns, which are policy concerns and not technical concerns. We did agree to warn those using the HCS of potential harm caused by segmentation. They have refused to withdraw their negative.

The mechanism for dealing with this in HL7 is a recirculation ballot. A targeted ballot to those that participated in the original ballot asking them to consider the outstanding negative ballot comments and either vote Affirmative to override the negative ballot comments, Negative to agree with the negative comments, or Abstain. The details are in the recirculation ballot package.

The concerns are not unfounded, they are just not related to what the HCS is defining. The HCS is a ‘conceptual level’ concept of using broad concept of security-tags to aid with Access Control for Privacy or Security purposes. It is not a ‘platform dependent’ nor ‘organizational policy’. The specific concerns to be considered are (these are in the recirculation ballot package):

• Data tagging is fragile: I would agree that tagging data is a fragile thing when the tag is conveying current policy. However the HCS is just defining ‘conceptual level’ concept of security-tags, not defining that they must be used or the ‘platform specific’ mechanisms to communicate. Separation of Metadata tags, from Package tags, from Consent Policies is important to robustness and to be agile to policy changes:
• Metadata – Metadata is descriptions of the data, and only the data. This level of security tag really needs to only describe the data. 
• Package – The package is the
  
  abstract concept of the interaction between parties. It would include push or pull interactions. It thus would include something like assertions of who the user that is requesting (pull) data, and under what purposeOfUse. This level of security tag can carry specific obligations about the communication agreement. It would not be duplicative of Metadata, but could be summarization of the Metadata. It could carry obligations related to the interaction (do-not-print), it could carry pointers to consent policies (see next).
• The unfortunate reality is that the –platform specific -- package level tag carrying is not very mature. Thus Metadata tags often carry these Package tags, or they are part of the overriding policies (e.g. DURSA).
• Consent Policies – This is an independently managed policy information point (PIP) that holds the current status of patient authorizations (aka Consent).
  
  This only appears where the parties that are interacting both agree upon one Consent Policy Point. Most of the time a sender and recipient have independently managed Consent Policy Points, as consents tend to be specific to a data-holding organization. There could be a common Consent Policy Point, it would be an independent communications pathway from the package. Most of the time a consent to release is indeed independent of the policy the recipient would need to gain to continue to use or disclose.
• Fine grain tagging could paralyze medical practice. – I don’t necessarily disagree, but this is the concern of Policy, and specific on fine-grain the CDA internal tagging discussion. The HCS is defining only at the ‘conceptual level’ and not indicating if this is fine-grain or coarse-grain. The HCS has no CDA specifics in it. The CDA specific use of the HCS is part of the DS4P ballot, which is being re-balloted. I have pointed at the use of "Transforms" as an alternate model.
  
• LOINC and SNOMED should be used and not a security/privacy specific vocabulary – It is hard to argue that universal and perfect use of these vocabularies would make life easier. Security nor Privacy are going to change that. However from the engine that needs to control security/privacy access, operating on a much smaller subset that represents the rollup from a security/privacy perspective is more efficient and more likely to enforce the right rules. This roll up is done once, rather than at each access (typically). This further supports security/privacy codes as actionable when the content is free-text or graphical or minimally coded. The HCS can also be used in DICOM or IHE standards. 
• Vocabularies pointed at include some dangerous codes – YES they do. The fact that the code exists does not mean it must be used. Even LOINC and SNOMED have some questionable codes, more so in history. Thus the comment should be directed at policies that would be choosing a value-set from these vocabularies. The HCS is just pointing at existing vocabularies and doesn’t forbid other vocabularies.
• Rules are regional – this was not mentioned in the negative comments, but has come up. The rules in one region, the sending region, might not be the same as the rules in the receiving region. Thus presuming that the proper thing will be done will fail. See Rob’s excellent article on this. http://fairhaven.typepad.com/my_weblog/2013/12/confidentiality-code-use-cases.html

Could the HCS be made better? A standard can always take on some improvement. I think this one is in good enough shape for now. As we use it, we can revise it.

• The HCS is predicate work to the DS4P ballot. The DS4P ballot is being re-balloted.
• The HCS is being referenced in IHE as a way of using the multi-valued metadata entry – confidentialityCode. 
• The HCS is being referenced in FHIR

If you were involved in the original HCS ballot, when the recirculation ballot opens on Monday, please set your vote to Affirmative. 

More articles:
Patient Privacy controls (aka Consent, Authorization, Data Segmentation)

• Defining Privacy
• Safety vs Privacy
• Privacy Consent State of Mind
• Defining Privacy
• Universal Health ID -- Enable Privacy
• Texas HIE Consent Management System Design
• Simple and Effective HIE Consent
• IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
• Data Segmentation - now I know where the term comes from

Access Control (Consent enforcement)

• Healthcare access control scope constraints on OAuth tokens
• Advanced Access Controls to support sensitive health topics
• Policy Enforcing XDS Registry
• Healthcare Metadata
• Texas HIE Consent Management System Design
• IHE - Privacy and Security Profiles - Access Control
• Data Classification - a key vector enabling rich Security and Privacy controls
• Healthcare Access Controls standards landscape
• Handling the obligation to prohibit Re-disclosure
• Access Controls: Policies --> Attributes --> Implementation
• IHE - Privacy and Security Profiles - Document Encryption

My Predictions and Year in Review 2013

I don't like predictions or reviews, but it seems bloggers are obliged to do this. I did make predictions last year, so I must also measure myself against those predictions.

Speed Bump Comic Strip

I am still excited by opportunities and results.

Less Blog posts in 2013 and 2014

My job at GE Healthcare is to create and promote Interoperability Standards; specifically in HIE, Security, and Privacy. This means that I have a dual focus: outside development in standards organizations (HL7, DICOM, IHE, ISO) and government adoption (S&I Framework, HIT-Standards, HealtheWay, WISHIN, epSOS, Saudi-MoH); and inside promulgation of those standards into products and services. The outside efforts had been put into place in the previous years, and had a reasonable trajectory; so my focus this year has been far more internal focused. Thus I have created less blog articles in 2013. In the three previous years I have created about 95-97 articles, with some months producing 14 or more (thanks to ONC). In 2013, I have only produced 56 articles, with one month with 12 articles (thanks to HL7 ballots including Digital Signatures, DS4P, and FHIR). Some people try to produce a blog article every day, I am happy with one a week, or one a month.

Past Predictions
I predicted three themes for 2013: Mobile, Privacy, and Services. The following themes that appeared throughout the year nicely fit these three high level themes, most of the time fitting all three (Accounting of Disclosures).

Measurements toward Predicted Theme
The themes that appear in 2013 posts

• mHealth Security (1), (2), (3), (4), (5), (6), (7), (8), (9), (10), (11), (12)
• FHIR (1), (2), (3), (4), (5), (6), (7), (8)
• Safety (1), (2), (3), 
• Privacy (1), (2), (3), 
• DS4P (1), (2), (3), 
• De-Identification (1), (2), (3),
• Accounting of Disclosures (1), (2), (3), (4), 
• HIE (1), (2), (3), (4), (5), (6), (7), (8), 
• Digital Signatures (1), (2)

Others view of my blog
This is satisfying to me, but not what my blog Google Analytics show was most interesting to the readers during 2013. The top most viewed articles are all from 2011 and 2012. One of them I didn’t even write.. In order, the most popular Posts in 2013 by click count:

1. Meaningful Use Stage 2 - Audit Logging - Privacy and Security
2. Meaningful Use Stage 2 -- 170.202 Transport
3. How to apply Risk Assessment to get your Security and Privacy and Security requirements
4. IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
5. Creating and using Unique ID - UUID - OID
6. Topics (my table of contents)
7. Patient Portal - view, download, TRANSMIT
8. IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
9. How granular does an EHR Security Audit Log need to be?
10. The Basics of Cross-Community Patient Discovery (XCPD) - Guest blog by Karen Witting

Posts fading away

I was glad to see these past popular articles become less interesting. They are all now 3+ years old, and likely not accurate today. Please let them fade away.

• Meaningful Use Encryption - passing the tests
• Meaningful Use Certification issue with Encryption of data-at-rest
• Meaningful Use Security Capabilities for Engineers

Theme in the theme
I am very happy that the most top viewed article posted in 2013 during 2013 was the one where I Define Privacy. This comes in at the 15th most popular article this year. The other articles written in 2013 that breaks the top 40 are where I Define Security Audit, and try to Define mHealth. Is this telling me that I should be in the Definition or Vocabulary space? I also posted this year that Vocabulary Standards make poor User Interfaces.

Predicting 2014

I suspect that the US government will continue to be consumed by things that are already in play. There will be a small number, mostly ONC and HIT committees, that keep trying to figure out what MU3 should be. The problem they will face is that it is not clear what the benefit of MU3 is going to be when so many are consumed by things already in play. 

Bluebutton+ will seem right, yet confuse. There will be some easy things, like "Bluebutton+", but as I point out on Keith's blog this is too nebulous of a specification to figure out what it means. The message needs to be made more clear, what part of the "Bluebutton+" experience is to be mandated and measured? I hope it is the CCDA, and not the transport. But Keith sees it otherwise.

Add caption

I don't object to the transport but it is pre-standards specification. I would rather see us mature the "RESTful" concept under FHIR and MHD, with security models from IUA, DS4P, and other projects underway. Getting this right is more important than getting it done fast. This is not to say that HIEs should not look to Bluebutton+, they should. The action should be to experiment and reflect on that lessons learned so that we improve the standards so that we get something worthy of mandate and measurement.

HIE Patient Identity. We will continue to work on the Patient Identity problem, more so this year. There was much talk in the past few years. There was some intense, urgent, work done in CCC and CommonWell. This work will be brought out into the open. We will learn that this is NOT  at technical problem, the standards support what is needed. This is a 'business' operational issue, and a 'privacy' issue. Meaning businesses don't want to change what they are gathering, yet everyone gathers different information. If we must  do patient matching, then we must all gather the same demographics with the same level of accuracy (Level of Assurance). For example, everyone must gather the SSN completely, not just the last four digits. This brings up the 'privacy' problem that this creates. We will not see a universal patient ID, but we will see what sure looks like one. It will simply be a well-structured-and-normalized mashup of the demographics all hashed together. This will fail to match sometimes, but it won't have false matches (false-positive).

Profiles. Simply the  USA will realize the need for Profiles. This  might not be "IHE" profiles universally. I am okay with that. I fully expect that HL7-FHIR will produce some profiles this year. I fully expect that HHS/ONC/HIT-Sc/HIT-Pol/S&I-Framework will come up with a concept closer to a 'profile'.  This is not far off, but not being done today with purpose. The purpose will come when the community sees what IHE does with DS4P. The result is simple and measurable. 

And everything else. Yes Security, Privacy, and HIE will continue to evolve and mature. This is going along at the right pace. Many want it faster, but faster is not how one moves such a large industry like healthcare. Especially since healthcare is very much thousands of competing organizations with highly educated and driven individuals as the workers. My themes from last year will continue to be the right themes: Mobile, Safety, and Services.

Optimism

Overall I am excited at our progress. It really is a team-sport. There are far more people 'doing' than ever before. There is a more common goal than ever in the past, and the majority of efforts are all clearly toward that goal.