Furore devdays 2017- profiling academy - profiling guidelines v1

1. FHIR® is the registered trademark of HL7 and is used with the permission of HL7. The Flame Design mark is the registered trademark of HL7 and is used with the permission of HL7.
Amsterdam, 15-17 November | @fhir_furore | #fhirdevdays17 | www.fhirdevdays.com
Profiling Academy – Profiling Guidelines
Lilian Minne, Furore

2. Who am I?
• Name: Lilian Minne
• Company: Furore, Amsterdam
• Background:
• PhD in Medical Informatics
• FHIR consultant / profiler
• Contact:
• l.minne@furore.com
2

3. Programme
• Session 1 (14:00-14:40)
• Profiling Academy
• Profiling guidelines
• Session 2 (14:45-15:30)
• Questions & answers
• Bring your own use cases
• Exercises on Profiling Academy
3

4. Profiling Academy
• Launched today!
• https://simplifier.net/ui/ig/ProfilingAcademy/ProfilingAcademy
• Who is it for?
• Anyone willing to learn more about Profiling (beginners and experts)
• Available for all registered Simplifier users
• Short modules covering 1 topic each
4

5. Profiling Academy
5

6. Profiling Academy
6

7. Profiling Academy
7

8. Profiling Academy
8

9. Profiling Academy
9

10. Profiling Guidelines
• Related to module in the Profiling Academy
10

11. Profiling guidelines
11

12. Part 1: Plan (design)
• Check what’s already out there
• Reuse (national) profiles
• Open vs closed modeling
• (Naming) conventions
• Functional definition
12

13. Check what’s out there
• FHIR specification
• Simplifier
• FHIR registry
13

14. Reuse (national) profiles
14
National identifier (BSN)
Hospital patient number
Race

15. Reuse (national) profiles
• Example: nl-core-patient
15
use of preposition in Dutch
name, e.g.: “Piet de Vries”
Dutch national identifier

16. Open vs closed modeling
Open model Closed model
16

17. Open vs closed modeling
Open Closed
Pros
• Forward compatibility
• Focus on what must be supported
• Fit more data
• No need to support all elements
• More specific models
• Smaller, straightforward models
• More implementer feedback
Cons
• Needs support of all elements
• Larger, vaguer models
• Less implementer feedback
• More versions of models
• Only backwards compatibility
• New elements require new version
17

18. Naming conventions
• In general:
• UpperCamelCase for resources
• lowerCamelCase for elements & slice names
• lowercase for extensions, using following format:
[context]-[name], e.g. patient-age
• Use name of country as a prefix / suffix
18

19. Naming conventions
• Example Nictiz:
• http://[domain]/fhir/[ConformanceResource]/[project]-[name]-[semver.major]
• http://fhir.nl/fhir/StructureDefinition/nl-core-patient
• http://nictiz.nl/fhir/StructureDefinition/zib-Dispense-1.0
• Example Germany:
• http://fhir.de/StructureDefinition/condition-de-basis
• http://fhir.de/StructureDefinition/condition-de-icd10gm
19

20. Functional definition
• ConceptMap resource
• ValueSets and codes
• StructureMap resource
• Relation of structures
• Allows automated conversion
• FHIR mapping language
• ElementDefinition.mapping
• Free text mapping within profile
• Harder to use when reusing profiles
20

21. Functional definition
• Example of ElementDefinition.mapping
21

22. Part 2: Collaboration
• Git repository
• Simplifier project
• Workflow / feedback loop
• Issue tracking
• Implementation Guide
22

23. Git repository
23

24. Simplifier project
24

25. Workflow / feedback loop
• Consultation rounds, web meetings etc.
25

26. Issue tracking
• Feedback team members / community
26

27. Implementation Guide
• Describe how to implement usecase(s)
• Include at least:
• Data definitions
• Use cases
• Actors
• Interactions
• Examples
27

28. Implementation Guide
• Example IG-editor Simplifier
28

29. Implementation Guide
• Example WiKi page
29

30. Part 3: Deliver (profiles)
• General
• Design
• Extensions
• ValueSets
• Mappings
30

31. General: Narrative
• Always fill the narrative with:
• A short description what it is (profile or extension)
• What FHIR resource it is profiling or extending
• One-sentence description what it does
• E.g. An extension <description> or A profile on <resource> <description>
• Set status to empty
• As it is neither generated nor additional content

32. General: Definition
• Copy-paste description into definition
• So it shows up at the start of the resource in Details view

33. General: Saving a Profile
• Extend filename with Resource Type, e.g.
• myPatient.structuredefinition-profile.xml
• workedOnMonday.structuredefinition-extension.xml
• This helps you to distinguish between StructureDefinition files

34. Design: Constraints
• Example: ContactPoint has constraint on System
• Choice: Constrain min cardinality in profile to make it more visible
34

35. Design: Coding datatype
• Code
• Bound to non-extensible and required code list
• CodeableConcept
• Supports textual representation
• Contains one or more Codings
• Coding
• Use is limited
• Primarily in extensions where there’s need for finer control over use
of translations and text
35

36. Design: Future use of data
• When profiling, keep in mind:
• Searches you want to do later
• How you want to transport data
• Example Nictiz:
• ZIB TreatmentDirective
• ZIB AdvanceDirective
36

37. Extensions: Description
• Complete description in:
• Extension itself
• Profile(s) it is used in
• So viewer doesn’t need to dig up extension

38. Extensions: Purpose
• Always fill in why you create the extension
• Not per se necessary for the profile
• Avoid future confusion due to evolving FHIR landscape:
• New extensions
• Updates core specification to cover your use case
• Resulting in duplicated functionality

39. Extensions: Reuse
• Before building, check if one already exists:
• Simplifier.net/core-extensions
• FHIR specification: hl7.org/fhir

40. Extensions: Constraints
• Constrain extensions at profile level
• Make them as generic and reusable as possible

41. Extensions: MustSupport
• Only apply mustSupport in the profile
• Not when defining extension itself
• Extension is more reusable this way

42. Extensions: IsModifier
• Provide isModifier flag at extension level
• Once created, you know it effects the meaning
of the resource you apply it in

43. ValueSets: General
• Preferred binding on extension level
• Choose binding level in profile level
• Extension is more reusable this way
• Place binding on value[x] not extension itself
• Selecting type of reference
• Explicit ValueSet: Reference(ValueSet), preferably canonical URL
• Implicit ValueSet: uri

44. ValueSets: Extending a required ValueSet
• If a ValueSet is required
• And you need to extend it
• Make a new extension and a new ValueSet

45. Mappings
• Always try to fill in the mapping to the logical mapping
• Use comments field to describe imperfect mappings
• Use mapping in the profile (not needed in the extensions)

46. Short summary
46

47. Don’t forget to visit our Profiling Academy
https://simplifier.net/ui/ig/ProfilingAcademy/ProfilingAcademy
47

48. Thank you for your attention!
Any questions?
48