The previous post explaining FHIR for a v2 implementer generated some private comments which leads to me to post two more lists: FHIR for CDA and V3 implementers.
Start with a Consolidated CDA document… and imagine….
- we’ll give each section a URL to identify it (it can be a local reference if we want) – now we can handle them independently
- we’ll use xhtml instead of the existing CDA narrative
- we’ll take each section and rename the fields for the specific use it has (i.e. the CCDA template – which means we can get rid of templateId)
- while we’re at it, we’ll simplify the xml and the definitions a little because the RIM-speak has been moved into the background
- treat the header just like the sections – gets it’s own narrative
- we’ll increase the control over the relationship between the narrative and data for people that use that
- we’ll add an extension sub-section for extensibility, with a single schema
- when we actually assemble a complete document from the pieces, we’ll bundle them together using an atom feed – lot’s of side benefits from that.
- Call the sections “resources”
Explaining FHIR to a version 3 messaging person is a little bit more complicated, courtesy of the deeper stack that is v3.
Start with a v3 interaction, including all the RMIMs that are used to construct the message and imagine the following:
- We’re going to begin by re-crafting the models as RMIM-specific domain analysis models (DAMs) – using business friendly names, and getting rid of all of the extra classCode, moodCode and deep nesting paths that RIM modeling requires
- However, we’ll keep a mapping that identifies how each of the classes, attributes and associations from the DAM corresponds to the RIM that those who want to can still look at.
- We’ll create roughly one DAM for each RMIM, though if we’ve got multiple variants of some CMETs (e.g. identified, identified confirmable, universal, etc.), we’ll create just one DAM for the combined set
- We’ll also simplify where we can, only keeping those data elements we expect most systems to actually use. We’ll handle all the special case stuff separately.
- Take the model view of each of the DAMs and craft XML structures for them, using the business friendly names as tag names and ordering things in a way that makes sense to the average business user.
- We’ll give a URL to each of the instances of these models so we can maintain instances of the various CMETs and payloads individually if we wish
- We’ll also add an ability to have human readable text as xhtml for each of those models, similar to CDA
- To handle all of those special cases we threw out earlier, we’ll give each resource an “extensions” section where those less common elements can be sent by those who need them, without breaking the schema or burdening all implementers with understanding them
- We’ll call each of those simplified DAMs “resources”
- To craft our message, we just collect all the resources and send them as an aggregation in an atom feed, starting with the resource that corresponds to our transport wrapper RMIM, which we’ll call Message
Thanks to Lloyd McKenzie for contributing the second list.