Additional population guidance - EMS Event Header Information

[james-answer]

EMS-MessageHeader-1 resource

Element	Description or requirement
extension(eventMessageType)	The spec does not mention the eventMessageType even though this item is mandatory in the resource. There is no information to say when to use the "new", "update" or "delete" values. We should make clear what the expected use of the values should be if we want a generic EMS approach or we should say that the expected functionality will by outlined by the specific event message specifications if the meaning of this field can be different for each of the events.   DF - We need to do a small piece of work on the lifecycle of an event which we can refer to here.
event	I assume guidance around which event type to use will be included in the event specific guidance pages, therefore I think we should add additional wording to say that which "event" value to use will be specified in the specific event message specifications.
timestamp	This is a mandatory element in the resource and has a meaningful description in the profile so probably does not need to be in the spec, I would suggest removing it as having it in the guidance page does not add any information. DF - Agree
source	Currently it says that the source element should be included but all the sub elements are optional within the profile. I think we should add to the guidance a minimum set of elements that we would like populating, probably the name, contact.system, contact.value, ie enough information to be able to contact the origional source of the event message. This could be done in the profile by making the elements we want 1..1   DF - We do need to make the provenance of the event clear – there are obvious overlaps with the Organization resource so we need to consider which attributes the publisher needs to include.
focus	We should probably add wording to make clear that the "focus" element will reference a different resource type depending on the event message being sent and outline that the specification for each event message will define which resource type this element will reference.   DF - Agree – we need to make it clear what the focus refers.

EMS-Communication-1 resource

Element	Description or requirement
status	The "status" element is mandatory in the resource, we should probably specify what it should be populated with as the different values can change the meaning of the resource significantly, for example "completed" is very different to "entered-in-error".   DF - Agree – this should be linked to the lifecycle of an event which will define what values we would be expecting.
sender	We could do with additional information around which circumstanses this might contain an organization or a helthcareService resource reference or no reference. What are the use cases for each type of reference and inclusion of the different resources?
payload	The "payload" elemnet is mandatory so we should give guidance as to what should be referenced and when. If the "payload" element population is event specific then we should call it out in the spec to say that population details will be in the event specific message specifications.

EMS-HealthcareService-1 resource

Element	Description or requirement
providedBy	We should probably call out what the reference "organization" resource should represent and containing, for example an organization resource containing an ODS Code identifier, representing the legal entity of an organization?   DF - Agree
type	The healthcare service "type" element has a fixed valueset which does not have consistent values. For example EMS and PDS are services, UHV Health Visitor is a person, CHO Child Health Organisation is an organization. Should the service types actually all be clearly identifiable services, do we need to re-visit this value set and make sure we have clear guidlines on what this value set represents?

CareConnect-EMS-Patient-1 resource

Element	Description or requirement
identifier (localIdentifier)	The local identifier slice is meaninless as it has a fixed value of "https://fhir.nhs.uk/Id/local-patient-identifier" which means if two suppliers populate it with their local identifier, it is no use to the other system as they don't know where the origional identifier came from or what type of identifier it actually is. I would suggest removing this slice from the profile. I heard this identifier slice is a hang over from some CDA identifier stuff but is not appropriate or useful for fhir resources  DF - Makes sense.
address	If an address is included we should mandate atleast population of the text element with the full address and only include structured address details if all details can be populated fully, what is the minimum we would accept as a structured address, just the post code and first line of the address? It simplifies the consumers job if they know what to expect as a minimum rather than the data possibly coming through in different ways within the resource element.
contact	Probably not relevant to NEMS core spec but we should have a consitent expectation that if a contact is included for a patient what details we would expect as a minimum, name, telephone number once again for consistency making it easier for the consumer?

CareConnect-Organization-1 resource

Element	Description or requirement
identifier	should we want to add guidance that if the identifier is an odsSiteCode that there should be an identifer with ODS Org Code or a partOf element with reference to an organizaition. We need to make it clear where a consumer of this resource can get the information to build up a picture of where this data came from, i.e. if this is a site as per the site code where can I find in the resource the organization which manages this site. Like in other resources the local identifier slice is meaningless outside the same fhir server as consumers may be using a different local identifier system, because the system is a fixed value it is impossible to know what sort of identifier is sent in this slice.
name	It would be useful to have a name for the organization that a consumer could just display, it might be worth mandating that publishing systems populate this element, possibly making the element 1..1 in the profile.
telecom	Do we want organizaiton resources to contain some sort of contact details for the organization, ie make this mandatory for a publisher of an event?

[james-answer]

Done most of the updates. A couple of things need seperate work such as event life cycle and I will create new issues for them. Changes have been committed to the develop branch.

[james-answer]

This has been merged in and pushed to current version so closing.