Inm fhir comments 20120505

InM FHIR Message Resource

---

This page is a beginning of discussion of comments specifically addressing the FHIR specification of the Message Resource.

Quality

On the main page there is a link to the wiki http://wiki.hl7.org/index.php?title=FHIR_Message_Page Which has no text!

• gg: wiki pages are all linked to in prospect. feel free to add text

Message <instant> http://hl7.org/implement/standards/fhir/instant.htm#instant invalid link

• gg: fixed next release

Message<source>(Device) http://hl7.org/implement/standards/fhir/Device.htm#Device invalid link Message<destination>(Device) http://hl7.org/implement/standards/fhir/Device.htm#Device invalid link In the datatypes I cannot find a definition for Device – probably there, but not on the datatypes.htm page. It appears device is a resource, but again, no definition.

• gg: device is not yet defined

Message(Any) http://hl7.org/implement/standards/fhir/Any.htm#Any invalid link Message <text> http://hl7.org/implement/standards/fhir/Narrative.htm#Narrative invalid link

• gg: hmm, have to fix that link

Instant is “an instant in time known at least to the second. “ why is this not bound to a universally recognize time datatype?

• gg: actually is bound to a universally recognised time data type. why do you think it isn't

Use cases

• IMHO the specification needs well defined use cases
  • The uses cases are required to describe the problem that is being solved.
  • Without them, the resources are meaninless.

Resources

• The specification states "A resource must have a master id that is never changed "
• The definition of id is
  • A whole number in the range 0 to 2^64-1, optionally represented in hex, a uuid, an oid, or any other combination of letters, numerals, "-" and ".", with a length limit of 36 characters
• IMHO the ID should have several attributes.
• In multiple vendor interoperability paradigms, there is no way to ensure a simple number or OID is sufficient to uniquely identify the resource across time.
  • At a minimum I would suggest Identifier

<x xmlns="http://www.hl7.org/fhir">
  <system> cond uri The system that defines the id</system>
  <id> cond string the actual identifier</id>
</x>

Message Resource

• <message><id> is an ID, which is allowed by the spec to simply be a number.
  • “A message receiver must always check the incoming aggregation package ids, and check them against a store of previously received messages (going back a reasonable period in time).” While the use of ID as a number MAY meet some requirements, the store of id’s in a multi-vendor environment would then require at a minimum a cache of <id><source> to meet the minimum requirements - which to me begs for an Identifier instead.
  • Recommend this be part of the spec from the gitgo. Remember that although the intent is to make this "Fast", failure to define sufficient criteria at the start leads to interoperability problems later.

• <message><Enterer> and <Message><author>
  • elevates information in the message to a level where it may not correctly reflect the relevant information – especially when the message is an aggregate of multiple resources.
• is there a use case for this information at this level?

Conformance Statement

• Best practice requires that Conformance statements be
  • Mandatory
  • Discoverable
  • Machine processable
• The term "published" makes it vague - allowing a paper book, word document, PDF or web page to meet the criteria.
• Leaving this as a MAY will ensure that many systems will implement/enforce it never.
• In fact MAY does not even define it as a best practice.
• IMHO this is a SHALL.

• <MessageConformance><publisher>
  • <name>Textual names of Publishing organization(s) are insufficient. Many organizations consist of multiple entities that have a common name.
  • E.G. Mayo Clinic identifies an entity that spans multiple practices in multiple regions in multiple countries. Brand identity has asserted that all of these entities be known textually as Mayo Clinic. But the textual name of these entities have morphed over time, and as such, Mayo Foundation for Medical Education and Research may not be recognizable as synonymous with Mayo Clinic. One possibility is an <effective-date> field on the name.
  • The addition of <governmentRegistration>mand code Government registration code would allow for the changes across time.
  • <address> opt should not be optional – there are an increasing number of organizations who share the same name, but various addresses.
  • <MessageConformance><date:Human date> may not be computable – and I believe it should be.
  • <MesssageConformance><Software><Version> should likewise be a coded value
  • <MesssageConformance><Software><releaseDate> should not be optional.