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, December 8, 2009

More on Language

This time the issue is inclusive language.  Several times over the past two days I've been involved in various discussions around standards around that particular topic.

Several readers complain that a given specification hasn't listed a given profession, care activity, or other detail pertinent to a specific job function in a list that's clearly marked as being an incomplete set of examples.

Other comments indicate that certain types of documents should be included in such a list of examples.

A specific example in one document is faulted because it uses a concrete term in a detailed example, indicating that the example need not use THAT concrete term, and could use others.

In another case, we are asked to rewrite requirements coming from a third party to incorporate those necessary for a specific type of product.

I have three ways to deal with these issues:
1.  Ensure example lists are clearly marked as examples, using terms such as for example, e.g., or "as in the following incomplete list".
2.  Point out to the commenter that a specific example is being given that doesn't indicate preference for any given concrete term.
3.  Add the suggested term to the list, or find another change that can be made to make the commenter happy.

In all cases, these discussions and the resolutions:
1.  Do not impact the normative text of the document (what needs to be implemented in the specification).
2.  Make the reader with a specific focus feel as if their concerns are addressed.
3.  Consume time.

It's a frustrating balance.  The end result is a document that will please a wider audience, at the cost of time.  I continue to remind myself that making readers happy is an important component of getting specifications read and understood.  It is amazing what inclusive language can do for a reader, even though in the end, it may not change anything required by a specification (the specifications usually already support the given requirement).

I'm defining the terms clinician, healthcare provider and provider organization in my book right up front because I want everyone to understand what I'm saying and why there is a need to distinguish between these three entities.  I'm even having to deal with comments from reviewers on that language.

Oh Lord, give me patience, and give it to me NOW!  -- Unknown


Post a Comment